A lot of people doing agile want to use an agile tool for a vague notion of “tracking stuff”.

They assume

• That their execution will somehow be more “efficient” if a tool is used
• That by spending a little bit (or lot) of money, it can replace the time and hard work required to get agile to work
• That they can forget about process and do some other work

Well, if these are the reasons for using a tool, then I can confidently predict right now that your tool investment will fail.

There are many, many valid reasons to use a tool – where the tool can make a difference you could not do without it. But let’s be clear – all these reasons depend on your individual context, they do not universally apply for every team. Which is why you need to think carefully about your needs in a tool.

A tool is extremely valuable when

• You have distributed teams and you are finding it difficult to keep in sync
• You want to involve customers, stakeholders or management and they are not in the room with you
• You would like historical data or archival records of all the past actions in the project
• You need to keep a record of data for compliance purposes
• You want to calculate certain metrics every day and it is too time consuming to do it by hand
• You need to coordinate multiple teams together

If you don’t have a clear picture of why exactly you need a tool, and all you know is that you want to “track stuff” (why?) then you are throwing money down the drain.

Finally, take a look at the Physical board vs Electronic board debate and weigh the pro and con of each approach for your context.

Yesterday I gave 5 reasons why physical boards are better than electronic boards.

But could an electronic board be better than a physical board? Sure.

Here are five reasons why:

1. Collaborate with distributed teams: Lets face it. A large number of teams are globally distributed. Either the teams are split between locations, or there are multiple teams in different locations, or the management, stakeholders or customer is not co-located, or some team members sometimes work from home. Every which way, there are some people who need to know whats happening who aren’t going to be in the proximity of the physical board. Electronic boards are accessible from anywhere, giving remote teams and stakeholders the visibility needed to collaborate effectively.
2. Ease of modification: This is a funny one, because we tend to assume that its easier to modify a physical board. Actually, it can be a lot easier to change the structure of an electronic board. Want to add a column to your physical board? You’ll need to take down all the cards in that area of the board. Then peel off the existing column markers. Stick new column markers. If you are running out of space, then create some space by reducing the width of the adjacent columns. Finally stick back all the cards you took out. Keep aside 30-60 minutes to do this. With an electronic board, you just go to the board configuration screen, add the column and you’re done.
3. You never run out of wall space: Unless you are lucky enough to have a large section of wall available, chances are that you have limited wall space. This is even more true if there are two or three teams competing for the space. If you are on a big project with lots of cards, its easy for the board to get cluttered – cards overlapping one another, cutting across column boundaries, falling behind tables. And once that happens, you lose the benefits of visualisation. The second problem is if you need to make the cards too small, then you have to get really close to read them. And if you make them bigger, then you need more wall space. An additional downside is that you also need to stand further back to see the whole board, so you need sufficient depth in the room. It’s very hard to find that balance of being able to see the whole board at once, and yet being able to read all the cards. With electronic boards, this is not an issue. You have infinite wall space, its easy to quickly zoom in and out and its quite practical to be able to view the whole board and still be able to read all the cards.
4. Eliminate overheads: With physical boards, you need to spend a lot of time doing low value clerical work. Want to generate a burndown or cumulative flow graph? You’ll need to spend 15 mins a day counting up the cards and plotting it on a chart. Need to calculate lead time or throughput? More manual work. Management needs status reports daily? Still more work to get to the board and make notes and send an email. Every day!! Even if you only spend an hour a day on this low value work, thats 12.5% of your time. If you are a project manager earning $10K a month, then it means the organization is spending $1250 per month to do this counting work. An electronic tool will do all of this automatically – collecting metrics, making graphs and emailing reports – leaving you free to do more important high value work, like delivering that project.
5. Go beyond a single team: Physical boards are okay for single teams, but when you go beyond a team then the physical board does not have the context. Want to see the flow of work across multiple teams involved in delivery? You’re out of luck. Want to update the backlog everyday with support tickets filed by customers online? Out of luck again. You have to sit and manually copy the tickets from the ticket system and put them on cards. When data is stored electronically, you can write scripts to process and manipulate the data automatically as per your needs. For example, you can use APIs to automatically pull in data from multiple boards and display it in a particular visualisation. Or to synchronize support tickets with the backlog. The possibilities are endless.

So there you have it. Five reasons why electronic boards are better than physical boards. Comments?

People often ask whether it is better to use a physical board or an electronic board. The answer of course is that it depends. What is the context of the team and the project? How many team members? Are you distributed? and so on.

