Chicago Bound - Agile 2009 Conference

Now two and two is four,
six and two is eight
Come on baby,
don't you make me late
I'm cryin' hey, baby,
don't you want to go
To the same old place,
sweet home Chicago

-- Muddy Waters (Sweet Home Chicago)


I'm not sure if I'll drive, ride the dog, take Amtrak, or fly, but I am reminded of this classic Blues Brothers scene:

Elwood: It's a hundred and six miles to Chicago, we've got a full tank of gas, half a pack of cigarettes, it's dark, and we're wearing sunglasses.

Jake: Hit it.

Discovering Tasty Cupcakes

At Agile 2008, in the Agile Playground, Don McGreal and Mike McCullough adapted a series of experiential learning games to accelerate the adoption and understanding of Agile. Hats off to Don and Mike for creativity and sense of humor.

The recipe cards for the games are listed at Tasty Cupcakes. There's an analogous list of exercises geared toward Extreme Programming (XP) at XP123.com.

For anyone who's suffered through a silent, non-participatory Sprint Retrospective, the potential remedy lies in a Tasty Cupcake or two. The Tasty Cupcake game called The Story of our Sprints is a promising exercise to liven up your Sprint Retrospectives.

Have fun with these.

Nothing Gums Up a Well-Oiled Agile Team Faster

