1

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
  • Wouldn't it be more prudent to roll changes to a test server daily, and roll the good changes to the production server on a less frequent basis? The most agile of processes specify a short (measured in weeks, not days), but not daily, release cycle. That said, I don't see any reason why you couldn't shorten your sprint cycles and still call it Scrum. Commented Feb 3, 2014 at 23:17
  • @RobertHarvey - I totally get what you're saying. We do have test servers but a constraint we have is that they do not simulate nearly the same load we have in live (millions of hits a day). A lot of our issues are scalability issues that only show up in live. We'd like to be able to test those issues in stage/test, but currently it's not feasible. We can tell very quickly, if not instantly, whether or not a roll in live is causing problems or not, and can quickly roll back if needed. Rolling is quick and cheap for us and gives instant feedback. Our test servers are used more for func. tests. Commented Feb 3, 2014 at 23:25
  • 1
    I'm a big proponent of releasing to production as often as possible. Where I work, we release every master branch commit to production as they come in. This works because of automated good unit, component, and acceptance testing. All commits go through this pipeline, and won't be released to production until they pass these quality gates. We wrap new features and such in experiments that prohibit the majority of our users from seeing the new features until our program managers decide to release them to the general user base. This, combined with cheap rollback, makes this rapid cycle possible.
    – dsw88
    Commented Feb 4, 2014 at 0:04
  • 5
    Waterfall, Extreme, Agile, Scrum all evolved to fix a problem you do not appear to have. If what you are doing works, the only change I can recommend it give it a name, write a white paper and join the conference circuit selling it to the rest of us.
    – mattnz
    Commented Feb 4, 2014 at 0:05
  • @mattnz your comment here is the answer I'd like to accept. Add it as an answer and I'll do just that. Commented Feb 4, 2014 at 20:32

1 Answer 1

2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.