What is a Forcing Function?

Forcing Function: In the Agile space, a forcing function is a constraint that causes a change in behaviour as a team adapts to accommodate the constraint.

A Scrum Sprint is good example of a forcing function - the team has to figure out how to complete work in a tight timebox. If they work in a sequential waterfall approach: analysis – design – development - testing, then chances are, they will fall out the back of the Sprint with only partially completed work. The Sprint boundary forces them to reconsider how they shape work and collaborate to get it done, thereby driving behaviour change.

Face-to-Face Communication

In the Agile world we have always favoured face-to-face over other forms of communication and this is enshrined in the 6^th Agile Principle:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

When we design teams, we aim to co-locate team members so that we maximise their ability to directly communicate and collaborate. If you’d asked me a few months ago, I would have told you that a co-located team will always outperform a distributed team.

Enter COVID

And then along comes the COVID lockdown! Organisations were forced to send their people home and fully distributed teams became non-optional. A new and far reaching forcing function had arrived!

Given the enforced distribution of their workforce, organisations were forced to rapidly confront a number of infrastructural and people challenges. Our experience over the past months is that many have adapted well and some teams (but not all) have begun to perform better in distributed form than when they were co-located.

At its heart, agility is about adapting. Those teams and organisations faring better have adapted, and continuing to adapt, their behaviours, policies and infrastructure to surmount the challenges. I think many of the adaptions may well be retained and incorporated into the new ‘normal’, whatever that might be…

Some teams and organisations bumped into limitations in their infrastructure and policies that dramatically reduced the ability of their people to productively contribute. Examples include:

• Severe and draconian security policies enforcing tight security, but preventing workers from actually working.
• Mandatory use of virtual desktops and VPNs where the performance is so poor that video conferences and use of online collaboration tools is impractical.
• Blanket ban on use of cloud based collaboration tools that sit outside of the corporate IT infrastructure.
• Overly rigid rules usually result in people finding ways to circumvent them (e.g. using their own PC) and potentially less secure.

Rather than blanket bans and rigid rules, security has to be contextually flexible and an enabler for a distributed workforce to work effectively whilst reducing risks to an acceptable level for the sensitivity of specific types of information.

Not all broadband connections are equal! Even those living in more populous areas, have really struggled along as 2^nd class citizens, repeatedly having to reconnect or unable to support video and audio.

I’m hoping that in the UK, Boris’s “Build Build Build” slogan is going to have our national digital infrastructure at its heart! Meanwhile, organisations might considering investing in business broadband connections for workers that are regularly facilitating or leading large online workshops and are currently suffering poor quality consumer Internet connectivity. Consider the real cost of a disrupted meeting versus the investment cost of better infrastructure.

The home office needs to be equipped to support extended digital collaboration. Siting on the sofa with a tablet isn’t going to cut it! The home worker must have reliable WiFi, suitable laptop, screen, keyboard, video camera, microphone, seating/standing desks, etc.

IT strategy and services need to redraw the boundary and recognise their workers home infrastructure as an extension of the corporate IT landscape.

Humans are by and large social animals. Our social interactions in a coffee break or grabbing a sandwich at lunchtime are an important part of the relationship building that collaboration and trust are built upon. They also play a key role in psychological wellbeing.

Extra attention needs to be put into non-work social interaction. Regular virtual coffee breaks with random colleagues are one approach – we’ve used an add-in to Slack called Donut for this. A bit of banter at the beginning of a meeting helps get people relaxed and talking, as well as providing a bit of an interaction fix. Having video on also humanises interactions as well as adding richness and effectiveness to verbal communication – seeing the Programme Manager’s Star Wars models on a shelf behind their head really helps break down barriers!

Motivation, focus and sense of purpose can be harder for some, removed from the buzz and life of the office environment.

Additional support may be required, adding structure to people’s days with regular touchpoints with colleagues and leaders, coaching to break down larger missions into short term tangible goals and ‘micro-plans’.

