Simplicity of Measure

October 18, 2014

Fitbit_Dashboard

I got a fitbit bracelet the other day. It’s a pretty nifty gadget. It tracks the number of steps that I take in a day, as well as measuring movement while I’m asleep. I’ve been very impressed with the number of things that you can derive from a simple measure of the frequency of movement. You get number of steps, activity level, calories burned, sleep periods, and a few other metrics. All of that from one simple measure of how often my hand moves.  Admittedly, some of those measures are inferred based on some simple assumptions like how many calories that the average person burns in a fixed period of time. However there is nothing wrong with that, The measure doesn’t have to be 100% accurate in order for it to be useful to me. I can see the trends and understand if my calories burned is changing for the better or for the worse without having the exact number of calories that I burn in an hour. An approximation is certainly sufficient.

It’s really quite impressive that you can derive so much from a single metric. It made me wonder about the metrics that we keep on Agile teams. Whether it’s velocity or throughput, there are metrics that we use for a lot of different purposes. We use velocity to tell us how much work the team can take on per sprint. We derive duration using velocity. I like the notion of having a small set of metrics like velocity that we can use for a variety of measures.

Advertisements

Using the Agile Cookie Cutter

August 2, 2008

How would you set up your next project? What would you require? I know what I’ve tried in the past – here’s a brief inventory of my standard Scrum Toolkit:

New Artifacts:

  • Team Working Agreement
  • Team Definition of Done
  • Task Board
  • Burn down chart
  • Impediments list
  • Release Plan
  • Backlog

New Meetings:

  • Sprint Planning
  • Daily Standup
  • Sprint Review
  • Sprint Retrospective
  • Backlog grooming

New Concepts:

  • Stories
  • Story points
  • Sprints
  • Releases
  • TDD
  • Continuous Integration
  • Cross Functional Teams

New Roles:

  • Team Members
  • Scrum Master
  • Product Owner

Boy, that’s a pretty long list of stuff. Looking at it, it sort of gives a guy cause to pause and wonder just how any team could absorb all of that. I guess that explains the deer-in-the-headlights look I get sometimes when I introduce teams to Agile processes. Do you need all of that to write good software?

This list is what I might call my “Agile Cookie Cutter”. It is the common set of ideas and practices that I try to role out with every team that I work with. But lately I’ve been thinking that slapping all this on a team all at once isn’t so smart. What I often see is teams going through the motions, adopting these practices whether or not they really need them. People get frustrated when they adopt processes wholesale and then run into problems with subsets of practices. What ever happened to gradually introducing practices and empirically testing their effectiveness?


Information Density and Project Tracking

May 29, 2008

One complaint that I hear from people who don’t like a given project tracking tool is that there is actually too much information on the screen at once. They find it distracting and it makes it hard to find the really relevant information. In response, usually I nod my head sagely, mumble something obscure, and move on.

But when I give my talk on the pros and cons of using physical vs. electronic project tracking tools I neglect to mention this difference. If I stop for a minute and take a good hard look at the task board our team is using right now, it doesn’t say a whole lot compared to the electronic tools we use. For one thing, the team and I keep a pretty sloppy task board. Stuff gets crossed out, notes are written in the margins, extra stickies are tacked on top of other stickies. We know what it all means, mostly, but I’m not sure that anyone else could easily parse it all out. There’s a lot written between the lines in both a literal and metaphorical sense.

On the other hand if I use my electronic tools, they pretty much force me into a much more orderly state. There is a lot of explicit information displayed – it takes a while to setup. But it’s neat and orderly. If I need to make notes, then I can put something in the “notes” field. Unfortunately the notes field is not normally displayed. I have to “open” a story to view the notes. Information is cleverly hidden. Like I said, it’s neat, it’s tidy, there is lots of information, but some parts are hidden.

Hmmm…Of course there is hidden information in my physical task board too. I have a confession to make: As a team, we’re pretty lazy – and proud of it. We’re firm believers in helping our environment by practicing the conservation of syllables. Why use two words when one will do? Mike Cohn said it best, The user story is a placeholder for a conversation. Amen brother! It’s remarkable how much we can read into so few words!

