Bringing agile ways of working to teams comprised entirely of people focused on business (ie. the non-tech folk) is a challenge. It’s notoriously hard to do, because the kind of work that’s undertaken isn’t easily shared, paired on, broken into sprint or sub-sprint length tasks. It’s not impossible, though. Here’s some of my experience (a work in progress).
Bringing agile ways of working to a team used to waterfall methodologies, reporting, and documentation will never happen overnight. Prepare to be very, very patient.
Understand the journey
Start by understanding what it is you want to achieve by bringing agile to your team. It’s not a magic pill that suddenly makes you more efficient, not by a long shot. Take a look at the things you aren’t doing well as a team, examine the reasons why that’s so, and then objectively evaluate whether or not practices from the world of agile delivery are even appropriate. They may not be, and certainly don’t assume that an ‘all or nothing’ approach will work.
What’s not so great? On joining a team there was a very clear structure (in terms of org chart) and clear reporting lines. Roles were well defined, but largely in silos. As a result collaboration wasn’t great, and nor was communication. Earphones were often in use throughout the day.
What’s the cause? Having a formal hierarchy and roles in silos makes it very difficult to collaborate. Visibility is poor, and so opportunities to contribute don’t exist.
What’s the agile journey? A full roll out of a formal agile methodology isn’t needed, but bits of one are useful.
Create visibility by employing some kind of information radiator (eg. JIRA). Create a space to interact by reviewing stories (eg. Backlog grooming). Create a collaborative environment by showcasing work and inviting discussion (eg. Monthly showcases).
Build understanding and buy-in
Once you have an idea of simple, actionable changes you can make to the way you work, the next thing to do is to start building support for those initiatives. Depending on where you are working, this may be somewhere between super-duper-easy and super-duper-hard to achieve, so here are my tips.
Start small. This is why I say that ‘all or nothing’ isn’t the best place to start. People like to be eased into things, for change to feel natural, and the best way to do that is to be focused on the smallest changes that will have the largest impact. Sticking with the example above, that’s why we’ve chosen to start with an information radiator.
Consider your audience. Different people in a team naturally take different roles. You have leaders, influencers, trusted confidants, followers, thinkers.. You name it, most teams will have people who fill one or more of these roles. Your job before you get going is to understand who to talk to first.
By and large, my tactic is to start with the influencers and their confidants. Win them over, and the rest will come along on the journey. The best way to do that is to share your idea in terms that state clearly what the benefit is to them personally. For example, if your influencer is a Project Manager you can sell the benefits of a communal information radiator as a way to make reporting and monitoring easier. Remember, you’re not aiming for an agile culture overnight, and so thinking in those terms (ie. reporting and control) are fine. They’ll change over time as you iterate over your plan.
Get the OK. Win over the person responsible for the team, get the go-ahead, and then share your thoughts with everyone on the team. That last step is key because it’s a subtle nod towards the kind of openness and visibility you’re trying to create.. it sets the tone.
Take baby steps
Implement your change, one at a time at first, and slowly. Take baby steps. At first you will find things difficult, but don’t be discouraged. The graph below, showing the Satir Change Model, and taken from this great post by ThoughtWorks on Adaptive Leadership, shows what you can expect.. in summary, after a change there is inevitably some resistance and difficulty before things significantly improve.