I ran into fellow Agile-ist Chris Bartling in the halls of the fine organization where we both consult on different projects (I'm working with an enthusiastic team building a collaborative community called Law School Exchange).

We yammered about the importance of Product Owners grooming and feeding the backlog. Today I noticed Chris blogged about, what else? ... The Importance of Grooming the Story Backlog.

This is often overlooked. But as a well-traveled, in-the-trenches developer I can say that

Nothing gums up a well-oiled Agile team faster than the business not feeding the hopper with meaty stories.

The first step is understanding what makes a useful story. Lots of people have written about, and know much more about, useful story generation (e.g., Agile coach David Hussman).

I volunteered to help our business side write story cards for a couple of Sprints ahead; they were not keeping up with our dev team's appetite. Developers love meaty stories.

Fortunately I have earned the trust of the Product Owner, so that I can say “We’re on the verge of flailing, how can I help?”. I met with him and his lieutenants for 3 hours yesterday afternoon. We generated about 20 meaty stories.

I hoped to suggest, in a non-abrasive way, the kinds of things that help developers be productive after, for example, reading the tests that constitute done, on the back of the story card.

Here are 3 simple things I hoped to impart about Story cards:

• Meaningful story title (card front);
• Blurb encapsulating the gist; AND
• Tests (card back) that "constitute done" using personae (e.g., Law Prof Larry can mark a document "private").

Once we understand how to write a useful story, the next step is make a grip of them. Lay out the path as far as you can. Developers love that. No one wants to see the business flail. When a Product Owner is not allowed to focus on the product, and starts to flail, projects get axed.

Product Owners need to be several Sprints ahead in the Backlog. I also suggested to our Product Owner that he have weekly meetings with his lieutenants to GROOM and FEED the backlog.

5 Characteristics of Effective Teams

One of my favorite engineering professors is Karl Smith. Karl Smith, Professor of Civil Engineering at the University of Minnesota, has researched and written extensively about the "engineering method" and teamwork. In the book Teamwork and Project Management, Karl summarizes what he and colleagues recognize as 5 characteristics of effective teams:

Positive Interdependence
"The team focuses on a common goal or single product"

Individual and Group Accountability
"Each person takes responsibility for both her or his own work and the overall work of the team"

Promotive Interaction
"The members do real work, usually face to face"

Teamwork Skills
"Each member has the skills for and practices effective communication (especially careful listening), decision making, problem solving, conflict management, and leadership"

Group Processing
"The team periodically reflects on how well the team is working, celebrates the things that are going well, and corrects the things that aren't"

These characteristics were observed and derived by Karl and his colleagues from many years of working with civil engineering groups and other teams of engineers comprised of students and practitioners. Those acquainted with Scrum, or Agile methods, should recognize these characteristics from their experiences with successful software teams.

Scrum, in particular, has nomenclature that jibes with these characteristics (e.g., Product Owner, Daily Scrum, Scrum Pit, and Sprint Retrospective).

Positive Interdependence is fulfilled by a Scrum team that designates a "Product Owner". The Product Owner drives priorities and keeps the team focused on the Product. In Scrum, work tasks are product-driven.

Individual and Group Accountability is fulfilled by a Scrum's emphasis on having each member take tasks to work on, then reporting daily progress to the team during the "Daily Scrum". Some Scrum teams have "Story Owners" which give individual members the additional responsibility of making sure the team progresses toward completion of Story tasks and then shepherds the Story through Product Owner approval ("Story Sign-Off").

Promotive Interaction jibes with the "Scrum Pit". The Scrum Pit is a physical location where team members work in close proximity. I have witnessed improvement in Scrum Pit interaction if team members are turned to face each other, rather than with their backs to each other. I have also found that paired-programming sessions enhance cross-functional learning and limit knowledge silo-ing.

Teamwork Skills are not necessarily tools that every team member has at the outset of a project, but Scrum encourages the development of these skills by structuring the project for group decisions and by creating a daily routine of communication in the "Daily Scrum".

Group Processing is fulfilled by Scrum's "Sprint Retrospective" where the team examines the previous Sprint to discuss "what went right?" and "what went wrong?", and to agree upon "action items" for improvement. Typically Scrum teams will have a retrospective meeting every 2 weeks or every month depending on the length of their Sprints.

What’s the SWOT on Scrum?

I was asked for my SWOT analysis of Scrum.

First, I recalled a mark my thesis advisor Otto Strack made on a paper I’d written. He wrote DUA. When asked about the mark Dr. Strack said, “Don’t Use Abbreviations”.

Next, I searched Wikipedia to find that SWOT analysis is a planning method to evaluate Strengths, Weaknesses, Opportunities, and Threats.

I don't claim to be the Sultan of Swat, but here is my SWOT analysis of Scrum:

Strengths

• Scrum is product-centric;
• Incremental progress is easily measurable and clearly visible to business stakeholders;
• Developers set the pace, are not overworked, and enjoy an increased role;
• Workload is infinitely adjustable, based on team-set capacity and business-set priorities;
• Issues are usually uncovered before they become endemic;
• Team is given authority to make decisions;
• Team is encouraged to "consult" with business;
• Tasks tend to be granular, and therefore, more readily testable;
• Team develops a get-it-done attitude;
• Team is implicitly encouraged to behave like a start-up; and
• The approach challenges organizational standards.

Weaknesses

• Scrum projects without an active Product Owner and without engaged business stakeholders will likely flop;
• If the Product Owner doesn't appreciate Scrum, or doesn't understand the role of Product Owner, success is harder;
• If the Product Owner doesn't work with stakeholders to keep backlog full with challenging functionality, developers get complacent and disengaged so productivity goes down;
• If the Product Owner doesn't attend to or appreciate technical debt articulated by the team, technical issues can fester;
• If developers not co-located or within earshot of the Product Owner and business stakeholders, productivity will suffer ;
• Silo-ing of knowledge can grow if ScrumMaster not attentive and team does not self-correct;
• Sprint retrospectives are wasteful if team is not forthright and constructively self-critical; and
• The approach challenges organizational standards.

Opportunities

• For product-driven organizations, Scrum is a way to revolutionize how you do business. That is, to increase productivity and to inspire commitment;
• Scrum features demonstrable progress realized through frequent, incremental production releases (Sprints). As such, it is ideal for start-ups trying to attract and maintain investors;

Threats

• Threats are most likely to emerge from outside the team;
• Compliance and legal issues in large organizations are always looming (e.g., legal team needs to review content);
• Security issues in large organizations are big because work product requires a security review;
• Jealously from non-scrum teams can be a threat;
• If an organization is not fully "Agile", or not all using Scrum, there's a perception that the Scrum team gets to do the best projects.
• Compensation issues can occur because internal team-members, or contracted team-members, typically do not work for the person giving their salary review or impacting their hourly rate;
• Revolutionary change does not suit all people in the organization; and
• Some organizations are not patient enough to realize the advantages of Scrum.

10 Critical Unity Factors in Cross-Functional Teams

At the core of successful Agile software projects are cross-functional and self-organizing teams. How is the "health" of your team?

Executive coaches Emilio De Lia and Ellen Fredericks identify 10 critical unity factors in cross-functional teams in their publication From Cross Purposes to Cooperation.

Below are their 10 critical unity factors along with associated questions posed by the authors (cf. italics). Each unity factor is annotated with observations and commentary from the in-the-trenches perspective of a Agile development teams.

(1) The Customer Factor
What is the team's relationship to its customers?

In Scrum, the Product Owner is the customer proxy. In most organizations, the "customer" is a large group with diverse interests and agendas. In successful Agile teams, team-members know and understand the customer. The iterative process of planning, prioritizing, and evaluating (e.g., retrospectives) is a rallying force and structure. Ideally, communication between customer and team is not filtered by the interpretation of a middle man (e.g., a business analyst's interpretation of requirements).

(2) The Engagement Factor
Does the team engage its members to the level necessary for the team to succeed?

Disengagement characterizes a dysfunctional team. All members must be satisfied their talents and strengths are used. Agile teams benefit from drafting a “development manifesto” at the outset of the project that outlines what is expected of the team. Architectural choices, coding practices, and standards are decisions made by team consensus. Team-members must share ownership and accountability.

(3) The Identity Factor
How strong is the team's identity?

A well-oiled Agile team has a common purpose, is proud of what the team stands for, and is proud of the team's incremental accomplishments delivering a product. Agile teams are often comprised of members who initially identify with their functional organization in the larger corporate hierarchy. Over time, this identity must evolve so that it is centered about and focused on the product (e.g., The Virtual Widget Team is an identity based on a product called the Virtual Widget). Building team identity around common purpose inevitably generates engagement and passion.

(4) The Behavior Factor
Does the team exhibit constructive norms and behaviors?

In a well-oiled Agile team, team members respect and abide by agreed upon behaviors detailed in the developer manifesto. Some teams explicitly try to root out the silo-ing of knowledge by distributing tasks accordingly. The team strives for this behavior and praises themselves for demonstrating it. High-performing Agile teams will self-correct destructive behavior. For example, one team member might suggest a paired-programming session to shine a light on something going badly, rather than continuing on a solo path "off into the weeds". Sprint retrospectives are often the best forum for evaluating, and self-correcting, destructive behaviors (e.g., gossip, technical cliques, blaming, withdrawing, or complaining).

(5) The Plan Factor
Does the team have a clearly defined plan of action that its members believe in?

Iteration planning (or Sprint planning in Scrum) typically has well-defined steps of indentifying stories, prioritizing stories, tasking stories, and generating estimates around the tasks. Many teams go the extra distance of "talking in tests". That is, each story (or task) has a list of tests that constitute "completion" of that story (or task). When successful, good planning yields a clear plan of action.

(6) The Process Factor
How effectively does the team communicate and make decisions?

Agile teams must establish trust amongst members. Trust enables members to discuss sensitive subjects and to make controversial decisions in a way that is satisfying to the group. Team-members must be able to subjugate ego and ask for help when needed. Team-members must understand each other's strengths and weaknesses. They must act in each other's best interest. The decision-making process should be simple and actionable (e.g., who, what, when, and how). Consensus vote is the preferred approach to decision-making because it generates the greatest participation.

(7) The Function Factor
How are the team's efforts integrated into the functional organization?

Some of the biggest challenges are the demands and constraints of the hierarchical organizations outside of an Agile team. Ideally, Agile teams behave like startup companies. That is, it is a flat organization where team-members wear multiple hats and responsibilities are equitably distributed. Institutional inertia and institutional controls outside of the team can often hamper team velocity. How does the team deal with these impediments and road-blocks? A ScrumMaster is often the person called upon to buffer the members from the counter-productive bureaucracy threatening the team.

(8) The Feedback Factor
How is performance evaluated and rewarded?

Agile teams have an end-of-iteration show-and-tell followed by a retrospective. This is a time where stock is taken of accomplishments, feedback is provided by the Product Owner, and the team looks back retrospectively to determine "what worked", "what didn't work", and "what action items" are needed to improve.

(9) The Responsibility Factor
What level of responsibility and commitment do members of the team demonstrate?

The daily Scrum makes responsibility and commitment difficult to shirk. Scrum or stand-ups require each member publically and succinctly state what he accomplished yesterday, followed by a declaration of what he'll accomplish today. Many teams assign story "ownership" to developers. While they might not work any tasks attached to the story, the "Story Owners" are responsible for shepherding the story to sign-off by the Product Owner.

(10) The Self-Interest Factor
Do team members see personal advantages to working on the team?

In high-performing Agile teams, individuals value the personal payoff (e.g., "I'm learning new things" or "I'm getting kudos from my teammates"). Furthermore, each member is proud of his contribution. The artifacts of personal payoff and pride in craftsmanship are easy to smoke out in the end-of-iteration show-and-tell or in the retrospective.

De Lia and Fredericks also provide a cross-functional team scorecard called TRUID. TRUID is an evaluation checklist that establishes a relative measure of how well your team is functioning as a team.

These 10 critical unity factors will help evaluate the “health” an Agile team and perhaps provide a basis for self-correction.

4 Scrum Team Tips

Following are four Scrum team tips I came up with for a colleague in the Agile .Net Practitioners group I moderate on LinkedIn. In his case, team-members were resistent to their experiment using Scrum for a host of reasons. We had a general discussion about what was working and what wasn't working.

I suggested four things to try:

1. Maintain an Impediments List
2. Maintain a Technical Debt List
3. Maintain an Inter-Personal Debt List
4. Allow for Developer Stories

Impediments

One of the roles of the ScrumMaster is clearing impediments. I favor a visible impediments list hung adjacent to the story wall. The Dev Team contributes to the impediments list, but the ScrumMaster works the issues then reports progress during Scrum.

Technical Debt

Developers frequently feel their concerns are glossed over. I favor a visible Tech Debt List, also hung adjacent to the story wall. Here developers list concerns that'll create long term detriment to quality or progress. The team acknowledges new Technical Debt during Scrum and subsequently assesses the list during Sprint Retrospectives.

Inter-Personal Debt

Teams develop inter-personal friction. The Inter-Personal Debt "List" is a series of emails (for semi-anonymity, rather than public display) kept by the ScrumMaster. Team members send issues to the ScrumMaster. The ScrumMaster addresses inter-personal issues as they arise during the next Scrum or, at the latest, during Sprint retrospectives.

Developer Stories

During Scrum planning, I favor making an allowance for at least one developer story (e.g., something a developer believes need to be worked or perhaps refactored). Developers must be able to articulate the value to the Product Owner since the Product Owner ultimately prioritizes that story with all the others (and either includes in the immediate Sprint or puts it in the Backlog).