Viewing entries tagged
Project management

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