Skip to content

Feed aggregator

Help! Too Many Incidents! - Capacity Assignment Policy In Agile Teams

Xebia Blog - Wed, 08/20/2014 - 23:26

As an Agile coach, scrum master, product owner, or team member you probably have been in the situation before in which more work is thrown at the team than the team has capacity to resolve.

In case of work that is already known this basically is a scheduling problem of determining the optimal order that the team will complete the work so as to maximise the business value and outcome. This typically applies to the case that a team is working to build or extend a new product.

The other interesting case is e.g. operational teams that work on items that arrive in an ad hoc way. Examples include production incidents. Work arrives ad hoc and the product owner needs to allocate a certain capacity of the team to certain types of incidents. E.g. should the team work on database related issues, or on front-end related issues?

If the team has more than enough capacity the answer is easy: solve them all! This blog will show how to determine what capacity of the team is best allocated to what type of incident.

What are we trying to solve?

Before going into details, let's define what problem we want to solve.

Assume that the team recognises various types of incidents, e.g. database related, GUI related, perhaps some more. Each type of incident will have an associated average resolution time. Also, each type will arrive at the team at a certain rate, the input rate. E.g. database related incidents arrive 3 times per month, whereas GUI related incidents occur 4 times per week. Finally, each incident type will have different operational costs assigned to it. The effect of database related incidents might be that 30 users are unable to work. GUI related incidents e.g. affect only part of the application affecting a few users.

At any time, the team has a backlog of incidents to resolve. With this backlog an operational cost is concerned. This operational we want to minimise.

What makes this problem interesting is that we want to minimise this cost under the constraint of having limited number of resources, or capacity. The product owner may wish to deliberately ignore GUI type of incidents and let the team work on database related incidents. Or assign 20% of the capacity to GUI related and 80% of the available capacity to database related incidents?

Types of Work

For each type of work we define the input rate, production rate, cost rate, waiting time, and average resolution time:

 \lambda_i = \text{average input rate for type '$i$'}, \lambda_i = \text{average input rate for type '$i$'},

 C_i = \text{operational cost rate for type '$i$'}, C_i = \text{operational cost rate for type '$i$'},

 x_i = \text{average resolution time for type '$i$'}, x_i = \text{average resolution time for type '$i$'},

 w_i = \text{average waiting time for type '$i$'}, w_i = \text{average waiting time for type '$i$'},

 s_i = \text{average time spend in the system for type '$i$'}, s_i = \text{average time spend in the system for type '$i$'},

 \mu_i = \text{average production rate for type '$i$'} \mu_i = \text{average production rate for type '$i$'}

Some items get resolved and spend the time s_i = x_i + w_is_i = x_i + w_i in the system. Other items never get resolved and spend time  s_i = w_i s_i = w_i in the system.

In the previous blog Little's Law in 3D the average total operational cost is expressed as:

 \text{Average operational cost for type '$i$'} = \frac{1}{2} \lambda_i C_i \overline{S_i(S_i+T)} \text{Average operational cost for type '$i$'} = \frac{1}{2} \lambda_i C_i \overline{S_i(S_i+T)}

To get the goal cost we need to sum this for all work types 'i'.


The process for work items is that they enter the system (team) as soon as they are found or detected. When they are found these items will contribute immediately to the total operational cost. This stops as soon as they are resolved. For some the product owner decides that the team will start working on them. The point that the team start working on an item the waiting time w_iw_i is known and on average they spend a time x_ix_i before it is resolved.

As the team has limited resources, they cannot work on all the items. Over time the average time spent in the system will increase. As shown in the previous blog Why Little's Law Works...Always Little's Law still applies when we consider a finite time interval.

This process is depicted below:

new doc 13_2

 \overline{M} = \text{fixed team capacity}, \overline{M} = \text{fixed team capacity},

 \overline{M_i} = \text{team capacity allocated to working on problems type '$i$'}, \overline{M_i} = \text{team capacity allocated to working on problems type '$i$'},

 \overline{N} = \text{total number of items in the system} \overline{N} = \text{total number of items in the system}

The total number of items allowed in the 'green' area is restricted by the team's capacity. The team may set a WiP limit to enforce this. In contrast the number of items in the 'orange' area is not constrained: incidents flow into the system as they are found and leave the system only after they have been resolved.

Without going into the details, the total operational cost can be rewritten in terms of x_ix_i and w_iw_i:

(1)  \text{Average operational cost for type '$i$'} = \frac{1}{2} \lambda_i C_i \overline{w_i(w_i+T)} + \mu_i C_i \overline{x_i} \,\, \overline{w_i} + \frac{1}{2} \mu_i C_i \overline{x_i(x_i+T)} \text{Average operational cost for type '$i$'} = \frac{1}{2} \lambda_i C_i \overline{w_i(w_i+T)} + \mu_i C_i \overline{x_i} \,\, \overline{w_i} + \frac{1}{2} \mu_i C_i \overline{x_i(x_i+T)}

What are we trying to solve? Again.

Now that I have shown the system, defined exactly what I mean with the variables, I will refine what exactly we will be solving.

Find M_iM_i such that this will minimise (1) under the constraint that the team has a fixed and limited capacity.

Important note

The system we are considering is not stable. Therefore we need to be careful when applying and using Little's Law. To circumvent necessary conditions for Little's Law to hold, I will consider the average total operational cost over a finite time interval. This means that we will minimise the average of the cost over the time interval from start to a certain time. As the accumulated cost increases over time the average is not the same as the cost at the end of the time interval.

Note: For our optimisation problem to make sense the system needs to be unstable. For a stable system it follows from Little's Law that the average input rate for type i is equal to the average production rate for type 'i'. In case there is no optimisation since we cannot choose those to be different. The ability to choose them differently is the essence of our optimisation problem.

Little's Law

At this point Little's Law provides a few relations between the variables  M, M_i, N, w_i, x_i, \mu_i, \lambda_i M, M_i, N, w_i, x_i, \mu_i, \lambda_i . These relations we can use to find what values of M_iM_i will minimise the average total operational cost.

As described in the previous blog Little's Law in 3D Little's Law gives relations for the system as a whole, per work item type and for each subsystem. These relations are:

 \overline{N_i} = \lambda_i \,\, \overline{s_i} \overline{N_i} = \lambda_i \,\, \overline{s_i}

 \overline{N_i} - \overline{M_i} = \lambda_i \,\, \overline{w_i} \overline{N_i} - \overline{M_i} = \lambda_i \,\, \overline{w_i}

 \overline{M_i} = \mu_i \,\,\overline{x_i} \overline{M_i} = \mu_i \,\,\overline{x_i}

 M_1 + M_2 + ... = M M_1 + M_2 + ... = M

The latter relation is not derived from Little's Law but merely states that total capacity of the team is fixed.

Note that Little's Law also has given us relation (1) above.


Again, without going into the very interesting details of the calculation I will just state the result and show how to use it to calculate the capacities to allocate to certain work item types.

First, for each work item type determine the product between the average input rate (\lambda_i\lambda_i) and the average resolution time (x_ix_i). The interpretation of this is the average number of new incidents arriving while the team works on resolving an item. Put the result in a row vector and name it 'V':

(2)  V = (\lambda_1 x_1, \lambda_2 x_2, ...) V = (\lambda_1 x_1, \lambda_2 x_2, ...)

Next, add all at the components of this vector and denote this by ||V||||V||.

Second, multiply the result of the previous step for each item by the quotient of the average resolution time (x_ix_i) and the cost rate (C_iC_i). Put the result in a row vector and name it 'W':

(3)  W = (\lambda_1 x_1 \frac{x_1}{C_1}, \lambda_2 x_2 \frac{x_2}{C_2}, ...) W = (\lambda_1 x_1 \frac{x_1}{C_1}, \lambda_2 x_2 \frac{x_2}{C_2}, ...)

Again, add all components of this row vector and call this ||W||||W||.

Then, the capacity to allocate to item of type 'k' is proportional to:

(4)  \frac{M_k}{M} \sim W_k - \frac{1}{M} (W_k ||V|| - V_k ||W||) \frac{M_k}{M} \sim W_k - \frac{1}{M} (W_k ||V|| - V_k ||W||)

Here, V_kV_k denotes the k-th component of the row vector 'V'. So, V_1V_1 is equal to \lambda_1 x_1\lambda_1 x_1. Likewise for W_kW_k.

Finally, because these should add up to 1, each of (4) is divided by the sum of all of them.


If this seems complicated, let's do a real calculation and see how the formulas of the previous section are applied.

Two types of incidents

As a first example consider a team that collects data on all incidents and types of work. The data collected over time includes the resolution time, dates that the incident occurred and the date the issue was resolved. The product owner assigns a business value to each incident which corresponds to the cost rate of the incident which in this case is measured in the number of (business) uses affected. Any other means of assigning a cost rate will do also.

The team consist of 6 team members, so the team's capacity MM is equal to 12 where each member is allowed to work on a maximum of 2 incidents.

From their data they discover that they have 2 main types of incidents. See the so-called Cycle Time Histogram below.

new doc 13_9

The picture above shows two types of incidents, having typical average resolution times of around 2 days and 2 weeks. Analysis shows that these are related to the GUI and database components respectively. From their data the team determines that they have an average input rate of 6 per week and 2 per month respectively. The average cost rate for each type is 10 per day and 200 per day respectively.

