Forecasting in agile Projects – Do you get your things done within time and budget?

Well, this sound like a question for classic approaches J. However, I often get asked how could we know in agile projects, or on product level if we get things done in time?
Agile projects are cool and simple, planning is sprint by sprint and team size defines monthly budget. However, if you’re a product owner you might be asked by your stakeholders and sponsors “what of the product backlog could be done until when”, “what does it cost” and most difficult “are we still on track”?-As usually just sprints are under deep monitoring I’d like to share with you a very simple instrument, the product burn up chart.
Usually I paint this to a physical flip-chart, but I was curious if I could manage to create a simple monitoring tool?-This tool should keeping track over whole product lifecycle. As I’m a mac user I’ve done that with numbers, however you could download and convert it to excel if you like. Just to to download here:
From my point of view most important things for a product owner to monitor towards his team are:
  1. Progress and Forcasting of Product Backlog implementation (Top Chart)
  2. Tracking continous Improvement of Team (Bottom left Chart, even if that’s in responsibility of SM I’d like to know about)
  3. Budget Burndown (Bottom right Chart)
While creating these graphs I started to play around with some scenario’s and I found out that this is getting more and more complex. E.g. it might be interesting to monitor development of product backlog size as well. In my scenario the product would be implemented within 6 sprints and additional stories would be rarely added. However in corresponding data sheet I’ve added some notifications if it gets unrealistic to stay within time and budget. Furthermore over time the best/worst case forecasts are getting more and more accurate. In my example the team is performing very well, since sprint 4 near best case scenario.
My calculations might have still some bugs, so I do not guarantee nothing. I’m curious about your input about, may be we could develop it more and somebody creates a standard plugin for Atlassian Agile?
Please note: I pass any monitoring of outcome like end user feedbacks, increasing of revenue, etc. at this moment.
Tagged with: , , , , , , , , ,
Veröffentlicht in field experience, scrum

My speech about “The future of …“ Collaboration – How agile cooperation models substitute classical client/vendor relationships

Last two days I was at conference ONE and “The future of..” in Zurich while  I gave a speech about „The future of collaboration: How agile cooperation models substitute classical client/vendor relationships“.-There were several other very interesting speeches about newest trends in technology, biology, culture, etc!

I’d like to share with you some impressions and tweets, over 150 attendees came to me speech. While the whole cause within that two days (ONE-Experience, The future of.., E-Commerce-Connect, Topsoft) had several thousands of registered visitors and exhibitors.


Find below the presentation at slideshare and don’t hesitate to contact me in any case of questions. I’ll answer you on any channel, like twitter, comment to that article, email, etc.

Tagged with: , , , , , , , , , , , , , , , , , , , ,
Veröffentlicht in field experience, scrum

How Hierarchy prevents Agility

Big projects tend to setup a big project organization, but why?-And is this really supporting agility needed or is it create other risks, that slows down time-to-market?
In my previous blog entry I told you about alternatives how to handle very big projects. Well, I’ve noticed even though big projects have been broken down into smaller waves companies tend to setup a big project organization. Basically there’s nothing against an agile organization consisting of multiple teams such as SaFE or similar. However, there have to be considered some important topics.

I’d like to start with 2 phrases of the Agile Manifesto
„Individuals and Interactions over Processes and Tools“
„Customer collaboration over..“
 Agile Manifesto, 2001
First phrase tells us that tools should have less priority than direct interactions and communication. Well from my point of view in a big project organization that’s true AND false at the same time, let me explain you why!-On one hand it’s crucial to invest more in direct communication as in a single team organization. Otherwise we end up in well-known situation of the calling game, that first/team says red and until the end of the queue it’s green to the last. On the other hand in a scaled agile organization it’s impossible to talk to each teams from scaled product owner organization perspective and not all the teams could talk to each other at all the times. Otherwise team productivity will decrease dramatically. So key is identifying and planning dependencies. But product owner should not exclude teams in direct communication then again we come back to a multi-layered proxy organization. 2nd part of first sentence „..over Processes and Tools“ gets another importance in scaled agile organizations. Tools such as for agile portfolio management could support transparency in progress and budget burn-down. They deliver real time informations bottom up and prevent the calling game situations.


