Scrum, Kanban or Other for 4 person dev team [closed]

Question

We have a four person development team that is in need of a formalized project management system. I have a general understanding of Scrum and Kanban but it's hard to truly understand until it's been tried. We don't have the luxury of trying one for a few weeks and then switching to another so I was hoping that someone out there in a similar situation might have thoughts on which worked better for them and why. Also, any other systems for managing development that worked would be great to hear about.

Another note: there's the possibility of the team growing, of course, so we would need a system that scaled well.

Yet another note: We work on three separate software applications in Windows all of which are based on a central library which we also wrote (so i guess you could say four projects)

Answer 1

Both Scrum and Kanban are really process "skeletons". Neither is specific to software development. Scrum was popularised by software development organisations but is positioned as general management technique rather than a software project management technique. Kanban emerged from manufacturing and has been adapted to software development, initially by maintenance teams. Both Scrum and Kanban aim to manage the flow of units of work through the team that is doing that work, measure how fast work flows so that estimates can be made more and more accurately, and make bottlenecks highly visible so that they can be addressed.

Because neither is specific to software development, teams using Scrum and Kanban add software development practices to the process to help them incrementally and iteratively release and improve the software. Most teams, whether working within a Scrum or Kanban process, adopt the technical practices of XP and reflective practices of Crystal.

XP is basically Scrum applied to a single team plus guidelines about what makes code "high quality" and how programmers can achieve that. Crystal Clear also applies to small co-located teams but is more flexible about programming practices although it also recommends the XP practices (the book describing the process is excellent and full of invaluable advice, whatever process you decide to go with). Scrum teams also usually adopt the reflective practices of Crystal: regular "heart-beat" retrospectives and larger retrospectives after every major milestone. Kanban requires continual reflection and improvement but some teams use retrospectives too.

If you want to start applying an incremental/iterative process in a small programming team, then I think XP is a good process to start with because it sets the bar pretty high for technical capability and is very well documented. How continuous-flow and Kanban best applies to different areas of the software development industry is still being debated on the kanban-dev mailing list and elsewhere.

I would recommend also performing regular retrospectives to improve the process and adapt it to your specific situation.

Answer 2

The most important part is to have a reflection/retrospective mechanmism in place which facilitates continuous improvement. Start with some process model and evolve it over time for your needs. Stop doing things that are not worth doing. Keep on doing things that bring in high value. Try new things that you think could be valuable or address specific problems.

Answer 3

I think Scrum works for small to medium team. Compared to XP it leaves out some details, so you can borrow from XP or do something that makes sense. Either methodology you pick, you have to consider the role of chickens(customers/managers/stakeholder/domain experts) role. Sometimes you have to play the roles yourself, but many agile methodologies work because there's external pace car with grounded knowledge of the domain.

Other key aspects are the communication level among your team and some form of quality assurance mechanism. It's hard to do pair programming if you are not located in the same building. Scrum tries to get a feature to acceptance within a sprint cycle, and XP tries to get the feature integrated within the day using unit tests, code review, and continuous integration.

*) Sprint can range from 15-30 days.