That is, the database related issues have: \lambda = 2 \text{per month} = 2/20 = 1/10 \text{per day} \lambda = 2 \text{per month} = 2/20 = 1/10 \text{per day} ,  C = 200 \text{per day} C = 200 \text{per day} , and resolution time  x = 2 \text{weeks} = 10 \text{days} x = 2 \text{weeks} = 10 \text{days} . While the GUI related issues have:  \lambda = 6 \text{per week} = 6/5 \text{per day} \lambda = 6 \text{per week} = 6/5 \text{per day} ,  C = 10 \text{per day} C = 10 \text{per day} , and resolution time  x = 2 \text{days} x = 2 \text{days} .

The row vector 'V' becomes (product of \lambda\lambda and xx:

 V = (1/10 * 10, 6/5 * 2) = (1, 12/5) V = (1/10 * 10, 6/5 * 2) = (1, 12/5) ,   ||V|| = 1 + 12/5 = 17/5 ||V|| = 1 + 12/5 = 17/5

The row vector 'W' becomes:

 W = (1/10 * 10 * 10 / 200, 6/5 * 2 * 2 / 10) = (1/20, 12/25) W = (1/10 * 10 * 10 / 200, 6/5 * 2 * 2 / 10) = (1/20, 12/25) ,  ||W|| = 1/20 + 12/25 = 53/100 ||W|| = 1/20 + 12/25 = 53/100

Putting this together we obtain the result that a percentage of the team's capacity should be allocated to resolve database related issues that is equal to:

 M_\text{database}/M \sim 1/20 - 1/12 *(1/20 * 17/5 - 1 * 53/100) = 1/20 + 1/12 * 36/100 = 1/20 + 3/100 = 8/100 = 40/500 M_\text{database}/M \sim 1/20 - 1/12 *(1/20 * 17/5 - 1 * 53/100) = 1/20 + 1/12 * 36/100 = 1/20 + 3/100 = 8/100 = 40/500

and a percentage should be allocated to work on GUI related items that is

 M_\text{GUI}/M \sim 12/25 - 1/12 *(12/25 * 17/5 - 12/5 * 53/100) = 12/25 - 1/12 * 9/125 = 12/25 - 3/500 = 237/500 M_\text{GUI}/M \sim 12/25 - 1/12 *(12/25 * 17/5 - 12/5 * 53/100) = 12/25 - 1/12 * 9/125 = 12/25 - 3/500 = 237/500

Summing these two we get as the sum 277/500. This means that we allocate 40/237 ~ 16% and 237/277 ~ 84% of the team's capacity to database and GUI work items respectively.

Kanban teams may define a class of service to each of these incident types and put a WiP limit on the database related incident lane of 2 cards and a WiP limit of 10 to the number of cards in the GUI related lane.

Scrum teams may allocate part of the team's velocity to user stories related to database and GUI related items based on the percentages calculated above.


Starting with the expression for the average total operational cost I have shown that this leads to an interesting optimisation problem in which we ant to determine the optimal allocation of a team's capacity to different work item type in such a way that it will on average minimise the average total operation cost present in the system.

The division of the team's capacity over the various work item types is determined by the work item types' average input rate, resolution time, and cost rate and is proportional to

(4)  \frac{M_k}{M} \sim W_k - \frac{1}{M} (W_k ||V|| - V_k ||W||) \frac{M_k}{M} \sim W_k - \frac{1}{M} (W_k ||V|| - V_k ||W||)

The data needed to perform this calculation is easily gathered by teams. Teams may use a cycle time histogram to find appropriate work item types. See this article on control charts for more information.


Categories: Companies

BE Agile before you Become Agile

Xebia Blog - Wed, 08/20/2014 - 21:49

People dislike change. It disrupts our routines and we need to invest to adapt. We only go along if we understand why change is needed and how we benefit from it.
The key to intrinsic motivation is to experience the benefits of the change yourself, rather than having someone else explain it to you.

Agility is almost an acronym for change. It is critical to let people experience the benefits of Agility before asking them to buy into this new way of working. This post explains how to create a great Agile experience in a fun, simple, cost efficient and highly effective way. BEing agile, before BEcoming agile!

The concept of a “Company Innovation Day”

Have you seen this clip about Dan Pinks’ Drive? According to him, the key factors for more motivation and better performance are: autonomy, mastery and purpose.
If you have some scrum experience this might sound familiar, right? That is because these 3 things really tie in nicely with agile and scrum, for example:

Autonomy = being able to self-direct;
• Let the team plan their own work
• Let the team decide how to best solve problems

Mastery = learning, applying and mastering new skills and abilities, a.k.a. "get better at stuff";
• Retrospect and improve
• Learn, apply and master new skills to get achieve goals as a team.

Purpose = understanding necessity and being as effective as possible;
• Write user stories that add value
• Define sprint goals that tie in to product- and business goals.

In the clip, the company "Atlassian" is mentioned. This is the company that makes "JIRA", one of the most popular Agile support tools. Atlassian tries to facilitate autonomy, mastery and purpose by organizing one day per quarter of “management free” innovation. They call it a “ship it day”.

Now this is cool! According to Dan, their people had fun (most important), fixed a whole array of bugs and delivered new product ideas as well. They have to ship all this in one day, again showing similarities with the time boxed scrum approach. When I first saw this, I realized that this kind of fast delivery of value is pretty much something you would like to achieve with Agile Scrum too! Doing Scrum right would feel like a continuous series of ship it days.

My own experience with innovation days

Recently I organized an innovation day with a client (for tips see on how to organize yours, click here). We invited the whole department to volunteer. If you didn’t feel like it, you could just skip it and focus on sprint work. Next we promoted the day and this resulted in a growing list of ideas coming in.
Except for the framing of the day, the formation of ideas and teams was totally self-organized and also result driven as we asked for the expected result. Ultimately we had 20 initiatives to be completed in one day.
On the day itself, almost everyone joined in and people worked hard to achieve results at the end of the day.
The day ended in presenting the results and having pizzas. Only some ideas just missed the deadline, but most were finished including usable and fresh new stuff with direct business value. When looking at the photos of that day it struck me that 9 out of ten photos showed smiling faces. Sweet!

The first innovation day was concluded with an evaluation. In my opinion evaluation is essential, because this is the perfect moment discuss deeper lessons and insights. Questions like; “how can we create the innovation day energy levels during sprints”, and “how can we utilize self-organizing abilities more” are invaluable as they could lead to new insights, inspiration and experiments for day-to-day operations.

The value of an innovation day as a starting point for Agile

All in all, I think an innovation day is the perfect way to get people experiencing the power of Agile.
Doing the innovation day on “day one” offers huge benefits when added to standard stuff like training and games. This is because the context is real. You have a real goal, a real timebox and you need to self-organize to achieve the desired result.
People doing the work get to experience their potential and the power of doing stuff within a simplified context. Managers get to experience unleashing the human potential when they focus only on the context and environment for that day.
I can only imagine the amazement and renewed joy when people experience the possibilities coming from a strong waterfall setting. All that good stuff from just a one-day investment!


It would be great if you would start out an Agile change initiative with an innovation day. Get people enthusiastic and inspired (e.g. motivated for change) first and then tell them why it works and how we are going to apply the same principles in day-to-day operations. This will result in less friction and resistance and give people a better sense for where they are heading.

Do you want to start doing innovation days or do you want to share your experience, feel free to leave a comment below.

Categories: Companies

Mental Health in the Tech Workplace

Derick Bailey - new ThoughtStream - Wed, 08/20/2014 - 20:25


15 years ago I went through a pretty serious bout of depression. I all but stopped eating, going to classes, and hanging out with my friends. I lost 40lbs that year from not eating enough, felt like there was no hope and thought I would never be able to get through anything, ever again.

Through various friends and other means, I eventually came out of it. But this wasn’t the first or last time I dealt with depression. It had happened before, and it has happened again in more recent times.

Even now, you can hear artifacts of my depression when I get frustrated with entrepreneurial life. It’s always there in the background for me, even if it’s not completely overwhelming like it is for so many others.

It can be hard to know what to do to get help… or even want to get help, because of the stigma against mental health in our societies and cultures. So I’ve asked Ed Finkler – someone who has dealt with these issues much more often than I have, and has been working to help educate the technology community about mental disorders - to provide some information and resources for those that may need it.

- Derick

My name is Ed Finkler. I’ve been a web developer for nearly 20 years, and I’ve been writing code for web applications for about 15. I’m a father, and I’m a husband. I am on a local school board. I founded an open source discussion group in my city. I also have something called Generalized Anxiety Disorder, and Adult Attention Deficit Disorder. I have also dealt with extended bouts of depression for the last 26 years.

There are a lot of people who have disorders like mine. Together they are called “mental disorders,” and in the United States 1 in 5 people deal with a mental disorder every year. The most common ones are anxiety disorders, like mine.Every day, I take a combination of medications that help me cope with my condition. I also see a therapist every couple weeks. This combination of psychotherapy and meds gives me more control over my anxiety and attention disorders. They are always there, but they don’t have the same debilitating impact they would if I didn’t get help.

My anxiety disorder has manifested in numerous ways:

  • Between the ages of 20 and 30, I suffered from irritable bowel syndrome (IBS), and was so afraid of being away from a bathroom that I rarely spent more than 15 minutes in a car. I was terrified to travel anywhere, even an hour drive to visit family. The anxiety made the IBS worse, and the IBS made my anxiety worse, ad infinitum.
  • I’m very scared to go places where I don’t know the “rules” or social etiquette. I’m terrified to get on public transportation because I think I will not understand how to pay or where to get off. I am scared to walk into unfamiliar bars or pubs, even if I know friends are waiting for me, for similar reasons.
  • When I have a lot of things going on, I often feel overwhelmed, and I become extremely irritable. I will yell at friends and family. I want to break things and scream and tell everyone I know and love to go to hell. It will make everyone I see an enemy, and everything I enjoy useless and empty. When I get like this, I often have to spend an extended period by myself until the emotions pass, for fear of lashing out at the people I love.
  • I construct elaborate negative outcomes quickly, often to benign triggers. If my boss writes me an email and says he needs to talk to me about something on Monday, I am apt to spend the entire weekend obsessing over the meaning, unable to enjoy anything, and convinced that I’m getting fired and will lose our house.

My Attention Deficit Disorder (ADD) was diagnosed when I was an adult, but I’m quite certain I had it as a child. I had lots of problems staying focused on tasks that didn’t interest me, and would become frustrated extremely quickly with schoolwork that wasn’t immediately obvious. It was a challenge all the way through college for me to balance multiple subjects. In my high school class I had one of the lowest GPAs, and one of the highest SAT scores. I have spent entire weeks of work not accomplishing anything because I didn’t want to do some semi-tedious tasks. I have hated myself for it, because I *knew* I was capable of doing the work, but I could not make myself to do it. I’ve often felt that I could accomplish so much more if I could just make myself do what I knew I should. This is incredibly frustrating and demoralizing.

The worst part of all of it was feeling like no one else was like me. For many, many years, throughout high school and college and well into my thirties, I was convinced that I was broken, and I will never be right. I believed that I was not capable of coping with life, because things always seemed to go wrong. I always screwed it up. Happiness never lasted. It would always be ruined, and it would always die. This was the pit of depression I would find myself in, where I could be in a room full of people but feel completely alone, because no one understood. No one was like me. There was no hope.

Turns out, I was not alone. There are a lot of people like me, dealing with anxiety disorders or depression or substance abuse or other kinds of mental disorders. 20% of Americans have one in any given year. As measured by years lost to disease (YLD),mental disorders are the most important cause of disability *worldwide*, accounting for a third of YLD in adults.

But most of them are scared to talk about it. Only 41% of people with a mental disorder get professional help. Help is available, but because we aren’t talking about mental health openly, and we don’t put the time in to educate ourselves about resources, people don’t get what they need. So they stay sick, and suffer unnecessarily.

In the workplace, those with mental disorders fear the consequences of speaking about their conditions with supervisors. They’re scared of being misunderstood, feared, or labeled as lazy or difficult to work with.

Right now, there are members of your team dealing with a mental disorder. They’re probably afraid to talk about it, and they probably don’t know how to get help.

As developers, we need to change the culture of our workplace. We need to speak openly about mental health. We need to learn what resources are available for ourselves and our coworkers, and we need to know how to help each other when we.

That’s why I strongly advocate taking a Mental Health First Aid (MHFA) course. I’ve done it myself. Here in Indiana, it took 8 hours and cost me $50. While I’ve been dealing with mental illness for over 25 years, I learned *tons* of new stuff in this course, and realized several mistakes I was making when helping someone having a mental health related crisis.

At the next team meeting, bring this MHFA. Explain what it’s about. Ask your manager if it’s okay to take a day and get certified. After you take your course, take 10 minutes to tell the team what you learned, and explain that they can talk to you if they need help.
Someone *will* want to talk to you. You will be able to help them.

Mental Health First Aid is available in 23 countries. Please, take a few minutes to learn where you can take a course. You *will* change people’s lives for the better because of it. Maybe even your own.

Ed Finkler, also known as Funkatron, started making web sites before browsers had frames. He does front-end and server-side work in Python, PHP, and JavaScript. Along with Chris Hartjes, Ed is co-host of the Development Hell podcast.

Ed’s current passion is raising mental health awareness in the tech community with his Open Sourcing Mental Illness speaking campaign. He is part of Engine Yard’s Prompt campaign.

Ed writes at

     Related Stories 
Categories: Blogs

Capitalization of Software Development Costs with SAFe

Agile Product Owner - Wed, 08/20/2014 - 19:27

There has been a long running thread in the SPC (and broader) community with respect to capitalization of software development costs in Agile. These practices are well established in waterfall, as the up-front requirements and design phases represent clear stage gates that must be passed before capitalization can occur. In Agile however, these activities are continuous, so the means for capitalization is not so clear. And as we know, when “how to do X in Agile without affecting our financial reporting” is not clear, then your Agile initiative may be stopped before it is started!

To this end, after much input from the community and background work on our own, we have drafted a Capitalization article, which is included in Guidance. If you would like to contribute to the topic, please post your comments on this blog post so that we get some further input before the next revision.

As always, thanks for the input that makes SAFe safe.


Categories: Blogs

You shall not pass – Control your code quality gates with a wizard – Part I

Danube - Wed, 08/20/2014 - 14:50
You shall not pass – Control your code quality gates with a wizard Now as easy as designing an email filter

Every project has different policies defining when code can be pushed into production. CollabNet’s code quality gate wizard for Gerrit comes with a bunch of predefined policies and lets you graphically design your own quality gates as easy as defining email filter rules.

Four-eye peer review, legal has to approve copyright file changes, senior staff has to approve the work of juniors, democratic feature voting? – Regardless of what your code quality gates look like, chances are very high you can now enforce it without having to write a single line of code.

What are Quality Gates – And Why should I care?

concept 22 You shall not pass   Control your code quality gates with a wizard   Part I

Quality Gates applied before commits get directly pushed into production

The days where version control was just a passive component where you store your source code are long gone. In the world of continuous integration and delivery, version control is an active component, typically the first step in a (semi) automated pipeline straight through production. This pipeline is typically automatically triggered whenever a commit gets merged into master (or any other branch used for production). If a commit that does not meet audit compliance or production quality gets merged accidentally, this can have immediate effect on your business. In the worst case, you face data loss, customers cannot interact with your business anymore or you are getting sued for having introduced a security hole or serious malfunction.

Code quality gates define the conditions to be met before a commit can be merged into master, i.e. when code is ready to be pushed for production. Typically those conditions are a mixture of automated checks like passing unit and integration tests, code quality and guideline checkers as well human checks like peer review, approval from legal and product management.

Having those rules automatically enforced is a big win for every team as it will make sure you always have the quality level and compliance conformance you need in production.

With CollabNet’s new quality gate wizard for Gerrit – TeamForge’s Git backend – you can now select from a number of predefined policies (best practices quality gates) which will be automatically enforced once deployed. In addition, you can design your own quality gates without having to write a single line of code. The way it works is very similar to email filter rules: You define the characteristics of a commit and related context (like associated peer reviews and feedback from code quality tools, system and integration tests) and decide whether under those conditions the commit can go in or not. You can even point to already existing commits and their context to automatically create quality gates and simulate them within the wizard.

This blog post series consists of three blogs. In the first one (the one you are reading right now), you will learn how to install the quality gate wizard and how to deploy the out of the box policies (collection of best practice quality gates), that come with the wizard.

In the second blog post, you will learn how to design your own quality gates based on the email filter metaphor. Furthermore, you will get an answer on how to define and distribute your own best practice policies for your organization.

The third blog post gets pretty technical and will dive into the more advanced concepts of the wizard, like defining filters on commit characteristics, counting peer review and CI votes. It will also explain the specifics of the language that is generated by the wizard to implement the quality gates.

With that said, let’s jump right in.

Make sure your Git/Gerrit Backend supports Quality Gates

If you are using TeamForge with our Git/Gerrit integration version 8.2.0 or higher, the quality gate backend is already installed. Otherwise, you would have to upgrade to this version which is supported by both TeamForge 7.1 as well as TeamForge 7.2. More details can be found on

Installing the code quality gate wizard

Designing code quality gates is a feature for power users. For that reason, we decided to implement the first version of the wizard inside our CollabNet Desktop for Eclipse and GitEye. If it turns out that you really love this feature and need a Web UI for it, we can make that happen too. As usual, just drop a comment in this blog post for any kind of feedback.

You can install any of the tools mentioned, my colleague Steve wrote two blog posts on how to install GitEye and how to set it up with TeamForge and Gerrit. If you already have GitEye or any other Eclipse based application installed and want to add the Quality Gate Wizard, point Eclipse to our update site and install all plugins available there.

Opening the quality gate wizard and selecting a predefined policy

Once you have installed GitEye or CollabNet’s Desktop for Eclipse and configured your TeamForge site, let’s navigate to the Git repository where you want to deploy some quality gates. Right click on the repository of your choice (in our case TeamForge-Git-Integration) and select the option Define Gerrit Review Rules …

 You shall not pass   Control your code quality gates with a wizard   Part I

A screen similar to the one depicted below will open. Within that screen, the option Load from template is already pre-selected. It contains a number of predefined policies (collection of best practice quality gates). The one we are using is called Relaxed 4 Eye Principle and 1+1.

 You shall not pass   Control your code quality gates with a wizard   Part I

You can skip over the details of this policy now, but if you are interested, here are the quality gates enforced:

  • Every commit has to be verified by a continuous integration (CI) system like Jenkins. The job of this system is to ensure that the code compiles, unit, integration and system tests are running through fine and all coding guidelines and code quality metrics are satisfied.

  • Every commit has to be peer reviewed by at least one person other than the author of the commit (4 Eye-Principle)

  • If a peer reviewer vetoes the commit, it cannot go in

  • If at least one reviewer strongly approves the commit (Code-Review +2) or at least two reviewers agree that the commit has reasonable quality (sum of Code-Review votes >=2), the commit can be merged if all conditions above are satisfied

We chose this policy as an example as this is the one we are internally following while developing our TeamForge-Git-Integration.

Testing the policy in the wizard

Once you click Finish in the wizard, an editor will open within Eclipse. We will cover most of its functionality in subsequent blog posts. For now, all we need to know are two buttons: Test Against Gerrit Change and Deploy to Gerrit. With the first one, you can test your quality gates against any commit not yet merged into a branch (to be more technically precise, any Gerrit change). The screenshot below shows how the current selection of quality gates would react to a particular commit. In the case below, the continuous integration system which tried to build the commit, ran unit and integration tests and checked code quality metrics, voted against the commit, so it cannot be pushed into production in its current form (red traffic lights). The yellow traffic lights indicate that no quality gate vetoed against the particular commits but there are still elements missing in order to let it pass (CI feedback or peer review feedback from a non-author). One commit (associated with Gerrit change 1985) has a green traffic light and could be pushed into production if needed.

 You shall not pass   Control your code quality gates with a wizard   Part I

Deploying the policy 

Once you are satisfied with your code quality gates, you can deploy them, i.e. make sure they are enforced for any commit in the repository in question. To do that, just hit the Deploy to Gerrit button (you need SCM admin permissions in TeamForge to make this work). A wizard will open that lets you enter your credentials for the Git repository in question and lets you specify a message that goes with your quality gate deployment (behind the scenes, quality gates are versioned in Gerrit as Git commits, so you can see any change to your policies and even revert back if needed).

 You shall not pass   Control your code quality gates with a wizard   Part I

Checking the result in Gerrit

If you now log into Gerrit’s Web UI (or use the Gerrit Mylyn Plugin), you can see the quality gates in action. In the screenshot below, you can see that

  • the commit in question has been already verified (green verified checkbox)

  • the commit in question has been already strongly recommended by a reviewer (green checkbox in Code-Review)

 You shall not pass   Control your code quality gates with a wizard   Part I

However, as the commit in question has been authored by the reviewer himself (see owner and reviewer fields), it cannot go into production yet. At the bottom of the screenshot, you see a message indicating that a Non-Author has to do Code-Review.


In this blog post you learned how to select, test and deploy predefined quality gates with CollabNet’s code quality gate wizard for Gerrit. Those quality gates will make sure that all conditions regarding code quality and compliance are met before a commit can be merged into your master branch and trigger a pipeline that will eventually promote it into production.

In the next blog posts we will focus on how you can define quality gates by yourself, using a methodology very close to setting up email filter rules.

The post You shall not pass – Control your code quality gates with a wizard – Part I appeared first on

Categories: Companies

The Impact of Agile and Lean Startup on Project Portfolio Management

Agile Management Blog - VersionOne - Wed, 08/20/2014 - 13:55

With the large number of organizations now adopting agile methods, the existing body of literature has paid significant attention to the function of project management, business analysis, and more recently program management.  This is understandable as individuals filling these roles are ubiquitous and critical to the operation of their respective organizations.

Many organizations have an additional formalized function, project portfolio management (PPM), that is also critical to the organization but gets little attention — especially in light of the considerable desire being shown to scaling agile to the enterprise level.  The focus, objectives, and responsibilities of agile PPM must fundamentally shift when transitioning to an agile model, structure, and culture.  The reason for this is simple—the same agile principles that are being applied to individual projects can also be leveraged to manage the portfolio.

Below are two ways that agile PPM differs from traditional PPM:

Traditional PPM:  Optimize portfolio resources (individuals) by skill set
Agile PPM:  Maximize value delivery to customers by team capability

Traditional projects, while still delivered by teams, are much more focused on optimizing skill set across a portfolio.  One reason for this is because most traditional organizations are structured and organized by functional specialty.  That is, the organization’s structure is very hierarchical and often has individuals within a particular functional specialty (business analysis, quality assurance, project management, etc.) reporting to the same manager.

Another reason is that projects move through the process by passing through one of several phase gates such as requirements, design, test, etc.  When this is the case, project execution may be throttled by a particular skill set at each gate.  For example, if you have five business analysts, you will be limited to the number of projects that can be active.  However, most organizations ignore this fact and still have far too many projects active at any time; this only adds needless risk.  The sad truth is that most organizations really have no idea of their true project capacity.

In agile organizations, the team (not the individual) is the unit of capacity measure.  Therefore, if you have three teams that are capable of delivering an initiative or feature, you are limited by the number of teams.  So, how many projects of each type can you have active at any one time?  I don’t know; each situation will vary by organization, team, and context.  However, to get started, try setting the limit to be equal to the number of teams with the capability of delivering that type of solution.  If it doesn’t help, experiment.

For example, if you have five products that need mobile solutions, but only have three teams capable of doing the work, only start the three that will deliver the highest customer value.  Of course, that assumes that the teams are not already working on other items.

Traditional PPM:  Maximize Revenue and Evaluate Project Health
Agile PPM:  Govern Empirically through Validated Learning

One of the primary goals of traditional PPM is maximizing revenue… that is, how much money a particular project or product can add to the “bottom line” of a company’s balance sheet.  In today’s economy that is characterized by pervasive, disruptive technology and consumers that demand choice and flexibility focusing on revenue alone misses the point.

Revenue is the metric of wildly satisfied customers.

Stated another way, many would say that the sole objective of PPM is to maximize shareholder value.  This is done through increasing revenue, but it misses the point.  Because customers have flexibility and plentiful choices, the focus must be on maximizing customer value.  By focusing on customer value, if shareholder value doesn’t increase, it may be because you’re building the wrong thing.  Wouldn’t it be appealing to find that out sooner rather than later?

Further, traditional PPM typically measures the health of the agile portfolio by evaluating the health of its component projects.  This is great—in theory.  But one of the big problems with this approach is the way in which health is typically measured.  It’s most commonly done through subjective mechanisms like project status reports, achieved milestones, and progress stoplight indicators.  None of these approaches offer an objective mechanism of determining if the project is actually building the right thing.  Personally, I’ve managed projects that have delivered the wrong solution on time and within budget.  The kind of objectivity that’s required is customer validation.

A more agile PPM approach would be to introduce some mechanism of validated learning to help us make more sound and responsible decisions for our customers about what projects or products to continue funding.  Validated learning is a key aspect of the Lean Startup approach made popular by Eric Ries’ book of the same name.  Agile projects aim to build small increments of a product.  This means we are dealing with smaller return-on-investment (ROI) horizons.

Through agile PPM it’s possible to incrementally fund two projects to experiment with two different solutions to a (perceived) customer problem.  This is known as A/B testing, a.k.a., “split testing.”  Because agile methods allow us to get solutions into the hands of customers more quickly, we can evaluate the results of our experiments and shift funding to investments that are more promising and pertinent.  Because the funding is done incrementally, we need not fund an entire project for an extended period before finding out whether our assumptions were incorrect.


While these are only two of many considerations when adopting agile PPM, each has the potential to make an immediate and lasting impact on your organization and its customers, thereby, positively impacting your shareholders as well.  In my opinion, the sooner organizations can sow the seeds of customer satisfaction through validated learning, engagement, and collaboration, the sooner they will reap the rewards of increased shareholder value.

What are your thoughts?  How can you begin to apply these concepts within your own unique context?

Categories: Companies

Using Card Types to Manage Your Work More Effectively

  In LeanKit, teams can customize their card types to match the nature of their work. Card types for a software development team might include user stories, defects, features, and improvements. For an IT Operations team, they could be desktop support, server support, maintenance, and implementation. LeanKit lets you define your own card types as colors or icons, […]

The post Using Card Types to Manage Your Work More Effectively appeared first on Blog | LeanKit.

Categories: Companies

Enterprise Lean Startup Webinar Series: Metrics and Analytics to Support Innovation and Learning

BigVisible Solutions :: An Agile Company - Tue, 08/19/2014 - 20:13

Join us for the next installment of our Enterprise Lean Startup Webinar series: ” Metrics and Analytics to Support Innovation and Learning”. Evan Campbell will introduce several of the measurement frameworks commonly used to define the critical levers to your business success, and methods for validating changes to your product through observed changes in usage. […]

The post Enterprise Lean Startup Webinar Series: Metrics and Analytics to Support Innovation and Learning appeared first on BigVisible Solutions.

Categories: Companies

Lean, Agile & Scrum Conference, Zurich, Switzerland, September 9 2014

Scrum Expert - Tue, 08/19/2014 - 19:52
The Zurich Lean, Agile & Scrum Conference (LAS) is a one day conference that focuses on Lean and Agile approaches for software development. The conference provides both German and English content. The keynotes of the 2014 edition of the Zurich Lean, Agile & Scrum Conference will be Alistair Cockburn and Bob Marshall. In the agenda you can find topics like “Our journey from Waterfall to Agile; Delivering an Agile Framework to a Global IT Organization”, “Transforming Addicted Organisations (Serenity to Accept What I Cannot Change, Courage to Change What I Can)” ...
Categories: Communities

Creating a Company Where Everyone Gives Their Best

J.D. Meier's Blog - Tue, 08/19/2014 - 18:50

“Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do.” —Steve Jobs

What does it take to create a company where everybody gives their best where they have their best to give?

It takes empathy.

It also takes encouraging people to be zestful, zany, and zealous.

It takes bridging the gap between the traits that make people come alive, and the traits that traditional management practices value.

In the book The Future of Management, Gary Hamel walks through what it takes to create a company where everyone gives their best so that employees thrive and companies create sustainable competitive advantage.

Resilience and Creativity: The Traits that Differentiate Human Beings from Other Species

Resilience and creativity are what separate us from the pack.

Via The Future of Management:

“Ask your colleagues to describe the distinguishing characteristics of your company, and few are likely to mention adaptability and inventiveness.  Yet if you ask them to make a list of the traits that differentiate human beings from other species, resilience and creativity will be near the top of the list.  We see evidence of these qualities every day -- in ourselves and in those around us. “

We Work for Organizations that Aren't Very Human

People are adaptive and creative, but they often work for organizations that are not.

Via The Future of Management:

“All of us know folks who've switched careers in search of new challenges or a more balanced life.  We know people who've changed their consumption habits for the sake of the planet.  We have friends and relatives who've undergone a spiritual transformation, or risen to the demands of parenthood, or overcome tragedy.  Every day we meet people who write blogs, experiment with new recipes, mix up dance tunes, or customize their cars.  As human beings, we are amazingly adaptable and creative, yet most of us work for companies that are not.  In other words, we work for organizations that aren't very human.”

Modern Organizations Deplete Natural Resilience and Creativity

Why do so many organizations underperform?  They ignore or devalue the capabilities that make us human.

Via The Future of Management:

“There seems to be something in modern organizations that depletes the natural resilience and creativity of human beings, something that literally leaches these qualities out of employees during daylight hours.  The culprit?  Management principles and processes that foster discipline, punctuality, economy, rationality, and order, yet place little value on artistry, nonconformity, originality, audacity, and élan.  To put it simply, most companies are only fractionally human because they make room for only a fraction of the qualities and capabilities that make us human.  Billions of people show up for work every day, but way too many of them are sleepwalking.  The result: organizations that systematically underperform their potential.”

Adaptability and Innovation Have Become the Keys to Competitive Success

There’s a great big gap between what makes people great and the management systems that get in the way.

Via The Future of Management:

“Weirdly, many of those who labor in the corporate world--from lowly admins to high powered CEOs--seem resigned to this state of affairs.  They seem unperturbed by the confounding contrast between the essential nature of human beings and the essential nature of the organization in which they work.  In years past, it might have been possible to ignore this incongruity, but no longer--not in a world where adaptability and innovation have become the sine qua non of competitive success.  The challenge: to reinvent our management systems so they inspire human beings to bring all of their capabilities to work every day.”

The Human Capabilities that Contribute to Competitive Success

Hamel offers his take on what the relative contribution of human capabilities that contribute to value creation, recognizing that we now live in a world where efficiency and discipline are table stakes.


Passion 35% Creativity 25% Initiative 20% Intellect 15% Diligence 5% Obedience 0%   100%


Via The Future of Management:

“The human capabilities that contribute to competitive success can be arrayed in a hierarchy.  At the bottom is obedience--an ability to take direction and follow rules.   This is the baseline.  Next up the ladder is diligence.  Diligent employees are accountable.  They don't take shortcuts.  They are conscientious and well-organized.  Knowledge and intellect are on the next step.  Most companies work hard to hire intellectually gifted employees.  They value smart people who are eager to improve their skills and willing to borrow best practices from others.  Beyond intellect lies initiative.  People with initiative don't wait to be asked and don't wait to be told.  They seek out new challenges and are always searching for new ways to add value.  Higher still lies the gift of creativity.  Creative people are inquisitive and irrepressible.  They're not afraid of saying stupid things.  They start a lot of conversations with, 'Wouldn't it be cool if ..." And finally, at the top lies passion.”


The Power of Passion

Passion makes us do dumb things.  But it’s also the key to doing great things.

Via Via The Future of Management:

“Passion can make people do stupid things, but it's the secret sauce that turns intent into accomplishment.  People with passion climb over obstacles and refuse to give up.  Passion is contagious and turns one-person crusades into mass movements.  As the English novelist E.M. Forster put it, 'One person with passion is better than forty people merely interested.'”

Obedience is Worth Zip in Terms of Competitive Advantage

Rule-following employees won’t help you change the world.

Via The Future of Management:

“I'm not suggesting that obedience is literally worth nothing.  A company where no one followed any rules would soon descend into anarchy.  Instead, I'm arguing that rule-following employees are worth zip in terms of their competitive advantage they generate.  In a world with 4 billion nearly distributed souls, all eager to climb the ladder of economic progress, it's not hard to find billable, hardworking employees.  And what about intelligence?  For years we've been told we're living in the knowledge economy; but as knowledge itself becomes commoditized, it will lose much of its power to create competitive advantage.”

Obedience, Diligence, and Expertise Can Be Bought for Next to Nothing

You can easily buy obedience, diligence, and expertise from around the world.

But that’s not what will make you the next great company or the next great thing or a great place to work.

Via The Future of Management:

“Today, obedience, diligence, and expertise can be bought for next to nothing.  From Bangalore to Guangzhou, they have become global commodities.  A simple example: turn over your iPod, and you'll find six words engraved on the back that foretell the future of competition: 'Designed in California. Made in China.'  Despite the equal billing, the remarkable success of Apple's music business owes relatively little to the company's network of Asian subcontractors.  It is a credit instead to the imagination of Apple's designers, marketers, and lawyers.  Obviously not every iconic product is going to be designed in California, not nor manufactured in China. “

You Need Employees that are Zestful, Zany, and Zealous

If you want to bring out the best in people and what they are capable of, aim for zestful, zany, and zealous.

Via The Future of Management:

“The point, though, is this: if you want to capture the economic high ground in the creative economy, you need employees who are more than acquiescent, attentive, and astute--they must also be zestful, zany, and zealous.”

If you want to bring out your best, then break our your zest and get your zane on.

You Might Also Like

The Principles of Modern Management

How Employees Lost Empathy for their Work, for the Customer, and for the Final Product

No Slack = No Innovation

The Drag of Old Mental Models on Innovation and Change

The New Competitive Landscape

The New Realities that Call for New Organizational and Management Capabilities

Who’s Managing Your Company

Categories: Blogs

Agile 2014 – speaking and attending; a summary

Xebia Blog - Tue, 08/19/2014 - 18:14

So Agile 2014 is over again… and what an interesting conference it was.

What did I find most rewarding? Meeting so many agile people! My first conclusion was that there were experts like us agile consultants or starting agile coaches, ScrumMasters and other people getting acquainted with our cool agile world. Another trend I noticed was the scaled agile movement. Everybody seems to be involved in that somehow. Some more successful than others; some more true to agile than others.

What I missed this year was the movement of scrum or agile outside IT although my talk about scrum for marketing had a lot of positive responses.  Everybody I talked to was interested in hearing more information about it.

There was a talk maybe even two about hardware agile but I did not found a lot of buzz around it. Maybe next year? I do feel that there is potential here. I believe Fullstack product development should be the future. Marketing and IT teams? Hardware and software teams?  Splitting these still sounds as design and developer teams to me.

But what a great conference it was. I met a lot of awesome people. Some just entering the agile world; some authors of books I had read which got me further in the agile movement. I talked to the guys from Spotify. The company which is unique in its agile adoption / maturity. And they don’t even think that they are there yet. But then again will somebody ever truly BE agile ..?

I met the guys from who developed a great new scaled framework. Awesome ideas on that subject and awesome potential to treat it as a community created open framework; keep your eyes open for that!

I attended some nice talks too; also some horrible ones. Or actually 1, which should never have been presented in a 90 minute slot in a conference like this. But lets get back to the nice stories. Lyssa Adkins had a ‘talk’ about conflicts. Fun thing was that she actually facilitated the debate about scaled agile on stage. The session could have been better but the idea and potential of the subject is great.

Best session? Well probably the spotify guys. Still the greatest story out there of an agile company. The key take-out of that session for me is: agile is not an end-state, but a journey. And if you take it as serious as Spotify you might be able to make the working world a lot better. Looking at Xebia we might not even be considered to be trying agile compared to them. And that is meant in a humble way while looking up to these guys! - I know we are one of the frontiers of agile in the Netherlands. The greatest question in this session: ‘Where is the PMO in your model….’

Well you clearly understand this …

Another inspiring session was the keynote session from the CFO of Statoil about beyond budgeting. This was a good story which should become bigger in the near future as this is one of the main questions I get when implementing agile in a company: “how do we plan / estimate and budget projects when we go and do agile?” Beyond budgeting at least get’s us a little closer.
Long story short. I had a blast in Orlando. I learnt new things and met a lot of cool people.My main take out: Our community is growing which teaches us that we are not yet there by a long run. An awesome future is ahead! See you next year!

Categories: Companies

Scaled Agile Framework (SAFe) 3.0 Released

Scrum Expert - Tue, 08/19/2014 - 17:43
The version 3.0 of the Scaled agile Framework (SAFe) has been released. The Scaled agile Framework is a methodology created by Dean Leffingwell to implement Agile practices at enterprise scale. Major changes in the SAFe 3.0 version include: * Guidance on the critical role, knowledge and responsibilities of Lean-Agile Leadership * Enhanced Portfolio Level — new flow, new Metrics, Strategic Themes that connect business strategy to Portfolio Vision, and Portfolio-level Non-functional Requirements (NFRs) * Lean-Agile Budgeting optimized for flow “Beyond Project Cost Accounting” * New guidance on Coordinating multiple Agile Release Trains within larger Value ...
Categories: Communities

Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game: Adaptive Planning for Adjusted Team Capacity in Scrum

Learn more about our Scrum and Agile training sessions on WorldMindware.comAuthor’s caveat:

Lots of smart people have already come up with lots of ways of doing adaptive planning, and chances are someone has already come up with some variation of this particular approach. I have not yet had the benefit of reading everything that everyone else has already written about Agile and planning, so this has been generated by my own experiential learning on the ground as an Agile coach.  Sometimes, as a ScrumMaster/Agile Coach, you are called upon to be a two-trick pony.  This is my other trick.

 Requirements for team estimation (and planning):
  • Product Owner
  • The whole Development Team (i.e. everyone who will be involved in doing the work)
  • Product Backlog
  • Definition of “Done”
 When team membership changes:

A Scrum Team that is estimating effort against Product Backlog items for project planning and timeline projections and changes team membership for one or more Sprints must also re-estimate the remaining items (or at least the items that will be part of the Sprints in which the different/additional team members are expected to participate) regardless of estimation method (Agile Planning Poker or otherwise). The people involved in doing the work (Development Team members/Sprint) must also be involved in providing team estimates. The Development Team is responsible for all estimates as a whole team and therefore should provide estimates as a whole team. The Planning Poker game is widely understood by Agile experts and successful Agile teams as the best tool for facilitating team estimation. Part of what makes Planning Poker so effective is that it does not only provide accurate timelines, but it also facilitates knowledge-sharing among team members as everyone on the team is required to endeavor to understand the degree of complexity of the work of all other team members in order to deliver each item according to the team’s Definition of “Done”.

When team member allocation is adjusted:

Sometimes, the Development team will have people partially dedicated to the team. After one or two Sprints, it becomes apparent that full dedication of all Development Team members is required for optimal team performance. As result, management can be assisted to reconsider allocation of team members towards 100% dedication to the work of a single Scrum Team. Increased (or decreased) dedication of team members can also be expected to have a corresponding impact on velocity (effort points completed per Sprint). However, the Scrum Master needs to help the team (and their managers) to be careful to avoid planning against the unknown. Scrum allows a team to adapt based on actual historical data. Therefore, planning against minimum historical velocity is strongly recommended as a general best practice. At the same time, if a team starts off with, say, 50% allocation of team members and management decides to bump it up to 100%, it is fairly safe to assume that you will actually get somewhat more out of the team. How much more is never possible to know, as human beings are reliably incapable of predicting the future. The moderate way to approach this is to plan the next Sprint based on previous velocity, finish the planned work early in the Sprint, get a bunch of “extra” stuff done, then calculate velocity of the new and improved team and plan against the new and improved velocity. This allows the team to adapt to actuals and not be blind-sided by unforeseen impediments/bottlenecks.

Sometimes, there is a need for management to get a sense of how much more velocity the team will get from increased team member allocation in order to feel that an informed decision has been made. There is a simple (though not risk-free) method for doing this that I have whipped up after being put on the spot on several occasions. I have decided to call this the Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game.


The purpose of this exercise is to provide decision-makers with a sense of how much they are going to get out of adjusted allocation of team members to Scrum Teams. Scrum Teams perform optimally when all team members are 100% dedicated to the team. This game should be used with caution and as a means to help organizations move closer to 100% dedication of all Scrum Team members (at least all Development Team members) and, therefore, eliminate the need for this game. Great care should be taken to not encourage perpetuation of dysfunctional Waterfall habits such as “we will now go twice as fast and get done twice as early with twice the allocation of resources because we have this shiny new crystal ball called Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game that tells us so.” As long as no one believes that this is magic, it is likely safe enough to proceed to Step 1.

Step 1 – What is our current velocity?

After the first Sprint, the team should be able to count up the number of Product Backlog items completed and add up the corresponding number of “Effort Points” established during its initial estimation (Planning Poker) sessions. Let’s say for our example that the number completed for Sprint 1 is 21 Effort Points. Therefore, the current velocity of the team is 21. Let’s say that this is not a comfortable realization for the team because at some point in the past it had been estimated that this project would take the team about 5 Sprints to complete. Now, the team has done 21 points in the first Sprint and the total number of Effort Points on the Product Backlog estimated by the team is just under 210. Uh oh… 10 Sprints! Whoops! Now what do we do?! Are the new estimation values wrong? Should we stick to the 5 weeks and just have everyone work overtime on this project? Should we take this to management? Let’s say that this team decides to take it to management. But what if management needs more information than “team velocity = 21, Product Backlog = 210, therefore it’s going to take us 10 Sprints instead of 5”? Never fear, Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game is here!

Step 2 – What is our current capacity?

As part of Sprint Planning, the team needs to have a sense of its capacity in order to create the Sprint Goal and Sprint Backlog. Therefore, the team should already have a sense of its own capacity. Let’s say for our example that the (fictional) Development Team had the following projected allocation for the first Sprint:

50%        Chris P. Codemuncher

50%        Larry Legassifulunch

25%        Beth Breaksidal

40%        Gertrude Gamesthadox

40%        Dana Deadlinedryver

The team is doing 2-week Sprints. After calculating the time that the team has allocated for Scrum Events, the remaining time for doing the work of the Sprint is about 8.5 days. Therefore, we can calculate the total allocated days per team member as such:

8.5 x 50% = 4.25 days    Chris P. Codemuncher

8.5 x 50% = 4.25 days    Larry Legassifulunch

8.5 x 25% = 2.13 days    Beth Breaksidal

8.5 x 40% = 3.4 days      Gertrude Gamesthadox

8.5 x 40% = 3.4 days      Dana Deadlinedryver

17.43                              Total combined available days per Sprint

Let’s round that down to 17. That’s the number used by the team to understand its capacity for Sprint Planning. This is a powerful number for other reasons than what we are trying to get at here, but they are worth pointing out nonetheless. For generating the Sprint Backlog in Sprint Planning, this is particularly useful if each task in the Sprint Backlog is a maximum of a one-person-day. Therefore, this team should have a minimum of 17 tasks in the Sprint Backlog and these tasks should all be a one-person-day or less amount of effort. If the team has more than 17 tasks which are all about a one-person-day of effort, chances are the team has overcommitted and will fail to deliver the Sprint Goal. This should trigger the adaptation of the Sprint Goal. In any case, it provides the team with simple transparency that can easily be inspected and adapted throughout the Sprint. For example, with one-person day tasks, each team member should be able to move at least one task into the “Done” position every day and point to that movement every day during the Daily Scrum. Also, this team should be burning down at least 5 tasks every day. If either of these fails to occur, this is a clear signal for the team to inspect and adapt.

Now, let’s get back to our Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game. As a result of Steps 1 & 2 we now know that the team’s velocity is 21 Effort Points and that the team’s capacity is 17 person-days per Sprint. For short, we can say:

21            Velocity

17            Capacity

21/17       V/C

(WARNING: This number is dangerous when in the wrong hands and used as a management metric for team performance)

 Step 3 – How much capacity do we hope to have in the next Sprint?

Let’s say a friendly manager comes along and says “you know what, I want to help you guys get closer to your original wishful thinking of 5 Sprints. Therefore, I’m deciding to allocate more of certain team members’ time to this project. Unfortunately, I can only help you with the ‘developers’, because everyone else reports to other managers. I’m concerned that Beth is going to become a bottleneck, so someone should also speak with her manager. But for now, let’s bump Chris up to 100% and Larry up to 75% and see what that does for you. We’re also going to throw in another ‘specialist developer’ that you need for some stuff in your Product Backlog at 100%. How much more velocity can I get for that?”

Okay. So…more allocation = more capacity = more velocity, right? If we acknowledge that this is highly theoretical, and remember the initial WARNING of the game, we can proceed with caution…

But just as we get started on calculating the adjusted allocation of team members, we find out that Beth was actually more like 50% allocated, Dana was more like 15% allocated and Gertrude was more like 30% allocated. We need to recalculate our actuals for Sprint 1:

8.5 x 50% = 4.25 days    Chris P. Codemuncher

8.5 x 50% = 4.25 days    Larry Legassifulunch

8.5 x 50% = 4.25 days     Beth Breaksidal

8.5 x 30% = 2.55 days     Gertrude Gamesthadox

8.5 x 15% = 1.28 days     Dana Deadlinedryver

16.58                               Total combined ACTUAL available days in Sprint 1

16                                    Actual capacity (rounded-down)

21/16                               Actual V/C

As a side note, Beth had to work on a Saturday in order to increase her capacity but she spoke with her manager and thinks that from now on she will probably be able to maintain this degree of dedication to the team without having to work any more overtime.

Now the team can calculate its hoped-for capacity for Sprint 2 and beyond:

8.5 x 100% = 8.5 days     Sally Supaspeshalis

8.5 x 100% = 8.5 days     Chris P. Codemuncher

8.5 x 75% = 6.38 days     Larry Legassifulunch

8.5 x 50% = 4.25 days     Beth Breaksidal

8.5 x 30% = 2.55 days     Gertrude Gamesthadox

8.5 x 0% = 0 days            Dana Deadlinedryver

(Note: Dana is also the Scrum Master with plenty of other work to do for the team)

30.18                               Total combined hoped-for available days in Sprint 1

30                                     Hoped-for capacity (rounded-down)

Step 4 – How much velocity do we hope to have in the next Sprint?

21            Actual Historical Velocity

16            Actual Historical Capacity

30            Hoped-For Future Capacity

x              Hoped-For Future Velocity

Some simple math, loaded with assumptions:

Actual Historical Velocity/Actual Historical Capacity = Hoped-For Future Velocity/Hoped-For Future Capacity

Therefore if 21/16 = x/30, then x = 21 x 30/16 = 39.375

39            Hoped-For Future Velocity

Step 5 – How do we adapt our planning in light of what we now know (assuming we now know something substantial enough to inform our planning)?

Hopefully, not much. The best thing for the team to do at this point is to plan against its actual historical velocity of 21. If team members finish their work in the Sprint Backlog early, they should help out with other tasks until the Sprint Goal is delivered. Then, if the team achieves the Sprint Goal early and has extra time left before the end of the Sprint, then the team can pull additional items to work on from the Product Backlog. If the velocity of the team actually increases as a result of actual increased capacity, then the team can safely plan against its increased velocity beginning in Sprint 3. However, Hoped-For Future Velocity is often way too tantalizing for a team that already strongly (and to some extent, logically) believes that it can get more done with more capacity. So, most teams will usually plan to do more in light of this knowledge and that’s fine. Scrum allows them to inspect and adapt this plan at least every day. The team will figure it out.

Thank you for playing Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game. I hope it was as fun to play as it was to create!

See you next time,


Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
Categories: Blogs

Software Waste is Invisible

Agile Tools - Tue, 08/19/2014 - 15:34


You know what one of the biggest problems with knowledge work is? It’s mostly invisible. We can talk about it, but we can’t see it. You can’t see the stuff you want to create (except perhaps in your own head, which really doesn’t count) and perhaps most importantly you can’t see the stuff that is missing.

It gets worse the more people you add to the equation. That’s right, go to a planning meeting and you will find a long list of things that the team thinks they want to do (struggling to make the work visible), but I can almost guarantee you there is no list of what is missing. Why not? Because we can’t see it. It’s hard enough to see the work – that’s tough enough to begin with, but you can just forget about seeing the delay that is associated with that work.

I was reading Reinertson’s book on Product Development Flow the other day and within a couple of pages, it hit me: we can’t see what the hell we are trying to do – and that makes knowledge work really hard. We are like blind men trying to describe the proverbial elephant. If I were assembling a bicycle, I would be able to see all the parts before I put them together. I might even have some sort of inventory list to check against. I can physically see and verify the parts and the work that needs to be done. Compared to knowledge work, this physical assembly is worlds easier to estimate and accomplish – simply because we can see it.

OK, to you this may be a big, “Duh!” moment. Fair enough. But here is where I realize that we may often have a problem. What is the output of a planning meeting? Some user stories, some tasks, maybe a few follow up questions? Perhaps a calendar or timeline of some sort? How often do you see a list of all the risks or potential delays that need to be addressed as an output of a planning meeting? Yeah, never.

You see any process can be broken down into work and delay. This is the foundation for value streams. The thing is, you can’t have one and not the other. There is always delay in any system, no matter how efficient it is. But delay is one of the most neglected things we plan for. Honestly, most of the time we don’t plan for it. We plan the work and choose to ignore the delay. This is like talking about the work, but not acknowledging the impediments to the work. You can’t have one without the other. 

So why in the world would you NOT plan for delay? Planning for it is simply acknowledging that it’s real. Well, I would submit that part of the reason that delay doesn’t get more consideration is because it’s invisible. It’s very hard for us to see and visualize. Let’s face it, human beings perception of time is a total mess. We suck at assessing duration, so why would we be any good at assessing delay?

On agile teams we have evolved mechanisms to make the work visible: Story boards, Kanban boards, & Story maps, are just some of the techniques that have evolved to make work visible to us. We need similar mechanisms to make delay, impediments and other forms of waste visible too. Once we do that, we will have a more realistic vision of the work we are trying to do.

Filed under: Uncategorized
Categories: Blogs

Design Thinking für Product Owner – Teil 1: Was ist eigentlich Design Thinking?

Scrum 4 You - Tue, 08/19/2014 - 07:30

Mit der Reihe “Design Thinking für Product Owner” wollen wir Product Owner Anhaltspunkte dafür geben, wie sie ihr Produkt gestalten können und wie sie die Items für das Product Backlog generieren können.

Warum ist Design Thinking für Product Owner wichtig?

Der Product Owner ist für den Return on Investment verantwortlich, er bestimmt die Eigenschaften des Produkts, priorisiert nach Business-Value und kommuniziert eine klare Produktvision. Aber was der Nutzer wirklich braucht und wie aus vagen Produktideen eine klare Produktvision wird, beantwortet Scrum nicht!
Genau hier kann Design Thinking den Product Owner unterstützen. 
In Iterationen nähert man sich der bestmöglichen Lösung für den Nutzer, generiert Wissen für sich und andere und kann schlussendlich dem Kunden und dem eigenen Scrum-Team eine getestete und erfolgversprechende Produktvision im Spannungsfeld aus Wünschbarkeit, Machbarkeit und Wirtschaftlichkeit präsentieren.


Design Thinking behält dabei stets die Menschen, die das Produkt benutzen sollen, im Fokus und strebt danach, die Erfahrung des Nutzers mit der kreierten Lösung zu verbessern.

Was ist eigentlich Design Thinking?

Viele Menschen sehen auf den ersten Blick nur den Design-Thinking-Prozess, im Grunde ist Design Thinking aber eine agile Grundhaltung und eine Sammlung verschiedener Techniken aus unterschiedlichen Disziplinen. In der Kombination soll dies die Erfolgswahrscheinlichkeit bei der Entwicklung von Lösungen in komplexen Umfeldern erhöhen. Die Entwicklung von Ideen im moderierten Design-Thinking-Prozess ist dabei absolut nutzerfokussiert, ergebnisoffen und doch ergebnisorientiert. Das interdisziplinäre Team sucht nach aktuell unbefriedigten menschlichen Bedürfnissen, die dann im Mittelpunkt der Lösungsfindung stehen.

Mitte der 1990er-Jahre wurde an der Fakultät für Ingenieurwesen der Universität Stanford der Name “Design Thinking” für dieses methodische Gerüst der Innovationsarbeit geprägt und in der 1991 gegründeten Innovations-Agentur IDEO bereits angewendet.
In Europa wird diese Methode heute an der School of Design Thinking des Hasso-Plattner-Instituts in Potsdam … nun, nicht gerade gelehrt … eher erfahrbar gemacht.

Was heißt “agiles Mindset”?

Die wichtigsten Komponenten sind das Team, der Raum und der Prozess, aber ohne die passende persönliche Einstellung funktioniert Design Thinking nicht. Design Thinking braucht “T-shaped People”! Eine Bezeichnung für Menschen, die eine Tiefe/Spezialisierung in ihren Skills (vertikaler Balken) aufweisen, aber dennoch in der Lage sind, über Ihre Disziplin hinaus (horizontaler Balken) mit anderen Experten und Perspektiven zusammen zu arbeiten, zu teilen und zu wachsen.
 Der Design-Thinker sollte mit Unvorhersehbarkeit und Unsicherheit umgehen können. Positiv formuliert: Es bedarf einer mutigen, neugierigen und ergebnisoffenen Grundhaltung, denn der Design-Thinker kennt zu Beginn die Lösung nicht und wird erst im Laufe des Prozesses zum Experten. Er provoziert das Scheitern und setzt sich dem gnadenlosen Feedback der Nutzer aus … und das tut weh! 
Aber es ist auch der Auftakt zu neuen Erkenntnissen und – da man stets im Team arbeitet – zum gemeinsamen Lernen.
All dies sollte der Design-Thinker wirklich wollen, verordnen kann man es nicht.

Design Thinking & Change Management Flipcharts

In den folgenden Beiträgen zu “Design Thinking für Product Owner” werde ich Design Thinking näher erklären und aufzeigen, wie es mit Scrum kombinierbar ist.
 Ich freue mich über Fragen, Anregungen und Diskussionen!

Related posts:

  1. Produktfindung mit Design Thinking
  2. 5 min on Scrum | Scrum and Design
  3. Training

Categories: Blogs

How to choose the right project? Decision making frameworks for software organizations

Software Development Today - Vasco Duarte - Tue, 08/19/2014 - 05:00

Frameworks to choose the best projects in organizations are a dime a dozen.

We have our NPV (net present value), we have our customized Criteria Matrix, we have Strategic alignment, we have Risk/Value scoring, and the list goes on and on.

In every organization there will a preference for one of these or similar methods to choose where to invest people’s precious time and money.

Are all these frameworks good? No, but they aren’t bad either. They all have some potential positive impact, at least when it comes to reflection. They help executive teams reflect on where they want to take their organizations, and how each potential project will help (or hinder) those objectives.

So far, so good.

“Everybody’s got a plan, until they get punched in the face” ~Tyson Surviving wrong decisions made with perfect data

However, reality is seldom as structured and predictable as the plans make it out to be. Despite the obvious value that the frameworks above have for decision making, they can’t be perfect because they lack one crucial aspect of reality: feedback.

Models lack on critical property of reality: feedback.

As soon as we start executing a particular project, we have chosen a path and have made allocation of people’s time and money. That, in turn, sets in motion a series of other decisions: we may hire some people, we may subcontract part of the project, etc.

All of these subsequent decisions will have even further impacts as the projects go on, and they may lead to even more decisions being made. Each of these decisions will also have an impact on the outcome of the chosen projects, as well as on other sub-decisions for each project. Perhaps the simplest example being the conflicts that arise from certain tasks for different projects having to be executed by the same people (shared skills or knowledge).

And at this point we have to ask: even assuming that we had perfect data when we chose the project based on one of the frameworks above, how do we make sure that we are still working on the most important and valuable projects for our organization?

Independently from the decisions made in the past, how do we ensure we are working on the most important work today? The feedback bytes back

This illustrates one of the most common problems with decision making frameworks: their static nature. They are about making decisions "now", not "continuously". Decision making frameworks are great at the time when you need to make a decision, but once the wheels are in motion, you will need to adapt. You will need to understand and harness the feedback of your decisions and change what is needed to make sure you are still focusing on the most valuable work for your organization.

All decision frameworks have one critical shortcoming: they are static by design. How do we improve decision making after the fact?

First, we must understand that any work that is “in flight” (aka in progress) in IT projects has a value of zero, i.e., in IT projects no work has value until it is in use by someone, somewhere. And at that point it has both value (the benefit) and cost (how much we spend maintaining that functionality).

This dynamic means that even if you have chosen the right project to start with, you have to make sure that you can stop any project, at any time. Otherwise you will have committed to invest more time and more money (by making irreversible “big bang” decisions) into projects that may prove to be much less valuable than you expected when you started them. This phenomenon of continuing to invest beyond the project benefit/cost trade-off point is known as Sunk Cost Fallacy and is a very common problem in software organizations: because reversing a decision made using a trustworthy process is very difficult, both practically (stop project = loose all value) and due to bureaucracy (how do we prove that the decision to stop is better than the decision to start the project?)

Can we treat the Sunk Cost Fallacy syndrome?

While using the decision frameworks listed above (or others), don’t forget that the most important decision you can make is to keep your options open in a way that allows you to stop work on projects that prove less valuable than expected, and to invest more in projects that prove more valuable than expected.

In my own practice this is one of the reasons why I focus on one of the #NoEstimates rules: Always know what is the most valuable thing to work on, and work only on that.

So my suggestion is: even when you score projects and make decisions on those scores, always keep in mind that you may be wrong. So, invest in small increments into the projects you believe are valuable, but be ready to reassess and stop investing if those projects prove less valuable than other projects that will become relevant later on.

The #NoEstimates approach I use allows me to do this at three levels:

  • a) Portfolio level: by reviewing constant progress in each project and assess value delivered. As well as constantly preparing to stop each project by releasing regularly to a production-like environment. Portfolio flexibility.
  • b) Project level: by separating each piece of value (User Story or Feature) into an independent work package that can be delivered independently from all other project work. Scope flexibility.
  • c) User Story / Feature level: by keeping User Stories and Features as small as possible (1 day for User Stories, 1-2 weeks for Features), and releasing them independently at fixed time intervals. Work item flexibility

