TFS as perfect tool for Scrum (Part 1) – Introduction in Scrum and TFS

This year I was invited again to present at Microsoft TechDays. This event is held every year in the World Forum in The Hague. This year I spoke about why TFS is the perfect tool for Scrum.

My session was about how to use TFS as tool for Scrum. I talked about the different stages of Scrum, and what TFS can do in these stages. For example, Where to put the Sprint Goal, How to Split up PBI’s etc.

For the people who speak Dutch, my session can be found on Channel 9 and the slides can be viewed here.

For all people who do not speak Dutch or who do not want to see slides or video alone this blog will be the answer. In the upcoming weeks, I will blog about this session. I will talk about how TFS can support the implementation of Scrum and walk you through the different stages.

1. Introduction in Scrum and TFS
2. Using TFS for grooming your Product Backlog
3. Using TFS in Sprint Planning
4. Using TFS in your Sprint
5. Using TFS in your Sprint Review and Retrospective

Today, Part 1 – Introduction in Scrum and TFS

Part 1 – Introduction in Scrum and TFS

Let’s start at the beginning. Before we dive into the details about how TFS is the perfect tool for doing Scrum, I want to explain a little bit about both Scrum and ALM. For most people reading this blog this is all obvious, but it is always a good practice to align some definitions.

What is Scrum?

“Scrum is a framework for developing and sustaining complex products”. This definition contains two parts which are essential. “Framework” and “Complex”

To stay in the analogy of rugby, I try to explain the term framework. Rugby is played with a predefined set of rules, within a field that is marked with lines and by a fixed number of people. However, the way how you play the game, defensive, offensive, tactical or strength based is not described in the rule book.

Same goes for Scrum. There is a predefined set of time boxes, artifacts and roles but you are free to operate within these boundaries. This is different from other development methodologies which describe how to deal with different situations etc.

“Complex” is the other term that needs a bit of attention. Scrum is suitable for complex situations. These are situation in outputs are often unpredictable and the exact outcomes cannot be predetermined. If we look a software development this is exact the case. To manage complex situations we need to use a suitable process control model. Scrum is a so-called empirical process control model, which is based on the fact that you constantly validate what you are doing and adjust your plans. So instead of trying to pre-define everything upfront, you embrace the fact that it is uncertain and about to change.

Scrum Process

This great picture from Chad Albrecht (http://blog.chadalbrecht.com/post/2011/10/24/Simple-Scrum-Diagram.aspx) describes Scrum in a nutshell.

If we start with the [Product Owner]. This guy is the representative of [customers and stakeholders]. He makes sure that all requirements and change requests are translated into tangible items. He puts all these items on the [Product Backlog] and prioritizes this list. The items with the most business value are put to the top. He is also responsible for the fact that items are well defined and that they contain acceptance criteria. Acceptance criteria are very important to validate the product that is built against the requirement.

During the [Sprint Planning] meeting the [Development Team] takes the top portion of the [Product Backlog] and puts this on the [Sprint Backlog]. The [Product Owner] explains the [Development Team] what he means and what goal he tries to achieve in the upcoming [Sprint]. Together is decided what items will be put on the [Sprint Backlog] and the [Development Team] starts their second part of the [Sprint Planning] meeting. They create tasks for every item which identify the actions that need to be done to convert the requirement into working software. After that the team estimates the work in hours.

When [Sprint Planning] is over, the [Sprint] starts. A [sprint] can be any length from 1 to 4 weeks. The most used sprint length is 2 weeks. The sprint length is something that you normally do not change over time. During the [sprint], the [Development Team] starts building the software. This includes everything to convert it to a “Done” product. And “done” means, potentially shippable. Developed, Tested, Documented etc. No work is needed anymore on these items. Every day a [Daily Scrum] is held. Team members tell each other 3 things.

• What have I done yesterday?
• What will I do today?
• What keeps me from doing my work?

If there is any problem (an impediment in Scrum] the [Scrum Master] is responsible for solving this. The [Daily Scrum] has a maximum time box of 15 minutes. During the [Sprint] all work is done including testing and Backlog grooming. Work for the next sprint will be validated and completed.

After the sprint, a piece of working software will be outputted. During [Sprint Review] this piece of software is demonstrated to the product owner and stakeholders and they will discuss what has been done and what will be done next. After Sprint Review the [Scrum team] comes together and holds a [Retrospective] meeting in which the process is discussed. What did we do well? What can we do better?

All feedback regarding the product is processed into Product Backlog Items. The [Scrum Master] processes the feedback of the retrospective to optimize the Scrum Process.

What is Application Lifecycle Management (ALM)

It is important to know what we are talking about when it comes to ALM in combination with TFS. See my earlier blog about the difference.

ALM is hard to explain by just stating a definition. That’s why I usually use the Product Lifecycle graph to put things a bit in context. If you want to know more about the Product Lifecycle, this link provides some good explanation). http://www.tomspencer.com.au/2009/01/25/product-life-cycle-model/

