I have been reading a lot on Scrum to evaluate its use in our company. I've done a few trials runs with it where the teams were exploring different aspects of it to get some real world feel. I'm not sure though that Scrum is our best option.

I realize this question likely overlaps strongly with others, and I'm looking into those as well.

Here are the characteristics of my company:

  • Small teams of 1-5 people
  • Many projects (almost as many as employees in the company)
  • Virtually no one works full time on any given project due to scope & funding of projects
  • Projects require diverse skill sets, so people tend to hop around
  • A few team members are remote
  • Some projects are process-oriented while others are research & development with no clear path forward for how to complete the project
  • Regulated environment requiring time tracking down to quarter hour

Given these features, it seems that having each project managed with Scrum won't work well since there's a lot of multi-tasking and flux between skill sets needed on one project versus another at any given time. Kanban might work better since we'd just focus on work-in-progress, but I'd be concerned about needing to properly maintain a "global view" of all tasking as well as making sure that timelines are still hit for each project. I can see applying a waterfall-like approach to the more straightforward, process-oriented tasks, but that's obviously not going to work for the R&D projects.

I'm not necessarily looking for a one-size-fits-all PM scheme, but I would like some general top-level guidelines for corporate level management and lower-level guidelines for the PMs on the ground, doing the individual management work.

In terms of tools, we use Jira for task assignment and management, but all projects are not managed with the same level of Jira integration. Many people still rely on MS Project, Excel, and/or notepad.

As an additional note, any time I've tried to discuss PM approaches with team members, they are highly skeptical and cynical about adopting some "process". I am typically hiding it from them that we're even trying something out. For example, many eyes roll when I utter the words "Sprint" and "Retrospective". That's a little outside of this question, but it's still a factor in the success of any approach.

  • 1
    +1 for the "Sprint" eye roll. I am so very familiar with knee jerk opposition to any process other than "I'll get it done when it is done".
    – MCW
    Commented Jan 5, 2016 at 13:55

2 Answers 2


I think Kanban may work best in your environment. And with some people being remote, you're almost forced to use an online Kanban board.

I'll try to address the two issues you raise one by one.

Global View

You can maintain a Global View of the multiple projects by:

  • Having all projects on the same board, and indicate with a color what project the task belongs to.
  • Having a separate project level board, indicating what stage a project in its generality is in.

Personally I'd go for the second option. It depends on the number of concurrent projects to decide what would better, and give you a good overview - without getting lost in extensive management.


Kanban focuses more on the flow than on rigid timelines. That being said, you can still use Kanban in an environment where timelines are important. For example, a simple board would contain three columns: To Do, Doing, and Done. By assign some kind of value (effort, actual hours/days/weeks etc.) to each task, and determining the overall timeline of the project, you can create a simple burndown graph by adding up the total value in each column.

Most online Kanban software has either a built-in burndown chart, or has an addition available to accomplish this. We're currently using Trello with Plus For Trello, and it gives us an idea of the amount of effort remaining in a particular project.

I've used Jira with Greenhopper in the past, and liked it very much. It has a more rigid structure though than what your team seems comfortable with. I would suggest looking at Trello, and set up some simple board to track tasks.

You may also be interested in how UserVoice uses Kanban boards to track tasks. Unfortunately I can't post more than 2 links in this post, so I'll try and post it in a comment.

Good luck managing all your different projects!


Ultimately your current working environment and constraints is not conducive with software development at all.

I would focus on trying to solve the list of dysfunctions that you described rather than trying to engineer a solution around it. You will have exactly the same problems with Kanban and Scrum. Both take dedication, focus, and attention to detail.

  1. Tackle small teams with many projects by looking to group like projects or consolidate projects into frameworks tt support many projects.
  2. Focus on one thing at once. If you have many this in flight for one team you will only create the illusion of more work underway. This will get nothing done and keep you in the perpetual loop. Get the business to prioritise projects. Maybe you can call projects Epics, but only work on one project at once. Finish it, then move onto the next. Read The Phoenix Project.
  3. Create dedicated collocated teams, and another team of remote individuals.
  4. Untill there is a clear path don't start the project. It is the job of the business to give you a clear path and funding to do a project, make them own that responsibility and stop taking it from them.
  5. There are no regulations involved here, just business processes. Time per project broken into capex vs opex meets any need I have ever encountered.

Happy to discuss further...

  • Thanks for your insights. A few clarifying points: we are mostly not a software company, more hardware and consulting/knowledge work, although we do develop some software too. My struggle is that I'm not sure how to focus on one thing at a time (at least at a company/team/macro level). Funding, contractual obligations, and team skillsets are not conducive to this. That same reason is why we can't divide teams strictly into collocated vs. remote. Additional complication...contract regulations sometimes require opex instead of capex. Appreciate any further insights.
    – faircdl
    Commented Jan 13, 2016 at 11:13
  • Feel free to email me ☺, I'm teaching a Professional Scrum Foundations class today bu can reply later... Commented Jan 19, 2016 at 7:17

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.