So both types of tools have their own forms of information density. And they both have different types of data that is “hidden”. Of course, I have more control over the physical taskboard than the electronic one. I’m pretty much forced to display certain data using electronic tools – even if it isn’t necessarily relevant to me. That’s probably where the information density argument comes in. I don’t mind information density if it is exactly the information that I want to see. However, if it’s not relevant to me, then it only serves as a visual impediment.

Something to keep in mind the next time you are tool shopping.


Agile Planning Tools Revisited

May 28, 2008

Since my last post listing Agile planning tools a few more have come to my attention including:

Check ’em out. Thanks to those who helped by pointing me toward these products – I appreciate it!

Happy Planning,
Tom


Agile Planning Tools

December 5, 2007

A few notes on this list:

I tried to collect just the tools that are written specifically for the purpose of Agile planning. I know that a lot of teams use 3×5 cards and/or Excel for tracking and managing their projects. However, although you can use Excel to manage your planning process, Excel was not created with Agile planning in mind. So Excel doesn’t belong on this list. There are plenty of planning products that make the claim of being compatible with Agile planning. For instance, Microsoft Project has a Scrum plug-in. But MS Project was never really intended to support Agile planning. And if I may be so bold, the support it does provide sucks. So I have left out products that are basically Gant charting tools that some might consider using for planning Agile projects.

This list is by no means comprehensive. If you are aware of additional products that I have missed, please let me know. So here they are in no particular order:

  1. Rally
  2. Scrumworks
  3. XPlanner
  4. Mingle
  5. VersionOne
  6. TargetProcess
  7. xProcess
  8. Extreme Planner
  9. ProjectCards
  10. CardMeeting
  11. XP Story Studio
  12. PlanningPoker
  13. Acunote
  14. SilverCatalyst
  15. PlanB

I learned a few things researching this list. First, everybody and their cat has a planning tool these days. It was only a few years ago that there were only a handful of products available if you were interested in a tool for planning Agile projects. Now they are a dime a dozen. It’s starting to look like a pretty competitive market. There still seems to be a healthy mix of open source and commercial applications, so alternatives are available to fit whatever budget you have (or don’t have).

I’ve provided some minimal information with each product so that you can investigate them yourself. For those of you who want the “Cliff’s Notes” summary, over the next few weeks my plan is to write reviews for these products. Some of them are products that I have used before quite extensively, others I will install and try out.

Stay tuned.


Rally vs. Scrumworks

December 4, 2007

My first impression is that these are two applications that have come from very different backgrounds. ScrumWorks started off as a java based desktop application. Rally is based on an ASP model where the application and data are all hosted at a remote site. Both applications have grown their feature sets over the last two years with what appears to be 2 different objectives in mind. Rally has taken the approach of adapting to a wide range of customer needs, both Agile and traditional. Their goal seems to be to reach the high end customer and integrate with existing high end systems on the market. Their feature set is very broad and has been adapted to fit in a variety of different scenarios. In addition, Rally has also significantly beefed up their integration support in the last two years. There is no doubt in my mind that when it comes to integration and customization, Rally is the clear winner.

ScrumWorks, on the other hand, has kept focused on a goal of serving just the Scrum and XP community. As a result, they have a much narrower feature set that is easier for the typical Agile team to understand. This is just speculation on my part, but I think it doesn’t require as much training to use ScrumWorks. I would describe the ScrumWorks product as more fit for a specific use – in this case for Scrum and XP projects.

In general, when it comes to ease of use, ScrumWorks benefits from the fact that it has a thick client that can take advantage of OS features that web based applications can’t do quite as easily (Drag and Drop, etc.). So in terms of usability, ScrumWorks is currently the clear winner. However, Rally is not resting on their laurels, and they are implementing new usability enhancements that will quickly come to rival those of ScrumWorks in short order.

When we look at reporting functionality, ScrumWorks comes out ahead. ScrumWorks has a custom report generator utility that allows you to create your own customized reports. All of Rally’s reports are fixed and can’t be changed or added to. Once again, Rally is acutely aware of this issue and not likely to let it rest for long.

