Build a Team Improvement Backlog

Retrospectives are the last thing a team does during a Sprint. There are a wide variety of approaches and formats one can use for Retrospectives, but the one thing all have in common is that the Retrospective must produce tangible results. One extremely effective way I have found to help ensure that the Retrospective meets this vital goal is to build a Team Improvement Backlog using the items the team identifies as action items.

A Team Improvement Backlog is nothing more than a prioritized list of action items the team comes up with during its Retrospectives. The most common recommendation, and one I heartily endorse, is that the team collectively chooses the top one or two items on the Team Improvement Backlog at or near the end of each Retrospective and then decides how to implement them and how to demonstrate success. Just like user stories, Team Improvement Backlog items need to have acceptance criteria -- the all-important definition of done.

There are a couple of nuances that can play into management of the Team Improvement Backlog. In general, items teams add to their improvement backlogs are public in keeping with the agile and Scrum values of openness and transparency. There are occasions, however, when I have recommended that certain items be kept private to the team. Examples include specific team interaction items, particularly when those items address individual behaviors. Retrospectives are sometimes more like the closed locker room meetings sports teams hold when they are experiencing a crisis. Teams typically do not allow reporters or even coaches into the locker room during such meetings simply because what the team members have to say to each other is strictly for their benefit as a team. In my coaching experience, private improvement backlog items are rare, but it's a handy tool to have in your bag especially when teams are storming.

Keep the Team Improvement Backlog visible in the team room and track progress at each Retrospective at the latest. Individuals who take on improvement items should also be talking about their work and plans during the Daily Scrum.

If you're not already using a Team Improvement Backlog, add this handy tool to your repertoire and use it to help your teams grow.

All for now....

...-.-

ScrumMaster Dilemmas

A few weeks ago, during a Product Owner class I was teaching, the lone practicing ScrumMaster in the room raised his hand after I had finished the section of the course reviewing Scrum roles. His question was basically this: "So, you just said one of the ScrumMaster's functions is to be a bulldozer, but when I solved a problem for my team last week, they accused me of 'throwing them under the bus' and now they won't talk about impediments anymore. What am I supposed to do?"

After learning more about the situation, I understood what had happened. At the last Retrospective, the team had raised an issue they were having with their Product Owner and, seeing himself as the fullback, snowplow, bulldozer, problem-solver, the ScrumMaster had simply taken the team's concerns to the Product Owner and worked out a solution. When he (the ScrumMaster) reported back to the team during a Daily Scrum his progress in resolving the issue with the Product Owner, the team reacted very negatively, as the ScrumMaster had described in his original question.

His confusion and genuine sense of hurt were palpable. He thought his role was to clear the road for the team so that they could get their work done as efficiently and effectively as possible. His point is entirely valid, but his experience demonstrates one of the many dilemmas that face ScrumMasters.

Take it to the team!

In her excellent book*, Lyssa Adkins gives this advice again and again. Self-organizing teams need to be empowered to solve their own problems -- or at least to devise prospective solutions to the problems they face. The ScrumMaster in my class did not realize that self-organizing teams, even those that have only been practicing for a few months, do not want to be presented with solutions to problems. Instead, as Lyssa points out, self-organizing teams want, and need, to be presented with problems. The team is then empowered to devise solutions -- and the team's solution will be the best one for that team. It may not be the solution the ScrumMaster would have chosen, but that does not change this essential fact.

Despite the best of intentions, ScrumMasters run into difficulties with their teams when they take on problems and solve them without team involvement. The team may ask their ScrumMaster to implement the solution to a problem, but the team itself needs to solve the problem. Many ScrumMasters came from backgrounds where individual problem solving was a major part of their job descriptions. Perhaps they were even evaluated on the basis of their individual problem-solving prowess. In a Scrum (or other agile framework) team environment, the equation changes. Problem solving abilities are still valuable, but within the context of of the self-organizing team.

ScrumMasters must engage in a delicate balancing act, being the bulldozer, fullback, or snowplow for their team, yet not imposing solutions on the team. It is more difficult to achieve this balance when a ScrumMaster is responsible for more than one team. Under pressure to help their teams succeed and with a severely limited amount of time and attention to offer to each team, such ScrumMasters are naturally inclined to gather lists of problems and run with them, handing solutions to their teams in rapid succession. This situation is bad for the teams, stunting their growth and inviting resentment against their ScrumMaster; it is also bad for the ScrumMaster who never really has time to get to know each team and the various individuals at the depth necessary to achieve the highest degree of effectiveness.

So what's a ScrumMaster to do? "Take it to the team," let the team solve problems, and keep the wolves at bay.

All for now....

...-.-

*Lyssa Adkins, Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition. Upper Saddle River, NJ: Addison-Wesley, 2010.

Scrum is more than just iterative and incremental

People often talk about Scrum as if it were nothing more than an iterative, incremental development process. Taking just these two aspects of Scrum makes it seem like it would be easy just to bolt Scrum onto existing development practices and organizational structures. I have trained and coached and talked -- either in person or on discussion lists -- with people who were completely comfortable calling their functionally delimited, mini-waterfall processes "Scrum" or "Agile."

"Well, we deliver a release every month that builds on previous month's release," is a common refrain.

A few quick questions reveal what's actually going on:
"Great! How's your quality? Is it getting better with each release? Are your teams getting better? Does every release contain the most valuable features you could possibly deliver?"

"Um, well...." is the usual response when an organization has adopted the superficial qualities of Scrum while ignoring the deeper principles and the practices they inform.

Iterative and incremental development are two results of Scrum done well, not the essence of Scrum. So what, you ask, is the essence of Scrum? I believe Scrum is about building cross-functional teams that are capable of learning how to do better work every day. Focusing on working software as the primary measure of progress by making use of the Sprint and daily planning cycles and the Sprint Review (to show our work) provides the framework for technical innovation -- and more basically, getting the job done, which is a huge challenge by itself in most organizations. The Retrospective gives teams the mechanism to improve both their degree of teamwork and, to a greater or lesser extent, the organizational environment in which they work. Learning teams, when propagated and nurtured, produce learning organizations that have a built-in competitive advantage over their less dynamic competitors.

