How to fail while implementing agile

Agile software development, the best process the industry has come up with so far, how could it fail? Easy.

Any of the following will do, even if you hired a professional trainer…

 

Dismiss the idea of training as “it’s obvious, isn’t it?!”.

About 80% of all attempts at agile result is “scrumfall”, i.e. people going through the motions w/o understand where the value is supposed to come from. So, no, it’s not.

 

Allow the trainer to avoid locking into any specific flavour.

Scrum or Kanban? Leaving the choice to the uniformed or proceeding with training not tailored to fit the organization is not a training, it’s an information session. People walk away w/o an understanding of the role they are supposed to play or how to play it or even why bother.

 

Let people taking the training to wonder in and out as they please.

Exercise in the class – focusing on one thing at a time improves the team productivity. If someone was allowed to skip it, they are still thinking in terms of their silo and how personally more productive they are if they don’t have to deliver in small chunks.

 

Fail to grasp product owners and project managers/scrum masters roles and their differences.

In a traditional development  model your manager and your team lead are playing both sides – figuring out what to do and how to do it.

To benefit from agile you need to let product owners concentrate on figuring out the “what” and “why” and let the team to come up with the “how”. Empower the scrum masters to facilitate and unblock.

 

Don’t provide additional training to product owners and project managers.

Focus on what and why is not natural for many people ending up in the product owner role. It requires a different “hat”, if you will.

Project managers need to learn when to step back and when to put their foot down – in agile these two usually happen for entirely different reasons.

 

Don’t bother with the definition of done, don’t account for testing in the estimations.

Even if your teams do everything right, without the definition of done you don’t know when or what you can realistically ship. Just trying to come up with the definition will highlight potential problems with your delivery.

 

Say that testers are uninformed, unavailable, elsewhere and don’t involve them in the planing and estimations.

Related to the definition of done. No testing? Chances are you’ve built the wrong thing, even if it works as intended.

 

Don’t write stories, keep writing tasks.

Tasks don’t tell the team what motivates you, people have to reverse-engineer the value you expect to derive from things you tell them to do. Describe the value instead, they will find the best way to provide it.

Coming up with the pipeline of prioritized “value adds” is not an easy job, don’t make it harder by trying to figure out the solutions as well.

 

Help the developers by solving the problems for them, instead of focusing on defining them.

Traditional approach to problem solving has produced generations of developers whos only motivation is not to screw up. Let the people come up with the solution and they will “own” it, they’ll take pride in it, they will think late at night reviewing their decisions.

 

Swoop on the team now and then and ask if they are done yet, make an off-hand remark that it shouldn’t take this long.

It’s their estimates, not yours. If it takes longer than expected, maybe the problem wasn’t well understood, or maybe the task was scoped too big. Unknowns will pop, feed the observation back into the next retrospective and the next planing session.

 

When another pressing thing comes up tell them to get on that, regardless of any previous priorities and commitments.

Some times you have to scrape the sprint, but it should be red flag – something is wrong with your planing. Making a habit of it will destroy the morale, as prioritized backlog is part of the trust relationship between the “chickens” and the “pigs”.

 

Talk about refactoring as if it were a separate, optional activity, done at another time.

This is often a developer’s folly. People used to others making the decisions will try to present the choice of “cheap and fast” or “slow, but good” to the product owner, not realizing that continuous delivery and improvement is on them.

This why having a good backlog is important – any refactoring decision has to be done by the developers, with the knowledge of the roadmap for the best results.

 

Keep pretending that you can estimate in hours, pad the estimates as your experience tells you.

By now the question “How long do you think it will take you?” should have been exposed as an apparent invitation for a lie. The only relevant question should have been that of relative complexity, everything else is counterproductive.

 

Skip on the retrospectives… you don’t have any power to change anything anyways.

What is the forum for the constructive feedback in your team and organization? How often are you prepared to receive it and react on it? Telling someone “if I’m doing something wrong just tell me” is not a forum, it’s an invitation for reprisal and hurt feelings.

 

Keep the cost, time and scope fixed.

Project management triangle has been known for a long time. Agile assumes that the quality is given. Pick two and let the other float, that’s the only way.

 

Advertisements
How to fail while implementing agile

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s