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 management team. an Agile/Scrum process for Lulu’s

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

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

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?

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

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 organizationallevel 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 Scrum Process Cost Owner

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

6