The Agile Word Association GameBy David Bulkin

#	Term	Possible Association
1	ATDD	Bad
2	Backlog	Coordinate
3	Daily Standup / Daily Scrum	Design
4	Product Owner	Facilitate Collaboration
5	ScrumMaster	Iteration
6	Sprint	Specify
7	TDD	To Do List
8	WIP	Tradeoff

We are about to play word association game.  This is a game, not a test, so the purpose is to provoke thought, not define the exact meaning of each term.

Given the list of the words on the left, find the most appropriate match on the right. Remember that this is a game, so, even though both “ATDD” and “TDD” are listed on the left, you won’t find “Testing” anywhere on the right. If it were that easy, it wouldn’t be fun or informative!

The Associations

ATDD = Specify

Oh, you thought ATDD / Acceptance Test Driven Development was about testing.

In fact, ATDD is at least as much about specification as it is about testing. With ATDD, Product Owners, Business Analysts, Testers, Developers and other stakeholders use a common language to concretely define examples that specify the expected behavior of a system.

The concrete examples are created before the code, and when specified in a format compatible with one or more testing frameworks, like Fit or Cucumber, they can serve as executable specifications (once the supporting fixtures are coded).

With ATDD, external dependencies are often mocked or stubbed, making it possible to verify that functionality meets the specifications, but not necessarily proving that the system works in an end to end fashion. As such, despite its’ name, ATDD does not replace integration testing, but it sure does make it a whole lot easier to specify expected behavior in a way that can truly be understood by all, hence, ATDD = Specify.

Backlog = To Do List

At its’ simplest, your Product Backlog is a prioritized To-Do List with estimates. Your Iteration Backlog is your short term to do list. Doesn’t sound very technical, but that’s what they are.

Daily Standup / Daily Scrum = Coordinate

Traditional project teams focus their status meetings on providing information to the manager, who then makes all of the decisions.  Agile teams answers three questions so that team members can commit to each other and self manage.  The questions are:

1. What did I do since the last stand-up?
2. What will I do before the next standup?
3. What blockers do I have?

You should answer these questions succinctly,  deferring details until the post meetings (which I call the “Daily Sit-Downs”) so that just the information necessary for the team to coordinate, and hence, self manage, is covered.

Product Owner = Trade-offs

We all know that the key responsibility of the Product Owner is maximizing the business value of the system that is developed.  But, how much fun would it be if "business value" was on the list?

More importantly, when I think about how the Product Owner maximizes values, I think of at least two key things, conveying the information that the team needs, and making trade-offs decisions.  I emphasize the trade-off decisions in this post, as in my experience, this aspect of the Product Owner role is sometimes not given enough emphasis, so, at least for this post, Product Owner = Trade-offs.

ScrumMaster = Facilitate Collaboration

There are many attributes of the ScrumMaster role.  At the core, the ScrumMaster ensures that the process is being followed.  So, I guess I could have said, ScrumMaster = Ensure Process is Followed, but, remember this is a game, not a test, so I want you to think.

In thinking about the ScrumMaster role, my experience has shown that it is easier for novice ScrumMaster's to grasp the process, but far more difficult to understand how to facilitate the self managing aspects of the team.

As such, in this post, ScrumMaster = Facilitate Collaboration.

Sprint = Iteration

A textbook definition of sprint (outside the world of agile), as given by Wikipedia is a type of short race in athletics.

When I co-train with Sanjiv Augustine he likes to point out that racing is not an appropriate metaphor for executing with a sustainable pace.  I agree, and I prefer Iteration to Sprint.

TDD = Design

TDD, or Test Driven Development, is an approach where a developer, or pair, write a test prior to writing just enough code to pass the test. The tests are automated, and they are constantly run, to ensure that code changes work and that they don't have unintended consequences.

OK, you may ask, then why do I equate TDD with design?  As with ATDD, TDD much more than testing.

Most hard core devotees of TDD will tell you that the act of writing the test prior to writing the code is an easy and cost effective way to create simple, clean, loosely coupled, highly cohesive, i.e., well designed, code.

Hence, TDD = Design!

WIP = Bad

Work in Process, a.k.a. WIP, is the partially completed deliverables. There will also be some unfinished work in a system, but complexity quickly expands as the amount of WIP increases, so, WIP = Bad.

Answer Key Summary

