Agile Coaching

Dot Counting

Here’s a very simple tracking mechanism for physical story cards that your team can use to learn more about the proportion of time you spend on different types of work. One of our product development teams at Unruly has used this approach for tracking time spent on things for at the last year and a half. As a team, we don’t typically do any deep analysis of the data gathered but it does help us understand what’s going on when our velocity dips. This data also helped the team push back on minor support requests over new features when this became an issue

Here's how it works. We use coloured cards to represent different types of work:-

• White cards are used for stakeholder facing stories. Blue half-cards are sub-tasks for stories and don’t get counted separately
• Green cards are technical tasks such as upgrades of infrastructure
• Red cards are support tasks such as bug fixes and data requests
• Gold cards are developer research. Although we don’t represent these using physical cards, instead we put them on our team calendar so that we know which day they’re planned for. We also use this team calendar to track the time spent in meetings.

The different colour cards have swim lanes on our team board and get prioritised in different meetings. Stories are prioritised by stakeholders every week. Red and green cards are prioritised by the team on a weekly basis.

At standup time, we apply a dot to the cards on the board based on how many developer days were spent on them the previous day. One dot represents a single developer day so cards that were paired on get two dots per day, etc. Then on Friday, someone from the team crosses out the dots on the cards and sticks the data into a shared spreadsheet. From this information, we can see that we rarely spend more that 50% implementing user stories and that we have spikes in green and red when there are outages. It’s also good to see whether we’re ensuring the developers are making time for their research.

Note, I don't think we've tried plotting velocity over this data but perhaps it might be interesting to do that some time.

Who counts the dots? We take turns to do this at the end of the week guided by our dot counting rota and checklist.

You don’t need any special stationery to get started because you can draw dots with a marker pen. We additionally use a date stamp to mark when story cards get started and finished. We also have a record card box to put completed stories into.

I guess to Kanban folk this might sound like we have no defined classes of service and corresponding limits. We find that pair programming and small team size puts enough of a limit on these for us. In a team with 3 developers we can only run one pair per day on features/stories and then the person who's not pairing figures out whether to dedicate the day to research or a mixture of green/red cards.

Introducing Agile Techniques to Teams Outside Software Development

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?