Scrum is also about letting go of false measures, unrealistic planning, and failed control mechanisms. Measuring team throughput (Velocity) rather individual utilization provides a realistic tool for planning. The planning itself changes from activity and milestone-based to feature- and value-based, using teams' demonstrated ability to deliver working software as the key metric. Having teams pull work from the top of a prioritized Product Backlog ensures that, by definition, the highest-priority features are being worked on at all times and that each release contains the highest-priority, and therefore most valuable, features that could be delivered. Finally, allowing teams to deliver features, instead of relying the thoroughly discredited industrial practice of externally assigned individual tasks, opens the door to creative solutions -- and breakthrough productivity.

Where does quality fit into all of this? Returning again to the agile principle of working software as the primary measure of progress, non-working, buggy, software cannot demonstrate progress and therefore cannot be called "done." Teams and organizations that hold true to this principle have the capacity to do truly amazing things in an industry too often characterized by the poor quality of its products.

This is by no means a comprehensive list, but for me, right now, these are the key features of Scrum.

All for now....

...-.-

WFH Scrum

Working From Home (WFH) is an amazing thing. I have done it for years, off and on, and I really like it. Studies have repeatedly shown that people are more motivated, more focused, and more productive when working from home than when working at the office. Another major benefit is for people who face long daily commutes. Not only do they not have to spend two or more hours of utterly unproductive time driving to and from the office, people working from home also reduce traffic volume and air pollution, both major concerns where I live on the Front Range of the Rocky Mountains of Colorado.

But how does one accommodate WFH within a Scrum team? I have coached a few teams that wrestled with this issue. It is tempting to say "everyone needs to be here, every day." And indeed, that is the only way to ensure the highest-possible bandwidth communication within a team. Given my own affinity for WFH, however, I decided the dogmatic approach would be neither effective nor realistic.

The approach I have adopted consistently -- and successfully -- is to work with the team to make sure everyone understands the importance of the principle of face-to-face communication and then recommend a few WFH ground rules for the team's consideration:

• During the first Sprint or two, everyone needs to be physically present while we learn how to apply the rules of Scrum in practice
• When the team decides it is ready to run a WFH experiment, I suggest the following ground rules:
• Everyone is present for Sprint Planning, Story Time, Sprint Review, and Retrospective, which generally works out to be three days in each two-week Sprint
  
• Use Skype or other video conferencing technology to facilitate the Daily Scrum -- voice-only dial-in may suffice temporarily, but is not adequate over the long-term
• The team needs to adopt a standard, high-bandwidth communication medium/technology, such as Skype with video, that all team members commit to use for daily collaboration
  
• The Daily Scrum rules: if team members decide pairing or other face-to-face contact is needed, the necessary team members must be physically present even if it means driving to the office after the Daily Scrum, although we try to avoid the latter whenever possible
  
• Try to give people as much predictability as possible, but the team's needs trump all else

This is just a basic set of ground rules that I recommend and that teams I've coached have successfully adopted to accommodate WFH. Teams always refine, change, and adapt the initial WFH ground rules, of course, but this list serves as a good starting point.

Let me know if you find these suggestions reasonable, useful -- or not.

All for now....

...-.-

Rehumanize Your Work

I was -- and remain -- a big fan of the popular music that characterized the 1980s. One of my favorite bands was The Police and one of my favorite songs was "Rehumanize Yourself" from their album Ghost in the Machine. That song was never a radio-play hit, but it always hit home with me. Listening to that album the other day on my iPod reminded me why it is exactly that I now spend my working life at what is essentially Agile evangelism.

Many of the key reasons companies decide to adopt Agile are based on hard-nosed financial, business, value, and competitiveness calculations. And that is as it should be. After all, without a competitive business there would be no employment. So yes, the competitive boost companies derive from Agile is a key benefit. But for me, the greatest benefit is the rehumanization of work and of the workplace.

Among the most insidious results of Frederick Winslow Taylor's Scientific Management was the utter and complete de-humanization of work and the workplace. In the software development world, the various pre-packaged methodologies that have come along have all contained the spirit of Taylorism with its cynical, command-and-control approach to the people doing the work.

The real genius of the Toyota Production System, to me, was its inventors' realization that the assembly line was not mechanistic; it was, in fact, a social system that could only work properly if it took into account the human element. The result was the andon cord, which gave all workers on the floor both the responsibility and the authority to control their work.

Henry Ford once said: "Why is it that when I want to hire a pair of hands, a brain comes attached to them?" This is the essence of Taylorism -- and the antipathy of the entire concept of the andon cord. No worker in any of Henry Ford's factories was ever given authority to stop the line.

Software development -- or any other type of product development -- obviously requires hands that are attached to a brain, but traditional methodologies assume that the brain thus involved must be allowed to work only within rigid constraints because the people doing the work obviously have neither the capacity nor the inclination to take responsibility for their work. This, too, is the essence of Taylorism.

The genius of XP and Scrum, which are my main focus within Agile, is the recognition of the human element, of the fact that product development is primarily a social activity. By offering the people doing the work the authority to accomplish that work as they see fit, by giving them the responsibility to ensure that the work is done in the best possible way, and by establishing the social environment in which that authority and responsibility can be expressed to its fullest, Scrum and XP provide the best known framework for rehumanizing the work and workplace.

Along with the values, principles, and practices of XP and Scrum, conscientious, dedicated leadership completes the puzzle. So how about it? What will you do, today, to rehumanize your work?

All for now...

...-.-

It's all about the Raspberry Jam

“The Law of Raspberry Jam: the wider any culture is spread, the thinner it gets.” -- Alvin Toffler

I recently delivered a series of Product Owner training courses for a large (massive, really) multinational corporation. The company has an Agile rollout strategy and a reasonable amount of tactical planning in place for making it happen. During the course of the training, one of the more interesting discussions that arose revolved around how many teams each Product Owner would serve. The Scrum answer is, of course, one and only one Product Owner per Scrum team. There are a variety of reasons for this one-to-one relationship between Product Owner and team, a few of which are:

• The Product Owner is a pig, a committed member of the team who shares in the ups and downs of the team's experience
  
• The Product Owner is the sole voice of the customer, the single source of business information on the team
• The Product Owner continuously prioritizes the Product Backlog, ensuring that the team always pulls the highest-priority work into each Sprint
• The Product Owner makes sure that the team never runs out of high-priority stories to work on
• The Product Owner and team build a relationship of trust and mutual respect based on shared work toward a common goal

The plan at this company was to have each Product Owner serve five teams, which brings us to the Law of Raspberry Jam.

Toffler was talking about cultures, but the same is true of people and roles. Spreading a Product Owner over multiple teams inevitably thins that Product Owner's commitment to each team. The thinning of commitment makes the building of trust and mutual respect much more difficult, perhaps rendering that vital connection impossible.

