One of the largest challenges preventing organisations from competing effectively in the market is their structure. When you are optimised for technology or role, then you are not optimised for customer value. But how do you actually get there? What does good look like for your organisation if you went back to the drawing board? I’m going to share a process I’ve developed for redesigning a system for outcome alignment.
Note that this is not going to be a full article on digital transformation or strategic redesign. I am simply going to focus on the guiding principles and a specific approach to assist in exploring an outcome aligned design.
The role of the project manager in Agile is often a complicated one. While there is little concrete direction by many of the frameworks, it is often understood that a traditional project manager may often find themselves moving into a Scrum Master or Product Owner role. The intent behind this guidance is clear, there’s no need for a Project Management Office (PMO) where we’re going. I disagree. Let me introduce the Lean PMO.
A dependency chain is where you have a number of functions that all need to do some part of a piece of work in order to fully deliver it. These functions complete their part and then pass it along to another.
In my last article I showed why your IT requests were likely taking so much longer to service than you expected. But what if you have multiple dependencies chained together? How can you get a rough idea of how long something is going to take when you have a disconnected dependency chain rather than an end to end view of the system. In this article, I’ll explain the process of getting a rough statistical idea of how long something is going to take when you have multiple dependencies all linked together. I’ll explain this through an R script, but the concept is easily transferable.
This Agile game is based on The Penny Game. I’ve seen it in various incarnations, but this is based on the original concept. Instead of simply showing how batch size affects throughput, this game has been heavily modified to give several additional lessons. Attendees can expect to learn about Agile’s roots in Lean manufacturing, batch size theory, single piece flow, being adaptive to change, quick feedback and communication.
Each round after the first is essentially optional, you can choose exactly which lessons you wish to deliver. This may be all of them for more experienced teams, or fewer for those new to Agile.