Welcome to EMC Consulting Blogs

Introduction

I thought I’d write a “Quick guide” to help our SfTS v3 beta 1 customers get their new projects configured correctly to ensure that the shiny new reports work as designed and the SfTS event service can automatically roll up dates and capacities. This guide will no doubt be superseded by the guidance when its available and we are also considering providing a new project configuration tool to make some of the following a little less fiddly.

SfTS v3 is designed to take advantage of the new capabilities of Team System 2010, with much more sophisticated support for larger Scrum programmes where you might see multiple distributed teams working across different time zones. Greater sophistication means that we now have a few more knobs and dials to think about when we set up a new project.

This guide takes you from the point where you have just created a new Team Project using the SfTS v3 Beta 1 template, if you haven’t got this far then please take a look at the installation notes pdf included in the download zip.

We will leave the full description of how this new template supports a comprehensive range of scaled Scrum project models to a later post, but we need to cover just a enough of the conceptual model to set some context for the initial project configuration.

Scrum Project and Planning Hierarchy Concepts

The diagram below illustrates the hierarchy of a Scrum project or program as modelled by SfTS v3 on the Team System 2010 platform. For simplicity, I have not included Team Project Collections in the diagram, a feature of the new Team System platform that allows us to have collections of projects. TPCs provide yet more options for how we choose to scale and structure a program.

A Story (Product Backlog Item) will typically move from left to right on the diagram over time, starting as an idea for a cool new feature that then goes through a process that will look something like this:

1. Evaluation of business value
2. Addition of Acceptance Tests that help to more tightly define the Story
3. Estimation of the effort required to deliver the Story
4. Prioritise, frequently
5. Plan the target Release for delivery
6. A team plans the Tasks (Sprint Backlog Tasks) that will implement the story in a Sprint
7. A team works on the tasks until the Acceptance Tests are passed

We track the evolution of stories and tasks with Team System’s Iteration Path and further support this model with three Work Item Types; Release, Sprint and Team Sprint who’s key features are summarised below:

• Release
  • Models a Scrum Release composed of one or more Sprints delivered by one or more teams
  • Must correlate with a matching Release node within the Iteration Path tree
  • Records the planned capacity and dates for the Release
  • Provides a read only view of the actual Release dates based on rolled up dates of the planned Team Sprints
  • Burned work – automatically shows actual completed work measured in Story Points
• Sprint
  • Models a Scrum Sprint delivered by one or more teams
  • Must correlate with a matching Sprint node under the appropriate Workstream node within the Iteration Path tree
  • Aggregates the capacities and dates of its “Child” teams (read only fields)
  • Post beta 1 will require a link to a “Parent” Release work item through an “Implements” Link Type
• Team Sprint
  • Models a Scrum Sprint delivered by a specific team
  • Must correlate with a matching Team node within the Iteration Path tree
  • Must be linked to a “Parent” Sprint work item through an “Implements” Link Type – reports will not function correctly and team capacity and Sprint Start/End dates will not roll up if this link is not in place.
  • Sets the Team Sprint Capacity
  • Sets the Team Sprint Start Date
  • Sets the Team Sprint End Date

The “Workstream” part of the model enables a project to contain Sprints of different cadence (e.g. 1 team on a 2 week Sprint and another using a 4 week Sprint) and is implemented only in the Iteration Path without a matching work item. Even if you use a single cadence (recommended in most situations) it is important that a workstream node is retained, even if you change its name, to ensure that reports run correctly.

New Project Configuration Steps

The following steps assume that you have successfully created a new team Project and selected Scrum for Team System v3 Beta 1 as your template and then take you to the point where you have a new project with a correctly configured Release and Team structure.

Step 1 – Configure the Iteration Path

We create a default Iteration Path (see screenshot below) and some matching work items as part of the Team Project creation wizard process but you will need to modify this to fit your project.

It is important that you keep the same structure but you can change the names of the nodes and add additional workstreams Sprints  and Teams. A simple example below which has:

• 2 Releases named Alpha and Beta 1
• Alpha has 2 Sprints of the same cadence within a workstream called WS
• Each of these Sprints is delivered by a single team called the PathFinders

Step 2 – Match work items to the Iteration Path nodes

Use the “Release, Sprint & Team” query to list all the relevant work items so that you can match them to the iteration path, by modifying existing and creating new work items of the appropriate type where required. This query will more than likely be replaced by tree query in SfTS v3 beta 2 which will improve the formatting and make the hierarchical structure much clearer.

Step 3 – Link Team Sprints to their Parent Sprints

