Tag: Three Amigos

A Highly Evolved Card Wall

I’ve been promising Mark Levison since forever to describe the highly effective card wall that evolved at one of my past clients. The team started with a simple beginning, and modified it as they saw fit to suit the needs of their situation. This is not a universal model for others to blindly copy, but there is much to learn from it.

No doubt that it continued to evolve beyond my knowledge, as this team spectacularly took control of their own development process. I’ll never forget the Monday morning that I walked into the team room, direct from the airport, and saw them pulling cards and tape off the corkboard wall. “What the heck are they doing?” I thought. I stood and watched from across the room as the scurried around excitedly with much conversation. Tape and cards started to go back on the wall in a different configuration. I knew then that this team was going to excel, as they were paying attention to how things were working for them and adjusting accordingly. Excel they did, and their wall was in frequent flux as long as I knew them. It’s amazing what a team can do when they have the desire and freedom to improve.

Read More
No Comments

Categories: Tools and Techniques

Tags: , ,

Using a good tool for the wrong thing

When I first met Andreas Schliep, he told me a consulting war story with the punch line, “Well, you can paint that wall with a screwdriver if you like”¦” There’s no stopping people who are intent to use the wrong tool for a job, or use it in the wrong way. Sometimes it even works. I’ve seen someone successfully, after a fashion, driving wood screws with a hammer. Read More

No Comments

Categories: Customer Collaboration

Tags: ,

Definition of Ready

Many time, in the middle of developing a user story, the programmer discovers a question about how it’s intended to work. Or the tester, when looking at the functionality that’s been developed, questions if it’s really supposed to work that way. I once worked with a team that too-often found that, when the programmer picked up the card, there were questions that hadn’t been thought out. The team created a new column on the sprint board, “Needs Analysis,” to the left of “Ready for Development,” for these cards that had been planned without being well understood. Read More

4 Comments

Categories: Individuals and Interactions

Tags: ,

Avoiding Mini-Waterfalls

A lot of people and organizations, when transitioning from a serial software development lifecycle toward an Agile one, fall into the pattern of mini-waterfalls. They start doing iterations, but each iteration resembles the development lifecycle they already know. The programmers do some design work, then they write the code to implement the design, then unit test the code, and then they pass it to the testers for testing. To many people, this is the only way it can work. Their mental model only admits to this series of phases.

And they run into typical problems. Sometimes the design doesn’t fit the problem well, and patches are needed because there isn’t time to go back to design. The testers get squeezed for time at the end of the iteration, and no one knows how to accommodate the rework when a problem is found. More patches are added, because there isn’t time to redesign. And the next iteration starts the cycle over again.

Sure, doing this in two to four week cycles beats doing it in six to twelve month cycles. But only a little. Most of the time, it starts to fall apart if the team doesn’t learn to work differently.

But it’s inevitable, they say. Read More

5 Comments

Categories: Individuals and Interactions

Tags: , , ,

Avoiding Iteration Zero

Teams new to Agile often realize that they have a lot to do before they get their new development process at full speed. Looking at this big and unknown hill in front of them, many Agile teams choose to do an Iteration Zero (or Sprint Zero) to prepare before they start delivering regular increments of functionality. During this time, they may try to get their ducks in a row with

  • A list of features to be built
  • A release plan or timeline for those features
  • Setting up development infrastructure such as version control or continuous integration servers
  • Studying or practicing skills in new technologies they expect to use
  • … and other management, infrastructure, and technical endeavors.

They try to get all the preliminaries out of the way so they can hit the ground running full speed in Iteration One. In my experience, they’re still not ready to go full speed. These things are rarely as complete as expected after one iteration, and often aren’t quite in tune with the actual needs of the project.

The list of features will likely not be complete, but the attempt to approach completeness will dump in lots of ideas that have been given little thought. Any attempt to project into the future still has no data about how fast things can be accomplished. The infrastructure may or may not be the best for supporting the project, but it is likely that the project will now conform to the infrastructure rather than the other way around. The choice of technologies will be made speculatively rather than driven by the needs of the project. While we may do OK, we’ll have made a lot of decisions with the least amount of information we’ll have in the project lifecycle.

And we’ll have burned an iteration without producing any working software that tests our decisions.

My advice is to borrow an idea from Lean and look at the situation from the output point of view.  Ask yourself, “what would it take to start delivering?” Read More

23 Comments

Categories: Tools and Techniques Working Software

Tags: , , , ,

Splitting User Stories

I’ve written about User Stories before and made available a handout that includes a page on splitting stories that, in addition to listing some splitting heuristics, includes several links to several lists of techniques for splitting stories.

What it doesn’t include is an even simpler way to split stories–the simplest way I’ve found yet. Read More

14 Comments

Categories: Tools and Techniques

Tags: , , ,

The Reality of Automated Acceptance Testing

Recently, Jim Shore wrote about The Problems With Acceptance Testing.  I like Jim, and respect him a lot.  Because of my respect for his opinions, I found it quite discouraging that he said, “I no longer use [automated acceptance testing] or recommend it.”  Gojko Adzic has posted his response to Jim.  This is mine.

Certainly when something’s not giving you the results you want, it’s time to make a change.  That change can be to drop the practice that’s not working for you.  It can also be changing the way you go about the practice, or changing what you want to accomplish.  Or, instead of changing, maybe the word “refining” is a better fit. Read More

11 Comments

Categories: Individuals and Interactions Tools and Techniques Working Software

Tags: ,

A Lingua Franca between the Three (or more) Amigos

There were a couple dozen people who showed up at the Fool, last night, for my presentation on A ”Lingua Franca” to Ensure You Get the Right System.  I’d like to thank them all for coming and for such lively participation.

These are exciting times.  The tools of acceptance testing and behavior-driven development are progressing beyond the domain of the techies.  They are entering the realm where they can help the Whole Team. Read More

9 Comments

Categories: Customer Collaboration Tools and Techniques

Tags: , ,