Do you want to know more about adaptive decision frameworks? Woody Zuill and myself will be hosting a workshop in Helsinki to present our #NoEstimates ideas and to discuss decision making frameworks for software projects that build on our #NoEstimates work.

You can sign up here. But before you do, email me and get a special discount code.

If you manage software organizations and projects, there will be other interesting workshops for you in the same days. For example, the #MobProgramming workshop where Woody Zuill shows you how he has been able to help his teams significantly improve their well-being and performance. #MobProgramming may well be a breakthrough in Agile management.

Picture credit: John Hammink, follow him on twitter

Categories: Blogs

A Creativity (R)Evolution

TV Agile - Mon, 08/18/2014 - 21:24
We are incessantly, almost compulsively drawn to gatherings of intelligent, creative people. While we are looking to learn ways to change our professional and personal lives for the better with Agile approaches, on a deeper level, we’re compelled because we crave profound change and the inspiration to instigate a revolution. There’s a movement brewing built […]
Categories: Blogs

Next Cape Town talk: Product Owners: Dealing with Capacity and Prioritisation

Scrum User Group of South Africa - Mon, 08/18/2014 - 10:51
During this session we will look at the various things POs need to focus on, manage and eventually master. The majority of the session will be spent on 2 areas that in our experience, many PO’s struggle with, capacity and prioritisation. To explain capacity we will use an analogy and help you self discover what […]
Categories: Communities

