In my previous post I started this series of antipatterns based on David Tanzer’s book “Quick Glance At: Agile Anti-Patterns”. Now I’ll go with 3 antipatterns more:
- Antipattern #4: Team Backlog
- Antipattern #5: Architecture Breakdown
- Antipattern #6: Burnout by 1000 Baby Steps
Antipattern #4: Team Backlog
When there are improvements that your team wants to implement, but they just never have time.
Maybe the author could have used a different title for this antipattern. Something like “Too busy to improve”.
It is, unfortunately, still very common. Many companies incentivize being busy over being effective. It’s cultural, but although it can be counterintuitive; making pauses regularly to reflect on how we work will eventually increase your productivity.
Reconsider your incentives so that people can find those spaces to reflect. Methodologies like Scrum organize work around cycles (sprints) and sprint retrospectives are the meetings defined to focus on how to improve the way the team is working.
Degrading quality to increase your team performance is bad business because you are acquiring technical debt
A backlog for technical debt is another sign of this antipattern. This is a piece of advice for managers: in general, degrading quality to increase your team performance is bad business because you are acquiring technical debt. You can take a small debt (delivering a quick-and-dirty solution) but then you will have to pay the interest and find the moment to develop the right solution, remove the bad one, and test everything again. As in real life, the more you wait to pay your debt, the more interest you’ll have to pay.
Image taken from Hakan Forss’s blog.
By the way, I encourage you to read the blog mentioned within the above picture, https://hakanforss.wordpress.com/201. There are many interesting articles about modern management methods like Lean, Kanban, Toyota Kata, etc.
Antipattern #5: Architecture Breakdown
When architecture and software design slowly gets worse over time.
Many years ago, a good friend of mine said that “bits don’t get rusted” as a metaphor to explain that software is something that will give the same result every time you execute it. Unfortunately, this metaphor has a very short run.
Every system is affected by its context to a greater or lesser extent. For example, your competitors develop a new feature but you can’t do anything similar because the libraries or the tools you are using are too old now. Maybe you are missing a business opportunity because you didn’t invest in keeping your systems up to date.
Take care of the design of your systems constantly or they will eventually become unmanageable
The internal design of your systems may also degrade if we don’t take care of them. It’s not uncommon to find a sedimentation architecture, i.e. an architecture made of layers deposited on top of older layers ad nauseam, where hardly anyone dares to touch inside that monster. I also like the more classical term “big ball of mud”, but the concept is almost the same. You must take care of the design of your systems constantly or they will eventually become unmanageable. It’s not a bad idea to ask for help from time to time like we humans do when going to the doctors for a health check.
You may be tempted to think that this is an antipattern that only concerns those roles involved with software development. The way you are organized is also important. Have you ever heard about Conway’s law? This “law” states that every organization designs systems which mirror its own communication structure. This means that if you divide your projects into specialized teams (based on your departmental organization) the result will be a system representing that structure.
Big corporate websites are a very good example. All the information shown is not focused on the needs of the visitor but instead, it reflects the departmental structure of the company.
If you want to avoid this effect, regularly reconsider if the design of your current organization is aligned with the architecture you want to produce, and also remember this principle of the Agile manifesto:
The best architectures, requirements, and designs emerge from self-organizing teams.
Again, this also applies to teams that don’t work on software development. Self-organization is a cultural practice that will enable teams to find solutions for complex problems, e.g. innovation, marketing… even sales. Every knowledge work, in general, may benefit from letting people adapt to how they organize themselves to their own context.
Antipattern #6: Burnout by 1000 Baby Steps
When Agile tools are used to micro-manage people and teams.
Agile project management is based on transparent processes. In a wrong organizational culture, this can be particularly painful because it may lead to micromanagement as soon as the expectations are not met. Managing expectations is much easier when you understand your production capacity.
It’s very important to have a good understanding of your own process and metrics to see the effect of the changes you make.
Image taken from my blog in Spanish.
But this antipattern is a serious warning for those tempted to use tools for something different than providing knowledge for the team, transforming them into evil supervisors instead. This is why I promote using burn-up charts or CFDs (cumulative flow diagrams) instead of burn-down charts —I can explain this difference in further detail in another post.
Burn-down charts create a sort of commitment over the work that we have estimated for a sprint, instead of burn-up charts that just show the amount of work that we are finishing sprint after sprint, allowing us to manage the expectation of workload that could be done if we had a predictable pace. Burn-up charts help incentivize a sustainable pace.
Also remember that Agile is about being flexible, not fast. At least not at the beginning of your Agile adoption. You will become faster eventually because you’ll learn how to stop doing unnecessary things.
Simplicity–the art of maximizing the amount of work not done–is essential.
This is one of my preferred Agile principles because it reminds us to be more critical on what we think it’s mandatory or not, and radically changes the way we understand planning as we stay open to introducing changes as we get real feedback from our users. Aligned with this, the concept of the last responsible moment (aka YAGNI) is the most useful mental model you need to develop as an Agile practitioner: don’t start something unless it has proven absolutely necessary.
As with many other things in Agile, it may sound counterintuitive, but it gives you the ability to stay focused on features that can be developed and delivered, and incorporate the feedback in order to make better planning decisions. That way you avoid working on things that later on will prove to be unnecessary, saving that cost in the long run and helping protect that sustainable pace we mentioned earlier.
This technique helps you manage everyone’s expectations on what has to be done, as we move from a fixed, predictive plan into an adaptive, iterative and incremental plan, and also helps to transform the reporting meetings into forums where everyone helps to unblock possible impediments to deliver that plan and to adapt priorities based on the feedback received.
I will not lie, this is not easy, but it’s much healthier once everyone starts seeing the benefits.
In the next article, I’ll finish with the 3 last antipatterns from David Tanzer’s book. I’d like to read your comments below.
