Wednesday, May 24, 2006

No Trust without Transparency

Is your project naked?

Is your agile development group hiding information about their work in progress? If you a project manager or customer, have you heard, “trust us we are doing agile?” If you are sitting with a project plan that says work will be done in 6 four week iterations and all you have is a loose idea of what is planned for each iteration, how do you manage risk? Traditionally, you’d ask for a more detailed plan. You’d push for predictable big planning upfront. However, the reality is that the team probably can’t make a more detailed plan due to uncertainties. So you do you manage risk?

If you are in the development team, it isn’t enough to say, “We have an iteration plan and we’ll deliver working code at the end of the iteration, trust us!” Trust isn’t enough. If a project plan schedules 6 months in 6 four week iterations, then it isn’t enough to give the project manager only six data points to show progress. Some transparency in to the progress within the iteration is required and it is essential that this data is shared with the project manager and the customer. What is being reported out must be the same data and information being used to run the project internally. At Microsoft we call this concept “Trustworthy transparency.”

Transparency is the antidote to requests for big planning upfront. Transparency offers project managers the ability to do risk management through the project life time. If you aren’t reporting cumulative flow, or burn down or burn up, or (gulp) earned value, every day to every stakeholder then you aren’t embracing the core foundation of agile development techniques - high trust.

Try running a naked project. You’ll find it liberating. Technorati tag: Agile, David+Anderson

What I learned this past week

So I’m back in Seattle after traveling to Orlando for VSLive! and Washington D.C. for IRMA. I’ve also been visiting a customer where I’m helping them with a long term case study for VSTS and MSF. I’ve got a single takeaway from these engagements - work item type definition is hard - really HARD! Walking through a workflow, optimizing it and transcribing it in to a state model for encoding in to a Team Foundation Server work item type is hard. I need to think more about this and publish some guidance. For now here a brief description of how I do it…

(1) I start by asking the business owners to sketch the flow of work using stick figures and little stacks of work to be processed. I get them to map the flow with arrows between stations and activities for the stick figures scribbled on to a white board

(2) I then make a statechart model in Visio and create a state for each station in the flow - typically identified by a stick figure performing an activity. I then create a state for each queue in front of each station.

(3) I then map all the possible transitions between states. Remembering to think about return transitions. “Ooops, I didn’t mean to close that, I need to re-open it.”

(4) I then ask for all the reasons that each transition can happen. This activity usually flushes out a few missing transitions and even an occasional missing state. So I then rework steps 2 and 3 and complete the reasons

(5) I then transcribe the Visio statechart in to the WITD XML using an XML editor. It is a good idea to start with the WITDs that are shipped with MSF and edit them.

We’re not done at that point.

(6) Next we need to identify all the data fields required and a form layout for those fields. We need to decide which of the fields will be used in reports.

(7) Now using the XML editor we add these to the WITD file.

(8) Now we need to go through each transition and identify required fields that must be completed as a pre-requisite for that transition.

(9) Finally we edit the subtle aspects of the WITD file to include the required fields for specific transitions.

We’ll be posting some white papers on customization of MSF process templates very soon now and I will alert you when they are on-line. Technorati tag: Agile, David+Anderson, MSF, Vistual+Studio