The world is changing fast around us and so is the technology.
In our case we are heading into a large project that might take more than a year for an Internet facing Solution.
Taking a mixed team (strong engineering focus, small amount of experienced Developers, some external Developers and Testers) on the route to DevOps is a multi-step process. This blog post describes some examples of our challenges and how we solved them.
I want to start on how to approach such a project and a lot on our usage of Team Foundation Services and Visual Studio.
Setting up the basics
The Theory – the SAFe Framework
SAFe 4.0 describes the way we want to operate in the future.
The top layer of the SAFE framework defines the work with Strategic Themes and the creation of Value Streams. This is done by the Architects together with the Customer and the Management.
The following picture shows the “Portfolio” section, the functions and roles. Described additionally is how we are integrating this with Visual Studio Team Services (TFS). You can find the full framework here: http://www.scaledagileframework.com/
Following this logic this team is working with Customers and Partners to define improvement and changes that are created as TFS work items and reflected in the ITSM system.
The work items are then triaged by a Development team that is doing initial estimates on the development and Testing. This teams also plans bug improvements and gradual improvements together with Operations. The “Value Stream” describes how Solution Teams do their work
The lowest layer of SAFe describes how the work items in the backlog get sorted, understood and handed to an Agile Team for execution.
The work of these teams is set up in Sprints. A Sprint is a time unit in which no additional items are added, but a predefined set of work is finished. In TFS work items are first assigned to a sprint and it is worked out if the assigned resources have enough time to finish their tasks.
SAFe is a huge effort to implement! – we had to simplify it
In our case we have decided to standardize on Visual Studio Team Services as the tool to implement SAFe (yes, this is the online version https://www.visualstudio.com/team-services/).
We started with an agile template in TFS as described here https://www.visualstudio.com/en-us/docs/work/scale/scaled-agile-framework
Then comes the time to think about how you want to implement the structure of Epics, Feature, User Stories and Tasks as described by SAFe. Each piece has a logic, hierarchies and implications when being used. If you are a geeky, technical team you will always shift fast to the implementation and tend to skip some of the steps that you must follow – get external help early – a company like Crossmind and the framework Vision2code helps staying on track for getting through the steps from the Business requirements to the correct structure and the correct work items.
The following picture shows how they combine different approaches and can help guiding teams in the definition phase.
Preparing TFS/Visual Studio
TFS can be a tremendous help for Managing and working in an agile world. There are many things to think of when you start.
How to structure the way your team works
- Use Area and Iteration Path to structure work in teams
read more here (https://www.visualstudio.com/en-us/docs/work/customize/modify-areas-iterations)
- Give good guidance on how to use TFS early
- Assign responsible resources for clean-up
Think of the Project Management
A major part of a highly complex project is splitting tasks in workable chunks, understand dependencies and manage time and resources. One very important aspect is early estimations – the Management and the Customer are eager to know how long things will take…
I was working before with T-Shirt Sizing and found it to be extremely accurate. In our case we have also the challenge that the early definition of the work items is done by somebody that is not implementing the work item later.
T-Shirt sizing is using well known sizes (like S-M-L-XL) and is aligned in our case with the amount of hours.
These are the sizes we are using:
|L||8 hours||= 1 work day|
Developing code with a DevOps system rarely will have tasks in the one hour range. After coding, checking in and unit tests even small items tend to be in the 2.5 hours and higher.
We have created separate fields in TFS where the User chooses the T-Shirt size and we translate it into a value field in the background.
These T-Shirt sizes like described before are often estimated by an Architect and give a first indication in the Sprint planning to a Project Manager, e.g. if items with all their necessary dependencies do not fit in a sprint they have to be moved to the next one.
To be able to have an overview we have introduced these T-Shirt size fields on the Task and the User Story.
Why an estimation on the User Story?
Someone will cry out lout at this point – you don’t do this…. Let me describe why we decided to do this.
Earlier we have described that we follow the Story Mapping approach.
By using this you will end up with User Stories, not Tasks and keep the Business requirements in the focus rather than the technical solution.
The User Story allows me to create a work item that capture the requirements and an initial T-Shirt estimation on how long it might take to implement this. Later it can be broken down in detailed Tasks.
Using TFS Aggregator we are aggregating these T-Shirt size values to the next higher level and are able on the Feature and Epic to display a time and effort estimation for a qualified discussion with the Portfolio team (=Customers and Architects in SAFe).
By splitting the T-Shirt estimation in a separate field, I give the implementing Engineer the chance to do an estimation on his own when he is getting the work item assigned as part of a Sprint. Only against his own estimation he is held accountable.
The daily work with TFS
Working with TFS means doing a lot of refining, finalizing, follow-up and clean-up work.
- Queries and Reports
Queries are used to group items together for a team to see only their items.
They are also used to find incomplete items, refined items, items many people depend on and do clean-ups on a recurring schedule. Make sure you define and understand how fields are used and how queries can be written to find and filter the ones that still need work, were not touched for a long time, block others, are poorly documented and many more.
A lot of the quality of work is determined by the scrutiny of the people doing this work and their ability to catch issues early on.
Tags can be assigned to work items and allow grouping mechanisms that can be used by teams or individuals to mark items for later retrieval, add their own language markers and help in general to quickly add structures that can help manage large volumes of data.
I want to give an example: We found that many work items that are created actually needed some research up front before it is clear what actually has to be done. We introduced the “Research” Tag that shows that this is not actually the final work item but rather the placeholder for the work to determine the resulting work item. A Project Manager can filter work items with this Tag and chase their owners for completion and closure. Only items without this Tag will be considered for Sprint planning.
The Tags Manager we are using shows a Tag cloud and helps cleaning up Tags with typos, duplicates and other errors.
A Triage meeting is done with a small set of people that can make decisions within and across feature teams.
While many Users will work with TFS only the Triage meetings are the place to decide on moving work items to the various stages.
The following picture shows an example workflow of a work item, the transitions and probable reason codes.
Changes to the workflow
We needed to change the permissions and flow so that only the Triage teams are the Gatekeepers of progressing a work item further in the flow.
We introduced the “Accepted” State – where a “New” Work item first has to go through a Triage Team to be “Accepted” to be further refined and later to “Active” to begin the implementation.
For the Triage, we are using Kanban Boards. This is the picture of our Kanban Board as it is seen in Microsoft Teams.
Earlier I described that we added the “Accepted” State – this becomes a new column in the Kanban Board between “New” and “Active”
and only Triage members get permissions to move work items from “New” to “Accepted”.
We have added many modifications to the Cards to help for a better understanding during the Triage.
Our Triage teams are sitting down on a regular base and triage the newly created work items.
Resource Planning using Microsoft Project
We are using Microsoft Project right now (this might change) to get a list of triaged work items and plan the resources to implement them according to their availability like described in this blog post.
Also, we use Microsoft Project for some fast help in structuring dependencies
While there are many more things to write about I want to conclude this first Blog post in the DevOps world with the list of some of the tools that we are using in TFS;
- TFS Aggregator https://marketplace.visualstudio.com/items?itemName=Vaccanoll.TFSAggregator
- Pester Test Runner Build Task https://marketplace.visualstudio.com/items?itemName=richardfennellBM.BM-VSTS-PesterRunner-Task
- Spec Map https://marketplace.visualstudio.com/items?itemName=techtalk.specmap
- Tags Manager https://marketplace.visualstudio.com/items?itemName=YodLabs.TagsManager2
- Kanban Board
- Microsoft Teams Integration https://marketplace.visualstudio.com/items?itemName=ms-vsts.vss-services-teams
We have implemented the described steps above and are looking forward to a well-managed Project.
Author: Thomas Theiner