I remember reading Bruce Tate’s books on Java and EJB
, which were all about anti-patterns, years ago and enjoying them. It was refreshing to read about how NOT to apply certain technologies. While there were plenty of books out there on how to do great things with Java and EJB (stop laughing), many of us using those technologies also found some not so great things we could do with them.
In much the same vain of Bruce Tate’s books, I give you a Scrum anti-pattern. Most Scrum teams will use a daily task board, either real or virtual. The task board contains a Sprint’s user stories and the associated user story tasks in the form of cards. It’s normal to see a few columns across the board along the lines of, “To Do”, “In Progress”, “To Verify”, “Done”, etc. The idea is for a team member to put his name on a task card and then move the card into the appropriate column. This is done throughout the day and especially at the daily Scrum. Below is an example of a Scrum task board.

Pretty simple. Below is the task board gone wrong. The difference is subtle and deserves an explanation as to why this is wrong.

Notice the extra column, “Today’s Work”. Having additional columns isn’t an issue, but this particular column presents a problem. The way the team uses this task board is to move tasks to “In Progress” when they’ve started work. But, since the team will sometimes start a task but then need to start on something else, the team decided they needed a column that showed what was in progress currently, thus the “Today’s Work” column. For example, in the daily scrum yesterday, Joe said he’s going to get Task A done. Joe moves this task to the “Today’s Work” column. Today, Joe tells the team in the daily scrum that he needed to start work on Task B for another story to help it keep moving forward, so he moves Task A to the “In Progress” column and makes sure Task B is in “Today’s Work”, as he didn’t finish that task yet. The problem is that we have impediments hiding under the “In Progress” column now. Rather than Joe saying that he was impeded from completing Task A, he moves it to a column (“In Progress”) that makes it seem like all is fine. All might be fine, but how do we know? It would be better to mark Task A as impeded. Joe could then make it clear to the team why he made the decision to not complete Task A in order to start on Task B. Everyone would see that Task A is in progress and it’s impeded (as opposed to simply “in progress”). The Scrum Master can help the team tackle this impediment.
Impediments aren’t inherently bad, but hidden impediments are. The task board gone wrong makes it far too easy to hide impediments while also making it difficult for the team to tackle properly. We all struggle with identifying impediments, so it’s important that we make sure our management tools are setup to help us make impediments visible and hard to miss.


It’s amazing to me how many projects start up without a clear vision. I’m not talking about an idea. I’m talking about a no kidding vision. And, no, I’m not picking on those who start projects on the side or just for fun. I’m picking on the those of us who are involved with projects for our organizations and customers that started up without a clearly defined and well understood vision.
Some may think the template above is only good for products or product focused companies. Internal projects or those that aren’t developed for resale can still make use of the template. The challenge is to think differently about certain concepts. For example, the competition for internal projects is normally one of legacy systems, manually intensive processes, or the status quo.
Over the last six months, I’ve been mulling over one of those subjects that has often been a stumbling block for IT providers considering adoption of agile for their customers’ software development projects. The dilemma revolves around contracts and estimating projects. The two tend to go together. Once you have one figured out it seems you’re left with even more questions with the one remaining. I have some ideas on how to make agile contracts and estimating better based on what I’ve learned and observed over the years.
My favorite agile software development topic of them all — tools. More specifically, agile project management tools. If you’re old school, you bust out some index cards, some 
The focus of these tools does not start with a project manager view of the world, but rather with a project contributor and user focus. This means that an issue tracker becomes the central nervous system. Version control is a first class citizen, not something you leave for third party integrations. Mailing lists, forums, and RSS/ATOM feeds are often key features in these open source software project management tools.
The team working this user story thinks they’ve got it during their backlog selection. They’re excited to put the screws to the carriers as they prepare to expand beyond AT&T and turn the cell phone industry on its head. The team does their task breakdown and they’re off and racing. Daily scrums are happening, team members are communicating, impediments are being raised, tasks are getting done, and all is good in iPhone VoIP call land. The sprint review rolls around and the team is ready to show off their solution. They demonstrate making VoIP calls on a 3G network. Only one little problem. The team mentions that in order to complete this story in time they decided it was best to use a VoIP service provider that would make the user experience far superior to any the team could develop in a reasonable amount of time. The VoIP service provider charges a monthly fee. On top of the monthly fee there are hidden charges around certain types of calls. The product owner does his own demonstration following this. He demonstrates how the iPhone 3G can be used in combat by chucking the sleek devices directly at the team members’ heads.