I’ve been helping a pretty large team for a few months now. Today I attended a user group meeting today on SecondLife delivered by Brian Harry of VSTS/TFS. It is very clear that there are some issues that get exacerbated when you have a very large project.
The first one that comes to mind for me is the formation of teams. It seems that while some organizations are moving to cross-functional teams to some degree, the silos of discipline management still exist and tend to get in the way. Brian Harry talked about the “Feature Crew” at Visual Studio. These teams are cross functional but are created for specific feature sets. These teams have specific goals and tend to be disbanded when the set of features are complete. The team members often have multiple assignments simultaneously. I’ll have to say that this is a step in the right direction in that the system and business capabilities are grouped with a team to deliver them. This tends to help with the coordination of work between teams. However the fact that they do not let the teams work together over an extended period means there is a lot of forming and learning about the team that is overhead.
One of the other problems is the tracking and processing of bugs. Because of the integration issues and the use of branching techniques to give the teams a relatively stable platform to work on, there are lots of bugs created and significant effort has to be put into managing and tracking them. If you have a project with thousands of active bugs, you have a very big problem.
However the biggest issue I’m seeing is the lack of visibility of the delivery of business value. Huge projects are generally managed by feature delivery and bug rates and counts. Most of this comes from the coordination of the work on the teams and the poor communication of vision down to the scrum team level. This results in the scrum or feature teams doing massive amounts of interpretation on the requirements and the result is a bloated codebase with excessive complexity and enormous testing and integration issues. Without a clear top-down expression of the vision for the product and the release the feature teams are virtually free to dump on the product.
All of these problems lead to release plan accuracy issues. The traditional way this happens is slipping the ship date. However the more dangerous risk is not delivering what the user needs. How do we reduce the impact of these issues?
Firstly we should NEVER slip a ship date. Our customers, users, clients need what we are building, otherwise they would not be paying for it. They get no value out of software that they can’t use.
Secondly we MUST adopt a business value driven approach to managing the work and the teams. This means that product and project management have to change. Traditionally either the specifications/requirements are either so massive as to not be understandable or so limited they are little more than hand waving.
To accomplish these two goals we have to prioritize the business value and constantly react to what the team is delivering. The scope of the release WILL change, but if we have prioritized based on relative cost and relative business value we can deliver the important features on time.
This takes metrics and project status reporting. Brian Harry said that metrics should be about making you ask questions. I could not agree more. However the most important question should be about the progress toward delivering high priority business value. If the teams were organized around business value items and the bugs were categorized by business value area then we could stop working on bugs that don’t impact the release plan. We could also concentrate more on the quality of the code with the basic principles of cohesion, low coupling, testability and clarity.
It does not matter what tools you are using, the focus should be on the delivery of business value. Track stories, bugs and scenarios in an appropriate way for your team, but concentrate, reward and deliver business value early in a way that will allow you to deliver business value quickly in the future.