Apr 15, 2008 / Should We Have Parallel Releases and Iterations in a Project?
7 commentsThe 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
7 Comments:
Hi,
Let's say 2 different teams are working on V1.x (maintenance, minor feature) and V2 (which will be released at a future date but still have beta stages and so on).
I suppose this is not what could be considered bad practices.
In that specific scenario, what would you consider the best approach using target process: different projects or parallel releases?
Thanks
Yes, as mentioned in the post, if you have 2 teams it is definitely OK. If the activity for v.1.x is long enough, it may be better to create project. If it is quite short, it is better to create separate parallel release (and that is one reason why we adding the functionality for parallel releases). There are some cases where it can be required and this case is one of them.
Arghhh... I have experienced this myself in one of my projects. We were team of 22 people working on 3 parallel sprints - Core, Maintenance, Patch. Overall, it was very similar to yours. The way I managed it was to create a project plan with some loss of productivity. Core team had dedicated 10 members, Maintenance had 5, Patch team has 3 members.
I delibrately refrain from assigning 4 people to any sprint. I would allocate them as late as possible to make things clear for me as to what story will finally get covered in what sprint. There was some loss of productivity but sprints don't get into ambiguity. For the matter of fact, there was hardly any fixed schedule as sprint plan was always in flux.
Thanks to those 4 guys who stuck by those hard times and still enjoyed the work.
Agile is supposed to be receptive to changes, in order to make the customer happy. We have a product with almost 10 million installed copies. Most of the time, we HAVE TO work in patches, while working in the next version. And since we work with security, we HAVE TO keep an eye on next trends, doing research and prototypes for future versions. We have been researching agile methodologies since 2003, and we currently use a XP-like approach in our projects. I am not sure if "not working in parallel versions" is a mandatory principle/practice for agile methodologies. We have been using TP the latest weeks and we miss some kind of control for concurrent releases, since that is our reality. We use custom fields for keeping control of versions, but we lose the ability to use the nice Release Management/Planning features of TP.
Rafael, sure I am not insisting that parallel releases ALWAYS bad sign. But I think it is better to try to eliminate them. In many cases it is just a matter of term release/project. For new technology prototype maybe it is better to create a separate pilot project with separate team than doing parallel releases.
As for TargetProcess, we will add parallel releases support. Agile is different and as far as I know there is no such a rule that team doing parallel releases is "not agile" :)
Hi Michael,
I think we need to distinguish between "what is a good idea" or "how we want to do things" from "how we have to do things".
I think working that on multiple releases while evil, is sometimes a necessary evil.
The UI on TP about Sprints and Releases in 2.8 is confusing. It looks like they are fields, but they are really one. You can assign to a sprint (which implies a release) or to a release (without specifying a sprint). If this were all one pull down menu, then OK. But there are two fields.
I think there are two questions to be answered here. When do we do the work (which Sprint)? And in When did we/will we push the code out to the user (which release). TP needs to handle that in reality, this is not always a 1:n but sometimes an m:n relationship.
I work in an environment where we have two versions of one intended system, i find that if the two versions co-exist and hence one does not superceed the other completely (i.e. if you have shrink wrap software, like Word or Excel and have customers on 2003 and 2007) then it makes more sense to have separate projects.
In truth i think that it's a semantics question on what you actually define as a "version", if your code is sits on top of the previous code and the customer has no option but to use the latest code base then it belongs in the same project and parallel releases are impossible. (In the example where some people may be developing feasibility prototypes for a future version then i would put this work against a request until the stories are defined)
If you are developing one "version" of a system for a specific audience that only use that "version" and don't have to upgrade then we are saying that the "versions" are actually independent of each other and are hence actually separate projects.
Post a Comment
<< Home