tag:blogger.com,1999:blog-6005334108330583722.post5463571135543318988..comments2023-10-29T08:46:34.806-04:00Comments on Confessions of an Agile Tester: Does having a separate maintenance team hurt efforts toward accountability?Dawnhttp://www.blogger.com/profile/00149191486108175617noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-6005334108330583722.post-10470753206368597332009-10-07T17:45:34.685-04:002009-10-07T17:45:34.685-04:00I would agree that having a separate maintenance t...I would agree that having a separate maintenance team hurts efforts toward accountability.<br /><br />Some of the reasons for two teams include:<br />1) PE / maintenance programming is "easier" and/or a training ground to "learn the code" .. I disagree to a certain extent .. but it is different. And some of the PE guys get very good at fixing bugs quickly.<br /><br />2) The management wants to improve accountability for the Development Team .. no excuses for not meeting the development deadline.<br /><br />I have watched two teams get more accountability when their maintenance team was not forth coming. This allowed the developers to directly feel the pain and also see where things were going wrong.<br /><br />Agile should help. <br />It is tough to meet schedule if bugs are falling like rain. <br /><br />So in a case as described above if someone can be "enlightened" and keep the quality, slip some of the function for a release all, customers and developers, should benefit.<br /><br />All too often a management team is seduced into a release date that has the function, but a boat load of bugs. The quality goes in "AFTER" the name goes on.<br /><br />Seen it several places.<br /><br />good luck to you.Unknownhttps://www.blogger.com/profile/07108382983986568443noreply@blogger.comtag:blogger.com,1999:blog-6005334108330583722.post-47828571782811728682009-10-05T23:55:02.668-04:002009-10-05T23:55:02.668-04:00I think you've got this exactly right, and it&...I think you've got this exactly right, and it's one of the reasons that agile teams that release frequently often don't run into this sort of problem. They're ALWAYS living inside that codebase, and there's not really a separate maintenance stream except for critical bugs.<br /><br />Recent events have taught me well about perverse incentives. I think you've identified one.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6005334108330583722.post-35397619473321206712009-10-05T15:22:40.165-04:002009-10-05T15:22:40.165-04:00Hi Dawn,
Interesting question! I can only speak f...Hi Dawn,<br /><br />Interesting question! I can only speak from my personal experiences of course...I have been on teams that were responsible for both new development and maintenance within the same product line ("product family" as we called it), and I think this approach was beneficial for a couple of reasons.<br /><br />1) The team could learn from the bugs they had to fix - a lot of the pain points in the apps being supported were architectural in nature and since the developers knew intimately what smelled, they knew where to focus refactoring efforts. <br /><br />As a tester on the team, I also learned about new (well, new to me) scenarios/use cases to consider when testing new features or changes to existing functionality. <br /><br />2) Speaking exactly to what you discuss in this post - at least partly because the team "felt the pain" of dealing with bugs and maintenance issues, we were aggressive (can't think of a better word) in our attitude and approach to testing. TDD, pair programming, shared testing responsibility (across all team members, not just "the testers"), building a regression suite, and collaborative acceptance criteria definition became part of how the team operated on a daily basis. <br /><br />Now, there did come a time when the maintenance and new development responsibilities were split across two teams. This was part of the reaction to an urgent business need. I ended up being on the "new development" team so I can't speak to what being on the maintenance team was like; I can tell you that more than half of the people on the maintenance team ended up leaving within 3 or 4 months of being put on the maintenance team, though.<br /><br />I'm going to forward the link to this post to some former colleagues who may want to share their experiences as well.<br /><br />MarisaMarisa Sealhttps://www.blogger.com/profile/12605012611300911507noreply@blogger.comtag:blogger.com,1999:blog-6005334108330583722.post-89866332658605894162009-10-05T14:36:44.516-04:002009-10-05T14:36:44.516-04:00I think they really need to be in cross functional...I think they really need to be in cross functional teams. Splitting new dev and maintenance activities only hurts the company as a whole. Being a support engineer is a morale crushing hole and not having to face the pain reinforces the wrong behavior. They are saying good boy to the puppy who craps on the rug and punishing the one that wants to go into the back yard.Angushttps://www.blogger.com/profile/12749636856451303702noreply@blogger.com