Why Scrum Works (And How to Sustain It)

This post summarizes Adam’s five-minute Ignite lightning talk entitled Why Scrum Works (And How to Sustain It).

Scrum is a flexible process framework that provides protocols and simple rules for organizing the work of development teams.

You should care about Scrum because Scrum helps solve a hard problem that nearly every software company has faced: how to establish and maintain development teams that deliver what customers want.

Scrum works by building teams. First and foremost Scrum solves the problem of reliably delivering what customers want by shifting the fundamental focus of an organization from the individual level to the team level.

And Scrum works by improving time management. By structuring organizational time management, good Scrum teams are able to spend less than 10% of their time deciding what to do and 90% of their time focused on implementing their plans.

Scrum works as an open standard. The benefits of this include broad community support and wide range of product and service offerings aligned to Scrum. Instead of building a process from scratch, you can start with Scrum and build from there.

Scrum works by creating social capital. Scrum prescribes networks so relationships form easily. It increases alignment, builds and maintains trust, and enhances a sense of motivation and control both inside and outside the team.

Scrum moves the dip to the left and accelerates the payback. Because of this organizations are more likely to follow through with it. Scrum works because you can implement it rapidly.

Scrum is a process framework that works for organizing teams who can build what customers want. Scrum solves a problem that almost everyone has by creating social capital and moving the adoption curve to the left. But once you’ve gotten started how can you sustain Scrum?

You can sustain Scrum by practicing your craft. If you’re a team member, good technical practices like test driven development, continuous integration, and the use of design patterns complement and enhance Scrum.

You can sustain Scrum by upgrading your management skills. Self-organizing teams don’t need to be told what to do and how to do it. They do thrive on servant leadership. Coaching and mentoring protocols can be learned if you are ready to take management to a new level.

You can sustain Scrum by upgrading Scrum itself. A 2-day training course can give you the minimum you need to operate a Scrum Team, but becoming a true master takes years of learning. Begin learning right away by improving your facilitation skills for retrospectives that can sustain continuous improvement.

You can sustain Scrum by redeploying resources to new frontiers. Scrum helps solve the hard problem of organizing the development team in a new way. For Scrum to really take hold you have to stop using the old way and focus people on the next hard problem.

If you practice your craft, upgrade your management skills, upgrade scrum, and redeploy your resources you can use your runway to sustain scrum and avoid a double dip.
Scrum is Smart because it makes easier the hard problem of delivering what the customer wants, allowing you to align your brainpower around building better products

Teamwork Required: Managing Agile Application Delivery in a Matrix Organization

Adam Light, Chris Vike, and Diana Larsen; Cutter Consortium Agile Product & Project Management Executive Update Vol. 12, No. 19

Effectively implemented, agile methods represent a leap in the ability to organize and direct knowledge work in a manner that creates and sustains greater throughput of client-valued functionality than methods previously employed. What determines whether managers are up to the task of managing an integrated agile organization and, more importantly, how can we help them catch up when they are not?

This Cutter Consortium Executive Update describes and analyzes experiences within the IT department of one midsized company as it transitioned from what had been a highly decentralized application delivery function to an integrated system organized using agile methods in combination with a matrix management structure. While this is a case study of one particular organization in a specific context, we believe it offers some universal lessons.

Adopting agile methods begins a journey of continuous improvement and so, after about two years, the story of this transition is still being written. Our experience thus far has been that while self-organizing teams may enable the organization to operate from day to day without active management, a more integrated organization and more productive teams make the value-add of managers highly transparent and place a premium on specific leadership skills.

 [Register with Cutter to Download Complimentary Copy]

Use a Casting Call to Form Cross-functional Teams

Cross-functional teams are a cornerstone of agile methods. But work groups and departments organized functionally are more prevalent organizational forms. Trying out cross-functional teams is usually straightforward enough: you recruit a talented group of individuals who are willing to try new things and you run a pilot project. But when your pilot shows promising results and obtains buy-in to organize cross-functional teams at a larger scale, things may become much more challenging!

The primary challenge in scaling the use of cross-functional teams is that a functional organization with a small fraction of cross-functional teams is a stable form, and an organization of cross-functional teams with a small fraction of functional teams is a stable form, but gradual transition between the two states is fraught with frustration and counter-productive side effects. This article describes a step-by-step method for forming cross-functional teams that is rapid, relatively painless, and balances self-organization with managerial decision making.

I have used the “casting call” process to design up to fifteen cross-functional teams in a matter of weeks. Formation of those teams has gone smoothly and the teams have performed well once formed. The following five steps describe the process.

  1. Begin with the work you have. Describe and organize the work your set of teams must accomplish. What this work looks like may differ a great deal from organization to organization and within an organization over time. For example: a product development organization may be focused on one large release or initiative, but once that project completes, the work may split into multiple streams for customer enhancements, technical support, and research and development for the next big initiative. In any case, start with what you know and your best set of assumptions about what you don’t know. If you can’t see very far into the future use the work of the recent past as a guide.
  2. Define the teams that you need in terms of knowledge, skills, and experience. This step is probably the most difficult one since it encapsulates most of the hard decisions related to forming cross-functional teams. Fundamentally, you need to decide what kind of teams you want to have (component or feature teams for example) and how you define the products or business processes to which you will align your teams. The key to this second step is keeping definitions at the team level in terms of skills, knowledge, and experience. For example: a team might require strong expertise in a particular business domain or specific technology, user-interface design skills, and Java performance-tuning skills. My experience has been that things will go much faster at this step if you keep specific team-member names out of the discussion and avoid succumbing to the temptation to divide up the existing teams and team members.
  3. Describe team attributes. Having described the work streams you expect to have and the ideal knowledge, skills, and experiences of teams that can deliver those work streams, you can now describe the attributes of the teams you need. Examples may include business domain, primary technologies, location, and whether the team provides reactive support and maintenance or works on new development projects. Team attributes should cover the aspects of the teams that are relevant to their prospective members.
  4. Take your show on the road! The next step is to obtain feedback on the work streams, team definitions, and team attributes – before aligning individuals to any specific teams. Depending on the size and geographic spread of your organization, some form of road show presentation usually does the trick. Be sure to visibly capture all the various ideas and criticisms. Then get your design team back together and see how you can make things better based on the feedback you’ve collected. Where you reject or don’t use specific suggestions, be sure to document the reasons.
  5. Match individuals to teams based on individual preferences and team attributes. Note that you aren’t asking people which team they want to join right now. You are asking them to rank their preferences for the kind of team they want to be on based on attributes of those teams. If you simply ask individuals to choose their favorite team you are running a popularity contest that collapses everything into one dimension and deriving no information that will allow you to tune things now or in the future. Not only will some number of people obviously get their second or third choice, you won’t learn very much about what people value – and neither will they since they haven’t been forced to reflect on it. But if you ask people whether it is more important to work as a Java developer or as part of a business intelligence team, now you’ve got two variables to assess and the individual has expressed a preference.

