RSS

Category Archives: Agile

Performance Appraisal on Agile Projects

Over the last week I’ve had two people ask me about performance management and appraisals on Agile projects.  This post is to provide them with some answers and will hopefully be useful for others in the future.

One area where the adoption of Agile approaches often bumps up against established organisation structures and frameworks is in the realm of performance management of individuals.

There is a lot of research to show that many of the current performance management approaches are actually demotivating and harmful, especially in environments (such as on Agile project teams) where the most productivity and value comes from collaboration and teamwork.

Daniel Pink gave a fantastic TED Talk in which he examines the science of motivation: http://www.ted.com/talks/dan_pink_on_motivation.html

In their book Craig Larman & Bas Vodde, discuss many of the problems inherent in the performance appraisal process, and how they actually destroy motivation and destroy team cultures – see “Scaling Lean and Agile Development”, Addison Wesley, 2009, pp.  267, 268

Even management guru W Edwards Demming advised organisations to “Eliminate Management by Objective”  and  urged “…abolishment of the annual or merit rating …”.  (Deming, W. Edwards (1986). Out of the Crisis., Chapter 3. MIT Press)

Michael James published an article in Better Software magazine entitled “What HR Doesn’t Know about Scrum” in which he summarises some of the key issues with traditional HR approaches and Agile (Scrum) practices.

The article can be found here: http://danube.com/system/files/WhatHRDoesntKnowAboutScrum_BetterSoftwareMagazine.pdf His key points are that many of the existing HR practices are derived from the era of Scientific Management and they don’t work for knowledge worker roles.   Individual performance appraisal drives behaviours that are contrary to team effectiveness:  “Team self-organization around business-driven goals will fall short when individuals also have goals of looking good for the boss or outscoring teammates in 360-degree peer review contests.

He goes on to discuss the importance of hiring for team cohesiveness rather than individual skills, ideally allowing the team to choose new hires themselves.  Yes, technical skills are important but more important is the ability of the team to jell and work effectively together.