Then there is the issue of keeping the backlog prioritized, groomed, and ready for each team to pull the highest-priority stories into each Sprint. I worked with a team a few months ago (at a different client) that had outrun its Product Owner's ability to keep the backlog stocked with appropriate stories. As that team's velocity increased, the Product Owner simply could not keep up. Imagine that situation multiplied by five!

The one-Product-Owner-for-five-teams experiment has not gotten off the ground yet, but I am very interested to see how it goes. As I told the trainees, it might work. But then again, there was no data or other evidence to support that supposition out of the gate, whereas for the standard format of one Product Owner per team, there is a huge amount of data that demonstrate success.

All for now...

...-.-

When do we start? When should we finish?

The snow that fell yesterday -- yes snow, yes on May 12 -- along the northern Front Range of Colorado has just about melted and it looks like spring again, even though it doesn't necessarily feel that way when one steps outside. The mountains give the appearance of mid-winter, which is encouraging given the lower-than-average snow pack to date.

In any case, the questions that form the title of this post are among the most frequently asked when I am both training and coaching. The context is Sprint begin-end boundaries and the answers I give are consistent. I encourage organizations and teams to follow the Lean principle of building-in quality, that is, make everything as unlikely to break as possible. When it comes to Sprint boundaries, regardless of the length of the Sprints, the least likely candidates are starting on Mondays and ending on Fridays.

There are several reasons why Monday-Friday Sprint boundaries are suboptimal. In the USA at least, most holidays fall on Mondays, almost certainly assuring disruption of Sprint planning at least a few times every year. And while ending Sprints on Fridays might seem to offer the prospect of a nice break in between Sprints, the all-too-common refrain from the team at the Sprint Review is: "Oh yeah, we're done with everything, but we just have a little testing/coding/cleanup, etc., to finish over the weekend." Uh-oh.



Fortunately, there is an extremely simple method of fixing these (and many other) common problems resulting from Monday-Friday Sprint boundaries: start and finish in the middle of the week. I personally like starting fresh with Sprint Planning on Wednesday mornings and wrapping up with the Sprint Review and Retrospective on Tuesday afternoons. Using this Sprint boundary template immediately remedies the Monday-holiday disruption. Finishing the Sprint on Tuesday afternoon -- with the Retrospective as the last thing the team does, always, without fail -- very neatly eliminates "we're done, but we'll finish over the weekend" syndrome as well. This one element, finishing work, is worthy of another blog post all to itself.

Another benefit of the Wednesday-Tuesday Sprint cycle is that it supports adherence to an oft-violated Agile principle: sustainable pace. As a coach, I am not about to encourage or even allow teams to get into the habit of working weekends between Sprints. The most effective way I have discovered to deal with this problem is simply to make it impossible: there is no weekend or other exploitable time between Sprints.

Closing out each Sprint on Tuesday with the Retrospective provides the team with the full experience of accomplishment and closure, of finishing the work of one Sprint before moving on to the next. Indeed, I invariably find that teams are anxious to get started on the next Sprint and welcome the opportunity to start fresh the very next morning. An added benefit is that holding Sprint celebrations on Tuesdays often results in a smaller tab at the team's favorite restaurant or bar, which often offer discounts to encourage mid-week trade.

Think about it and let me know about your experience with Sprint boundaries.

All for now....

...-.-

Confessions of an Agile Purist

It's sunny down in Texas today and the late, great Stevie Ray Vaughan is cranking from my Mac's tiny speakers. It all seems appropriate somehow, Texas blues and the recent accusation that I am an "Agile Purist." My initial thought was that that label was somehow derogatory, a slap in the face, a put-down. A few sweet licks from SRV's guitar has helped me see the light, however. Now I'm ready to embrace the Agile Purist tag rather than trying to wash it off.

So here's the deal, I train and coach Agile teams and have been extremely successful at both of these related endeavors. My philosophy is a simple one: present the rules of the product development game, primarily Scrum, but drawing also on the best that XP has to offer, with a little Lean thrown in for leavening, so that my trainees both know the rules of the game and have the beginnings of a sense of how to take the field and begin to play. Experienced Agilists know all too well that the framework is very simple and lightweight, but that does not make it easy to put into practice. Indeed, simple most certainly does not equate to easy in this context. So my guiding principle is to make sure that everyone in my training classes emerges knowing what to do when they hit the ground, whether with me there to coach them or not.

When I'm coaching, I follow the same principle. Everyone knows exactly what to do -- or at least what to expect -- every single day that I'm on the ground with a client, whether it's an ordinary day with a daily Scrum, a Sprint planning day, or a Review/Demo and Retrospective day. What happens, specifically, during each day is highly variable and hence where the difficulty lies in putting this simple framework into practice. Starting with that Agile Purist approach, which in reality means making sure that everyone knows what to do/expect coming into each day on the job, has served my clients very, very well indeed.

What this means is that I train and coach client teams to play by the rules so that they have confidence in what they are doing and in their individual and collective ability to do it from day one. I want them to learn good habits so that when the unexpected happens -- or when the entirely predictable challenges arise -- they are in the best possible position to make adjustments and continue moving forward with their Agile practice.

Aside from the purely practical, experiential basis for following the rules of the game, there is this one other thing that informs my work as a trainer and coach: I actually believe in the value of the core Agile principles captured in the Agile Manifesto. I believe that putting those principles into practice -- playing by the rules -- has a proven record of success, not just in getting the right product to market, at the right time, and for the right price, but that those principles translated into practices create a healthy, productive, and adaptive work environment that none of the prepackaged methodologies can ever hope to touch.

My devotion to Agile principles and practices, those rules of the game, is therefore not based on a pedantic need to follow some arbitrary formula. Once a team I am coaching learns how to play at a basic level, which typically happens very quickly, I help them learn how to adapt their practices as needed, all the while keeping the principles in the forefront of everyone's mind. We're just not going to start there, on the highly adaptive end of the time line.

So yes, I admit it: I am an Agile Purist.

All for now....

...-.-

Is it a Group or a Team?

This question often occurs to me when I'm on training or coaching assignments. The provocation is usually a statement similar to the following: "We have a development team of 250 highly skilled engineers...." or "Our QA team just can't seem to keep up with development...." or "The business analysis team writes all of our requirements...." or "Our middleware team serves multiple simultaneous projects."

