Skip to content

Feed aggregator

Open a Github Issue From Slack!

The other day one of my co-workers opined that it’d be fantastic if we could open a GitHub issue from Slack. Fifteen minutes later the channel got to bask in the awesomeness… of this!

Read on to discover how to use Zapier (shameless plug: yes, I work on this) to whip this up quickly as well!

Opening the Issue

First up, we need to log in to Zapier and set up our first of two Zaps, the one that will create a new issue from Slack.

Now we’ll select our two services and the desired actions:

Next up, connect Slack and GitHub to Zapier.

When we get to step four, we’ll want to setup a custom filter so that we only trigger on Slack messages that contain !gh_issue.

At step five we’ll want to plug the values in to the GitHub issue from Slack. If you scroll back you’ll remember we used a specific format for our issue:

!gh_issue title(Junk Issue) description(Junk Issue!) repo(zapier/zapier-infra)

In Zapier-land, we extract those elements with parenthesis as variables. So when pulling from the trigger we get the raw text and the extracted variables as names like {{text__title}}, {{text__description}}, etc.

At step six we’ll load some samples.

Hrmph. All filtered out. Ah! We haven’t actually tried to create an issue from Slack. Let’s go do that now!

Now we go back to step six and refresh and we should see a new unfiltered sample, of which we can click “See filter sample” to view what will go to GitHub.

Looks good! Let’s go ahead and click “Test” and check that the GitHub issue was created on GitHub.

Great! Let’s go ahead and name this Zap!

But that’s only half the story. It’d also be nice if there was some notification in the channel that it had been created. Not 100% needed, but it would be nice!

The Webhook

So we have multiple ways we could approach this here:

  • Create a Zap that polls GitHub issues and alerts the channel of new issues
  • Setup a webhook through Zapier to push new issues instantly to Slack
  • Use the native Slack/GitHub integration on Slack to send the new issue notification

I’ll admit I didn’t have much luck using the native integration despite wanting it to work as it would have required the least amount of setup. Polling was easy to setup, but it means I can have anywhere from a 1 minute to a 15 minute delay from when I open the issue to when it is published back to Slack. So I opted for the webhook route.

The Webhook Trigger on Zapier is immensely powerful. You can use it to poll a URL, catch incoming webhooks, and even send webhooks back out to other services. It’s pretty raw but it gets the job done, and it gets it done instantly.

Like last time, for step one we will select our services: Webhook to Slack!

In step two, we’ll be given a webhook we can copy and paste to plug it into GitHub. Let’s navigate to GitHub really quick to add it.

In our repository settings page on GitHub, let’s add a new webhook.

By default this will fire on all events. We don’t want that, we want each issue.

This will be grayed out until an event fires, so let’s go back to Zapier and continue working on our Zap.

On step four, we’ll want add a custom filter so that the Zap will only trigger when issue action is equal to “open”. Otherwise this will fire whenever any activity takes place, such as opening and closing issues.

The first time through you may get a modal pop up prompting you to go create a new issue when you try to select a field. This is because webhooks are instant and require a user interaction to take place first. So go create an issue (manually or from Slack, it doesn’t matter) and follow the instructions to get it caught by Zapier. Now we can select the field we need and move on. :-)

At step five it’s time to set up the channel the message will be sent to and what the message will be. I typically prefer to alert the channel of a new issue opened on a repository and then link to it.

There is also a field for Icon URL that can be used to plug in a specific icon for the Slack bot that broadcasts the message. I usually use a character of ours (Zapbot!) that is similar to Hubot, but Octocat fits well here too!

Now we’ll test the Zap and if all goes well, name it and set it live!

Whelp that wraps it up for us… hope you find these Zaps as useful as we have!

Categories: Blogs

Patterns: a New Standard for Scrum

