Agile Transformation:10 Potholes to Avoid When You Drive an Agile Car

by Avienaash Shiralige

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.

agile-pitfalls-to-avoid

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.


About Avienaash Shiralige


Avienaash Shiralige is an Agile Coach, Trainer, Business Optimisation and Agile Transformation Consultant @ AgileBuddha. He has been on senior leadership positions in various companies and comes with very rich 17+ years of experience in product and service companies. He has consulted companies in India, US, Europe and Australia on Agile/Scrum/Lean/Kanban and successfully set-up various distributed agile teams across timezones. He can be reached at avienaash@gmail.com.

{ 12 comments… read them below or add one }

Matt July 3, 2012 at 7:58 pm

An excellent article, could I quote from it (with citation) in my Blog?
Cheers,
Matt.
Matt recently posted..The release sprint

Reply

Avienaash Shiralige July 3, 2012 at 9:02 pm

Sure. Provided you give link back to my blog.

Reply

Romain July 4, 2012 at 12:32 pm

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/)

Reply

Avienaash Shiralige July 6, 2012 at 8:57 am

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

Reply

Vin D'Amico July 4, 2012 at 8:34 pm

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.
Vin D’Amico recently posted..Software Teams Have to Manage Scarcity to Be Successful

Reply

Avienaash Shiralige July 6, 2012 at 8:48 am

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

Reply

Ben Linders July 10, 2012 at 12:04 pm

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.
Ben Linders recently posted..Re: CMMI V1.3 Released: High Maturity Clarified

Reply

Avienaash Shiralige July 13, 2012 at 10:57 pm

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.

Reply

galina July 10, 2012 at 11:30 pm

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.

Reply

sri February 21, 2013 at 11:11 am

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…

Reply

Evans Travis April 18, 2013 at 11:07 pm

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!

Reply

Avienaash Shiralige May 2, 2013 at 3:13 pm

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.

Reply

Leave a Comment

{ 3 trackbacks }

Previous post:

Next post: