Viewing entries tagged
Agile

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

1 Comment

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:

2014-07-20_21-16-13

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)
agile-forecasting-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.

agile-forecasting-sheet

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.

1 Comment

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

Comment

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.

future-of-speech-mirko-kleiner
BnGmqXlIgAAapAH

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.

[slideshare id=34468771&style=border:1px solid #CCC; border-width:1px 1px 0; margin-bottom:5px; max-width: 100%;&sc=no]

REVOLUTION - How agile cooperation models substitute classical client/vendor relationships

from

Mirko Kleiner

Comment

 How Hierarchy prevents Agility

3 Comments

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.

trafic-organization

I’d like to start with 2 phrases of the Agile Manifesto

„Individuals and Interactions over Processes and Tools“
and
„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.

agile-portfolio

Image Source: rallydev.com

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)?

3 Comments

Are Scrum Members compatible with line Organization?

2 Comments

Are Scrum Members compatible with line Organization?

Scrum changes working culture of the team members fundamental, or as Henrik Kniberg from 

Spotify.com

 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 :-).

BZCJ685CQAA3TA_.png-large

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?

2 Comments

Does Scrum generate a Project Overhead?

2 Comments

Does Scrum generate a Project Overhead?

In project negotiations I'm sometimes getting told that Scrum is not an option at customer side as cooperation model. From Customer point of view Scrum generates a management overhead, by a lot of additional meetings and customer doesn’t have whether capacities, nor won’t pay for.

 Of course such statements came from Scrum Newby’s, however lets make an example calculation of "overhead

“ and find my conclusions from the field about.

First let’s imagine we do a one-week sprint. As you know all rituals in scrum are time boxed relatively to sprint length. Only exception is 

daily Scrum Meeting, that is always 15 minutes in maximum.

 I’ve visualized below possible schedule of all rituals, while light gray area’s is "productive" implementation time.

fac3c1caefcaf32652e052867b2b5cd3

Already according the painting above it’s visible that there is just a minimal „overhead“. However, lets make a example calculations: 

  • a development team of 5 Full-time Employees (FTE’s)
  • a day has 8 working hours
  • Scrum Master is attending all Meetings, that is covered by a Scrum Expert of the 5 Developers 
  • Product Owner is as much as possible accessible by team and will attend all meetings of Scrum

Topic

Capacity [Hours]

Description

Total Capacity of Development Team

200

[COUNT OF FULL-TIME-EMPLOYEE] X [8 HOURS] X [5 DAYS]

Scrum Master „Overhead"

- 4.75

[PLANNING] + [ALL DAILY SCRUM’S] + [REVIEW]

 + [RETROSPECTIVE]

Team "Overhead"

- 19

([COUNT OF FULL-TIME-EMPLOYEE] - 1) X 

[PLANNING] + [ALL DAILY SCRUM’S] + [REVIEW]

 + [RETROSPECTIVE]

„Real“ Team Capacity

176.25

Product Owner „Overhead"

4.75

[PLANNING] + [ALL DAILY SCRUM’S] + [REVIEW]

 + [RETROSPECTIVE]

Find below my conclusions related to the calculations of various "overhead’s" above:

Team

Using Scrum the team has in general a 

productivity time of 88.1%

. From experience everything more than 80% is 

very good 

comparing to traditional approaches

. As Scrum keeps Product Backlog Items ready in advance, continous delivery and high workload is guaranteed. If we break down „overhead" for one employee we’re talking about 4.75 hours per week. If we reduce this by 3 hours of planning/review meeting, that could be counted to productive time too, a team member just „looses“ 1.75 hours. This could be explained as a regular weekly status meeting in a traditional approach, without benefits of Scrum in general.

Scrum Master

The Scrum Master won’t usually attend to all the meetings, but he ensures that those take place. However, there are other tasks e.g. removement of impediments, facilitation of team members, etc that need additional time. From experience 1.9% time usage for Scrum Master could be realistic for a 

well rehearsed scrum team. On the other hand development teams in traditional cooperation models are not self organized and need a team leader in area of 20% similar to a technical project manager, that will be for sure more than time usage of a Scrum Master.

Product Owner

Even if Product Owner needs additional 10% of his time for direct clarifications an

 experience Product Owner could work it out with 11.9% of his time. This is far away better than usual time needed for Project Management (usually 20% in minimum), Business Analyses (30% of all project time), etc. This contains just cooperation with team and obviously time for stakeholder management, product refinement, etc have to be added. However this customers often forget to count in traditional approaches.

In general Scrum generates a smaller overhead for additional meetings, than traditional approaches. But those meetings ensures continous communication and delivery. Together with the short delivery cycles and the daily Scrum Meetings Scrum reduce risks and ensure business success. On top Scrum could improve delivery performance 2 - 8 times and spare additional costs by delivering faster. 

Sorry Newby's, don’t denounce Scrum if you don’t know it :-). 

2 Comments

Why Scrum is that successful - Another perspective