If we look at the graph we see Time and Sales on the axis. When you start building a product, you don’t have any sales. Even worse, you have costs. When the product matures, sales will hopefully increase and after a while, when people lose interest in your product, the sales will decrease again and eventually your product will be end of life.

I think that a high level description of Application Lifecycle Management are the arrows in this specific graph. Application Lifecycle Management deals with processes and tools to support the lifecycle of an application. ALM provides the tools to make people more productive (arrow to the left) so that you can build faster and deliver earlier. Then ALM helps you with the process to get insight in what your users want. Capturing user feedback and prioritize this and make this visible makes the product better, so more people will buy it (arrow up). And eventually the quality and flexibility of the product. By ensuring quality, your product can be updated frequently without jeopardizing the current version and flexibility ensures that ou can adjust easily so your product is feasible for a longer time.

If we then look at the definition of ALM (source: Wikipedia http://en.wikipedia.org/wiki/Application_lifecycle_management) it makes a little more sense.

Application Lifecycle Management (ALM) is a continuous process of managing the life of an application through governance, development and maintenance. ALM is the marriage of business management to software engineering made possible by tools that facilitate and integrate requirements management, architecture, coding, testing, tracking, and release management.

Team Foundation Server as ALM tool

If we look at Visual Studio Team Foundation Server (TFS) we can conclude that TFS has a lot of these aspects embedded.

The picture above shows a high-level overview of Visual Studio ALM and Team Foundation Server. Without talking about every single aspect, it is important to see that TFS is the foundation of everything. It contains central repositories and allows you to manage source, bugs, planning, build test etc. Within TFS you choose a process to work with, for example Scrum, and there are various clients that allow you to connect to your data that is stored in TFS.

The most important part is the green part. Extensibility. TFS delivers a lot of value out of the box, but is the extensibility part that makes TFS really great. All things that are not present, can be created or changed and that is exactly what you need to do to make TFS really “fit” in to your organization.

The Perfect Combination

Both Scrum and TFS are very popular. Various surveys and research reports emphasize that (e.g. Gartner’s Magic Quadrant) so one would say that the combination is automatically perfect. But is that the case?

What does TFS actually deliver when it comes to Scrum?

Let’s take a look at the picture below

TFS works with process templates. A Process Template can be seen as a blueprint for new projects in TFS. The blueprint contains Work Item Types, Documents, Reports, Configuration Settings etc.. TFS is not critical about the process you choose. You can follow any kind of methodology that you like whether it is RUP, Scrum, Agile, CMMI or else. The process template only contains templates and definitions for every template. The Scrum templates uses Work Item Types like Bug, Task, Product Backlog Item and Impediment and the template contains some reports (like Burndown and Velocity). Other templates use different definitions or reports but the underlying structure is exactly the same.

The extensibility and adjustability is great but is also maybe a disadvantage when comparing TFS with other (maybe more targeted) tools.

It’s all about the process

So no matter how much features and tooling TFS offers, it all comes down to the process and implementation. The choice for the Scrum template, does no guarantee a successful implementation of Scrum. In the first place because Scrum does not describe “how” to play and in the second place that TSF only offers you a part of the solution.

Aspects like how to deal with source control, builds, multiple feature teams, large Product Backlog items can all be managed with TFS. But the way How you manage is the bigger challenge.

In the upcoming blog posts I will walk you through the different time boxes of Scrum and give some insights in to how TFS can support this.

Resources

• Techdays 2013 – http://www.techdays.nl/
• Wikipedia definition – http://en.wikipedia.org/wiki/Application_lifecycle_management
• Gartner Magic Quadrant – (http://www.gartner.com/technology/reprints.do?id=1-1ASCXON&ct=120606&st=sb)
• Delta-N – http://www.delta-n.nl/producten_microsoft_visual_studio_alm.asp
• Delta-N SlideShare – http://www.slideshare.net/Deltanbv/team-foundation-server-als-perfecte-tool-voor-scrum-17104406
• Channel 9 session (Dutch) – http://channel9.msdn.com/Events/TechDays/Techdays-2013-the-Netherlands/Team-Foundation-Server-als-perfecte-tool-voor-SCRUM
• Product Lifecycle – http://www.tomspencer.com.au/2009/01/25/product-life-cycle-model/
• Implement TFS or ALM same or different? – https://osnabrugge.wordpress.com/2012/04/23/implement-tfs-or-alm-same-or-different/
• Agile blog of Chad Albrecht – http://blog.chadalbrecht.com/post/2011/10/24/Simple-Scrum-Diagram.aspx