Agile programming — for your family
Bruce Feiler: Agile programming — for your family
http://go.ted.com/0TxLvA
A roadmap to where
There has been quite a bit of interesting discussion on Twitter about Roadmaps; what they should include, how they should be structured, how to make them useful for agile teams.
A roadmap shows the direction and the destination. If we think about actual roadmaps, where the metaphorical roadmaps we refer to come from, they show all the possible destinations (towns, cities, etc.) and all the possible routes to get there (roads). Typically, if you wanted to get to a particular destination (achieve an outcome) you would start heading in that direction, but if an obstacle was in your way you’d change route but still be heading in the same overall direction towards the destination. Some routes are faster, some routes are more interesting.
So, a good roadmap (back to our metaphorical roadmaps now) should show the outcome that we want to achieve (destination) and provide some direction of travel as a guide to keep teams moving towards the destination. The direction of travel acts as strategic bumpers to help explain the ‘where to play’ decisions but gives the team enough room to decide on the route for themselves.
Roadmaps that explain the destination and the direction of travel become ‘who & why’ roadmaps rather ‘what & when’ roadmaps. ‘What & when’ roadmaps are misleading and often obscuring because they try to define what the team should build before they’ve started the journey and when they’ll be able to do it. ‘What & when’ roadmaps show uncertainty as a pretend certainty.
So, we should accept that ‘Roadmap’ is an incomplete phrase. We should be clear about it not meaning ‘A roadmap of what to build when’. We should be clear about ‘roadmap’ actually meaning ‘A roadmap of why we’re building and who we’re building it for’. Then roadmaps become about achieving an outcome (getting to the destination) rather than the stops along the way. Then our phrasing can become more specific; ‘A roadmap for achieving x for y’. That could be ‘…achieving product/market fit for our idea’ or ‘…achieving 30% time saving for regular subscribers’.
Different teams move at different paces
I drive a sports car. You drive a bus. I can get myself there quickly. You can get lots of people there slowly. You can’t make a bus handle like a sports car but you can tell people to get off the bus and find other means of transportation.
No deadlines
Scrum works for cross-functional teams of specialists that only work on one thing at a time and have everything they need within the team to complete the work.
Scrum has the #NoEstimates movement that says slicing work small enough enables teams to incrementally deliver value without requiring any kind of estimation.
But Scrum doesn’t work for multi-functional teams of generalists that work on lots of different things at the same time and have to work with other parts of the business to accomplish their goals.
I’d like to propose #NoDeadlines for modern agile teams not using Scrum and working in ways that mean the work they are doing requires collaboration with other people and teams who also have other work and different priorities, and which is often out of the teams control.
#NoDeadlines recognises that it’s impossible to accurately predict when work will be completed if it is dependent on people that aren’t part of the core team doing the work. The more people and teams involved, and the more things those teams are working on, the more impossible it becomes to accurately predict when any piece of work will be completed.
Commitment to deadlines should only be made if everything that is required to meet that deadline is within the control of the person making the commitment. If any element of the work requires input from someone who isn’t part of the team doing the work, isn’t asked to commit to the same deadline, has other priorities, works to a different schedule, or suffers no consequences from not meeting the deadline, then deadlines should not be set.
Deadlines set in these kinds of situations are at best completely arbitrary and at worst pure fantasy. Communicating fantasy deadlines to other parts of the business undermine the team when those deadlines aren’t achieved because the team needed input from other people who weren’t committed to the work in the same way.
Not setting deadlines takes the pressure off of teams from chasing unrealistic fantasy deadlines that they don’t have control over and provides psychological safety to experiment rapidly and focus on delivering value to the customers when that value is ready.
Buying and merchandising teams have always been Agile
For a Buying and Merchandising Team performing quite a traditional function for a business that is moving towards a more Agile approach, the uncertainty around impending changes could be a cause for concern. But they shouldn’t be. I think Buying and Merchandising Teams are already working in quite agile ways.
Accepting change
Merchandisers will start a year with a target for how much they think a product will sell, which they use to buy the right quantity of stock. They’ll create a plan based on last year’s sales information to suggest how much will sell, when and where (which shops), but
Merchandisers inspect the sales and adapt the replenishment of stock to shops to maximise the sales potential.
Small batches
A merchandiser could send all the stock they have out to shops at the beginning of the season, but instead, through analysis of sales patterns they break the stock down into small batches and distribute it to shops for when they need it.
Merchandisers slice the available stock into small batches.
Fast feedback
New products are introduced in a disciplined way. They are bought in smaller initial quantities, trialled in a small number of shops, and watched carefully to see how they perform. These initial reactions are then used to plan further roll-out of the product to more shops, or discontinue the product.
Merchandisers get fast feedback from customers and use it to inform how to distribute stock to shops.
Scrum Training
I spent the day doing Scrum training with some of the teams who work on the BHF website. Everyone had different levels of experience of using Scrum and those who are currently working in Scrum approached the training in a very different way to those who aren’t. It was clear they were seeking answers to specific challenges they are facing.
For me, the interesting thing was talking about ‘Definition of Ready’, which is something I’ve not previously given much thought to. It’s obvious that a piece of work has to be ready to be worked on; clear requirements, stakeholder agreement, etc., but the idea that the more certain a thing becomes the closer it is to being ready connected with my thoughts about uncertainty and risk.
More scrum versus whatever it is that we do
You iterate, we evolve.
You work in fixed time boxes, we let each thing grow at it’s own rate.
You have a definition of done, we try never to finish anything.
You burn down work you’ve done, we stack up things we’ve achieved.
Good customer services gets you closer to the customer
Our new customer support system has been live for a week now, and we’ve already seen benefits in customers getting better answers quicker than ever before.
Of course serving customers better is really important, as is making the teams more efficient, but the real benefits come from getting closer to our customers. We now have a means of recording, collating and analysing the that are bothering our customers most.
Agile demands that we get closer to the customer. The manifesto says we should value individuals and interactions and customer services is one place where those individuals we are serve are interacting with the organisation.
So as we take steps to become a more agile organisation we should make real efforts to seize the opportunities that our customer services teams and system offer.
Agile Risks Meetup
I went to a meetup with a group of Agile practitioners discussing Agile ways of dealing with risks. It gave me lots of interesting things to think about:
- Get close to the customer, really understand their needs, to reduce the risk of building the wrong thing.
- Users who are choosers give helpful feedback because they can decide not to use the solution. If not, feedback is superficial.
- Explore possible solutions concurrently before going on to build a single solution.
- Ignore the likelihood of the risk and focus on impact.
- Communicate risks and issues sooner rather than waiting until they become big problems. Don’t pretend to be green if things are really amber.
- Deal with risks as you go along rather than identifying and only intending to deal with only if they arise.
- Risk reduction = knowledge acquisition.
- Learning about the risky things is building business value.
- Traditional risk management focuses on ‘known unknowns’, but misses the ‘unknown unknowns’.
- Unknown things often get put to bottom of the list but maybe they should be dealt first.