Other commentators have written about the danger of individual performance reviews on Agile teams.  Esther Derby posts about the dangers of the review process, and she provides advice on addressing the common concerns among managers when looking at changing the review process.  (http://www.estherderby.com/tag/performance-appraisals)

She lists the most common  reasons for having performance appraisals and addresses concerns around them

  • Determining how much to pay people
  • Determining who to promote or fire
  • Helping team members understand how they need to improve

http://www.estherderby.com/2010/07/performance-without-appraisal-addressing-the-most-common-concerns.html

If organisations insist on retaining performance reviews there is some advice available from Alan Atlas in the Agile Journal.  http://www.agilejournal.com/articles/columns/column-articles/5742-performance-management-for-agile-people

He examines the motivation for performance management, discusses why they generally don’t work, and gives some possible approaches that could be used.  His key points for performance appraisals are:

  1. Give all of the members of an Agile team the same performance goals.
  2. Assign individual goals for individual development.
  3. Make sure individual goals are aligned with team goals.
  4. Frequent 360 degree performance feedback is better than many alternatives.
  5. Value highly the personal traits, characteristics, and behaviors of good team members.

Jeff Sutherland posted his approach to performance reviews and presents a possible approach for an appraisal process here: http://scrum.jeffsutherland.com/2006/11/agile-performance-reviews.html

Lean & Agile thought leader Mary Poppendeick has also written at length on the topic in this article http://www.poppendieck.com/pdfs/Compensation.pdf where she examines the typical dysfunctions caused by the process, and provides guidelines for designing an effective performance management system.

Tara Hamilton-Whitaker of the Agile 101 blog has two posts discussing an Agile Balanced Scorecard, which can be used to assess a TEAM as a whole, rather than trying to assess the individuals against one another.

http://agile101.net/2009/07/18/agile-balanced-scorecard-measuring-the-effectiveness-of-an-agile-software-development-team/

http://agile101.net/2009/07/19/the-agile-balanced-scorecard-tracking-the-reliability-of-an-agile-software-development-team/

I hope this helps, and as always I welcome feedback.

Posted by Shane Hastie

 
Leave a comment

Posted by on February 26, 2012 in Agile

 

Tags:

Scrum Thoughts

I’ve just spent the afternoon reading the updated Scrum Guide from Ken Schwaber and Jeff Sutherland.

There are some great points in it – some of which I have recorded here because in my experiences working with the various agile teams that I have met over the years it is good to have a reference point for some of the key things that I have noticed not working correctly, but are being done in the name of Scrum.

“Scrum recognizes no titles for Development Team members other than Developer. Regardless of the work being performed by the person, there are no exceptions to this rule; “

I like this – it is not the “developer” definition in the sense of a developer being someone who writes code, but a developer is someone who contributes to the development of the product. This has been used and maybe even abused in the past where teams consist of only programmers, rather than a cross skilled group of “developers”. We need to think about the skills needed in the team and the proportion of those skills, and what work is required to be done to complete the task as opposed to the titles of the team members.

“each event in Scrum is an opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to insect and adapt.”

This one is a good one too – how many times to team decide to not do something because they don’t see the value and then head off down the wrong path. I was recently speaking to a group who does not do Showcases at the end of an iteration – why not? The extended team did not want to attend….what a missed opportunity and a “failure” according to the Scrum guide.

“Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product.”

This will challenge a lot of people’s thinking, particularly those teams who are tending to do incremental delivery of a predefined product, not looking at each interation as a separate activity that needs to be planned and actioned appropriately. I said something similar to this in a training session lately and almost everyone in the class gasped….until I explained the concept, then they all said “yup – that makes sense” (phew!).

“The Daily Scrum meeting is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours.”

How often do we hear of Stand-Ups being extended for the longer period. Meeting still need to happen but the standup or Daily Scrum is so important for this synchronisation and planning actions – teams that are dysfunctional and don’t understand the need for the stand-up or do them poorly often don’t have this coordinated view of what needs to be done by the whole team!

 
Leave a comment

Posted by on August 5, 2011 in Agile

 

Tags: ,

Splitting stories and exploding scope in agile projects

We used the  “Abstract to concrete” approach to splitting stories in a training course recently.The approach is published in our “resources” page, alongside some other approaches that also work.

But I told the class I would publish it here for easy reference, so here it is.

008

Read the rest of this entry »

 
1 Comment

Posted by on July 2, 2011 in Agile, Business Analysis

 

Tags: ,

‘Soft’ skills or dealbreakers?

A few weeks ago the Australian sales team headed down to Sydney to attend Agile Australia 2011. They had a busy couple of days meeting and talking to Agilests from all over the country and noticed a common theme. Lots of companies have adopted the practices of Agile without accompanying them with the necessary cultural shift that they needed to make things actually happen. Anyone working in software development will have heard that story before and it always makes me wonder why we still use the term ‘soft skills’. Soft skills are not a small, unimportant or unnecessary thing to consider, they are the crux of your organisation’s ability to succeed. If you can’t talk to people, listen to them and work together you’ll never get anything done!

With regards to Agile, in order for projects to be successful you need support from your business and investment in training and coaching so that all staff members come along for the ride. The processes of Agile and Scrum are important, but without understanding why you are following these processes it’s going to be almost impossible to make anyone do them (which is the reason SoftEd’s Agile training courses focus on awareness as well as process).

What else did they see at the conference? First of all keynote speaker Alistair Cockburn talked about Agile UX Design as an ‘up and coming’ area of interest. They listened to Rob Thomsett‘s presentation on whether your business is ready for Agile According to Rob, “implementing Agile practices is a disruptive cultural revolution” and Agile business models are based on simplicity and transparency. Daniel Oertli, who has made big changes at REA Group, promoted the value of planning (not plans necessarily, but the actual planning process) and of being customer centric rather than customer driven (an important distinction I think, after all you can’t and probably shouldn’t do every single thing that every customer requests, but you need them at the heart of your organisation to make sure you’re going in the right direction).

According to Michael Bromley Agile isn’t the point, better is the point, and his organisation (NBN-Co) believe that Agile is radical and will take time to develop, but the only way to make this happen is to get started and go for it because you learn Agile by being Agile. Just as you learn, fail and improve in Agile projects you must learn, fail and improve at doing Agile itself, “Agile is a way of thinking”.

There were a few other things you see at most conferences nowadays: panel discussions, game playing (the marshmallow challenge) and the usual buzz-word bingo (everyone has their favourite terms!) which keep us entertained over the two days. Thanks Agile Australia!

And just one last thing, we at Software Education run conferences as well: SDC, focusing on business analysis and Agile and STANZ, our testing conference. We are really proud of the calibre of international speakers who present at these events and the high quality of the event, the material and the discussions which is always reflected in the feedback we get so if you’re interested in coming along, or want to know more about us in general please go to www.softed.com. Thanks!

 
Leave a comment

Posted by on July 1, 2011 in Agile, Culture

 

Tags: , , , , , , , , , , , , , , , , ,

SoftEd runs a course in Israel for M86 Security

Software Education is delighted to announce that we are delivering our Practices of Agile Teams training course for M86 Security, the global expert in real-time threat protection and the industry’s leading Secure Web Gateway provider. Our chief knowledge engineer Shane Hastie is flying to M86’s R&D centre in Tel Aviv, Israel in July to deliver the Agile course and will then go on to M86’s offices in Orange County (O.C. ) in California to provide some consultancy services, following on from training he delivered to the O.C-based team last year.

This will be the first time that SoftEd has delivered a course in Israel, although we have always had a global reach with courses taking place in the U.K. and U.S. as well as Australia and New Zealand. We are proud to see that yet again knowledge from ‘down under’ has such influence across the world! M86 Security are a global organisation and our ability to work with them in Israel, the U.S. and New Zealand is a testament to our dedication to providing our customers with a tailor-made solution for their training requirements. Shane first gave a short Agile tutorial to the M86 Security research and development team in Auckland, which lead to more training for their New Zealand team and then the opportunity to work with the team in O.C., culminating now also with the trip to Israel. Thom Linden, SVP of Global Research and Development at M86 Security said, “To make a successful transition to Agile, training and coaching from experts, who have the right combination of knowledge and effective interaction skills are extremely valuable. SoftEd has achieved great results in mentoring our development teams to adopt practices and tools to successfully apply Agile in our business.”

Shane is looking forward to this trip, which adds to what has been a busy and exciting year for him with not only several training and public speaking engagements but also with his work with the IIBA defining the Agile Extension to the BABOK (Business Analysis Body of Knowledge). He is the only Australasian member of the committee developing BABOK version 3.0. Shane will also be speaking at Agile 2011 in Salt Lake City on 8 – 12 August with Steve Adolph.


M86 Security is the global expert in real-time threat protection and the industry’s leading Secure Web Gateway provider. The company’s appliance, software, and Software as a Service (SaaS) solutions for Web and email security protect more than 25,000 customers and 26 million users worldwide. M86 products use patented real-time code analysis and behavior-based malware detection technologies as well as threat intelligence from M86 Security Labs to protect networks against new and advanced threats, secure confidential information, and ensure regulatory compliance. The company is based in Orange, California with international headquarters in London and development centers in California, Israel, and New Zealand.

Software Education are internationally recognised for their expertise in software development training. With over 50 different course titles in Business Analysis, System Design, Programming, Software Testing, IT Management and Agile Development, Software Education not only provide access to leading-edge content but also to an unrivalled network of international experts.

Whether through Software Education’s public courses, individually tailored in-house training or our international conferences, STANZ and SDC, you will acquire practical, relevant skills which you can use immediately or work towards certification.

 
Leave a comment

Posted by on June 21, 2011 in Agile, Courses

 

Tags: , , , , ,

Answering questions from the User Stories Webinar

Last week I delivered a webinar talking about building good user stories. We had nearly 200 participants from five countries. Thank you to everyone who took the time to register and participate.

I was unable to respond to every question as they were asked in the chat window, and we had to stick to the limited time we had available.

Fortunately we were able to record the questions so I could try to answer them after the event. Here are a sample of the questions with my answers. Where more than one person asked a similar question I have only recorded it once, and there are a few questions that I can’t answer publicly 🙂

There was one question about the work being done on the Agile Extension to the BABOK(tm) – is the working group only looking at techniques or at the broader framework?
We are examining all aspects of how Agile techniques impact on all aspects of business analysis activities. Keep an eye on the IIBA(tm) website for more details as the work progresses.

When we were talking about the Vision Box someone asked: Would going into detail like logo and other not destract the purpose of the vision meeting?
The logo and other details are not intended to be high-fidelity or precise, they are meant to provide a hook for the conversations and creation of shared understanding of the vision. Don’t get bogged down in the exact placement of graphic elements, fonts and Pantone colours – focus on the essence of the vision elements.

The discussion about Personas generated a few questions:
Could you please advise what tools and techniques we should use to ensure that we have identified all the personas?
There is no magic trick to this one, I’m afraid; you need to conduct a stakeholder survey and ask lots of questions – who are our customers, users, clients, victims, other interested parties. A question that I’ve found useful is to ask every participant in the workshops “who else should we be talking to about this thing”.

Should a regulator/ govt law maker be a persona?
In my experience external groups that provide constraints rather then functional aspects generally don’t warrant detailed personas (but they might be referenced in stories such as “as the compliance officer I want …so that we don’t lose our banking license”) if they will actually interact with the product then they deserve a persona and profile.

The Epic Model also generated a number of questions:
A few people questioned the “one person” aspect of the definition of an Elementary Business Process.
The description I use is that an EBP is something done “in one place, at one time, by one person” and it should achieve a specific result for the business. It will normally be part of a chain of events that result in the delivery of value for the consumers of our product or service. There are some EBPs that are not “one person”, often these are “small team” activities where a small group of people are working together to do a job. Some EBPs have no human interaction – these are fully automated activities. Examples of these two types of activity are – replacing a large window in a building (“replace a window” will be an EBP for a glazing company but some windows are too big for one person to replace alone) and the overnight charge for staying in a hotel (undertaken at say 2am every morning by a computerized process).

Someone questioned the amount of detail in the epic model – should this not be left for the detailed user stories?
Here I resort to the consultant’s standard answer “it depends” – if you are able to identify the primary objects and start to understand their relationships at the Epic stage then do so, but be very careful not to get bogged down in the detail. In my experience adding the objects at the Epic level helps clarify the overall understanding of the scope of the work to be done without increasing the amount of work and time needed at this stage in the overall process.

There were a few questions specifically about user stories and acceptance criteria.
Do user stories supplement or replace functional specification documents?
In my experience user stories are a far better tool than functional specification documents, especially when used in this Progressive Elaboration way. Most of the requirements are likely to change over the duration of a project so trying to lock down the detail early on simply results in more wasted effort as we make the changes later in the project.

User stories are deliberately kept light early on, and the acceptance criteria are only added to the story on a just-in-time basis, typically this is done a few days ahead of when the story will be worked on by the technical team. What goes into the acceptance criteria depends on what the team need – it could include screen wireframes or mockups, low-fi data models and other structural aspects. I feel you should always include the test design criteria, ideally in the Behavior Driven Development format.

Someone asked What is the difference between Use Cases and User Stories?
A Use Case is a combination of scenarios about how an actor will interact with the system, normally written in a structured “Actor does … System does …” format. A single use case normally includes multiple paths through the system (primary flow and the alternatives/exceptions) and is often built with the intent of defining the full interaction early in the project. This is far too detailed to be used early in the project.

Each row on the Epic Model could be a placeholder for a Use Case, and that model can be used to provide a list of Use Cases if you are using that approach.

A User Story is much smaller than a Use Case and the two are quite different.  A Use Case covers multiple interaction scenarios, whereas a User Story could cover a single scenario for using the resultant system.

Alistair Cockburn says that “a user story is to a use case as a gazelle is to a gazebo

When should the Acceptance Criteria be added to the User Story?

As late as possible, but not too late 🙂  The concept here is the “last RESPONSIBLE moment“.  There are some things which we need to consider early on in the project – typically these are the Architecturally Significant Non-functional Requirements that are very expensive to refactor if they are not built in to the product from the beginning.  The trick is to consider just enough and just in time without undertaking a lot of wasted effort.

Again – thank you to everyone who participated.  The audio recording and copies of the slides can be downloaded from the Software Education website.

Posted by Shane Hastie

 
Leave a comment

Posted by on May 30, 2011 in Agile, Webinar

 

Tags: , , , , , , ,

Learning from Baboons

I’m sitting on a plane flying from Wellington to Melbourne, and find myself urged to write this blog post.

I’ve just watched a National Geographic video called “Stress. – Portrait of a Killer” that I found really fascinating. It looks at research that has been conducted over the last 30+ years into where stress comes from and how it impacts us.

Stress related illnesses have a huge impact on our society today, and together make up the majority of the illnesses that kill people before their time.

I knew that, and was at least somewhat aware of a lot of the material presented in the documentary.

What leapt out at me were some of the conclusions, and a piece of research done by Robert Sapolsky.

Over 30 years he has followed a number of troops of baboons in the Serengeti and found typical baboon behavior (hierarchy driven, top-down, might-is-right, to win you need to beat everyone around you, etc.) which is equated to the behavior seen in many hierarchical human organizations; the documentary talks about the Whitehall Study that show the same stress responses in 20000+ civil servants in the UK as found in the baboon studies in the Serengeti.

Sapolsky recounts the story of one particular troop of baboons that suffered a tragedy about 20 years ago – illness wiped out all Alpha males in the troop along with many others. The animals that survived were the ones who were more cooperative than combative, perhaps it was because the “nice” baboons were the ones who would be cared for by others when they fell ill.

The fascinating thing is that this troop of baboons went on to become a grouping of “nice guys” where collaboration, grooming & feeding each other and supportive behavior is now the norm. When new males join the troop they bring with them their old hierarchical habits and it takes about six months for them to learn that “that’s not the way we do things here” and to fall in with the cooperative behavior.

Part of Sapolsky’s research involves taking blood samples from the baboons and he has found a significantly lower level of stress hormones in the cooperative baboons than in any other troop he has studied over the last 30 years.

He goes on to suggest that human beings could learn from these baboons and create a better society, in which collaboration, autonomy and cooperation are the norm, and as a result lower our stress levels and improve both the quality and duration of our lives.

Being a staunch Agalist I found this speaks to my fundamental beliefs about why Agile practices work – an Agile team is a collaborative environment, where people support each other and all “win” together, rather than competing for power and privilege. Certainly it has been my experience that effective Agile teams are nicer places to work, with generally less stress and greater levels of happiness.

What do you think – am I just an idealist, or can we turn our organizations into happier, more productive places?

 
2 Comments

Posted by on May 8, 2011 in Agile, Culture

 

Tags: , , , , , , ,