Agile in the Mainstream

It means that it's dead in the water, just like anything else that goes mainstream and bureaucrats and consultants get their hands on.

These companies don't really care about anything until they see some way to capitalize on it by selling their services to folks that have no clue. Oh, you say agile is the latest greatest thing John? Ah, let's hire an agile consultant. WTF does an agile consultant do? Agile was at one point supposed to be people over processes, where now each manifestation of it is being as some innovative process yet another consulting company.

Folks, software development is art as much as it is science. You need a scientific foundation, but once you have that, its art. No process in the world make it a perfect practice (because it's not true engineering). I'd like to see Michelangelo or da Vinci create masterpieces under the constraints of a process. Better yet, I'd love to see those two pair paint.

Not at all! Agile is very convenient to a lot of folks, especially consulting companies - it is all just "time and materials". Because of focus on short term agenda it is even more convenient than ever to run in circles without making actual tangible process. So, Agile is here to stay.

I am not against Agile, I am against considering it to be 'improvement' tool. IMO it is 'amplifier'/power tool that improves good dynamics, and worsens bad ones.

I think you are in an interesting place Dan. To protect agile/scrum from those who would change it... you harden it... therefore making it less agile. To prevent semantic diffusion, you more precisely define agile and therefore make it less useful overall. You are getting more rigid, and less willing to apply situationally specific strategies.

I personally don't think this a good place to be, nor particularly healthy for us as a community, or for companies trying to adopt Scrum. At the end of the day, people with one tool, that want to apply that tool to every situation, are going to fail. I'd rather have a full toolkit of options at my disposal. Who needs a one trick pony?

Personally, I don't care if what I do is called Scrum... or even agile. We have to meet companies where they are and help them get better. Regardless of what I am allowed to call it, I will continue to draw on agile principles and practices to help companies get better. I can only hope that my customers value a breadth of experience and pragmatic application of practices and principles over religious debate over methodology.

Great discussion... and even though we don't always agree... nice article!

Mike,

Thanks for coming into the discussion!

You know some of my ideas, but I am not listing them here. Here I am reporting the news, and the news is that Martin Fowler as something to say about Scrum's wider adoption dynamics ("semantic diffusion").

And, JeffS and KenS are more clearly defining Scrum in more explicit terms via the Scrum Guide.

Isn't it interesting that they are doing these things to the Scrum definition?

I should have probably phrased this better. It's engineering in terms of the true definition of engineering, it's not engineering in terms of equating it to bridge or production engineering. These processes just don't work. Software development is a creative process and process constraints only provide setbacks and kill that creativity.

Dead in the water, no, that was wishful thinking. I also wasn't wishing agile was dead, but I was wishing that the hype and unreal expectations surrounding it would stop. Ah, and also that all the bureaucrats would go away.

Also, engineer used to somewhat be synonymous with inventor, but in today's practice, this is no longer the case. Many engineering disciplines today follow some hard core predefined corporate process and mostly work within the constraints of that to ensure all daily operations flow smoothly. There is no creativity there and definitely no invention. So these folks are more operators than they are engineers.

I fully agree to the part about the mainstream and art, but I wouldn't bash the consultants as a whole.

"Mainstream kills" is my favorite phrase here.

Once the marketing departments take notice of a new term, the whole thing is going to be screwed soon. Take object-orientation, XML, web services, SOA, ...

The problem with the stuff we do is that its intrinsic complexity is not visible from outside. This lowers the barrier of abuse, since it is difficult to look behind the empty phrases. How can you tell if someone's buzz about agile or Scrum is true or not? You would have to watch him developing his software. The end product doesn't reveal how it has been built.

Without consultants however, I think that most companies would never get a grip on latest techniques because their employees are too tied up and rarely have a chance for in-depth studies of new stuff. Besides, many people don't study at all, they need to be instructed.

I wonder if this is a natural consequence of success. In terms of Rogers' innovation adoption model, if agile crossed the chasm as of a couple years ago then it may now be in the late majority adoption phase. It's not an "innovation" anymore. If it's not an innovation, it doesn't need a name.

The agile movement did a lot of good. So, what's next?

When you say it did a lot of good, how can we measure that in an objective way? We were all definitely told how great it is, but I'm yet to see numbers that make it any better than any other methodology and/or no methodology/process at all.

In a manufacturing environment, this is easily measured based on productivity (which is not complex when producing physical goods) and quality. In software development, it's not as straightforward to measure these and also to ensure that the confounding factor is the actual process.

Measuring the impact of something requires all other factors to be (reasonably) constant during the inspection interval. This is most likely never the case in software business. In a single project, it seems possible to me, but for a whole company, let alone an industry, I don't see a chance. People change, projects are never the same, technology varies, etc.

On the one hand, I am glad to work in an industry, which is not characterized by repetitive tasks, which are alway the same. On the other hand, this makes it so much more difficult to convince anyone who has no experience with or intuition for software development of new ideas.

The question of measurement is interesting, but perhaps not answerable. Many people demand "proof" that agile "works." No one offers "proof" that the traditional methods agile aims to replace ever "worked." Maybe that's why you haven't seen numbers that satisfy you. Where are the numbers that say traditional methods work so well that we needn't look for better ways? In the end, I think that demands for "numbers" are not straightforward requests for information at all.