Cross Team & Program Management – Both products claim to have some cross team and program management features. Neither product really possesses a strong feature set in this domain. Rally defines a program as a combination of a specified product and a specified release – a very loose definition. ScrumWorks uses a separate mechanism that is completely orthogonal to the Stories and releases – instead you can create arbitrary groupings of features which can represent programs. This is a more flexible approach, but it still doesn’t provide the financial tracking features that I would expect from a full fledged portfolio management tool.

Detailed Feature Comparison

Feature

Rally

ScrumWorks Pro

Desktop (Fat) Client

No

Yes

Web (Thin) Client

Yes

Yes – Not all desktop features are available on the web client

Local Database

No – hosted by a 3rd party

Yes – Built into the default installation

Impediments Log

No

Yes – Tracks dates, resolution, and responsibility

Records blocking issues

Yes

Yes

Burn Down Charts

Yes – Sprint Burndown/Cumulative flow, Release burndown/cumulative flow, Bug & Test Tracking

Yes – Mike Cohn style ‘enhanced burndown’, Sprint & Release burndown

Customized Reports

No

Yes – Customizable report builder GUI

ROI and EVA

No

Yes

Time Tracking

Yes – optional

Yes – optional, but supported with custom reports

Supported Object Types

Release, Sprint, Story, Task, Test, Program, Defect, Defect Suite

Release, Sprint, Story, Task, Theme, Program

Supported Methodologies

RUP, Scrum, XP

Scrum, XP

Drag n’ Drop UI

Limited to certain screens

Used almost universally

Hierarchical Relationships

Yes

No – Uses themes instead

Built in collaboration features

Yes – Wiki & IM integration

No

Test management

Yes

No

Defect management

Yes

No

Program Management Features

Release Status – not really configurable

Release Status + configurable feature sets, Good cross product functionality

Sprint Task Tracking

Yes

Yes – nice web based task board UI

Assign Business Value

No

Yes

Product and Role based permissions

Yes

Yes

LDAP Integration

No

Yes

Import/Export

Yes – Excel, XML

Yes – Excel

Supports Use Cases/Non-functional requirements

Yes

No

Notifications

Yes – RSS, email

No

Detailed Change History

Yes

No – very superficial

Product Integration

Eclipse, Mercury, Salesforce, Bugzilla

Bugzilla, JIRA

Pricing

$65/person/month

$249/person/year ($21/month)

Admin functions

User accounts, Roles, Custom features, Workspace management

User accounts, Roles

Hardware Requirements

None – externally hosted

Server must be allocated for clients & web app to connect with

Frequency of Updates

Quarterly

Quarterly

Built-in Support for pairing time management

No

Yes – There are “Team hours” and “individual hours”

Usability for teams

OK, some complain of delays and there are complaints about charts

Good, The thick client offers more natural DnD style of interface – good web interface for task board – natural for teams to adopt

Multiple Teams/Common Backlog

Possible, but awkward

Pretty well thought out

Support

Online, Forums, Coaching, Training

Online, Forums

Integration Technical Options

REST, SOAP, Others

SOAP


Task Boards: Telling a Compelling Agile Story

November 24, 2007

The task board is the single most important information radiator that an agile team has. A task board illustrates the progress that an agile team is making in achieving their sprint goals. Usually the task board is located in an area that is central to the team. For example, it’s in their work area or in the war room where they hold their stand-up meetings. I would maintain that the task board is an expression of the personality of the team. Some teams operate in a very minimalist style – only the most essential information is displayed. Other teams are quite disciplined. Everything is neatly laid out and you can get a very clear picture of the product that they are working on. From what I have seen, every task board is unique. It’s interesting to look at the different kinds of task boards that teams use, and compare and contrast the differences.

A Survey of Task Boards

Out in the “wild” there are many different examples of what a task board looks like. For example, this one uses a corkboard and three by five cards. One way to improve this task board would be to add a burn down chart. Then you not only see the status of the tasks being worked on, but you also see the burn down information which provides a overview of the progress that the team is making on the tasks for that sprint.

Coarkboard

Figure 1 – The Corkboard Task Board