In this post, I’ll talk about five reasons why physical boards are better than electronic boards. Tomorrow, I’ll do the opposite, with five reasons why electronic boards are better than physical boards. Finally I’ll do a post on how to choose between the two.

Are you ready? Here we go:

1. Physical boards are always visible: You put it up on the wall and its always visible from anywhere. At any time, you can just lift your head and know the latest state of the board. Anybody walking by will peek in and get an idea of the board.
2. Physical boards are tactile: There is something about picking up cards and moving them that is nice and makes team members feel more involved. I don’t know what it is, but it works.
3. They encourage conversation: When someone is walking by and sees the board, they tend to ask questions about it and it builds a conversation.
4. They are flexible: You can easily make the physical board in any form you want. Need extra columns? Need a completely custom board design? Want to decorate the card with stickers to denote different conditions? Want to annotate it with custom information? Want to write on the back of the card? You can do all of that.
5. They are simple and intuitive: Everyone knows how to use a physical board. You don’t need one week of training to figure out how to put a card on the board

There you have it – 5 reasons to prefer a physical board.

A lot of emphasis in software development process is placed on project management – making a commitment, planning, and tracking everything so you ensure you don’t drift away from the plan. Funnily enough, many agile projects have also ended up with this ‘form’ of project management.

And don’t get me wrong, it is important not to screw up!

But, in the worry not to screw up, are we losing sight of the opportunity to get better? Do we understand what we are building? Do we know where our bottlenecks are? Are we best aligned to business needs?

So here we go – the showdown between Project Management and Project Intelligence:

One of the core goals of Enterprise Kanban is to effectively link business with development teams, and to do this across multiple teams, stakeholders and initiatives. This alignment is hard to do, and that is where bigger picture techniques come into play. Some of these techniques are

• Using Story Maps to effectively translate between high level activities/objectives to low level stories
• Using multi-tier kanban to manage feature flow at different levels of abstraction
• Using multi-team kanban to coordinate features that cut across different teams
• Using class of service to align development workflow with business needs
• Using a risk oriented view to manage backlogs (1, 2, 3)

Silver Stories is a product and portfolio management tool that enables you to apply these higher level concepts across multiple scrum or kanban teams.

Webinar

For this month’s webinar, we are going to do a free, early access demo that shows these concepts in action. Register for the Silver Stories demo here. The demo is on Wednesday, 23rd March at 10:30 PM IST (see time in other timezones)

An extremely funny cartoon courtesy the folks at Geek and Poke. Though the joke is on MS Project, the same could be said of many agile project management tools too. Is your team a slave to a tool?

If you look around the agile project management tools landscape – and it is now a rather big landscape – you’ll notice something strikingly odd. What I’m talking about is the pricing model for most of these tools. Almost all the tools follow a per-user pricing model. In other words, if you add more users into the system, the cost goes up.

Why is this odd? Because the primary purpose of an agile or scrum project management tool is to increase visibility through the organisation. But per-user pricing actually does the opposite – it encourages companies to reduce the number of users who have accounts in the tool.

Companies know that they need to pay for every single person that gets added in. The natural response is to figure out the absolute minimum number of people who need to be involved in the tool. Everyone else gets information outside the tool through emails or meetings.

At the extreme end, you could have a situation where a few users proxy the entire team – one account for all stakeholders to use,  one for all the testers and so on – all to reduce the number of live accounts in the system.

I understand the need for agile tool vendors to scale the pricing as usage increases. After all, we are an agile tool company too. But the per-user model is actively harmful for agile teams.

There are other ways to scale pricing.

A per-project pricing model is one of them. That’s what we decided to use for Silver Catalyst. We wanted a situation where teams could add users to the system without thinking twice about it

Another model is to charge extra for additional features. Many of the larger vendors do this too in the form of different editions aimed at small teams and large enterprises. We do this through hosted and on-site versions.

These and many other models are fine for agile teams. But per-user pricing can cause side effects that are especially bad for agile teams.

A new release! SilverMock is a python mock object library that was developed for internal use at Silver Stripe Software. It is now being released under the MIT License. If you are looking for a simple, lightweight mock object library for Python, then check out SilverMock.

I first did a demo of SilverMock during the 2nd Chennai Agile User Group meet earlier this month to demonstrate writing unit tests with mock objects. In the discussion, we though it might be useful to create a screencast of the demo. While preparing the screencast, I though why not release SilverMock under an open source license? So thats where we are now.