It is common usage to apply the term "team" to mean any collection of individuals who perform some related function, regardless of how those individuals actually work. To me, a team is a very specific type of human organizational unit, defined by how it works, rather than by what it works on. Simply put, teams are distinguished by teamwork. I have even, very occasionally, encountered fair approximations of cross-functional Scrum "teams" that fail to meet this most basic definition.

Teamwork describes a particular way of working toward a shared goal. I have distilled the essential characteristics of teamwork into the following (incomplete) list:

• sublimation of individual ego and need for recognition to the needs of the team
  
• sharing and balancing workload dynamically at daily or finer granularity
  
• individuals offering and requesting help in an environment of trust
• willingness to make personal sacrifices in support of the team
• recognition that the team's goal outweighs (but does not exclude) individual goals
  

I'm certain there are many more traits that one could apply to describe teamwork, but this works for me as a starting point for the discussion. The key distinction I see between a team and a group is the collaborative effort a team engages in to meet its collective goal, for example, a Sprint commitment. A group, on the other hand, may indeed consist of skilled, well-intentioned individuals, but without a collaborative framework and a collective goal, teamwork is absent. The common example is the group of developers, each individually working on their assigned tasks, head down, blinders on, either unable or unwilling to share the load with their fellow group members. Sure, they're all working toward the same end point, but on parallel tracks that by their very nature cannot converge. Group work results in the standard array of dysfunctions and failures that characterize traditional software projects.

Implied in my list of teamwork traits is a self-organizing, empowered team that has the authority to set its own commitments and determine how best to meet those commitments. Another implication is that a team is small. The standard Scrum guideline for team size (seven plus/minus two) has always worked brilliantly in my coaching experience.

So the next time you hear a client or colleague talking about a "team," make sure you know what they really mean: Is it a Team or a Group?

All for now....

...-.-

The Law of Unintended Consequences

This is big topic, but today I want to talk about just one small aspect: the unintended consequence of command-and-control work environments. There is a persistent myth in the software business that runs something like this: if we plan every detail of our product, assign the details to individuals, monitor and track each individual's progress on each task, make sure the load is balanced across individuals and always at the maximum (or just a little more) that each individual can deliver, and if we put in place sufficient incentives and penalties to make sure that individuals follow the plan exactly, the end result will be a perfectly executed project.

Aside from the obvious difficulties of planning a future over which we mere mortals have neither control nor even foreknowledge, there is a massive gotcha lurking in the shadows of this defined, command-and-control approach that is the result of the Law of Unintended Consequences: malicious obedience.

Malicious obedience is a common behavioral response to situations in which individuals know that they have no control over what they work on, how they work, or the outcome they produce. When the incentive/penalty structure emphasizes obedience over all else, people learn very quickly to do precisely what they are told and nothing more, even if they know perfectly well that what they are doing is not the best way to achieve the end goal, which in the software industry is a working, valuable product. A common example, and one that I have experienced on more than one occasion, is when developers write code exactly as specified even when they know that what they're coding is incompatible with some other part of the system, either because of an initial design failure or a requirements change that did not propagate to their part of the system in time. Since command-and-control values obedience over all else, the developers in question had no choice but to follow the plan, write the code as specified, generate waste, and damage the overall project. "We were just following orders, sir."

Since a successful project is (or should be) the actual goal, the cure is to apply Agile principles and practices throughout. When people choose their own daily tasks, freely commit as members of a team to deliver a Sprint backlog, and have control over how they implement a solution, malicious obedience is no longer an issue. To put it another way, removing the compulsion to follow arbitrary orders from the equation eliminates the possibility of malicious obedience. When people are empowered to take ownership of their work, the Law of Unintended Consequences breaks down, resulting in innovative solutions, sterling quality, and timely feature delivery.

All for now....

...-.-

The Ghost of Frederick Winslow Taylor, Part 4

Last time we saw the Utopian glimmer Taylor thought his vision of scientific management offered. Let's wrap that up and get to the Agile connection this time.

In his cold, raspy, ethereal voice, Taylor's ghost asserts that scientific management gives both workers and management what both groups most want, viz., high wages and low per-piece labor costs (cf. p 93). He goes on to say that workers "should" be encouraged and allowed to propose new and better methods of working, which after adequate study and experimentation, management may choose to adopt as the new standard for a given task. The individual worker who proposed the new method "should" receive full credit for the innovation and be paid a cash bonus as a reward (cf. p. 128). Taylor is unable to provide an answer to the question of just how exactly any worker, bound up by the rigid work rules and defined pace scientific management imposes, could ever have the opportunity even to think of a better way of performing a work task. Even worse, management is under no obligation to allow workers to experiment with alternative ways of working.

Taylor wraps up his case with yet another Utopian flourish. First, he states that the new division of duties between labor and management along with "intimate, friendly cooperation" ensures labor peace (cf. p. 140). And finally, scientific management, by dramatically increasing wages ends the wage problem. Even more, the close, constant, and intimate cooperation (there's that formula yet again) between management and labor produces a commonality of interest that makes labor strife impossible. The broader benefits that result are reduction in poverty (through high wages), cheaper products, and better competitiveness even during economic downturns, resulting in minimal economic dislocation (cf. pp. 143-44).

Those are bold statements, but they are -- and always were -- as ethereal as the ghost who continues to assert their validity. First off, Taylor never had any evidence to support his Utopian vision of labor-management cooperation and perpetual peace. Labor strife did not end as scientific management spread. Indeed, scientific management simply escalated the labor-management war by giving management a potent weapon to use against labor. Secondly, he simply ignored the greed and lust for power that characterize the owners and managers of capitalist enterprises. Scientific management came into widespread use and indeed is still at least implicit in the vast majority of businesses of all types.

Taylor provided the theoretical basis for management to remove every shred of the workers' control over the work they were doing. He took away their tools, their knowledge and expertise, and their genius for self-organization and replaced them with rigid command-and-control structures that governed every aspect of work. His predictions of huge increases in productivity, the one aspect of scientific management for which he had good data, were indeed realized. High wages did not follow, however. Industrial management realized that they could realize vastly higher profits by reducing their workforces by the 80-90% Taylor forecast. As scientific management spread rapidly throughout the US economy, high unemployment became the norm, making it very easy for management to use scientific management to squeeze high productivity from workers while offering only the threat of replacement as an incentive to stay in their increasingly oppressive jobs. Henry Ford's famous doubling of his workers' wages in 1914 was short-lived: a stockholder rebellion and resulting lawsuit forced wages back down.

So where's the long-awaited Agile connection, you might ask (I'm sure you are)? Easy. Taylor was wrong. Scientific management, with its heavy handed, command-and-control work methods, stifled innovation by making it impossible for the people actually doing the work to contribute to the development of new and better products. Agile frees this most important source of innovative thinking from the bonds of rigid work rules and suffocating management oversight. Companies haunted by the ghost of Frederick Winslow Taylor stagnate and are unable to adapt to the rapidly changing economic conditions that are now the rule rather than the exception.