Below is a rather more elegant version of a task board. I call it the “Beautiful Mind” task board. We just took some of that blue masking tape used for house painting and laid out the task chart directly on the window. Post-Its were used for everything else. It was located in an office building where there were many windows, but not very many walls. It was sort of a “low impact” solution. This demonstrates that with a little imagination you can create a task board just about anywhere.

Beautiful Mind

Figure 2 – The “Beautiful Mind” Task Board

It also makes you look smart if you stand next to it and gesticulate.

Here are a couple more examples of some task boards that we have seen “out in the wild”.

3 by 5 Cards

Figure 3 – The Minimalist Task Board

This one is just 3 by 5 cards taped on the wall. The yellow cards indicate the stories and the teal cards indicate the tasks. Task progress and status is indicated by putting little stickers on the cards and updating the hours remaining. Again, we see the burn down charts displayed prominently next to our task board.

Now we venture into the den of our very own CTO, Brent Barton! I wonder what he does?

Brent’s Board

Figure 4 – Our CTO’s Task Board

It seems that he prefers the “Beautiful Mind” style of task board. Very interesting! Again, it has the same columns that I described above. The interesting thing about this task board is that it is used just for tracking the work that Brent does. So, a task board can be applied not only to a team, but also to the work of an individual (especially one as busy as Brent). We should leave now before he wakes up…

Now I would like to share a rather unique idea for a task board that I was introduced to the other day:

Laminated Poster

Figure 5 – A Laminated Poster Task Board

This is a laminated poster that was created a team member with an innovative streak! He’s done a great job of standardizing the information and making it easy for people to update. It’s organized a little bit differently than the other task boards that I have shown you. There are some little bits that I might change, but I love the idea in general. I’ve seen a few more of these posters springing up lately, so maybe they’re catching on.

Here is another example of a printed poster that was used as a task board:

Excel Spreadsheet

Figure 6 – Excel Spreadsheet Task Board

This is just based on a printout of an excel spreadsheet. That certainly makes it easy. Just print it out and fill in the blanks.

So What’s in a Task Board?

These are just few examples of task boards in the real world that many of our customers use to track their sprint progress. All of these task boards have a few simple things in common:

1) 4 basic columns (there can be more)

a. Stories

b. To Do

c. In Process (In progress, WIP, etc.)

d. Complete (Completed, Done, etc.)

2) A Row for each story

