Recently I've been helping teams outside Development apply some basic Agile practices. Our company was founded using XP at the core of our approach to software development. We've grown along with the success of our products and now have several departments with day-to-day work that does not involve the Development team (such as Finance, Infrastructure, and "People & Places" who combine HR and facilities management) interested in managing their work along similar lines.
Rather than blasting these teams with Agile theory and principles, we're building things up slowly. We start with a simple sketch about how to make the work for the week visible on the wall then put it together using super-sticky notes - see the photo from our Infra team based. Columns can be added as needed and, when the system seems to be working, lines can be added with tape. Our People & Places team brought in a spirit level and some flowery scrapbooking tape for to make their wall beautiful.
Around the board, we run a simple meeting cycle: surfacing and prioritising work for the week ahead, daily standups and monthly retrospectives. People on these teams are positive about the new approach because it helps them to know what's going on around them and have the benefit of advice from team members. They're also enjoying spending more time together as a team and getting a buzz from seeing how much work has been Done. Our People & Places team even have a large photo album where they file all their Done tickets so they'll be able to look back later.
Challenges that come up are pretty typical things we see in software development teams, like long standups and large tasks that don't move. We don't currently estimate the work or apply work-in-progress limits although we've discussed whether this might be worth experimenting with. For now we're limited by wall space and when columns get too full we can see we're being a little optimistic -- taking on too much work or have a lot depending on external suppliers.
Based on this experience I convened an Open Jam discussion at Agile2012 for people who were also interested in applying Agile techniques with non-software teams at Agile. You can see the original flipchart notes here. I've reworded them a little to help the points discussed clearer.
What's different outside software development?
- Not having a shared goal (on the org chart but not sharing work as a team)
- IT based examples may not help communicate ideas to non-software people
- Work may be very fluid or constrained by lead times and dependencies on other groups
- Team members may be used to being told what to do
- Team members may be uncomfortable with increased visibility of their work
- Team may have more varied experience levels whereas in software development most are engineering graduates
- Individuals may not be interested in team goals if they have a strong focus on their own objectives
What techniques are not specific to sw dev that you can try anywhere?
- Visible work "Kanban"
- Standup meetings
- Setting priorities as a team
- Limiting work-in-progress
- Retrospectives
- Product Owner role (responsible for priorities)
- Coach role (helping team reflect and improve)
- Reviews / Showcases of work done
- Timeboxing / Pomodoros (http://www.pomodorotechnique.com/)
- Pairing
- Test driving without automation
- Visible outcomes - iterating over visible product
- User stories: Who? What? Why?
- Frequent user testing
- Interactive facilitated workshops
- Shorter more focussed meetings with only relevant people
- Balancing relevance against exclusion
- Focus on throughput over efficiency
Getting the conversation started:
- Explaining the value over beer or coffee
- Introducing facilitation as a way to make meetings more fun
- Executive evangelists
- Arranging a tour of software development teams using Agile
- Finding one open and curious person
- Organising a team reliance - involving all hands as supporters
- Making an Agile coach available to teams outside Development
- Crafting an interesting elevator pitch
- Create interest with cool looking stuff
Poll of areas where people at this Open Jam were applying Agile outside software:
- Publishing school text books
- Finance
- Exec team
- National sales
- HR
- Marketing
- Infrastructure
- Supply chain optimisation
- Political programs
- Volunteers at conferences and festivals
- Academic researchers
- Working with children (at school and at home)
If you came to this Agile2012 Open Jam session, please let me know if I've missed anything important from this write-up. It would also be great to hear from anyone who has tried applying Agile techniques outside software, what challenges did you encounter and how did you overcome them?
Hi!
I think we will see these techniques, values and principles more and more outside software.
I have helped an organization with their process to design aeronautical parts. (It´s in spanish, google translator might help you? http://najaraba.blogspot.com.es/2012/05/agilismo-sin-software.html )
I know people using scrum for cultural projects.
Agile will control the world, for sure :P
Posted by: Joserra | 04 September 2012 at 09:37 PM
Good article.
Agile is a set of values, principles and practices. Most of it can be used outside of software devloppement.
Here is an example with a marketing group:
http://www.agile-ux.com/2010/12/23/agile-marketing-why-marketers-love-it/
JC
Posted by: JcQualitystreet | 05 September 2012 at 12:34 PM
Rachel,
Excellent post. Agile/Scrum techniques are well-suited to non software projects precisely because "...challenges that come up are pretty typical things we see in software development teams, like long standups and large tasks that don't move..." I've been presenting on the ways in which we've adopted Agile and Scrum to manage workflow and impediment removal in everything from HR to Accounting to Sales at Cyrus Innovation(www.cyrusinnovation.com). Slides are hosted here: http://www.slideshare.net/msalernocyrus/non-developer-scrum-teams-how-scrum-can-improve-your-operations
Posted by: Matthew S | 12 September 2012 at 07:12 PM
Brilliant post...Agile adoption outside of software is nothing new , it dates back very close to the origin of today’s agile methods, predating the term “agile”.
Posted by: software development company Australia | 23 February 2013 at 07:54 PM
Difficulties that come up are fairly common things we see in application growth groups, like lengthy standup and huge projects that don't shift.
Posted by: Hunter Frye | 07 March 2013 at 07:58 AM