Q&A with University Scrum Students: Doing Agile in Tough Environments

This is part three in a series of blog posts derived from a one-hour Q&A session I had with University of Alabama students who were using my Essential Scrum book as the core of their course curriculum. You can read the prior two blog post here:

How do you do agile in a fixed-price contracts environment?

I have a detailed answer to this question that I will elaborate on in a future blog post. For now, have a look at “Scope is the Antifragile Degree of Freedom.”

Can and do government agencies use agile?

Yes, I personally have done work with the DOJ, Tarrant County, Texas, Larimer County, Colorado, and with both large and small defense contactors. From a training perspective, working with these entities is no different to me than working with a commercial client.

Over the past ten years I have seen governments more willing to embrace agile. In the past, bidding to use agile on a government project was more difficult because of regulations surrounding DOD-STD-2167A in the US (that basically prescribed Waterfall). Changes in procurement have made it easier for agile to be used on government projects.

One issue I have noticed on some government projects is that during sprint review meetings, government bureaucrats show up, which is OK—stakeholders are encouraged to attend! However, these bureaucrats aren’t there to provide feedback, they are there to evaluate progress and confirm certain contractual obligations are being met. As such, they provide no real value to achieving the goal of the sprint review meeting, and can become a roadblock. See my blog, “It’s a Sprint Review Not a Sprint Demo!

You work with many different companies. What are some of the common problems or obstacles that you have to overcome?

Although I acknowledge that some heavily regulated environments can be a more difficult (but possible) to navigate with agile, I truly believe that agile can work in almost every environment. Nearly every company I work with initially believes it is the exception—that its company is unique and its problems are unique, but on closer inspection it usually isn't. I can typically classify each company’s problems into various patterns that tend to repeat themselves time and again, across industries and company sizes.

The most frequently recurring (problem) pattern is there is no shared understanding of core agile principles through the value chain, which results in large disconnects. (You can read more about this issue in this blog).

The second biggest problem I encounter is overall resistance to change based on conflicting mental models (people are familiar with Waterfall and less so with agile).

Note: At this point I asked a question back to the class. “How many people have studied Waterfall?” About ½ said they did. I then described how more and more frequently these days I ask that question in a corporate classroom and fewer and fewer hands go up. In the past, the answer to that question used to almost always be 100% of the people in my classes were familiar with waterfall.

Remnants of the waterfall tradition can impede the successful adoption of Scrum but they don’t have to derail it. With proper training in both the how and why of Scrum throughout the value chain, most organizations find that Scrum is an effective tool for their development efforts.

What's Next in the Series

This leads to the next blog in this Q&A with University Scrum Students’ Series: “Finding Joy in Agile.”