This is the Way Scrum Ends

September 30, 2014

Processed with VSCOcam with x1 preset

This is the way the world ends
This is the way the world ends
This is the way the world ends
Not with a bang but a whimper.

– T.S. Eliot

Did you ever wonder if this is the future of Scrum? Will it eventually go out with a whimper? I think a lot of people fear this fate for everyone’s favorite framework. Go to a conference or follow your favorite luminary on Twitter and you hear a chorus of “That’s Scrumbut!”, “It’s FrAgile”, or “Welcome to Scrummerfall!” And maybe that’s the way it has to be. Perhaps all great new ideas eventually become diluted in a sea of mediocrity.

I think I hear a longing in some to fight such dissolution. To resist the forces of corporate entropy. Rather than try to fit in, they urge us to confront and overturn the system. You know, subvert the dominant paradigm? Confronting this dissonance is the difference between making a living and actually living.

I wonder if that’s the difference between those who “fire” their customers and those who stay and work within the system. Are those consultants who give up and declare, “These clowns aren’t ready for Scrum.” going out with a bang? And what about those who stay? Are they afraid to make the big moves and just content to fit in? Whimper. Or are they more subtle than that? Can you embrace your client and still change them? Perhaps the “bang” approach is quicker, and more decisive. And maybe, just maybe, remaining engaged is very, very hard, but yields results in the end.

I know, I know…why so bleak? Well, I feel this tension a lot in our weird little community. I’ve been on both sides of the engagements where a respected consultant has tossed their hands in the air and walked away from the engagement because “They just don’t get it.” or “They’re not ready yet.” And I’ve been that poor fool, laboring away within the system, living on a meager diet of optimism and the occasional conference, trying to make change happen. I won’t pretend to know which approach is right, or even when to use these strategies, but I think it would be worthwhile to understand this issue better.


Some Ideas for Managing an Effective Agile Transition

January 14, 2008

Going into an agile transition there are a lot of variables that need to be considered in order to make the transition a successful one. Those variables include:

  1. Timing – Should the transition be made in the middle of a major project or should the transition be timed such that it takes place between or at the beginning of a major project
  2. Transition Strategy for multiple teams – There are two major strategies that I am aware of (and I’m sure that there are many more): make the transition all at once, or start with a pilot project and move gradually toward an agile organization. Each has its own costs and benefits. The culture of the organization can also play a role in making this decsion (cautious vs. aggressive)
  3. How will distributed teams be brought on board. These days it is very common for companies to have either distributed or outsourced teams working around tht world. An agile transition is going to impact them too. How do you manage their part of the transition to agile? Ignore them? Train them up too? And what about the cultural considerations with trying to train someone in Agile techniques from a radically different culture?
  4. How will the training be organized? Do you want to train and certify everyone before starting the first iterations of the project, or is there more value in giving them an orientation, setting them loose, and then returning to run them through the certification course after they’ve stubbed their toes a few times? Again, there are trade offs to each approach.
  5. What sort of coaching support will you provide for the teams?
  6. What kind of additional materials can you bring to bear in support of the teams making the agile transition.
  7. how will the Agile roles (Scrum Master, Product Owner, Team) be mapped to the existing organizational structure. What will be the impact on the people who are currently in those roles?
  8. What kinds of tool support may be required to help facilitate the transition to agile? Communication support tools for distributed teams? Automation and testing support for operations and QA teams?
  9. What are the drivers for the change to Agile? What is motivating this move? A desire for more rapid releases? Perhaps reduce costs? Improved quality? Once you have identified the drivers, then you need to identify the metrics you are going to use to measure the success of your agile transition. Bug count? Throughput? Lead time?
  10. What additional training can be provided in support of this transition? Training in technical practices such as TDD or design patterns?
  11. Is scaling an issue here? Will the teams need to be trained in managing teams at the enterprise level (ie. Scrum of Scrums, Meta Scrum)?

These are just a few of the questions we have been asking as Ibegin the transition to agile for this company. For some of these issues I have opinions and recomendations. For others, it is simply a matter of discovering what the motivations and desires of the company are.


What’s a Waterfall?

December 12, 2007

As an Agile coach and a trainer I often compare Agile methods to “Waterfall”. Waterfall is a bad thing. We all do it. When we are assessing a team, sometimes I hear people say in a desultory tone, “They’re just doing mini-waterfalls.” Typically when I think of waterfall processes I think of a project that is organized as follows:

Analysis ->Design->Implementation->Test->Release

Or something close to this (you may use different terms). Basically, we do this, then this, then this… and repeat. Typically this method is criticized as creating too much specialization, not enough collaboration, too many hand-offs, and so on. So far, none of this should be  a surprise to anybody. I can slap this sort of project together in MS Project in my sleep.

Now, let’s take a look at our Scrum task board. Here we see something similar to the following:

ToDo, Test Complete, In Progress, In review, Done

Interesting. In a typical case, can we do any of these steps out of order? No.  Can we skip steps? No. Hmmm…let me show you those terms one more time:

ToDo->Test Complete->In Progress->In review->Done

Oh, now that’s kind of interesting. It seems that the Agile process that we are using to track our tasks looks remarkably similar to the Waterfall process. But that can’t be right! Let’s put them side by side and see if we can find a difference:

AGILE:                 ToDo->Test Complete->In Progress->In review->Done

WATERFALL:    Analysis ->Design->Implementation->Test->Release

Oh nuts! Now I’ve really done it. Perhaps its a matter of scale. Perhaps its a matter of the order of magnitude difference in the activities. Or…perhaps using the “Waterfall process” is a straw man that we shouldn’t really be using when we talk about the benefits of Agile. Perhaps the greatest difference between how things are done on an Agile project, and whatever folks have done in the past is not in the order that the tasks are completed in. You can rename the tasks, reorder them all you want. But you still end up with the same thing. Call it something different, “a mini Waterfall.” If it makes you feel better, great. But my argument is that this is not the key difference between Agile and other methods. The difference lies someplace else, not in the ordering of the tasks – because, if we just compare the ordering of the tasks, guess what? Agile and Waterfall look the same.

Maybe I’ll sleep on this tonight and look back on this tomorrow and regret it. After all, I’m a good little ‘Agilista’ and I don’t want somebody to stamp my meal card “No desert”.  Perhaps I’ll go back on my medication tomorrow and realize that this was all a hallucination. But somehow I doubt it. If we are looking to explain to others how doing an Agile project is different than others, perhaps we should avoid this comparison and focus on other differences.