Scrum Expert - 3 hours 34 min ago
Patterns are the new defacto Scrum standard. In recent years, international Scrum Leadership has been meeting about once a year to write a rationalized foundation for Scrum using Organizational Patterns as a public resource. This is the most inclusive forum for segments of the Scrum community meet and find common ground in the deep groundings of Scrum, and it is converging on a socially agreed definition while the certifying bodies have take less compelling paths. Jeff Sutherland’s Scrum training now revolves around the application of seven Scrum patterns. Using the same approach ...
Categories: Communities

Lean Agile Scotland, Edinburgh, Scotland, September 11-12 2014

Scrum Expert - 4 hours 5 min ago
Lean Agile Scotland is a two-day conference focused on the Lean and Agile approaches to software development. It will be preceded by a workshop on September 10. In the agenda you can find topics like “Join the Dark Side – why developers should choose management”, “Building the Boardwalk Empire: Visual Management in Action”, “Overcoming Self-organization Blocks”, “Lean Estimation & Planning”, “Better Decision Making: Gathering Data and Mapping Decisions”, “Lean Product is about the people – Putting it all together”. Web site: Location for the 2014 conference: Our Dynamic Earth, Holyrood Rd 112, ...
Categories: Communities

Sample Page

Manage Well - Tathagat Varma - 4 hours 31 min ago

This is an example page. It’s different from a blog post because it will stay in one place and will show up in your site navigation (in most themes). Most people start with an About page that introduces them to potential site visitors. It might say something like this:

Hi there! I’m a bike messenger by day, aspiring actor by night, and this is my blog. I live in Los Angeles, have a great dog named Jack, and I like piña coladas. (And gettin’ caught in the rain.)

…or something like this:

The XYZ Doohickey Company was founded in 1971, and has been providing quality doohickies to the public ever since. Located in Gotham City, XYZ employs over 2,000 people and does all kinds of awesome things for the Gotham community.

As a new WordPress user, you should go to your dashboard to delete this page and create new pages for your content. Have fun!

Categories: Blogs

Hello world!

Manage Well - Tathagat Varma - 4 hours 31 min ago

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!

Categories: Blogs

News update 2014/08 – 5 Reasons to Kill Time Sheets - Peter Hundermark - 6 hours 44 min ago

Welcome to our August newsletter. Do you also have a dislike for time tracking? Joanne Perold does, and she explains why in this month’s blog post….more.

Kanban Foundation TrainingKanban Training

We still have spaces available on our upcoming Kanban Foundation and Advanced courses. Scrum Sense will once again be teaming up with LKU-accredited Kanban Trainer, Dr. Klaus Leopold of LEANability to present this training.

Kanban foundational course provides insight and visibility to the “why” of doing things – Dean Harvey, Nedbank Ltd.

The Applying Kanban (Foundation) and Improving & Scaling Kanban (Advanced) certified courses will be taking place in Sandton on the 20-21 Oct and 23-24 Oct 2014 respectively. We are running a 3-for-2 special offer on both courses, so be sure to secure your place!

Interesting Links
  • InfoQ has published the first in a series of articles from the short book “Leading Self-Organising Teams” written by Dr. Sigi Kaltenecker & Peter Hundermark. The first article is on “what are self-organising teams?” In the coming weeks this will be followed by “why do we need self-organising teams?” and “what is Leading Self-Organising Teams all about?”. Be sure to follow this series!
  • Dillon Weyer of Scrum Sense has written a blog post on the importance of a defined outcome. The title, “Without an outcome in mind, any road will do!“, perfectly sums up the significance of having an outcome.
Upcoming Courses

Certified Scrum Master (JHB) 
02-03 Sept 2014
FNB Conference & Learning Centre, Sandton

Leading Self-Organising Teams (JHB)
16-17 Sept 2014
FNB Conference & Learning Centre, Sandton

Certified Scrum Product Owner (JHB)
30 Sept-01 Oct 2014
FNB Conference & Learning Centre, Sandton

Applying Kanban (Foundation) – (JHB)
20-21 Oct 2014
FNB Conference & Learning Centre, Sandton

