A software development workflow for a company of 2-4 developers?

Question

I work in a research group of an architecture firm that contains around 4-5 developers at any given time. We develop a lot of the in-house architecture software, and our skillsets range from C#, to Java, to PHP, to most of the major web languages (like JS, HTML, SQL, etc). We are definitely a group of transdisciplinary skills. Our work involves not only working on software, but also communicating with the architects within the firm to better improve current software and develop new tools.

As the number of developers increase, and as the result of us just releasing a new piece of software for commercial release, we noticed that we definitely need and definitely will need a new way to manage our team. That is, to coordinate projects, to monitor/track changes (git, or any version control), to manage features, and much more. As we are a team of many skills, I am the only developer in the team that came from an actual software development team. Tools I used in my previous gig was project management software like JIRA, Confluence, HipChat, git, and more. However, my previous company was a firm of 100+ developers, while this team is only 4-5, so using JIRA, for example, would be overkill.

I am in need of some help and suggestions. What type of project management software can we use to track the things I listed above? What type of workflow can we adopt, i.e. Agile, Scrum, etc?

Answer 1

This can actually be a really fun place to be. Given the size of the team, I probably wouldn't add any technical overhead by trying to bring in technology (software) to help with the problem...maybe a wiki. But, you get to define what it should look like based on various considerations/concerns.

For example, if your corporate culture places a really high emphasis on time/deadlines - Scrum might be a good idea; or, more traditional project management. Other cultures may be less deadline driven and decide something more like a Lean Software Development (just in time) approach is okay (not that there aren't deadlines, just an example). Or, some combination.

What this comes down to for me is a popular refrain with me: Software won't save you. It sounds harsh sometimes when said that way but it basically means: Don't let technology define your workflow; rather, define your workflow and discover technology that makes it better.

At this point in the game, you folks may be better off with a wall, some index cards, and a source control system with regard to technology.

As for what project management methodology to use - in all honesty - they're pretty similar at the highest abstract levels:

1. A list of things to do (product backlog or Work Breakdown Structure),
2. A way to track progress (task boards, information radiators, or status reports),
3. A time for reflection and continuous improvement (sprint review/retrospective or the PM term I can't remember right now).

Again, I go back to corporate culture. Do you have a lot of folks who know about Scrum? If so, start there. Maybe you're already using a task board of sorts, which makes Kanban or Lean a more likely transition. Maybe most of the team, at some point, took Project Management courses in college and a non-agile approach would be easiest to transition to.

In summary:

1. Inspect and adapt loops for improving the process built into the process.
2. Until you can figure out what to do without electricity, don't worry about whether to use AC or DC.

ps. The concept of the transition comes from evolutionary theory in biological systems (Jeff Sutherland touches on it in one of his Google Tech Talks on Scrum). Basically, the way evolution works is slight mutation over multiple generations, yeah? But, if there is too much mutation in a single generation then it can have devastating affects on the system/subject. Same is true for teams. So, figuring out where you are and taking baby-steps to get where you want to tends to be less traumatizing then saying, we want to be over there - now! - Go!

Answer 2

One of the main things that you must not forget when you start out is to start out small and simple. Although it may be good to implement a framework or a well established method of some sort such as Agile or Waterfall but you don't want to overwhelm yourself with the overhead processes to implement the entire framework. Implement more only when you feel the need to.

The principals of cost and benefits need to be kept in mind when applying a defined process flow. If a certain process doesn't have a significant purpose, or if the benefits of it is insignificant, then most likely you can take a shortcut.

You might want to start out with Agile or Kanban.

1. Start with defining a simple delivery of scope, something that might take less than 2 weeks for your team to deliver.

2. Write them down in a card or sticky note.

3. Put them on a board in order of priority, with the top item being the highest priority. Start working on them from the top.

4. After putting the delivery items on the board, break them down into tasks that is needed to be completed in order to complete a delivery.

5. Put them into phases such as To Do, Work In Progress, and Done.

6. Remember to revise the list every 2 weeks, and only after that 2 week "sprint".

Answer 3

I'd recommend having a look at Workgroups if looking for a solution still. It is a highly customizable solution with lots of great features for managing tasks, tracking time, automating workflows, etc.