#	Term	Association
1	ATDD	Specify
2	Backlog	To Do List
3	Daily Standup / Daily Scrum	Co-ordinate
4	Product Owner	Tradeoffs
5	ScrumMaster	Facilitate Collaboration
6	Sprint	Iteration
7	TDD	Design
8	WIP	Bad

Closing

There are many equally valid, and in fact more valid associations than the ones I listed, but this was a game, not a test, with the intent of provoking us to think.  Please feel free to provoke me, and all readers of this blog by providing your feedback.

Death by Team Room, or Teamroom-A-CideDavid Bulkin

Agile teams are often co-located with all team members sitting in one physical room.  The rooms are often spacious, with ample natural light, an effective layout, nearby private space, etc., and, as a result, productivity is high.

But, there is an anti-pattern; productivity-robbing team rooms that please no one (OK, maybe the cost accountants are happy).

A Good Team Room

Let’s start with a quick look at some attributes of good team rooms.

• Ample storage for personal possessions in cabinets and cubbies.
• Ample space for team members to comfortably stretch out.
• Nearby private space, often called caves, for private calls, deep thinking or collaborative work between two or three people.
• White boards, tack boards and other mechanisms that support big visible charts.
• Natural light / windows.
• Ample ventilation.
• Large screen monitors to support collaboration.
• Full size keyboards to support ergonomics.

Team Room Anti-Patterns

Sometimes agile team rooms are designed from inception into new floor plans, or as a well thought out redesign to an existing floor plan.  In other cases, team rooms are put together with little focus on productivity.

• Perhaps a cost conscious company is focusing on square foot per person (an example of metrics misuse).
• Maybe a manager just has no place to put a new team.
• Or worse yet, perhaps a manager mistakenly believes that packing everyone together will result in increases in productivity, irrespective of the conditions (a belief in agile magic).

The instantaneous conference room conversion, a.k.a., ICRC

Let’s look at one near worst-case scenario, the instantaneous conference room conversion, a.k.a., ICRC.  With an ICRC, existing employees re-locate from their cubes or offices to a conference room, often joined by new staff members (consultants or new employees).

Let's look at a theoretical, but all too common, example of an ICRC Anti-Pattern:

In our example a team of 18, eight existing employees, two new hires, and eight consultants, are packed into the conference room (hey, why not, 20 people can sit there for a meeting).

This conference room, like many, has good ventilation and natural light. Additionally there is ample white board space upfront. 

On the other hand, there is no tack board or magnetic boards for cards, so one on wheels is brought in, which takes up just enough space to make it difficult for those sitting in front of the board to get in and out of their chairs.  When people come by during the day to look at cards, it is a tight fit, which sometimes results in a few spilled cups of coffee.

Power and network connectivity is available only at the two ends of the room so long wires are dangerously snaked throughout the room.

There is no place for private stuff so team members place their personal possessions under the table and in the desks of friends who are located elsewhere. 

Many of the team members used to use separate full size keyboards and an external monitor, but with the reduced space, ergonomics is a luxury that can’t be afforded. 

Taking personal calls now requires a hike to the lobby area or outside, the most private spaces still available for the team.  Conference calls are conducted several times a week in the room, and although collaboration is important, it is rare that all 18 team members are required for a call, but they really have no option other than listening.

The Productivity-Robbing Result

As a result, our team experiences a significant increase in stress.  They also experience minor injuries like tweaked backs from leaning at odd angles, carpal tunnel syndrome from typing on a poor laptop keyboard and eyestrain.  No surprise, illness is also passed around quite rapidly.

Productivity is low to non-existent, and 18 team members produce output that a team of four could easily create.

Management eventually notices, and mercifully, the team is disbanded.  Unfortunately, this was the first agile project, and the entire transition to agile is canceled based on the poor results of this one effort.  Apparently no one in management seems to understand just how detrimental the poorly designed team room was.

Conclusion

Despite what the above scenario may lead you to believe, I am an advocate for team rooms, assuming they fit the needs of the team, are designed by the team, and provide basics like ample space, ventilation, light, windows, ergonomics, storage, nearby private areas, etc.

But, as extreme as the above scenario seems, truth is often, stranger, and worse, than fiction. I had to make the scenario sound plausible so I couldn't use the real examples I have seen (you wouldn't have believed them)!  As agile usage continues to grow, and as companies continue to face tough economic realities, anti-patterns like the Instantaneous Conference Room Conversion will likely occur more and more frequently.