Course schedule and Book Online

The post News update 2014/08 – 5 Reasons to Kill Time Sheets appeared first on ScrumSense.

Categories: Blogs

5 Reasons to Kill Time Sheets - Peter Hundermark - 6 hours 50 min ago

I subscribe to a newsletter from Projects at Work which I rarely read. I happened to open it this month and stumbled upon a gem.

5 Ways to Improve Time Tracking

It prompted this post…

5 Reasons to Kill Time Sheets

I have a strong dislike to time tracking, especially on software projects and here is why.. 

1. Motivation of people.

The first problem that I have with tracking time is that it inherently sends the message to teams “We don’t trust you.” Even if this is not the intended message, it is the one that everyone hears. More often than not these metrics are used in bonus and performance conversations and used as punishment or reward. For this reason the inherent behaviour that it drives is that people lie, and to feel unsafe and untrusted to get their work done. How will your data be accurate if everyone is lying. If you want people to stop lying then change what is driving their behaviour.

2. Managing resources

Secondly time tracking implies “resource” management and people aren’t resources. I won’t go into detail on that. Rather, here is a blog post on why that is important.

3. Individuals over teams

Thirdly this encourages working towards goals as individuals instead of as teams. If the end game is for people to work better as teams then this drives dysfunction rather than collaboration. If project managers and teams are collaborating daily, then tracking of hours to understand progress is redundant. There are also better ways to visualise progress, and encourage team collaboration and team work. An example would be using a task board to visualise the work and track progress. Less work in progress also encourages collaboration, limiting WIP encourages team members to pair and learn. 

4. Satisfying the need

Mostly it doesn’t address or satisfy the need. If the need is to understand how long a piece of work takes before a team is finished with it, then there are far better ways of getting this information than tracking time. Measuring a work item start to finish is better than measuring a person for 8 hours or 10 hours a day. Understanding how many work items are done is a better indication than understanding the number of hours James spent on project A. If James said that it was going to take 100 hours and he has spent 80 hours then he has 20 hours left, and so you believe that he is 80% done. That might be true but equally as likely is that James has just discovered that he is only a quarter of the way through. My experience is also that often the last 20% takes 80% of the time. 

5. Measuring Productivity

Do you want to measure profit or cost? If 3 pieces of work move through a pipeline in a week, that is a far more accurate measure of A: capacity and B: throughput. 

Productivity does not equal profit and linking the two together means that you focus on filling up capacity and measuring hours as productivity. Measuring productivity also implies that a team needs to fill up their capacity. The reality is that a team with 100% capacity is much like a highway with 100% capacity: a parking lot. 

What you don’t do is measure the rate of work through the system, or give that work space to move through quicker in future. Teams need space to move quicker and filling capacity is not likely to get that. Managing hours is also not a way to drive the right behaviour. If you fill up capacity then you won’t have space for innovation. If you focus on productivity you might miss focusing on profit. 

The post 5 Reasons to Kill Time Sheets appeared first on ScrumSense.

Categories: Blogs

Principle #5 of Capacity Planning: Tolerance for Incomplete Data

Rally Agile Blog - 7 hours 42 min ago

The first four Principles of Capacity Planning start us on a planning journey to run a business more effectively. Here are the topics we’ve covered so far:

This post addresses the value of tolerating incomplete data in portfolio planning -- a principle that applies to both demand and supply. Here are some specific examples for each.

Demand Tolerance: Detail Initiatives Only As You Get Close to Scheduling Them

When we plan out 12 to 18 months, we’ll make decisions on less-accurate data than we’ll have for, say, the upcoming quarter. In other words, we’ll be less certain as our planning horizon moves farther into the future.  