If you go to the SilverMock page, you’ll find the first part of the screencast showing how you can use mock objects during unit tests. Since the screencast uses SilverMock, it doubles up as a bit of documentation as well

The idea behind SilverMock is to make mock objects as simple as possible. The whole library is under 200 lines of python code (under 400 is you include the unit tests), so it’s very lightweight. The API is as straighforward and readable as it gets. IMHO, you read a line like ShouldBeCalled(“count”).with_args((“abcd”,)).and_return(4) and you immediately know what is expected to happen. If you find all this intriguing, then head over to the SilverMock page, where you can download SilverMock, check out the screencast and see an example of a typical unit test that uses SilverMock. Hope you find it useful!

A new version of Silver Catalyst has been released. The latest version is now v1.3. Get the latest release from the download page. A free 3 team member version is available from the download page, while paid members can upgrade their installation of Silver Catalyst to this version for free.

The main feature addition is this version is support for CSV import and export. Most popular spreadsheet programs allow you to save and load data in this format, so the new feature allows you to import your spreadsheet data into Silver Catalyst, or export project data into the spreadsheet. This feature is especially useful if you are currently using a spreadsheet to manage your agile project and you want to move the data over to Silver Catalyst.

To import data from Microsoft Excel, create a spreadsheet with a column containing task descriptions, and optionally, the priority, person assigned to, estimate, status and notes. Save this file in the Unicode Text format and upload the saved file through the CSV Import/Export plugin (Click the Excel icon next to the project name). If you use OpenOffice Calc you will need to save the data in Text CSV format.

Version 1.3 also contains a number of UI enhancements. The status update area has been made more prominent and there is more feedback when submitting forms and editing tasks.

Check it out. Download Silver Catalyst v1.3 and see how you like the new enhancements.

I’ve said before that more than practices or techniques, agile is often about a mindset. It is about understanding the values and principles behind the practices that really enable you to be ‘agile’.

I often discuss Silver Catalyst with managers who are interested in an agile tool, and often there are some feature requests. Some feature requests are holes in the functionality of the tool and these are carefully noted down and scheduled for a future release. Some features, however, stem from bringing in a traditional mindset to an agile project.

The agile mindset

For example, in Silver Catalyst, any team member who is a part of a project can edit a task. I’m often asked why Silver Catalyst does not have a fine grained authorisation system when each individual can only edit their own tasks.

This kind of thinking is common among traditional managers who have moved into agile. In their old process, it would be the responsibility of the project manager to create, schedule and estimate tasks, and the team members would do their work and update their tasks. So this is the model that they are used to.

In an agile process, it is the team members themselves who take responsibility for the tasks. They create and schedule and estimate the tasks. As they perform work, the team as a unit updates the tasks. The team works together. Agile processes change the individual-centric view, replacing it with a team-centric view. The team is a single unit.

Let us say someone is ill and takes a day off. In an agile team, someone else might well step in and complete the task. In such a scenario, it makes sense for the other team member to edit the task that was assigned to the original team member. But you can’t do that if you have a system where team members can only edit their own tasks. The team as a unit is a powerful concept, and a core concept of agile.

Talking through the tool

Another feature request that is often asked is for what I call “talking through the tool.” For example asking team members to enter a reason when a task estimate is changed so that the project manager can view it later.

Agile processes encourage communication between all the team members and stakeholders. A scrum project provides two avenues for such interaction — the daily standup meeting and the iteration retrospective. Most agile projects have equivalents. If something unexpected happens, a team member can bring it up at these points. So agile processes already have techniques in place where problems can be brought up and discussed.

Therefore adding such a feature to a tool encourages teams to “communicate through the tool” rather than communicating directly, which in turn reduces the quality of communication.

Tracking and controlling

I’ve said it before — an agile tool is a communication tool, not a tracking and controlling tool. This is critical. What Silver Catalyst aims to do is to improve visibility and communication among distributed teams and stakeholders. Managers sometimes ask me about features through which they can control the team — the individual history of a particular team member for example. It is really important for the success of an agile project that the team be allowed to self organise. Micro-tracking of the project by the project manager can often be counter productive.

Silver Catalyst

As far as Silver Catalyst is concerned, I am pretty clear that the tool is there to support the team and process. Unlike traditional processes where the tool is front and center and in many ways the enforcer of the process, in agile processes the team is the core, supported by the process and the tool. Thats the role that Silver Catalyst is designed to fill.