Chase Taylor's ghost from your building -- and from your mind. Take advantage of the power of self-organization. Win in the market by being adaptable, by drawing upon the power of innovation that comes with building teams of motivated individuals and trusting them to get the job done. It's long past time for Taylor's ghost and his century old prescriptions to be laid to rest.

All for now....

...-.-

References
Taylor, Frederick Winslow, The Principles of Scientific Management. New York & London: Harper, 1911, reprint edition, 1934.

The Ghost of Frederick Winslow Taylor, Part 3

Last time, the ghost of F.W. Taylor told us about management-labor cooperation and gave us a hint of his Utopian vision. Today, he's still going on about cooperation and how it is to be achieved. Let's listen in....

Since scientific management requires companies to define each task to the finest detail, there must be a massive expansion of management activity going on as well. And indeed, that is the case. According to Taylor, scientific management requires the establishment of a large and elaborate management structure to plan the work of each worker at least a day in advance, record each worker’s output, train each worker as needed for each task, keep and issue necessary tools each day, etc (cf. p. 70). Whereas previously, workers had provided their own tools, expertise, and initiative, now all three of those categories would fall strictly under the control of the new, massively expanded management.

Achieving maximum output requires cooperation, but no individual worker has the authority to require peers to cooperate in that effort. Only management has that power. Therefore,

“It is only through enforced standardization of methods, enforced adoption of the best implements and working conditions, and enforced cooperation that this faster work can be assured. And the duty of enforcing the adoption of standards and of enforcing this cooperation rests with the management alone.” (cf. p. 83. Original emphasis)

Management must train all workers and dismiss those who are unable to meet the required work pace after training. Management must also recognize that workers will not submit to rigid task standardization and faster pace of work unless they receive a substantial increase in pay in return. And finally, all four components of scientific management must be applied in order to realize the promised results (see the previous post in this series).

This is beginning to sound less and less Utopian, despite Taylor's repeated and plaintive calls for dramatic wage increases after the adoption of scientific management.

Next time we'll drive a stake through the heart of Taylor's Utopian daydream and examine the consequences of his ideas.

All for now....

...-.-

References
Taylor, Frederick Winslow, The Principles of Scientific Management. New York & London: Harper, 1911, reprint edition, 1934.

The Ghost of Frederick Winslow Taylor, Part 2

In our last installment, we heard Taylor state that cooperation between management and workers was the essence of scientific management. Now it's time to query him about what scientific management actually is. So here we go....

The new role of management under scientific management is to provide task-level standardization of methods to achieve maximum efficiency from each worker. In return for vastly increased productivity, workers must receive 30-100% increase in wages or else they will simply not agree to work in a new way. With management taking on half the burden of the work, in the form of task-level planning, and the increase in pay, labor-management relations will be automatically close and cordial (cf. p. 27).

Taylor's thesis was that only through scientific management could both employer and worker fulfill their needs and ambitions and that once those criteria were met, there would no longer be any cause for labor unrest. The backdrop to Taylor's work was the intense, violent, and often bloody warfare then taking place between owners and workers, both in the US and in Europe. There was also the ideological struggle being waged between industrial capitalism, socialism/communism, and anarchism. Taylor attempted to demonstrate that by cooperating in a spirit of shared sacrifice, labor and management could work together for the benefit of everyone. We'll assess the success of his prescriptions in that area later as well. Suffice it to say that following a visit by Taylor to a workplace, 80%-90% of the original workforce joined the ranks of the unemployed. But back to our Taylor haunting....

Taylor urged management to take on the responsibility of collecting all of the tacit knowledge of every trade practiced in their enterprise and “classifying, tabulating, and reducing this knowledge to rules, laws, and formulae which are immensely helpful to the workmen in doing their daily work.” Management would also take on four essential tasks that form the heart of scientific management:

1. Develop the science for each element of the work every worker performs, using time and motion studies, etc.
   
2. Scientifically select, train, teach, and develop each worker to the highest level. Previously workers chose their own work and carried out their own training by whatever means they could arrange.
3. Management must “heartily cooperate with the men so as to insure all of the work [is] being done in accordance with the principles of the science which has been developed.” This means training at the task level.
4. Almost equal division of work and responsibility between management and labor, with management taking on the science and task-level direction of each worker (cf. pp. 36-37).

Taylor acknowledges that scientific management inevitably results in a further division of labor as tasks are separated and subdivided (cf. p. 38).

So where are we at? So far we have vastly improved productivity, a recommendation for much higher wages, labor-management cooperation, task-level direction, and extreme and increasing division of labor. That is at best a mixed ledger. Next time, we'll look at Taylor's ideas on cooperation and how it is to be achieved. We'll also begin to form a picture of what scientific management meant to the people doing the work. And don't worry -- we'll get to the Agile connection very soon.

All for now....

...-.-

References
Taylor, Frederick Winslow, The Principles of Scientific Management. New York & London: Harper, 1911, reprint edition, 1934.

The Ghost of Frederick Winslow Taylor, Part 1

So who was Frederick Winslow Taylor and why is he haunting my blog? Taylor, 1856-1915, was an American mechanical engineer and among the first practitioners of the management consulting profession. So much for the "who" part of the opening question. The haunting part is more complex. Taylor not only haunts my blog, he has haunted my entire working life and certainly the the working lives of countless millions around the world.

How could one dead white guy have that much influence, you might ask? The answer lies in a paper Taylor presented to the American Society of Mechanical Engineers (ASME) in 1911 and later published as a short book. Both presentation and book bore the title: The Principles of Scientific Management.

Taylor's purpose was to explore President Theodore Roosevelt's call to increase national efficiency and was a part of the larger efficiency craze sweeping the United States in the early twentieth century. William Howard Taft was president of the US in 1911, when Taylor presented his findings and prescription for industrial efficiency, but no matter.

