I have a question for you.
My IT department have what you would classify as a small pool of developers, architects and testers. As projects come along people are put on the projects – it can be a simple case of who’s available. The projects are typical quite short 1-5 months. Some developers are regularly pulled off on support tasks.
I feel short projects make calculating velocity almost pointless when the teams change. By the time you have a good idea of velocity the project is almost done. In addition, people (management) always want to know near beginning of a project when it will be finished. With this in mind I have been using ideal days rather than story points to size items on the “backlog” (release scope).
However, I’ve discovered of late that some developers can’t estimate very well. They also change their estimates dramatically when managers start questioning their estimates. Getting detail on some requirements can take weeks – either the true customer is not available or the feature requires investigation to know what’s feasible.
Can Scrum or another Agile technique work in such an environment? Am I flogging a dead horse?
BTW: Are there any good forums that can answer similar questions in an anonymous way?
- Create or build out a matrix according to a dynamic range of skill sets that your development department has. Do you currently even have a good visual overview of hat types of developers you have?
- You may be able to break out teams based on their ability to deliver certain things. Such as, an infrastructure team, a front end web team, or a business intelligence team for example. That way, if possible, you can keep the teams somewhat static.
- I would ask your management if they would like to have consistent teams deliver reliably. If the answer is “yes” then let them know you need A) consistency of team makeup and B) Little interruptions to that team away from primary delivery functions.
- I would fully do a release plan for each project. Wallboard it out with all the epics and features of that particular project. Elicit from your stakeholders what the highest priority items are and their value (if they have that information). Do preliminary estimations on the top priority items and forget the rest for now. Understand (within reason if possible) how long it will take to get the top items done. Start there and iterate as things get complete.
- Again, stable teams with little change can create the consistency your business requires that will in turn create some semblance of predictability. Without stable teams, you’ll never get past Storming per Tuckmans Model.