Yesterday we showed how you can get started with Kanban. Today’s video shows Silver Catalyst in Scrum projects.

We just released a new video on using Silver Catalyst in a Kanban project. View it below:

When confronted with the task of scaling agile teams, most people go down a familiar path – scrum of scrums. But did you know that there is another method of scaling, a method that uses a single team and no scrum of scrums?

Scrum of scrums

Before that, here is a quick overview of the scrum of scrums method.

Let’s say we have 40 team members. First we split them up into four teams of ten members each (or five teams of eight). Each team is cross-functional with their own scrum master and product owner. The product backlog is broken into four parts and each team is given one set of stories to implement. Each individual product owner maintains the backlog for the team.

In order to coordinate the four teams, a meta-team called a scrum of scrums is formed. This is a higher level team with one member from each of the teams present. Their responsibility is to ensure that all the teams are coordinated and heading in the right direction. This meta-team also manages dependencies between the various teams.

Every day the scrum of scrums team gets together for a standup to ensure that there is visibility and coordination between everyone.

The scrum of scrums is a simple hierarchical solution to the problem.

Feature Teams

Instead of scrum of scrums, an alternate method is to use feature teams.

Feature teams are small, ad-hoc, cross-functional teams that work on a single story. The feature team is responsible for getting a story from Not Started to Done. Once the story is complete, the feature team is disbanded and a new feature team is formed for the next story. Feature teams are completely self organized in how they form and who works on what.

With feature teams, the whole team is kept intact. In our example, all forty members will be a part of a single team.

For example, consider a new story that is not yet started. Team members from the main team will decide who wants to be a part of the feature team for that story. In the simplest case, you may have one or two developers and a tester volunteer to be a part of the feature team. This decision can be made either at the start of the sprint, or just in time later on. Once the feature team is formed, it is their responsibility to work together and deliver the story. Once delivered, the feature team breaks up and each team member signs on for a new story, joining a part of a new feature team.

Since a feature team is cross-functional to deliver a story, there is no real need to have a daily standup meeting. Instead, meetings are called ‘on demand’. For instance, a meeting might be called when an impediment is found. There is also no need to split the backlog as everyone works from the top of the same backlog.

There are many variations to feature teams. Sometimes the feature team is kept intact for a long time, sometimes team members are a part of more than one feature team, sometimes a quick standup is still done to maintain cadence, and so on. The basic concept remains the same.

Feature teams were made popular by their use at Microsoft, and are often used on agile projects that follow the Feature Driven Development method.

Ichak Adizes, in his 1976 paper on Mismanagement Styles, identified four roles that a manager needs to play.  A good manager is able to play all four roles (with some roles better than others). A mismanager is only able to play one of the four roles. Based on this, Adizes arrives at various styles of mismanagement. In this post, I’m going to take a look at these mismanagement styles in the context of managing an agile team.

The four roles

According to Adizes, a manager should be

• A producer: Understand the functional and technical know-how to turn out maximal results
• An administrator: To implement a system to achieve those results and keep it running
• An entrepreneur: To initiate new directions whenever opportunities or threats arise
• An integrator: To harmonize individual goals into group goals and individual results into group results

When a manager only performs one of these roles, mismanagement results.

Mismanagement Style #1: The loner

The loner is a manager who is only a producer. The loner is very industrious and knowledgeable, but his main fault is the compulsion to do everything himself. He does not trust anyone else to do anything.

You sometimes see the loner in an agile team. This person is experienced but is the typical solo programmer. He has picked up all the difficult tasks for himself. He doesn’t have time to help others in the team get up to speed. A common complaint of his is that the rest of the team is dragging him down. The loner is often overburdened. Tasks and features are only half done because he doesn’t have the time to do them all.

The micromanaging PM also falls into this category. The micromanager does not trust anyone else to get something done unless they are involved in the task.

Mismanagement Style #2: The bureaucrat

The bureaucrat is a full time administrator, unable to do anything else. The bureaucrat knows the standard operating procedures by heart, more concerned with how things are done rather than what is done. He considers himself the guardian of the system, and primary commitment is implementation of a plan, regardless of its wisdom.

Sometimes the ScrumMaster does down this line. Everything must be done exactly by the book, no matter the results. If results are poor, the result is more procedures and more bureaucracy. Compliance is his favourite word. If the organization has a process group, then they can end up becoming bureaucrats too.

Mismanagement Style #3: The crisis maker

The crisis maker is a manager who is exclusively an innovator. The crisis maker charges ahead at all opportunities simultaneously. Every day it is a new idea on the horizon, even before the old idea has been implemented. The crisis maker changes direction constantly, without making progress anywhere.

