Transforming your organization towards agile is like moving your organization to a new country with new culture and language with clear differences from how you work today. No amount of training will help you in dealing with different situations. I am compiling some common challenges & scenarios organization sees when they are new to agile. We all have to work proactively to sense these indicators or situations.
1. Lack of Discipline
Although it may seem counter intuitive, Agile is an extremely disciplined approach to working. Agile teams work in rhythm to attain sustainable pace. This is mantra of success for agile teams. It is like doing Yoga. Read my earlier article Agile is Like Doing Yoga. Agile does not equal sloppiness. Hence most people will have a difficult time adjusting to this.
Tracking stories to closure, sticking to ‘definition-of-done’ come what may, coming to stand-up on-time and able to finish in-time, estimation tracking, getting ready for decent demo etc– these are all things where every team will slip up the first few iterations. Without discipline Agile will not work.
2. Business is not as usual
The business stakeholders involved must understand and inculcate agile as it is very different for them. Often overlooked or avoided because the delivery team may also be ramping up on the methodology and hence feel uncomfortable teaching it to others. If this group is not brought into the fold there will be major disconnects in terminology, approach to situations, handling slippages, commitments etc.
The business also needs to clearly understand expectations of the team; that they are available to the team and easily reachable whenever team needs them. If not teams will end up with unfinished work, unmatched expectations and other issues that are often comes due to long breaks between business reviews.
3. Iterative death
People mis-interpret the term ‘iterative’ to mean that there is unlimited ability to revisit scope. In fact, agile success hinges on incremental completion of scope throughout the project. Teams that do not effectively define their “acceptance criteria” for each story will never get real closure on work in progress. This leads to endless cycles of revisions that are really scope changes but which are not labelled so because of the mis-perception, causing
delays, overruns, and a demoralized team.
4. Blame game
Agile can be a scapegoat for initiatives gone wrong, because Agile is very good at surfacing issues very early in a project. Inculcating agile thinking and scrum framework cannot be done overnight. An experience coach can come very handy here who can do root cause analysis to mitigate this challenge.
5. Playing without a coach
In a typical project the pressures of understanding the business, learning and addressing technology, business, and team personality issues; will very quickly overwhelm even the most prepared person. Adding upon this a major change in delivery methodology (even if only in certain areas) will lead one to revert to known approaches. The volume of information is simply too huge. The new techniques and thinking will be dropped and mis-interpreted. A major mitigation here is training and more importantly, effective support from someone with actual experience in the field.
6. Working style
Developers used to working in a solo mode will find difficult when working in small teams to complete stories. This can manifest itself in stalled work, as communication reverts to inefficient mechanisms such as email (instead of sitting together, or picking up the phone).
7. Testing undervalued
Often the need to do continuous QA on an application is not appreciated, and the initial releases will see not enough emphasis on testing. An effective test plan must be created, and things like data creation, environment setup, etc., must all be addressed very early in the project(some teams use sprint zero to do initial kick-off which includes such activities).
If these steps are not taken, then it becomes essentially impossible to execute and hence the stories cannot be completed and delivered. This undermines the entire premise of incremental delivery causing most of the benefits of agile to be lost.
8. Lack of automation testing
Automated testing is fundamental to quality, short delivery cycles, and hence the agile model. Yet, there are many barriers: taking on a legacy application with no existing test suites; lack of tools for many aspects of an application; lack of team knowledge on how to do this. People will want to revert to more comfortable manual testing approaches.
As the product gets bigger, then teams unable to finish all the manual testing within the sprint and quality issues starts creeping in. Hence investing on test automation early in the project makes lot of business sense.
9. Multi-skilled team
Teams working in a much focused environment within a larger project may find themselves struggling within a short iteration to get involved in a much broader range of skills: estimation, design, development, testing, and finally demonstrating functionality to the business. This has tremendous upside in terms of learning new skills, etc. but can be very stressful if NOT managed (facilitated) well.
10. Agile tools over mindset
Teams get hung up with tools while moving to agile. Yeah you definitely need to track few metrics like velocity, burn-down, estimates. But you don’t need fancy tools while you are starting. Even excel would work fine. Teams should focus on Agility and Scrum framework first and then on tools.
To avoid such pitfalls real time constant monitoring and analysis to find root cause will go a long way. Check my article on “How to Apply 5 WHYs Technique” to find a root cause.
An excellent article, could I quote from it (with citation) in my Blog?
Cheers,
Matt.
Sure. Provided you give link back to my blog.
In addition for 8th item : more than a lack of knowledge in testing automation, the issue is the lack of culture and experience. Developers should have practiced test-first development to appreciate it and become efficient while doing it. With inexperienced people, automated testing has a quite important cost. Automated testing needs that people involve themselves into it and practice in their free time. Not so easy.
Here the success also depends on item 1 : discipline. The first time production code is written without being associated with testing test, the first time a failing test is commented instead of fixed is the first step of testing policy decline.
Eventually, automated testing on a legacy app is indeed a challenge but is always doable incrementally. There are books about this (Micheal Feathers’s Working Effectively With Legacy Code is the best known but one can also have a look at the Mikado Method http://mikadomethod.wordpress.com/)
I agree with you Romain. Very valid point. Agile teams should have discipline running in their blood. How many times we see team commenting failing tests before they commit. Hence keeping this on Definition of Done, will remind people every time. Many times I don’t really get worried about experience of team, but what really counts is their attitude. It is organization onus too to invest time and energy to mentor their people.
Thanks,
Avie
I especially like point #3 – Iterative death. Iterations (or sprints) are not an excuse to do something over and over. (If you don’t get it right the first time, do it again!) Each iteration needs to deliver something that is complete. You can enhance, augment, re-factor, etc. but you can’t fix it later. Do it right the first time.
You are right Vin D’Amico. Getting clients on-board with clear understanding of iterations is very important. Many time even teams have to resist their temptation to achieve perfection. Because there is a cost to achieve to perfection in very sprint. Team need to understand Agility is about achieving good enough. You can read my earlier post on this. http://www.agilebuddha.com/agile/agility-barely-good-enough/
Thanks for coming here.
Avie
From the 10 things you mention my experience is that discipline (#1) and insufficient focus on learning (#2 and #5) are the things which organizations find difficult to implement. Yet these are crucial to secure your improvement investment, and to get lasting improvements (not only agile but any improvement).
My advice: As a manager (or coach) pay extra attention to these things, and help teams whenever possible to learn and improve. Discuss it, make it visible and celebrate successes.
Thanks Ben for coming over here. I have seen all these points impacting transformation with a different level of degree from one org to another org. One thing I have seen consistent is playing without a coach. If you have very good coach, then all these points can be addressed by working with team, management and other stakeholders.
IMHO most of those listed are related to not having defined engineering good practices. Scrum does not prescribe any of this – as it is just a framework for the team. Each team should define and follow set of practices – for example – what is the minimum accepted test code coverage, how often code checked in into source control, is there a daily build, when is peer review required etc. All those are responsibilities of the dev team, the rest is on scrum master.
Excellent article.
Have a question on multi skilled.
When you say multi skilled team, I assume that means the competencies needed to execute a project is available.. Is it important for the resource managers to assess the competency before building a scrum team.. Otherwise we may end up in lot of churns when the required skill sets are not available…
Great article, Avie! I will pass it on to some of my colleagues and be sure to include a link back to your blog.
I especially like the overall theme of preparation as essential to successful agile adoption. This is something I “preach” on a regular basis as part of my focus introducing agile practices to consulting work in the field with paying customers. The kind of preparation and training you talk about is critical for the performing organization (my company) as well as the client. Trying to persuade a client that they may not be ready to use Scrum, for example, while they insist on going ahead is a complicated conversation!
Thanks Evans. Scrum, many people start treating like another practice or just a methodology. This is where thinking fails. It is more of organisation design framework and hence it touches every part of the organisation. Education plays a very big role in making them aware what is Agile is all about, and what changes in the organisation we are staring at by taking this route. Many times people are not ready to change status-quo due to fear of failure.
Some good reasons in here – must agree. I’d personally add one more – failure to get prepared for a huge failure in advance. With only 39% agile adoptions being a success (cannot remember where I’ve read this stat!) – it’s vital to prepare for the – clearly – most likely scenario, which is failure to adopt.
This was well mentioned in this post: http://kanbantool.com/blog/common-agile-adoption-mistakes – makes a good follow-up read on your.
Thank you for a comprehensive list.