Image Source:
With real time information product refinements, problems identification and intervention could be done much earlier. Furthermore the agile organization, with it’s self organized approach, reduces overhead costs but also organizational risks.
“In reports about the failed project Insieme from the Swiss Fedural Departement of Tax the risks were much more positiv reported at management level, than originally at project level. For the followup project Fiscal-It Findel proposes reports on a half-year-based by the governement.”

Findel-Report, NZZ 4. April 14
That leads me to 2nd phrase „Customer collaboration over ..“. Beside self-organization of scaled agile organization the stakeholder involvement is key. Based at real time informations and feedback about the periodically delivered working increments the stakeholders take there responsibility and even big projects could be worked out successfully!-How agile is that if we send reports on a half-year base, as mentioned in the Findel-Report (Findel is the delegation for finance from the Swiss Governement)?
Tagged with: , , , , , ,
Veröffentlicht in scale, scrum

Will a centralizing of IT sourcing solve the image problem of Swiss government?

The IT departments in Swiss Government hit several times the headlines in the past few months. Some of there projects of importance were massive over budget, failed and big question marks  came up about processes for request for proposal and contracting. But what is the root cause of all that and will it really help to centralize IT sourcing as mentioned in the Swiss press ( today? 
As I was not involved in these project failures myselfs I just can assume. However, lets reflect the general situation with big projects in none-IT sector and address some potential advices using a more agile approach.
The IT projects were related to Federal Employment Office RAV Image Source: Martin Rütschi Keystone
It seems main issue is that the customer at government was not familiar with such big IT projects. Here a centralized IT sourcing for sure could help, but just in area of IT partner management and request for proposals. In other words I expect root cause in much more areas:
  • CHF 34 till 100 Mio. Projects are too big to manage
  • Such big projects could be specified just roughly or a final detailed specification is already out-of-date
  • These rough specifications will defines scope and budget
  • So big projects lasts for years and create a lot of changes in scope and budget
  • A long through-put-time leeds to changes of key persons
But how to overcome all this potential problems?-May be an agile approach could help here. But therefor a paradigm change will be needed at customer and supplier side.
As a starting point the big project has to be split into waves of several small projects. This reduces scope and so complexity of requesting for proposals. The through-put-time in contracting could be reduced one more time if goal-based contracts were negotiated. This needs mutual granting of trust in rough estimations, billing at a time and material bases, with flexibility in scope. Furthermore customer needs to overtake his responsibility and include all stakeholders during all project into decisions and reviews. If we are aware of that just 20% of all features built are really used by end user, we will set project focus to business outcome. This will make project up to 80% more cost efficient.
Just 20% of all features built are really used
Standish Group, 2013
Now, if you’re new to agile you’d say this is a win-loose situation for supplier/customer?-But then you have to consider, that time/quality and also costs are fixed. Per definition of goals customer knows, what he will get in minimum. This minimum will be a working increment, as customer gets  delivered within short cycles of 1-2 weeks one in review. All this flexibility allows customer to include in every review end user feedback, that could be implemented with no additional costs (Changes for free). Last but not least customer gets freedom and flexibility to change supplier from wave to wave. So it’ll be in supplier’s interest to deliver expected quality and becoming a real partner. Even if that means to deliver faster the right thing and getting money for nothing!
Succeeding in these paradigm changes customer and supplier will create a win-win situation!-So what are we waiting for?
Veröffentlicht in scrum

How important is consideration of cultural differences in Scrum Teams?

One of most important thing in Scrum is forming a self organized team. Do you consider cultural differences while social integration of team members and how do you know them in advance?

Especially in distributed Scrum Teams the local and delocated team members have differences in culture. But even local scrum teams might have team members with another cultural background. So it’s important to be aware of that while forming a team and while running scrum of course too.

For social integration we usually bring the delocated team members together. Over a longer time at the beginning and later on for short time on periodical base at one or the other location, e.g. for an on site sprint retrospective-, sprint demo- or planning meeting. As I’m working together with my team members already some years I know them very well. However, I’m sometimes asked by potential customers about cultural differences and if we’ve issues cause of those?


This always was a difficult question for me, because I could give them just my personal perspective but no educated data. I’m happy to present you the solution: „The Hofstede Center’s research into national and organizational culture“. They offer a great FREE country comparison tool on there website National Culture, Countries.
The tool makes a culture comparison using the following 5 dimensions:
  • Power distance (PDI): This dimension deals with the fact that all individuals in societies are not equal – it expresses the attitude of the culture towards these inequalities amongst us. Power distance is defined as the extent to which the less powerful members of institutions and organisations within a country expect and accept that power is distributed unequally.
  • Individualism (IDV): The fundamental issue addressed by this dimension is the degree of interdependence a society maintains among its members. It has to do with whether people´s self-image is defined in terms of “I” or “We”. In Individualist societies people are supposed to look after themselves and their direct family only. In Collectivist societies people belong to ‘in groups’ that take care of them in exchange for loyalty.
  • Masculinity / Femininity (MAS): A high score (masculine) on this dimension indicates that the society will be driven by competition, achievement and success, with success being defined by the winner / best in field – a value system that starts in school and continues throughout organisational behavior. A low score (feminine) on the dimension means that the dominant values in society are caring for others and quality of life. A feminine society is one where quality of life is the sign of success and standing out from the crowd is not admirable. The fundamental issue here is what motivates people, wanting to be the best (masculine) or liking what you do (feminine).
  • Uncertainty avoidance (UAI): The dimension Uncertainty Avoidance has to do with the way that a society deals with the fact that the future can never be known: should we try to control the future or just let it happen? This ambiguity brings with it anxiety and different cultures have learnt to deal with this anxiety in different ways.  The extent to which the members of a culture feel threatened by ambiguous or unknown situations and have created beliefs and institutions that try to avoid these is reflected in the UAI score.
  • Long term orientation (LTO): The long term orientation dimension is closely related to the teachings of Confucius and can be interpreted as dealing with society’s search for virtue, the extent to which a society shows a pragmatic future-oriented perspective rather than a conventional historical short-term point of view.
Thanks to The Hofstede Center for publishing this data and for the open access of the tool!
Example 1: Nearshoring in Serbia
As my team consists of team members from Switzerland and Serbia I’d like to show you an example culture comparison using that tool:

Basically the 5 dimensions are very general, but I must say it’s surprisingly accurate and was helpful for understanding some of issues we had. Find some of my thoughts below:
  • PDI is very important dimension in Scrum, you have to bring team members to similar level to become a self organized and proactive team.
  • Regarding IDV we didn’t encountered problems, but we will more focus to this dimension in regards to inter-team cooperation.
  • MAS could become problem in case of e.g. demanding Product Owner in Switzerland, that is not challenged by team members abroad.
  • UAI, the avoidance of uncertaincy is helpful from point of view of quality and delivery aspects. But could be challenging to find the balance between certaincy and innovation.
  • Tradition (LTO) is strong in both countries, that was a good base for long-therm oriented teams.
Example 2: Big „Canton“ Germany
Interesting might be also the comparison with the big „Canton“ Germany. As Swiss people often think we are so much different :-).

