I started this out as a single post, but it’s become far too unwieldy for a single day. Thus, I’m breaking this up into two segments — one focusing on missing the point, the other on finer mistakes that sink potentially “good” teams moving into Agile processes. It’s still one of my longest posts here, but I hope you find it worth the read.
“Agile” and “Scrum” have seemed to take a beating over the past few months, with a lot of criticisms and complaints online and off with regard to how it’s not the “silver bullet” everyone expects it to be and how it actually fosters a lot of dysfunction and bad behaviors in developers, Product Managers, and management. The problem with a lot of these criticisms, at least the ones that I’ve read, is that they take one or two bad experiences with agile methodologies and apply them as a blanket criticism of all agile methodologies — and almost universally one can look to the details of these complaints and see that it’s far more likely that the bad experiences are caused not by a bad philosophy or a bad methodology, but by bad implementation of those principles and processes.
I’ve worked with several companies to effective transform from backwater processes to effective, efficient, and successful product delivery teams through the use of agile philosophies and a variety of agile methodologies. The problem is, nearly every team has some level of dysfunction already (and likely always will), and if you go in blind to those dysfunctions, or with a belief that all you need to do is “be Agile”, then you’re destined to fail — but I would posit that it doesn’t matter what process you choose, if you ignore your dysfunctions they will always come back an bite you in the end.
To that end, I wanted to take some time today to discuss some dysfunctions that I’ve seen in teams claiming to transform into Agile/Scrum teams, all of which are not only contrary to the principles on which the methodology is founded, but each of which can sink any attempt to be more agile into an unending quagmire of crap.
Missing the Point — When “Agile” isn’t “agile”…
I touched on this topic in a prior article (You’re Not “Agile” Unless You’re “agile”…) but it’s a point well worth repeating in this context — agility is not something you do, it’s something you are. You can adopt all the trappings of any Agile methodology, you can mix and match them until you’re blue in the fact, and you can talk the talk of repeating the principles of the Agile Manifesto, but until or unless your company actually accepts what it really means to be “agile” at a very core level, you’re setting yourself up to fail…and likely to fail miserably.
Being “agile” is not something you do as a company; it’s a quality that you either have or don’t; it’s something that you either embrace or combat.
Here are some warning signs that your “Agile” world isn’t really “agile”:
- If your management still wants requirements defined as fully as possible up front, you’re not agile.
- If your developers are being handed specs from which they are not permitted to deviate, you’re not agile.
- If you’re working from 9/12/18 month roadmaps that define deliverables at the feature level, you’re not agile.
- If your backlogs and priorities are shifting so fast that nobody knows what the next most important thing to do actually is, you’re not agile.
- If your developers just want to go off and do what they want, then come back and deliver whatever it is they thought was best, you’re not agile.
- If you have daily standups, but no sprint plans, not retrospectives, and no demos to actual stakeholders, you’re not agile.
Everyone who wants to be “agile” should go back and re-read the Agile Manifesto until they can recite it from memory, and they should be willing and able to push back and help educate others in the organization about what being “agile” really means — ultimately, it’s a way of approaching the business, the market, and the product as whole, not “just” a development ideology (as discussed here – What “Agile” Means to the Business). Then you should measure everything that you do as a company against these principles — do you really value “Individuals and Interactions over Processes and Tools”; do you really value “Customer Collaboration over Contract Negotiation”? If not, challenge it — and work to improve it. Until or unless a company actually adopts these principles in practice and in culture, it’s exceptionally difficult to be successful with an “Agile” approach.
Not Embracing the Fundamentals of the Methodology
Here’s where we separate out the “Agile” philosophy from the “Agile” methodologies.
- Agile is not Scrum; Scrum may or may not be agile as you have implemented it.
- Agile is not Kanban; Kanban may or may not be agile as you have implemented it.
- Agile is not Extreme Programming; Extreme Programming may or may not be agile as you have implemented it.
Do you see a pattern there? Adopting a methodology such as Scrum or Kanban or Extreme Programming does not magically or mystically make you an agile company. There are (highly dysfunction) ways to implement any of those (or other Agile methods) that achieve none of the benefits of being agile, and which may in fact be less productive than a traditional waterfall-based methodology (Stage-Gate, for example).
Agile is not Scrum. Agile is not Kanban. Agile is not Extreme. And none of these is Agile if poorly understood or implemented.
I’m going to stick to Scrum here for this article, because it’s what I put in the title, but I believe that this general rule applies to all forms of Agile methodologies — if you ignore the fundamental principles underlying the methodology, you’re setting yourself up for failure.
The typical mistakes that I’ve seen in companies who poorly implement Scrum, for example, include some or all of the following:
No Training
Sure, the concepts behind Scrum and Agile in general are pretty simple — you make a list, you choose what you’re going to do from that list, and you do what you think you can, then review, wash, rinse, repeat. The problem is that it’s all deceptively simple. Teams that have made no investment in actually training themselves and the company in effective ways to implement a methodology like Scrum often struggle with moving from the theory to the practice. So, you have a backlog — but how do you prioritize that backlog? How much work should you do in estimating each item on that backlog? When are backlog items “ready” for teams to take on? What happens if something winds up being bigger (or smaller) than expected? What do I do when the CEO wants something out-of-band?
All of those questions are things that you’ll have to answer on a daily basis in a true Scrum environment, and all of them can throw the team into complete chaos if they’re not managed properly. And I practically guarantee you that a company that invests no money in training or preparing their teams to tackle a Scrum transition are capable of answering all of those questions and resolving them in a way that moves the team forward and not backward.
Transitioning a team to Agile without some form of formal training or someone with deep experience in what works and what doesn’t is like putting your toddler on a bike with no training wheels — they might succeed, but it’s unlikely.
Now, this doesn’t mean that you have to spend $50,000 on a long series of classes for everyone to break away from work to attend. Nobody has time for that. What it means is that you need to set aside some time, some money, and some effort to ensure that your team has the tools and knowledge that it needs to succeed from the outset. This could mean bringing on a Product Manager with extensive Scrum experience; it could mean hiring a consultant to come in and advise you on how to be most effective; it could mean simply ensuring that your dev manager has attended some formal Scrum training. But you have to do something. Just like most other cultural changes, if you don’t have the context for what it is you’re trying to achieve, you’ll wind up pretending and just making things worse in the long run. “Fake it ’til you make it,” is a recipe for disaster in an agile transition.
No Team Engagement
One of the single most important and fundamental aspects of Scrum (that I’d wager half of the companies adopting the methodology don’t “get”) is that it is a team-oriented methodology. Scrum teams are expected to have the authority to do what they need to do to meet their commitments, the autonomy to achieve those commitments in the way they deem most appropriate, and the insulation to focus entirely on what they have committed to during each iteration. Most of the time when I see a failed Scrum implementation, this is one of the main reasons for the failure — the company and the culture have not accepted the autonomy of the team, hasn’t delegated the team the necessary authority to do their work, and/or doesn’t insulate the team while they’re working from the other goings-on in the company.
Further, effective Scrum work requires that the entire team be engaged from planning through to delivery — nobody should be allowed to sit by the wayside and let things steamroll through the team. Everyone should have the ability to “push the big red button” and stop everything if they feel things aren’t going the way they should. Scrum is an extension of lean production methods — and the most important concept to the success of the team is that…well, they are a team. Teams need to engage on estimation exercises; teams need to engage on backlog prioritization efforts; teams need to engage on what they can or can’t do in a given iteration; teams need to review their work with the Product Owners and Stakeholders. It’s the team that succeeds or fails to achieve their commitment, and the individual needs to support the efforts of that team. If a member of the team isn’t engaged or supportive, they become separated from the goals, and that’s a cancer within the organization that’s only going to grow.
The entire point of Scrum is to provide the team with the authority, autonomy, and insulation to make their commitments and to achieve them on a consistent basis.
The entire point of Scrum as a team-oriented process is that the team is expected to internalize the goals that they are committing to. They are expected to push each other and to hold themselves accountable for the work they’re doing (or not doing) to meet the goals. There’s a strong level of peer pressure (in a good way) that is supposed to make the team better — nobody wants to cause their team to miss their commitment. Nobody wants to be “that guy” that constantly over- or under-estimates the amount of work something’s going to take. The dynamics of a strong, successful Scrum team are those that serve to reinforce good behavior, punish bad behavior, and strive to achieve — all without the external oversight of a traditional management structure. The team matters, the team establishes their norms, and the team reinforces and polices those norms. Self-direction is more than just a buzzword; it’s essential to a successful Scrum transition, and absolutely required to scale it beyond a few teams.
Dictating Commitments
The other 99% fatal flaw in poor Scrum implementations is that the “business” dictates to the “developers” what gets done, and/or how to do it, and/or what timelines “have to” be met. These behaviors are entirely antithetical to the concept of Scrum development and often to Agile principles themselves.
First, when commitments are dictated to the team — when they’re told “you have to do X in Y time with Z resources,” you’ve emasculated the team’s authority. They’re no longer buying in to the work they’re taking on, and once that happens, the necessary internalization of the goals falls to the wayside, and they’re just taking orders again — no better than what happens in the old Waterfall world of “check-the-box” requirements.
Second, by removing their input and commitment, you’re setting them up to fail. The purpose of high-level estimation and sprint planning in Scrum is to act as a check against the common practice of the business underestimating the complexity of technology problems. It’s intended to give the developers not only a voice in the discussion of priority and difficulty, but to give them the ultimate veto power to say, “No, we can’t do that in two weeks. Let’s do something else and come back when you’ve broken that down more.” This level of empowerment makes sure that the team not only feels heard, but that they feel understood by those above and around them who are “telling them what to do.” If all you’re doing is handing them a list of things to do and expecting that they’ll get them all done when you’ve told them to…well, you’ve missed the point entirely.
Scrum is a cooperative, collaborative process that allows developers to veto unreasonable commitments being foisted upon them by people who may not understand the complexities involved.
No, this is not to say that there aren’t clear business priorities, or that the developers only get to work on the things that they want to work on, and the business can be damned if they want something shiny and pretty. The power, authority, and responsibility of ensuring that the right things are being built in the right way lies on the Product Owner, who is the representative of the customer to the developers, and the representative of the developers to the customer. It’s up to the Product Owner to create stories in a way that the development team sees the benefit to the customer, and it’s up to the Product Owner to take the developers’ feedback out to the business and make those stories better. If you’re doing it right, there is little tension in these planning meetings, and they can take less than 15 minutes from beginning to end. The corollary there is that if these meetings are more than a half hour, you’re probably doing something wrong. Terribly, terribly wrong if they’re taking more than an hour.
That’s it for part 1 — in the next installment, I’ll talk about the more nuanced things that companies struggle with when transitioning to an Agile/Scrum process from whatever they’ve been doing before, seemingly simple things that have a significant impact on the teams’ successes…and which thus have direct impact on the company’s success.
