News

So, you’ve just learned about agile practices and the agile mindset and you’re excited about shifting to an agile way of working. Great! You’re going to (eventually) love the difference it makes in productivity, customer satisfaction, and team morale. But... it is all too common for the initial bloom of enthusiasm to turn into the doom and gloom of “What were we thinking? Agile is a chaotic mess of endless confusion!”

It does not have to be this way. This reaction is not a sign that agile is “bad.” It’s a sign that agile has not been implemented well. Here are eight tips on how to get agile rolling in your team or organisation in a way that minimises the startup pains and delivers the promise that agile holds out to new adoptees.

1. Bring in some experienced leadership to guide teams

It is common that you’ll start out with nobody on the team knowing anything about agile other than what they’ve read in a book or a couple of blogs. But my recommendation is to hire an experienced coach or ScrumMaster to guide the team through the process. This person will be a trainer as much as a project facilitator as the team comes up to speed.

In addition, or as an adjunct process, I do recommend giving the first agile project team in your organisation training as a group. SoftEd’s Agile Fundamentals course is an excellent way of getting thought processes, vocabulary, and particular techniques across to the whole group at one time, setting the team up for success right from the get-go.

2. Introduce methods and practices bit-by-bit

Don’t feel you need to throw out everything you currently do and replace it with the entire agile methodology overnight. This can create more problems than it solves. There are a number of practices in the agile world that can be added to existing traditional practices - Kanban boards, retrospectives, daily stand-ups, lightweight estimating. You might consider asking yourself what is the least effective element of your current practice? Then determine what agile practice correlates to that and make that your first change. I mean, how bad can it be if it’s replacing something that’s already messed up?

Related to this bit-by-bit advice, have your first agile project be a relatively small or short one. Cut your teeth on something manageable. You are going to learn a tremendous amount doing this project, and you can then apply what you learn to a bigger project more successfully. I find that a bulk of the learning about how to do agile comes toward the end of the project, so the sooner you get that end, the sooner you’ll start to understand the big picture and how to adjust for future work.

3. Mindset and culture are critical

A common cause of agile failure is that teams undertake agile processes with a rigid and hierarchical mindset. This doesn’t work. A big challenge I throw out to managers (project and otherwise) is that their new responsibility is to manage the context in which their teams can be successful; it is now the team’s responsibility to manage the project. This is hard for some of them to swallow if they have a tendency to micro-manage and measure their satisfaction by how much control they exert. They need to learn to back off, trust-and-verify, and be supportive more than demanding. Yes, set high expectations (and clear goals and vision!), but give the team what they need to be successful and let them go for it.

Within the team, the mindset plays out in terms of collaboration, openness, and multidisciplinary respect. All roles are valued, all voices are heard, all disciplines are critical to success. If this mindset, this culture, is not strong within the team, agile may well be less successful than an old-fashioned command and control way of “running the project.”

4. Make sure the ScrumMaster and product owner have a good partnership

In a recent blog on Agile Team Roles, I highlighted the importance of the relationship between the ScrumMaster and the Product Owner. This is a partnership that is powerful when it works but can wreak havoc on everybody when it doesn’t. Make sure that you start with excellent personal chemistry between these two people. They will have disagreements, but they will need to work them out with large amounts of diplomacy and mutual respect. And as they do this publicly, they set the example for the rest of the team for how an agile team collaborates successfully. If you don’t have an experienced agile person in one or both of these roles, consider sending them on a training course together. 

5. Management is on the agile team too 

A common problem with agile adoption is that some high-level manager dictates the shift to agile - “I read a blog that said agile will solve all our problems” - and then does not make the shift to the agile mindset himself/herself. What that person may not realise is that an agile team is larger than just the implementers - it includes managers and executives and customers/users. Because the team is regularly giving showcases to stakeholders, they will need to be involved regularly to review progress and to provide feedback on any number of issues that need to be addressed as the team makes the discoveries that always come up in a project. Yes, getting these people’s time is always challenging, but agile requires a certain level of engagement from them that they have to be willing to provide.

Related to this, it is imperative that the project/product vision and goals are made clear at the very beginning of the project, and that adjustments to vision or goals are made clear between the sponsors and the team. Executive engagement and communication often need to be more frequent in an agile project than a waterfall project. This is a good thing.

6. Customers have to be agile too 

Because agile is a user-centric, customer-centric approach that recognises that iterative development produces insights (and surprises!) as we proceed, customers are going to have to have a more frequent and deeper involvement in the development process - be available for showcases, make users available for testing, and be decisive when options need to be evaluated. The old days of the initial brief being sacred are over. The product definition, goals, and priorities are going to shift as we learn more from initial releases and increased user engagement, so be ready to analyse what comes up and work with the team to agree on and plan out those adjustments. 

7. Get your team processes working before taking on agile software tools

Okay, this one is not a hard and fast rule, but I would point you to agile value number one - Individuals and Interactions Over Processes and Tools. There are some great tools out there for supporting agile teams and processes. Jira and Microsoft Team Foundation are two that I know and like, but there are others. What I’ve seen work well is for a seasoned ScrumMaster or coach/consultant to come into an organisation and implement both scrum and a Jira implementation. This can work, but short of that, I’d recommend getting the team to start with lightweight paper-based processes like Kanban boards and daily stand-up reports - processes that force face-to-face interactions. Once the team has worked these for a while, they’ll make adjustments toward something that is really working for them.

Later they can add Jira to the mix. Because Jira is highly customisable, they can set up Jira to work the way they’ve learned is successful for them, as opposed to working in Jira’s standard ways. It is a bit more work to reconfigure a tool to work your way than it is to make quick adjustments to a casual paper-based system. That said, for sizeable projects, you will want to get tools like Jira or MTFS working for you, for sure.

8. Use retrospectives

Hang on to your hats, I’m going to rant and rave for a minute. The most critical component of a successful agile adoption program is to acknowledge that you are going to stuff up a whole lot in the early stages of what you do. This does not have to be painful. If you adopt bit-by-bit, then you’re only going to stuff up little bits at a time. But the team has to be honest and open about what’s not working, and it has to take concrete steps toward getting better at how it’s working.

This is where retrospectives come in. They should be the first agile practice you get going in your group. Do them regularly, do them with discipline, and make at least one small change in how you work, as determined in the retrospective. We’ve heard great stories from clients who have adopted my retrospective format - video here - and made it a standard part of their practice. Some people are initially resistant to participating in retrospectives, mostly because they have accumulated so much scar tissue from attending old-fashioned Post Implementation Reviews in the past. These shame-and-blame sessions are caustic for company culture and even worse, they often produce very little meaningful improvements in how teams work. Effective retrospectives (almost) always come up with small incremental improvements to the process, communication, or documentation, and best of all, because the team is working together to get better and better, the effect on morale builds and builds over time. Remember, if you don’t change how you’re working, you didn’t have a retro, you just had a gripe session.

For some teams adopting agile is a small step, and for others it’s a giant leap, but I think all teams should consider these eight ways of getting started. I don’t want you to fall into that unfortunate pool of people who “tried agile,” but didn’t feel it was successful. Agile is not a silver bullet. It takes effort to get it working successfully, but I know from my experiences and the experiences of teams I’ve worked with, that if you follow these tips, your chance of success will be much higher. 

Post by Jim Simmons