As agilists, we have to dispel the notion co-location equals agility.   We also need to accept the fact that if the space isn’t available, perhaps it may be better to:

• Delay the project start until space becomes available for an appropriate team room.
• Form a smaller team.  Perhaps a productive team of five is better than 18 non-productive members.
• Not execute the project at all.
• Execute the project without co-locating the whole team in one room!  Yes, old fashion cubes and offices can be better than a poorly designed team room.
  

Please respond with your thoughts and experiences.

Chickens, Chigs, Pigs and PigletsBy David Bulkin

Although many don’t like it, all agilists are familiar with the chicken and pig joke that explains that pigs are committed to success, while chickens are at best involved. As we continue to move to larger scale enterprise agile, we can benefit from understanding varying levels of participation and commitment. As such, I use terms like piglets and chigs to describe patterns and anti-patterns of team participation and commitment.

Piglets are part time participants that view their role as making a project successful, and act accordingly, despite their part time participation.

Chigs on the other hand, are individuals who look and act like chickens, but whom should really be pigs or piglets. Chigs are often worse then chickens as they frequently focus on finding problems and derailing the project instead of helping the project succeed.

Looking more Closely at Piglets

Long before Scrum became popular, there were concepts like being a member of a Core Team (think pig) or an Extended Team (think chicken). Over the years, many organizations have benefited from another concept; an Extended Core Team (think piglet).

Extended Core Team Members work part time on a project, but they are committed to success. They focus on finding solutions, not poking holes. They are only successful when the projects they are on are successful. To make this delineation clear in the agile community, I have often used the term piglets to describe Extended Core Team Members.

A Typical Anti-Pattern, Security Engineer as Chig

The evil inverse of a piglet is a chig. For example, let’s assume you are developing a new application in a high security environment. Your team works hard to understand the complex security infrastructure, but the custom services for authentication, authorization, and file transfer, along with multiple dependencies on other teams, makes it difficult to get clarity on how to proceed.

Unfortunately, Chuck, let’s call him Chuck the Chig, is the Security Engineer assigned, part time, to your team. The part time nature of his assignment is a problem, but even worse, he is simply not concerned about your project’s success.

Chuck the Chig views his role as telling you why your system can’t go live, without giving you solutions. Here’s a sample conversation that you may have with Chuck the Chig or other chigs like him.

You: How does our app look from a security perspective?

Chuck the Chig: Not good, I don’t like the authorization mechanism. I will have time in two months to review this again after you fix it.

You: But, as you know, we are due to go live in six weeks, and you have had access to everything since day one. Can you give me a specific recommendation and work with us to fix the problem?

Chuck the Chig: You don’t seem to understand my role. As a Security Engineer, I can tell you what is wrong, but I can’t tell you what to do. You have the detailed, 218 page, document that describes valid protocols and how to leverage our security infrastructure. Read it, fix the app, and when I have time in six weeks, I will check to see if you have done it correctly.

Even worse, Chuck the Chig goes back to his peers, and explains just well, how dumb your team is. In short, Chuck the Chig views his role as an auditor, someone who finds problems, not as someone who helps with solutions. In fact, he gets more accolades from his boss for pointing out problems than he does for helping your team succeed.

Pulling off the Feathers

The pattern described above is far too common, and it often occurs with individuals from compliance, architecture, privacy or similar groups in larger companies. It would be nice to have full time participation from the aforementioned groups, but this is often not possible. The real leverage point is a commitment to success by those who may potentially view themselves as chigs. They, their bosses, and the organization, must view them as piglets, or Extended Core Team Members if you prefer, and use whatever limited time they have on the project to maximize the chance for success.

Saying this another way, you need to pull the feathers off of the chigs and make them piglets, where pulling off the feathers is a metaphor for removing the false assumption that there job is to find problems (e.g. their job is provide solutions).

Closing and Credits

The example above makes the case for the piglet and chigs delineation, highlighting the importance of being fully committed to project success even when participating only part time.

I coined the term piglets quite some time ago, but special thanks go to Teresa Tierney, a creative individual indeed, for coming up with the “pulling off the feathers” analogy. Hopefully this vivid metaphor will help your team (including those on the Extended Core Team) achieve success.