The Process Ladder- UP, RUP, EUP, PLE, & Never Neverland
I have had the experience to work in one shop that did XP, and did it for real. It was a small shop with a very, very, sharp team. Communication was constant, and short meetings were happening all the time. TDD was really TDD and not just tests written after they were done coding the modules for regression testing purposes. Pair programming was a way of life. It was fast paced and the adrenaline levels had to be kept high. Documentation was created, Agile Modeling was used, and it was an awesome sight to see. After seeing that way of doing things however, I know that most development shops can not pull it off. The skill sets are not available, and management doesn't provide the tools needed to create such an environment. Plus there are very few project managers with the skill sets available that can run such a shop.
Most shops I go into do not have an industry standard process like the UP, SCRUM, or the RUP. When asked about their process they default to saying they are an agile development shop using XP. Well, in reality they are developing by the seat of their pants and have absolutely no development process. They are living in Never Neverland. They do the task list presented to them at the beginning of the day or week, and next day or week figure out what that task list broke in other areas of the application. Patch all that up over the next few days or weeks, and then start on their next task list. It works for them because they have never been exposed to any other way of doing things. Many of them have had bad experiences with industry standard development processes and they have written them off as fairy tales, or textbook processes. Good for learning about, ok to market with, but they don't believe they really work.
A lot of these places with no process will lay claim to having their own home brewed process that they came up with during the dotcom boom when every company was doing that. Companies were thrust into software development without knowing that was even what they were doing. You will usually find a page or two describing their process on their web site at a very high level, with a few colorful images with loops and arrows. If however you go into the company and ask to see their documented process, they will have nothing more to show you, or they will pull a dusty fat binder off the shelf with a ton of post-its sticking out of it that say, needs completed.
There is hope for such places. I have had the opportunity to move several development shops out of Never Neverland into a real world process. The type of projects the company wins contracts for will determine the process to which you will want to move to on the process ladder. You also need the skill sets of the team members to change as you move up the ladder, or you need to change the team members. A lot of educating is involved with these climbs, as well as a lot of un-educating. In other words, getting teams to forget the way things were done in the past.
Keep in mind that a development process is NOT a one and done deal. Every project should start with the planning of the process that will be instanced for a given project. Meaning that there will be different levels of ceremony for every project, there may be different team member experience levels, the projects will always be different, and the process should be shaped to the individual projects. Anyone that tells you one process instance is used for all their projects is telling you that to build a tree house, a 4 bedroom home, a shopping mall, and a hospital, can all be done by the same team, with the same resources, the same effort, and the same amount of planning. They are living in Never Neverland.
So with that said, I want to make sure that the process ladder diagram below is understood. The different levels of process are levels at which processes are performed, but each project would always get a new instance of a process. The current move I am taking a company through is from Seat of your pants development to Product Line Engineering (PLE). A very big transition that is going to take a long time, a lot of educating and training, and a large upfront investment of time and money.
Image 1: Process Ladder (Shift Click Image for Larger View)
SharePoint Team Site
One tool I found to be valuable during these process implementations is SharePoint. SharePoint makes a good tool for a development team repository. For every project I put together a team portal. It houses our process definition, asset templates, work spaces for individual workflows that are part of the process, discussions, and educational resources for team members.
Process Definition:
A visual representation of our process along with detailed information that explains the different workflows of the process.
Asset Templates:
These are housed in Document Libraries. The different Document Libraries included templates for such items as Business Analysis Assets, Architectural Assets, Analysis and Design Assets, Development Assets, Testing Assets, Project Planning Assets, and Estimation Assets. They are arranged and housed according to the process phases.
Each of these Document Libraries include guidelines for the use of the assets they house.
As we move into different workflows, sub sites will be created. The same structure of the Document Libraries are used, but they house completed assets for that particular workflow.
Work spaces for individual workflows:
These are used by different individuals that are filling the roles assigned to that workflow and are working on assets produced by that workflow. This is were they keep completed assets for the rest of the team to access them.
Discussions
These are used at the top level site and the sub sites (individual workflows) to maintain on going discussion about the current activities. This is much easier than following email threads.
Educational Resources:
There will be a lot of things that will need to learned depending on the experience of different team members. This area contains links to learning resources, white papers, videos, and other things to help them get familiar with it.
This takes a lot of effort to put together, but the ROI is always well worth it. New developers to the team can become quickly educated on the process and where we are with it. It also helps with educating the companies current developers, managers, marketing team, and sales team on where the company is headed.
Most shops I go into do not have an industry standard process like the UP, SCRUM, or the RUP. When asked about their process they default to saying they are an agile development shop using XP. Well, in reality they are developing by the seat of their pants and have absolutely no development process. They are living in Never Neverland. They do the task list presented to them at the beginning of the day or week, and next day or week figure out what that task list broke in other areas of the application. Patch all that up over the next few days or weeks, and then start on their next task list. It works for them because they have never been exposed to any other way of doing things. Many of them have had bad experiences with industry standard development processes and they have written them off as fairy tales, or textbook processes. Good for learning about, ok to market with, but they don't believe they really work.
A lot of these places with no process will lay claim to having their own home brewed process that they came up with during the dotcom boom when every company was doing that. Companies were thrust into software development without knowing that was even what they were doing. You will usually find a page or two describing their process on their web site at a very high level, with a few colorful images with loops and arrows. If however you go into the company and ask to see their documented process, they will have nothing more to show you, or they will pull a dusty fat binder off the shelf with a ton of post-its sticking out of it that say, needs completed.
There is hope for such places. I have had the opportunity to move several development shops out of Never Neverland into a real world process. The type of projects the company wins contracts for will determine the process to which you will want to move to on the process ladder. You also need the skill sets of the team members to change as you move up the ladder, or you need to change the team members. A lot of educating is involved with these climbs, as well as a lot of un-educating. In other words, getting teams to forget the way things were done in the past.
Keep in mind that a development process is NOT a one and done deal. Every project should start with the planning of the process that will be instanced for a given project. Meaning that there will be different levels of ceremony for every project, there may be different team member experience levels, the projects will always be different, and the process should be shaped to the individual projects. Anyone that tells you one process instance is used for all their projects is telling you that to build a tree house, a 4 bedroom home, a shopping mall, and a hospital, can all be done by the same team, with the same resources, the same effort, and the same amount of planning. They are living in Never Neverland.
So with that said, I want to make sure that the process ladder diagram below is understood. The different levels of process are levels at which processes are performed, but each project would always get a new instance of a process. The current move I am taking a company through is from Seat of your pants development to Product Line Engineering (PLE). A very big transition that is going to take a long time, a lot of educating and training, and a large upfront investment of time and money.
Image 1: Process Ladder (Shift Click Image for Larger View)
SharePoint Team Site
One tool I found to be valuable during these process implementations is SharePoint. SharePoint makes a good tool for a development team repository. For every project I put together a team portal. It houses our process definition, asset templates, work spaces for individual workflows that are part of the process, discussions, and educational resources for team members.
Process Definition:
A visual representation of our process along with detailed information that explains the different workflows of the process.
Asset Templates:
These are housed in Document Libraries. The different Document Libraries included templates for such items as Business Analysis Assets, Architectural Assets, Analysis and Design Assets, Development Assets, Testing Assets, Project Planning Assets, and Estimation Assets. They are arranged and housed according to the process phases.
Each of these Document Libraries include guidelines for the use of the assets they house.
As we move into different workflows, sub sites will be created. The same structure of the Document Libraries are used, but they house completed assets for that particular workflow.
Work spaces for individual workflows:
These are used by different individuals that are filling the roles assigned to that workflow and are working on assets produced by that workflow. This is were they keep completed assets for the rest of the team to access them.
Discussions
These are used at the top level site and the sub sites (individual workflows) to maintain on going discussion about the current activities. This is much easier than following email threads.
Educational Resources:
There will be a lot of things that will need to learned depending on the experience of different team members. This area contains links to learning resources, white papers, videos, and other things to help them get familiar with it.
This takes a lot of effort to put together, but the ROI is always well worth it. New developers to the team can become quickly educated on the process and where we are with it. It also helps with educating the companies current developers, managers, marketing team, and sales team on where the company is headed.
posted by tadanderson at 8:04 AM
0 Comments:
Post a Comment
<< Home