I facilitated a discussion on “Agile in the Indian context” at the AgileNCR conference a few weeks ago. The image below is a mindmap of the discussion.

If you look at the mindmap you’ll see that only a few of the challenges are specific to Indian contexts (specifically the bit on service companies). Most are universal across the world.

What challenges did you face when adopting agile? What did you do about them?

(Click the image to view the map in full size)

One of the really nice things with physical cards is that you can easily annotate it with stickies and other things such that the story card conveys a huge amount of information right at a glance.

For instance, lets say that one feature requires having a conversation with Bill. This is not a formal task that you want to track, but its just a kind of ad-hoc reminder on something that needs to be done.

Doing this with physical cards is easy! Just take a small sticky, write “Talk to Bill” on it and slap it on the story card. Done!

You’ll never forget with the sticky right there on the card. When you’re done, take out the sticky, tear it up and throw it away.

This simple operation can become extremely complicated with an electronic tool.

That’s the kind of problem we always grapple with.

How can we make the board as simple, visible and flexible as a physical board, but retain all the functionality that electronic tools excel at?

Creating Ad-hoc notes in Silver Catalyst

So here is how you can create ad-hoc notes in Silver Catalyst and get them to display on the card in the board.

It’s very simple really.

Just go to the project settings and add a new custom field as shown below. Lets call this field ‘notes’. Set the type to text.

And…you’re done!

Now if you fill up this notes field, it will appear on the card on the board. Just like the image below.

Wasn’t that simple?

Over the last few months I’ve noticed one anti-pattern come up again and again. This anti-pattern is very common in the agile community, but now its jumped over to kanban as well. It’s the dreaded local optimization.

Here is how the pattern goes

• Someone in an organization learns about Kanban (assume its the test lead)
• The person gets excited and decides to apply it to her work
• She looks at her workflow and maps it out to columns
• Kanban is used to track the flow of work through the workflow

Assume that the kanban board looks something like this

The flow of work is mapped out, bottlenecks identified, the cycle time for testing is tracked and the process is improved.

All is good.

No! No! No!

This is a classic local optimization. All you’ve done is to optimise the testing process alone. But does that add value?

I recently has a problem with my laptop. The service guy came over to my office and replaced my hard disk. Took 15 minutes. Then he called up the service center and called another person to come to install the operating system. This person came a week later, and took another 15 minutes to install it.

So, whats the cycle time? To me, it was a week. That’s the time since they started fixing the problem to the time when it was actually fixed.

The way the company tracked it, the average cycle time per ticket is only 15 minutes. Service people are encouraged to cut the cycle time by scheduling more tickets of shorter duration each. Instead of taking 30 minutes and fixing everything, they preferred to have 2 tickets of 15 minutes scheduled a week apart. That’s because cycle time is tracked on ticket time, not value delivery. For the customer it means 1 week to get a problem fixed instead of 30 minutes.

Go a level higher

The Kanban board should represent the value stream, not workflow. Subtle difference: A value stream, represents the flow of value from when some value was requested to when the value was delivered. A workflow is just a sequence of steps.

If you don’t map out the whole value stream, you are likely to end up in local optimizations.

You’ll never identify this problem if the Kanban board just maps one tiny bit of the value stream. Maybe the problem is elsewhere and you’re just wasting your time optimizing something irrelevant. Worse, maybe your optimization is counterproductive to the actual value being delivered.

The solution is to go a level higher. This is a better board:

I’ve simplified the value stream to just 3 steps for the purpose of illustration. This board tracks from when a story is not started to when it was released. If it isn’t released, it hasn’t added value, simple as that. Teams that take a day to build and test a story, but release once a quarter have a cycle time of 3 months, not 1 day. Now you start to see the real picture.

This is a good start, but it’s not enough.

Go a level higher (again)

Building and releasing features is well and good, but are they delivering value? A team could efficiently deliver a stream of useless features with a one week cycle time and not add any value. From a stakeholder perspective feature are just features. Value is delivered only when a higher level goal is met – perhaps some strategic direction is enabled, or new sales are made, or new markets are opened. Having a great cycle time on feature delivery is nice, but its a local optimization.

Lets go a level higher:

Now we see the real picture. This is the real value stream (simplified of course). Now we can see bottlenecks in the whole process. Maybe the goal was not satisfied because we developed the wrong features. Maybe the marketing needs some tweaking. Maybe the first sales approach didn’t work and a new approach is needed. Whatever the case, the cycle time clock is ticking on until the value is delivered.