4 Comments

Why Scrum is that successful - Another perspective

I recently talked with a Scrum Newby about why scrum is that successful and what makes the difference. I explained him that based at an instrument he knew, the task force.A task force is a temporary grouping of best resources for the accomplishment of a specific objective within shortest possible time. In IT it’s usually to solve a business critical incident.

4844707562_e22e72af2d

If we compare a scrum team with a Task Force I see a lot of overlappings. We put together a multi-funtional team, containing of best resources each to accomplish fastest possible our objectives. While this process the scrum team has full management attention with direct communication to. Outcome has to fulfill highest business value, otherwise company looses time-to-market and it will become a problem. Only difference is that a Task Force will be disband after incident is solved. In other words we also could say:

"Scrum Teams are ongoing Task Forces"
Mirko Kleiner, 11/2013

Interesting point thinking about Task Forces is, that this is not new -but used very rarely- and just in extreme situations. Question is why, it’s approved and one of multiple reasons why Scrum is that successful.

4 Comments

Double O Model - How a Product Owner can escape the hungry Beast Scrum

2 Comments

Double O Model - How a Product Owner can escape the hungry Beast Scrum

As Richard Stinear mentioned  recently  "Scrum is a hungry Beast, that wants to be feed constantly by Product owner". Lets see how Product Owner could escape this end-less-loop.

Gabrielle Benefield recently published by Twitter the Double O Model (see graph below). As I understood it will be part of her new Book, that comes out soon :-). It shows the 2 O's, where on the left hand side Product Owner is creating new Options and Innovations that will bring valuable Outcome. On the other side we see the delivery cycle, that runs experiments with common Output like Stories, Bugfixes, etc. Those impact are measured/adapted and flow back to Create Options O.

BWH1fK3CYAAtvQ4.png-large

By Alistair Cockburn @TotherAlistair

What is danger now if a Product Owner is fully occupied in the delivery O, without any time left for Innovation.

Some Product Owners are captured in delivering Output, instead of caring about valuable Outcome

Gabrielle Benefield, 10/2013

In other Words Team and Product Owner are just focused to deliver fast, but wrong, non-valuable Output. To get back to the left O it's recommended to constantly do a  critical review of your current top Backlog Items and check there Outcome. As Alternativ go back to your stakeholders, the team and ask for the 2 most valuable Requests each and try to calculate the costs if Item wont be Done.

2 Comments

Comment

My Talk about distributed Scrum @CodeCamp Romania

Today I held at Developer Conference CodeCamp in Isai, Romania a talk about our experiences in setup and run a distributed scrum. I'd like to share with you some impressions, over 150 attendees came to me speech. While the whole event had 600+ registered visitors.

1383447_578133535557745_2126878009_nFoto-11

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.

[slideshare id=27100393&style=border:1px solid #CCC;border-width:1px 1px 0;margin-bottom:5px&sc=no]

Download Link:

Comment

1 Comment

When we have a distributed Scrum?

I'd like to present you my personal definition of "Distributed Scrum". Do not take it too serious. But on the other hand it's not so wrong too. In discussions with newbie's about distributed scrum I often notice, that they put it in relation with nearshore/offshore teams. This gave me reason for finding a simple definition, that makes sense for business people too :-).

2013-10-17_09-35-40

It's a fact that a lot of informal talks but also social integration are important topics during a coffee break. Thinking about this I came up with idea, that

TO BE ONE TEAM IT "HAS" TO USE SAME COFFEE MACHINE.

Mirko Kleiner, 10/2013

If they don't do, they are distributed and should organize themselves as distributed scrum teams do. I often saw on customer side, that those teams are not aware of being a distributed teams. In other words companies with multiple offices, even in same street/city/country have distributed teams and should be aware of that while implementing scrum.

1 Comment

Comment

Importance of Meetings on same level in distributed Teams

While sharing customer experiences about distributed scrum a very simple action came up, that could have big impact to team culture and satisfaction. Last week we made a workshop with one of our team sourcing customers, that has it's own nearshore team at youngculture as workbench extension of his local developement team. While discussion with customer about they're implementation of a distributed scrum we noticed one simple action I'd like to share with you.

Usually meetings, e.g. daily standup, were done using video conferencing. Therefor each part of team moves to it's meeting room. So far so good.

augenhöhe

In this case scrum master was part of local part of scrum team. So local team was talking and talking and often after a while they realized, that delocated part of scrum team was recently disconnected because of network issue. This sounds now nothing special, this happened to everybody of us in the past.

However, customer had afterwards internal discussions about this from another perspective. How this meeting passed off until this moment from point of view of delocated part of team?-The local part of team put themselfs in place of delocated team members and decided together the following action.

From now on scrum master was in any meetings added remotely too. In my opinion they reached with this very simple action, that  both parts of team are handled at same level. Doing so local part of team accepted delocated part of team as full-fledged team members!

To be honest I never looked at this from this perspective, but I will give this higher priority in the future for sure.

Comment