Apr 15, 2008 / Should We Have Parallel Releases and Iterations in a Project?

7 comments

The story began few months ago when we restricted creation of overlapping releases in TargetProcess. What does it means? People lost a possibility to create several parallel releases. The answer is pretty simple if you have several teams working on the same large project. Definitely you may have parallel releases and in fact each team may have own release schedule which should be approved/synchronized with other teams, but it may have different end date. It is not a mandatory to have all releases from all teams in the same day X.

But what if you have one team and one project? The main concern is something like that: “We are working on version 1.5 now, but we need to releases some patches for version 1.0 and also some people from our team working on version 2”. Sounds like a natural situation. Indeed we have to release some patches with bug fixed as soon as possible since it affects current customers and they need resolutions right now. Indeed we are developing new version with defined set of functionality. And hey some our gurus started prototyping several killer features that are not will be a part of version 1.5, but may be released in version 2. All it may look reasonable. Isn’t it?

Well, the simple answer is no, it isn’t. Let’s dig into details. For example, we have a team with 6 developers (skip QA and other team members for simplicity). You have 1 month releases schedule. You have defined scope for release 1.5 and some features for release 2. You know that you should also release 2 or 3 patches during this month for version 1, but the scope of the patches is undefined at the moment. How will you plan the release(s)? “OK, Joe, you will work on patches when some important issues will be reported by customers. But till that time you may work on Feature X for release 1.5. Mark, Beth and Teddy will take all other features from release 1.5. Also we have some very important and complex features that planned for version 2. We should mitigate risks and prove the concepts right now. Tom and Jerry will work on that”. What we have in the end?

Joe belongs to both releases. Other people do not have multi-tasking. Everything looks good. In reality we may end up with some bad things:

• Some issues assigned to release 1.0.x are hard to fix and Mark will help Joe to fix them.
• Joe spent too much time on bug fixes and unable to complete Feature X on time. So it will be required to exclude the feature from release 1.5 (or call someone from release 2 to help Joe).
• Beth’s feature appeared to be more complex than expected. Again two options (drop it or call for help).
• Jerry did not finish his work for release 2, since he was helped Beth and Joe in release 1.5
• Tom did all fine, but in the end it appeared that customer decided to drop the feature from the release 2 at all and replace it with another feature.

I agree that all above sounds pessimistic. But didn’t you have similar problems in the past?

Now we have 3 people with multi-tasking and all Tom’s work out of context (he did not add any value to the releases). Obviously, our plan failed. Why? We violated some core principles of agile development:

• Make decisions as late as possible. In fact Tom and Jerry’s assignment to release 2 was a mistake, since the release 2 will happen next to release 1.5. Important addition: It is OK (and even recommended) to proof all possible concepts before project start or in release 1.
• Reduce Work in Progress (WIP). The more WIP you have for given resources, the later you will release something. If we have 10 user stories and all of them will be in progress, we will have waterfall process in the end. We will have 90%-done problem and all related risks.
• Avoid Multi-tasking. Something related to point 2, but with such plan we really increased multi-tasking. Depending of context it may be better to assign Joe full time to Release 1.0.x (if you are struggling with de-motivation problem, you may just rotate developers for patch releases for example).
• Avoid 100% people loading. You may want to load all people 100%, but that’s a mistake. People should have some free/spare time. It is a proven fact that 100% load decreases productivity/throughput. So if you assign Joe to release 1.0.x and he will do nothing 1-2 days that is not a problem. He may do some minor refactoring or some minor bug fixes. But he will be available just in time when first issue request will be received.

Is this plan better?

Well, maybe. We eliminated all work from Release 2, which is good. Could we eliminate work from release 1.0.x? Probably, if fixes are not very important and may wait till release 1.5 availability. And often they can! Most likely you will have several fixes that MUST be released ASAP. It may take 2-3 days from one of the developer to handle them.

Turning back to TargetProcess ask me a question “Will you make it possible to have parallel releases in a single project?” I am answering “Yes, we will”. In reality things are more complex. You have pressure from top management who knows nothing about lean and agile and you gave up explaining the reason behind one release at a time and 100% people load problem. You have a large team inside one project and want to separate work with releases (why not?). You have maintenance releases and want to track them separately (why not?). Maybe there are more cases. Real life is complex and teams are learning doing agile.

Labels: agile, parallel releases, planning, release planning

posted by Michael Dubakov @ 5:53 AM

Apr 1, 2008 / TargetProcess Announced Integration with Microsoft Surface

0 comments

It looks like a magic, but soon it will be possible to manage projects using TargetProcess on a very cool Microsoft Surface table. Releases and iterations planning using drag and drop with usual human hands and fingers (throw your mouse and seal up your touchpad), nice sorting and grouping, fantastic user interface and experience!

"Microsoft Surface brings real tactile feeling into software world. You may operate with entities using hands on a table, almost like with usual cards. You may take a bunch of user stories and throw them to release. You may drag the slider to move release date. You may give a flick on user story to delete it! It really sounds like a miracle. I think such experience is a huge step forward for whole software engineering industry.", commented Michael Dubakov, founder of TargetProcess, Inc.

We are creating new appealing user interface with really handy functionality and unsurpassed usability. Stay tuned and find additional details here!

posted by Michael Dubakov @ 7:14 AM