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?

Did you know that you could link code commits in your source control system to cards in Tools For Agile?

If you didn’t, then take a look at the video below to see you can integrate with subversion. (You can find detailed instructions here)

The integration looks at the commit message for the card #id and links the card in Tools for Agile to the commit. You can then look at the card details page to see a list of all commits that are linked to that card.

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.

Early 2005

This is the board from early 2005.

The board has three sections

1. Not Started. The cards that are not started are arranged in columns, based on who is planning to pick up that card (although it could eventually be picked by someone else)
2. In Progress. Cards in progress are arranged in columns, each column containing cards of one team member
3. Awaiting verification. This column in labeled “Customer”. These are cards that are complete and are awaiting verification. Usually the verification was done by me.

The colour of the card indicated the type: Pink for important work, orange for bugs, yellow for new features and green for enhancements.

A couple of patterns jump out straight away:

First, most of the cards are waiting on the customer. That’s because the customer (me) only verified cards at the end of the release. We did three week releases, so these cards would queue up for three weeks. If any card wasn’t okay, then we would put it back into the Not Started section for the next release.

Second, look at the amount of multitasking for some team members relative to others. Some team members are overloaded for sure.

July 2005

This photograph was taken sometime in July 2005, so its a few months later.

You can see that there are two boards now. The board on the left, directly facing the camera is the roadmap board. This board contains the “big features” that were planned for the next six releases. You can see the release number and date on the top card of each column. The team board on the right has also been redone. Team names have been replaced by photographs, but more significantly you can see that the multitasking is way down. Also the customer column, while still long, is now a lot shorter compared to before as some cards were verified without waiting for the release date. It also helped that we could cards which failed verification back and fix it before the release came.

Visualisation is the important part

Day before yesterday I blogged that visualisation is the key to being agile. You can see that in action here. After putting up the team board, suddenly every team member knew what was going on. This enabled the team to take ownership of the work, leading to better collaboration, and better agility. Nothing rocket science about this. The success of the team board prompted us to create the roadmap board with the next six releases on it.

More patterns

The team board is just one of many kanban board pattern. Pawel’s blog post shows another pattern. At LSSC12 Alisson Vale showed me a board where the team board pattern is embedded within a larger kanban board (You can see that board depicted in our electronic kanban board tool here). Visualisation goes far, far beyond just the basic kanban board.  If you are interested in visualisation, then check the recording of my July webinar on Advanced Kanban Board Patterns.

Also, visualisation isn’t just for a team’s work items. You can see above that the visualisation of the roadmap that we did in 2005. It was rather basic and didn’t visualise everything we wanted. So I was always on the lookout for a better way to go about it. In the last three years, I’ve become a big fan of using story mapping as a way to visualise a project vision, roadmap and progress against that vision. If you’re interested in story maps from a visualisation standpoint, then sign up for my upcoming webinar this month on story mapping.

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..

Imagine for a moment that you’re playing a sport. Lets say football (soccer). Also imagine that the players in your team are told to wear blinkers (blinkers are what they put on horses so they can see only ahead), giving them a limited vision range, maybe just 1 metre in front of them. Only the coach can see the whole field. Therefore the coach has to tell the players where to kick the ball, and the players blindly follow the coach’s orders. How effective do you think this football team is going to be?

Donald Gray has a fabulous case study about three different leadership styles brought out while managing traffic at an intersection. This is a fantastic article and I suggest everyone read it and come back here. He shows how a policeman manually trying to manage the traffic is a lot less effective compared to leaving the drivers to figure it out themselves. Anyone who has driven in India knows this already. The traffic here is utter chaos, but it flows, even when the traffic lights aren’t working. In fact, if you see a long jam, chances are high that policemen are manually regulating the traffic!!

What these stories tell us is that when lots of complex decisions are to be taken, it is a better to decentralise decision making lower in the system.

