Category Archives: ALM

Scaling Agile using Microsoft Visual Studio Team Services

When the Agile Manifesto was written about 16 years ago, it had a simple goal and that is to uncover better ways of writing software.


Writing software was and still is at the heart of it. In fact, the manifesto states that the primary measure of progress is a working software.

Small teams are able to easily adopt and adhere to these principles, since they usually don’t have historical processes and practices they are bound to.

However, larger organizations, have historically struggled in deriving the same value from Agile methodologies for a multitude of reasons.

In the recent years, there have been many strategies aiming to scale Agile for larger enterprises.

Business Mapping
all take different approaches at adapting agile to the realities of larger enterprises.

Whichever methodology you chose, keep in mind the original goal and the primary measure: Better Ways of Writing Software | measured by | A working software.

Let us choose SAFe as an example, and let us choose Visual Studio Team Services (VSTS) as a tool to implement it.


Out of the box, when you create a VSTS project, it lets you choose one of 3 default process templates: Scrum, Agile or CMMI.

You may be asking yourself:

Sample Implementation:

Imagine the following Organization Structure:

Let’s see how such an Organization would organize its work in VSTS.

The initial setup would lead to the following areas hierarchy:

In addition, we would have the following cadences (for instance):

Each team will choose their areas of interest, and they would subscribe to the cadence the will use to plan.

The Portfolio Team:

For this example, let’s consider the “Modern Portfolio” Team. The team would mostly focus on Envisioning Epics, describing them, and most importantly defining their value stream or funding source.

They could manage their work using a Kanban view which allows them to visually plan and track the stages of their Epics as well as their related implementation features.

(All Epics in this example are imaginary, and names were hidden)

Each epic is tagged using a combination of its value stream or funding source. As each epic gets decomposed by the different program teams, the portfolio team can then monitor progress and the value it accrues. Results are much better when a bottom approach is followed. Most of their planning activities can be done directly from the board.

The Portfolio team can monitor the flow of their backlog, to make sure they are working on the same amount of value at any stage of their lifecycle, and that their backlog is proactively populated. Hence, they might set their dashboard with indicators showing them how many Epics are being considered for each stage, and they would continuously monitor the cumulative flow diagram, but more importantly track the “Lead Time” for their Epics. This indicator shows them how fast are they able to take an idea from inception to market availability.

The Program Team:

The role of the program teams is to implement the vision and goals set by the portfolio team. They will be creating Features, Mapping them to Epics:

They will plan their work using program Increments:

They will track progress through their workflow stages using the Kanban board, allowing them to see the value they accrue via the implementation PBIs from different feature teams:

More importantly they will track Lead Time and Cycle Time to make sure their release train is on a healthy path.

The Feature Team:

Sometimes feature teams are also be referred to as implementation teams or products teams. They are mostly focused on implementing the Features defined by their parent program team and they do that by implementing Product Backlog Items and resolving bugs.

They plan using Sprints that belong to the parent Program Increment:

Their kanban board reflects the stages they go through to deliver a working Story or Bug:

Their dashboard would have KPIs From the Sprint Progress, Bugs Count, Testing Results, PBIs Lead and Cycle Times, Cumulative flow , Test Trends, Build History, Release Progress and Real Time telemetry from their production systems. In other words KPIs allowing them to answer the question: Do we have a working software?


All these teams would do shared planning and look at their delivery roadmap, across teams and across cadences:

Getting started with your DevOps journey

You have probably started to hear all the noise about DevOps. Most likely you fall into one of the following categories:

  • I have no idea what DevOps is.
  • Sounds promising. Where can I buy it?
  • We realize that it’s a journey and we have already started it.
  • Our team is way ahead in that journey and we are looking at ways produce even more value.

Regardless of which phase of that journey you’re actually in, there are few pillars that your organization has to go through.

Understand that this is an organization wide effort

If you walk into a room of 5 people and ask the question: What is DevOps? You will get 10 answers. Hence, it’s really important that your team, and more important your organization, has the same common understanding of what DevOps is. So what is it?

  • Development and Operation collaboration: form a team of highly motivated individuals and include all the required specialties to design/build/test/run/monitor your application.
  • Continuous delivery of value: Get your customers into the habit of continuously receiving new value from you at a regular cadence. Prioritize/balance customer input/feedback/market influence in selecting what comes next.
  • Automation and innovation at every phase of the lifecycle: Someone once told me a joke that goes: “If you don’t automate, machines get together at night and make fun of you”! . It’s a joke. But automation is about giving yourself enough time to work on what’s important. That is business value. Hence focus on automating anything that can be automated. Documentation, Testing, Deployment, Telemetry, Feedback are some of the areas where the industry has matured, you really don’t have to reinvent the wheel, unless that’s your business.
  • Small (miniscule) deployments: 5 lines of code are easier to deploy and fix in case of a problem than 5000 lines of code. Setting a similar target will drive your whole lifecycle to focus on small needs and small problems and split big goals and into small pieces.
  • Treating your infrastructure as code: This is another area where operations can help developers, but the overall team should focus on being able to reproduce or create environments from code. What you deploy should be idempotent, giving you one less variable to plan for.
  • Feature switches: Deploying a feature to production doesn’t mean it’s already live. You should have the ability to control when it can be seen, who can see it, what’s the percentage of my overall audience that I want to enable it for, and how do I learn from it.
  • (possibly) Kanban for Operations: Get your operation team to adopt the same visual application lifecycle tracking techniques that the planning team uses. Kanban offers a great way to do that.

