Following on from the previous post - The Cranky Product Manager's Imposition: WTF Refactoring?
Scene: War Room. 2 days until Code Freeze.
LEAD DEVELOPER:
So, unfortunately, we’re going to have to pull FavoriteFeature out of the release in order to meet the schedule.
THE CRANKY PRODUCT MANAGER:
Huh? That feature’s been in the product for 3 releases now. Customers love it. Why do we have to pull it?
LEAD DEVELOPER:
Well, we had to refactor the code, but unfortunately we just don’t have the time to write unit tests.
Fast forwarding...
LEAD DEVELOPER:
Well, I, uh…. Well, …while the guys were in there modifying, you know, the CODE, well, they, uh, figured they could, uh…, well…, add some stuff to create some WICKED cool Hologram broadcasting stuff. It affected the old tests.
THE CRANKY PRODUCT MANAGER:
(pause)
First, Hologram what? That’s not in the backlog!
LEAD DEVELOPER:
We thought it would be cool.
This is a situation or something similar that happens too often. Engineering wants to do something "cool" and may at best slip the release date. At worst, as in this example, product quality and features may be compromised. What is a Product Manager to do? The development effort happens at too many levels and areas to keep track of and still performing all the other Product Management functions. So what can be done about this?
Several things, the choice of which depends on your development atmosphere and program maturity.
One of the buzzwords gaining traction since 2001 is "Agile Development." Agile development encourages frequent inspection and adaptation. It is a leadership philosophy that encourages team work, self-organization and accountability. The weekly team meetings may have revealed that the "unit tests" were failing well in advance of code freeze. There is also less of a reliance on a true code freeze. Features are implemented in small bite size and scoped chunks over iterations. These iterations last from one to four weeks. Because of the frequency of these iterations the code / product has less of a chance of deviating too far from the code's projected path. It also has the ability to change direction and focus as the market needs evolve.
Agile development emphasizes people and interactions over tools. The original incarnation was to use sticky notes on a white board or wall. With time, tools became an inevitable out growth. They do help automate and manage the process. Also, sticky notes do not work for remote teams. Free tools such as Agilefant and XPlanner can be used from the open source community. (http://www.agile-tools.net/) If you have the budget, subscription based services can be had from Rally Software or VersionOne. There is a whole ecosystem building up to support this development need so I won't belabor the point.
Agile development can be a bit of shift in thinking for some development teams. Another approach is to modify the code check in process and have the development team itself monitor what is being produced. One model that I have seen used with good success is a two tiered code submission process.
Individuals work in their own private "sandbox." When the feature they are working on is complete they check that in to a sub-system location. A sub-system integrator (SSI) takes the code that was checked in and builds it as a unit. Regression tests can be run on that unit before it is checked into the main code base or 'head'. The whole purpose of this exercise is to ensure that the main code line remains stable. Members of a subsystem team can be rotated through the SSI role. This way everyone gets the responsibility for ensuring sub-system's stability and no one is ever always the policeman.
With code in various stages of development, acceptance and testing it may sound like a management nightmare. It does not have to be though. Establishing a holistic approach to software development can smooth out potential problems and keep everyone informed as to the release's status. Treating the process of specification, development, testing and deployment as a continuously repeating cycle frees teams up to focus on what goes into the software rather than how to get the software out. This is referred to as Application Lifecycle Management (ALM). Now instead of treating each piece as a separate entity if you can tie them together the entire team is aware of where the code is in the development cycle and what is in the product.
Referring to the CPM's example from above and using a rudimentary example to finish the story out; a specification is created with some identifier. This is agreed upon with engineering and work begins. The code, when ready for testing, is checked into the release branch using the earlier assigned ID. A flag is set to indicate the ID's status as "checked in." This can be seen by the various team members (i.e. Prod. Mgr., QA, docs, etc.) The other members can then begin taking care of their part of the development process. As they complete their functions associated flags are also set until finally the feature is deemed complete. Repeating this process for all the features assigned to a release finally culminates in the release with known entities. No last minute surprises should occur.
Of course, this is all in a perfect world and everything works flawlessly. I have also managed to shorten book length topics to a single paragraph or two. I would be interested in how you have managed to reign in rogue development work? And what was the effect on the team's creativity? Let me know.
