Agile for any organization – a guide
Posted on 16. Jun, 2011 by ger in Guides, New Ways to Work
Agile management techniques have been used successfully in software and development in recent years, but can they be used to run other kinds of business? I believe they can. If you want to transform your business into an empowered, self-organizing machine that performs better, read on.
In this guide to agile I will, tell you three stories which will hopefully:
- Outline the benefits Agile
- Point out some tips and pitfalls
- Suggest some further reading
It’s about 13 years since I first encountered agile management. At the time I realized we were already naturally using some agile ideas, we just didn’t know they had a label. As you read this guide you might say “We already do that.” If you do, congratulations, you’re some way down the agile road already. Learning a little more will help you see the bigger picture and get even more out of agile.
Agile before we’d heard of Agile
Around 20 years ago (I’m really dating myself now) I worked for a US multinational building software for managing networks of telecom equipment (for a new standard called GSM). The project had run for a number of years with a large team and we had little working code to show but lots of specifications and elaborate plans.
A number of us felt a growing sense of unease so we put together a small team of five engineers and decided to rapidly build a simplified version of the overall system. Our small project was going to be a backup plan for the main team – risk mitigation. The other seventy engineers kept working on the existing plan. Can you guess what happened?
Our small team didn’t put any big plan in place. We commandeered a small meeting room and drew a list on a big whiteboard of the phases of the project. Each engineer owned a specific area of the product. We didn’t work in our regular cubes, we worked together in the meeting room. We lived and breathed that project. In effect the product was built during an extended ten-month meeting.
When the big team tried to put all their pieces of software together, they wouldn’t fit. Then we demoed our simplified product. It was fast, elegant but most importantly – it worked. The simplified product, built by five engineers in a small meeting room, became the basis of future products by that company for many years.
How did we do it? We had a simple goal, a simple plan, a deadline not too far away & we continuously reviewed progress and made many small adjustments. Management didn’t interfere but more crucially provided air cover for our small team. We were agile but didn’t know it.
First successes with Scrum
A number of years later I was working on another project that hit a problem. We realized a crucial software subsystem was more complex than we had estimated, the subsystem was underresourced. Our reputation was on the line. We had five months to turn it around. In a previous company I had been experimenting with two new management techniques, one called Episodes and one called Scrum. To my eye they looked very similar. Episodes went on to become Extreme Planning and Scrum went on to become er Scrum.
Again we put a small team together, this time four engineers. We split the overall project into a series of five month-long sprints. We then focussed only on the current sprint. We held daily meetings and everyone planned their own tasks each day. For each task we put post-it notes on a big A2 sheet of paper on a table in the middle of our work area.
We built the crucial subsystem in five months and three days, which for a software project is remarkably close to the deadline.
Our next project, spanning 15 months with 30 engineers (6 teams of 5) mostly used Scrum. This project we completed one week early (which is very rare in software projects). Other teams in the organization started using A2 sheets and daily meetings. The company’s post-it note bill skyrocketed. Projects hit their deadlines.
I think there were a number of key factors in these successes:
- Everyone on each team had a sense of ownership both of the project and their own destiny.
- We didn’t spend time building intricate and brittle long-term plans.
- Everyone was focussed on a tangible milestone, at most a month away. We didn’t have time to delude ourselves into a false sense of being-on-track. We didn’t change plans during each sprint.
- We met almost daily and made many small adjustments.
- We created a simple visualization of the project and progress.
- Everyone, even the graduate engineers, became a project manager of their part of the project.
- We held retrospectives at the end of each sprint to decide what went well and what went badly. We saw genuine organizational learning.
Scrum to manage marketing campaigns
Recently Goshido began working with another multinational product company, but this time instead of building products this team was managing retail marketing projects in 13 countries. The team was running well and getting results, but each quarter-end they seemed to have an increasing backlog of open issues dragging into the next quarter.
They decided to look at their projects as sprints. Deciding what needed to be done in the first sprint (month) led to interesting and surprising debates about priorities. They quickly realised they were not all pulling in the same direction, they were being unrealistic and putting themselves under unconstructive pressure.
Today they’ve mapped out their projects at sprints. They’re not looking too far down the road. Instead of post-it notes, they’re using Goshido and their distributed team (some of whom are outside the company) have an always-up-to-date picture of what’s happening on the project. They spend less time in meetings, more time making progress.
We would wholeheartedly recommend the agile approach to running projects. The key challenges are not technological but sociological – resistance to change. Agile is a new way of thinking, but when your team starts thinking in that new way, they feel more empowered, more engaged and will improve your business performance.
Learn more
Kirsten Knipp’s blog post show’s you how to run a marketing team like an agile startup.
Read Mike Cohn’s blog post on how to decide if Scrum is right for your project.
The wikipedia article on Scrum will give you a good primer on the terminology.
Joe Little has written a short but great blog post about getting started with agile and Scrum.
Kelly Waters has written a series of blog posts outlining 10 easy steps to implement Scrum.
A recent HBR article by Eric T. Anderson and Duncan Simester suggests running a business as a series of experiments. Short test-learn cycles sound like the short iteration cycles of Agile.
Stephen Denning’s book The Leader’s Guide to Radical Management applies agile techniques to the organization as a whole, not just a single team or even a product development group.
Update 12-Jul-2011: Steve Denning has also published an excellent introduction to Scrum from a general management perspective.
Jurgen Appelo’s Management 3.0 is a tour-de-force showing how businesses are complex adaptive systems and how this theory can be applied to bring greater agility to any organization, team, or project.
Jurgen Appelo has put together a list of the top 100 agile books. Many of these books are specific to software engineering. I really liked Succeeding with Agile: Software Development Using Scrum by Mike Cohn.
Try Goshido, a new cloud-platform, which helps people: focus, communicate, and do their best work. Goshido applies new principles for how work can be organized; the perfect blend of Agile, Lean, Productivity and Attention Management.