Hem » agila metoder » agile and scrum » jeff campbell » scrum » Three Common Mistakes in an Agile Transformation
Time and time again I see teams making the same mistakes when attempting their agile transformation. Since one of the most important ideas in agile methods is visibility, I wanted to make some of these visible in the hopes of creating change. This is by no means an exhaustive list, just three I see a lot.
1) Non-experienced "coaches"
Let me be absolutely clear on what I mean here, I think that creating coaches, scrum master and the like from within you organisation is not only advisable, but vital for long term success. However, there are some pitfalls with this in the early days.
Transforming to an agile way of working is much more about a change in mindset then it is about process and tools, it's written right there in the agile manifesto, but changing your way of thinking is extremely hard. So, you have someone trying to coach the organisation on change, when they have not yet had the opportunity to make the change themselves. And it's a lot harder to sell a product you don't use yourself. This often results in the teams and organisations not only having some strange ideas about what agile is, but losing confidence in it because the person who is driving it is still learning themselves. This person needs the time to really "get it" before they can help others do so.
I am not criticizing the people who are just starting out, they will get there eventually and we need their passion to succeed, but I was there myself once and I know the difference experience makes.
All that being said, be cautious if you are hiring this kind of support from outside, there are a lot of people who sell themselves as agile coaches, but have not really "gotten it" yet.
2) Transforming to agile with a traditional approach
Agile emphasises an iterative approach to things, but time and time again people try to become agile overnight.
It is impossible to fix all your problems at once, treat your "agile development" the same way we treat "development in agile". Focus on the most important things first, your biggest bottlenecks, and make some progress on them before you focus on other things. Use your retrospectives as a tool for this, take away one or two solid action points from your retrospective instead of a list of 15-20 things to improve. Fixing everything is impossible, fixing one thing is easy! Well, easier...
A lot of teams create backlogs for their improvement the same way we create backlogs for a products improvement, this can be a useful tool!
3) Hand-offs to testers
The idea with a cross functional team is that we have everyone we need in the team to take something from a request for a feature or product to the market in order to start making money from it, or "from concept to cash" as it's called. But early teams often take things "from concept to testing".
The reasons they do this are obvious, testing takes a long time, and if quality is poor the results of that testing are often unpredictable. But, by doing that we are trying to hide the problem outside the iteration instead of fixing it. The result is what is called "iteration avalanche".
The team "finishes" the iteration and hands off to testing.
Testing finds bugs, but the team has started the next iteration.
So, those bugs have to wait until the next iteration.
At which point the team "fixes" the issues and hands to testing again.
Then the whole cycle begins again.
Nothing is ever done in this approach, the team has to take back stories over and over again, and an adversarial relationship develops between testing and development. If testing is part of the iteration we are forced to solve these issues instead of hide them.
Testing is too slow? We need automation to make it happen faster.
Testing finds too many issues? We need to increase quality early to prevent this, test driven development being the most popular approach to this, but not the only one.
As I said earlier, these are only some common mistakes I see, but if I can help even one team avoid one of these things, I will consider this post a success!