“Manifesto for Agile Software Development” – the name gives the game away! ‘Agile’, as it is commonly called nowadays, is for software development and, for that reason, the relationship between agile ways of working and development teams is mature. We have an opportunity to take a look at this and ask ourselves, what does this mean for groups of people who don’t build … Read More
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).
The idea of ‘reporting’ is disgusting and pervasive. I hate it.
That’s not to say that there isn’t a place for governance and oversight. I’m not about to argue against that. I’m talking about the idea of reporting driven development, the idea of a ‘status meeting’. I’m talking about the idea that you are being watched.
Now, if you’re on a project where your development, targets, and daily work are driven by reporting your status something is, in my humble opinion, wrong. It’s an indicator to me that you are concentrating decision making authority for too much to too few. It’s an indicator that your team feels ‘watched’. It tells me that at a fundamental level the communication on that project is broken.
I hate the phrase ‘Continuous Improvement’. It conjures in my mind the image of innovation days, innovation champions, written feedback, suggestion boxes. It makes me think of all of the organisations I’ve worked with who see that they are stagnating but fail to grasp the basic concept behind their stagnation: the desire to adapt and change is a state of mind, not a question of process rigour.
Go read the wikipedia entry on Kaizen and come back if you don’t know the term. That’s what I’m talking about. Everyone feeling a sense of ownership, everyone empowered to speak up to suggest improvements (big or small). If you are relying on enforced ‘innovation days’ then I fear the boat has sailed for you. Stop doing that, and think about it a little differently. Here are my suggestions for how you could go about making a big change with a slow burn (nb. slow burn = high buy in).
Our project is lucky enough to have the holy trinity of analysis, namely dedicated business analysis, user research, and graphic design specialists. It’s amazing! Every two weeks we run user research sessions to gather feedback and try out new ideas, either with the working version of the application we’re building or with decent mockups.
Our user researcher goes. Our graphic designer goes. Heck, most times the majority of the team goes. I do not.
It’s not something I’ve really talked about here with people on the project, or publicised, but it came up today because I’ll be leaving the project soon and the Product Owner realised I hadn’t been to any of the sessions. So, here’s my thinking.