Every day I take the train to go to work. I notice how groups of people start creating in areas where the doors of the train are expected to open. It must be funny if you look from up above. Imagine a long train platform and groups of people spread in 4-5 meters distance between each-other, all long the platform. Why? Because they expect the train to arrive soon, and based on previous days, they expect the doors to be open at a very short distance from where they start forming groups. The first that gets in, might find a place to sit!
So I made a Mind Map to organize the lessons learned from riding a train, and map them to running software development project.
I can go as literal as I want to, but there are some good areas to learn:
1. Even though a train can go very fast, the speed is limited, to control the timing at each station. It is almost like limiting WIP to have a good pace and be predictable, without extra effort
2. The Project team can be kept at the required minimum (there are 2 staff on the train and some staff at the stations to deal with ticket issuing). Operations are there to make sure everything runs smoothly.
3. There is a good Communication system for emergencies, updates, notifications, etc.
4. There is a map of the route and clear understanding of destination
5. If there are issues, buses run as backup strategy
6. There is a clear Cost strategy, based on the distance
7. Good strategy on Dependencies (a train stops when the train ahead has problems)
And this is from a Canadian train. Imagine how much we can learn from the German train system!!
statcount
Wednesday, 29 May 2013
Wednesday, 8 May 2013
How would I run an Agile transformation: Hamburger style!
I can't say I am "an experienced Agile coach" but I have seen three of them in big scale. In all three, the initiative has been from the Top (CTO, CIO, Department VP) as "Agile is the solution of the issues we are facing". Issues can be different but more or less are always around expenses, ROI, fast delivery and also as a peer pressure since all the successful CIO/CTOs out there are benefiting from Agile tools and practices. So far so good.
Usually, the way it gets executed, it is with project/product teams.They are the first to attack since they deliver what we produce. An outside or internal person that knows about Agile, is assigned to work with delivery teams. There is some work done with Managers as well, to help them understand the new language the people will start using now on.
What I notice is, that after a while, the Top and the Bottom layers are running Agile in their own way with their own expectations, but the layers in between, Managers/Directors/AVPs, are stuck. They are still Managing details, day-to-day operations, Severity 1 issues, approve Gatings, control communications top-bottom and bottom -top, run performance improvements, .....They become bottlenecks and get very busy at it.
I think that the Top layer, needs to understand Agile delivery before they ask for it. As a rule, in an Agile delivery, you hit first the most visible/riskiest feature and then improve/add functionality on it. In an Agile transformation, this feature is seen to be Delivery process and that's why, the whole work of the transformation is done around improving the process, making the process agile.
When I make two steps back, improving the delivery process, is the whole "product" you are delivering in a transformation. Some analysis, story mapping and story breaking need to be done, to understand what is the most visible/riskiest feature of this delivery process you will produce.
And from what I see, it is the Management layer. At the end, even the end delivery process will need to be managed!
So, I would start my Transformation with the Management layer.
At the end, even in an hamburger "the meaty part" is in the middle!
I would :
Maybe this approach will not see the BIG impact right away, but is the incremental way to run a full Agile transformation. By starting with the Management layer, the highest risk "feature" is done first. During that process, we will learn, improve, progress and evolve as per the context of the organization. Then, the rest of the Transformation value comes, incremental and with purpose in mind. By now, managers should know how to manager people, how to create a trusting environment, how to allow test/try/experiments and how to empower people.
Usually, the way it gets executed, it is with project/product teams.They are the first to attack since they deliver what we produce. An outside or internal person that knows about Agile, is assigned to work with delivery teams. There is some work done with Managers as well, to help them understand the new language the people will start using now on.
What I notice is, that after a while, the Top and the Bottom layers are running Agile in their own way with their own expectations, but the layers in between, Managers/Directors/AVPs, are stuck. They are still Managing details, day-to-day operations, Severity 1 issues, approve Gatings, control communications top-bottom and bottom -top, run performance improvements, .....They become bottlenecks and get very busy at it.
I think that the Top layer, needs to understand Agile delivery before they ask for it. As a rule, in an Agile delivery, you hit first the most visible/riskiest feature and then improve/add functionality on it. In an Agile transformation, this feature is seen to be Delivery process and that's why, the whole work of the transformation is done around improving the process, making the process agile.
When I make two steps back, improving the delivery process, is the whole "product" you are delivering in a transformation. Some analysis, story mapping and story breaking need to be done, to understand what is the most visible/riskiest feature of this delivery process you will produce.
And from what I see, it is the Management layer. At the end, even the end delivery process will need to be managed!
So, I would start my Transformation with the Management layer.
At the end, even in an hamburger "the meaty part" is in the middle!
I would :
1- train managers with Agile principles and thinking
2- train managers on how to identify issues in an Agile environment
3- make sure managers understand Trust (they have to go through that themselves before)
4- train managers on how to manager people
5- train managers to have their personal Kanban to control their work
6- give managers chances to test all of the above without dropping the Agile hammer all over the place
And then....
Ask managers to run the Transformation with their teams, starting with organizing the teams according to work flow.
Delivering in an Agile way is the side effect that will come naturally and managed properly.
Subscribe to:
Posts (Atom)