Agile adoption failure stories are abundant, especially in large organizations. There are many vague reasons and lame excuses for this: “Our culture doesn’t support change initiatives.” “Our leadership won’t adopt an agile mindset.” “Our change order process can’t integrate with an agile process.” And so on.
Here are some concrete things you can do or consider as an organization leader or manager if you seriously want to see an agile approach bear fruit. For each of these, I’ll share a Silver Bullet Solution or SBS for short.
Remember: Learning to be Flexible is Hard
Keep this in mind for the first 1-2 years of piloting an agile approach. Replace all stickies on your monitor with stickies that say “Learning to be Flexible is Hard.” Get it etched on the inside of your car’s windshield.
Learning something new is easier if you start by following a set of basic rules for a while until they become rote and can be applied and combined in an ad hoc manner. A healthy agile team determines their starting rules for the situation and changes them over time to adapt to the changing situation.
Herein lies a conflict. A team new to agile needs direction on how to get started in a way that doesn’t just create a new calcified process which they don’t own.
SBS: Have the team work with a well-defined agile process template for the first 3-6 months. Then have them start introducing changes through process retrospective meetings every 2 weeks.
If you followed my earlier advice, in a year, you’ll remember that Learning to be Flexible is Hard, and you’ll check in with your team to see how flexible they really feel they can be. Permission is necessary but not sufficient to escape the feeling of we’ve always done it this way (even if always is just the past few months).
Once your team has mastered the basic tools of your template process, they need to get good at bending and breaking those rules. Maybe join a retrospective meeting and suggest a radical change your team assumed you’d never be okay with changing. Get the point across that they are responsible for how they work together and achieve success. And make sure no one is turning into an overzealous Scrum cop. Speaking of which…
Maybe Don’t Hire a Scrum Master
I’m not saying “NO Scrum Masters!” Rather, consider whether your team needs one, and, if so, be thoughtful when providing one. In my experience, many full-time Scrum Masters tend to become process police. They insert themselves into retrospectives to chastise anyone perceived to not follow The Process and act as the gatekeeper for any new ideas the team wants to try out. This behavior pattern is antithetical to an agile approach and will very effectively teach your team to hate your process.
If you or your team feel as though someone needs to hold this role, have a developer, designer, or product owner who is 100% dedicated to the team take it on. That way their primary goal is achieving success for the team’s goals through an effective process, vs having an effective process while justifying the value of a Scrum Master.
If support from outside the team from an experienced agile practitioner is desired, consider contracting or hiring an agile coach. The key here is, let your team(s) decide whether they want to start, stop, or continue working with the coach to ensure the agile coach always provides value to the people over the process.
SBS: If you want a Scrum Master, make it a team role instead of a job. Let your team decide if they want an agile coach.
Small 100% Dedicated Teams
Keep your teams small enough so they can communicate effectively not only on what they’re working on but how they’re working. Changing a flexible process should only require a retrospective meeting, not a change initiative prefixed with rounds of buttering up and politicking.
Also, don’t split people between multiple projects. I’m not saying it like this because I expect you to never do so. But when you do, you should need to dig for a good justification. You need to dig for a good reason because it hurts to be only part of a team instead of on a team. Part-time people fall behind on context or need special separate work set aside for them. They feel less allowed do advocate for a process change. I know you’re going to do it, but just… feel bad about it when you do.
SBS: Keep your teams at 10 people or fewer 100% allocated (this includes product owners and designers, etc.)
All Process, No Practice
Don’t just think because your Jira’s in order, your iterations are chugging along, your stories all have tall/grande/venti Starbucks sizes assigned… just because your burncharts are burning, your WIP counts are low, your planning meetings are ending on time – that doesn’t mean your team is sustainably producing valuable output.
For that you need solid development practices woven into your agile team’s process. Things like test-driven development, end-to-end testing, continuous integration and delivery, pair programming, and more. These are important pieces of a high performing agile team and should be managed as formally as the process. A discussion of how pair programming assignments should be determined going forward should happen in the same retro meeting as you’d discuss changing a sprint length.
SBS: Consider extreme programming practices as important as your agile PM-focused process.
Leave Velocity Alone
Velocity is one tool in a set that a team can use to manage medium-term expectations. It’s not a means to judge a team’s productivity week to week. It’s not a way to understand how much value a new team member is “ReAlLy pRovIdiNG”. It’s not input for someone outside of the team to build up their own expectations of how “easy and quick” something should be.
Your team may use it to draw a picture of future projected progress for you or to reflect the projected cost of optional paths forward. But whether they use points, exotic bird weights, t-shirt sizes, or MMF counts to do it is up to them, not you.
SBS: If you’re not a full team member, don’t look for or expect to see velocity.
Measure Outcome Instead of Output
So what do you measure if not velocity or commit count or lines of code? Well now, that’s up to you.
Why do you have a software team? Use your larger goals to guide how you determine what a team is producing. Do you have near-term goals to increase the stability of your existing product or platform? Do you have a near-term immovable deadline you need to actively manage the definition of success for and hit? Do you have a longer-term goal that you want to see incremental progress towards?
Collaborate with your team leaders to set realistic goals and milestones based on them. Even our best practices for managing “productivity” of custom software development yield spikes in output that don’t directly correspond to whether an individual or a team is contributing value.
SBS: Don’t use metrics like velocity, lines of code, commits, or deploys to measure the value produced by a team.
Let Go of the Wheel
Were they in a game of chess, your team members should feel like they’re playing the game and not pawns on the board. This is especially true with respect to their process and tools, but also with respect to product and platform decisions they’re implementing. As much as possible, delegate product and platform decisions to your team. Ask them to find the best decision and not feel bottlenecked on you or others outside of the team for sign-off or approval. Doing so will yield a team engaged with how they work and what they’re working on.
SBS: Ensure your team knows they have responsibility and authority to run themselves.
Lead From Within
You will need a team of people who are excited to take up this challenge. No agile Eeyores you’re looking to cheer up or Gantt chart jockeys you’re looking to convert. Don’t think of agile as a Scrum-branded band-aid that’ll help a Matt Foley “get back on the right track.” You need people who are motivated to work together in a way they might not have done before. Put another way, the first thing you should do is:
SBS: Don’t try to drive agile adoption from the outside. Find people excited to be on your first agile team and let them lead themselves.