RSS

Please don’t equate Tragile with Agile

Lajos Moczar recently posted an article in CIO magazine titled “Why agile isn’t working” in which he states that “I’ve concluded that agile has not only failed like other fad methodologies before it but, in fact, is making things worse in IT”.  He goes on to identify ways in which he says agile is not only failing but making things worse for the IT industry as a whole.

I’ve read the article carefully and tried hard keep a balanced perspective as I perused it.  I can’t keep calm – this article is dangerous unadulterated drivel! The author misinterprets the agile manifesto and takes some of the agile practices completely out of context, using unfounded statements to justify his conclusions.

This post is my response, addressing the points he makes and tackling the myths he propagates.

Advertisements
 
Leave a comment

Posted by on June 14, 2013 in Uncategorized

 

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:

STANZ Wellington and Melbourne

Wow –how cool was it to catch up with everyone at STANZ in Wellington. The Amora hotel was great sized for the conference and it was fabulous to see so many familiar faces. It was also great to have such a line up of presenters. Then after Wellington we went to Melbourne. It’s fascinating how two different towns with almost the same conference presenters can create such a different event. I love the fact that STANZ is in two places to give this effect. Obviously the audience is the key factor! Different audiences, different questions, different learnings, different approaches – so many differences, but still some fabulous outcomes.
I know that Jonathan Kohl was awesome in his opening session and Karen Johnston had us all riveted with her view on the virtual teams (more on these later). It seems the whole conference was about challenging the way you think and what you currently do. We also had a really strong focus on providing value for the business. This was backed up by Mark in Melbourne talking about testing from the point of view of a CEO. I loved the fact that all of the presenters had a different point of view for how and where we can look at our work, our work place, our approaches and our mindsets. I really liked the way the audience interacted and challenged, and it was really funny to sit in Gorenka’s session on Testing Games and see how many people became hooked on SET as a way of stretching their minds (once again – more on that later). Jan Japp’s discussions on TMMi and thinking and challenging your approaches was also great! I enjoyed the checklists and new approaches that I took away from the conference, and I spoke with so many people who mentioned that they had things that they wanted to do as soon as they got back to work – now that is what I call a valuable conference!

 
Leave a comment

Posted by on September 23, 2011 in STANZ 2011

 

STANZ speaker profile: Karen Johnson

If you’re interested in testing you’ll want to hear what testing experts have to say on the subject. At this year’s STANZ (Software Testing Australia New Zealand conference) there will be presentations from four international testing experts. Each week we’ll tell you a little bit more about each of them. This week we’re introducing Karen Johnson.

About Karen:

Karen is a software test consultant. She is based in Chicago but travels to speak at conferences around the world and work with organisations planning test strategy.

She has worked as a software tester or test manager since 1992 after catching the testing bug (pardon the pun) while writing technical guides.

Karen’s testing history is very varied. She has worked with banking, manufacturing and ecommerce software as well as content management systems, medical software and business intelligence initiatives.

As well as teaching and testing Karen is a contributing author to the book Beautiful Testing released by O’Reilly publishers. She has published numerous articles and blog posts about her experiences with software testing.

Working with Remote and Distributed Teams

The biggest key to a successful project is good communication. Unless you always work on your own there will come a time when you have to explain something to someone. Still, that’s pretty easy isn’t it? You just talk.

Unfortunately it isn’t that simple, maybe the person you need to talk to is in a different office, in another country, and is awake when you’re asleep and asleep when you’re awake. Maybe they speak with a different accent to you, or have a different understanding of what certain words mean, or a different cultural perspective. Maybe you’ve never met them, nor will you ever meet them, so you don’t know whether to be very formal or more chatty. Maybe you’ve never worked with them ever before.

Good communication is about more than you communicating out, it’s about considering how your communication will be received by the person on the other side. This keynote talk will focus on good communication skills, how to get them and how to use them when you can’t see the person you’re communicating with.

The Strategy Part of a Test Strategy

Strategic planning is an indispensable skill for test leads and testers alike. A test strategy is the first thing a test manager or lead needs to develop, before you can even write a test plan.

You might not always have all of the resources you would like on a project, so this workshop will show you how to use what you have to get what you need. It will look at ways to get input from other team members. It will help you to get buy-in from all of the concerned parties and overcome political obstacles. Finally it will help you to continuously assess and monitor you testing efforts as your project progresses. After attending this workshop you’ll be able to think and plan strategically on any project that comes your way.

Here is a brief video clip of Karen at the Software Test Professionals Conference earlier this year:

 
Leave a comment

Posted by on August 15, 2011 in Uncategorized

 

STANZ speaker profile: Karen Johnson

If you’re interested in testing you’ll want to hear what testing experts have to say on the subject. At this year’s STANZ (Software Testing Australia New Zealand conference) there will be presentations from four international testing experts. Each week we’ll tell you a little bit more about each of them. This week we’re introducing Karen Johnson.

About Karen:

Karen is a software test consultant. She is based in Chicago but travels to speak at conferences around the world and work with organisations planning test strategy.

She has worked as a software tester or test manager since 1992 after catching the testing bug (pardon the pun) while writing technical guides.

Karen’s testing history is very varied. She has worked with banking, manufacturing and ecommerce software as well as content management systems, medical software and business intelligence initiatives.

As well as teaching and testing Karen is a contributing author to the book Beautiful Testing released by O’Reilly publishers. She has published numerous articles and blog posts about her experiences with software testing. Read the rest of this entry »

 
Leave a comment

Posted by on August 11, 2011 in STANZ 2011, Testing

 

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: ,

Performance agreements when you are on projects

I was happily running a class when someone asked about how performance agreements work if you are on projects.

“Really well” I replied, “you just need a new one for each project you are on.”

My answer didn’t seem to go down well though. After all, who wants yet another piece of administration to do?

Then we discussed the problem that both permanent staff and contractors often have with projects. Contractors get no real feedback on how they are going until their contract ends, while permanent staff have to have a series of discussions based on a document that bears little relationship to what they are doing on their projects.

Read the rest of this entry »

 
1 Comment

Posted by on August 3, 2011 in Business Analysis, Testing

 

Tags: ,