Many companies are very much aware of what is called “technical debt”. While there are several trains of thought and definitions around this term, I’d explain technical debt– for the purposes of this conversation – as known technical shortcuts or compromises that were taken in the course of developing something or known, non-critical defects that are allowed to exist, at least for some period of time. Examples: Developers choose a sub-optimal technical design of a solution that is known to be less robust, but quicker to implement. Or: a key feature in need of being released to the market still has several medium-severity bugs that are deemed non-critical, so the feature is released with those defects. In either case, technical debt is like regular debt in that it has to be paid off, hopefully sooner than later, by refactoring the code, rectifying the design/architecture or fixing those known bugs. If not attended to, technical debt will pile up and make the product unreliable, fragile and harder to maintain in future. Some would argue that unresolved technical debt over time even incurs something equivalent to interest in that it gets – like financial debt – harder and harder to resolve. Mounting technical debt is also known to slow down new feature development as more and more energy is spent on just keeping technical issues under control.
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.
Focus on practices without anchoring on values and addressing culture
Ignoring of traditional behavioral patterns and management styles.
Reliance on external consultants without growing local roots.
Team-only approach without addressing team context and organizational impediments.
Insufficient training (team members, Scrum Masters and Product Owners).
Leading the transformation with the implementation of an Agile tool (ALM) and assuming this will make teams Agile.
Grass-roots only, bottom-up transformations without leadership support.
These are just a few examples that come to mind. To see other common anti-patterns, I recommend looking at the results of VersionOne’s annual State of Agile Survey.
The shortcuts mentioned above will – by themselves – not automatically result in doom and complete failure of an Agile transformation. However, similar to technical debt, they will weaken the impact and progress of a comprehensive transformation and limit the benefits the organization will reap. Dealing with the ramifications of these compromises will consume more and more energy as we’re attempting to pay off this debt. Over time, these “cracks in the foundation” will impede additional progress and the organization may even start to regress to the “pre-transformation state” due to the always present organizational inertia and tendency to revert back to previous state.
It comes down to this: Agile debt is real and at least as destructive as technical debt. So let’s not take the easy shortcuts, but focus on doing it right. Only that way will an Agile transformation “stick” and provide real and lasting benefits to an organization.
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?
Subscribe to our mailing list and get interesting stuff and updates to your email inbox.
Thank you for subscribing.
Something went wrong.
We respect your privacy and take protecting it seriously.