How NOT to do “Scrum but”

Today we want to talk about overcoming obstacles, or how not to do Scrum but. We have folks in the classes who commonly come with real agile challenges. These are good to hear about and good to share about within class. So, let’s walk through a few of the typical “Scrum but” agile challenges:

We are doing Scrum but…

• we have Distributed Teams
• we are working with Hardware and Software
• we are working in a Structured Environment with a PMO
• we are working on a project with Fixed Scope and Fixed Budget

Can we do Scrum in the face of these agile challenges? Yes, absolutely you can. Is it harder? Sure. But, I’d rather be doing Scrum with these agile challenges, than doing Waterfall anytime.

On those very large projects, you might look at the Scaled Agile Framework for some guidance.

Scrum but… Distributed Teams

Most commonly, we hear, “Can you do Agile and Scrum with distributed teams?” Yes, you can. Is is challenging? Yes, it is. However, it’s better to be doing Scrum with distributed teams, than doing Waterfall with distributed teams.”

Despite being distributed, if Scrum is going to be effective, we are still going to have all of those same meetings; the planning meeting, the daily Scrum, the sprint review and the retrospective, with everyone on the team. Remember, Be Agile. You can do Scrum, but we want to Be Agile. Remember: …individuals and interactions over processes and tools.

Your daily Scrum might end up being at 9pm or 10pm. When I was working with a team in Hyderabad, that’s when ours was. Sometimes we had a sprint review at 10pm with stakeholders coming on the line to look at what the team had done. Don’t sacrifice those! Lots of folks say, “Well, we’re distributed, so we don’t do a daily Scrum. We just can’t make it work. So, we’re doing Scrum but we don’t do the daily stand up.” Eliminating the daily scrum is only going to hurt you, in terms of distributed teams. We’ve certainly seen cultural differences, where maybe it’s harder for one group to raise concerns or issues. Now, all we’ve done is cut that problem at the knees by saying, “Well, they’re not talking as much.” So, now you’ll find out in the sprint review that that’s actually not what they thought that they would be doing. So, watch out for that one.

Scrum but… Hardware and Software

We’ve also had plenty of people come in, more and more, and saying, “We’re doing hardware and software. So, can we do Scrum with that?” I agree, again, it is harder, but I’d rather do hardware and software with Scrum than with Waterfall. In this case, you might need longer sprints. The most common sprint length is two weeks, but maybe that’s a little tight for hardware/software work that we would do. Maybe go out to 4 weeks. I just don’t want it to be, “Well, yeah, this sprint took a little longer so it’s going to be 5 weeks, or 6 weeks for this iteration.” Again, “we’re doing Scrum but our sprint lengths aren’t fixed,” and that would cause some problems. We’ve done a number of hardware/software instances with Scrum. There are lots of case studies around that, as well, that you could take a look at.

Scrum but… Structured Environment with a PMO

Last commonly, people say, “Well, we’re in a structured environment with a PMO and we’re matrixed, and we’re a very large organization, so can we really do Scrum there with these teams, and being self-organizing?” Yes, you can. There’s a large healthcare organization that we worked with, with over a dozen teams, where the PMO actually acted more like an Agile PMO, and helped us slot out which teams would be working with which Product Owners when, and were very helpful to us as we did the work underneath all that.

Scrum but… Fixed Scope and Fixed Budget

There may be issues with fixed scope and fixed budget that we might look at. But even within that, I don’t mind high level scope that we can still be flexible underneath. The principles are we’re going to flex on scope. If it’s a high level, maybe a 1 or 2 pager about what we’re after with this project, within that date, I think we can still do that. We just really have to work with our product owners to know that there are plenty of options to get from Point A to Point B that they’ve committed to delivering. We have some flex in there that we can leverage for the team. So, yes you can still do fixed scope and budget. Again, I’d much rather be doing a large project effort with using Scrum, for that visibility that we’re going to get that we’re really on track across multiple teams, than surprising us at the end that maybe we’re not really on track.

Also, on those very large projects, you might look at the Scaled Agile Framework as some help, too.

Watch out for doing Scrum but, and good luck on your journey.

Case Studies:

Case study: Distributed Scrum Project for Dutch Railways

Improvement, Success and Failure: Scrum Adoption in China

Agile Project Management with Scrum (Developer Best Practices)