Collaboration: At the Extremities of Extreme
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Agile in the Mainstream
Posted by Dan Mezick on Apr 01, 2010
Mainstream Agile is an idea whose time appears to have arrived. Larger consulting services firms are now touting "agility", with firms like IBM Global Business Services and Cap Gemini pitching Agile-related service offerings. Offshore firms like Cognizant and ITC Infotech are also active in the Agile software and services space.
Mainstream Trends
A quick scan of the online job sites shows a remarkable increase in the use of the term 'agile' in job descriptions. Here is a sample of the data changes in roughly one year, from the job sites Dice.com and Monster.com:
| Term found in Job Listings | Dice, July 2009 | Dice, April 2010 | Growth |
| Agile | 2084 | 4088 | 96% |
| Scrum | 755 | 1222 | 61% |
| Term found in Job Listing | Monster, July 2009 | Monster, April 2010 | Growth |
| Agile | 1756 | 3031 | 72% |
| Scrum | 379 | 755 | 99% |
Given this kind of sudden mainstream popularity, what does it mean for Agile in general? What does "mainstream" Agile look like? What's in mainstream Agile? Scrum is the most popular Agile framework. As such, it is a good focal point for discussing mainstream Agile. So, what does mainstream Scrum look like?
According to Martin Fowler of ThoughtWorks, Flaccid Scrum is the new pandemic. The pattern has three steps and looks like this:
- They want to use an agile process, and pick Scrum
- They adopt the Scrum practices, and maybe even the principles
- After a while progress is slow because the code base is a mess
According to Fowler:
...projects get into trouble for poor internal quality all the time, the fact that a lot crop up under Scrum's flag may be more due to the fact that Scrum is so popular at the moment then anything particular to Scrum.
Now here is where it gets interesting. Fowler says:
I always like to point out that it isn't methodologies that succeed or fail, it's teams that succeed or fail. Taking on a process can help a team raise it's game, but in the end it's the team that matters and carries the responsibility to do what works for them. I'm sure that the many Flaccid Scrum projects being run will harm Scrum's reputation, and probably the broader agile reputation as well.
Mainstream Meaning
What does this mean regarding the "mainstreaming" of Agile? It means that Scrum as a term may become meaningless over time, as organizations who claim to be doing 'Scrum' are in fact doing something else, and callng it Scrum. Jeff Sutherland and Ken Schwaber have a name for it: they call it Scrum-butt.
Fowler has a term for the "watering down" of a previously well-formed definition - he calls it Semantic Diffusion:
Semantic diffusion occurs when you have a word that is coined a person or group, often with a pretty good definition, but then gets spread through the wider community in a way that weakens that definition. This weakening risks losing the definition entirely - and with it any usefulness to the term.
In response to the trend, Ken Schwaber and Jeff Sutherland, co-creators of Scrum, have created a definitive and authoritative definition of Scrum, called the Scrum Guide. This freely downloadable resource describes Scrum. The document is intended to strengthen and sustain the Scrum definition. According to Ken Schwaber:
Scrum has been used to develop complex products since the early 1990s. This paper describes how to use Scrum to build products.
A excellent discussion of the Scrum definition appears on Dominique Stender's blog post on Ken Schwaber's "Confusion about Scrum". In that post he echoes Martin Fowler's stand on semantic diffusion:
I also agree with Ken that it is required to have one (!) formal description of what Scrum is. As [Ken] points out, in application Scrum is mixed up with other agile approaches such as Kanban, XP and others. This makes it important to have one (!) "master copy" of what is Scrum and what is not Scrum. A benchmark is required.
Mainstream Agile: Of Products and Product Owners
The "mainstreaming" of Agile may mean that Scrum as defined by Ken Schwaber and Jeff Sutherland is even more polarizing than ever. Even as Agile goes mainstream, the co-creators of Scrum are in fact hardening the definition of Scrum. What is going on here?
Case in point: the current Scrum Guide states that the Product Owner is "always a single person, never a committee." Others in the blogosphere are talking tough now about Product Owner problems in Scrum implementations. For example Roman Pichler of InformIT writes in an article on Product Owner problems:
A product owner committee is a group of product owners without anyone in charge of the overall product. There is no one person guiding the group, helping to create a common goal, and facilitating decision-making. A product owner committee is in danger of getting caught in endless meetings with conflicting interests and politics - something also referred to as "death by committee." No real progress is achieved; people stop collaborating and start fighting each other.
Always ensure that there is one person in charge of the product, an overall or chief product owner who guides the other product owners and facilitates decision-making, including product backlog prioritization and release planning.
The "mainstreaming of Agile" seems to be setting up a need for a very clear definition of terms. The term 'Scrum' is being actively defined and sustained by Scrum's founders, via the definitive Scrum Guide. What the term "Agile" actually means is becoming more and more important, as Agile goes mainstream and becomes more subject to semantic diffusion.
- This article is part of a featured topic series on Agile
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Agile Development: A Manager's Roadmap for Success
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Dead in the water
by
Ilya Sterin
Posted
Re: Dead in the water
by
Konstantin Ignatyev
Posted
Re: Dead in the water
by
Alexandre Poitras
Posted
Re: Dead in the water
by
Ilya Sterin
Posted
Re: Dead in the water
by
Ilya Sterin
Posted
Re: Dead in the water
by
Hermann Schmidt
Posted
Watering down Scrum?
by
Mike Cottmeyer
Posted
Re: Watering down Scrum?
by
Dan Mezick
Posted
Late majority phase?
by
Dave Nicolette
Posted
Re: Late majority phase?
by
Ilya Sterin
Posted
Re: Late majority phase?
by
Hermann Schmidt
Posted
Re: Late majority phase?
by
Dave Nicolette
Posted
-
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. -
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.
I disagree it is engineering and just as engineering no process is going to make it perfect either. The difference in other industries is that they have a legal liability (imagines having a one year warranty on a software...) and that the cost of a recall is very high (in software we just send a patch) so they put much more emphasis on quality. -
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.
12 comments
Watch Thread Reply