5 minutes on scaling: Hangout & Co

Scrum 4 You - Mon, 08/18/2014 - 07:40

Natürlich nutzen wir mittlerweile neben den physischen Taskboards auch JIRA und Co. Doch jedes Mal, wenn ich diese Tools nutze, gehen mir ihre Unzulänglichkeiten auf den Geist. Sie lösen im skalierten Umfeld das eigentliche Problem nicht: Sie helfen nicht, die Kommunikation zwischen den Scrum-Teammitgliedern einer weltweit aufgestellten Organisation zu vereinfachen. Vielmehr sind sie zu Datenbanken, Reporting Tools, perfektionierten Bug Tracking Tools und Forecast Push Systemen degeneriert. Selbst bieten diese Wesen keinen Mehrwert – sie müssen sich der Lebenszeit von Entwicklern und Managern bedienen, um am Leben zu bleiben.

Dabei wäre es so einfach, ein wirklich funktionierendes, agiles Scrum-Tool zu entwickeln. Eines nämlich, das Arbeit beschleunigt und Kommunikation erleichtert, statt zu einer Belastung zu werden. Dazu bräuchte es nur ein paar Entwickler, die nach folgendem Rezept das perfekte Scrum-Tool bauen:

  1. Man nehme ein wirklich funktionierendes, d.h. stabiles Video Conferencing System wie zum Beispiel Google Hangout und verpasse ihm eine bessere Usability – sorry liebe Googles, das geht besser!
  2. Man füge eine Prise Telefoneinwahl international und kostenfrei hinzu – für die Teammitglieder, die während des Daily Scrums unterwegs sind (sorry, noch ist WLAN oder LTE auf deutschen Autobahnen und im ICE zu instabil – vor allem bei Hochgeschwindigkeitsfahrten).
  3. Dann mische man ein Whiteboard, eine Desksharing-Funktionalität, einen Persistent Chat und ein Taskboard hinzu.
  4. Nun braucht man noch die Möglichkeit, Texte auffindbar zu erstellen, die u.a. aber nicht nur an den Stories hängen. Deshalb integrieren wir ein Wiki, das sich aber bitte so wie ein Google Docs verhält.
  5. Für große Mengen an Bildern und Dokumenten brauchen wir noch Dropbox oder Evernote.
  6. Als Dessert nehmen wir noch einen integrierten Kalender, ein Shared Adressbook und eine E-Mail-Funktionalität.