Teams that had already formed before COVID have generally been able to adapt to the distributed world, taking their existing relationships and team identity into the online world. Where a new team has been formed from scratch there have been far greater challenges to building the team identity, cohesion and trust.

Additional thought and time should be put into online team building activities to accelerate the development of the interpersonal relationships. Systematic pairing or even working in threes will also fast-track the sense of team as well as increase knowledge sharing, common purpose, work quality and collaboration.

Zoomed out! Whilst Microsoft Teams and Zoom are essential collaboration tools for the distributed workforce, they can also become a prison. Back-to-back conference calls are draining and when there’s no time for a toilet break or lunch then they create an unstainable pressure as well as reduce the time for focused work. Another side effect, is that meeting start times are delayed waiting for everyone to escape from their last call, reducing the effectiveness of the meeting and leading to it running over time.

Schedule meetings with gaps and reduce meeting duration. Rethink how meetings are run, look for fresh alternatives to watching a slide deck presentation that really get participants engaged. We use virtual whiteboard tools as platforms to create interactive meetings with far greater collaboration and enjoyment. Check out: https://www.mural.co/ and https://miro.com/.

The whiteboard artefacts transcend the scheduled meeting period so collaboration can take place before and after the meeting, as well as in the session.

Shameless plug… whilst we’re talking about tools, have a look at our: https://www.leancoffeetable.com/ for online Lean Coffee format meetings.

Summary

COVID has forced us to rethink the way we work. The result is that we have proved remote working and distributed teams are viable and, with some adaptions and effort, made to work well. I suspect that a co-located team will still generally out perform a distributed team (especially if we include team formation). However that’s just one dimension and we should also factor in the advantages:

• Potential for a better life-work balance
• Reduced corporate office costs
• Reduced travel time
• Positive environmental impact
• Removal of geographical barriers to team membership

There are number of tools and techniques that I’ve used through this period that I will continue to use even when/if I get to work with co-located groups again.

Tweet.

Agile experts will tell you the first rule about scaling Agile is … Don’t!

The ideal Agile team model is a single co-located, cross-functional team working closely with the customer. As soon as you involve multiple teams to build the same product there will be challenges and a reduction in efficiency (the amount of value created for a given investment). However, if timelines and product scale are beyond a single team then we consider scaling to a “Team of Teams”.

We attempt to structure the teams and work for maximum effectiveness by staying true to Agile principles and adopting a set of scaling patterns.

There are many potential patterns, however there is usually a fundamental choice between the Component or Feature team pattern as a basis to structure the teams.

This article will consider the pros and cons of these two approaches.

Lets start with some brief definitions of the two patterns:

Component teams are structured to match technical layers, components or services. Examples include; iOS team, Payment API, Data Services, etc. Customer and/or Business valuable backlog items are split across the teams, each contributing functionality in the components or services for which they are responsible.

Feature teams are structured to match business value so that they take end-to-end stripes of customer valuable functionality and deliver them within the boundary of a single team. Unlike the Component teams, Feature teams work across all components related to providing the business functionality.

The venerable Burndown chart has been a central plank in tracking progress and predicting likely release dates in Scrum since I can remember. Over the last few years, the Burnup chart has gained popularity – lets explore why.

The strength of the burnup approach is in its simplicity and clarity, providing a view of net progress which helps predict when a product might be ready for release. Propagating the net velocity helps to show when the product might become releasable – the dotted blue line on the diagram.

Each data point of the burndown tells us how much “Work Remaining” there is at that point in time, i.e. the current amount of work left to release the product. The delta, the “Burndown”, between the points is the total of:

• Backlog completed satisfying the Definition of Done (burnt)
• New backlog added to the Release scope by the Product Owner
• Backlog removed from scope by the Product Owner

Burndown Drawbacks

The simplicity and elegance of the burndown also turn out to be its weakness.

Agile approaches embrace change as a positive aspect to increase the value delivered to the customer and business. So, it’s no surprise to find that release scope often changes significantly over time (usually in an upwards direction!). In a burndown chart, it isn’t clear what contribution scope change is making to net progress, often the impression is that the team simply aren’t working hard enough.

