Good teams are like good code: Highly Cohesive, Loosely Coupled

The best Scrum teams I've worked with have been reflections of the code they produced: highly cohesive -- meaning focused on a project or product -- and loosely coupled -- having minimal direct dependencies on other teams. Like excellent code, excellent Scrum teams don't just happen; it takes careful planning and continuous attention to detail.

Let's start with high cohesion. The highest performing Scrum teams are initially built around a purpose, a specific project or product, and allowed to focus exclusively on that project or product. But after that the team's design is emergent, adapting to changing circumstances and increased knowledge about teamwork, the domain, and the product. Like a well-designed class, the team is directed at its purpose and resists attempts to redirect it. Once the current project or product is complete, the team can take on a new project or product, just like a cohesive class can be instantiated repeatedly. The key is that, like a cohesive class, the team is focused.

Great Scrum teams are also loosely coupled to other teams. What this means is that a great team has very few dependencies on other teams, that is, the team can complete its work without waiting on outside experts or the work of other teams. I can already hear the objections: "Okay, so a great team contains all of the skills and knowledge needed to complete its own work, fine. How can you keep even the best team from waiting on other teams to complete their work?" Okay everyone, turn your eyes to the Product Owners in the room.

A great team must have a great Product Owner. The best Product Owners ensure that their team's backlog is independent of the backlogs of other teams. Even more, a great team of Product Owners can decouple the backlogs of all teams to the maximum extent possible, ensuring that all of their teams, like all of the objects in a well-designed application, only access each other through well-defined interfaces that minimize dependencies.

The next time you survey your organization's Scrum teams, think like a software architect and work on making your teams highly cohesive and loosely coupled!

All for now....

...-.-

Don't be like Homer Simpson

"In times of trouble, go with what you know."
--Homer Simpson

Words of wisdom from a notoriously brainless cartoon character seem like an oxymoron -- and in fact that is the case. Unfortunately, Homer's prescription is something I experience over and over again with client organizations. In the midst of a difficult and challenging change, like moving the organization from a sequential development process to Scrum, there is strong temptation to fall back on old habits of mind. Whenever things get uncomfortable, whenever Scrum makes a long-standing problem unbearable, the knee-jerk reaction is to ditch the part of Scrum that "caused" the problem and revert to a previously learned behavior.

One example I have experienced repeatedly is the problems caused by a widely distributed Scrum team, that is, one with some team members in North America while others are in China or India. I recently ran across an issue in which the more experienced North American team members were attempting to work with freshly minted graduates in China who lacked even the slightest shred of domain knowledge. Since the time shift in this case was exactly 12 hours, it was impossible for the team members to work together closely. Not only were there twice-daily hand offs of code between team members in the different geographies, there was also the issue of the Chinese team members lack of experience in the domain.

The response from the domain-expert team members in North America was to clamp down process on their young Chinese peers. Over time, many gates had been constructed to prevent the Chinese team members from doing any damage to the code base. By the time I arrived on the scene, the gates were so restrictive that the Chinese side of the team -- and make no mistake, each geography had taken sides -- was unable to do any work at all. Even the simplest tasks were impossible to complete without involving the North American side because of the gating requirements.

A better solution, which the organization actually implemented, was to create separate North American and Chinese teams. While this by itself did not solve the bigger issue of domain knowledge being restricted to the North American team, it did allow both teams to work with a degree of independence and to finish the work they committed to each Sprint. The one major adjustment was to have the Chinese team work in one-week Sprints while the North American team worked in two-week Sprints. Shorter Sprints forced the Chinese team to break its work down into very small bites that the North American domain experts could then help with during the short window of overlapping availability each day. By limiting the range of variability -- implementing one-week Sprints -- the organization was able to move forward with new feature development much more quickly than had been the case with a distributed team and a multiplicity of gates for the Chinese team members' work to pass through. The organization also unknowingly implemented one of W. Edwards Deming's credos, that of changing the system to reduce variability. More on that topic in a later post....

All for now....

...-.-

Got a Morale Problem? Get Quality!

The connection between product quality and morale isn't a big mystery, but it seems to be one that is frequently overlooked. W. Edwards Deming and, somewhat later, Frederick Herzberg famously linked the sense of accomplishment people experience when doing good work on projects over which they are able to control how the work is done with high morale. Scrum's emphasis on delivering a working product increment at the end of each Sprint fits into the morale equation perfectly.

So what's the problem?

We don't always do as we should. When teams are pushed to take on more work than they can competently deliver, quality is the inevitable casualty. Teams that find more and more of their capacity sucked away by bug-fixing rapidly experience significant, sometimes catastrophic, declines in morale. With morale goes innovation, productivity, and continuity as people seek to flee the bug storm.

An even worse situation occurred in one company's misguided attempt to focus on its defect backlog while at the same time delivering new features at their accustomed pace. The solution they settled on was to create a bug-fixing "team" -- actually a large work group -- that would, in essence, clean up the messes left by the over-worked feature group. Freed from the responsibility for the quality of their work, the feature group delivered a large number of features. Unfortunately, the feature group's freedom from responsibility produced a product strangled by defects which the poor souls on the bug-fixing work group couldn't hope to save. Both sides blamed the other for the rotten product quality and morale throughout the company hit absolute rock-bottom. An attempt to introduce Scrum into this situation failed because of the maelstrom of blame, mistrust, horrible morale, and fear of change.

The highest morale I have had the privilege to share in occurred on Scrum teams that were allowed to play by the rules of Scrum: only pulling in the work that the team members could commit to, failing tests were simply an indication of "not done," and nothing that was "not done" ever saw the light of day. The company provided adequate support for continuous integration, TDD, refactoring, and other good engineering practices, which allowed the teams to work without fear of unintended consequences. When a bug did surface, as bugs inevitably will, the team that produced it was responsible both for the fix and the tests to prove the fix. The teams in this organization felt the same degree of ownership and satisfaction when fixing bugs as when developing new features. In short, their morale was in the stratosphere. Their quality was also spectacular.

So the next time you notice one or more teams suffering from poor morale, work on quality. Fix the quality problem and the response to an inquiry about morale will almost certainly be "what morale problem?"

All for now....

...-.-