Lets rewind back to the football team. Anybody can figure out that playing the team with blinkers, and the coach directing every move is a bad idea. It’s so obvious that you wouldn’t even consider it for a single moment. But, isn’t that exactly what we are doing in our software development teams? The project manager is often the only one who knows whats going on in the bigger picture. The team is developing with blinkers on. The project manager makes the move, communicates it to the team and the team executes the move. It’s not a very effective way of working.

In fact, like the policemen story, a single project manager who makes decisions on behalf of the team is likely to only make things worse. A project manager who assigns tasks to people in an attempt to balance work, is more likely to overload some people compared to each person picking up a task themselves when as they get free.

#1 A team is more effective when they make team level decisions for themselves.

But of course, thats not enough. If the blinkers are on, the team is going to flounder. You cant expect a team to make decisions effectively when they can only see a limited view. So you need to remove the blinkers. They have to see the same picture that the project manager sees when making a decision. They need to know what everyone is working on, and whats stage each work is in, and what is upcoming.

#2 Make the work visible.

Making work visible is good, but humans find it hard to make out patterns (unless its really obvious) from a table or spreadsheet. In this amazing TED video, David McCandless explains how the visual bandwidth of the  human brain far exceeds any other sense. Analytic capabilities are tiny by comparison. We are genetically predisposed to being very fast at identifying colour, shape, pattern and geometries.

Here is an example: Take 10 seconds (no cheating! ) looking at this, and see what you notice

Did you notice these things:

1. Everything going to Test is being blocked
2. Lots of things in progress, nothing completed
3. Sid is overloaded with work and is multitasking many stories

How does this team move forward? Take a while to think about possible next actions, before heading to the next section.

Now take 10 seconds looking at this:

Find it easier to see the patterns?

Now, how does this team move forward?

• It would seem that the first step is to unblock test and get those cards to completion. No point finishing Development cards and adding it to a blocked test queue. So the developers drop what they are working on, and pair with the Ram & Arjun to fix the bugs and get those cards passed
• Then Ram & Arjun (now free) help Sid to cut down the multitasking and get get some of the cards through test
• The bottleneck at test and development are now both untangled. The team discusses how the queue got blocked, how Sid landed up with three cards in progress, and how it can be avoided

Go back to the spreadsheet. Did any of these steps jump out? Come back to the visualisation. Did these steps jump out?

These are the kinds of decisions that team members can take for themselves when the blinkers are off. Much better than the project manager trying to make the decisions.

#3 Visualise the work

Visualisation leads to understanding. Understanding enables team decision making. Team decision making enables collaboration and agility.

Some of our case studies back this up. When teams could visualise work, they collaborate more, and self organise better, leading to better agility.

The best part?

Project managers get to take a break from all that decision making and can focus on much higher value activities, like steering the team towards the goal.

Our next webinar is on the 23rd of November, 9PM IST (10:30 AM US East Coast, 7:30 AM US West Coast, 4:30 PM Central Europe).

In this webinar we explore Story mapping, both to conceptualise a project, and to guide the implementation strategy.

Topics covered will be

1. Create a story map
2. Perform a business analysis of your story map
3. Come up with a release strategy
4. Link project progress towards business goals
5. Find out how you can do it all using story mapping functionality in toolsforagile.com suite.

Learn more about this webinar or register for free here.

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?

The new requirement specification

Remember the old days? Customer gives you a requirement spec, you implement the spec. Customer gets the software, and then requests changes. “But, thats not in the spec” you say.

Fast forward a decade, and what do we have

Old days Today What do we build? Look at the requirements Look at the acceptance criteria How do we test Conformance to requirements Conformance to acceptance criteria When are we done? Requirements met Acceptance criteria pass The hitch Requirement were flawed Acceptance criteria were flawed I love acceptance criteria

I earlier said that I love acceptance criteria, and now I’ve just gone and bashed it, comparing it with that waterfall document. Whats going on?

Well I love acceptance criteria at the story level. Over there, acceptance criteria do a wonderful job. It lets us know when a story is done and when we can move on to the next story.

