James Shore has an excellent post here about whether agile is on the brink of failing and why that could be. I may or may not comment in detail somewhen soon – depending on whether I find the time.

On the other hand, I don’t really need to comment, because I agree with about everything he says in his article. One of the best quotes is as follows:

Maybe we need to be firm and say, „Sorry, if you don’t use agile engineering practices, if you don’t have high-bandwidth communication, and if you don’t include a strong customer voice, you’re not going to succeed. Try something else instead.“ Scrum is popular because it’s easy–and that’s part of the problem.

Exactly.

Average Rating: 4.8 out of 5 based on 272 user reviews.

We’ve been practicing Scrum at work for about nine month now. We got from one team to two teams and will be moving back to one team in a short time (although not really, but more about that later).

We’ve been constantly redefining the process. Sometimes it was little changes like coming up with a few easy rules to make daily scrums move along faster. Sometimes it was bigger changes like defining a new way to do estimation sessions.

In the near future we’ll be adding more teams to work on our product, some of which are offshore, which forced us to rethink our process. Currently nearly everyone working on the product is located in the same office, even on the same floor, so communication between Scrum teams, ScrumMasters and product owners as well as others involved in building the system has been easy and uncomplicated. This won’t be the case once we have teams in another country or even another continent.

One key change that has already been made is that the design phase has been dis-integrated from the actual work of the Scrum team. A designer who only recently was a member of one of the Scrum teams is now working with the product owner, defining designs for user stories.

Estimation meetings now take place with the product owner and designer present. Estimations are therefore made based on the existing design. This is not necessarily a bad thing. In fact it takes some of the risk out of the equation for Scrum teams. We no longer have to estimate something without having a design. Also, since the design is mostly made by one person in collaboration with the product owner and whoever else is of help, it ensures consistency throughout the system.

However, it makes me wonder whether we have already stopped doing Scrum and might just be doing agile. Not that this is bad in any way, it’s merely a question that I might ask. How far can you go from the process as it was defined before you have to admit to yourself that – while what you’re doing is Scrum-based – it’s not longer what you started with.

Is this a bad thing? Not really. In fact, it could come as a relief. Once you’ve drifted so far from the defined methodology that have to stop fooling yourself that you’re actually doing it, maybe it’s time to take a step back and review all the things you’re doing , re-evaluating what is working, what might need improvement and what is simply a waste of time.

On the other hand, sticking to a methodology makes you less eager to give up something that you might not like as long as you’re convinced it is a part of the methodology. (I.e. because daily scrums are such a key item in the Scrum process, you’re less likely to skip them even if you don’t like it.)

In the long run, Scrum is just a word. We might be on the brink of letting go of what makes Scrum Scrum, recognizing that we have our own agile process that has no name and probably doesn’t even need one. Whether we get there and how we will go on from there, I have no idea. But I hope it will be fun to find out.

Average Rating: 4.6 out of 5 based on 276 user reviews.