This is the third in a series of posts discussing the various reasons why Agile transitions tend to run into roadblocks or fail completely. In the first post, we looked at some fundamental considerations that often wind up causing problems for teams wanting to make the change to Agile practices. In the second, we discussed the importance of retrospectives and evangelism in the success of such transitions. Here, in this third post, we’re going to examine some things that many teams lack which may significantly affect their ability to implement, embrace, and succeed with Agile processes: Knowledge, Commitment, and Progress.
Lack of Knowledge
Although this has been touched on in the other parts of this series, the single biggest blocking issue that most teams run into when wanting to migrate to more Agile methods of work is that they simply lack the knowledge of how to do so. This might be a lack of fundamental knowledge about Agile in general, or it may be lack of knowledge about the what’s and why’s of a specific methodology, or it might be a lack of knowledge about how to effect cultural change throughout an organization. All of these elements of knowledge are absolutely necessary for a successful transition to Agile practices. It’s not enough to just say, “Hey, let’s be Agile!” or “Hey, let’s start scrumming!” There’s a lot of research and planning that needs to go into consideration before any organization makes that kind of commitment to procedural, organizational, and cultural change.
Too many teams just decide that Agile sounds like the right thing to do, go to Google or Wikipedia, and think that’s sufficient to understand the entire process from beginning to end. And, unfortunately, Agile methodologies can be deceptively simple – what’s hard about doing 2-week sprints and showing what you’ve done? But the honest truth is that the success or the failure of any team’s efforts do not rely on the high-level, conceptual ideas that underlie these methodologies — rather, the team’s success or failure will rely on the details and minutia of the process. What do you do when something takes too long? How do you know when you’ve taken enough work into a sprint? Who should manage the Kanban “parking lot”? All of the “edge cases” as we’d call these in software development really become impactful, as teams without the knowledge of “why” can’t adjust to situations outside the broad strokes of online resources.
In order to effect change, you must seek out knowledge about your end state, so that you understand not only the “what” to do when you’re there, but the “why” you’re doing it.
Lack of Commitment
Far too many people think that Agile is “easy” and that it “just works”, which is far from the truth. In fact, both during and after a transition, maintaining agility and constantly pushing for improvements in the process and the product is hard work. You simply have to be committed — as an individual, as a team, and as an organization — to make a successful transition to Agile practices, no matter what form they may take. You have to internalize the principles of agile software development, you have to live the principles in your day-to-day interactions, and you need to work constantly to ensure that you’re improving every single step of the way. Far too many organizations decide that they “don’t need” the ceremonies involved in their chosen methodology — “Let’s just do stand-ups every other day,” or “We don’t really need retrospectives after every sprint,” are common phrases that indicate a lack of commitment to the process (unless, of course, you’ve tried these things for months on end, and the team has rational, data-driven reasons for wanting to change — then, by all means, give it a try…and track the impact).
Commitment means sticking to your guns when crunch time hits. It means reasserting the “rules” of managing change that you’ve established. It means pushing back on those who want to go back to the “old ways” just this once. It means that sometimes people need to go elsewhere, if they don’t want to continue in a new culture. It means that you push through the rough patches and the hard times, with an eye toward the future state that you want to achieve. It means being an evangelist to anyone who will listen.
To be successful in making a change to agile practices — or for any cultural change — you need to commit to that change.
Lack of Progress
The absolute worst thing that we can do when we want to convince others to make a cultural change is to fail to demonstrate the value of that change in a timely fashion. This not only hinders the overall adoption of proven processes of continuous improvement, but it also waters down your own ability to influence — and thus, to lead. Far too many Product Managers want to pick a big, hairy, nasty project in order to “prove” how much better Agile works. Unfortunately, if the organization as a whole hasn’t embraced agility as a core value, choosing such a large undertaking is almost guaranteed to result in failure. Such projects inevitably have dependencies on other teams, which will always torpedo any efforts that you might have to show the value of agile approaches if those teams aren’t also Agile (which they rarely are). You’ll spend far more time talking about your backlog and how pretty it is and how clearly prioritized it is, and negotiating with other teams to make your dependencies their priority than you will actually executing against your goals. And, eventually, you’ll wind up blocked almost entirely — which is the worst place to be when trying to show how much “better” an Agile world really is.
Instead, look for opportunities to engage on smaller projects, isolated projects, some manager’s “pet” project. By picking something small and isolated, you ensure that (1) you and the team remain in control of your own destiny, and success or failure is entirely in your hands; (2) that the overall impact of the project is likely to be minimal, so you won’t have people looking over your shoulder all the time; and (3) if you do it right, you’ll have constant, data-driven updates every two weeks to provide. Starting small and working your way up lets people acclimatize to the “better” way of doing things. Establishing a cadence of reporting and providing data-driven updates will invariably put other teams in an awkward situation — one that is best solved by moving to more agile practices. And, if you pick the best-case project, you wind up giving a manager the “pet” project that they’ve wanted with a minimum of effort on their part and (presumably) some demonstrable progress shown with every single iterative step.
When making transitions in culture and practice, start small and work up from there — showing small amounts of progress over time demonstrates to others the value of making change.