There have been a number of approaches used to enhance the burndown chart to provide deeper insight but to my mind these attempts lose the chart’s strengths - simplicity and readability (they also look ugly!).

Although a  team’s throughput can and does vary, working overtime, stronger coffee and more pizzas only has a marginal impact and is usually not sustainable on an ongoing basis. It turns out that the biggest lever we have to impact a release date is the scope. This is where the burnup chart comes in.

The Burnup Chart

The burnup chart tracks the throughput of the team and the scope separately so that the growth in the backlog is made very visible to all stakeholders. The chart illustrated to the right shows an all too common situation where the backlog grows at a similar rate to the team’s throughput.
We can add a forecast for likely team throughput based on their historical performance. Forecast approaches range from simple standard deviation through to sophisticated Monte Carlo simulation, modelling the team’s throughput data (Probabilistic Forecasting).
Now we add an indication of how the scope may grow over time. This chart shows a scope forecast range from zero additional scope through to an increase at the current average rate.
The intersection of the forecasts ranges provides something we call the “Landing Zone”. If we drop vertical lines down to the x axis from the intersection points is shows the release date range from the earliest likely, through to the latest expected dates. Working with a delivery date range is much more healthy and realistic than forecasting to precise dates.

Summary

We have found that when stakeholders see the impact of scope on delivery dates it removes some of the emotion from the debate and instead creates a healthy discussion and focus  on those backlog items that are critical to release versus those that are not.

While the Burndown chart is an elegant and simple view of release progress, the Burnup drives more healthy conversations that help shape the Minimum Viable Product. If the Burnup is used all the way through a release, it will help prevent the pressure on the team to work at an unstainable level and/or reduce quality levels to hit an unrealistic scope and deadline combination.

Agile process tooling is catching on with growing support for burnup chart functionality. If you use JIRA, TFS or VSTS then take a look at SenseAdapt which supports the burnup and a multitude of other handy charts.

Why have an ROI field in the Product Backlog

The goal of a Product Owner in a Scrum team is to derive the maximum benefit from the team’s time, in other words to maximise the Return On Investment (ROI). Where the “Investment” is the cost of running the team and the “Return” is the value of the Product Backlog Items (PBIs) that the team turn into working software.

To help the Product Owner achieve this aim, they need to understand the relative business value per unit effort for each of the backlog items, so that they can guide the team to work on the items that will realise the most value for the lowest team effort. This is why it is common practice for Product Backlogs to have an ROI field which is calculated by taking the estimate of business value and dividing it by the estimate of the required team effort to implement the PBI. We then use this field as guide to order the backlog so that the higher value items, per unit effort are towards the top – allowing the team to deliver greater value in their Sprints.

Enabling an ROI field in TFS

By default, a PBI in the standard Microsoft Scrum process template does not have an ROI field so the first thing we need to do is add the field to our Team Project.

Here’s a view of a PBI in the standard Scrum process template, showing just the Effort and Business Value fields highlighted in red.

Add an ROI field to your PBI workitem definition and set is as type Double and configure it as Read Only in the Team Explorer form as it will be calculated by dividing the business value by the effort field. Something similar to this should do the trick in the Workitem Type Definition XML:

Field Definition

<FIELD name="ROI" refname="RippleRock.ROI" type="Double" reportable="measure" formula="sum">

   <HELPTEXT>Story ROI based on Business Value/Effort</HELPTEXT>

</FIELD>

Form Definition:

<FIELD name="ROI" refname="RippleRock.ROI" type="Double" reportable="measure" formula="sum">

   <HELPTEXT>Story ROI based on Business Value/Effort</HELPTEXT>

</FIELD>

The result should look something like this:

The next problem to solve is how to automatically calculate the ROI value.

The standard way of calculating the ROI field is by using an Excel view of the backlog via a workitem query, recalculating the ROI every time the value or effort changes and then manually publishing back to TFS. Not a great solution!

