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”.)
- 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.