The problem comes when you roll it up and use acceptance criteria to steep the ship. Just because we are meeting acceptance criteria doesn’t mean that we are building something useful. We build software, not to meet acceptance criteria, but to solve some business or customer goal. And lets face it, goals are nebulous beings, which most of the time cannot be translated into acceptance criteria. Look at these examples

• I’m building a search engine. A key goal is to deliver more relevant hits than Google. What are “relevant hits”?
• I’m making a game. A key goal is that the game should be fun. What is “fun”?
• I’m writing an iPhone app. A goal is that it should be easy to use. What exactly is “easy to use”?

None of these goals can be translated into acceptance criteria. The only way to get there is to do something, make changes, and repeat.

Build with acceptance criteria, steer with goals

Now, you might think this is obvious. After all, being agile is all about responding to feedback. So it is rather surprising that many agile teams have their sprints and acceptance criteria and definition of done, but have no techniques to validate the application against goals and change direction. In essence, they are playing the “requirements specification is God” game all over again.

If you are a product owner, then your job is NOT to simply to accept or reject stories, but to keep validating the product being built against goals and steer the ship.

via Geek and Poke

Agile is Bloated

I realised this the other day when, on a mailing list, someone asked about what the “Sprint Goal” was supposed to be. A reply came from someone else that they didn’t have a goal, but since “scrum mandates a goal”, they decided that their goal was “to implement stories”. Of course, this is a rather meaningless way to have a sprint goal.

So that got me thinking: Have agile processes become so complicated that they confuse the hell out of most people?

Take something simple, like user stories. Originally they were just little pieces of features to build.

Nowdays you’ll be told how user stories have to be from the user’s perspective. And they have to follow this “As.. I want.. So that” template. And that they have to be INVESTable. And oh, the stories have to be small. Like really small. Really, really tiny small. There is a whole industry around just making your story so small that it cant be cut any smaller. (PS: dont forget, vertical slicing only! Like a sashimi).

And you have to estimate them. There is a whole another industry around how to estimate these really, really, tiny small INVESTable stories. Using these things called ‘story points’. Y’know relative estimation and all that (psst.. relative complexity, not relative effort). But only with fibonacci numbers (they’re cool!). And overlapping probability distributions (also cool!). But be careful young padawan, because when it comes to tasks (which are SMART by the way), then you don’t use story points.

I could go on and on, but you get the picture. What a mess. And this is supposed to be a lightweight process? COCOMO is easier than this stuff (just kidding). I’m not surprised that most people fall into the pit of despair before they can get their Hello, World user story ready (see cartoon above).

How did we get here?

Just as we get anywhere: One step at a time. You see, people mess up. So we add a couple of rules. But they still mess up, so we add a few more. But they still mess up, so we add a few more. But they still mess up. And this time its because they cant comprehend all those rules that were put in.

Why do we have all these rules?

A fragile process requires a perfect environment and perfect execution. Without that, it will fail. Worse, it fails much more spectacularly than whatever was done before it.

A forgiving process process works in a variety of different environments and execution skills, perhaps with a range of results, from mild improvement to much more radical improvement.

Unfortunately, most of the attention has focused on fixing the environment and execution instead of making the process more forgiving. So, an agile transition goes

1. Fix the organization
2. Follow all the steps of the process

There are a whole bunch of people who will validate whether the organization is ‘ready’ for agile. It is the spherical cow syndrome again.

Today you need a PhD to understand agile. Woe betide you should you fail to understand the difference between a complicated system and a complex system. What?? You don’t know the difference? No wonder your agile team failed!

Agile really IS simple

When you really think about it, agile is pretty straightforward. There are only two concepts to it.

1. Release a few features, get feedback, adjust accordingly
2. Improve your collaboration and communication

Thats it!

All those things like iterations and user stories and fibonacci story point estimates are nice, but you can be perfectly agile without them too.

Start where you are

So your first release is three months long. You’re release cycles are  not of the same duration. You don’t use user stories. Your features take three weeks to deliver. You don’t do TDD. The team isn’t colocated.

That’s okay. The main thing is to delivering once a quarter or less, and incorporate the feedback. Then, see what you can do to improve collaboration.

