project after another large up front project Whats a PM and designer going to do whilst theyre waiting for you to fi nish being horribly over-estimate Talk about feedback from customers being 2 x a year Release process / prd marketing Can’t really respond to urgent requests or leave without needing to push out time
We’re spending large amounts of time in meetings or discovery attempting to quanitfy something we’ve not done before when we could just be doing the thing
least And sure - we can communicate con fi dence ranges but at the same time, we’re incentivising sticking to the plan instead of responding to change, which I dunno seems pretty anti-agile to me Ok but sure lets take those numbers that we’re con fi dent in and pad them
Software Engineer, I am going to add 25-50% to it” We play games with estimates We play poker to tell you how long something will be We take times given to us and pull random math out of thin air so it sounds “right” do us Parkinson’s law tells us that work expands to fi ll the time available - so worse, when we pad the time - we end up taking longer anyway
something is going to be done In my case - we have marketing and customer work to do before a release Depending on the release that may mean a decent deadline So what do we do?
I deliver the thing I say I’m going to How can I ensure I don’t harm the team? How can I ensure I don’t harm the product? How do I deliver all that I set out to deliver?
Cycle Time Enable sharing for admins 4 2 1 7 Enable sharing for managers 3 1 2 6 So I start tracking these 3 variables in a spreadsheet, each fortnight I review JIRA and collect data to help build a map of our system of work We dont track individuals - teams cards
objectives And our user activities - the big things your users are going to want to do, but is too big to fi t a single story Then we’re going to break that down further from highest priority to lowest and start marking out the releases For us we used a miro plugin that let us work with JIRA to accomplish this, if JIRA’s your thing EasyAgile makes a bunch of tools one of which is for user story mapping in JIRA. This let us explore and take a lot of the initial planned work and descope or deprioritise it. It let us learn more about the domain as a team You may not get to those other releases and that’s ok but you immediately develop a pretty focussed backlog
to wrong sooner Quick anecdote about excalidraw designers and devs Importance of slicing already - mapping out release slices Impact on our projects - helped us learn a new domain
members - usually about 2 less Helped us to respond to urgent requests or mobbing on unblocking issues Encourages sharing of learning and domain knowledge Handle folks sick or team changes or have learning time In the same way that you’d be setting alarms if your systems were at 100% CPU, we don’t want our teams at 100% capacity at all times Increasing wip will increase time spent at each step in your system of work
queue, and that’s true But I haven’t talked about how we manage ensuring a relatively consistent processing time of each item in that queue and why its important So naturally, I’m going to talk about Maccas
can be very di ff erently sized. So that can make it di ffi cult to accurately assess when it will be done by Explain queing system and impact of large items in the queue or large orders
avg. cycle time + variation) We now have to consider the days remaining as a lower and upper bound. And that upper bound is determined by the amount of variation in your cycle times
How work fl ows through the system Quick anecdote about excalidraw designers and devs Importance of slicing already - mapping out release slices Impact on our projects
that we needed to remove a lot of the variance around our cards. I also wanted to minimise the amount of time spent estimating in a re fi nement session vs outlining the desired customer outcomes. So we needed to learn collectively, how to slice our cards in order to try and make them roughly the same size.
day Learning stuck - great example of short learning cycles More business options and fl exibility, easy to drop a story without the burden of sunk cost. Less time “underwater”, helps prevent assumptions which can lead to bloat
3 days worth of work? - for some folk your smallest unit might be a day, we knew our legacy codebase was going to make stu ff hard * why this works - how much we can think in our head * And those small cards are going to be relatively consistently sized and move through your system of work that much easier * Its a pretty easy thought process / decision which is about how much time I want the team to think about estimation because the rest of the session is more important * Cant under-state how important this was for us. This quick check, if not we discussed and sliced
minimise variation by same sizing things Keep cycle times smaller because easier to process small things - eg easier to review a small PR compared to a large one
I learn most effectively? The answer is often to have many short learning cycles” Above all else I want to optimize the team for learning - that applies as much to creating short learning cycles through slicing at a story level, as it does at an epic, or project level. We want to create more opportunities for learning
that we fi nally made it over the fi nish line Break your work up into small batches and you get to celebrate just about every other week and not feel stressed from being over estimate
estimate more correct, you create dysfunction. By optimising for the queue, we were able to improve how the team worked, and how it felt to be in that team.
Lean software development (an agile toolkit) Spreadsheet Tool Michele’s great talk Neil Killick Allen Holub Mary and Tom Poppendieck’s book Link to spreadsheet there - will share the slides on LinkedIn Linear B - dont love this tool personally but you might fi nd value
ridget
rabernat
apolaine
akashhashmi
addyosmani
codingconduct
hatefulcrawdad
wjessup
greggifford
aleyda
jlugia
bethany
aemeredith
