12 brilliant ways to fail with Agile

One of my first articles on Agile, dated May 2018 - It still hits the spot for me

How to ignore the principles behind the Agile Manifesto

I bet that you know the Agile Manifesto by heart. If someone wakes you up at 3 AM, you are still going to say:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

And perhaps you can also cite the 12 principles: http://agilemanifesto.org/principles.html.

The Agile Manifesto has existed for 17 years already. It’s a two-pager. Many people know it. How can it be that so many organizations fail with Agile? Here are 12 ways.

1. Don’t focus on value, focus on velocity instead

Your primary way to measure the success of your teams is the velocity. Or rather: the growth of the velocity. You set a target to see a 10% growth in the velocity on a quarterly basis. Teams are being praised when they reach the velocity growth goals. And they are punished when they fail to reach their goals.

You ignore completely whether the teams delivered valuable software. You are not measuring whether the users are happy with what they got.

This is directly related to probably the most important principle behind the Agile Manifesto:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Your success is not measured by the number of items that you are able to deliver. No, your success depends on the value that you are delivering to your customer/user.

2. Don’t allow any changes to your Sprint backlog

Another sure sign you are having issues is when you stick to the plan created at the start of the Sprint, ignoring developments that impact the value of what you are planning to deliver.

You tell users and customers who come with important feedback that we are not going to break the Sprint. They can come back next week.

So what about this principle behind the Agile Manifesto:

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

If you consider a Sprint to be immutable, you’re probably doing mini-waterfall. It’s very healthy to regularly assess if you’re still betting on the right horse. At least daily.

3. Don’t break down your items into smaller pieces, so you are sure to deliver later

You are ignoring the notion that earlier delivery will result in shorter feedback loops. You work on a large item for months, only to conclude that the whole direction was wrong from the start. The software you show your customer is not doing what the customer wants.

This is heavily related to the following principle behind the Agile Manifesto:

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Nowadays, we are talking days to a couple of weeks, not weeks to a couple of months. Here, you can see that the Agile Manifesto was written at a different time. But the idea behind this principle only grew stronger.

4. Avoid Business and Software Development from working together

You have a Product Owner, but the Product Owner and the Development Team aren’t in the same team. As a result, the team is building something that might not be what the Product Owner wants.

This violates the following principle behind the Agile Manifesto:

Business people and developers must work together daily throughout the project.

Only through daily cooperation between business people and developers do you have the best chance of delivering valuable software.

5. Micro-manage your development team’s performance

The burn-down charts are your friend. You are checking on a daily basis if the team has burned enough story points, if they are still following the ideal line. If not, instruct the team to work on getting this issue fixed.

This is touching upon the following principle behind the Agile Manifesto:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

You are not going to get the best out of people if you micro-manage them on results. Individuals find motivation when you give them the trust that they can finish their job.

6. Avoid face-to-face communication

Use e-mail as your main means of communication. People won’t read their e-mails; they have other things to do and can’t constantly watch their inbox.

While the principle behind the Agile Manifesto says:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Face-to-face conversation is so powerful. It is good for understanding, creativity and collaboration. It trumps indirect communication, via e-mail, via Slack, anytime.

7. Build a Feature Factory

You may be able to deliver more and more items. You are not spending this amount of energy on the question if the software does what it should do.

Did you forget about this principle behind the Agile Manifesto?

Working software is the primary measure of progress.

Regularly ask yourself the question: Does the software do what it is supposed to do? Does it even WORK? No? Well, it’s back to square 1 then.

8. Make working overtime to make the Sprint a standard practice

You committed yourself to finishing 6 items in the Sprint. So the team will bend over backwards to ‘make the Sprint’. They will work overtime if they have to. You will be heroes forever. Well, at least for a couple of hours.

The following principle behind the Agile Manifesto slipped your mind:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

You should find a pace that you will be able to continue ‘forever’. These rules out working overtime, working at weekends. There’s scientific proof that you will be more productive this way. And added to that: the work you deliver will be of higher quality.

9. Deliver stuff, worry about the quality later

You fool yourself that there are shortcuts to deliver the items. What is the harm of skipping a code review (once or more often), or not running a regression test for once?

You just fell into the trap of ignoring this principle behind the Agile Manifesto:

Continuous attention to technical excellence and good design enhances agility.

Everything falls apart if you ignore technical excellence and good design. You will bite your tail eventually.

10. Create complex solutions

Let the architect build a complex solution and ask the development team to build it according to the specifications. The chances of failure are tremendous.

This is related to this principle behind the Agile Manifesto:

Simplicity — the art of maximizing the amount of work not done — is essential.

Make it an art to work on the items that you really need. Skip the non-essentials. Work on the most valuable item first. And when you finish that, work on the item that is now deemed most valuable.

11. Discourage the teams from self-organizing

Don’t allow the team to self-determine how they can best do their work. Assign individuals to certain tasks and track if they complete the tasks accordingly.

You obviously didn’t grasp this principle behind the Agile Manifesto:

The best architectures, requirements, and designs emerge from self-organizing teams.

Let the teams self-organize. Trust the team. They made the planning, they feel ownership. They are motivated to make the most of the Sprint. You’ll see!

12. Skip inspect and adapt

You don’t see the need to do a retrospective. It’s better to spend those three hours on that additional item on the backlog. You‘re also not going to spend some time during the next iteration to put into improvement initiatives. We use 100% of the capacity on new items.

This shows you missed the following principle behind the Agile Manifesto:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

This touches the core of “Agile”: inspect and adapt. It is essential to regularly reflect on how you are doing as a team and where you can improve. To stand still is to regress.

So…

I barely touched the surface. There are many other ways to fail with Agile. It’s easy. Just ignore the principles behind the Agile Manifesto.

Original article May 2018