Experts and highly competent professionals strive for perfection. Big planning mistakes have ruined careers. Yet to be successful, leaders must make decisions using imperfect information. Strategic planners have to navigate uncertainty and risk as investment scenarios become plans of record. To have a reasonable chance of success, we must know something about the investments we select to execute on: the rest of the information is either knowable or unknowable. There is a huge cost associated with gathering this knowledge. On the other hand, tolerating incomplete data is no excuse for ignorance.  

A prominent, former presidential cabinet member advised that you not take action if you have only enough information to give you less than a 40 percent chance of being right; but that you shouldn't wait until you have enough facts to be 100 percent sure, either, because by then it’s almost always too late. This instinct is right: excessive delays in the name of information-gathering leads to analysis paralysis. Procrastination in the name of reducing risk actually increases risk. For example: one Fortune 500 organization was spending so much time to have 100 percent of the decision-making information that its approval process took years -- longer than the time required to implement the approved projects and programs.

When applied to an annual cadence, expect to be on the low end of this information-gathering range (around 40 percent.) At this point you’re planning at more of the initiative level, maybe with some features identified. With roughly right estimates, we will set ourselves up for more accurate near term plans.  Within a quarter, I expect to be closer to 70% because I should have more complete information.  As you embark on continuous planning cadence, the ability to manage uncertainty becomes much more tolerable because you know you will have the opportunity to inspect and adapt at more frequent intervals.  In today’s fast-paced world, the cost of delay can be so high you have no choice but to get comfortable with operating on good-enough data.  

One of the proven benefits of Agile software development methods is that you can adapt to necessary changes in schedule and priorities, and avoid the misalignment of scheduling work far ahead of execution. In a continuous planning cadence, annual planning becomes part of long range business commitments, forecasting and budgeting, while scheduling becomes part of rolling wave prioritization and value delivery.

Ironically, traditional sources of guidance support the notion of tolerating incomplete data. According to PMBOK, “A Planning Package is a work breakdown structure component below the control account with known work content but without detailed schedule activities.” Each organization should determine its policies for when it’s feasible to refine details and schedule them. Our experience shows that this planning horizon for prioritization and value delivery in today’s fast-paced world is about one quarter (three months.) With these rhythms, we can get better at operating on “good enough” data.

Supply Tolerance: Fuss Only When You Must

When working with large customers, we’ve found that most managers have been burned by failing to pay attention to the scarce capacity of specialization areas. Examples include UX designers and DBAs, as well as expertise specific to a company technology environment, such as network or security engineers. The cost of not accounting for this scarcity of talent is an overly optimistic plan that does not match the reality of what can be delivered. This is one criticism of Agile methods to-date: they lack a good approach for handling exceptions to cross-functional teams.

The key to tolerating incomplete data is to plan at the delivery group level and, if necessary, the delivery team level. This respects the principle of the team as the resource unit and has the added advantage of simplifying the capacity planning exercise by a factor of 10 (roughly assuming 10 individuals per team.) Only when planning at the team level isn’t roughly right do we fuss more, usually because of the need to pay special attention to scarce expertise. Because managing expertise adds overhead to matching supply to demand, the goal is to fuss only where you must!

How do we fuss just enough? Let's take the example of a fictitious company that has both retail brick and mortar stores and a successful online presence. Initially, this organization had a platform delivery group that provides all the backend services. Every other delivery group was dependent on the platform group. With so many dependencies, managers were constantly scrambling to remove bottlenecks and resolve schedule conflicts. The solution was to distribute the platform delivery group onto several of the other delivery groups so they could be made “whole” (each group had what is needed to deliver value with minimal external dependencies.) By designating “platform” as an expertise, and just a little extra fussing to account for platform constraints, we can match supply and demand and have better results.  

Roles and Expertise

Expertise can be used to support flexible resourcing. Take, for example, an organization that has several delivery groups, with some aligned to specific products.  Most of the time, each delivery group is self-sufficient in delivering their allocated work.  When there’s an unusually high need for a given expertise, the delivery group can be augmented by providing additional capacity from other delivery groups for that expertise.  One customer told us, “We rob teams from Peter to pay Paul all the time in order to deliver maximum value.” Expertise should only be fussed with when we must.

