Tools For Agile Blog

Jim Coplein posted on Jeff Sutherland’s blog basically criticising Kanban and trying to put forward a case of why Scrum is closer to Toyota’s principles that Kanban.

I’m not going to comment on the post (not directly anyway), but here is a story:

Five years ago I posted about a trend that was happening then, of asking whether a practice is agile or not. There would be endless debates about whether doing Practice X was big design up front (BDUF) or whether it violated YAGNI and what have you. Sometimes you would come across a post where a person loved a technique, but was afraid that it was big design up front. Just to set the context, in those days XP was the dominant method in the agile space and BDUF and YAGNI were the hot topics of discussion. The bone of contention was with methods like FDD that promoted up-front modeling, and Crystal which encouraged documentation and up-front UX design, and DSDM which many XP thought leaders found to be too heavy.

People essentially stopped asking “is it useful?” and started asking “is it agile?”

As any community forms around an idea, the first few years are open to playing around with it and improving it, but after a point the community attention switches over to protecting the idea from corruption and external forces. This protects the initial idea, but closes it down to growth. A lot of good ideas get discarded, because “it isn’t agile”.

I’ve learnt a lot of good things from reading FDD, and Crystal, and talking to people about CMMI. Its funny how many people in the agile community are happy to bash CMMI without ever talking to someone accomplished in it. To be frank, I was in that camp too, until I had a number of discussions with people who understood CMMI well. It turns out that CMMI has a lot of interesting ideas.

Today, people dont talk too much about XP anymore. Most of the XP thought leaders have moved on, some to the Scrum or Kanban world, others elsewhere. Meanwhile a lot of XP has been absorbed as standard practices that teams pick and choose for their project. Teams no longer talk about “doing XP” (as a package) but more about we’re doing TDD or we’re doing continuous integration.

But history repeats itself, and once again we find the question coming around once again to “is it agile?” instead of “is it useful?”

PS: Agile India 2012 is coming up next year. Be prepared to discuss a number of interesting topics, some of which might fail the “is it agile?” test Registrations are open, so what are you waiting for?

Following up on a twitter discussion, Pawel blogged about alternative kanban board designs, and showed an interesting board with columns indicating priority and stickies on a card to indicate the tasks to complete. This motivated me to search for pictures of the board we used back when we first adopted agile process. Pawel says that exposure to “standard kanban boards” has meant that everyone has ended up with similar looking boards. I think to an extent that is true. This board was designed in 2005, much before there was a kanban method, and it doesn’t really look like a kanban board you would see today. In fact, I wouldn’t even call it a kanban board as it has no WIP limits or pull. It’s more of a team board visualisation.

Continue reading ‘Visualisation in Board Design’ »

This coming weekend, I’m going to be talking at Agile Tour Chennai about visualisation in the context of agile teams.

It is my belief the visualisation is the key to being truly agile. Why? Read on..

Continue reading ‘Why Visualisation is the key to being Agile’ »

This is a three part video series that shows how you can do more with story maps. Story Maps are a really powerful method to both a) create the product vision in a collaborative manner and b) visualise the scope. Here at ToolsForAgile.com we are huge fans of visualisation, and with our electronic story maps, you can do a whole lot of cool things.

The series has three parts

1. Creating the story map
2. Release planning
3. Tracking progress against the vision

Creating a story map

Creating a story map is not simply a matter of entering data into the system, but a process of collaborative exploration. Our tool is expressly design to support this exploration. This video shows a typical session of creating a story map. Notice how cards get moved around, some cards get grouped together while others get split. And the tool never gets in the way throughout the process.

Release Planning

Release planning is where development team meets business strategy. Therefore, before you do a release plan, it is important to understand the business strategy. Which features are our differentiators? Which parts of the system are risky? Do we need early feedback on specific features? Are there some features which we are not sure the market will accept? Only when we answer these question can we make a truly effective release plan.

Unfortunately, release planning is often considered only in terms of selecting some stories and calling it a release. Most electronic tools do not allow you to effectively do a business visualisation prior to creating the release plan. The result? Product development is not aligned to business strategy!

In this video, we show you how our tool supports creating release plans through visualising the application in business terms

Execution Tracking

Once you have your vision laid out and the release plans done, then its time to execute stories. You will usually take your stories from the story map, and go elsewhere and put them in another tool or physical board to execute them. And what happens there will not be reflected back onto the story map.

But things are different with toolsforagile.com. In this video we show how to you move stories between the story map and team boards (scrum/kanban boards), and have the result overlaid on the story map.

You can now answer questions like

1. How many of our differentiators are remaining?
2. Have we implemented our risky features?
3. What level of enhancement is a specific feature?

There has been a lot of talk in the agile community about acceptance criteria. How having defined acceptance criteria beforehand makes development a lot easier. And it does. I’m a big fan of acceptance criteria. But just because someone write an acceptance criteria on the back of a card, doesn’t mean that what they’ve written is the correct criteria.

That might sound like a dumb thing to say. After all, if someone writes a wrong acceptance criteria, then what can we do about it? It’s their fault, they’re just going to get the wrong software, and they have no reason to complain… Right?

Continue reading ‘Don’t fall into the Acceptance Criteria trap’ »