Software development methodologies with understaffing

[rm2011]

Hello: First post in the project management section.

I've been with company "X" for 3 years. During year one, I was a developer along with one other gentleman, and we developed two applications for a single business unit and I often had to support the other gentleman because he was behind schedule. We had a small project management team at the time who helped gather requirements and created documentation using a traditional, waterfall approach. Soon, other business units needed to use our products and we added a few more applications. Because of my early success, I was promoted to head up the newly growing development team and the other guy was (mutually) let go. During year two we grew our development team significiantally, had a good project management team to support us and implemented an Agile Scrum approach which helped us address customer needs with much faster releases. This proved successful to meeting our deadlines for a while until it became clear that we were still somewhat understaffed as people resigned and we weren't allowed to replace due to budget constraints.

Fast-forward to now. Company "X" has recently minimized staff to two developers who have to do all of their own project management. They need to continue to support all of these business units and the six enterprise applications which are functional, but still not complete with all of the features needed. No one wants to eliminate any of the projects, and they are not in a position to finance additional resources to work on them at this time (or into the foreseeable future).

I wanted any anecdotal advice others' may have in this area. While some of the tennets of the scrum approach may continue to work for us, we don't even have enough personnel anymore to constitute a traditional scrum team, and it's clear that we won't be able to dedicate a developer for new development anymore as production support issues swell without resources. I'm trying to think of a scenario where requirements management, communication, programming, production support, qa testing, and documentation with two "programmers" will have any sort of possible positive outcome.

 

[BNPMike]

Scrum is ideal for you as you only commit to delivering bits at a time, and you can respond to changes in business priorities.

You're in a difficult situation but what you must do is give realistic completion dates for each sprint. It's then up to Management to cope. Despite the fact there are only two IT people, you still have the Business. Make sure they make the calls on what gets done. Let them fight the battle about lengthy timescales. What you want to avoid is getting trapped into unrealistic deadlines. If you spend 80% of your time on maintenance, then what you commit to in a sprint goes down by 80% or the timescale goes out by 5. Just keep offering people options but never commit to anything that you can't do. If necessary, say you use best endeavours but they must accept a high risk of failure.

 

[rm2011]

Thank you BNPMike. One other approach I've been really pushing back on is requirements gathering by the business people themselves. We can hash it out in a big requirements planning meeting. I want to avoid having business people hammering developers with phone calls whenever an idea pops into their head and instead use the backlog appropriately.

 

[johnherman]

I agree with BNPMike that some sort of agile methodology would be best. In addition to Scrum, you can consider Kanban.

The trouble with doing something right the first time is that nobody appreciates how difficult it was - Steven Wright