Step-up TFS Rippler. This add on service for TFS has a number of useful capabilities, performing field calculations is one of them. For more information about what TFS Rippler can do and how to install it, have a look at the dedicated website or other related blogs.

We can setup a couple of XML rules in TFS Rippler’s TransitionRules.xml file that will instruct it to automatically recalculate the ROI field whenever the effort or value fields change.

An example of a one of the required XML rules is annotated in the image below:

When workitems are changed, TFS Rippler executes the instructions in rules that match the workitem change event. This example matches against changes to the Effort field in PBIs that are in the eligible states listed, and then updates the ROI field in the same PBI. We need a similar rule that triggers on changes to the Business Value field.

The complete set of XML for driving the automatic updates to the ROI field are shown below:

Some things to check:

ü  We recommend testing out your changes on a test collection & project first.

ü  Backup your rules files before you set about modifying them.

ü  Remember to match the workitem and field names in the rules to the names defined in your process template!

ü  Also pay attention to where you place the rules within the TransitionRules.xml files to ensure that the rules are in scope for the given Team Collection and Team Project.

For more information on TFS Rippler checkout the website.

Tweet.

TFS Rippler is an add-on for Microsoft’s Team Foundation Server (TFS) that runs as a background service, providing some key benefits that you don’t get out of the box with TFS. TFS Rippler automatically and efficiently updates workitems based on a set of customisable rules, triggered by changes to workitem fields or states. Here are few examples of what TFS Rippler can be used for:

• Populate an ROI (Return On Investment) field in your Product Backlog Item or Feature calculated by dividing the Business Value by the Effort field.
• Aggregate values from child workitems up to a parent, for example calculating the Total Work Remaining to complete a Product Backlog Item, calculated from the remaining work on its Tasks.
• Provide a Feature’s percentage completeness,  based on the Remaining Story Points effort versus the Total Story Points required to complete the feature, aggregated from its child Product Backlog Items.
• Automatically moving a Product Backlog Item to In Progress as soon as any work starts on its Tasks

Here’s an example Excel Feature Dashboard that is driven by a number of TFS Rippler capabilities, working in combination to show a great overview of Feature progress for all stakeholders:

Outlined in Green we have the percentage complete calculated for a Feature by a calculation that compares the Remaining Story Points against the Total Story Points required to complete the feature (calculated using TFS Rippler’s aggregation facility).

In Pink outline we have the Total Story Points for a feature calculated by aggregating all the Effort estimates for the related Product Backlog Items – this total figure is then in turn used to help derive the Percentage Complete and ROI for the feature.

Outlined in Blue we have the ROI for the feature calculated by dividing its Business Value by the Total Story Points required to implement it.

In the next few blogs I’m going to show how to make all this work and delve into a lot more detail. For more information on TFS Rippler checkout the website.

Introducing Team Foundation Server 2012 and Scrum V2.x

The combination of Microsoft’s latest Scrum process template and Team Foundation Server 2012 brings a host of new features and much improved user experience. Most of the interaction and administration of Team Projects moves into the web interface with only rare visits to Team Explorer required.

A “Backlog” view enables the team to refine the backlog, quickly adding new User Stories and reprioritising any story by simply dragging it up or down the order. A forecast function provides the ability to visualise sprint by sprint how the team might progress through the backlog at a specified team Velocity. Sprint Planning is well supported; the team simply drag candidate stories into the new Sprint and then as they add tasks to the stories there is automatic feedback of team commitment versus their capacity.

A “Board” view provides an interactive virtual team board with state swim lanes so that the teams can see exactly what each other are working on and how the sprint is progressing. The Board view can be narrowed down by team member to aid Scrum meetings and personal work management. The user experience of the board is excellent, with low impedance changes to task states, hours and assignments with an automatic background save.

What About Multi-team Support?