Be willing to experiment

Understanding that DevOps is a journey and that each case will have its own context, constraints and complexities is crucial to your success. Often times I get asked “How does Microsoft do it”, I am glad to share, but that doesn’t mean that’s exactly how you should do it. You may be facing a case that is unique to your business or your industry. That means you should get inspired from others have done, but anchor it to your situation. Try new things, learn from their success and failure and adapt fast.

Challenge the status quo

“That’s not how we do it at….”, have you heard this before? Well you can’t expect to keep doing what you have done for 20 years and for some reason get different results. Entering such a journey, should not be simply because you heard it on the news, but because of a clear business need (Competition/Making the market/ or innovation). Therefore, new situations may require new solutions. And new needs should drive change. No one person should own the decision, but the group should drive towards what’s best for them.

It’s not about any one tool

While DevOps is not a tool you install or a product you buy. Tools and products will be a major part of it. Each of you will have a tool of preference, just like we all drive different cars. (I still believe my car is the best). But the most important part is the flow of data, and traceability from one phase of the cycle to the other. Why?

  • Smartly repeat yourself: If a new business need is similar to something you’ve done in the past. You should be able to easily trace it to the code you wrote, the test you automated, the (positive or negative) impact it had on your product and your customers.
  • Fix it fast: If you deploy this great new feature and it shuts down your system, then you should be able to easily point out Who/What/Where to get it fixed. DevOps practitioners call that MTTD (Median Time to Detect) & MTTR (Median Time to Resolution).
  • How fast can we get something out to the market: Can we trace the real effort it took us to get something out? (don’t think about it from a traditional project management perspective) but rather here is what we will have to do to deliver something.
  • Use what you have first, until it doesn’t meet your needs: Can the tool we have already do 80% of what we want?

Learn how to be data driven

Data insight can be a great way to make conversations objective. Are you measuring the right things? How do you measure Customer Satisfaction? How do you measure your ability to deliver fast? How do you measure your reaction to problems? How do you measure the productivity of your team? Set up the right KPIs, and stop using them when they stop driving change.

Don’t be scared of the word Cloud

Cloud can be a great enabler of many of the challenges you will face during your DevOps journey. Don’t be scared of it. Try to even go after it. Cloud is not about one specific public cloud provider. It could be an internal cloud. But distinguish between cloud and virtualization. If your team has to send an email or a fax or call an 800 number to get a VM, then you don’t have a cloud. It should be self-service, and should support automation.

Get help

“This all sounds too cool, let me go hire a consulting firm to help me get started.” There is nothing wrong with that, but you should be as involved as they are if not more. They should have lived this in the past, so that they are able to share real field experience.


Ilias Jennane

Tagged , ,

Managing your Backlog

In my previous post: I laid out the different phases of an agile project. As a reminder:

Hence during the envisioning phase we should focus on the Product Backlog, but at a high level. We should try to capture all the Stories/Product Backlog Item/Business Needs that will create your backlog. If you’ve been handed a 600 pages requirement document and you’ve told “We will use Agile, but we had to get all the requirements detailed upfront” then you may want to have a discussion about how agile the project is.

“How detailed should my Product Backlog Items (PBIs) be? (during the envisioning phase)”

At the envisioning phase you should have enough details to help you Understand and Estimate (at a high level) the work you need to do to reach the done state. After that estimation your backlog should look something like this:

This screenshot from a TFS 2012 demo project show some very important concepts. Every PBI has an effort, is assigned to a release (not a sprint) and the backlog is ordered by business value. This will allow you to Estimate cost and then if we are over what your stakeholders or your customers are willing to invest in that project, you can start to deprioritize into another release. Being able to order your PBIs by business value is critical, because if you don’t know the answer to what value that feature brings to the product or the project then you need to request more information. It’s an indicator for you to let you know whether you know enough about the project to envision it.

“How should my product backlog evolve”

The product backlog is a live list. It will evolve during the product lifecycle. During the Iterative implementation phase you can always glance at it to know what you have already achieved and how close you are from being done:

In the screenshot above, we are looking at the (Kanban) Board view of the Product during Sprint 3 of my Release 1. We can see what’s Done, What’s Committed and what’s not yet started. Stakeholder will be approving new PBIs as they get added to the backlog, reprioritizing them and your implementation team will be committing to them.

