Idea Transcript
1. 2. 3. 4. 5.
(/)
Silver Catalyst (/silvercatalyst/) Silver Stories (/silverstories/) Resources (/resource/) Contact (/contact/)
6. Blog (/blog/)
Tools For Agile Blog (/blog/) Should you have separate product and maintenance teams? (http://toolsforagile.com/blog/archives/383/should-you-have-separate-product-and-maintenance-teams) Posted on July 5th, 2010 in Agile (http://toolsforagile.com/blog/archives/category/agile) , Lean (http://toolsforagile.com/blog/archives/category/lean) by siddharta || 8 Comments (http://toolsforagile.com/blog/archives/383/should-you-have-separate-product-and-maintenance-teams#comments) Tweet
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 (http://www.amazon.com/Facts-Fallacies-Software-Engineering-Robert/dp/0321117425) , 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. Related posts: 1. 2. 3. 4. 5.
How agile teams handle maintenance work (http://toolsforagile.com/blog/archives/390/how-agile-teams-handle-maintenance-work) Should bugs be in a separate backlog? (http://toolsforagile.com/blog/archives/158/should-bugs-be-in-a-separate-backlog) Product Owners – What kind of product risk are you dealing with? (http://toolsforagile.com/blog/archives/630/product-owners-what-kind-of-product-risk-are-you-dealing-with) Agile for maintenance projects (http://toolsforagile.com/blog/archives/92/agile-for-maintenance-projects) Agile Advice on maintenance projects, Yahoo India tries out Kanban (http://toolsforagile.com/blog/archives/93/agile-advice-on-maintenance-projects-yahoo-india-tries-out-kanban)
Doing Distributed Agile? Share and collaborate with distributed teams with our electronic agile board tools (http://toolsforagile.com/?utm_campaign=blog&utm_term=banner) . Get all the benefits of electronic tools without sacrificing the benefits of physical boards. Supports Scrum taskboards, Kanban boards and user story maps. Check it out! (http://toolsforagile.com/?utm_campaign=blog&utm_term=banner)
8 Responses to “Should you have separate product and maintenance teams?” 1. How agile teams handle maintenance work » Silver Stripe Blog » Blog Archive (http://toolsforagile.com/blog/archives/390) Says: July 7th, 2010 at 6:19 pm (#comment-163967)
[…] 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 […] 2. terry Says: July 8th, 2010 at 7:56 pm (#comment-164017)
I just wanted to say I’m absolutely convinced and excellent article!!! It’s SHOCKING how many managers look down on maintenance work and believe that only new and finished projects are important. They fail to realize that maintenance makes up the vast majority of the life cycle of any piece of software were talking at least 80-90%. 3. Kevin Rodrigues (http://kevinrodrigues.com/blog) Says: July 8th, 2010 at 9:52 pm (#comment-164020)
I agree with your point that the developers that have created the new code should be the ones maintaining it. In addition to the points that you have mentioned, I would also like to add that it is much easier for the developers who have written the code to maintain their code than for other developers to jump into code written by others and try to fix bugs in it. And with bugs it should be such that most of the critical bugs should be fixed and the product should not be considered complete till that happens. 4. Cumbayah (http://cumbayah.dk/) Says: July 9th, 2010 at 2:19 am (#comment-164028)
Developers only doing green-field work often fail to learn and repeat maintainability disasters over, never even realizing what a maintainability mess they’ve left behind. I’ve seen it again and again. In a company with a faulty reward system culture, they might even viewed as the Heroes that Did Whatever Needed to be Done in order to Ship. Yay. After the project shipped it becomes the Maintenance department’s problem. And good riddance. I’m firmly convinced that developers should generally live with the code they’ve made and be responsible for maintenance as well, in order to continuously improve and learn how to design for non functional aspects such as maintainability as well. (I’m a software architect, developer AND maintaner myself.) 5. anonymous Says: April 27th, 2014 at 11:56 pm (#comment-351595)
The main problem with feature development and maintenance (or bug support) in one team is that feature work gets disrupted and it may come to a situation that in light of backlog and contractual commitments, because the scrum team is so busy addressing bugs, feature development is done in a hurry creating scope for even more bugs. Due to urgency of making bug fixes available as in high number of cases testing teams maybe getting blocked, feature starts getting pushed further and further into smaller time slot, dependencies may not also get resolved as a result, stalling work of other developers and in worse cases other scrum teams also. There is no fully clear solution, probably scrum teams should handle intial phases of bug fixes and after few sprints/feature delivery, scrum teams should be re-organized with new bug fixing team being created with few developers from all teams. Additionally one sprint can be dedicated to giving feature/code overview to the new bug fixing team for areas they may not be equipped to handle. 6. Anonymous Says: June 20th, 2015 at 1:52 am (#comment-679558)
I tried to treat this same topic last year, and came to many of the same conclusions. The point about the learning loop is so crucial. I’ve seen teams spend 70% of their time fixing bugs, and 30% creating the same bugs over again in different places. One team I know had over 10,000 bugs, and 80% of them were related to pointer errors in C++. I asked the developers about what they thought was common about defects, and they told me that each one was different and there was no pattern. Digging deeper, we found there was NO MEMORY MANAGEMENT POLICY AT ALL. People passed all kinds of objects by pointer, it was up to the developers to read all the code in the lifecycle of the object to find out if it was being borrowed, owned, or shared. As a result, they deleted things they shouldn’t and leaked things that they should have deleted. As long as the defect-fixers and the defect-makers never collaborated, it could have gone on for years and damaged the reputation of a very fine, storied, large corporation. I just wanted to amplify that point. My take on it is here: http://agileotter.blogspot.com/2014/01/bug-teams-well-meaning-foolishness.html (http://agileotter.blogspot.com/2014/01/bug-teams-well-meaning-foolishness.html) 7. Jeff Says: January 10th, 2017 at 2:14 am (#comment-1099463)
Here is the problem I see with trying to do development with people who have been happy doing maintenance for many years: 1) dislike technology change They might adapt new technologies, but don’t embrace them. By that I mean they don’t feel comfortable with disruptive changes… gradualism is safer and encouraged in a maintenance environment. 2) are not life-long learners Most developers I have worked with strive to stay abreast of concepts. Maintainers, not so much. 3) confounded by uncertainty When developing, you go through a tortuous analysis phase where you start of discovering that everything you think you know is wrong. It can take a long time before a development team drives out all the ambiguity and false assumptions. Maintainers are not used to this. 4) have to much familiarity with legacy implementation When developing, you have to be willing to re-examine concepts, at a conceptual level. Businesses change, software development practices change, what once was ubiquitous is now seen as quaint. Maintainers have too much invested in how things work now, and can’t see the forest for the trees. Also, they a prone to what Brook’s called “the second-system effect” Okay, that said, maintainers are often the domain experts. They can help in driving out the ambiguities of a new design; they know corner-cases; they often can be fed into a development project once it starts rolling. I am over-generalizing here, but at the moment I find myself frustrated trying to get my team to *move* and rethink. The legacy stuff is a mess. Not the worst I’ve seen, but I’ve seen plenty. 8. Bhagwat Katha (http://www.yugalsarkar.com) Says: August 30th, 2017 at 6:49 am (#comment-1168813)
Girls want to see a ripped body check us out for advice!
Leave a Reply Name Mail (will not be published) Website
Submit Comment Notify me of followup comments via e-mail Connect with us on Facebook
Follow us on Twitter @kausikram (http://twitter.com/kausikram) search for Indah cocoa powder on amazon 08:01:08 PM January 22, 2017 (http://twitter.com/toolsforagile/statuses/823183726175621120) from Aeries 2 (http://www.BradStevenson.co/Aeries) in reply to kausikram (http://twitter.com/kausikram/statuses/822328704512626693) Reply (http://twitter.com/intent/tweet?in_reply_to=823183726175621120) Retweet (http://twitter.com/intent/retweet?tweet_id=823183726175621120) Favorite (http://twitter.com/intent/favorite?tweet_id=823183726175621120) Totally agreed https://t.co/b11QIzWF95 (https://t.co/b11QIzWF95) 09:01:52 PM November 03, 2016 (http://twitter.com/toolsforagile/statuses/794207978727444480) from Aeries 2 (http://www.BradStevenson.co/Aeries) Reply (http://twitter.com/intent/tweet?in_reply_to=794207978727444480) Retweet (http://twitter.com/intent/retweet?tweet_id=794207978727444480) Favorite (http://twitter.com/intent/favorite?tweet_id=794207978727444480)
RT @venkat_s (http://twitter.com/venkat_s) : That moment when your mind congratulates your packing skill and, at the same time, your eyes catch items forgotten on the cou… 07:38:53 PM November 03, 2016 (http://twitter.com/toolsforagile/statuses/794187094935506944) from Aeries 2 (http://www.BradStevenson.co/Aeries) Reply (http://twitter.com/intent/tweet? in_reply_to=794187094935506944) Retweet (http://twitter.com/intent/retweet?tweet_id=794187094935506944) Favorite (http://twitter.com/intent/favorite?tweet_id=794187094935506944) Two pretty cool sessions on bot frameworks at #buildabot (http://twitter.com/search?q=%23buildabot) Using api.ai and LUIS through python 11:54:08 AM October 01, 2016 (http://twitter.com/toolsforagile/statuses/782111336675233793) from Aeries 2 (http://www.BradStevenson.co/Aeries) Reply (http://twitter.com/intent/tweet?in_reply_to=782111336675233793) Retweet (http://twitter.com/intent/retweet?tweet_id=782111336675233793) Favorite (http://twitter.com/intent/favorite?tweet_id=782111336675233793) RT @jeffpatton (http://twitter.com/jeffpatton) : #mtpcon (http://twitter.com/search?q=%23mtpcon) speaker says "I hate Agile. It's all points and velocity. No one talks about the customer." 1,400 people applaud. #… 11:48:32 AM October 01, 2016 (http://twitter.com/toolsforagile/statuses/782109927154159616) from Aeries 2 (http://www.BradStevenson.co/Aeries) Reply (http://twitter.com/intent/tweet?in_reply_to=782109927154159616) Retweet (http://twitter.com/intent/retweet?tweet_id=782109927154159616) Favorite (http://twitter.com/intent/favorite? tweet_id=782109927154159616) Follow @toolsforagile
1,879 followers
© 2007 Silver Stripe Software Pvt. Ltd. | Privacy Policy (http://www.silverstripesoftware.com/policies/privacy/)