Viewing entries tagged
Scrum Master

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

Shared vs. dedicated Scrum Master in distributed Teams

Comment

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 t

hese 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.

Conclusion

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.

Scrum-master-distributed-team

We at youngculture.com 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?

Comment

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

Comment

Checklist to become a good Product Owner

What does the profile of a good Product Owner cover, what are his duties and how he could achieve those? Bild

Image Source: http://inspiretilyouexpire.files.wordpress.com

Most of you might know Michael James' ScrumMaster Checklist, which already mentioned some tasks regarding improving Product Owner from Scrum Master perspective. Recently Lare Lekman posted a checklist to become a good Product Owner.

2013-10-04_16-21-12

Download product-owner-checklist-september-2013-v2

I will for sure use it. What I personally like is that Lare tried to cover Product Owner's role 360° and with the point system  at the bottom "My current Product Owner Score is ________ / 28 points." you have a neutral KPI as base for discussions.

[polldaddy poll=7449444]

Comment