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:

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: 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.  (

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

If organisations insist on retaining performance reviews there is some advice available from Alan Atlas in the Agile Journal.

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:

Lean & Agile thought leader Mary Poppendeick has also written at length on the topic in this article 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.

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



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.


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 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?


Posted by on May 8, 2011 in Agile, Culture


Tags: , , , , , , ,

Why so little good Agile?

Today I gave a talk at the  Government Test Professionals Forum conference in Wellington.

I presented a case study about how the Farm Systems Division of Livestock Improvement Corporation have adopted Agile methods.
I told the story of Team Awesome (they choose the name themselves), how their practices have changed and the measurable benefits that have resulted from their new way of working:

  • Massive reduction in residual defects
  • Increased team satisfaction
  • Shorter time to market
  • Increased customer satisfaction

I told the story of how the team collaborates, how all the roles work together. How testing is fully integrated into the flow of work and how the whole team (developers, analysts, product manager, testers) coordinate their activities starting with expressing the detailed requirements for user stories as test design specifications using the Behavoural Driven Development model. They have adopted Agile well, and gained the benefits that all the books talk about.

After the talk I was chatting with one of the attendees and she said that my story was unusual – her experience as a tester on “agile” projects has been uniformly negative – testers as victims of development teams who use “going agile” as a excuse for hacking and not bothering with requirements.

This saddened me; surely we know how to apply these practices properly, don’t management in our organizations understand that agile is about applying the practices in a disciplined way, you can’t just pick the pieces that seem easy? Agile works when the combination of practices are applied together – for example: user stories are a good technique for identifying features and prioritizing the work to be done, but they must then be supplemented by some technique to define the detailed requirements on a just in time basis, just ahead of when the story will be developed. You can’t just adopt user stories and ignore the detailed requirements and testing – that is truly Tragile, but seems to be oh-so-common.

Building software is hard work; building good software takes a concerted team effort, irrespective of the methodology being used. We know this, and have known this for the last 40 years.

Please stop calling these half-hearted implementations Agile – it’s not, it’s just a continuation of the bad practices that many organizations have followed over the years, just with a different brand.

1 Comment

Posted by on May 3, 2011 in Agile, Testing


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

Advanced Agile?

I was at an Agile Academy Meetup last night and the topic was “The Agile Journey and beyond”. It was great to hear about the agile concepts and practices being applied, in real world scenarios – small and large organisations. But it was equally great to hear about how these organisations were using agile in the way I think it is meant to be used – not as a rigid framework, but as a guideline for an approach. All three of the speakers made a comment like this (please note that I am paraphrasing here) ….”We tried XYZ and it worked for a while, then it stopped working so well, so we changed it”. I had to giggle when Adrian said they sit down at their standups….because they use a webcam and it is not viable to standup. Another speakers said “we tried the 3 questions at the standup, but it did not work, so now we “walk the wall””. I was really excited to see this extension of agile practices and acknowledgement that the practices that we see, read about and talk about so widely are totally malleable and able to be modified to suit each and every organisation. But there is a gotcha! All of the modifications came as a result of trying the “proper” way of implementing the practices, and then careful and comprehensive understanding of what about the practice did not work, and why, and then careful and incremental changes to the practice to make it work better. It was described best by one of the speakers as “an agile implementation of agile”.
So I was wondering:
1. is taking the agile practices and modifying them a good indication of agile maturity?

2. which practices are the riskiest to change and why?

3. how long should you try the “proper” way before considering change?

4. is modifying the practices a sign of agile maturity of advanced agile usage?

What are your thoughts?

published by Sharon Robson


Posted by on February 23, 2011 in Agile, Culture



Daily Standups are for intra-team communications

I’ve been teaching a lot of Agile courses lately, and a very common point of discussion is the way the Daily Standup meeting is often abused and misused. Words like “micromanagement” are often used.

The primary purpose of the daily standup is for the team members to communicate with each other about their progress against the tasks they are working on. A coincidental benefit is that a leader or manager gets to hear about what’s going on. The meeting is for the team NOT for the manager!

The most common structure for the daily standup is the three questions from Scrum:
What have you done since the last meeting?
What will you do before the next meeting?
What is in your way?

Each member of the team should answer the questions in less than one minute. The answer should be against the tasks they have committed to, and the response should be short, sharp and to the point. The whole meeting should take no more than 15 minutes.

For example, lets say you are busy with a two-day task –

If everything’s on track, your response would be something like:
I started on task xyz,
I will continue with task xyz,
Nothing’s in my way

These responses let your team mates know that you are on track and they don’t need to be concerned about your progress.

On the other hand, if you’ve been pulled off the task to work on a production problem then your responses might be:
I started on task xyz and had to leave it to spend half of the day on the production problem, (your team mates now know that they have to adjust their work on any tasks which are dependent on you finishing yours)
I will need to continue working on the production problem – that will take me out all day (now your team mates know that they need to adapt to not just a half-day delay, but a day-and-a-half)
The production problem is in my way (this is something the manager/leader might be able to do something about)

Another common state is when you discover that the task is more complex than you thought:
I started on task xyz,
I will continue with task xyz,
I’m struggling with the task, I thought it would take me 2 days, but now that I’ve started it looks like i will need 4 days. (You might BRIEFLY describe what the issue is)

If someone else on the team could help you with the problem then they may say so, but you mustn’t solve the problem in the standup – talk about it together afterwards.

The key to an effective standup is keeping it short and focused, your team mates don’t want to hear the details of your day(“I spent three hours talking to Mary, wrote 500 lines of C code and spent 30 minutes in the bathroom”) they do need to hear about things that will impact their work and if you need their help.

A note for managers – the daily standup is NOT the dreaded “status meeting” – please don’t turn it into one. They waste the whole team’s time, and don’t add any value to the team’s work. If you really need a status meeting, hold it every month or so, and trust your team to work in the organization’s, the project’s and the team’s best interest in the meantime.

What do you think – how do you make sure the daily standup achieves it’s positive purpose?

Here’s an example of how NOT to run a daily standup:

Posted by Shane Hastie


Posted by on December 1, 2010 in Agile


Tags: ,