All this new functionality and user experience works nicely when you have a single team working within a single Team Project. It is common though, for multiple teams to work against a common Product Backlog which requires a single Team Project. Consider for example where multiple teams are collaborating to build a product or ecommerce system. Configuring a Team Project based on Scrum V2.x template to support multiple teams is certainly possible but the behaviour of the board and backlog views makes some assumptions and requires some working around.

In VS2012 the multi-team scenario is supported in part by an area path mapping per team that is intended to act as a filter for the backlog and board views such that the teams see their own subset of data. There are a number of challenges with this approach though:

• The area path is no longer available for Product Backlog theming or categorisation which is a major setback for those of us trying to make sense of large backlogs.
• The filtering by area path is too binary, providing one of these two options:
  • A team has visibility of the entire Product Backlog but their Sprint Backlog view is unusable as they can’t filter out other team’s backlog items
  • A team can’t see the entire Product Backlog (only those scoped to their area path) but their Sprint Backlog view makes sense. I suspect this is the intended option!
• Lack of complete Product Backlog visibility degrades architectural decisions and ability to work with the other teams sharing the backlog.
• The “Forecast” feature of the backlog view isn’t effective unless it applies to the entire backlog rather than just team subsets filtered by area path.
• Teams can’t pull requirements into their Sprints until backlog items have been moved to the team’s area path by someone else.
• The issues above drive early assignment of backlog items to teams, causing sub optimal scheduling and flow of stories.
• One of the teams has to be the “Default” team which inherits its area path setup from the Team Project configuration and doesn’t appear as a named team in navigation lists.
• New Product Backlog items inherit their area path from the default team path setting, so the “non-default” teams can’t see them
• All teams share Sprint start and end dates – generally good practice but teams working from different countries often have different holidays requiring adjustment of sprint dates.
• It is possible to use a custom field as a “Team” field but this approach shares similar challenges as above except that it does free up the area path for backlog categorisation.
• The custom field approach requires the addition of a team field in all appropriate work items (e.g. Product Backlog Item, Bug, Task & Impediment.

Given the challenges outlined above I have spent some time exploring a number of alternative approaches to supporting multiple teams. Here are three different patterns that work reasonably well if you are prepared to live with a few compromises. There may well be other good patterns so please let me know if you discover them!

Multi-team configuration – Area Path Pattern

If your teams won’t miss the area path as a means of Product Backlog theming or categorisation and all the teams use consistent dates for their sprints then try this pattern. This approach uses the area path to split the team’s views of the backlog but uses an additional “virtual team” to provide the teams a way of interacting with the whole backlog.

Setup

In this example, I’m going to have two teams, Team A and Team B, working together against the same Product Backlog within a single Team Project, Scrum03.

I’ve created three teams, the two Scrum teams and then a third team, the Über Team, who will be the “Team of teams” and are set as the default team – notice the bold formatting of the team name in the screenshot below:

The Über Team is the key to working around many of the challenges listed earlier, providing our teams the visibility of the whole backlog for Product Backlog refinement activities and joint planning. All members of both teams are also assigned to the Über Team so that they can use the Über Team’s backlog view. I’ve used Windows groups as security containers for my 3 groups, hence why the view above only shows “1 member” for each team.

The area path configuration for the Über Team should be set to the root, with sub areas included to ensure that the entire backlog is visible, regardless of whether items have been assigned to a specific team:

The two Scrum teams provide filtered views via their area path setting so that Sprint Backlog and Board views show only those backlog items and tasks committed to by each team. The area path setting for each team should be configured to the specific team path.

The iteration path configuration is consistent across all the teams as they share the same Releases and Sprint cadence.

How to work with it

See the screenshot below that shows the backlog view from the perspective of the Über Team, with the entire Product Backlog visible. Notice that we have switched the Forecast to ‘on’ so that we see how the combined teams are likely to progress through the backlog Sprint by Sprint.

The teams can jointly assess which stories should be considered for the upcoming Sprint and how they should be split between the teams and pulled (just in time) into each team’s Sprint Planning meeting. They will need to set each story they are going to consider for the next Sprint to their specific area path so that it will appear in their backlog and board views. Until they do this, they will have empty views! See PB06 above, it has been moved into both the new Sprint iteration path and the team’s area path.

To pull a backlog item into Sprint 1 is easy enough; simply drag the desired item to the sprint. The backlog item has to be edited though to select the team who are going to take it into Sprint Planning:

Having used the Über view to select backlog items for planning, teams can then switch to their own view so that they just get their own backlog items to which they can add tasks. Switching between the different team views is shown in the partial screenshot opposite. I’ve added some red marking to indicate the teams we’re currently interested in. Observe that the Über Team doesn’t actually have a name as it is the default team so it just goes by the Team Project name of Scrum03. In this example we are moving from the Über Team’s view to Team A’s view.

In the team backlog view, we select the new sprint and our selected backlog items should appear. If they don’t then either the area path or sprint selection may have been incorrect. In the screenshot below, look for the ‘+’ button to the left of each of the Product backlog items that enable tasks to be added in Sprint Planning.

We’re looking at the “Contents” tab in this example but you’ll notice that there is also a “Capacity” tab that enables the availability of each team member to be set for the sprint. This is what drives the numbers and bar charts that appear in the “Work” section of the contents tab – see the area to the right marked in red. With this feature we can see whether our team still has capacity to pull more work into the sprint.

Having planned a backlog item and confirmed that we have enough capacity to commit to the item, we move the state of the backlog item to “Committed” – see the red marker in the centre of the screenshot above.

Once the team get stuck into the sprint they have their own interactive “board” that allows them to track their progress and synchronise their work:

Multi-team configuration – Team Field Pattern 

This approach is very similar to the previous pattern except that we use a custom field rather than the area path to indicate which team has ownership of a given work item. From a usability point of view it is a very similar experience but with the major advantage that we can now use the area path for backlog categorisation.

The major disadvantage to the previous pattern is the amount of work you need put in to the initial setup of a Team Project to get this to work.

I’m going to try and save this blog from being the longest ever by simply highlighting the differences between the Team Field and Area Path patterns – most of this being in the Setup.

Setup

In this example, we have two teams, A Team  and Dilberts, working together against the same Product Backlog within a single Team Project, ScrumDemo04. This approach also requires the “Team of Teams” model and here we have the “Online” team setup as default team to enable an overall view of the Product Backlog.

In summary, what we need to do is:

1. Create a Global List look up for the team field
2. Configure the Team Project to use a custom field rather than the area path to support team selection
3. Setup a custom field type and associated UI configuration for each work item type that we will need to set the team ownership – at least the PBI and Bug
4. Map the teams that your Team Project will use

1. Create a Global List look up for the team field

The simplest way to create the team Global List is with the Process Editor tool, part of the TFS Power Tools. If you can’t use the Process Editor then there is always the command line and witadmin, using exportgloballist and importgloballist options along with some xml editing.

Here’s the Process Editor method:

2. Configure the Team Project to use a custom field rather than the Area Path to support team selection

Use the command line and witadmin with the exportcommonprocessconfig option to export the CommonProcessConfig.xml file and then edit the Team mapping from:    

<TypeField refname="System.AreaPath" type="Team" />

to something like:

<TypeField refname="RippleRock.TeamName" type="Team" />

"RippleRock.TeamName" is the custom field that will be added to each of the work item type descriptions to enable team selection from the teams in the Global List.

See the screenshot below:

After amending the team mapping and saving the file, re-import the updated CommonProcessConfig.xml using witadmin with the importcommonprocessconfig option.

3. Setup a custom field type and associated UI configuration

Use the Process Editor to add the team custom field type to each of the work item definitions that you care about and then expose the new field on the work item form so that it is visible in both Web Access and Visual Studio. Alternatively you can use witadmin from the command line and edit the xml directly if that makes you happy.

3.1 Adding the team field to the Product Backlog Item using Process Editor:

3.2 Set the Rules for the field so that it can only be populated from the Global List you setup in step 1:

3.3 Configure the layout or UI of the PBI work item to expose the Team field:

And here’s what the field looks like on the working PBI:

How to work with it

The screenshot below shows the backlog view from the perspective of the Online Team (the default team), with the entire Product Backlog visible and the Forecast option on. The only difference with the Area Path model is that we now have the team set by our custom field, while the area path is free to be used to categorise the backlog.

The teams will still need to switch views between the Online team and their own as they move to Sprint Planning and update the Team field of those PBIs they pull into their Sprint. Just like the Area Path model except that we now use the Team field instead of the area path.

Multi-team configuration – Iteration Path Pattern

If your teams can’t function without using the area path as a means of Product Backlog theming or categorisation or some teams need to have different dates for their sprints then try this pattern. This approach uses an extra level on the iteration path that allows both a holistic view of the product backlog but also allows the teams to view just their own items at the Sprint level. There is an Über team again but its only role is to support a combined forecast view of the overall backlog.

There is an issue with this approach however, the standard Release Burndown chart that ships with the template doesn’t seem to handle the extra level in the iteration path. It is fairly straightforward to use Excel Reporting to show a Release Burndown and there is an example shown towards the end of this paper. RippleRock are working on an alternative chart that will cater for this approach and works on a daily basis rather than sprint by sprint. We’re hoping to have this report available for on-premise TFS setups soon …

Setup

As in the previous example, we have two teams, The A Team and Dilberts, working together against the same Product Backlog within a single Team Project (ScrumDemo 01). In addition to the two Scrum teams, we also have the Online Team (like the Über team in the first example), who will be the “Team of teams”.

The major differences in this approach are in the area and iteration path configurations as we will see below.

The area path can be freely used to categorise the Product Backlog as per the example shown here.

This is the configuration for the whole online team. The team area path configuration can either match this or you can configure subsets for teams specialised to a part of the system. Obviously in Scrum, we encourage good cross-functional teams but in technologically diverse systems this is occasionally necessary.

Notice that with the area path selection, it can be configured such that sub-areas are included with the parent so that all the children are also accessible to the team. This functionality is not available for the iteration path.

The iteration path has additional level for “Team Sprints” under each of the standard sprint nodes.

This enables individual sprint start and end dates and also provides the team filtered data we need to drive the backlog and board views.

By default, new Product Backlog items are created at the node set to be the “Backlog iteration” for the default team, or Über team in our models.

To scope backlog items for a release, simply move them to the Release iteration path node – Online MVP in this example.

We are looking at the A Team’s iteration path configuration and we can see that they are set to only be able to see their “Team Sprints”.

Here we see that the team of teams view is configured to only see the parent sprints and not the individual team sprints. This is important as it will enable a nice combined team forecast on the overall backlog from the team of team’s backlog view

How to work with it

See the screenshot below that shows the backlog view from the perspective of the combined team of teams, with the entire Product Backlog visible. The Forecast feature is showing how the combined teams are likely to progress through the backlog sprint by sprint, based on the parent sprint nodes rather than the individual team sprints.

From the team specific backlog view we see only the sprints for that team but we also see the entire backlog. In the screenshot below, the team are dragging a backlog item into their sprint for planning.

The other team will also see the entire backlog, including those items that the A Team are planning – as you can see from the iteration path which is indicating which team has each item. Teams can pretty much stick with their own view for planning and working through the backlog and really don’t need to keep switching to the team of teams view as we did using the area path pattern.

As we can see from the A Team view of their planning, all the new backlog and board features work as Microsoft intended them:

The only wrinkle is that the Release Burndown report doesn’t cope with the team sprints. We will be making a day by day Release Burndown report available but it is really easy and quick to use the Excel Reporting capability of TFS to build one like this:

Summary

All three of these patterns are quite workable for supporting multiple teams within a single Team Project with a MS Scrum V2.x process template. My thoughts on each approach are:

• The Area Path model is my least favourite as it sacrifices a key categorisation facility and also offers a clunky user experience.
  
• The Team Model is a better model but it requires quite a bit of setup work and shares the same issue of user experience as the Area Path model.
  
• My personal favourite is the final pattern as it frees up the area path, has great flexibility of sprint configuration and a better user experience around Sprint Planning.

I’d be very interested to hear your opinions and experience too.

Tweet.

The performance of software delivery teams is so often undermined by team members being shared with other teams or regularly borrowed for operational support and other emergencies.

We know that small, collocated, cross functional teams provide optimum performance. So why is it so difficult to have a small group (7 +/- 2) dedicated and focused on one project at a time?

One major reason is that organisations have too much Work In Progress – WIP. Just count the number of in-flight projects and then count the number of teams available to deliver them. If there are more active projects than teams then there is too much WIP. Reducing the number of active projects results in a dramatic increase in the rate of value delivered to customers.

Let’s explore why spreading people across multiple projects is so detrimental:

Switching Cost

it takes time to get our head around a problem domain and then find the relevant bit of the system to work on. The more switching of business and technical domains, the more loss through spin up time. There is much research and writing on this topic, here are a couple of references: 

In their excellent book, PeopleWare, Tom DeMarco and Tim Lister describe: "flow”, a state of deep concentration necessary for “high-momentum” tasks such as engineering, design, development, and other aspects of building software. It takes 15 minutes or more to achieve this state and only a moment to lose it. Every time a team member is interrupted, it costs the company fifteen minutes while they re-enter a productive flow of work. 

In another great book,
Quality Software Management: Systems Thinking by Gerald Weinberg, he estimates that there is a switching cost of around 20% for every project that a team member is shared across. The impact of switching cost on a team member’s available time is illustrated nicely by this graphic:

Blocking

Solving complex problems requires close team work with swift collaboration. When a colleague switches to work with another team, any unfinished work they were involved with can block progress of fellow team members. In the worst case, the original team may have to wait for the team member to return before completing a highly specialist task. Over specialisation is another issue that drives organisations to share people across multiple teams but I’ll save that for a future blog.

Dilution

It takes a focused effort to gain and retain a sufficiently deep understanding of a complex business and technical domain. Attempting to achieve this feat across multiple simultaneous projects, leads to a shallow veneer of knowledge and a poor basis for smart decisions and design.

Excuses

Being shared across multiple projects erodes commitment by providing places to hide, and we hear this sort of thing: “Sorry I didn’t get my stuff done because I was working on the other project”.

Deployment Contention

In most organisations, fully live-like testing environments are rare and expensive resources that are vital to ensure the software is of sufficient quality to release to production. Like a crowd of people trying to get through a single small door, these environments become a bottleneck on a project’s journey to live deployment. The greater number of projects in-flight exacerbates this situation, leading to a queue of projects and delaying the delivery of value to customers.

Meeting Overhead

Very little software is actually developed in meetings so we try to minimise our meeting overhead to just enough and just in time. However, even with an Agile approach like Scrum it is necessary to spend some time in meetings; as much as 15.5 hours for one team member in a 2 week Sprint. The more teams a person is shared across, the less time they have to actually develop software – see the numbers below:

The numbers below are worked out assuming:

• Scrum
• Working time of 6 hours per day (minus breaks and non-project time)
• 2 week Sprint
• 60 hours available per person per Sprint

Meeting time per person per Sprint:
     Sprint Planning 4 hours
     Sprint Review 2 hours
     Sprint Retrospective 1 hour
     Backlog Refinement (10% max) 6 hours
     Daily Stand-up 2.5 hours
     Total 15.5 hours

Impact of meetings as numbers
of projects increase

Summary

Of course, all these problems tend to be cumulative. So for example, the reduced time for actual work caused by multiple projects is further compounded by the switching cost, leading to very little productive working time.

Organisations that accept shared team members as an inescapable reality, must also accept the reality that their teams are never going to perform as well as they would like.

So the bottom line; reduce the number of simultaneous projects and focus team members to one team and one project at a time to increase the flow of value delivered to customers.