Often times stakeholders can become crisis makers for the team. Everyday is a new “simple feature” to be implemented. Even before it is out in production comes another new direction, and another. Meanwhile the project has made no progress towards its goals, only a bunch of half implemented features lie on the floor.

Mismanagement Style #4: The superfollower

The superfollower is great at bringing together people, but nothing else. There is nothing he wants to achieve except the role of conflict resolver. The superfollower has no ideas of his own, and is unable to ensure that ideas get executed upon.

The superfollower is somewhat rare in agile teams. I’ve not seen anyone who really fits into this category. Superfollowers are more common higher up in management where initiatives cut across department boundaries. Have you seen this archetype in your agile teams?

Summary

Have you seen these mismanagement styles in agile teams? Put your experiences in the comments below.

Many people new to agile have misconceptions about agile. The same way, many people in the agile community have misconceptions about CMMI. In this post I want to highlight five of these misconceptions.

Misconception #1: CMMI is prescriptive

The truth is that CMMI prescribes very little. Talk to a high maturity lead appraiser and they will say that CMMI is descriptive, not prescriptive.

For example, CMMI says that you should have a requirement document, but does not say anything about what it should look like. Should it be in-depth and in-detail? Should it be lightweight? The choice is yours. Can a product backlog satisfy this requirement? Sure! As long as it meets the need of your project.

You decide what is appropriate for you. CMMI just says that you should follow whatever you decided on.

Misconception #2: One process cannot work for all projects

A lot of people in the agile community have the misconception that CMMI mandates a single process across all projects. This is not true.Yes, CMMI Level 3 asks for an organizational standard, but that does not mean a single process for every project. The organization can have a multiple standard processes that can be applied to different types projects. So you can have an agile as a standard for certain types of projects, and kanban for other types of projects, and a traditional model for still other types of projects.

Furthermore, each process can be tailored for the specific project through tailoring guidelines – so that each project ends up with a distinct process that is suited to the project context.

Also, the standard is expected to continuously evolve. When you have a project that needs something different, that learning should go back into the tailoring guidelines so that other projects in the organization can learn from it.

Misconception #3: CMMI has high overheads

CMMI actually asks for very little. Most (well run) agile projects generate much the same documentation that CMMI asks for. Where overhead comes in is during the appraisal process, where you need to keep lots of “indirect documentation” like meeting minutes as evidence for the appraisers. If you just want to improve your process and don’t have any need to get appraised, you can get rid of these documents and cut your overheads. (I believe this requirement for indirect documentation will be going away later this year.)

Misconception #4: CMMI means waterfall / CMMI means following a plan rather than changing the plan

CMMI lets you choose any lifecycle model. You can choose an agile model if you want to – it’s perfectly compatible with CMMI. You are also not tied up to the plan. You are in fact expected to change the plan when something fundamental changes.

Misconception #5: CMMI values process over people

Valuing people is a property of the organization culture. CMMI doesn’t tell you not to value people There is no conflict between CMMI and valuing people.

The bottom line

CMMI gets a bad rep in the agile community because a lot of companies apply CMMI for getting appraised without really buying into what they do. This leads to a dysfunctional process implementation (just like ScrumBut).

Properly understood, there are good principles in CMMI, and many parts of it are actually well aligned with agile principles.

If you go over to the tools for agile pricing page, you’ll notice that we’ve introduced a new pricing model. We’ve moved to a new user based pricing model from the previous project based model.

Since this is a fairly big change, I thought I should explain the rationale behind it.

Why did we change the model?

We wanted a model that we could extend to Silver Stories, which is coming up. Since Silver Stories doesn’t have the concept of projects, we couldn’t use the same model. Either we needed to introduce a different pricing model for this tool, or we needed to move to a common model.

We decided to change to a user based pricing model which could be easily extended to Silver Stories as well.

What does it mean for existing customers on a project based model?

Nothing. If you are a customer, you will continue with the old model, just as before. However, if you upgrade you will have to transition to the new pricing model.

What about reduced visibility due to a per user model?

We have previously blogged about why per user models are harmful for agile teams. The short summary of that article is that user based pricing encourages teams to reduce the number of manager and stakeholder users in the tool, reducing project visibility. We definitely don’t want to reduce visibility so we thought hard about what we could do about it.

The result is that observer users will not count under the user limit and are not charged (observer users can view projects, but not edit – typically managers and stakeholders). You only pay for the participants and administrators in the workspace. This way you can have as many observer users as you need – increasing project visibility in the organization.

Further questions?

Feel free to ask in the comments below, or on our support site, or via the contact page.

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