Lulu Enterprises, Inc.

860 Aviation Parkway

Suite 300
Morrisville, NC 27560
Phone 919 447 3273

Management Scrum
Recommendation

Looking Towards an Agile

Organization

Prepared by Chris Anderson

August 20, 2006
Management Scrum Recommendation
Looking Towards an Agile Organization
Purpose

Background

During the Agile Retrospective sessions the week of August 7, 2006,

one of the top 5 recommendations from the team was for other teams,
including management, to utilize Agile practices and be tied into the
Development Agile process as much as possible. This report is the
result of an action item that was assigned in response to that
recommendation.

Action Item

Research and recommend an Agile/Scrum process for Lulu’s

management team.

Recommendation

MetaScrum1

Weekly meeting of all stakeholders

 Includes senior management and sales, marketing, development,

services, and support leadership

Led by Product Owner

 What did teams accomplish last week?

 What will they accomplish this week?

 What are impediments?

All product decisions made here

 All releases started, stopped, or modified here

 All decisions communicated to entire company same day

1
See “Scrum II: Better, Faster, Cooler!” presentation by Jeff Sutherland
(http://jeffsutherland.com/scrum/ScrumIIAgile2005.pdf)

2
  Damage control plan for customers and partners executed on same
day by senior management

This weekly meeting would be approximately 1 to 1.5 hours long and

would need to be well-attended so as many decisions as possible can
be made on the spot and all teams leave the room on the same page.
This requires a very open line of communication where the entire
organization knows all issues and the company’s position on each.

The weekly regularity is important to provide management

consolidated updates and for the teams to get inter-team issues voiced
and addressed. We would need to make sure that we do not spend
much time preparing extra reports for this meeting but rather just use
the tracking tools we will already be using on a daily basis while driving
our iterations.

Organizational ScrumMaster2

Identify an Organizational ScrumMaster

 Responsible for identification of organizational impediments to the

Agile development process

 Responsible for working within the organization to cause the

change that removes organizational impediments

 Similar to a ScrumMaster, except the impediments are on the

organizational level, outside singular teams

Identify an Organizational “Product Owner”

 Responsible for creation, maintenance, and prioritization of the

Organizational Product Backlog

 Organizational Backlog is comprised of organizational impediments

requiring attention

 Generally, the items on the Organizational Backlog can be

categorized in one of the following four areas:

 Scrum Process Itself – what impediments are

occurring that get in the way of the Scrum
process?

 People Practices – what people practices are getting

in the way of developing, distributing, supporting
and using products to maximize the fulfillment of
everyone involved?
2
See “A CIO's Playbook for Adopting the Scrum Method of Achieving Software Agility” by Rally
Software Development Corporation, Ken Schwaber, and ScrumAlliance with Dean Leffingwell and
Hubert Smits (http://www.rallydev.com/documents/CIO_Playbook_For_Adopting_Scrum_080805.pdf)

3
  Product Engineering Practices – what practices are
impeding the optimization of return on
investment, or maximizing the mission of the
organization from a product perspective, and what
impediments are there to optimized product
development and delivery?

 Organizational Issues – what systemic organizational

issues - that lie clearly outside the team’s control -
are preventing the teams from delivering software
to its users more quickly?

 The Backlog should be organized by these categories and then the

categories prioritized separately

 An example Organizational Product Backlog has been included in

this document and can be used as a starting place (from Ken
Schwaber’s whitepaper)

Utilize Scrum Process to Address Organizational Backlog

 Organize Sprints around the tasks required to make the changes

necessary to address impediments

 Team made of up members of the organization who will make the

changes (management team is my expectation to be the primary
members of the Organizational Scrum team)

 Schedule regular Scrum meetings (perhaps daily depending on

size, criticality of items in the backlog) which should be just like the
development Scrum meetings (i.e. quick, standing, and just the 3
Scrum status questions).

 Discontinue Organizational Scrums when Backlog is reduced to zero

or when decisions are made to postpone any further organizational-
level changes; restart process during planning for next release

 Should take the place of weekly management team meeting

Observations

While I know that these recommendations may seem too involved for
the management team to undertake and may provide more structure
than is deemed necessary, the fact that communication within the
organization was cited many times during the Agile Retrospective
should be motivation enough to “do something different” as Jean
Tabaka repeatedly told us during our training. Plus, there is something
to be said about the effect it would have on the teams if they saw the
management teams following a Scrum-like process as well.

4
Many organizations have implemented Scrum from the bottom-up,
which is what is happening here at Lulu. So, we are certainly not
doomed if the above recommendations are not utilized at this point.
But, as we move forward I think it is important that we continue to
figure out ways to get the entire organization into the same steady
rhythm and utilizing the same vocabulary. The impact on our speed
would be dramatic, I think.

5
 Example Organizational Backlog

Impact Cost Owner

Scrum Process
People arrive late to daily Scrum and do not support basic
discipline
Scrum meetings take too long – team is bored and considers the
time unproductive
ScrumMaster dictates design decisions or micromanages
Teams are too large for effective daily Scrum and Sprint planning
Teams do not report task remaining time for BurnDown analysis
People Practices
Individuals interrupted and tasked to work outside the Sprint
Teams isolated in cubicle and not in open Scrum area
Team members not accountable for personal Sprint
commitments
Individuals are multiplexed across too many projects and teams
Product Engineering Practices
Cross-functional resources for definition, design, implementation
and test are not present on the team
Sprints do not fully implement and test potentially deployable
increments of customer valued features
Product owner not easily available/not integral to team
System integration is not forced at each Sprint
Product owner won’t split up massive product backlog items to
fit within a Sprint.
Teams have ineffective resources for automating builds and
integrations
Features loaded into Sprint after Sprint begins
Organizational Issues
Software process police regulate to ineffective processes
Management assumes fixed price, fixed time, fixed functionality
delivery posture
Software Test/and or System QA is separate organization and is
not integrated with team
Organization rewards individual, rather than team behavior
Existing rules or software capitalization demand adherence to
document-driven, waterfall approaches
Teams not co-located to maximum extent feasible
Teams cannot make small organizational, space and expense
decisions needed to do their job
Legend: Impact of this impediment to the project (0-9, 0 low, 9 high),
Cost to resolve this impediment (0-9, 0 low, 9 high)
Owner: Point in an organization for resolution: C – CEO/CTO/COO/CFO, PR –
President, O – Operations Management, P – Product Management, E –
Engineering Management, U - UX Management, T – Team