If you could travel back in time and change one thing in a delivered project, what would it be? I spent my last two years working on a major digital transformation project. The project was delivered using at its peak a project team of about sixty team-members, organised in nine teams across two geographical locations. We’ve used Kanban, ran a #NoEstimates approach and relied heavily on Lean product management concepts. It was what I consider a fairly successful project. We delivered regularly working software (deploying to production multiple times per week), we engaged well with the client, we learnt and got things done. As the project ramped down for me, it felt natural to look back and reflect. Were we as successful as we could have been? Could we have done more? What was the ‘ ’ that done differently it would have made the biggest impact? That one thing. one thing Maybe the question is not the right one, maybe you should not look for only one thing to improve and maybe improving loads of small things creates that significant impact. If you would tell me that I wouldn’t disagree with you, however I was determined to find the most impactful ‘thing’. I spent quite some time thinking about it. Could we have tweaked more our Kanban method? Could we have had more collocated Product Owners? Could we have identified our risks sooner? Yeah, maybe all of the above would have helped, but none of them would have been the ‘one thing’ I’m looking for, the one thing that would have made the biggest impact. After a number of sleepless nights, it dawned to me — that one thing that would have made the biggest impact was a . OK, just kidding on losing sleep over it … better decision making process Throughout a day hundreds of micro decisions were made. What should I build first, this story or that story? Should I start a new story, or should I do a bit of refactoring? When should we release, today or tomorrow? Is this story really needed for this release, or can it wait for another release? Can it wait another fortnight? Which feature should we build first? Do I need extra people for the user research, or what I have is enough? For a project of over five hundred working days, with a team of around sixty members, that amounts to a lot of decisions. With so many decisions, it was not surprising that some of them were not understood by the wider team, some were disputed, some disappointed. And, at times some wrong decisions were made. Decisions are triggers of our actions. We act based on what we decided. Take a wrong decision and you create a lot of wasted effort. Make a decision that is not well understood and you have a lot of displeased team members whose morale will be negatively affected. And that had a significant negative impact. So how can we make better decisions? First of all, we need to understand when we are really in a position to make a decision. Ronald A. Howard, quoted by Sam Savage in his book “Flaw of Averages”, put it succinctly: The three elements of any decision are alternatives, information and preferences. Like a three legged stool, if any of these is missing we don’t really have a decision .— Ronald A. Howard This is an important aspect to acknowledge. Paying attention that all elements are present in the decision making process is key. All too often decisions are made on preference alone. Assuming that we are in position to make a decision, then how can we improve the decision making process? Making all the decisions centrally by a person or a group of people it is just not feasible. What about defining all the rules upfront and giving each team-member a rule book? This approach doesn’t seem too appealing either. The rules would impose too many constraints, likely they would not be exhaustive (could you define all possible instances of action?), hard to maintain and difficult to introduce at scale. How about a ? Daniel Kahneman in his best-seller “Thinking, Fast and Slow” defined heuristics as “ ” heuristic based approach a simple procedure that helps find adequate, though often imperfect answers to difficult questions. Dave Snowden talks about the use of heuristics in a Cynefin context [2]. He cites the US Marines who rely on heuristics when the original battle plan breaks down — “ capture the high ground, stay in touch and keep moving”. A good heuristic should be easy to comprehend and easy to with it. For instance, in the US Marines case it is easy to measure if the heuristic was followed or not — ‘have you captured the high ground?’ This is an easy assessment. measure compliance The goal of each project then would be to define a set of heuristics specific to its context. Once defined they would form part of the team’s doctrine (in the same way they are part of the US Marine doctrines) and teams would use it to derive decisions. As an example, a set of heuristics could look something like this: on items which are work only part of your work-in-progress. work-in-progress items. Therefore, before we start working on a new item we check the age of all the items. We select the oldest one we can deal with. work on the oldest , but understand that cost of gathering the information should not exceed the value of the information itself. Therefore, in face of uncertainty we seek ways to reduce it by doing first the activities that will give us the information (as long as they are in WIP). value buying information . Therefore, we will prioritise activities that will give us the fastest route to gain benefits. value cost of delay over solution purity . Therefore before starting any activity we ask ‘why’ are we doing this? question why we are doing the work We will be able to easily measure if we followed the heuristic or not, if we are compliant with it. For instance we can ask ourselves, ? This should be a very easy question to answer. “have we worked on the oldest work-in-progress item” As Daniel Kahneman stated, heuristics don’t offer guarantee of success in all situations. Equally, in the US Marines case by following the heuristics success won’t be always guaranteed. However, what heuristics offer is an ability to move forward in a coherent fashion — as long as all team-members use the same heuristics they should arrive to the same decision, understand how and why the decisions have been made. If the heuristics stop working, then they would focus on finding new heuristics. And don’t forget about the three legged stool. Maybe you are not even faced to make a decision. Yeah, if I could go back in time this is what I’d change. I’d look to improve the decision making process. I can’t go back in time but I will have a chance to do something about it in a new project. These doodling mean nothing of course. I did them unconsciously while making some decisions. [1] Sam, Savage (2009). The Flaw of Averages: Why We Underestimate Risk in the Face of Uncertainty [2] http://cognitive-edge.com/blog/cynefin-dynamics/

Keep

Blues jamming and Agile

Kanban or TOC, which came first?

Read My Stories

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

Decisions

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

A mechanism for building a roadmap

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

10 Product Development Traps

A mechanism for building a roadmap

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

10 Product Development Traps

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps