What's a project management methodology suitable for a small team that addresses both operations and rapid-fire small projects?

Question

I work for a small distributor of technical products. We're about 20 employees strong; our primary business involves sourcing and selling often-obscure technical equipment and accessories.

I've been made team lead of our three-person "data team". Our responsibilities revolve around the maintenance of the rapidly-changing data on which our business depends.

My goal: I want to adopt an effective methodology (or combination thereof) for my team that acknowledges our main challenges:

• My team is involved in both projects and in operations. We must make reasonable progress on priority projects while always reacting to issues brought to our attention.
• Our assigned projects are many, small, and typically short-lived.

In short, the environment is often organizationally chaotic. Several small projects are completed weekly, but even more are created meanwhile, and throughout it all we're bombarded with issues and requests major and minor. Our task lists are growing at all times.

(I won't delve into the steps I've taken to help resolve the 'company culture' side of the problem. I'm concerned here with doing right by my team and by the work we are reasonably capable of doing.)

Is there a methodology (or hybrid) around which to structure my team's work? The vast majority of the methodologies and tools I've encountered are centered around major, multi-step projects that are attacked by project-focused teams. This is not our environment. I'm hoping that people brighter than me have developed effective ways to operate in these or similar conditions. I don't expect a perfect system, but I'm struggling to even find one that will serve as a starting point.

[Note: our company's official project management tool is TeamworkPM. My team uses this daily. However, I'm interested more in a system than a tool; I can adapt our use of TeamworkPM as needed.]

Answer 1

As RubberDuck noted, kanban seems like a pretty good place to start in terms of process. Just constructing the board and flow will probably give you and the team a lot of insight into the amount and nature of the "chaos", and if you can use it for a few weeks, gain a lot more insight into bottlenecks, loops, blockers, etc. Just be sure to use columns or a flow that actually maps to your current reality/steps, not an idealized version, or what you think it should be eventually.

Answer 2

Scrum!

I see two levels of Scrum to fit your description. Level one, a Scrum program management system. Use Scrum to backlog and prioritize your various projects. You may have to take some liberties with sprint timeboxing to accommodate, or then again, maybe not; maybe the length of the Sprint is a good time to re-assess and re-prioritize and evaluate the project's continuation.

The second level would be to manage each project through Scrum.

---

What you said:

Our assigned projects are many, small, and typically short-lived.

and

...the environment is often organizationally chaotic. Several small projects are completed weekly, but even more are created meanwhile, and throughout it all we're bombarded with issues and requests major and minor. Our task lists are growing at all times.

and

We must make reasonable progress on priority projects while always reacting to issues brought to our attention.

Why Scrum fits:

For you, I think the backbone of how Scrum will work is it's ability to tame chaos, and deliver constant results.

By committing to do certain items (Sprint goals) within a short period of time (Sprint) you minimize the effects of constant change on your ability to make progress, and you keep morale up because you are constantly making progress and constantly delivering.

Scrum is designed as a way to manage complex and changing projects. It's not limited by focus or product - anything that fits as complex or has changing requirements can, in my experience, benefit from Scrum. In my experience (I'm not a software developer by the way - we're using Scrum to manage the design and development of hard goods [highly engineered hard goods]) Scrum works very well for collections of short projects and for long, complex projects.

It also serves really well when your "assignments" come from multiple places. Sometimes it can be hard to manage conflicting priorities from multiple groups. What I recommend here is to organize the various groups into a quasi-council to serve the "Product Owner" role - and let them reach consensus on what will be worked on each Sprint, and let them organize and re-prioritize the backlog. This can work wonderfully with the right approach to get drastically better results and better satisfaction from multiple departments.

What Scrum does well (IMHO) is that it does not attempt to stop the chaos, but it provides a way to tame chaos, and makes it sustainably manageable.

---

Afterthoughts

I purposely avoided getting into the nitty gritty of how Scrum works, describing the roles, ceremonies, etc. There is information ad-nauseum about this available on the web, and many other questions that have discussed these topics on this SE site even. I will however share some of my favorite resources for the basics. Collabnet's e-learning series provides a great overview of all the basic concepts in easy to follow video format. Mountaingoatsoftware is Mike Cohn's site and he has many good blog articles, powerpoint presentations, videos, etc. available for free, and more detailed video training and even in-person training available for purchase. (Mike is one of the primary founding contributors to Scrum's development). And there are many good books on Scrum - a popular choice, and one I'll admit I've only made it part way through, is Essential Scrum by Ken Rubin.

I'm less familiar with hybrids, but I know Scrumban is a popular hybrid approach for combining Scrum practices with a Kanban "pull" system. I personally haven't done enough research on it to offer any insights or opinions; at this time, I'm merely aware of it's existence :)