How long it will take?!
Forecasts.Estimates.Deadlines.Sadlines.
I do believe you received this question many many times, more than you would like if you are project/product/delivery manager and to no surprise these days — it doesn’t matter what is written down under your name right next to the job title bit — people just decided that this is the only question they need to ask. At some extent, you are lucky if people still do ask. Sometimes it is a decision made out of absolutely no idea, so just that the box — deadline can be ticked and for that, it doesn’t matter what your job title is either!
It is a constant battle that everybody loose and the new day comes and the battle starts again. It is very sad to see that this goes over and over again and there is this all stress created for many, not the few. Through all the experience in different teams, I heard about story points, T-shirt size, even sweet size! People with loads and loads of experience were cracking their heads together to come up with the size of the story and how long it would take to implement it. Just a year ago I joined team who is using Kanban. And I was wondering the first few days where is those cards with story points or any indication of how these get estimated. I was pleasantly surprised that there is another option that you can use and apply in your day to day life. Confidence + range=forecast.
People on TV when they tell you what the weather will look like they don’t just go, hm I think tomorrow will rain and then the person next to them says oh no no look at the sky it will be sunny tomorrow! No. They go through tremendous amounts of data to work out what will happen in the next few days. You can’t possibly tell people that it will be sunny and actually it appears to be a storm outside! And that is what Kanban uses to predict how long it may take to complete one or another story or fix. Collecting data takes time. To improve that data takes time. To understand the factors why something changed takes time and it involves a lot of events around us. Did we do something like that before? Is the story sliced well or there is something we missed in discovery? Did we rushed through some stories, but therefore introduced defects that appear on different metrics? But the indicators are there. There are many tools these days that can help you to load your data and observe the results. It depends on how confident do you want to be? 50%/85%/95% for a stretch? Choosing the right confidence level is down to you and your team. But looking at numbers than you can say with 85% confidence we will deliver this item in 14 days or less! This is a very different approach for usual giving exact days type of thing. When someone asks how long it will take and you say 5 days, all they do they count from that moment 5 days and mark in their calendar the day the feature/fix suppose to be delivered. You just signed yourself a deadline. With the confidence approach you are using the data that your team produced in some amount of time and you can choose how confident you want to be. By saying to a customer it will take 14 days or less they could still write that date in their calendar as deadline, but it could mean you will complete it quicker and that will build confidence and trust between you and your customers. Giving some sort of date and then not meeting the expectations — is not something that helps to build a positive team culture. Giving a range — opens the opportunity to succeed.
There will be times that a story or two will breach the confidence level, something unexpected will happen because that is normal. Building and integrating with new API is not exactly the same as to add a button on the web page. People need to understand that building software is not about how quickly person types. Is about the best solution to building it. Quality. Does anyone remember that word? Quality is something that will just add and support your confidence. Quality is something that will not put you in the even deeper technical dept. There is absolutely no way to tell exactly how long something will take when you are constantly building something new. When it constantly having different dependencies. When it is constantly changing because that is what is happening today in technology. There is a question you need to ask yourself and your boss who is desperately waiting there for dates — do you want me to build you a crap which will lead to many problems in the future, or you want me to build something you will be proud of, but it will take time.
In the beginning of year I took a challenge with my manager to read 25 books. Year has 52 weeks so we thought with a book every 2 weeks we will have 2 weeks to spear. It was a brilliant idea and I can’t be thankful enough to Sam Lewis for suggesting this! It helped me build my experience and understanding on a day to day basis. I found quite a few answers and suggestions. My main goal was to read as close as possible to Kanban, product, agile in general, but I didn’t push away a few books that came along just by talking to people. It was the best way to use up my time every morning traveling by bus. At first, I thought this will be impossible. I thought about 20 books maybe but 25 is a bit too much. There were big books and small books, thin books and fat books.. When I started I had no idea how long a 300 page book would take me, I knew I had a deadline — 2 weeks. But it was impossible. With only time to read on the way to work for 35 min and maybe another 20 min during lunch, it was still not enough time. Today, when I am reading my 25th book and its 15th of November I can tell you that Sam was using his confidence level very well. Not all books were the same size, therefore one took 2 weeks, another took 3 weeks and I think one I managed to read in less than 7 days! (It was more of a personal choice that was close to how I was feeling and I really wanted to find the answer). In this case, I had 25 books and a range of 52 weeks with the possibility to spare 2 for Christmas break :) but actually I will have way more to spare if I decide to stop here. I know that to finish this book it will take me 5 or less days. Because now I have experience. I did something like that in the past. Because I built my confidence level. Unless someone would throw at me a 600page book on my table and ask me when I will finish, it would be different, because I never read such a big book before, but still, I would have some sort of indication when approximately I will be done. But it wouldn’t be 2 weeks. That would be a sadline to declare.
In case anyone is interested these are the books that I read this year:
1. ‘Actionable Agile Metrics for Predictability’ — Daniel S. Vacanti
2. ‘Black box thinking’ — Matthew Syed
3. ‘Agile Project Management with Kanban’ — Eric Brechner
4. ‘User stories applied’ for Agile software development — Mike Cohn
5. ‘Sprint — solve big problems and test new ideas in just 5 days’ — Jake Knap
6. ‘Kanban in action’ — Joakim Sunden and Marcus Hammarberg
7. “Lost connections’ — Johhan Hari
8. “Kanban — Successful Evolutionary Change for Your Technology Business” — David J. Anderson
9. “Kanban Maturity Model — Involving fit for purpose organizations” — David J Anderson; Teodoro Bozheva
10. “Specification by example” — Gojko Adzic
11. “DevOps and Microservices handbook” — Stephen Pleming
12. “Everybody lies. What internet Can tell us about who we really are’’ — Seth Stephens-Davidowitz
13. “User story mapping” — Jeff Patton with Peter Economy
14. “Escaping the build trap” — Melissa Perri
15. ‘Agile retrospectives — making good teams great again’ — Esther Derby, Diana Larsen, Ken Schwaber
16. “Powerful — Building culture of freedom and responsibility’’- Patty McCords
17. ‘Accelerate Building and scaling high performing technology organisations’ — Nicole Forsgren, Jez Humble and Gene Kim
18. ‘The lean startup’ — Eric Ries
19. ‘Practical Kanban’ — Klaus Leopold
20. ‘Product Leadership — how top product managers launch awesome products and build successful teams’ — Richard Banfield, Martin Eriksson and Nate Walkingshaw
21. “Right to left — the digital leaders guide to Lean and Agile” — Mike Burrows
22. “Start with Why” — Simon Sinek
23. “rethinking agile — Why agile teams have nothing to do with business agility” — Klaus Leopold
24. “Strong style Pair-programming” — Maarte Pyhajarvi
25. “Fit for purpose” — David J Anderon and Alexei Zheglov
As you will see not all of them scream Agile! But it was the right choice. There are many more. You read one you get a recommendation for many more and because you read the book that you thought was good you trust that recommendation and get another one. I know I will not take the same challenge next year. But I know that I will not stop. No one can take away what I learned during this time. And I hope that some things can be implemented at some point in time when people are ready.
Many businesses these days work with their customers who are still working in a waterfall approach. It is a constant challenge. But if you will not take an action, you will find yourself in constant battle. There are ways to communicate and educate your customers on how software development works. How to build together something that everybody will love and use instead of just blindly put some stuff together and hope for the best. There is a way to explain how you work and build that trust step by step. Nobody likes to change. And nobody said it will be easy. But hey, maybe it is a good challenge if you never did this before and wonder how long it will take..?
