Choosing an appropriate development process/methodology

Question

I'm looking for some advice on implementing or defining a development process for my team. I'm having a hard time finding something that seems like it would fit, but it may be just due to a misunderstanding of the processes.

I am managing a small team of half a dozen software developers, who are split between two main systems/projects that we work on, 3 developers on each system, although the team has been growing and I'm expecting those numbers to get bigger, which is part of why I'm hoping to get things more structured now.

Up to this point there hasn't been any real defined development process, but since I've begun managing the team I've been working to try and organize/structure things as much as I can while keeping the development on-going.

Most of the work that we do is through a ticket-system style set of requests, where we receive user reports of bugs or requests for small features/changes, and we work through the requests in order of submission and priority. We periodically work on larger features which may involve a couple of weeks of development, but for most things development is only a few hours of changes.

These systems don't have any automated testing, which is something that we're also starting to work towards, so after development is completed the tickets go through a peer review process and then I complete a final review/manual test before the changes are merged in and released to live systems in updates (which usually just happen whenever there are enough pending changes to warrant releasing an update).

I've been reviewing different development methodologies but I'm not sure what would fit well with our requirements. It seems as though most of the methodologies are designed around doing larger scale projects which span multiple weeks and have a lot of back and forth with end users, but that's very rarely something that we do. However that's just my understand from what I've read, so I may just be misunderstanding something.

Any thoughts or advice on moving forward would be greatly appreciated, and please let me know if I should clarify anything further.

Answer 1

You can do a pilot of the Kanban method

Welcome to pm.stackexchange!

As @nvogel suggested, Kanban method may be suitable for your type of work. Again, as he suggested, you should let the dev team 'to self-organise and allow them to choose a way of working that will suit them'.

However, I would suggest that you run a pilot of the Kanban method that will give the dev team a hands-on feel for how the process works and whether it suits them.

• You can use an open source tool like Kanboard or TaskBoard to run this pilot.
• You can have task status columns such as To Do, Assigned, In Dev, Peer Review, In Test, Done.
• You can have separate swimlanes for the two projects. You can also have separate swimlanes for the Priority tickets for the two projects separately.
• Apply Work in progress (WIP) limits for each swimlane and see what works for the team.

Answer 2

It sounds like you could benefit from adopting something like the Kanban method. Personally I would want to encourage the team to self-organise and allow them to choose a way of working that will suit them. Development teams are usually most productive when they have collective ownership and accountability and the freedom to innovate but a lot depends on the character and experience of the people concerned. See: self-organising team.

Answer 3

I would suggest not to use any 'methodology' as is. Just try to find weak spots and implement some methods/artefacts to your current process and improve it. You can talk with developers, use metrics for this. For example if your team feel uncomfortable because there is any kind of communication or transparency problems - try to add and facilitate meetings on daily/weekly basis and let your team work as they used to but with small improvements.

You can use list of scrum artefacts or any methodology methods. You can highlight the problem you found for whole team and try to solve it together, find solution that fit your team. I am totally agree with @nvogel about self-organising teams.

I mean you always need basic processes, but your team is already working now, no need to brake working things even for the good purpose.

Answer 4

I would also work to introduce the team to the idea that "anyone can work on anything." Don't have, say, three developers who are dedicated to each system: all of the developers should be conversant on everything. They should regularly rotate from one to another, and both the process and the accumulated knowledge about every system should be rigorously documented and discussed.

I would also caution against a "ticket-driven" workflow. Tickets should be an input to a periodic process that determines what the teams are going to do next. (e.g. "a sprint"), but they should not entirely drive that process, i.e. in a "reactionary" way.

You definitely need to build out a testing and "pre-flight" process, whether that is automated or not. So-called "test-driven development." Any "apparently-innocent, innocuous change" can result in regression ... trust me on that. (Even when I'm speaking about my own code!)