When we create a new Team Project it isn’t possible to create template work items that are linked together within the Project Creation Wizard process so you will need to manually set the “Implements” links between each Team Sprint and it’s parent Sprint work item. Any other link type will not function correctly.

This is one of the areas where we see the need for a project configuration tool.

From the “Linked Team Sprints” tab of a Sprint work item, select the Add button – see image above in step 2. This will show the screen below:

Ensure that you select the “Implemented By” Link type and then type in the work items IDs of all the Team Sprints that contributing to this Sprint. Click “OK” and then save the work item changes.

Step 4 – Setup the Releases

The Release work item provides the ability to track whether the Sprints and Team Sprints configured for a given Release match the intended duration of the Release. The “Actual Duration” dates are read only and automatically updated provided that all iteration paths are set correctly and that all Sprints and Team Sprints are correctly related as in Step 3.

Step 5 – Setup the Team Sprints

The Team Sprint work items are the source for Sprint start and and end data which is automatically propagated up through the Sprint and Release work items. As a result the only elements of a Sprint work item requiring configuration are the “Implemented By” links to its Team Sprints, unless you would like to set a joint Sprint goal for multiple teams working together to deliver the Sprint commitments.

Most organisations that we see adopting Agile approaches for large programmes or across an entire organisation have already seen success with one or more Agile projects. In fact, we wouldn’t recommend not having seen a few successes before embarking on large scale adoption! Based on these early successes there is a temptation to simply “Hit the gas” and do a lot more of the same by simply multiplying the small number of successful teams. Life just isn’t that simple and very often large scale adoption runs into trouble. There are many reasons for this:

• Early Agile teams have usually chosen an Agile approach themselves as opposed to the later teams who have the decision thrust on them by a corporate mandate.
• A small number of Agile projects can be a sufficiently small target and slip under the radar so as not to fall foul of corporate project management offices or be viewed as a significant threat to the status quo.
• The vision for what the organisation is trying to achieve and why it is adopting an Agile approach is poorly communicated to all those who are going to be affected by the change.
• An underestimation of the impact on organisational functions like HR and logistics.
• Resistance from middle management who feel threatened by the concept of self organising teams.
• Resistance from staff who are either in an operational role or have some operational responsibility, like application support for example where it is more difficult to see how Agile approaches can be applied.
• Departmental structure and management hierarchy – common issues are management interference with the team’s working practices and requests to work on other work outside of the project.

Communication, communication, communication …….

Getting buy-in is vital, as is communicating the “Big picture” of what is at stake. I listened to Kent Beck speak at the Agile Business Conference and he told the story of a cleaner at NASA. When this cleaner was interviewed he responded to the question of “What do you do?” by answering “Son - I send people to the moon”. This is a man who doesn’t just clean toilets but clearly gets the big picture of what his organisation’s mission is! One of the manifestations of people not understanding the overall goal is “Sub optimisation” (see Lean Software Development - Mary & Tom Poppendieck). You see this in multi-team environments where the teams just focus on their own piece of the puzzle to the detriment of the overall programme. I’ve seen extreme cases where teams don’t even have visibility of their own requirements backlog but exist on just the small list of the next iteration’s priority features fed to them by their Product Owner. I liken this to running full tilt along a London street with your eyes firmly fixed on the ground or driving at 70mph in the fog! Without visibility of what’s ahead a team will tend to make poor design decisions. Without an overall picture of the wider programme objectives a team will see any task like integration with other team’s work as an irritation and impediment to getting their real work done.

So communication is absolutely key – I don’t think I’ve ever heard anyone complain that they have been the victim of over communication! An initial communication out to the organisation explaining the strategy and the approach to achieving it is a great start. But ongoing updates are necessary as progress is made and as strategy and approach is revised. New team members need to be inducted and provided the big picture before they join.

Evolution not Revolution

Change is hard. Many people don’t like change and there is always an organisational inertia dictating the practical pace of change that depends on the organisational culture and size. Ideally the changes in process and organisational structure required to make an organisation capable of truly Agile software development should be introduced gradually. In other words it is better to start small and gather momentum, allowing time to sort out the wrinkles that will appear. This strategy applies to both a large multi-team programme and to organisational adoption.

Assuming that there are already one or more teams successfully delivering good quality software every iteration, build the existing team sizes with a gradual addition of new team members. Get these new team members trained in the fundamental principles of Agile and the mechanics of your chosen Agile framework (e.g. Scrum). Make sure that the new team members are paired with experienced team members and allow for the drop in productivity that will occur while time is spent bringing the new blood up to speed. Grow the teams above their optimal size for productivity and then divide the teams in two with a balanced mix of experienced and new team members in each new team. Repeat this process until you have the required level of scale.