All in, consideration of cultural differences matters a lot in scrum teams. Especially while forming a self-organized team the educated data of  The Hofstede Center could help.
Feel free to make a cultural comparison with your current or future scrum team. I’m interested into your results?
Tagged with: , , , ,
Veröffentlicht in scrum

Are Scrum Members compatible with line Organization?

Scrum changes working culture of the team members fundamental, or as Henrik Kniberg from said: „Scrum Teams are designed to feel like a mini-Startup“. But is this still compatible with traditional line Organization?
All companies I know, that run Scrum, still have a line organization. Idea of line organization is to link organizational units, with the help of managing relations, to a hierarchical organization system. In other words e.g. all Scrum Masters are part of a Scrum Master line, developer of a developer line, etc. By today there are a lot of  organization types known and hybrid implementations possible too. Don’t take the models in following graphic to serious, but it shows up „modern” implementations :-).
But isn’t that hierarchical thinking incompatible with the self-organized multifunctional approach of Scrum?-Do we really need a managing role that has the last word and decides e.g. about strategy, salary, etc?
May be we find a solutions thinking about, what Henrik said: How we’d organize a mini-startup, where all employees are company owners?-I personally like to be part of a team, where all are equal partners, similar to a Scrum Team. Of course the roles have to be shared, somebody has to take over product owner hat, another scrum master hat, etc. Depending at personal interests this could be fixed- or rotating roles. Critical decisions would be taken as team, well known in Scrum as team commitment. While base for decision would be worked out in team as well, as we do with a story. Planning meeting would help to structure our tasks in mini-startup, we would set Team goal for next time boxed sprint and would review result, but also continuously improve ourselves through retrospective’s.
If our mini-startup is getting bigger, we split team in two to minimize overhead. From my point of view 3 things would be important during scaling:
  1. Product Owner is working with both teams
  2. New Team members getting equal partners too
  3. Teams are building guild’s depending at topics
