9

As a consultant working for a consulting firm, planning projects using Agile/Scrum methodology can be quite challenging.

Considering we do not work full-time for our clients, it is hard to use Scrum to analyze velocity, make good time estimates and always keep work in the pipeline. It is possible to manage the user stories, assign the product owner / scrum master / dev team role or estimate using points, but the whole idea that we can't track our velocity makes us lose a big part of what Scrum is all about.

How would you approach that challenge? Is it possible or recommended to put every client's user stories in one shared backlog, including our internal user stories (like Website development, looking for additional clients, developing in-house projects) and prioritize them depending on the budget or availability they have? This way, we could track our internal velocity, collaborate on multiple projects together and track our consulting firm ROI at the Product owner level (which could be the Practice owner?).

Improve this question

3 Answers 3

Reset to default
11

Why do you think you need Scrum in the first place? You may want to start with Kanban.

Using it, you will:

  • get a clear stage by stage overview of your process/pipeline
  • identify the bottlenecks that prevent you from delivering projects in time
  • identify the pace with which tasks flow through the process, which should help you with estimates

The goal (besides limiting work in progress) would be need to get an even "work in progress" surface over your stages. If you manage that, then your results will be predictable and repeatable. You can tweak your process over time and observe changes on your board(s) to see the feedback earlier rather than later.

Travel time for one work item through the process would provide you an idea of how much you can accomplish in a given time, and how delays are going to impact you, as well.

If your process is large enough, you may need to have a larger board for "projects", and a set of smaller boards for "tasks" per stage - a view of the same process on a different scale.

I've tried this approach for a service-based team (comparable to a consultancy), and it proved quite useful in seeing what we can and cannot do, and what we should do to improve our delivery.

Improve this answer
5
  • Kanban for sure. We're in a similar situation, and tried Scrum as you describe - it was not better. Kanban has (so far) proven to be more effective.
    – MattBelanger
    Commented Nov 4, 2014 at 14:18
  • @alex-leonov It's more about being able to get to track velocity, make better estimates (so that if we re-prioritize, we know if release dates are changing or not), remove the noise on the line so there's only 1 source of work for the internal dev team (1 backlog, 1 true source of priorities) and so on. I don't think a simple Kanban can achieve that. Am I wrong?
    – jpmonette
    Commented Nov 10, 2014 at 10:22
  • @jpmonette Tracking velocity and better estimates are about knowledge of how much of customer-valued work you get done in a unit of time. It doesn't matter much, which tool you use to measure it. In Kanban, you could try this: 1) apply some "estimate points" to the tasks that come in; 2) measure, how many total points come out of the last stage, bi-weekly; (3) now, you can do a rough estimate of when the stuff piled in the first stage will get done. This requires having a stable process without bottlenecks (i.e. you can actually do all you take in, and not increase queue time indefinitely).
    – Alex Leonov
    Commented Nov 10, 2014 at 18:14
  • @jpmonette Removing the noise and making a single source of work is also done without a specific tool. With Scrum it is a unified backlog of multiple products. With Kanban there is only one backlog anyway (the first stage of your process). Noise-wise I prefer Kanban because it shows you the entire pipeline at a glance. You can still use great tools from Scrum, like daily standups and periodic "grooming" of your "backlog", etc.
    – Alex Leonov
    Commented Nov 10, 2014 at 18:17
  • @AlexLeonov Thanks for your detailed answer Alex. I think I was asking the question How before clearly understanding the Why. Thanks.
    – jpmonette
    Commented Nov 13, 2014 at 11:10
4

Don't get to hung up on following a framework. All the frameworks are the practices others came up with to reach the agile principles and values.

Take a step back and ask "why" you want some of the benefits of scrum.

What principles are you trying to achieve? What are the problems or pains you are trying to solve? What are you trying to change? Why are you trying to change it?

From that place maybe you are better informed on why you could pick a few of the scrum/kanban/agile practices and see if you benefit from them. Example: Build a backlog and see how that informs your daily decisions as a team. Then pick another thing to change. The goal shouldn't be to force your environment to look like "scrum" but to solve the business problems you are facing in the best way possible. There are all sorts of ways you can achieve it, so why not look at what it is about scrum is going to improve your environment and then trying asking, what parts of scrum could get us that and what parts do we need to adapt to fit our context.

Good luck.

Improve this answer
1

I agree with the other answers in that Scrum may not be the best for you and you need to identify your current problems first, then look for suitable solution approaches. To help this, I would suggest studying the Lean approach to software development, as Lean can be viewed as the wider foundation of all Agile approaches.

In a nutshell, Lean is focused on

  • empowering the people actually doing the work to make as much of the decisions affecting the work and the process as possible, and
  • eliminating all waste (of time, energy, information, ...) from the development process.

I find this quite a universal approach. Their recurring statement is that one of the best measures of quality for a software development organization is their average response time, i.e. the time it takes on average from the moment the client explains her new concept to when it is actually delivered as a new feature, ready to use and bring in cash. It seems to me that for a consulting firm like you describe, this may be a more useful measure than trying to apply velocity on an area it's not really meant to fit to.

Reading the book Implementing Lean Software Development: From Concept to Cash by Tom and Mary Poppendieck gave me a host of new insights and widened my horizon a lot, casting new light onto a lot of things I already thought I knew. I believe this book would probably help solving your dilemma too.

Improve this answer

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.