When I first heard about Extreme Programming back about 5 years ago and poked around its practices, I recognized the On-site Customer as one that I had done before back in 1992-1993 and found it very beneficial. So, I decided to get together with my manager from those days to discuss the motivation for co-location, when conventional wisdom at the time was to keep the bloody Customer as far away from the developers as possible in order not to disturb them!
I started off the "interview" with a request for a history lesson on the creation of the Whole Team. What ensued was a description of Agile Development that was only missing automated tests.
This project started in late 1987, and was for a public sector organization's HR system. It was intended to handle functions such as classification, staffing, staff relations, and training, and would be written in PowerHouse on a Data General mainframe. My old manager decided at the time that he was tired of having 2 roles in charge of the project - the Customer in charge of the requirements and providing the funding, and the IT group in charge of building the system. The Customer would throw their requirements together and hand them to the IT group to be implemented. When, 18-24 months later, the system didn't do what the Customer wanted, IT became the scapegoat.
Additionally this manager felt, and continues to feel, very strongly that a good overall multidisciplinary team was essential to success. So, he pushed hard to be placed in charge of all people who would work on the project. This wouldn't mean that people would change the actual reporting relationships, but rather that while working on the project they were part of his team. These people included the development team and the business or domain experts, which was the departure from the past. He was given complete control over how the team worked, and how the system would be developed and deployed. He had already realized that the absentee Customer was a non-started, so he insisted that the development team and Customer sit together - the On-site Customer.
The next step was to figure out what to build. The development team sat down with the assembled domain experts for the different parts of the HR process. They started by talking about the first event in the process of hiring someone, and then stepped through that process to retirement. This wasn't done at a ridiculously detailed level, but rather in terms of the titles of the different steps in the process. With these basic steps in place, this group then determined what part or module of the system needed to be built first. Bear in mind that most of these modules were quite dependent on the others - you couldn't build one and leave the others as manual processes. Regardless, the development was broken down into these modules so that development would be focused, and in order to minimize the risk that the system as a whole would never ship.
For that first module, the development team really didn't have a concrete idea of how big it was, or how long it would take to develop. They knew it wasn't too big, and that there wasn't much risk that they wouldn't be able to develop it at all. They communicated all of this to the Customer, which was another departure from tradition at the time. The development team, mainly the manager also explained that this first module would very much be a learning experience, and would likely be completely rewritten over time. They essentially performed the Planning Game, and Refactoring.
So, the team built that first module, and it took a bit longer to build than they anticipated. However, the Customer was kept in the loop at all times and could see the progress of that first module. When it was completed, the team and the Customer sat down to review how things went (a retrospective) and to plan for the next module (Release Planning). The team had learned quite a bit, and shook out a lot of issues along the way. Even though they hadn't actually shipped anything to production, they had already built up trust with the Customer.
When they started planning the work on the next module, they had the domain experts of the each of these modules in the room. The expert for the first module was asked, "On a scale of 1 to 10, how big would you say that module is in the overall HR process?" The person answered, "Three." They then asked the expert for the second module, "How big do you think this next module is?" They responded, "Nine." With that answer, the team then estimated that developing the new module would take 3 times as long as the first. Forget COCOMO, forget Function Points, they just tripled their time based on the Customer's evaluation of how big in a relative sense the next module would be. The time estimate and budget for the new module were based on Yesterday's Weather. And, they were right. Remember, this was 1988!
This process was repeated for each of the mandatory modules, and the system was placed into production in late 1989 or 1990. The full production cycle had taken 2 years, but the Customer (in the form of domain experts for each module) had been involved from start to finish.
I didn't actually join the team until early 1992, when I was hired on contract to evaluate the progress on a stand-alone interim version of the training module being developed in the same general group as the main HR system, but as a separate product. After a day or two I recommended a rewrite, and found myself the lucky winner of the contract to perform that work! I was immediately placed in a desk in close proximity to the Customer for the system, and worked very closely with her over the next few months to build it.
The interesting thing about that training system is that it had been intended from the start to be included in the main HR system. However, it wasn't a core part of the HR process, and it never reached a priority level required for it to be incorporated. Again, the organization as a whole identified the modules, and prioritized them according to the overall business value. For the training module, it could provide equal value in an interim, desktop system while the main team focused on the higher value modules. (As an aside, that training system was called ITS - Interim Training System - and was first released in 1990. In 1995 or 1996, I finally convinced people that the 'I' should be changed to mean something other than Interim so it became the Integrated Training System!)
Meanwhile, the main system was having releases to production every 8-12 months. When the government department for which the system was built merged with a larger department in 1993, it was decided that this system would be the HR system for the new department. In 1995, PeopleSoft arrived on the scene and was to replace what was now perceived as an old, character-based mainframe system. The head of HR (the Gold Owner) made it abundantly clear that PeopleSoft wouldn't replace the system until it provided the same level of functionality. PeopleSoft, the last I heard, is slated to roll into production in 2007.
So, I came away from my meeting this morning with a renewed sense that I had been part of something quite special, although I didn't consciously know it at the time. Many of the development practices from XP/Agile such as automated testing and true iterative development weren't done, but the overall team practices were. We had the On-site Customer, Planning Game, Frequent Small Releases, Collective Ownership, Refactoring (although not in the modern sense), and Sustainable Pace (there was overtime, but not all that often).
We were successful. We were Agile!
I started off the "interview" with a request for a history lesson on the creation of the Whole Team. What ensued was a description of Agile Development that was only missing automated tests.
This project started in late 1987, and was for a public sector organization's HR system. It was intended to handle functions such as classification, staffing, staff relations, and training, and would be written in PowerHouse on a Data General mainframe. My old manager decided at the time that he was tired of having 2 roles in charge of the project - the Customer in charge of the requirements and providing the funding, and the IT group in charge of building the system. The Customer would throw their requirements together and hand them to the IT group to be implemented. When, 18-24 months later, the system didn't do what the Customer wanted, IT became the scapegoat.
Additionally this manager felt, and continues to feel, very strongly that a good overall multidisciplinary team was essential to success. So, he pushed hard to be placed in charge of all people who would work on the project. This wouldn't mean that people would change the actual reporting relationships, but rather that while working on the project they were part of his team. These people included the development team and the business or domain experts, which was the departure from the past. He was given complete control over how the team worked, and how the system would be developed and deployed. He had already realized that the absentee Customer was a non-started, so he insisted that the development team and Customer sit together - the On-site Customer.
The next step was to figure out what to build. The development team sat down with the assembled domain experts for the different parts of the HR process. They started by talking about the first event in the process of hiring someone, and then stepped through that process to retirement. This wasn't done at a ridiculously detailed level, but rather in terms of the titles of the different steps in the process. With these basic steps in place, this group then determined what part or module of the system needed to be built first. Bear in mind that most of these modules were quite dependent on the others - you couldn't build one and leave the others as manual processes. Regardless, the development was broken down into these modules so that development would be focused, and in order to minimize the risk that the system as a whole would never ship.
For that first module, the development team really didn't have a concrete idea of how big it was, or how long it would take to develop. They knew it wasn't too big, and that there wasn't much risk that they wouldn't be able to develop it at all. They communicated all of this to the Customer, which was another departure from tradition at the time. The development team, mainly the manager also explained that this first module would very much be a learning experience, and would likely be completely rewritten over time. They essentially performed the Planning Game, and Refactoring.
So, the team built that first module, and it took a bit longer to build than they anticipated. However, the Customer was kept in the loop at all times and could see the progress of that first module. When it was completed, the team and the Customer sat down to review how things went (a retrospective) and to plan for the next module (Release Planning). The team had learned quite a bit, and shook out a lot of issues along the way. Even though they hadn't actually shipped anything to production, they had already built up trust with the Customer.
When they started planning the work on the next module, they had the domain experts of the each of these modules in the room. The expert for the first module was asked, "On a scale of 1 to 10, how big would you say that module is in the overall HR process?" The person answered, "Three." They then asked the expert for the second module, "How big do you think this next module is?" They responded, "Nine." With that answer, the team then estimated that developing the new module would take 3 times as long as the first. Forget COCOMO, forget Function Points, they just tripled their time based on the Customer's evaluation of how big in a relative sense the next module would be. The time estimate and budget for the new module were based on Yesterday's Weather. And, they were right. Remember, this was 1988!
This process was repeated for each of the mandatory modules, and the system was placed into production in late 1989 or 1990. The full production cycle had taken 2 years, but the Customer (in the form of domain experts for each module) had been involved from start to finish.
I didn't actually join the team until early 1992, when I was hired on contract to evaluate the progress on a stand-alone interim version of the training module being developed in the same general group as the main HR system, but as a separate product. After a day or two I recommended a rewrite, and found myself the lucky winner of the contract to perform that work! I was immediately placed in a desk in close proximity to the Customer for the system, and worked very closely with her over the next few months to build it.
The interesting thing about that training system is that it had been intended from the start to be included in the main HR system. However, it wasn't a core part of the HR process, and it never reached a priority level required for it to be incorporated. Again, the organization as a whole identified the modules, and prioritized them according to the overall business value. For the training module, it could provide equal value in an interim, desktop system while the main team focused on the higher value modules. (As an aside, that training system was called ITS - Interim Training System - and was first released in 1990. In 1995 or 1996, I finally convinced people that the 'I' should be changed to mean something other than Interim so it became the Integrated Training System!)
Meanwhile, the main system was having releases to production every 8-12 months. When the government department for which the system was built merged with a larger department in 1993, it was decided that this system would be the HR system for the new department. In 1995, PeopleSoft arrived on the scene and was to replace what was now perceived as an old, character-based mainframe system. The head of HR (the Gold Owner) made it abundantly clear that PeopleSoft wouldn't replace the system until it provided the same level of functionality. PeopleSoft, the last I heard, is slated to roll into production in 2007.
So, I came away from my meeting this morning with a renewed sense that I had been part of something quite special, although I didn't consciously know it at the time. Many of the development practices from XP/Agile such as automated testing and true iterative development weren't done, but the overall team practices were. We had the On-site Customer, Planning Game, Frequent Small Releases, Collective Ownership, Refactoring (although not in the modern sense), and Sustainable Pace (there was overtime, but not all that often).
We were successful. We were Agile!