Some quick background – we don’t have PMs or upper management breathing down our necks about status of features, etc, as we almost always deliver ahead of time and have built up a high level of trust with them. In other words, we have a huge amount of flexibility as far as process goes. We do very well with our current process, but we feel there can be some improvement.
We have a small team (3 devs, 1 tester) and everyone on the team is senior level and can deliver large pieces of functionality, and usually does so on an individual basis. Sometimes two people work on the same story/task, but since we are all very familiar with the codebase(s), we typically handle things by ourselves and consult/collaborate when needed.
We roll to a live site and have the ability to roll on a daily basis, which someone on our team typically does. On average, I’d say an individual developer rolls his own code 3 times a week.
We have been doing scrum with 2 week sprints, but from my experience scrum was more advantageous when we needed the majority of the team to work on the same features at the same time (swarm-type stuff), and when needing to communicate out to external teams. We currently don’t have either of those needs, so we’re re-evaluating our process.
What it seems like we’re moving toward is a model where each team member exists in his/her own sprint (with optional teammates being less common), which lasts anywhere from 1-3 days. We don’t have a requirement that all sprints have to end on the same days, etc, so in theory we could pull this off. My question is, is there something better than scrum that models this type of development process?
Oh, I almost forgot. We’re moving away from TFS to use Git, and while I have experience with Git, most of the team members don’t. Since it’s a paradigm shift for some on the team, I’m wondering if we can use the change to our advantage somehow process-wise. Thoughts?
5
If you take a step back and look at why ‘formal’ development processes such as Waterfall, Extreme, Scrum evolved, its because many development houses struggle with developing software products (as opposed to ‘software programs’) that met the business and customers requirements. Every published process is an attempt to provide a framework to help achieve these goals. Some frameworks (e.g. Rational RUP) are large and prescriptive, others (e.g. Agile) a light weight and provide guidelines.
What you have evolved may not be Scrum, but is a form a Agile. It does not need a name to work. It appears to be working for you and does not appear to be broken, do not change what you are doing because someone says they have a different way.
What I suggest you do is look at you process and ensure that it is more than luck that is keeping it working. Document how you work now so its repeatable – pretend anotehr team wants to adopt what you are doing and write it up.
Look for weaknesses – For instance a team of 3 could become a team of two overnight and feasibly a team of one. Is the process robust against this kind of change, can you bring a new member into the team with little process change? Does it scale – can you double the size of the team and still get the same results – if not, ask is it needed, and document the decision.