Taylor set out to use the scientific method (or just "science!" as Thomas Dolby sang back in the 1980's) to secure maximum prosperity for both employer and employees by developing each employee to a state of maximum efficiency in the highest grade of work for which each employee was suited. Taylor was speaking of manual labor, both skilled and unskilled, of course, since there was no such thing as a "knowledge worker" in that day and age.

Taylor's observations of working people led him to the conclusion that any "work gang" left to its own devices would work only at the level of its least efficient member. In those days, the term for slowing work to that level was "soldiering." Taylor understood that the workers engaged in soldiering to protect their own interests against what he called "defective management practices." Workers believed, and as it turned out rightfully so, that broad increases in productivity would lead to mass unemployment, then as now, the scourge of the American economy. More on that in a later installment.

Taylor identified the key elements of labor inefficiency:

1. Workers use rule-of-thumb practices handed down through observation of their peers. There were no standardized practices even within the same trade within the same company. Management does not know how the work is done and therefore leaves the heavy responsibility for figuring out how to do the work up to the workers themselves.
2. The worker best suited for a particular job is incapable of understanding the scientific laws governing the most efficient way to complete the work. Taylor stated that it was the duty of management to take on half the workload by deriving those very scientific laws and then providing the resulting information and training to the workers.

I'll leave you with the following quote: "This close, intimate, personal cooperation between the management and the men is of the essence of modern scientific management." (p. 26)

More on Taylor's ideas next time.

All for now....

..-.-

References
Taylor, Frederick Winslow, The Principles of Scientific Management. New York & London: Harper, 1911, reprint edition, 1934.

Pragmatism

Pragmatism is a word I hear quite often in my coaching life. Webster's defines pragmatism as "a practical approach to problems and affairs." To me, that is also the definition of Agile. Every minute of training or coaching I deliver is devoted to building a practical approach to whatever problems the client is facing. With its focus on flexible planning based on realistic time horizons, short-term commitments, frequent deliveries and adjustments, Agile is the acme of pragmatism.

Where I find the term pragmatism problematic is when clients or colleagues use it as an excuse to paper over or otherwise avoid addressing issues that Agile principles and practices expose. Overcoming impediments is a part of the Agile game and the only path to continuous improvement, so declaring that some set of organizational or corporate-cultural impediments cannot be overcome is simple capitulation, not pragmatism.

That is not to say, of course, that it is possible or even desirable to change everything about an organization overnight. Successful Agile coaches -- and successful Agile clients -- are committed to playing by the rules of the game, even if getting there is a process of incremental change rather than a single, sweeping event.

The vital thing to keep in mind is that Agile, whether XP, Scrum, Lean, etc., or some combination, is a framework, something like a scaffold, in which every key aspect depends on other key aspects. What this means in practice is that for companies to be successful with Agile, they -- and their Agile coaches -- cannot pick and choose amongst the principles and key practices, deciding to implement some and ignoring those that are difficult or otherwise inconvenient. As Takeuchi and Nonaka* put it so succinctly 25 years ago when they wrote about a new way of developing products: "These characteristics are like pieces of a jigsaw puzzle. Each element, by itself, does not bring about speed and flexibility. But taken as a whole, the characteristics can produce a powerful new set of dynamics that will make a difference."

Agile today is no different than the "new new product development game" Takeuchi and Nonaka described in their ground-breaking article. Pragmatism does not mean dropping the troublesome pieces of the puzzle on the floor; it means finding practical ways to implement the key practices and all Agile principles in a given context. And that is "a practical approach to problems and affairs."

All for now....

...-.-

*Hirotaka Takeuchi and Ikujiro Nonaka. "The New New Product Development Game." Harvard Business Review, January 1986, p. 138.

The Meaning of Commitment

A common dysfunction I encounter when coaching Agile teams is a failure to understand the meaning of commitment. Scrum teams commit to delivering the Sprint backlog -- complete, tested, and ready to be shown to stakeholders by the end of the Sprint. That commitment means that the team members agree, freely and entirely of their own volition, to do their level best to meet their collective Sprint commitment. Does it always work out exactly as planned? No, of course not. But over the course of repeated Sprints, teams learn what that commitment looks and feels like and they get better at delivering on their commitments.

The lament I frequently hear is: "This team always misses its commitments." Oddly enough, I almost never hear that from members of the team in question. The source of the complaint is almost always from a stakeholder, functional manager, or executive at some level.

In the rare instance of a team whose members acknowledge that they routinely fail to meet their commitments, I work with the ScrumMaster, Product Owner, and team to ensure that they have good stories, solid acceptance criteria, follow the Agile rules for estimating, and that they understand the importance of building trust by doing what you say you are going to do. A team-based commitment failure is usually not difficult to overcome, although sometimes there can be a painful drop-off in perceived productivity as the team learns how to make a realistic commitment and deliver on it.

The much more common case of a stakeholder, functional manager, or executive expressing exasperation with routine commitment failure is usually easier to diagnose, but often more difficult to cure. The essential problem is a failure to understand that the team itself must commit to the Sprint backlog, freely and with complete consensus among team members. Any hint of a commitment that is forced from outside or arrived at without team consensus is automatically invalidated.

Think for a moment about the nature of commitment. We make commitments at many points in our lives. Marriage is a commitment. Having children and being a good parent is a commitment. While a Sprint backlog is trivial in comparison, the nature of the commitment required is exactly the same. Commitment must be voluntary. Commitments cannot be taken lightly. Commitment is a personal decision, sometimes taken in a collective context, as with a Sprint commitment when a team arrives at consensus.

One recent example of habitual commitment failure demonstrates very clearly a fundamental misunderstanding of the nature of commitment and the inevitable result. On a coaching engagement, I heard from an executive that several teams never met their Sprint commitments. He was intensely frustrated with the situation. A little probing of the situation revealed the exact nature of the problem: When asked where the Sprint commitment for the teams in question came from, his response was, "I tell them what they'll commit to each Sprint." It turns out that he had laid out the teams' Sprint commitments months in advance. I explained that a Sprint commitment forced on a team from outside placed the team under no obligation whatever and that such a policy had completely undermined the company's entire Agile practice. When the members of the teams confirmed my assessment of the situation, the executive backed off and started allowing each team to make and deliver its own Sprint commitments. The problem of Sprint commitments not delivered vanished instantly.

A related problem at the same client proved to be the result of the ScrumMaster assigning all tasks at Sprint planning. The team did have control over its Sprint backlog commitment, but pre-assigning tasks left the team fragmented, demoralized, and unable to make the daily adjustments necessary to meet their commitment. When the ScrumMaster agreed to allow team members to self-assign tasks on a daily basis and to self-organize, using the daily Scrum, to ensure that they did everything possible to meet their Sprint commitment, the result was amazing. The team became cohesive, lively, and productive. They began meeting their Sprint commitments and experienced a remarkable increase in velocity after a few Sprints.

Commitment is not just a buzz-word. It is a vital component of Agile and a key ingredient in every team's success. So do the right thing, empower your teams to commit and reap the benefits.

All for now....

...-.-

Some Musings on Recognition

Watching the Golden Globe awards the other night, a couple of things struck me. The first was that people who do excellent work were being recognized for it. The reason that struck me is that, in my personal and consulting experience during the last decade, I have seen essentially nothing resembling a corporate award program for excellence in the workplace in the United States. I'm sure there are companies that still engage in this now seemingly quaint activity, but such things are not the norm anymore.

So what's up with that? Are we so deeply buried in the "just be happy you have a job" mentality that we have no time or interest to promote and reward excellence in the workplace? Perhaps this is a symptom of the pervasive job dissatisfaction plaguing the US. Currently 55% of Americans are dissatisfied with their jobs. I'm not sure where the answer lies. What I do know is that we cannot afford to have a largely disaffected workforce if we in the US intend to avoid a sharp and disastrous economic decline.

The other thing that struck me about the awards show was that, as each winner spoke about the privilege of receiving the award, thanking parents, spouses, children, directors, actors, the Hollywood Foreign Press Association, etc., they all kept coming back to the statement that their project was a collaborative endeavor involving a team of dedicated professionals. Martin Scorsese hit on this point repeatedly in his speech.

So what does any of this have to do with coaching Agile teams? The first thought I have is that there is nothing inimical to teamwork in recognizing individual contributions to the success of the team. We don't want to encourage the development of a hero mentality within a team or destructive internal competition, but it is entirely appropriate to recognize individual excellence in a team setting.

How do we recognize excellence in a way that promotes teamwork? One excellent way is to include appreciations in every team retrospective. Not only do appreciations help build a team mentality, they also provide an incredibly appropriate setting in which to recognize individual excellence in a team setting.

All for now....

...-.-

Scrum != !Scrum

This formulation, which should really be an Assert() statement, struck me the other day as I was reading about some of the fallout from the recent changes in the board of directors of the Scrum Alliance. I have read about some of Ken Schwaber's famous (infamous?) conflicts with various members of the Scrum Alliance community. I also have colleagues who have faced the ire of Mr. Schwaber for promoting ideas that Ken found inimical to Scrum.

In a very major sense, I admire Ken for defending Scrum. Indeed, I find his tenacity refreshing, inspiring even. There are so many people who would dilute Scrum for whatever reason. As with some clients I have worked with, some people want to change or even drop key elements of Scrum because they would rather paper over dysfunctions Scrum has exposed instead of fixing the root cause of the problem. Ken's devotion to Scrum has helped me repeatedly in sticking to my guns and insisting that teams I am coaching follow Scrum practices rather than taking the path of least resistance.

Other people believe, not necessarily incorrectly, that they have discovered an optimization to one or more Scrum practices and then want to share their discovery with the rest of the Scrum community. I see no issues with sharing the idea or experience. That in and of itself, however, does not mean that Scrum has been extended, improved, or changed. The Scrum community must validate changes to the basic practices and adopt them as part of Scrum. There should not, in my view, be any restriction on the sharing of experiences and ideas about Scrum.

This brings us to what I see as two problem areas. The first is that the Scrum Alliance is perfectly justified in cautioning Certified Scrum Trainers against teaching practices in CSM or CSPO courses that are not part of the recognized and agreed-upon components of Scrum. Put more simply, no one should be passing off anything that is not Scrum as Scrum in certified training courses. Additional practices, extensions, or differing interpretations of Scrum and its practices should not be suppressed, simply not labeled as certified Scrum.

The second problem arises from extending the first problem beyond the bounds of certified Scrum. Colleagues of mine have been cautioned very strongly against presenting, teaching, or writing about extensions, modifications, or variations on standard Scrum practices, even when those non-standard items are never advertised as parts of certified Scrum. To me, this goes beyond defense of Scrum and into the realm of censorship. New ideas need to be given free hearing and either added to the body of knowledge and practices of certified Scrum or not. That decision rests with the Scrum community, however, and not with any specific individual.

So, to recapitulate, certified Scrum is what the Scrum Alliance says it is and should be taught as such. Other ideas should be given a free and open hearing and freely discussed, but should not be passed off as a part of certified Scrum. At least that's my interpretation.

All for now.

...-.-

Insurgent Scrum

Just watching Everton take Manchester City apart. Nice to see the Toffees in full recovery from their awful start to the Premier League season. The snow is also finally beginning to melt off after over a month of cold weather and continuous snow cover. North-central Colorado isn't Minnesota after all and we're not used to snow cover for weeks on end.

Thinking about the ways in which Scrum can get started in an organization, one possibility is an insurgent movement on the ground. I have experienced Insurgent Scrum on a couple of occasions. The driving force is usually the total desperation of a development group in the face of an organization in chaos that is unwilling to change its ways. In my experience, the development manager and some or all of his charges decide that they are going to work as a team, deliver working increments of software, and use as much of Scrum as they possibly can. As a team, they convert requirements into user stories, prioritize the stories with or without direct input from the business/PMO, plan their Sprints, commit to the plan, and get on with it day-by-day. On one occasion, the development manager was able to bring the QA manager on board as well, resulting in good automated testing practices being put into place and the formation of something very closely resembling a cross-functional team.

The development of a team dynamic and the sense -- and reality -- of accomplishment that came from delivering working product increments every two weeks brought about great improvements in product quality, staff morale, and productivity. Everyone involved wanted nothing to do with going back to the old command-and-control, isolated individual style of work. The QA staff realized the biggest improvement in their working lives, the result of the emphasis on automated testing and the distribution of testing throughout the course of each Sprint, instead of the usual over-the-wall at the last minute testing push.

That was the end of the positive results, unfortunately. The business and PMO, once they figured out what was going on, applied massive pressure to return things to the way they had been before the Insurgent Scrum movement started. In both of my experiences, it turned out that vastly improved quality, increased productivity, and empirically derived planning were not sufficient to overcome the perceived loss of control. Allowing developers to chose their own daily work, and even worse, to determine their own Sprint commitments, constituted a threatening degree of freedom. The universal expectation in the business and the PMO was that they would give the orders, down to the level of specific design solutions and that development and QA were there simply to type in the code and test the results. Wow. Ultimately, control was more important than the success of the product and indeed the success of the company. Double wow.

In neither case that I experienced personally was Insurgent Scrum successful. It did lift product quality, improve planning, and, most importantly, improve the daily working lives of the people doing the work. In one instance, the front-line managers dug in their heels and refused to stop using Scrum. The only way the business could find to squash the insurgency was to lay off the entire development and QA staffs, including the managers. Triple wow. Strangely enough, I have seen similar outcomes, minus the layoffs, when coaching organizations that brought me in specifically to help them in their move to Agile/Scrum.

So what's the lesson here? Well, first of all, I am convinced that Insurgent Scrum is worth the risk. Improving the working lives of the people on the ground is worthwhile regardless of the ultimate outcome. There is also always the very distinct possibility that an organization will see the benefits of Scrum and adopt it on a grander scale, using the original insurgency as the example of success and the source of practical knowledge which could then be spread throughout the organization. Companies that are focused on winning, instead of on control and corporate politics, will clearly follow the model that leads to successful adoption of Scrum.

Is your organization focused on success? How will you know? It may be impossible to tell until you start, which is where courage comes into play. Be courageous, but always remember that discretion is truly the better part of valor. Get going with Scrum, but avoid open provocation. Demonstrate the benefits of Scrum: delivery of working product increments, fully tested, ready for release, and with much greater predictability than is possible under traditional defined process management; vastly improved staff morale and therefore productivity; innovation as a matter of course; and on and on. Build trust Sprint-by-Sprint. If your company is unable to recognize the benefits of Scrum, it's an unmistakable sign of where the organization's priorities lie.

All for now....

...-.-

Organic Scrum

Whenever I step into a coaching engagement, one of the first pieces of information I track down is where the initiative for the move to Scrum originated. The answer is invariably one of three: a top-down initiative; a move from the middle outward; or an organic, bottom-up approach. The first two types present challenges of their own, of course, but the third, what I have taken to calling Organic Scrum, presents many special circumstances and difficulties not generally found in the first two.

The usual path into an Organic Scrum setting is that a functional manager or technical lead either learns about Scrum or has been in a Scrum/Agile environment previously. The leverage is usually a troublesome project that is either in progress or on tap. The troublesome part of the proposed pilot project is that it is either stuck or has already failed at least once using traditional project management practices and needs to be restarted afresh. Either of these situations produces the right mix of management desperation and therefore openness to new ideas to make an Organic Scrum push possible. And despite the deck being stacked so unfavorably, troubled projects are often ideal candidates for Scrum.

Under the best of circumstances, the person championing the move to Scrum is able to coax management at a higher level to devote some resources to training and coaching, which is, of course, where I usually enter the scene. Under less favorable circumstances, the entire Scrum transition ends up without management support or resources and takes on the character of an insurgent movement. I'll try to cover insurgent Scrum in a later posting. Now, back to Organic Scrum....

The greatest challenges in an Organic Scrum environment, both for me as coach and for the people who want to get Scrum moving, are setting up a truly cross-functional, self-organizing, self-managing team and getting some level of cooperation from the business so that the team can work from a prioritized backlog. Let's examine each issue separately.

Most US companies are organized along functional lines, creating the very skill silos W. Edwards Deming decried over 60 years ago. Unless the silo walls can at least be bent or stretched, the nascent Scrum team will not be able to deliver a working product increment each Sprint. The major silo division is almost always between development and QA, although there can be others, equally insidious, that divide development into specialized segments that maintain a mutual over-the-wall mentality. Architecture and design also commonly form another silo. Punching holes in these functional silos is the first priority in an Organic Scrum movement. Breaking the shared-resource organizational model -- the "matrixed" organization -- is a common follow-on activity. The members of the Scrum team must be allowed to focus on the project Scrum is supposed to deliver. Failure in either of these areas generally proves to be a hard stop in the development of Organic Scrum.

Assuming the silo walls can be made permeable enough to allow the formation of a cross-functional product team and that the company allows the team members to exit the matrix, the next big step is to find a courageous ScrumMaster to support self-organization/self-management and protect the team from the inevitable distractions. The new cross-functional team members almost always report to different functional managers, yet as members of a self-organizing, self-managing Scrum team, that reporting relationship must change. It is often the ScrumMaster's unpleasant duty to inform various functional managers -- and sometimes higher-level managers as well -- that no one gives orders here anymore. The team commits to work and delivers on its commitments however the team members collectively see fit to do so.

A common area of team distraction is outside interference with the team's Sprint work in the form of requests to do something unrelated to the Sprint. It is not unusual for this form of interference to come from the very same functional managers who garner the ScrumMaster's attention for other reasons. It's really not the functional managers fault -- they have other projects that need to get done so they call on their direct reports, assigning work as they always have. The problem is that distractions are a common source of a team's failure to deliver on Sprint commitments. Delivering on Sprint commitments is the Scrum team's only way to build trust with the organization and with the business. Finding the right person to take on the ScrumMaster role is so vital that failure in this area also constitutes a hard stop.

The final major ingredient needed to grow Organic Scrum is cooperation of the business. When I coach in Organic Scrum situations, I invariably spend a huge amount of time and energy working with the business to help build an understanding of what the Scrum team is trying to do, why they're doing it, what the benefits are for the business, and how the business plays a vital role in making it all possible. In most cases the benefit side of the equation is an easy sell: the business gets a fully tested, working product increment at the end of each Sprint. The required input from the business can be more difficult to sell, however. It can be difficult for people schooled in traditional project management to let go of the detailed requirements document, delivered to development before a line of code gets written. It can also be difficult for traditional project managers to give up the perception of control that comes from telling people what to do and how to do it. If we can overcome those hurdles, the business must then at least agree to provide a Product Owner for the team or work with a Product Owner the team designates. The business must also agree to prioritize a backlog from which the team can work, to define acceptance criteria (the all-important definition of "done") for each user story, and to review the output of each Sprint.

The business can certainly be skeptical of the idea of Scrum, but must play by the rules, even if grudgingly, in order for Organic Scrum to have a chance to succeed. When I coach, I emphasize the inherent trust-building that takes place when a team commits to a Sprint backlog and then delivers on that commitment, Sprint-after-Sprint. As long as the business is more interested in results than in control, trust is the Scrum team's most powerful incentive to continue and indeed expand Scrum within the organization.

All for now....

...-.-