Agile and The Moving Train
Back into the Blogging mood after long years! The reason is simple, I did not have much to share than the mundane stuff that kept on running for the last few years.
I am back because I am now beginning to implement agile development process for a large team and am discovering wonderful stuff as and when I plough through the details of the agile delivery model. There are a lot of anologies that comes to my mind and I will keep writing these as a beginner trying to unravel a new world.
First is an anology that I draw to a moving train. In agile you make timeline constant but scope the welcome variable (which is exactly the opposite in Waterfall), this means how often you deliver to the outside world is constant, but what you deliver is what you play with. A moving traing has stations and their locations constant (where/when) and how many people you move across is a variable. When you start with this basic analogy, there are a lot of things you can draw and ensure various roles are understood.
The overal teams goal is to ensure that they deliver more and more people to various destinations and always on time. This goal can be acheived by a contributor being inside the train or outside the train.
If you are inside the train, you are very much part of the team, and you should ensure you take in as much of scope you can deliver. You should ensure that you are aware of the size of the bogie (team's velocity) you are in and ensure that you do not take more than that and look for various reservations to address priority of the customers you are supporting. You should make sure you call out any impediments you find within your bogie and pull the chain (block a User Story) when you feel you cannot make it happen.
If you are outside the train, you are really making sure you are helping the train move faster from infrastructure perspective, is it well oiled (CI running effectively), is the direction of the train right (vision is matching with the upcoming iteration), are you seeing any impediement coming ahead or for the team and remove these before the train reaches it (US grooming) and and program level impediment.
It is interesting to note that if you keep the time to reach station constant, the engine can run as efficiently as possible with almost no drag. This helps and really helps software development, with respect to development infrastructure, when you test, when you deploy, when you document, when you package and when you release will all be aligned effectively and efficiently.
It will slowly evolve into a very interesting anology for you to stop worrying about right defintion of the process items but help you look at how the team can come on to the same page on their role and how they can support the train to be on time at every station and taking more and more people. My question is simple ' Are you inside or outside?' and that helps you to know how you can help the train.
I will come back to share more anologies I am drawing as I begin to peel the agile model for real.
I am back because I am now beginning to implement agile development process for a large team and am discovering wonderful stuff as and when I plough through the details of the agile delivery model. There are a lot of anologies that comes to my mind and I will keep writing these as a beginner trying to unravel a new world.
First is an anology that I draw to a moving train. In agile you make timeline constant but scope the welcome variable (which is exactly the opposite in Waterfall), this means how often you deliver to the outside world is constant, but what you deliver is what you play with. A moving traing has stations and their locations constant (where/when) and how many people you move across is a variable. When you start with this basic analogy, there are a lot of things you can draw and ensure various roles are understood.
The overal teams goal is to ensure that they deliver more and more people to various destinations and always on time. This goal can be acheived by a contributor being inside the train or outside the train.
If you are inside the train, you are very much part of the team, and you should ensure you take in as much of scope you can deliver. You should ensure that you are aware of the size of the bogie (team's velocity) you are in and ensure that you do not take more than that and look for various reservations to address priority of the customers you are supporting. You should make sure you call out any impediments you find within your bogie and pull the chain (block a User Story) when you feel you cannot make it happen.
If you are outside the train, you are really making sure you are helping the train move faster from infrastructure perspective, is it well oiled (CI running effectively), is the direction of the train right (vision is matching with the upcoming iteration), are you seeing any impediement coming ahead or for the team and remove these before the train reaches it (US grooming) and and program level impediment.
It is interesting to note that if you keep the time to reach station constant, the engine can run as efficiently as possible with almost no drag. This helps and really helps software development, with respect to development infrastructure, when you test, when you deploy, when you document, when you package and when you release will all be aligned effectively and efficiently.
It will slowly evolve into a very interesting anology for you to stop worrying about right defintion of the process items but help you look at how the team can come on to the same page on their role and how they can support the train to be on time at every station and taking more and more people. My question is simple ' Are you inside or outside?' and that helps you to know how you can help the train.
I will come back to share more anologies I am drawing as I begin to peel the agile model for real.
Comments
Very creative anology...this is indeed a great way to explain agile to people who dont understand what it is.