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.