Now you’d say Product Owner is getting manager of mini-startup, but this is not true. He’s still equal partner to team members, but he has other focus. Decisions are still taken in team or by team representatives depending at topic. The more we scale organization the more important Guild’s will become. Those would be the glue to keep independent teams together, to exchange best practices and to take decisions within guild’s topic.
Wouldn’t that be more compatible company organization for Scrum Teams?-Or how you’d design your agile organization?
Tagged with: , , , , , , , ,
Veröffentlicht in scrum

Shared vs. dedicated Scrum Master in distributed Teams

No matter if you’re running a distributed Scrum or not you’ve to find balance of sharing most experienced Scrum Masters over multiple Teams and facilitating a scrum Team the best.
Each team has to have a Scrum Master in Scrum. One approach is to share these rare resources over multiple Teams, another to have a dedicated Scrum Master per Team. Lets compare both options and think about what is best for distributed Scrum Teams.  

Shared Scrum Master
Especially if a company is new to Scrum experienced Scrum Masters are very rare. Often those are expensive external Scrum Consultants, so it’s a good approach to share these Capacity and Costs over multiple Teams. One disadvantage I see in sharing Scrum Master is, that from point of view of team Scrum Master looks like an external assessor. This needs a lot of investment in trust and social integration. The advantage of a shared Scrum Master is, his personal distance and objectivity.
It’s getting tricky in a distributed Scrum Team, where you might have 2 or more parts of team at different locations handled by same Product owner. In that case it’s best practice, that each part of team has a local Scrum Master. Main reason is, that just if Scrum Master is on site he could take over responsibility of Done and facilitate the team the best. Now this mean in a distributed Scrum Team we don’t need just one-, but one shared Scrum Master per location.
Dedicated Scrum Master
Another option is to have a dedicated Scrum Master per Team. This often is a regular Team Member, that is actively e.g. developing too, but has additional role of Scrum Master. This has advantage that he knows them personal, with there strengths, problems, etc from daily work and could facilitate the team very easy. On the other hand fully integrated Scrum Master won’t  have personal distance to team, that could generate other problems. Especially for companies that are new to Scrum this could be a very challenging option, cause the learning curve will be much longer in that approach if no experienced Scrum Masters are already available within company.
In a distributed Scrum Team this has advantage that we don’t need additional resources. It’s just covered within multifunctional team.
Both options have it’s advantages and disadvantages. In distributed teams it’s recommended to have dedicated Scrum Masters per location. Depending at team size this could be covered by an existing team member in personnel union. However, as we know that a distributed Scrum is the most complex thing in Scrum it needs most experienced Scrum Masters available. If there are no experienced Scrum Masters in Company yet there is option to take the longer learning curve, or to add a shared external Scrum Coach, that is consulting all the dedicated Scrum Masters.
We at made exactly this several years ago. By today very experienced Scrum Masters are still rare, but we established a guild meeting (something like a retrospective Meetings over all Scrum Masters), were we meet and exchange latest experiences, pitfalls, tools, etc. So less experienced Scrum Masters are facilitated and external in-team coaching time was reduced to zero. Furthermore this Scrum Competence Center is responsible for:
  • Internal Standards and best Practices 
  • Initial Training of new Team Members and Scrum Masters in Scrum and Tools 
  • Internal & External Scrum Consulting (Coaching in Scrum Setup/Implementation/Meetings, overtaking Scrum Master or Product Owner Role, etc)
 This gave us flexibility we needed to add new distributed Scrum Teams very easily and shortest possible learning curve. But also to consult our internal team and our Customers in best Practices continuously.
How you solved Scrum Master Implementation with what experiences?
Tagged with: , , , , , , ,
Veröffentlicht in scrum


Mirko Kleiner is a Blogger, Agilist (Agile Evangelist), Vice President Delivery at youngculture AG, Twitterer, Father of 2 beautyful Sons and Partner of a lovely Wife.

Verifizierte Dienste

Vollständiges Profil anzeigen →


Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 409 Followern an