Keep an eye on how many PBIs you are consuming compared to new ones that get added to your backlog, that will tell you if you will make your initial release date, and more importantly what will make it or not. Here are few examples on how to do that:

1/ Using a cumulative Flow Report

2/ monitoring your team velocity (How many story points you are delivering per sprint):

3/ Forecasting when you will be done using an average velocity against your current backlog state:

This screen shows me that based on some velocity value I should be done in Sprint 6.

Your Sprint backlogs will be detailed to the task level and each PBI will have acceptance criteria (exit criteria):

At the sprint level the backlog has task estimations as well, that are not necessarily a match to the PBI estimate. These estimate impact directly your team capacity (green bars on the right).

Achieving Agility in a Waterfall World

Many of the customers I talked to during the past few years are either starting the process of becoming Agile or have been doing Agile for a long time. With very few distinctions, most of them have to plan their projects, monitor them, and report on them to upper management in a non-Agile way. Is that a problem? Are they truly being Agile? What does it take to become Agile? And what is the Return on Investment?

“We usually spend the first few months of our projects gathering detailed requirements”.

Does this sound familiar? If so, this should be a first flag that you are not truly agile. It doesn’t mean that you are doing anything wrong. It just means that your process doesn’t adhere to agile principles. If you wanted to ask what are these principles, then let’s take a moment and review them: . Specifically let’s focus on the following agile principle: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” Thus if you have spent a good chunk of your project initial months writing requirements are you going to welcome having them changes late in the game? Probably not. You are most likely going to push back as much as you can and you will most likely embark on a negotiation with your customers or stakeholders. Negotiating with stakeholders, or compromising, leads me to talk about another agile principle: “Customer collaboration over contract negotiation“. This is actually part of the original Manifesto: . It doesn’t means that we are going to just ‘accept’ whatever comes from stakeholders or customers, but the key is collaboration over negotiation. Do you have the right environment or framework to collaborate with your customers? If not try to evaluate how you can implement one that fits your context.

“We monitor how much time our developers spent on their tasks to pulse the project health: we have many reports to watch this data”

Usually these reports show mainly whether team members are working or not (you may disagree). Is it a good metric to measure the health of an agile project? Well let’s compare the data they would show to the following agile principle “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” If you are focused on how much time a developer spent on his/her task, are you implying that they should spend less time? Are you implying that they are not going as fast as they should? Probably a better metric is to monitor the remaining time, which will indicate to you how close you are to being done. The basis of the relationship among team members in an agile world is trust, motivation and empowerment. They real question you should be asking is do I trust my team? Do I trust that they are doing their best to get their tasks done correctly in the least possible time? Do I provide them with the support they need to get the job done? And last but not least, what is their motivation to work on your project. In addition there is an additional agile principle that is worth mentioning while we are on this topic: “Working software is the primary measure of progress“. Do you have the right metrics in place to measure whether your product is working? Working doesn’t mean that it runs only. It also means that it responds to my business needs and that it is providing the expected value while of course maintaining or enhancing its quality.

“Our team leads estimate the work based on their long expertise”

If that’s what you’re doing for estimate, are you taking in consideration everybody’s input? Are you being realistic? How is it working for you? Estimation is one of the hardest phases of a project, especially in an agile project. Your team leads are probably doing the best estimating a story that has very little details, they are not to blame if the estimation is off. While the agile principles don’t necessarily address estimation directly because the focus on the way we work to deliver value. However there are techniques that exist to help you get the best estimate possible. First of all the estimation should include everybody! If that’s not possible try to get representatives from every aspect of your project delivery team. Then trying playing poker! Yes it’s called Planning Poker. The idea is that using standardized values, some use Fibonacci numbers (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, and 100), some use T-shirt size, to estimate the complexity of a Story (or requirement) rather than the hours it would take. You will have some sort of mapping between these values (points) and the equivalent hours. For instance, your team will know that a value “3” means 16 hours. And for the rest of the estimation you will just focus on comparing other stories (in complexity) to that reference story. Everyone in the team will share what value they evaluate the current story at? If you don’t agree on the value it means you don’t have the same understanding, and that will triggers discussion that will have great business value, and will allow you to have shared knowledge about the project. You don’t see the value of doing so? The key is to make your estimation not decided by one person, takes in consideration all aspects of the project and remove the stress of estimating hours. There are sites such as that allow you to do your estimation online using this technique (ideal for remote teams).

We can’t possibly cover all what it would take to become agile or to achieve agility in one blog post, but I would like to use a Diagram to attempt to explain how you can be agile while not completely ignoring all your current methodologies:

If we think about a project or product as three major phases: Envisioning, Implementation and adoption. The activities during the envisioning phase are supposed to be conducted at a high level, while during the implementation we’re supposed to be as thorough as possible. Then of course while our customers adopt (or not) our product we should continuously be getting feedback, monitoring the health of our product, evaluation its needs to scale and implementing it and finally thinking about its next evolution based on all of these factors.

I will be address each of these activities in separate blog posts over the next few months, so Stay tuned!