Team System and Process Governance

So, you have a process for developing your software.  Good for you.

So, you have educated your project managers on this process and how to monitor and enforce it.  Excellent – double Good for you!

Is there anything you can do to make it easier for all of the people on your team to understand and follow this governance?  Is it enough to publish the rules and methodologies that enforce this governance? 

Software Engineering Governance (SEG – I just made that up and it sounds rather cool), in its simplest form, is just a harvesting of process and control best practices used to help unify how you will develop software across your enterprise – from project to project, and from team to team.  Many organizations have invested a great deal of time and money developing and establishing these best practices – typically in the form of process and governance documentations.  Yet, because of this same fact, these established rules become hard to manage and update.  Sure, anyone can simply go and update the governance document – but, how do you get your team follow it. What’s more, there seems to be a difference between Governance and Enforcement – we can post speed limits on all of our roads, however, traffic patrols and automated speed camera systems are there for the enforcement.  Actually, that’s not true – the police and automated ticketing systems aren’t responsible for enforcement, they are responsible for slapping you on the wrist if you break the rules – not consistently, just enough to make you want to follow the rules – they are deterrents, not enforcements.

Let’s take the speed limit metaphor a bit further, however not too far because no single metaphor can be used to represent software development.  If a governing body really wanted people to obey all the rules all the time, in this case the speed limit, wouldn’t it make sense for them to make it easy to obey the rules and rather difficult to break them?  Wouldn’t it be cool if cars could know what the speed limit was for any track of road and prevent the driver from exceeding the speed limit, unless they purposefully overridden (in case of an emergency of course <grin>)?  Wouldn’t that reduce the number of speeders on the road?  More so, if the governing body chose to increase the speed limits for any individual road, the cars would instantly follow these new rules.  We wouldn’t have to post speed limits.  We wouldn’t have to educate people on the rules that govern speed limits – and we wouldn’t have any speeders – and we’d have smoking cool cars!

Now, I want to think about governance and software engineering again – SEG (I just love making up TLA’s – Three Letter Acronyms).  Let’s start by looking at something like MSF 4.0 for Agile Software Development.  Let’s pretend that a Project Control Office (PCO) specifies that all projects need to follow the methodologies, roles, and individual processes (risk management for example) specified by this process.  On its own, MSF is simply a declaration of a process, the definition of the governance that you expect your project managers to understand and to follow.   Just like cars that understand how fast they are allowed to travel on certain roads, wouldn’t it be cool if the tools that our software engineering team use follow the process governance (the speed limit) automatically, eliminating the need for traffic cops (i.e. eliminating the need for the project manager to facilitate all aspects of the project according to the defined process), yet still provide the ability to go outside of posted speed limits and rules when needed.

Well, this is where Team System comes into play.  You see, Team System really doesn’t know about MSF 4.0 for Agile Software Development – nor any other prescriptive methodology or other forms of software engineering process governance.  What it does know about is Work Items and the ability to associate Work Items with other perspectives of a project such as Test and Test Results, Build and Build Results, and even Source Code.  Work Items are extremely powerful because a work item’s definition is completely declarative and this is important when it comes to governance, and more importantly, the need for continual process improvement and resulting process adoption when it comes to governance.

At its primary level, Work Items are the Generic Type.  Specific Types derive from Work Items.  For example, a Task is a type of Work Item.  A Bug and a Risk are also examples of Work Items.  They all follow their basic definition of what a work item is (something that has fields, has state, has a layout, can be associated with other “things” and ability to promote their values to participate in a data warehouse), yet provide a way of controlling and governing process.  A Risk, for example, could have fields such as Impact, Priority, Mitigation Strategy, Contingency Strategy, and Trigger.  A Risk might also flow from state to state based on either events or conditions that within project.  A Trigger, for example, could correspond to an event that may have occurred on the project that would initiate the contingency set of tasks that need to be performed to minimize the impact of the risk.  In essence, the definition of a Risk and the processes that surround it, in this case the workflow and the fields and events that drive it, are an implementation of a Risk Management Process employed for a project.  Essentially, the definition of a Risk implements Risk Management Governance – and this is true for all work item types including, in the perspective of MSF 4.0 for Agile Software Development, Tasks, Scenario, Bug, and Quality of Service Requirement. 

Governance of process may also go much beyond Work Items to include a more document centric approach to process control.  For example, “You know you are done the elaboration phase when the Vision Scope and the Design Documents are complete and signed off” – sure, this work – however, enforcement and gentle guidance takes a bit of a back seat.

So, this is, in my humble opinion, where Team System rocks.  We have processes that are implemented in Work Item Type definitions that help gently guide team members when they need the guidance.  Let’s suppose that you need to change your risk management practice, well – you simply change the definition of your risk and the workflow and rules that it supports – and you have magically changed your process – and you didn’t really need to inform or retrain your entire team to help to enforce these new changes – Team System can help you do this, and even better – give you fancy tools and reports to help you measure and monitor your process execution and overall adherence (and in some cases, the results of that adherence such as quality, etc).

This opens the discussion into how one would make changes to processes.  Team System doesn’t really ship with any good project template editing tools – unless of course you are happy with Visual Studio itself since you would need to write applications that support this.  Coupled with the fact that there are a couple of different perspectives on process enhancement and support – this becomes quite complicated.

The dimensions you will have to deal with, when it comes to Process Improvement or Augmentation are the following:

1. Modification of a Team System Project Template (to be used with new projects)
2. Modification of a Team System Project (to modify existing projects)
3. Modification of the Methodology Template documentation – such as MSF 4.0 for Agile software development.

The first ability to perform process modification is by modifying the Team System Project Template.  This is a great way to take your lessons learned from one project and integrate them into the template that is used to define the work items and the reports that reflect them, along with document templates, etc.  This will really only allow you to implement those best practices on your next project – any existing project will not be changed.  What if you want to implement those changes on your current project?  Well, you’re gonna have to modify the definition of the work item type while online – something you need to do programmatically. 

Don’t fret,– the company I work for has been developing a set of tools for Project Manager and Project Control Office to help automate the modification of project templates or the modification of Team System projects directly.  These tools will allow you to better manage libraries of Project Definitions (read that as libraries of methodologies) that can be used on appropriate projects.  You could, for example, create a full SCRUM based project template for smaller team based projects – as well as more formal project templates for larger projects that require more ceremony and predictive control.  These tools will also allow you to take your harvested best practices and use them on existing team projects – essentially updating the process in place.  If you are interested in some of these tools – let me know.