September 21, 2015

Using TestTrack and the Scaled Agile Framework: Part 1

Helix ALM
Agile
Many organizations are realizing the value of organizing their efforts using Agile software development practices. This often leads to bigger questions about how to scale this approach and how to integrate Agile with other related enterprise practices, such as portfolio and project management. In other words, Agile is very good at delivering value as quickly as possible in a continuous flow, but how do we make sure that our Agile teams are working on the goals that our enterprise strategy has defined? How do we give the flexibility to our Agile teams that they need, while still making sure that we have the appropriate governance and budgeting directing their activities? It’s natural to define and communicate your vision, goals, strategies, and roadmaps as documents or perhaps in distinct PPM tools. The problem with this approach is that these are disconnected from your development process. This forces you to make a difficult choice:

A. Allow the Agile development teams the flexibility they need, but struggle to keep them connected to your strategic goals.

or

B. Impose an Agile-killing bureaucracy to ensure alignment.

TestTrack gives you the best of both worlds because of the way it allows you to create documents. When you create a document in TestTrack, each item in the document is also a record in the database. This means that once you create your vision and roadmap documents and finish your high-level assessment and approval, the items within these documents simply and naturally evolve into features, user stories, and—ultimately—working software.

The Scaled Agile Framework

The Scaled Agile Framework® (SAFe®) has some very good ideas around scaling Agile. I've taken their ideas as a framework to illustrate how to use TestTrack to scale and integrate Agile into your enterprise. The basic idea is that, because you have a completely connected end-to-end process in one tool, it is easy to get visibility and transparency. Throughout this series, I'll be referring to the sample project pictured below. [caption id="attachment_17557" align="aligncenter" width="975"]Sample TestTrack SAFe project Sample SAFe project in TestTrack[/caption] Before we go any further, I should say that this blog does assume some familiarity with SAFe. I don’t intend to (nor am I qualified to) explain the intricacies of this model. They explain it much better than I ever could here: http://www.scaledagileframework.com/. However, I am going to try and give just enough background about SAFe so that we are all on the same page. Here is how the good people at Scaled Agile Inc. visualize the Scaled Agile Enterprise: [caption id="attachment_17549" align="aligncenter" width="975"]CREDIT: ScaledAgileFramework.com The Scaled Agile Framework (CREDIT: ScaledAgileFramework.com)[/caption] I’m going to use their terminology and some of their processes to illustrate how you can use TestTrack to assist you as you move towards Scaled Agile. The SAFe model uses “epics” to mean the highest-level item to define what the software is going to do. A “feature” is the next level down, with each feature then broken down into one or more “stories.” See the diagram below, which shows the complete model. [caption id="attachment_17551" align="aligncenter" width="975"]Complete SAFe model The complete SAFe model[/caption] There are three main parts or stages defined in SAFe: Portfolio, Program, and Team. I’m going to walk you through how epics, features and user stories are used in these three stages. I am going to give you an overview of the process, but even so, this is a very large topic. I’ll cover Portfolio today, and the other two stages in future blog posts.

Stage 1: PORTFOLIO

[caption id="attachment_17553" align="aligncenter" width="975"]SAFe Portfolio In the Portfolio stage, you document your Vision. CREDIT: ScaledAgileFramework.com[/caption]

Vision Document

In the Portfolio stage, the first thing you do is document your Vision as themes, goals, initiatives, and epics within a TestTrack document. This is a simple and natural way of capturing, maintaining, and communicating the big picture of what you intend to do. Create TestTrack requirement types of themes and epics to create a document structured like the image below. Note that just by virtue of the natural process of arranging themes and epics in paragraphs (as shown in the image below), TestTrack automatically knows which epics belong to which theme. This really helps in organizing and visualizing your activity by theme later on. I’m going to follow Epic 1, “New CRM capabilities,” which I have highlighted throughout this blog series, so keep your eye on it! This epic is part of the “Become Leader in Customer Services” theme. Remember, too, that whenever you see EP-1 in TestTrack, it is the same record; you don’t have to worry about duplicating data from one place to another. This is true whether you are looking at a document, a Kanban board, a list view, or anywhere else. This is the key to ensuring seamless integration and visibility from top to bottom.   [caption id="attachment_17565" align="aligncenter" width="975"]Epic 1 in TestTrack Keep your eye on Epic 1, highlighted by the green box.[/caption]

Lightweight Business Case and Epic Value Statements

SAFe suggests that you add a lightweight business case and epic value statement for each epic you consider. It’s easy to do that in TestTrack. I suggest that you use the model templates (or your own) as default values in TestTrack to automatically put the correct templates into custom fields “Light Business Case” and “Epic Value Statement.” [caption id="attachment_17567" align="aligncenter" width="975"]TestTrack Custom Fields TestTrack with custom fields for "Epic Value Statement" and "Light Business Case"[/caption]

Use WSJF to score your epics

You need to figure out which epics you are going to sanction for the next stage, and in what order. You therefore need to figure out which is the most important one and whether each epic is going to be approved or not. SAFe suggests that you use “Weighted Shorted Job First” as a good way of scoring features, but I think it is not a bad way of evaluating epics, too. I’m sure some of you will shoot me down in flames for this, but whether you use this for features, epics, or both, it is relatively easy to implement in TestTrack. Add in a custom field for each of the factors in the calculation and a calculated field called “WSJF” derived from this. The calculation is defined as: [caption id="attachment_17568" align="aligncenter" width="975"]WSJF calculation WSJF calculation[/caption] A suitable list view for your epics allows you to enter the factors and see how that affects the score for each epic (or, later, features).   [caption id="attachment_17569" align="aligncenter" width="975"]TestTrack list view TestTrack list view[/caption]

Use a Kanban System to approve or reject Epics

Lightweight business cases, epic value statements, and WSJF values are all vital bits of information about your epic, but you need a way to manage the flow of epics as they appear in your Vision. You also need to control when work is done and data is added to your epic. There is no point, for example, in spending the effort on adding even a lightweight business case if the epic is a complete non-starter. SAFe suggests a Kanban process as the most suitable way of managing this, and also suggests a set of stages in this Kanban: Funnel, Under Review, Analysis, Backlog, Implementing, and Completed. Implementing a Kanban along these lines is really easy in TestTrack:

1. Create a folder in TestTrack to contain your epics. 2. Create your Kanban (task board) as shown below.

    [caption id="attachment_17571" align="aligncenter" width="975"]Kanban task board A Kanban task board in TestTrack[/caption] I would also recommend that you add an automation rule to automatically add each epic to this folder as soon as it is created. If you do that, then all your epics are immediately visible on your Kanban board as soon as you create them and appear in the first column, which is the “Funnel” column in SAFe. Note that you don’t need to do any additional grouping of your epics into themes. Epics are automatically grouped by theme in your Kanban (if you want them to be), simply because of the way you have organized your Vision document. The Kanban board is used to manage the flow of epics throughout their lifespan. Once they reach backlog, they are then ready for inclusion in the Program stage, where we use these Epic records are used as the main input. I’ll look at the Program stage in Part 2 of this series.