Exposing preferences provides the power of the casting call process. Being part of a team isn’t about every individual doing everything she wants to do all the time it is about a group of people achieving more than the sum of their individual parts. Designing multiple teams is hard because you must make trade-off decisions along multiple dimensions. Asking prospective team members to make the same type of choices puts everybody in the same difficult decision space. Though it may seem paradoxical, it can then be easier to satisfy a plurality of individual preferences on multiple dimensions than when you have fewer dimensions and less data to work with.

Exactly how you implement the above steps depends on the size of your organization and its culture. A survey may work best in a larger or more formal organization that values objective data. In a smaller organization you may be able to move more nimbly by organizing a series of workshops or even accomplishing all the steps in a single workshop. Whatever the approach, keep in mind that the participation of many individuals from different roles is what creates buy-in.

Even if you are very successful in designing stable, productive cross-functional teams, things will eventually change and you may want to re-run the casting call process. People will come and go, your business may change, or you may get better ideas for how to structure your teams relative to the work that needs doing. But even if none of these things happens to any great degree, people will change – both as a function of the work they do and what they learn,  and as a consequence of life events outside work. This is where the flexibility of a people-centric approach to team design really shines. Consider the example of a highly skilled and highly-motivated developer. When that developer also becomes the father of young children, working long hours with late-night conference calls to India in the name of shipping the latest product may become relatively less attractive, but when the children enter junior high school and saving for college becomes an imperative, priorities may align differently again. Agile methods embrace business change. The casting call works will because it also embraces the changes that happen in the lives of team members and the personal and business changes that they want to make for themselves and the organization.

Encouraging reorganization based on the collective choices of workers may seem radical to some managers, but it doesn’t have to be. With a step-by-step approach managers can control as much of the casting call process as they wish to. For example, in matching individuals to teams, managers may choose to override the expressed preference of an individual whose self-assessed readiness for a new role differs from their own judgement. Even when this does happen though, the nature of the decision-making conversation changes from one based on power (who gets to decide?) to one based on facts and information (why should we decide that way?; what are the trade-offs?; have we considered all the evidence?). When the process is working effectively, managers will find that they have finer-grained control than in the past about how to match individuals to teams but that they don’t need to exercise control all that often.

Plan to Re-Plan: Adaptive Planning & Agile Methods to Increase Value in Smart Metering Projects

Adam Light and Eric Spack; Autovation 2011; Washington, DC; September 27, 2011

In 2010, Portland General Electric won the Utilimetrics Award for “Excellence in AMI/Smart Grid Management.” A key component of the project business case included leveraging meter deployment to transform existing business processes and building new processes to extend the value of smart metering. The first part of this one-hour session chronicles lessons learned, including challenges met, obstacles overcome and a few near misses. The second portion describes the innovative methods used to drive project success and how the utility is now using those methods to deliver similar results from its other applications of technology.

[View PDF Presentation]

Chasing the Constraint Beyond the Development Team

Around the same time that the term “lean” was coined in the western business lexicon, Eliyahu Goldratt published his bestselling business novel The Goal which popularized the theory of constraints (TOC). Boiled down to its essence, the theory of constraints states that, at any given time, a system of production has one and only one constraint. Improvement away from the constraint will not improve performance of the system.

More thorough plot-spoiling summaries of the goal have been published elsewhere. Briefly stated, The Goal chronicles the exploits of a fictional manager of a midwest manufacturing plant as he struggles to improve delivery of orders in time to prevent his plant from closing. In the process he is aided by an enigmatic consultant figure named Jonah who bears an uncanny resemblance to Eliyahu Goldratt. The plant manager and his team discover constraint after constraint as they transform their plant from the worst-performing plant in the company to the best-performing plant.

At this point, in the story, the management team realizes that the constraint has moved outside of their plant and that further increases in manufacturing throughput will not deliver more profit until they can sell more of the products their plant produces, so they follow the constraint into the sales organization and convince the sales manager to address the issue there.

While software development and delivery processes may be more variable and less deterministic than many manufacturing processes, the theory of constraints can also be applied to software development. By analogy with The Goal, adopting agile methods often dramatically increases the the throughput of the software development function. If the system constraint was initially in the software development function, it is likely that agile adoption will cause it to move somewhere else.

In a workshop session I organized at the recent Agile 2011 conference in Salt Lake City, a diverse group of practitioners engaged in a focused discussion of this phenomenon. Their observations provided evidence that constraints do indeed move. The general pattern was that as teams adopted agile methods they became more productive and the constraint moved either upstream or downstream in the development value chain.