A task board is really just a glorified swim lane diagram. I wonder what Edward Tufte (The data visualization genius, http://www.edwardtufte.com/tufte/index) would have to say about task boards? I bet he would like them. So if we are going to toss together a basic task board, then we need to take the ingredients above and find a little wall (or window) space to work with. The layout is very straightforward. Here is a simple diagram to illustrate this:

Simple task board

On the left, you have a list of the stories that you are working on for the sprint. In the next column, “To Do”, you have the tasks necessary to complete the story. You move the tasks from “To Do” into the “In-Process” column while you are working on them. When you are done, you move the task from “In-Process” to “Complete”. It’s really pretty simple.

Transitions

You can also do a more complicated version that looks something like this:

Taskboard

Notice that there are some extra columns in this one: Tests Ready and Hours. Test Ready indicates that the acceptance tests for this story are ready. This serves as a sort of gate that prevents work from moving forward on a story until the acceptance tests have been written. Having the hours remaining summarized at the end of the row just makes it easier for the team to keep track of time remaining for that story. Combine the hours remaining with a burndown chart and you will find that the chart gets to be very easy to update.

Electronic Task Boards

So, by now it should be clear that there are many different types of task board a team can easily create. They work great for people who are all co-located, but you might ask, “What about people who aren’t located in the same room as the team?”

Well, I’m glad you asked!

There are many tools out there that provide electronic versions of team task boards. One that I’m very familiar with is Rally. It gives a nice detailed summary of the stories and tasks that a team is working on in a sprint. It tracks time remaining, who’s responsible for the task, and what state the task is in (Defined, In-Progress, Complete). It has nice reports and burn down charts. In fact, some teams that I work with will display the burn down chart on a monitor above their desks so that the whole team can see the current burn down status. Good idea!

Rally

Figure 7 – Rally Task Board

As you can see, there is a lot of information on display here. In this view, Rally displays a hierarchical list of stories and their associated tasks for a given sprint. However, instead of moving tasks from column to column like we have seen in previous examples, Rally uses icons to indicate the current state of each work item (‘D’ for Defined, ‘P’ for In Progress, ‘C’ for Complete, and ‘A’ for Accepted).

Perhaps a web-based tool like Rally isn’t what you are looking for. Then perhaps you might consider looking at a tool like ScrumWorks. Their product has been around for a long time and continues to evolve in interesting ways. Again, ScrumWorks provides an information rich display of the current stories and tasks for a sprint. Overall, the Scrumworks interface is somewhat cleaner and simpler than the Rally interface. You aren’t plagued with a host of different tabs and options on each screen. Everything is pretty straightforward and simple to use.

Scrumworks

Figure 8 – ScrumWorks Task Board

The ScrumWorks display shows us the list of stories and tasks and that’s just about it. They don’t overwhelm you with multiple columns of information like other products do. However, there is no real analog to a task board here.

Just when I thought I understood all the players in this domain, our friends at ThoughtWorks brought their own product to the playground. The new kid on the block is Mingle. Mingle is based on a very flexible, wiki style platform. I haven’t had as much experience using it as I have with the other two products, but it looks like it’s going to give folks like Rally and ScrumWorks a real run for their money. The UI is clean and the product seems to allow a nearly endless variety of configuration options.

Mingle

Figure 9 – Mingle Task Board

So there we have a few of the electronic tools for task board management that are available out there. Most of my software friends run straight to the electronic tools like moths toward a bug zapper. I’ve done it myself – I’ve got the scars to show for it. The fact is that electronic tools have their uses, but they are not a good substitute for a nice tangible task board that a team can stand up in front of and work with together. Online tools seem to keep people in isolation. Everyone at his or her own desk, staring at the screen – that’s just not agile. I prefer to have the team working with a real physical entity that they can manipulate, edit, whatever. The quality of interaction is much higher.

In addition, electronic tools tend to hide information. They tend to make things less transparent rather than the other way around. If I walk into a team’s work area and they have no task board, then there is no way for me to quickly assess how they are doing. For a team member, the information is gone the minute I switch to any other activity on my computer. The information remains hidden until I select the tool again.

If you have a customer that can’t see your task board (as is often the case), then using an electronic tool makes a lot of sense. The same applies to working with distributed teams. However, use the electronic tools as a supplement, rather than as a replacement for the physical task board.

Let’s Review

Here’s a radical idea: Maybe we should be thinking of a task board as a recruiting tool. We should be showing off the cool stories that we are working on. They should be compelling enough that people passing by might take interest in them. They might stop, look, and think to themselves, “I would like to be a part of that…” Perhaps they might pass by, stop dead in their tracks and say, “No, no, no! I have a better idea!” Task boards should tell us all how the project is going. They are something to be proud of. A team slogging through incredible obstacles could show off the stories that they’ve accomplished like tattoos on the arm of a war veteran.

Task boards should be vivid illustrations of the achievements of a team. They should present a compelling picture of the challenge the team has undertaken. Along with a vision statement, they should draw us in. Like the TV commercials, they say this is where “The Few, the Proud, the Daring” will go. Give me an audacious goal, a compelling story to get there, and I will sign up in a heartbeat.

I can imagine walking through team workspaces and reading the task boards for each team. Some may have stories for teams that are just getting started and looking for new team members. Exciting stories full of promise. Others might reflect the work of projects that have been in progress for months or years, representing a tale of the battles that our grizzled IT veterans have fought and won – their challenges and triumphs. As I walk around the company, the task boards should reflect the nature of the work that each group is doing. Maybe I see financial projects near the CFO’s office. Perhaps corporate initiatives are tracked near CIO’s office. I bet there would be some exciting stuff up there.

When I think of the task boards, they remind me of those thermometers that HR puts up when we are doing a food drive. There is some compelling goal or vision (feed the homeless, toys for tots), and a big visible indicator of how close we are to achieving that goal. We need more of those. Make people want to work on your team – take the time to make your task board tell a compelling story.