What about roles? Modern capacity planning strives to use role as an attribute of a team. Applying roles to teams helps identify team competencies and provide convenient capacity planning building blocks. A team’s role can be thought of as expertise. Although we value teams over individuals, we recognize that individuals are the basis of great teams (it’s commonly cited that a good programmer can outperform a mediocre one by a factor of 10.) When the team is the fundamental planning currency, the need to fuss about the roles of individuals diminishes. Thus, resist the urge to track capacity of individual roles within each team. For planning purposes, this would be artificially precise (read more about the capacity planning principle of “roughly right.”)

This blog rounds out the five principles of modern capacity planning that should help you have a less dreadful annual planning season. If you'd rather listen to an overview of these principles, check out the "Business Agility and Annual Planning: Solving the Paradox" webinar.  

Most importantly, don’t waste any more time creating precisely wrong plans when you can leverage Rally’s expertise in portfolio capacity planning.

Brent Barton
Categories: Companies

A dev walks into a bar… - Elizabeth Keogh - 8 hours 14 min ago

…and says to the barman, “I’m in the bar. I’m thirsty. I have £10.23 in my wallet.”

“Great,” says the barman. “What can I get you?”

The dev looks around. “When you take that glass and put it in front of that pump there,” he says, pointing at a pump, “you should be able to fill it full of beer.”

“Guess so,” the barman says. He picks up the glass and starts pouring the pint.

The dev points to a spot in front of him on the bar. “Given the glass is full of beer, when you put it there on the bar, you should ask me for £3.80,”

“Uhuh,” the barman says. He finishes pouring the pint and puts it in front of the dev.

“You should ask me for £3.80,” the dev says again. “If you don’t, I’m going to throw… um…” He looks around again.

“You know,” the barman suggests, “if you want to learn to use Cucumber you could just start by having an ordinary conversation first.”

Categories: Blogs

Cross-funktionales Arbeiten – wie geht das?

Scrum 4 You - Thu, 08/21/2014 - 07:30

Über Apple ist in den letzten Jahren so viel geschrieben worden, dass in der Flut an Informationen nur noch wenige wirklich neue Erkenntnisse aufwarten. Und doch: Auf der Webseite Co.Design ist kürzlich ein aufschlussreiches Kurzportrait über Apples Designkultur erschienen. Der Bericht stützt sich auf Mark Kawano, der sieben Jahre lang als Designer für Apple arbeitete.

Die Kernaussage ist: Apples Designkultur ist nicht auf die Herrschaft besonders begabter Designer zurückzuführen. Sie beruht vielmehr auf einer Ausrichtung des gesamten Unternehmens auf gutes Produktdesign. Bei der Entwicklung neuer Produkte sind Designer und Entwickler so in der Lage, am gleichen Strang zu ziehen:

“For the most part, Apple didn’t employ specialist designers. Every designer could hold their own in both creating icons and new interfaces, for instance. And thanks to the fact that Apple hires design-centric engineers, the relatively skeleton design team could rely on engineers to begin the build process on a new app interface, rather than having to initiate their own mock-up first.”

In Scrum sprechen wir in diesem Zusammenhang von cross-funktionalem Arbeiten: Wie in einem Operationssaal arbeiten Spezialisten Hand in Hand. Jeder hat andere Aufgaben und auch Ziele – und trotzdem weiß jeder zu jedem Zeitpunkt, was der andere gerade macht und wo er welche Unterstützung braucht.