The real cycle time

• If it takes one hour to test a feature, but a year to deliver value to the business, the cycle time is one year
• If it takes one day to build and test a feature, but a year to deliver value to the business, the cycle time is one year
• If it takes one month to decide on a feature set, build and test the features, but a year to deliver value to the business, the cycle time is one year
• If it takes one quarter to make a release from start to end, but a year to deliver value to the business, the cycle time is one year
• If it takes six months to go from idea to released to marketing ready, but a year to deliver value to the business, the cycle time is one year
• If it takes a year to get from deciding on a goal to achieving it,the cycle time is one year

How well can the organization go from goal creation to goal satisfaction? That’s when value is delivered. That’s the real cycle time.

If you are not mapping out the real, end-to-end value stream, chances are high that you are optimizing locally!

This is a mindmap from Hedwig Baars’ session at AgileNCR titled “How to screw up agile”.

(Click to view in full size)

In the previous post I asked whether project managers can debug the process when something doesn’t work. But how do you debug the process?

Before you can debug the process, you need to understand the underlying ‘laws’ of the process. By laws I don’t mean physical equations that you can solve to get an accurate answer. Rather, it is understanding the factors that affect software development, so that when something happens you can understand what needs to be changed.  Without understanding the laws, you will resort to fixing the symptoms of the problem based on a partial (or incorrect) understanding.

This is much like giving ice to a patient with fever. Does the problem go away? No. It remains, or even gets worse.

The root cause needs to be addressed, but you can only do that if you understand the underlying cause.

Every software developer knows how to debug code. When something goes wrong they can figure out what the problem is. Once the problem has been identified, they can figure out how to fix it. (In most cases.)

Would you hire a developer who didn’t know how to debug and fix code? I’m guessing not.

Yet, its surprising how many project managers don’t know how to debug the software development process. When the project runs into trouble, how many PMs can identify what the problem is? Not many. And how many can fix the broken process? Even fewer.

Its no surprise then that most PMs resort to two popular responses when the project is in trouble – adding more people, or getting people to work overtime. Does that fix anything? No. But PMs who can’t debug their process can’t do anything else.

Do you know how to debug your process?

Agile teams that make releases to production every few weeks are likely to have a substantial portion of project with new product development on upcoming stories running in parallel with maintenance stories from previous releases. This is unlike traditional processes where maintenance only starts at the end of product development.

Therefore it is all the more important for agile teams to be able to effectively manage both new product and maintenance together. This set of slides shows different ways to do that:

Agile Techniques for Managing Work Items

View more presentations from Siddhi.

1. Have a single backlog

This technique involves having a single backlog containing both new feature stories as well as bugs and support stories. The whole list is prioritized and the team works from the top of the list. To do this effectively the product owner needs to have the knowledge to decide on the tradeoffs involved in prioritizing the list. For instance, the PO should be able to understand whether a refactoring is important or not, whether a bug is critical or not.

2. Have multiple prioritized lists

Usually the PO only understands the the new feature perspective and may not be able to effectively decide where a particular bug or refactoring should be prioritized with respect to new features. In this case it is better to have multiple prioritized lists, each list maintained by a person who understands that perspective. The bug list may be maintained by the test lead who understands which bugs are most important to be fixed. The refactoring list may be maintained by a dev lead and so on.  All these people would be a part of a product owner team.

Each list is prioritized by the person who maintains the list. At the time of sprint planning (or if you are doing kanban, then when starting to pull to the backlog) the maintainers of each list get together and discuss the top few items from each list, which are then combined into a small backlog to support one or two upcoming sprints.

3a. Allocate capacity by time

In this method you maintain independent lists and divide up the capacity to handle each one. For example, the team may decide to spend one day a week on bugfixes, one day on technical stories and three days on new features. This method is fairly simple, but also suffers from the problem that you may end up doing low priority new feature at the expense on a high priority bug fix and vice versa.

3b. Allocate capacity by sprint

An alternate method of the same technique is to allocate capacity by iteration. For example, two iterations of new feature development followed by one “hardening iteration” of only bug fixes. This is generally a method to be avoided for a couple of reasons. The first is that is delays even critical bugs. The second is that it compromises the ability to keep the software ‘potentially releasable’. Finally it can lead to a waterfall mindset where you do a certain amount of feature development followed by bug fixes.