Organisational Change

As the number of Agile teams increases, the conflicts with the way Agile works and the existing way the organisation works will surface. To smooth the adoption, a parallel change programme should run alongside to gradually align the two worlds. An approach that works well is to run this change programme on an Agile footing, with its own prioritised backlog of change tasks – Ken Schwaber calls this the “Transition Backlog”. This approach has a natural empathy as it supports the flexibility to incorporate new tasks that arise out of the Agile teams trying to build software and it also helps align management to an Agile mindset.

Part 3 to follow

In part 3 I will talk about some of the approaches and patterns for enabling multiple teams to work in concert.

I recently ran into a problem using TFS Source control on a new laptop where the buttons and icons in the "Compare" dialog box and screen came up blank, leaving me to guess which was which.

So if you get this really helpful set of icons:

Or these really helpful buttons:

Then you have the same issue.

I initially thought it was the NVIDIA drivers for the display but it turns out that this problem occurs with McAfee VirusScan ver 8.0.0 and the "Buffer Overflow Protection" feature. I'm not sure whether it is McAfee or Microsoft code at fault. 

The workaround is to go into the VirusScan Console and disable the "Buffer Overflow Protection". This will obviously mean a reduced level of protection from your virus scanner. Apparently, this setting can also cause blank list boxes when binding to a collection.

Ok so we've released Scrum for Team System and so far about 550 people all round the world have downloaded it. What next then?

Well we are starting to think about additional tools and enhancements and would love to have your top feature requests. Just to fuel your thoughts, we are currently productionisng a tool we built for testing the plug-in that will allow you to move projects and all their history data between different methodologies. So for example you can take an MSF Agile project and convert it to Scrum. Another use for this tool will to enable Scrum for Team System projects to be moved to future releases of the plug-in.

Talking about future releases we are looking to do a minor release (1.1) in early May that will tidy a few things up. Keep a watch on www.scrumforteamsystem.com for details.

Please email your ideas for enhancements to scrumforteamsystem@conchango.com.

I co-presented 'The Value of Agile Methods' at the Microsoft Architecture Forum on Monday along with a colleague Howard van Rooijen. The presentation discussed the shortcomings of traditional software development approaches, before looking at agile methods and engineering practices that we have found help deliver quality software with features that the business actually need. Here at Conchango we have adopted a combination of Scrum and engineering practices derived from XP and this is what the meat of the presentation material covers.  

Microsoft has posted an early version of our combined slide deck and this can be downloaded from here.

Howard has published his final version slides with extensive notes on his blog.

My slides have quite a few custom animations in them with the result that the message may get lost in the translation to jpeg so I've decided to leave them in PPT format on the link above rather than including them in this post.

We had very good feedback after the presentation and it was a shame that we didn't get more time to answer the many questions. It was interesting that the questions and concerns were not with the concept of agile methods but more about how to persuade organisations to adopt agile approaches, with the most common obstacle seen as the dreaded 'Fixed price - fixed scope' impasse.

Sadly there is no instant silver bullet answer to this problem with the reality being that culture takes far longer to change than technology. The big problem is this illusion of fixed scope. This could only be a real concept if the requirements could be recorded in such a way that they were 100% rigorous, complete and unambiguous. Having achieved this impractical aim the requirements would then have to remain unchanged through to the time the software gets delivered. Life isn't like that, well at least mine isn't! An interesting example of the impedance caused by the written word occurred in the panel Q&A session at the end of the Architect Forum. Delegates wrote down their questions for the panel on post-it notes that were then read out by the facilitator. Almost every single question needed to be qualified verbally before we could be sure we understood the question enough to begin answering it.

So we give up and admit that we don't fully understand the requirements at the start of the project and we know they'll change anyway by the time we're done. This makes it somewhat problematic when trying to gain budget approval or bidding for a project. A certain amount of education needs to take place in the corporate world to make it understand that specifying and building software is far from the exact science that it is generally assumed to be.

When we engage with a customer we explain the futility of the fixed scope concept and rather than fix the scope we agree a fixed price to suit the budget. We then incrementally deliver the most valuable features, as prioritised by the business, until either we reach the end of the budget or achieve enough value from the delivered features. This approach does require a level of trust between the parties and has a much greater chance of success when the relationship works as a partnership rather than a customer-supplier arrangement.

Another colleague has a post dealing with the change in approach required from the Project Manager's perspective when dealing with the cost-scope-time triangle. Find this here on Steve Garnett's Blog.