Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Is it done yet? (How about now?)


Published on

No matter how utopian your agile working environment, if you're building a commercial product, at some stage you will be asked the inevitable question - When will it be done? This talk will provide you with tools and techniques to use when you hear your manager say "We just need to get better at estimating".
If you have ever wished for a crystal ball to help you predict the team's future, this talk is for you!

Published in: Engineering
  • Be the first to comment

Is it done yet? (How about now?)

  1. 1. IS IT DONE YET? … HOW ABOUT NOW? MICHELE PLAYFAIR DDD PERTH 2019 Hi Perth! This talk will give you some ideas about tools and techniques to use when you hear your manager say "We just need to get better at estimating". If you have ever wished for a crystal ball to help you predict the team's future, this talk is for you! 1
  2. 2. Many thanks to all the wonderful sponsors that make this event affordable – including YOW!... YOW! Perth coming up in September, come and see us ☺ I would also like to give some love to all the organisers who have ONCE AGAIN done a fantastic job crafting DDD Perth. THANK YOU!!! 2
  3. 3. micheleplayfair#DDDPerth REAL AGILE WORKPLACES DON’T HAVE DEADLINES Once upon a time, when Agile and I were young… I was working in a Agile-ish company, which still had projects, deadlines, and the associated overtime and weekend-free death marches. I figured that if we ONLY did this Agile thing PROPERLY then we wouldn’t have these stupid deadlines and life would be beautiful.... Then I started working for a company that had pretty mature product development, people were experienced and understood agile ways of working and YET we still had some deadlines and end dates!! What is going on??? 3
  4. 4. micheleplayfair#DDDPerth In my case there were government legislation related dates that need to be met, and compliance is not optional if you want to stay in business - I worked on teams that were creating solutions for two of these 4
  5. 5. micheleplayfair#DDDPerth Maybe you’re working to meet another kind of event-related immovable date 5
  6. 6. micheleplayfair#DDDPerth Photo by Pixabay Maybe there’s a race against your competition to get a product to market first – we had that as well! 6
  7. 7. micheleplayfair#DDDPerth Photo by Pixabay Maybe there’s some kind of staffing dependency and you’re going to lose people on a certain date Maybe you announced features to your user base - made a public commitment to customers that you will deliver something. If you do this too often without living up to it, you get…. 7
  8. 8. micheleplayfair#DDDPerth Elon Musk Today – a site entirely dedicated to tracking Elon’s promises made on Twitter!! Hell hath no fury like a customer scorned. 8
  9. 9. micheleplayfair#DDDPerth REAL AGILE WORKPLACES DON’T HAVE DEADLINES … said nobody ever So where did this impression come from?? It’s not in the Agile Manifesto… it says “sustainable pace” but nothing says “we value not having deadlines” I figure there are a couple of factors at play here… First, companies that we’re told have the “best agile working” - like Facebook, Google, Spotify, Twitter, Netflix – I have never seen them make a public commitment to producing a feature by a certain time. The updates just "appear" whether we like it or not. Sometimes in the case of Google products you can go back to the previous version - for a short a/b period, before you're forced to take the latest. And sometimes you just get… 9
  10. 10. micheleplayfair#DDDPerthMing Johanson on LinkedIn 17 Jul 19 This. Cheers Ming for this timely observation!! Does your company work this way or more to the point, is it even possible for them to do this to their customers and stay in business? 10
  11. 11. micheleplayfair#DDDPerth If you could come in on Sunday too, that would be great. Yeah, I’m going to need you to go ahead and come in on Saturday… Second issue is that so many people associate “deadlines” – even the word DEADLINE - with the big push at the date looms closer, where your weekends and your life disappears along with your sleep And like I did, they hope that in a better, more AGILE work environment, this deadline-induced misery would disappear… where’s my sustainable pace?! 11
  12. 12. micheleplayfair#DDDPerth DOES IT HAVE TO BE LIKE THIS? Joshua Partogi on LinkedIn 16 Jul 19 Manifesto for Deadline Driven Development We are uncovering bitter ways of developing software by doing lots of overtime and helping others do it… Manifesto for Deadline Driven Development - We are uncovering bitter ways of developing software by doing lots of overtime and helping others do it… Does it have to be like this? If we take as a given that deadlines – or milestones, or whatever you want to call them – WILL happen…. We need to cope with the idea that sometimes you do need to know WHEN WILL IT BE DONE and IS IT DONE YET? – while avoiding the mini-waterfall death march 12
  13. 13. OBVIOUSLY THE ANSWER IS…. Or is it? Because if we only did this part RIGHT then we would *know* when we would finish! Easy peasy. 13
  14. 14. micheleplayfair#DDDPerth We need to get better at estimating! To many managers, the existence of an estimate implies the existence of an “actual”, and means that you should compare estimates to actuals, and make sure that estimates and actuals match up. When they don’t, that means people should learn to estimate better. (Ron Jeffries) I have heard senior people say this!! Do you really want to spend time getting better at estimating?? 14
  15. 15. micheleplayfair#DDDPerth “ ” WASTE IS ANYTHING THAT DOES NOT ADD VALUE TO A PRODUCT, VALUE AS PERCEIVED BY THE CUSTOMER. Poppendieck – “Lean Software Development” In “Lean Software Development” Mary & Tom Poppendieck wrote that “Waste is anything that does not add value to a product, value as perceived by the customer.” By this definition, time spent estimating is waste and should be minimised with the view to eliminating it. I’m not gonna say NOESTIMATES because that summons trolls – what I will say is that you should spend LESS time on estimating, not MORE. BUT we still need a way to know WHEN WILL IT BE DONE? So what is the alternative?? 15
  16. 16. micheleplayfair#DDDPerth SIMPLE, TRANSPARENT AND PREDICTABLE First goal: We want to make the work as simple, transparent and predictable as possible 16
  17. 17. micheleplayfair#DDDPerth “ ” PREDICTABILITY IS IMPROVED BY BEHAVING AND DELIVERING MORE PREDICTABLY, NOT BY MAKING PREDICTIONS. - Neil Killlick Neil Killick has observed that “Predictability is improved by behaving and delivering more predictably, not by making predictions.” We want to put something valuable into the hands of users sooner rather than later, then iterate on it in a rhythm. Getting regular feedback along the way. 17
  18. 18. micheleplayfair#DDDPerth I’m sure many of you have seen this drawing by Henrik Kniberg before. Assuming in this case what I am trying to do is “get somewhere faster than walking.” I can quickly deliver a skateboard and then get feedback from users which might have been, “I like the wheels idea but I am afraid of falling off and it’s still hard work” - then you next produce a scooter. NONE of these is The Perfect Solution but each is better than the previous. If we only made it to step 3 by the “Deadline” - are we OK? I say yes we are! Note that if we were in a waterfall project, our “requirements” would have most likely been to build the car!! And look where we are at step 3, we can’t use it. Sounds good in theory but how do we actually DO this fast, predictable delivery thing?? 18
  19. 19. micheleplayfair#DDDPerth STORY MAPPING – JEFF PATTON First recommendation, use Story Mapping – this is some real secret sauce and if you haven’t read User Story Mapping I suggest you get your hands on a copy, you won’t regret it. The story map describes what users will do to reach a goal, over time going left to right the same way you would tell a story to someone else. The backbone across the top is made of higher-level activities that represent groups of tasks done at similar times to reach the goal Below that in the body of yellow stickies are the user tasks – short verb phrases – that are a breakdown of the higher level above. Using one of the examples from Jeff’s book, you might have a summary task of “get cleaned up in the morning” and the user tasks might be “have a shower”, “do my hair”, “shave”, “put makeup on” etc What you have now is something that is simple – story to explain what users want to achieve – and transparent – if its on a wall where anyone can see it! 19
  20. 20. micheleplayfair#DDDPerth STORY MAPPING – JEFF PATTON Once you have your map laid out you can identify a set of tasks that could form a goal and literally draw a line under them to form a “slice” – something you could release to a customer to get their feedback Summary – go for GOOD ENOUGH then BETTER then BEST. If you have a deadline work towards getting the GOOD ENOUGH version into your users hands as soon as you possibly can and iterate from there. 20
  21. 21. micheleplayfair#DDDPerth Here’s one from Real Life!! You can see the first major release slice was the “compliance goal” – we used goal instead of deadline as it’s less scary - this was the Minimum Viable Product – the skateboard from Henrik Knieberg’s drawing Next release would have made it nicer for users and added some extra functions – and you get the bicycle Third one was the really awesome bells and whistles one – the car, if you will. We also had smaller slices of bits of it along the way that we gave to users for feedback which was very helpful 21
  22. 22. micheleplayfair#DDDPerth “EASY AGILE STORY MAP FOR JIRA” This is a 3rd party add on called “Easy Agile Story Map for JIRA” - I assume there are people here using JIRA? (if anyone boos – you don’t hate JIRA, you hate whoever configured it at your workplace and maybe the managers who think it’s magical!) Physical boards are awesome for planning but if you use JIRA I really recommend getting this little add-on to storymap inside JIRA eg for remote teams or places where the dang board is too big for the wall or to match JIRA to your physical board. It Just. Makes. Things. Easier. 22
  23. 23. micheleplayfair#DDDPerth STORY POINTS So now we’ve got our map of user tasks / stories to work with. I was really bothered about all the time spent in meetings arguing about whether a story is a 3 or a 5 – and don’t even get me started on the constant conversions to and from points and time “umm so if that takes a week it will be a 3”, “we’ve got a total of 9 points so that’s.. What, 2 weeks? 3?” It just seemed like a waste! But you NEED story points if you’re going to be agile, right? 23
  24. 24. micheleplayfair#DDDPerth STORY POINTS - ? Then I saw this from Ron Jeffries talking about how to size stories: 1, 2, too big – days not points. And I thought – yeah that sounds better Who’s Ron Jeffries? 24
  25. 25. micheleplayfair#DDDPerth STORY COUNTS NOT STORY POINTS He’s the guy who may have invented Story points and has been apologising since for how they are misused. Break the work down into stories as small and uniform as possible, try for consistent sizing – 1 or 2 days - and just get on with it. It won’t be perfect but it will be good enough! Rule of thumb from Neil Killick is for each story to fulfil a single acceptance criterion. Once you have started the habit of working on small stories and each story is close to the same size, you can COUNT them instead, and being predictable is much easier… And YES! You can configure JIRA to use card counts instead of story points or time. 25
  26. 26. micheleplayfair#DDDPerth THROUGHPUT & CYCLE TIME Work Started Work Completed (In Production) Throughput = Number Stories Completed per Iteration Sprint 1: Sprint 2: Sprint 3: Cycle Time Cycle time – this is the average time that it takes something to get from the start to the end of a process. In development it’s often the time that something moved to “In Progress” up until it’s “Done Done” or Released. Throughput = units of work per unit of time. In this case, Throughput is the number of DONE stories completed by a team per week or per sprint. According to the theory of constraints, the best way to optimise is to focus on throughput. Teams with shorter cycle times are likely to have higher throughput, and teams with consistent cycle times across many issues are more predictable. So that’s the aim. 26
  27. 27. micheleplayfair#DDDPerth CYCLE TIME (CONTROL CHART) For those of you in JIRA land this is the Control Chart where you can check on your team’s cycle time. This particular specimen is not great (1 week average!) When your cycle time is consistent the green dots will be closer together and the shaded area will be thinner… also you probably want to make your cycle time lower! 27
  28. 28. micheleplayfair#DDDPerth FORECASTING Forecasting - Once we’ve started to become predictable, we can more safely assume that our past performance is a reasonable indicator of how things will go in the future. So for example in Brisbane in summer you can reasonably safely say that tomorrow’s weather will be “hot, chance of rain” – but in Melbourne, not so much. Bearing in mind of course that this is all a model and all models are wrong, but some are useful. Now there are a number of ways to do this – here is an example of a burndown chart from our friend JIRA where it has predicted based on your team’s previous velocity, that there are 6 sprints remaining. This is OK but we can do better. 28
  29. 29. micheleplayfair#DDDPerth PROBABILISTIC FORECASTING Probabilistic forecasting for weather might be “what is the chance of rain tomorrow?”. In the forecasting software world, this is normally “what is the chance of finishing on or before date x.” In a probabilistic forecast we look at what percentage of the possible results were actually “on or before date x.” This allows us to say things like, “We are 85% certain to deliver by 7th August.” Good news is that probabilistic forecasting relies upon the input parameters being non-exact. 29
  30. 30. micheleplayfair#DDDPerthPhoto by Tumisu Using Arthur C Clarke’s 3rd law – any sufficiently advanced technology is indistinguishable from magic – this brings me to the crystal ball I promised you!! This link will take you to a github repository full of amazing resources related to forecasting and modelling from Troy Magennis of Focused Objective The tool I used from this treasure trove for PROGNOSTICATION is the Throughput Forecaster. This sheet has a lot of features that duplicate some of the things you can get directly out of JIRA so even less work for you – yay I set up filters on the JIRA board that let you easily see the story counts per release so we could track to complete for each milestone/goal/deadline and then you can just add them to the sheet. 30
  31. 31. micheleplayfair#DDDPerth TEAM 1 It’s also pretty flexible, I used it with 2 teams that were working in different ways – so here’s some data input for team 1 Team 1 - we did a Tshirt sizing (Small, Medium, Large) on future stories which will give us the max-min number to use in “How many stories remaining to be completed”. For the min we assume that a Large/Spike will eventually break up into 3 stories, a Med into 2 and a small = 1. For the max, Large/Spike = 5, Med = 3, small = 1 - Therefore the low and high on splitting is the same at 1 – because we already included the variance in the stories to complete. - used kanban not sprints so we did this per week - Used historical Data – I got the number of completed stories from the “Created vs Resolved” issues report and just entered them into another sheet. - If you didn’t have that you could put a low-high guess in the fields at the bottom AND YOU GET… drumroll 31
  32. 32. micheleplayfair#DDDPerth What is this witchcraft?? It’s a Monte Carlo simulator – using statistics and probability to help visualise potential outcomes. In this case the simulator will forecast how long it will take to complete features based on the data entered - Using this information it hypothetically completes the work 500 times and shows you the likelihood of success by date. For us this was such a valuable output for such little work to create. Essentially we’re estimating CONFIDENCE as well as TIME 32
  33. 33. micheleplayfair#DDDPerth Simple, transparent and provides an indicator of our predictability!! Thanks Troy! 33
  34. 34. micheleplayfair#DDDPerth THE TL;DR 1. Deadlines happen 2. Spend less time estimating, not more 3. Use storymapping (even in JIRA) to break up and visualise the work 4. Story counts, not story points 5. Focus more on throughput & cycle time 6. Try the Throughput Forecaster – estimate confidence as well as time 1. Deadlines happen 2. Spend less time estimating, not more 3. Use storymapping (even in JIRA) to break up and visualise the work 4. Story counts, not story points 5. Focus more on throughput & cycle time 6. Try the Throughput Forecaster - estimate confidence as well as time. 34
  35. 35. micheleplayfair#DDDPerth THE DISCLAIMER These are things that we tried and they worked for us – please don’t do the SPOTIFY MODEL thing and think this is what you HAVE to do! I hope I have given you some ideas and a starting point - Do a bit more research, experiment, tweak – INSPECT AND ADAPT 35
  36. 36. micheleplayfair#DDDPerth FOR MORE INFO – SEE THE WORKS OF: ➢ Jeff Patton ➢ Troy Magennis ➢ Ron Jeffries ➢ Neil Killick ➢ Mary & Tom Poppendieck ➢ Gojko Adzic ➢ Johanna Rothman If you want to know more about how to manage your work in an agile way while still dealing with the reality of WHEN WILL IT BE DONE?? and IS IT DONE YET?? Look into the books and posts done by Jeff Patton, Troy Magennis, Ron Jeffries, Neil Killick, Mary & Tom Poppendieck, Gojko Adzic and Johanna Rothman 36
  37. 37. IS IT DONE YET? … YEP 37