Fertig. Alle zu Tisch, so kann man international arbeiten.

Ach so: Die Reporting-Funktionalitäten fürs Management lassen wir weg.
Fortschritte zeigen wir, indem wir fertige Produkte liefern – wir zeigen es nicht durch abgearbeitete Stories oder Tasks. Das ginge ja, wenn wir das Video-Chat-Programm so ausweiten könnten, dass wir ohne Probleme Demos auch für nicht Firmenmitglieder abhalten könnten.

Naja, ich träume. Aber ganz ehrlich, wir brauchen solche Tools. Die Entwicklung in der postindustriellen Netzwerkgesellschaft geht hin zu mehr Remote-Arbeit (work were you are), denn Teams kaufen sich die Kollegen dort ein, wo sie eben wohnen. Einer meiner Bekannten wohnt in St. Pölten (Niederösterreich) und arbeitet täglich für ein kalifornisches Unternehmen als Entwickler – warum auch nicht. Softwareentwicklungs-Teams können das heute. Andere Firmen werden folgen.

Wir müssen das möglich machen. Die Teams eines unserer Kunden arbeiten an zwei Orten in den USA, in China, in Indien und in München. Wir brauchen die Infrastruktur, um sie miteinander arbeiten zu lassen – und zwar produktiv. Und nein: Menschen zu einem Umzug oder hunderttausenden Flugmeilen mehr zu zwingen, ist keine wirkliche Alternative – weder steuertechnisch noch aus Sicht der Produktivität. Wissensarbeit braucht den Austausch, das miteinander Denken. Das geht in der Business Class des A380 nicht, da hilft auch die überfüllte Senatoren Lounge nichts mehr. Das ist nichts anderes als verlorene Lebenszeit.

Verteiltes, skaliertes und mulitkulturelles, grenzüberschreitendes Arbeiten wird zum Alltag werden. Kleine, schlanke Firmen werden das mit einer Symbiose aus den günstigen Lösungen wie Google HO, Confluence, Evernote und Dropbox stemmen. Große, unbewegliche Konzerne werden folgen – und dafür teure Enterprise Tools einkaufen. Vor allem müssen wir es schaffen, auch den multikulturellen Aspekt zu berücksichtigen. Schweizer, Österreicher und Deutsche – wir sprechen eine Sprache und meinen etwas völlig anderes. Ein elektronisches Board, dessen Sichtbarkeit auf die Größe eines Monitors beschränkt ist, muss also etwas anderes können, als beim Verschieben der Tasks die Farbe zu wechseln.

Related posts:

  1. 5 min on Scrum Tools
  2. Scrum Tools | VersionOne
  3. 5 min on Scrum | Tools

Categories: Blogs

Knowledge Sharing

SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.