The agile software delivery model functions through self-organizing, cross-functional teams. While agile promotes continuous improvement, many organizations have encountered catastrophic failures while transitioning to this newer style of software development.
Some people assume that once we adopt agile, we will be able to move faster. Agile does not solve our problems for us, but it does cause problems to surface sooner than they would have otherwise.
This article discusses three reasons why agile transitions fail, what typically goes wrong, and how to head off disaster before it occurs.
Impediment #1: Missing or largely incomplete Impediment Backlog
Ironically, the first impediment toward a successful agile implementation is the missing or largely incomplete Impediment Backlog. There’s a school of thought that says an inventory of impediments should not be encouraged. If we developed software in an ideal world where the rate of impediment removal is equal to the rate at which impediments occur, I would agree. But most organizations do not function in such ideal scenarios, and hence the Impediment Backlog needs to exist.
Not without metrics, though. Average age of impediments, or MTTR (mean time to resolve) impediments, when trended over time, sheds light into the overall health and behavioral issues, if any, within the organization.
Without a comprehensive view into our organizational challenges, we can only fantasize about stepping on the gas. Velocity rises organically if all feature teams keep an updated Impediment Backlog and remove impediments as they occur. Impediments may need to be injected into the Product Backlog and addressed alongside other high-priority stories.
Similar to tests and defects, we should not spend time prioritizing impediments so that the lower-priority ones get dragged from one sprint to the next. If it’s an impediment, it needs to be resolved. Consider this: If you use an Impediment Backlog and it is allowed to overflow with issues, instead of moving forward as hoped, you may come to a screeching halt.
Experienced folks with great foresight can predict impediments even before they happen. Preventive approaches translate directly into more savings than old-school, reactive approaches.
Impediment #2: Your agile tech lead manager isn't very technical
There are three aspects to how a tech lead manager (TLM) could potentially become an impediment in the agile world.
The TLM has insufficient grasp of technology
Age-old traditions—such as managers having the entire engineering team reporting to them—have gone the way of the dinosaur. When agile shops were first being established, an important consideration was to keep TLMs from having full visibility into any one agile team. The reason was that this sets up tech leads for failure, causing them to regress into being more people managers than technical leaders.
Now it's more important for the TLM to have full visibility into the technical domain. For TLMs to be the champion of the product, process, tools, and the technology, they should have a deep understanding of the technical direction.
Legacy management structure can't cope with agile
Large and mid-sized enterprises had to (or, in some cases, chose to) roll over into the brave new world of agile with a legacy fat layer of middle management that they didn’t know how to fit into agile practices. This is commonly referred to as the “old wine in new bottles” syndrome, which plagued most of the organizations when they were transitioning to agile.
Senior-level traditional managers were appointed as TLMs due to the many years they had spent in traditional management. This led to the classic quantity-versus-quality debate.
Senior-level traditional managers are not used to:
- Dealing with the delivery line on a daily basis
- The ever-changing technology landscape
- An engineer’s jargon, which is usually refreshingly “unpackaged” and brutally honest
These folks inadvertently misrepresent stellar engineers and architects and end up making ineffective decisions regarding customers, process, product, and technology. Worse still, they could be influential within the organization, and hence may do some serious damage when faced with the bitter truth around competence.
A weak TLM is the hiring manager
If you think making ineffective decisions about customers, process, product, and technology could be detrimental, think about what happens when you make bad calls regarding the hiring of team members. Ideally, you should be surrounded by people smarter than yourself, so that every working day is like going to school. Also, if you have the right people in the right positions, you can scale well. They will take care of customers, people, process, product, and technology for you.
But when an ineffective TLM is the hiring manager, the result can be fatal. Such TLMs hire people who are like themselves—maybe easy to sit down and have a beer with, but lacking sufficient skills to become part of a lean agile team. Too often, a weak TLM ends up cultivating and championing weaklings.
Impediment #3: Too much consensus creates inefficient decision flow
If “agreement by consensus” is the model that you have chosen as your decision-making framework, you could experience a slowdown in decision flow. Not all links in a chain are robust and responsive. Even though agile rests on collaboration, the “agreement by consensus” model has it’s share of flaws, depending on the who, the what, and the when.
Who: The "birds of a feather flock together" idea can ruin innovation
In fact, that idea may be the biggest weakness of the consensus model. Too much collaboration can set your organization back by years, especially if you want to promote a culture of disruption versus status quo. Sure, decisions can be made by majority, but sometimes one person—often the latest hire—brings fresh blood to the system. Outlier opinions, even if jarring, can potentially be catalysts to long-overdue change. These outliers or change agents could be the “movers and shakers” and may not “flock together.”
What: It depends on what needs to be decided
If you are deciding on architecture and design, you may move the needle faster if nontechnical folks are not in the decision-making process. A nontechnical person may choose to be like a fly on the wall, seeking education, and that’s great and should be encouraged. But too much direct immature participation and intervention could be disruptive to more productive trains of thought that go into making long-term decisions.
On the other hand, you could have so-called technical folks who can neither make solid decisions nor take full responsibility in the event of failures. If these folks are part of a team whose velocity (average number of story points completed per sprint) is significantly behind other teams, they may try to get competitive in creative ways. In fact, comparing one team's velocity against another's is a bad pattern. Defining story points is different from one team to another, subject to human perceptions. Trying to compare one team against another can lead to overpadding of story points simply when one team is desperate to raise its velocity. Measuring velocity is a good thing, just that “raising” it without considering the true underlying details can lead to severe blind spots.
When: Done must mean done. Really.
Delivery deadlines, acceptance criteria of user stories, and general consensus over things like "definition of done" could be (mis)timed, depending on a given manager's agenda or an organizational goal. Things need time if they are going to get completed with quality. Decision-makers may set artificial deadlines according to pressures that are not always clear to the full team. It is human nature to gravitate toward rewards, so how incentives are set becomes critical.
In determining a "true-north" definition of done, I recommend the lightweight RAPID decision-making framework (even though the common perception is that the team should decide collaboratively—for diverse teams, collaborative decision making does not scale).
Here's how that works. Note that my order of the letters in "RAPID" is not the same as the word's spelling:
The most competent person, most often the product owner, is the one who D(ecides), and the second-most competent person (or pair) has to A(gree). Anyone (technical or nontechnical) could R(ecommend) and optionally provide I(nputs). Depending on skills, the relevant people would need to P(erform) the actions arising out of the decision. This way, decisions flow at the speed of the most competent person, and that’s a good thing when there’s a large disparity in skill sets.
Agile transition: Keep the focus on success
Agile software development and delivery is generally structured around the principles set forth in the Agile Manifesto, but the specific practices frequently used by teams transitioning to agile can run counter to the spirit of the Manifesto. Honest, competent leadership, along with open and healthy communication, are the ingredients that make up a successful agile transition.
The thing that you want to tell your team and your customers is “S CCESS is incomplete without U”. While it’s great to have a set of default agile practices you can refer to, what's best is a customized delivery framework whereby you end up with a happy team and repeat customers.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
