After an organization has successfully gone through its initial Agile transformation, what does it take to 
“keep the ship on course” and prevent backsliding into old patterns and behaviors? That’s what I’ve been thinking about a lot lately. First of all, it’s somewhat of a fallacy to claim and celebrate success when it comes to an Agile transformation. While it’s very natural to want to acknowledge achievement of a transformation goal (e.g. “all our teams are now Agile!”), it’s really more the beginning of a journey than an end point. Some may argue that the more difficult work now lies ahead. (Just ask someone from an organization who’s removed from the original transformation by several years of “being Agile”.)
Why is that? During a transformation, a lot of attention is paid to what’s going on with Agile, the teams, metrics, etc. Ideally – if we approach this holistically – clear ownership exists and often a cross-functional steering committee keeps very close tabs on what is happening. These are stressful, but also exciting times and Agile and what it can bring to the business are “sexy” and new.
After the initial excitement wanes and success has been claimed, people’s attention starts to wander. Agile is now the “norm”, the status quo and eventually other, new and exciting things pop up and make us forget about all the effort we’ve put into the transformation. The steering committee may disband and the question “who owns this” now becomes more difficult to answer. In the worst case scenario, all off a sudden, there isn’t anybody left who feels responsible.
So back to the original question: what does it take to keep moving forward strong from here? I’ll use scientific phenomenon of entropy as an analogy (and I’m hopefully not offending any of the scientists among the readers with my poor-man’s understanding): the natural state of a system is … chaos! You’ll see this in your house if you’ve neglected to clean up for a week or two: stuff ends up all over the place, it gets dirty and messy. (Don’t tell me this doesn’t happen in your place!) My understanding of entropy is that if you want to counteract the natural chaotic state of a system, you need to apply energy to it. In your house, you need to make the effort and spend the time to clean up, put things into their rightful place and the reward for the applied energy is … order!
Energy is what we applied to our organizational system during the transformation by having people at various levels focus on creating order from the chaos and guiding individuals and groups towards a new, orderly end state. Once we relax and focus elsewhere, the system’s inertia sets in and old habits reappear as people slide back into pre-Agile patterns or simply just into chaos. Other anti-patterns include “Agile-on-the-surface behaviors”, where people seemingly follow the Agile “process”, but are simply just going through the motions without understanding the roots and spirit of the practices and ceremonies and therefore don’t receive many of the real benefits (maybe a new term Agile Lemmings is in order, but I digress).
So, to make the long-term journey of Agility successful, we need to deliberately and constantly continue to apply energy to maintain order and prevent chaos. Here are several things one should consider:
- Have clear ownership: Figure out who really “owns” and is passionate about Agile in your organization. This could be one person, but having a group of people – potentially a cross-functional one – may be even more beneficial. (To stay with the “ship thing”, you need a captain.) Ideally, this person or group should also
have the influence to make things happen and affect change. Maybe the Agile steering committee could transform itself into the Agile leadership committee and persist.
- Know how to chart your course: Figure out where do you want to go, at least directionally. Have goals and in-between milestones. Determine which metrics (yes metrics!) you will use to see what course corrections are necessary and where attention is needed. Without any goals and metrics to guide you, how would you know where you’re going and if you’re doing well or not?
- Nurture the community: Agile is not practiced by individuals, but by groups of people. There are obviously the teams themselves, but think of Scrum Masters, “QA people”, .NET developers, automation engineers, business units, etc. as communities of practice (CoP), i.e. like-minded people with similar goals and challenges. CoPs can be functional or cross-functional, local or virtual (spread out), within the same business unit or across. These are all mutually-complimentary CoPs. Create opportunities and spaces for people to connect, share and learn, in larger groups or regular small groups, in person and through electronic means. (Many of you will have heard of the Spotify model, which is more explicit about acknowledging these different groupings.) Invest in skilled facilitation.
- Have a backlog: No surprises there, a backlog helps make things explicit, so why not have one (an Enterprise Agile backlog) during the transformation and beyond? It could contain additional teams to spin up, improvements you’re planning on making, etc. Hell, you could even use it to plan monthly or quarterly “sprints” for your Agile journey or at least feed a Kanban board. It goes without saying that it could be a planning tool and an information radiator for those involved in “running Agile”.
- Bake Agile roles into your organization: You won’t want Agile roles such as Scrum Master to be just something that somebody does on the side. That may work initially, but not once you make Agile part of your long-term DNA. Instead, you’ll want it to be an explicit, dedicated role with a title, a job description, skills and
professional development. Overall the skills you need on the teams will be different as well and you will hire different kinds of people. So why not adjust the job descriptions and even reward systems to account for that?
- Invest in coaching: A lot can be gained by having experienced, professional coaches with focus on Agile assist your various Agile teams as well as the “business side”. Not only will they help on the team level, but also be catalysts to organizational change management and achieving business Agility. They will also bring the right perspective and voice of reason and will not only be the first ones to spot the ship getting off course, but they’ll also be able to counteract those tendencies.
- Know how to operate your model: Having a deliberate and explicit operating model for Agile will be hugely beneficial. How do you keep track of all your teams, their health and metrics? How do you know when to engage your coaches and for whichteams? How will you on-board and train new resource and get them educated and embedded in your Agile teams? What are you standards for tooling, internal or external training and certifications? Who in the organization is helping with propagating your Agile model (multipliers)?
- Don’t be satisfied with just the basics: There’s more to Agile than just running basic Scrum (or Kanban) at the team level. There is scaling, (A)TDD, automation, various technical practices rooted in XP. Don’t forget that technical excellence and true craftsmanship are elements of Agility as well. CD/CI and DevOps should also keep you busy for a while. Don’t get stagnant!
- Invest in training, education and outside perspective: Agile is evolving every year and like any field of knowledge, it takes effort and time to keep up. How will you invest in training and ongoing education? And don’t just stay in your four walls: get an outside perspective by exposing yourself to what’s going in the industry, in other companies, at Agile conferences and events. And don’t be shy to bring external thought and expertise into your organization in terms of external consultants. Fresh thought and a clear unbiased perspective are hard to come by from the inside alone.
These are just some of the examples of how one can apply energy to the Agile adoption and being Agile on a consistent basis in order to not just maintain the status quo, but continue to improve and push the envelope. (And avoid wrecking the ship… 🙂 )
What have you seen work in your organization?
Back to Agile: is there something equivalent to technical debt when it comes to transforming teams and an organization and moving them to Agile? I would argue yes, there is. Let’s think about some examples.