Some of the agile folks are going to laugh at you and your ‘agility’. Just ignore them.

Yes, some of these things do help, but you don’t need everything at once right from the start. All these things are just practices. You can implement them if you want to, or skip them if you don’t, or implement them later if thats better. For what it’s worth, I’m no longer a fan of user stories.

Start where you are.

You collect requirements a certain way? Just do the same thing. Estimate a certain way? Continue that. Then add or replace pieces one by one as you hit roadblocks.

It’s not the most efficient way of doing things, but it is the most forgiving.

Somewhere along the way, the whole agile movement got derailed.

One set of folks went into researching how the organization could be fixed.

Another set went off into adding more and more rules so that people wouldn’t shoot themselves in the foot.

All this has just made things much more complex (or is that complicated ). And the more complex something is, the harder it is to get right. It’s a positive feedback cycle.

Back to Basics

All the jargon is unnecessary.

You dont need a PhD to understand this agile stuff.

Feedback. Collaboration. Thats it.

It’s time to cut the agile crap and go back to the basics.

Over the last year we have gotten various feedback on the need to be able to assign a card to more than one user. In response to that request we had come up with the pair programming plugin for the Scrum and Kanban Boards. However this too did not satisfy a subset of our users who wanted more functionality. A typical case is when you are part of a cross functional team and a card would require to be worked on by atleast two or three people (lets say an analyst, a designer and a programmer, etc). It was hard for the Pair Programming plugin to support such scenarios and it was even harder to track user capacities with it.

So today, we take honour in introducing a new enhancement to ToolsForAgile.com, that will address this problem. We bring today, full and complete support for multi-user card assigns. You can from now on be able to assign a card to more than one team member, and the associated estimate and other card parameters will be shared by all  assigned team members.

Assigning to multiple users will also be a breeze. The Edit and Add Card Dialogs will have a much more intuitive select box from which you can select and deselect team members as you deem fit.

We would at this juncture like to point out to you that our old Pair Programming Plugin will be discontinued in favour of this new feature. We have ensured that your pair programming data have been migrated into the current enhancement. Here is hoping that this feature provides you with much more flexibility in project management, and much more accurate reports and data.

Do let us know if you like the feature. you can reach us at contact@silverstripesoftware.com

If you create large kanban boards or user story maps, then you’ve probably felt the need to sometimes take a screen capture of the whole board or map. Perhaps you want to email it to someone outside the tool. Or maybe you want to archive it somewhere.

The problem is that if you try to use the print screen feature, you’ll only capture a part of the content.

Fortunately, simple solutions exist in the form of browser add-ons. These add-ons support capturing the whole page, including the parts which are not visible on the screen. Here are three free extensions:

Firefox: ScreenGrab! for Firefox is a nifty add-on that saves the whole page as an image. You can save the whole page, or just the visible portion, or you can select the parts to save.

Google Chrome: Screen Capture is Google’s own free extension that allows you to save the whole page.

Internet Explorer: IE Screenshot Free allows you to capture the whole page and save it as a bitmap file.

Now you can easily save your whole story maps and kanban boards and create images like the ones below

Enjoy!

Silver Stories has been in beta for a while now. It’s now time to take it out of beta. Silver Stories will be out of beta from Monday, Oct 3.

What is Silver Stories?

Silver Stories is a tool for creating and visualising story maps. Story maps allow product and stakeholder teams to understand the scope of a project and the current progress against that scope. It allows projects with multiple teams to coordinate together better and improves communication and collaboration across multiple teams and stakeholders. Click here for more about Silver Stories.

Silver Stories Pricing

Silver Stories will follow the integrated pricing model of Silver Catalyst. Just like Silver Catalyst, it will not be priced per-user, but instead one credit per-story map board.

We have a handy price comparison calculator available to compare the per-board pricing model of Silver Stories with the per-user model used in most other tools.

Sign up for launch discounts

We will be distributing a launch discount code valid for one month. This code can be used with both Silver Stories as well as Silver Catalyst. To get this code, sign up for a trial before Oct 3.