Silver Stripe Blog

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:

Continue reading ‘How agile teams handle maintenance work’ »

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.

Continue reading ‘Should you have separate product and maintenance teams?’ »

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.