Slicing For Organizational Agility – Neil Killlick

“Organizational agility is about learning about the market and changing to provide what it wants”.
This is the opening statement by Neil Killick at the recently concluded Dev Day 2015.
“Agile is ordering tapas till you’re full and not ordering a 10-course meal”
Neil opens with the quote which refers to ordering small chunks of food called “tapas” and sharing it with everyone else. So essentially, we would keep eating with tapas until we are full, rather than ordering a 10-course meal. This he says, is agile. In developing software, we come up with grand plans on how to achieve and build something and then commit to it. However, we should be agile in doing smaller things so that in the event there is a change of plans, we are open to mixing things up a bit as we go along. It’s important we work in small batches so we can throw away and prioritize.

He then shares an image of a bullet train. After learning about how bad our train service is, he shares 4 qualities of the bullet train service

• Speed: They reach speeds of 320km/j
• Predictability: 13 trains between Tokyo and Osaka
• Reliability
• Comfort & Safety

How did they achieve this? They built dedicated lines for high-speed rail so they aren’t slowed down by slower trains. There are virtually no road crossings and the tracks are specially designed with dedicated drivers and support staff. So basically, the moral of the story was not to make a train faster or more reliable, but rather, to create a network for high-speed trains.

Most organizations and environments will ask their employees to simply work faster and more predictable rather than building a network to support people from delivering software quickly. The key here would be to let one team focus on one thing without worrying about multiple things.
The big question: Is agile estimation really helping us evolve into more agile developers? It’s better than the tools we used before but it’s still predictive, which means we are still trying to figure out how expensive software is which result in the project and its members going over-budget. He refers to the train again where we know that in developed countries the trains always show up in 3-5 minutes, in a software world we don’t know things for certain so we are predictive. He gives poker planning as another example which is predictive and organized for speed so we quickly try to get it out of the way and any points used in it is becomes abstract. Planning poker is also focused only on cost, not on when the customer will receive the benefit of the product. It’s also develop-centric, we don’t concern ourselves with marketing and legal issues. It also encourages a false security because again it doesn’t give us an accurate ETA, rather it only helps us make predictions which may not be accurate.

These, Neil states, are just some of the problems with agile planning.
Enter Slicing heuristics. Rather than estimating how long things take, one simply breaks down goals into small chunks and measures how long each chunk will take. You can then learn from that and improve the entire process going forward. It’s aimed at improving predictability and reduce time to release products. Now the keyword is heuristic, is that it’s not an approach that’s not perfect.
The 5 steps are:

1. Define and agree on work types: Define an initiative which is the strategic theme likely to last month. Define capability which is the desired customer outcome. Feature which is the proposed solution. story
2. Agree on slicing policy for each work type. Here you need to define when to stop slicing and decide on the desired cycle time and variation. Make policies explicit and visible. This takes a page from the Kanban method.
3. Slick work, Just-in-Time. Have 1 card for each work item coming into the system, which increases predictability massively. Make sure the appropriate people meet for each work type and remove/ de-prioritize options.
4. Do your work and also don’t forget to measure cycle times
5. Inspect & adapt policies.

What do we learn from all this?
The work might take a longer time, it may be straight up unpredictable, or simply unpredictable within a work type, or a certain work type may become retired. If we reduce asking people for too many things then we can get more things done. In a software company the queues are invisible. Unlike in a coffee shop, adding another person to the task simply makes the queue longer, thus delaying your coffee.
If we have a variable cycle time then we can try being more consistent in the way work is defined, keeping work-in-progress consistent and minimizing distractions. This also results in reduced stress.
So slicing heuristics lead to:

• Common language of time and work type
• Conversations
• Do lots of small things rather than try to complete large objectives.
• Faster turnarounds
• Options to see which tasks/goals can be achieved the fastest.
• Less risk

However, this will only work if you try it. Neil went on to explain that you shouldn’t go ahead and implement this in all in one go, rather, you can take a few bits and pieces from this theory and try it out.
“If you’re not experimenting, then you’re committing to something that may not work in your context.”
Neil ends his session with a few chosen words of wisdom.
“Always focus on individuals and interactions over processes and tools”