10 brilliant ways to fail by ignoring the Agile principles
10 brilliant ways to fail by ignoring the Agile principles
Re-release - original from August 2023
The Agile Manifesto has existed for 23 years already. It’s a two-pager. Many people know it. How can it be that so many organizations fail with Agile? Here are 10 ways.
1. Don’t focus on value, focus on how much they can do instead
Teams are praised when they reach capacity growth goals. And punished when they fail to reach their goals. They are oblivious to whether the team actually delivered value and whether the users are happy with what they got.
2. Don’t allow any changes to your plans
Another sure sign teams are having issues is when they stick to the planning created at the start of their work, ignoring developments that impact the value of what you are planning to deliver.
You tell users and customers that have important feedback to come back next week when the current work is done according to plan.
Teams that act this way are probably doing mini-waterfall. However, 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 large items into smaller pieces
Teams work on a large item for months, only to conclude that the whole solution direction was wrong from the start. As a result, the team will have to throw away many weeks of work.
The better way forward is to take smaller steps and work on smaller items. This allows the team and their users to assess what was built and determine how to proceed. It avoids working on the wrong things for a long time.
4. Avoid teams working on the product to work together
Many Agile teams are only responsible for pieces of the product. But a product is more than the pieces. It includes product support, policies, marketing, supporting systems and other facets that are often outside of the scope of an Agile team.
The customer is interested in the complete experience, not in the functionality of the core product only. As an example, when my smartwatch provides excellent data during my run but lacks the means to track my fitness progress over time, I will not be happy.
5. Micro-manage your development team’s performance
The burn-down charts are the manager’s friend. They are checking on a daily basis if the team burned enough story points and if they are still following the ideal line. If not, they instruct the team to work on getting this issue fixed.
Managers are not going to get the best out of people if they micro-manage them. Individuals find motivation when you give them the trust that they can finish their job.
6. Build a Feature Factory
You may be able to deliver more and more items. You are not spending your energy on the question if the software does what it should do.
Instead, regularly ask yourself the question: does the product do what it is supposed to do? Does it even WORK? No? Well, it’s back to square 1 then.
7. Make working overtime a standard practice
The team will bend over backwards to finish what they had planned. They will work overtime to achieve this. Every time. Breaking the team.
Teams should find a pace that they will be able to continue ‘forever’. This rules out regularly working overtime and working at the weekends. There’s scientific proof that you will be more productive working at a sustainable pace. And added to that: the work will be of higher quality.
8. Deliver, worry about the quality later
The team skips a review or a test. Timely delivery is more important than quality. But everything falls apart if teams ignore technical excellence and good design. You will bite your tail eventually.
9. Discourage the teams to self-organize
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.
In contrast, let the teams self-organize. Trust the team. They own the planning, they feel ownership. They are motivated to make the most of the Sprint. You’ll see!
10. Skip reflection moments
Teams don’t see the need to do a retrospective. They believe it’s better to spend those three hours on that additional item on the backlog. They’re also not going to spend some time during the next iteration putting into improvement initiatives. They use 100% of the capacity on new items.
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.