In der Produktentwicklung gibt es diese Spezialisierung ebenfalls: Disziplinen wie Design, Konstruktion, Qualitätsmanagement, Einkauf, Marketing und Vertrieb sind normalerweise in verschiedenen Abteilungen untergebracht. Innerhalb von Produktentwicklungsprojekten kommen die Abteilungen zwar punktuell zusammen (etwa beim Erreichen von Meilensteinen), doch findet keine intensive Zusammenarbeit wie im OP-Saal statt. Das führt häufig dazu, dass jede Disziplin ihren eigenen Zielen folgt und sich nicht genügend austauscht:

  • Die Entwickler wollen anspruchsvolle und komplexe Funktionalitäten.
  • Die Designer wollen einen Benutzer, der zum Produkt eine positive Beziehung aufbauen kann.
  • Das Marketing will, dass sich das Produkt von der Konkurrenz abhebt.

Dass jede Disziplin ihren eigenen Zielen folgt, ist völlig normal. Doch führt ein Mangel an Zusammenarbeit dazu, dass aus Unkenntnis über die Ziele der anderen kein gemeinsamer Grund entstehen kann. So haben wir die berüchtigten Silos, in denen nur noch lokal optimiert wird.

Das Team als Keimzelle der cross-funktionalen Zusammenarbeit

Mit der Schaffung von Scrum-Entwicklungsteams ist formal eine Instanz geschaffen, in der die verschiedenen Spezialisten zusammen kommen. Und es gibt auch einen gemeinsamen Grund: Die Verantwortung des Entwicklungsteams ist die erfolgreiche (Aus-)lieferung des Produkts. Doch der erfolgreichen Zusammenarbeit stehen häufig Hindernisse im Weg. Die typischen Hindernisse sind:

  • Ressourcenengpässe: Wer für viele Projekte eingeplant ist, kann in keinem wirklich mitarbeiten.
  • Wissensmangel: Interdisziplinäre Zusammenarbeit erfordert genügend Wissen über die Arbeit der anderen, um von den gleichen Dingen sprechen zu können.
  • Unklare Rollenerwartung: Die Mitarbeit in interdisziplinären Teams braucht zunächst eine andere Haltung: nicht die des Experten, sondern die des lernenden Anfängers.
Organisationsveränderung will gelernt sein

Keines der drei Hindernisse ist prinzipieller Natur – alle sind sie überwindbar. Sie erfordern allerdings mutige Entscheidungen, die altbewährte Denkweisen und Paradigmen wie z.B. das der maximalen Auslastung und Effizienz in Frage stellen.

Machen wir uns nichts vor: Der Weg zum cross-funktionalen Arbeiten ist für die meisten Unternehmen ein starker Veränderungsprozess, der zu Widerstand und tiefer Verunsicherung führen kann. Umso wichtiger ist das Design des Prozesses: Veränderungen, die von wenigen konzipiert und dann ausgerollt werden, haben meistens mit erheblichen Akzeptanzproblemen zu kämpfen. Man spart sich viele Grabenkämpfe und Umwege, wenn die Betroffenen von Anfang an zusammen kommen, damit sie selbst einen Lösungsvorschlag erarbeiten.

Hierzu bietet sich das Format der Pilotgruppe an, die aus einem repräsentativen Querschnitt des Unternehmens besteht und damit beauftragt wird, Antworten auf die relevanten Fragestellungen zu finden. Wichtig ist, dass eben diese Fragestellungen und die dazu gehörigen Rahmenbedingungen im Vorfeld vom Management festgelegt werden. Wir haben am Beispiel Apple gesehen, wie ein Unternehmen seine Kernbotschaft (bei Apple ist es das Design) über einige wenige Spezialisten hinaus in der gesamte Unternehmenskultur verankern konnte.

Was auch immer Ihre Kernbotschaft ist: Erlauben Sie nicht, dass sie von den Zwängen der Unternehmensprozesse und -strukturen verwässert wird.

Related posts:

  1. Einen Schritt aus dem Moloch heraus
  2. Communities of Practice
  3. Product Owner – Das unbekannte Wesen

Categories: Blogs

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

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

tl;dr 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 have your own Eclipse IDE and just want to install some additional plugins, we provide info about our update sites here.

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

Knowledge Sharing

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