4. Always fix bugs first

This strategy is popular with zero-defect teams. The problem with this is that you may end up fixing a number of low priority bugs when you could instead be working on an important new feature.

5. Have a separate team

The worst solution of the lot for the reasons mentioned in the previous post, but perhaps the easiest for an organization that is not used to combining new development and maintenance. Simply maintain separate teams to handle each type of story.

Comparision between the techniques

A single prioritized backlog is the best solution with a knowledgeable PO who understands all aspects of the project. Otherwise multiple prioritized lists are a good option.

What do you think? Are there any other techniques that you use? Do post in the comments below.

A question that comes up once in a while when addressing team composition is whether to have separate product and maintenance teams or merge them into a single team.

Traditionally organizations have had separate teams. The common pattern is for the main team to deliver the product over a period of a few months (or years). Once they are done, they move on to the next product, and any support issues, bug fixes and enhancements are handled by a separate maintenance team.

The two teams are staffed differently, with the product team composed of the better developers and designers, while the maintenance team is usually staffed with junior developers or the second line of developers.

Recently however, there has been a movement towards the same team doing both product development as well as maintenance. This is more prevalent in agile teams where, due to early releases, there are maintenance tasks right from the first sprint itself. Thus, new feature development and maintenance proceed in parallel for a major duration of the project.

In this post, I’ll take a look at some of the factors in both approaches.

Differences in Skill Requirements

The biggest reason for separating the teams is the belief that new development requires greater levels of skill than maintenance does. The idea is that new development requires you to create something which calls for design and technical ability, whereas maintenance is just a matter of fixing a few bugs here and there.

Thus, teams staff the best people in the product team, and keep the junior or second level of developers in the maintenance team.

However, as Robert Glass points out in his book Facts and Fallacies of Software Engineering, this assumption is not true. He points out that maintenance is often the trickiest part of software development as you need to understand the existing design. It is a magnitude harder to understand the code and design when you were not part of the team that took the decision (and you have no access to them). Furthermore, 60% of maintenance is enhancements, not bug fixes. Each of these enhancements requires one to understand the existing code, and possibly make rather big changes in the design to accommodate these enhancements.

Being able to refactor an existing design into something else is a skill that requires the best people.

This leads to two points

1. It is much harder to do maintenance if you have no access to the team or people who made the product decisions. When the same team does development as well as maintenance, this is not an issue
2. A majority of maintenance is enhancements which require both understanding the design and being able to change it to accommodate the enhancement. This requires the best developers, not the junior developers

Both points can be addressed by using the same team for development as well as maintenance.

Preventing Disruptions

Another reason for having separate maintenance teams is that if the same team is working on bugs as well as features, then the inflow of bugs is disruptive to them delivering on new features. By having a separate support team, it is possible to minimize the interruption to the product team.

In sounds good, but there are a few hidden problem with this reasoning

• Learning loop is not closed: By sending all the bugs to another team, the product team never learns about errors they are making or any deficiencies in their design. They are likely to just continue creating the same errors over and over.
• Real progress is not known: The product team continues developing new features even as bugs are being created. So although it seems that they are making progress, it is not true, because all those bugs have to be fixed. So you get a false sense of progress. When the team is slowed down due to fixing bugs, the problem becomes visible and the real progress rate becomes known.
• Priorities are not managed properly: With two teams, the product team will be working on new features even if there is a backlog of critical bugs for the other team. Similarly, sometimes the support team may be fixing low priority bugs when there are high priority new features in the backlog. If there is one team with one backlog then it is possible to focus the entire team on the most important problem at hand – whether it is high priority new features or critical bug fixes.

Morale

Another argument is that good developers don’t like doing maintenance. They want to only work on new product development. This is not true.

In my experience the really good developers want to become better, and there is no better way than to do maintenance. It teaches a whole lot of things – where your design is failing, what kind of changes are being requested, how customers are using your software and which assumptions were invalid. By going away to work on another new product, you don’t learn anything. You will simply commit the same mistakes again in the new product.

Summary

There are many good reasons why the product and maintenance teams should be the same team. Hopefully I’ve convinced you that you should not have separate teams. Not convinced? Do post your arguments in the comments below.

