4 ms·
Ask HN: Maintenance/support heavy teams?
I manage a development team comprised of the following: 1 data arch/dev, 2 biz/front-end .NET devs, and two BAs. We use VSO for our SCM, product backlog, work items, etc. We have segregated environments that follow our SDLC: Dev, Test, UAT (staging), and Prod.
An understandable reaction might be that the team composition I describe is a bit atypical/not ideal. I'm working towards building the team to have clearer separation of concerns as well as bringing on a full-time Software Test Analyst.
Team responsibilities:
- Supporting over 200 customers: this ranges from various levels of data ETL complexity, to customized development change requests to our internal systems and/or integration projects between our systems and theirs. In many cases, we become an adopted dev team since a given customer may be so small that they have no dev resources. Or, some larger customers say they'll have to wait years to get X project done through their internal IT, so they turn to us to get it done in weeks or months.
- Supporting our internal departments: This is Help Desk tickets, internal Change Requests,CAPA responses, etc. 30% of my team's time is dedicated to this internal support on a weekly basis.
- New development: we have a large product backlog. Shiny object syndrome is real and something I continue to reduce through education, metrics, etc. Dev efforts that need to be dedicated to our internal operations department are neglected for months on end because of some new customer project, partner alliance, etc.
It's this last bit I struggle with finding ways to improve upon (deadlines, higher quality, clearer requirements). In Oct 2013 we moved away from a waterfall dev methodology to Agile. In a nutshell, I learned that Agile really doesn't fit well on teams that have a lot of maintenance/support. I've looked into Lean, Kanban, etc but am hesitant to switch to something else without hearing from the community about similar challenges and approaches.
- LeoSolaris 12y agoI work in a maintenance heavy shop. We are a manufacturing support team of 8 devs and a rotating team of 6 troubleshooters that handle 90% of the nuisance issues. We do support work for our mission critical software as well as most department level software. About a year and a half ago, we switched to Agile methodology with an incoming boss. It was based on complaints about the old info silo style that had dominated our team for decades. The transition has been interesting. "Scrum it" has become a new term for larger projects. We too have found that Agile is a very poor fit for maintenance work. We developed a quick kanban board to address those issues, and to clean up the project tracking board. It is still a work in progress, but so far the chief complaint about it is the lack of maintainable recurring tasks. Things like periodic backup tasks to remind the newbies and the forgetful have to be added by hand or just never placed in the done column.
- Silo18 12y agoThank you, it's encouraging and just nice to hear from someone else in a similar situation. I want to be very aware of the risk in switching gears to a new approach; but I think that's healthy as long as it's not too frequent. We're almost a year into the Agile experiment here. Your input helps reinforce my thinking that a move to some form of Kanban approach might be a worthwhile step in the right direction. Thanks again!