Agile done right
We start the conversation about Agile, how it is a powerful tool in our toolbox, and how things can go way off track.
Hi, this is Peter with the next edition of the Professional Manager newsletter. I publish this newsletter to illustrate what decent, seasoned, professional engineering management could look like.
In this edition, we will start the conversation about Agile and how, when applied right, it is a powerful tool in our toolbox.
A brief history of Agile
Agile had a few glamorous decades! And that good run is due to compelling reasons. The Agile mindset will tremendously benefit your business and engineering teams. The Agile Manifesto has some convincing principles like
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for a shorter timescale. Note from Peter: any two-pizza team should be able to show progress over a work week.
Working software is the primary measure of progress.
Continuous attention to technical excellence and good design enhances agility.
Simplicity - the art of maximizing the amount of work not done - is essential.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
While Agile transformed how we create products and ship software, it has also been contorted and weaponized over its illustrious tenure. An entire cottage industry is riddled with folks who call themselves “Agile experts.” Some “experts” have never built software yet talk a big agile game.
How things go wrong
When engaging in Agile, a process will likely emerge for your organization. At this point, things could go wrong for many teams. Here are a few antipatterns to watch out for.
Top-down process
Executives, too far removed from the dynamics of software development, sometimes demand a rigid process for the entire engineering organization. In some egregious situations, they may require the same process across many disciplines. This process usually works for absolutely no one. The teams hate the process because they did not come up with it. Somebody forced the process upon them. Some groups may not even understand how to follow the process. The overzealous executive hopes to achieve a culture of accountability, but an uber-process will not help create the desired culture.
External “Agile expert” bringing the “Agile best practices”
I have seen organizations so lost that they thought bringing in an external “Agile expert” was the only answer to their woes. An “Agile expert” usually comes in with great-sounding ideas and a regretfully rigid process that is generally “by the book Scrum.” Ironically, most of these “Agile experts” forget the Agile Principles and want to force a process upon the team. This approach usually never works out. When the “Agile expert” leaves their assignment, the team still has not improved in delivering business value.
Team choosing anarchy
Sometimes engineering teams decide to give up on all processes. Engineering leaders worth their salt should only allow this to happen for a period of time. While no-process anarchy may feel freeing, this approach usually never works out in the long run. I am a strong advocate for a light-touch, data-driven process. A light process shall not be confused with anarchy though! More on this in the next edition.
Sloppy engineering leadership hiding behind the “Agile way”
Some engineering managers think their job is to enforce an Agile process on the team. An engineering manager approaches software engineering in an Agile Dictator fashion when they have no interest in deeply digging in to understand what’s best for the team and the business. The Agile Dictator usually does not have any technical curiosity. Without the motivation and empathy to help the team and a lack of technical interest, this Agile Dictator only has one tool in their toolbox. You guessed it! It is to weaponize rigid Agile ways. This approach is a quick way to alienate the team. The team will usually cynically attend ceremonies and sarcastically play along to appease their Agile Dictator. The team will cast our Agile Dictator on an Island of Agile Misery.
Choosing the right process
I am a big advocate for the Agile Principles. I love to work with teams to help them establish a light process. This process needs to be done by the team, for the team. It needs to be rooted in the above principles. Your customer needs to be satisfied. Your team must accept the realities of changing requirements. You have to deliver working software rapidly - in today’s world, the unit of measurement for rapid is days, not weeks! Progress, however small, is measured in working software.
In an upcoming edition, we will explore the process that has worked best for the teams I have been part of. We will also discuss the drawbacks of Scrum.
Summary
This was the intro to my thoughts on Agile. As long as you root yourself in Agile Principles and do not take one of the fraught paths I described above, Agile is a powerful approach to software development.
I sincerely thank you for reading my newsletter. I’m always open to your feedback. I would also love for you to share The Professional Manager with your friend!