One of the things that is fantastic about physical post it notes is the way you can easily make various bits of information visible. You can jot down any relevant information, like created and started date, cycle time, any reference id. You can use stickies to identify who is working on the feature, and further stickies to indicate blocks and other bits of information. By doing this you can easily visualize what is going on.

This is an area where electronic tools often fall short. Many tools don’t use a card visualization at all, and of those that do, most just display a card with the description on it.

Being big believers in visual management, we just couldn’t leave it at that. That’s why we’ve gone ahead and implemented a brand new feature – card  annotations.

Feature properties are now annotated on the card so that whether you are looking at the backlog, or the board, you see all the information that you need to.

Examples

Here are some examples of annotations in Silver Catalyst.

The above (click to view full size) is an example of annotations when viewing features in the backlog. Each row is colored according to the feature type. Red is a bug, green is an enhancement and so on. Additionally, cards are annotated with priority (Must), and Class of Service (Expedite, Fixed Date). In case a feature has a fixed date for delivery (for example to meet a conference/demo date) then the time until it is due is annotated. If there is an estimate then this is annotated on the card as well. These annotations are there to help you to make smart choices when looking at and ordering the backlog.

In addition to the ID and class of service, the feature card also shows properties related to external integrations. In this case, it shows links to change sets in source control that are linked to this feature (#55 ,#60, #61). We also see external test results from another tool annotated on the card (10 tests, 6 passing).

If you have linked Silver Catalyst with Silver Stories then you will see some Stories annotations like which initiative this story originated from (Silver Catalyst).

Task cards are annotated with the task estimate (if any) and the person working on it. The person is color coded – each user is assigned one color so you can quickly glance around the board and figure out what everyone is working on.

There is a lot of scope for using annotations – for example, you might want to create custom properties and have it show up as an annotation on the card. With card annotating, all the information you need on the backlog and on the board is made visible – another example of our commitment to helping you use visual management principles to improve your delivery process.

We’ve just deployed a new feature in Silver Catalyst. The feature view and task view pages have been reorganized. In addition, you can now add additional feature details on the feature view page. We’ve added tabs to separate the feature contents from the event history and have moved the history to its own tab.

The page also sports the new property bar in a yellow band at the top of the page. This bar contains all the properties that are associated with the feature.

The screenshot below shows more details

Scrum (and agile in general) has been responsible for a lot of the current visibility on softer, social aspects of software development – empowered teams, tight collaboration, higher communication and so on. XP’s engineering practices have also been extremely valuable. Those parts work well and we use them along with Kanban.

The problem we found with scrum is that it works well in a certain context: single team, completely dedicated to single project, completely cross functional, no external dependencies, product owner knows exactly what to build, experienced team members with good skills in engineering practices. In such situations it works well. But when you move away from the ideal context then you run into issues. External dependencies? Not fully cross functional? Boom. When I was working in Singapore, we were doing Scrum on embedded systems, and there had to be one set of manual acceptance tests that took a week to complete and couldn’t be automated. Trouble!

There is a joke that goes something like this: A physicist, engineer and psychologist go to a dairy farm to maximize milk production. The engineer derives the optimum packing of cows. The psychologist derives the optimum colour of the barn. The physicist starts “First, assume the cow is a sphere..”

Its the same thing with scrum. If the organization is already at the ideal state (the sphere) then scrum can work really well. If it is not a sphere, then before you can get started, the first step in scrum is to make it a sphere.. and then things get messy.

99% of the time, the organization itself is the “impediment”. It is interesting, because in many cases it is an impediment only from scrum’s point of view. Almost all the “ScrumButs” out there are because of this requirement that everything is an impediment until you get to the sphere… and only then can scrum start working. Every time scrum doesn’t work, invariably it is something to do with the environment not being a sphere – team is not cross functional, PO doesn’t know what to do, developers don’t understand TDD, testers don’t know coding etc.

I really do understand the need for adopting new values and new skills, but they don’t come about overnight. Until that time, you are going to have a hard time with scrum.

The other problem with scrum is that it has an underlying undercurrent of being anti-management. Scrum is essentially a solution to tell management to keep their hands off the team and leave the team alone to figure out how to meet the commitments by themselves. This negative view of management runs through the process – from dividing up people into chickens (management) and pigs (team), preventing all external interruptions and so on. The message is to stop micromanaging and leave the team alone. In many, the scrummaster is equated to a guard dog that protects the sheep (team) from the wolves (management).

Unfortunately once you train ScrumMasters to take a dim view of management, then it gets tough to get management cooperation when you need to interact outside the team.

IMHO, these two places are where Kanban really helps. With Kanban, you no longer have the requirement of making the organization a sphere before even getting started. You can start out with things exactly how they currently are. And Kanban is much better at integrating outside the team. There is still value in doing a lot of things that scrum requires – cross functional teams or engineering practices. You can now do them one by one at a pace at that suits the organization.

One of the slides from my talk at LSSC was about multiple projects being developed in parallel. (Slide 15)

Background

This was when I was working at Innvo Systems, around 2004-05. The company had got one round of venture capital financing and we were about 20 people strong with one acquired product. We were looking for another round of funding and the pitch was to use the money to scale fast, update the current product to latest standards and complement it with a complete suite of products (3 in all). The pitch worked, we got funded and the race started to scale as fast as possible and build up the suite.

Within a few months, the company scaled from 20 people to a peak of about 50. Around 30 were to be involved with the new product development roadmap, and were split into three teams.

Work on each of the products proceeded in parallel.

What we expected

When we first started out, the plan was that each of the products would be completed in about 12 months. So we would then have a complete suite ready to take to market.

What actually happened

What actually happened was that we were too few people to build three major products from scratch. With three teams, each of the teams ended up being understaffed. In addition, all the experienced folks were divided up among the teams, leaving each team with predominantly the new hires. A substantial portion of time of the experienced folk was spent getting new hires up to speed on the specialized domain.

The end result was that all three teams limped along and it took a lot longer than expected for the complete suite to be finished.

Lessons learned

Instead of working on all products in parallel, it would have made more sense in committing all efforts to one product. When it was complete, the team could have moved on to the second product and later the third product.

By doing this we would have got one complete product out much sooner. We could then take this product out to market and start booking revenue right then, without having to wait for the other products.

Further, it would have made more sense to have one solid team, rather than four understaffed teams. One team of about 15 might have worked out better than three teams of 10. A bonus would be that we could then put all the experienced people in this one team and thereby reduce the ratio of new hires to experienced people. This would have reduced the ramp up time before the team got productive.

One team, Sequential projects Multiple teams, Parallel projects One solid complete team Each team is understaffed and short of resources Best team members work together The best team members are divided up Specialists are first class members of single team Harder to manage specialists common to multiple teams New team members rise up to the level of other team members Experienced team members need to step down to the level of other team members Need to manage cross-team communication Reduced need for cross-team communication Only one team to align Need to align the direction of all teams

Silver Stories has an Enterprise Kanban board to track the flow of MMFs from the story tree. In this screencast we explore the functionality of this board. In the process we show how Silver Catalyst can be linked up to execute upon the backlog created in Silver Stories, and the expand-collapse pattern for enterprise kanban boards.

Silver Stories allows you to create flexible team configurations. Have multiple initiatives that are executed by the same team? Have one initiative that is executed by multiple teams?

Check out this video to see how you can handle this in Silver Stories

Silver Stories, our tool for product owners and stakeholders has now moved into a closed private beta. We will soon be opening it up for a closed public beta.

Would you be interested in running an early access version of Silver Stories through its paces?

Then head over to this form and sign up. Only users who are signed up will have access to the closed beta. Plus, users who participate in the closed beta become eligible for special discounted rates when Silver Stories is launched. What are you waiting for? Get on the list.

More about Silver Stories

• Silver Stories – The first agile and kanban tool for stakeholder teams
• Losing sight of the big picture
• Silver Stories in Action: Story Trees
• The 10 foot, 3 second rule
• User Story Mapping with Silver Stories

http://toolsforagile.com/blog/wp-admin/post.php?action=edit&post=329

In a previous post I introduced the Story Tree functionality of Silver Stories. Here is a video that shows how you can go about creating such story trees.

We had three goals when developing the interaction interface for story trees:

• Support different feature hierarchies: The video shows how we can use the Story Tree functionality to build a user story map, but you can create any other feature hierarchy too. You use a Theme->Epic->MMF structure? Or Goal->Feature->Story? You can model those too.
• Keep it visual: We are big believers in visual management, especially in the 10 foot, 3 second rule. We could have shown trees using the regular collapsible tree structure, but you lose all the context as you drill down or roll up the tree. By visually depicting the entire tree at once, you can always view your operations in the context of the entire story tree.
• Make it fluid: If the story tree is to support collaboration, the interaction had to be fluid. You should be able to create cards and move them around as if you were on a card wall. You can get remote stakeholders on skype conference call, share your desktop, and collaboratively build up the tree in real time as the conversations are happening. You can see that fluidity in action in the video above as we build up a small story tree in only three minutes.

So what do you think of the story tree functionality? We would love to hear your comments below.

Here is a question for you: How long does it take to identify that you have a problem with your process? A month? A week? A day?

Ideally, you want this information in near real time. A well designed Kanban board can do this if you design it with the 10 foot, 3 second rule in mind.

The 10 foot, 3 second rule

The rule says that a person should be able to look at the Kanban board from 10 feet away, and should be able to understand what is going on within 3 seconds.

Kanban uses visual management to achieve this. Humans are well evolved to quickly make sense of shapes, patterns and colors. We can leverage this to design boards that convey more information within seconds. Here are some ideas:

1. Using color
   1. Mark blocked work items prominently with red tape
   2. Use colored stickers to indicate states, eg: code review complete
   3. Highlight columns that are above the work in process limit
2. Using shape
   1. Look at the shape created by the cards in each column. This gives a quick indication of the flow of work items
   2. Look at columns where cards are piling up to identify bottlenecks
3. Using patterns
   1. Use colored cards to depict work item type or class of service. Quickly identify the type of work in the system by looking at the color across the board
   2. Use a colored sticker or a small picture to indicate who is working on each work item. Then glance around the board to quickly identify who is working on what

With a single board, you can now answer questions such as:

• Are work items flowing smoothly through the system?
• Where are the bottlenecks?
• What kind of work items are we working on?
• Who is working on what?
• Are too many items waiting in queues?
• What is the next action required to move a work item forward?
• How many work items are blocked? Why? Do we need to investigate for root causes?

Are you spending hours searching, filtering and mining around a messy spreadsheet or database to answer these questions? By making things visual, you can get all the answers in a few seconds.

Support for visual management in Silver Catalyst

Visual management techniques are a core part of the way Silver Catalyst is designed. Each screen of the tool uses color, shape and patterns so that you can quickly identify multiple trends in a few seconds. Try taking the taskboard in Silver Catalyst and projecting it on to a wall to quickly enable the 10 foot 3 second rule.

Here is a question for you: How long does it take to identify that you have a problem with your process? A month? A week? A day?

Ideally, you want this information in near real time. A well designed Kanban board can do this if you design it with the 10 foot, 3 second rule in mind.

The 10 foot, 3 second rule

The rule says that a person should be able to look at the Kanban board from 10 feet away, and should be able to understand what is going on within 3 seconds.

Kanban uses visual management to achieve this. Humans are well evolved to quickly make sense of shapes, patterns and colors. We can leverage this to design boards that convey more information within seconds. Here are some ideas:

1. Using color
   1. Mark blocked work items prominently with red tape
   2. Use colored stickers to indicate states, eg: code review complete
   3. Highlight columns that are above the work in process limit
2. Using shape
   1. Look at the shape created by the cards in each column. This gives a quick indication of the flow of work items
   2. Look at columns where cards are piling up to identify bottlenecks
3. Using patterns
   1. Use colored cards to depict work item type or class of service. Quickly identify the type of work in the system by looking at the color across the board
   2. Use a colored sticker or a small picture to indicate who is working on each work item. Then glance around the board to quickly identify who is working on what

With a single board, you can now answer questions such as:

• Are work items flowing smoothly through the system?
• Where are the bottlenecks?
• What kind of work items are we working on?
• Who is working on what?
• Are too many items waiting in queues?
• What is the next action required to move a work item forward?
• How many work items are blocked? Why? Do we need to investigate for root causes?

Are you spending hours searching, filtering and mining around a messy spreadsheet or database to answer these questions? By making things visual, you can get all the answers in a few seconds.

Support for visual management in Silver Catalyst

Visual management techniques are a core part of the way Silver Catalyst is designed. Each screen of the tool uses color, shape and patterns so that you can quickly identify multiple trends in a few seconds. Try taking the taskboard in Silver Catalyst and projecting it on to a wall to quickly enable the 10 foot 3 second rule.

dzone_url = "http://toolsforagile.com/blog/archives/310";var dzone_style="2";

We recently announced Silver Stories, a tool for agile portfolio management. In this post, I explain some of the problems that we hope to solve with Silver Stories. Click here for the entire series of posts on Silver Stories.

About User Story Mapping

User Story Mapping is a technique popularized by Jeff Patton that allows teams to build up a set of user stories by looking at the software from a user centric point of view. You could say that Story Maps are a combination of user centric design and feature breakdown trees. User Story Mapping is a powerful way to gain an understanding of scope for new product development.

The feature breakdown in user story maps is User Activity -> User Task -> User Story

User Activities are things that users do towards achieving a particular goal. For example, “Create a profile” might be one activity in a social networking website.

User Tasks are specific steps within an activity. Tasks by themselves do not move towards a goal, but are required components of an activity. For example, “Add contact information”, “Add education experience”, “Add hobbies and interests” might all be user tasks under the “Create a profile” activity.

User Stories are small end-to-end vertical slices of functionality that implement User Tasks. For instance, the “Add contact information” task could be broken into stories to “Add contact information”, “Edit contact information”, “Validate email address”, “Create a % complete progress bar” and so on.

Story mapping is a fluid, collaborative effort. Multiple stakeholders can participate on different sections of the map until a single shared understanding of the system is created. Cards are dynamically moved around, changing the order of the activities, grouping cards together under an activity or breaking cards down into tasks and stories.

Once created, the story map provides a good high level picture of the software to be built, along with a flow of activities from the user’s perspective.

User Story Mapping with Silver Stories

Silver Stories has a unique story tree view that allows stakeholders to easily create story maps. Here is a story map created using Silver Stories:

The story tree is visualized using a 2-dimension mapping of cards. This visualization enables you to see the entire tree at all levels of hierarchy on the screen at one time, eliminating the need to drill down through the hierarchy. The problem with drill downs is that you are always looking at sub sections of the system, losing the context in which it is placed. This visualization allows you to see user activities, user tasks and user stories within context.

Cards in yellow represent User Activities, cards in red are User Tasks and cards in blue are User Stories.

The shape of the story map gives an indication about which sections of the software contain the highest density of functionality.

Thus, the visualization of user story maps in Silver Catalyst use patterns, shapes and colors to convey much more information than can be obtained using a tabular form or a tree drill down.

Resources

This post only touches on user story mapping from a visualization point of view. For more on how you can use story mapping to collaborate with multiple stakeholders and create a shared understanding of the product, check out Jeff Pattons resource page on User Story mapping.

dzone_url = "http://toolsforagile.com/blog/archives/305";var dzone_style="2";

This is a guest post by Venkatesh Krishnamurthy. Venkatesh is a Bangalore based agile blogger who blogs at http://agileworld.blogspot.com. Here is Venkatesh:

How do we handle late comers to a Standup meeting?

One of the first rules of Scrum Meeting is to ensure that it is conducte at the same time every day at the same place.  It also expects that the team members should come on time to the Scrum Meeting.

Typical practice is that, late comers to the Scrum Meetings should either wear a joker cap or pay a $ as punishment for arriving late.  However many thought leaders share that these practices of punishment is bad and it is not going to improve the situation or change the behavior of the late comers. Worse, Thought Leaders proficient in Intrinsic and Extrinsic Motivation, believe that, over a period of time the extrinsic motivators(reward or punishment) actually reduces the intrinsic motivation too.

So, what should we do in this situation ?

How do we handle the late comers ?

Should we ignore them ?

How do we make them come on time ?

The answer is not easy. Researchers believe that there is no one formula that could be used to motivate every one. If someone is not coming on time to the Scrum meeting, it means either he/she is not interested or does not believe in these meetings or it could be something else. One needs to identify the root cause of lack of intrinsic motivation and work on an individual basis rather than applying the same reward/punishment formula.

Cognitive Evaluation Theory and FLOW seem to provide some insights to improve Intrinsic motivation.

A couple of my thoughts:

1. I’m not sure you should “make” people come on time. Instead this seems to be an area for 1-on-1 coaching. Perhaps the team member doesn’t see why it is useful. In that case, the importance of the standup needs to be coached.
2. Sometimes the standup really doesn’t add value. Often times the standup becomes a boring status update meeting that nobody is looking forward to. Is there a way to fix that?

So what do you think? How would you handle this situation?