My Latest news item on InfoQ:
Here’s some of my 2012 predictions, ok…. guesses:
1. Real Options will become a bigger part of planning software and application development projects. Unlike other projects we’re not discounting a straight stream of cash flows. We’re discounting a complicated tree of decisions.
2. Scrum Will Breakup – The forces that made it popular will rip it apart.
3. Agile’s Luster Becomes Rustier – The torrent of zealous marketing and hype will take its toll on agile. There will be increased backlash and doubt through 2012.
4. The Kanban Rock Will be Turned Over – Executives will look into Kanban for software development and ask “Where’s the value here?”
5. Managed Service Providers Will Enter Software Development – Utilizing contingent labor available through sites like Guru.com they’re finding ways to drive down the costs of software development for cheap, simple, fixed bid projects.
6. Agile 2.0 Bandwagon – The agile 2.0 proponents will attempt to reboot life into the “movement”.
7. Startups get faster, leaner – Driving towards continuous, high quality delivery…some startups will take Eric Ries Lean Startup philosophy further and push tool vendors, or even create their own tools.
8. Tools Start To Takeover – We may have stretched the limits of new practices and patterns. Time for the tools crowd to take over? NoSQL and the rejection of OOD&D as too complex for most development efforts may yield simpler higher quality tools.
I never can seem to round out my lists to 10. How do other writers do that? Oh well. See you in the new year. 🙂
Over commercialized, overused and mis-applied the word “agile” has become synonymous with being better, faster, and cheaper. The hype around the “A” word is nonsense. Most of the software vendors, consultants, and marketers plastering agile on everything are simply capitalizing on the popularity of some ideas that aren’t even correlated with what their selling.
Agility is not a panacea. It’s not a software tool. It’s not a product you can buy. To my opinion it was a state of mind, a way of approaching problem solving.
It’s now lost that meaning. It’s original luster is awash in a sea of hyperbole and advertising. When someone says they’re agile or they practice agility….I no longer know what they mean. It might be that they read a book, they use some self-professed agile software tools, they have a poker planning card set, they bought a CSM certification, or they recently attended some conference on agile software development. Stop Agilizing Everything was written in protest to the fluff, and monetization of agility.
Will it stop? I doubt it.
Instead it will kill itself through abuse. Eventually it will become the worn fad of the day. In disdain and disgust we’ll turn our backs on the “A” word and seek something with more substance.
Scrum, probably the most widely adopted agile software development practice, is cracking up. The signs are evident and this article discusses the trend and what it means for agilists today. If you practice scrum, are thinking of using it, or have used it in the past you’ll find interest in this article.
Oh yeah? Prove it!!!
It’s a truism that rapid growth and popularity put a strain on organizations, movements, ideas…….or ,more fundamentally, the people comprising these very human vehicles. As an idea ferments and then exponentially amplifies to encompass a wider politic of devotees and admirers there is the impending fog of dissent with the origin, the core. From this comes splintering, debate and eventually more novelty and innovation.
Fine, but what about direct evidence for the rift in scrum?
03/05/2009 – Scrum But…Test. Jeff Sutherland.
09/15/2009 – Ken Schwaber resigns from Scrum Alliance
06/15/2010 – Ken Schwaber establishes Scrum.org
04/20/2011 – The CSM certification wars
07/26/2011 – Forrester calls Water-Scrum-Fall the norm
08/02/2011 – Bloggers Suggesting Scrum Variations
As the agile movement hybridizes and evolves scrum is feeling the brunt of this pain. The forces of hybridization are ripping scrum into distinct camps whose views are aligned with their respective organizational needs. Who are these camps and what will ultimately happen to scrum as this spider web is tugged from it’s anchors?
The Enterprise – Most enterprises don’t build software as a core part of their operations. Projects here are usually centered on delivering some base set of functionality for a fairly fixed price. Stability and low cost of operation are prized. The organization doesn’t usually see this as an investment…but as an expense to be managed and tracked. The pressures enterprise software development groups face at the capital planning phase and the release phase have sculpted the Water-Scrum-Fall that’s prevalent.
The Software Companies – In contrast to the enterprise, software companies build software as their core product. It *IS* their operation. Software companies see their products as an investment and it’s life cycle is fairly unlimited, or at least tied to the life-cycle of the company. Pure scrum works in these companies fairly well. There’s usually still pressure to reduce the number of production releases but on the planning side managing features in a backlog fashion is workable, even preferable when you have a product that has a potentially unlimited lifespan.
The Startups – Startups face a different set of pressures from their venture capital investors. The need to rapidly introduce new features and create value to customers and investors by gaining a competitive advantage quickly is paramount. Startups are tearing scrum towards the Lean Startup methodology professed by Eric Ries. The focus here is continuous delivery of new software: stability be damned. Usually these startups don’t build software that’s mission critical or life threatening.
The Purist Methodologists – Among these are the various scrum trainers, agile coaches and general agile philosophers who profess a puritanical approach to scrum. Their insistence on a dogmatic approach to scrum are rooted less in practice and more in theory.
What are they doing to scrum…where are they taking it?
These groups are doing what’s natural. They’re catering scrum to their practice and profession of application life-cycle management ( ALM ). But this tug of war for scrum’s future is changing it. Instead of a simple, one-size fits all methodology, it’s becoming a framework of patterns & practices.
You can see this through the introduction of scrum extensions, which is a natural way of recognizing the various groups that have adopted scrum in some fashion. With scrum becoming an umbrella concept, it’s importance is melting away. It will devolve and eventually disappear. Instead the extensions, much like design patterns in software development, become the value added pieces that development teams will use and rally around. Each camp will likely pool certain extensions, patterns as their ‘methodology’. In time, these flavors of scrum will tear it completely apart.
Scrum’s popularity will likely be its undoing. But is this something to be avoided or stopped? Hardly. Hybridization and evolution of scrum is a natural process that is both pragmatic and necessary. Jeff and Ken’s baby is growing up and leaving the agile house. The original agile manifesto signatories accomplished their mission; they broke the one size fits all ALM world down. The new heterogeneous landscape of practices and patterns, while less clean than the bi-polar world of agile vs waterfall, is primed with greater opportunity for innovation.
Latest news item on InfoQ: http://www.infoq.com//news/2011/12/water-scrum-fall-is-the-norm
Among the aroma of fruit cake, hot cider, and sub-zero temperatures Santa Claus announced today that his North Pole Workshop would switch to using agile practices in toy production. Santa sighted a number of reasons for the change, among them:
- Increasing need to be first to market against growing competition.
- Better collaboration between kids’ toy lists and toy developers.
- Reducing the risk that kids don’t get what they want.
- Increasing quality and accountability in toy development and delivery.
According to Santa, “We’ve analyzed this decision for some time and it became clear that change was needed after re-reading little Timmy Todsnockerdellturtlefoof’s complaint letter from last year. Instead of receiving a bicycle, as stipulated in his toy list; he got two fake icicles.”
The well publicized failure last year to meet the requirements of Timmy’s wish list was not the first time Santa’s North Pole Workshop hadn’t delivered, but in this day of social media and instant updates; the story took on a vicious viral characteristic….hitting #1 in the tweetosphere for a full month with the hash tag: #TimmyTodsnockerdellturtlefoofGotIcedBySanta.
When asked what type of agile practice the workshop would be adopting, Santa replied: “Scrum. It’s well known, proven, and being used in some isolated corners of our workshop today.” Some muted ‘boos’ could be heard from the audience.
Santa went on to say that Rudolph The Red Nosed Raindeer would head up the agile transformation of the North Pole Workshop in conjunction with an outside agile consulting firm to be named later. That development confirmed for some that Rudolph was next in line to take over The North Pole. Rudolph was on hand to comment to reporters after the announcement:
“We’re looking at one of the big 5 consulting firms, but we haven’t ruled out the smaller players. Look, what’s important here is that we get to done. I have a nose for this kind of thing. I’m not a dreamer..I’ve been a servant leader for a long time…I realize this transformation isn’t going to happen overnight, there will be pain and there’s a lot of existing process and procedure that will have to….well, frankly….go away. But, one step at a time. I expect we’ll have a more detailed plan in May or April. Talk to me then.”
Reactions among the North Pole elves was varied. One older elf man pointed out that Santa had to be dragged “kicking and screaming to the decision. He wasn’t on board at all. Rudolph, Frosty, Mrs Claus and the Yeti really had to sell him on it. When they broke out Timmy’s letter to remind Santa of the increasing defect rates in his shop….he went ballistic. I mean he really lost his cookies. Then the Yeti put his foot down. I think Santa knew what that meant.”
Others, like a younger elf woman, had a different opinion on the switch to agile: “I’m fine with the whole agile thing, but I guess I don’t understand why they chose Scrum? I mean….from what I read XP is way better and more applicable to our environment. I really don’t think the elves, particularly the older ones, will like daily stand-ups. I mean most of them can barely wake up every day….let alone stand up.”
Still another view was held by Donner, “What about Kanban? No one’s talking about Kanban, but in the reindeer house we use it all the time to limit HIP ( hooves in process). I bet Rudolph moves us there. I think there’s going to be a power play here between Santa and Rudolph. It’s a battle that’s been brewing for centuries.”
“Give me a break. Agile? Really, let’s knock off the buzz and hype. So we goof up on a few thousand toys out of the billions we make a year. How’s agile gonna solve that? I don’t get it. I guess I’ll ride it out and see where this goes. But limiting HIP in the reindeer house has done nothing but give some of us more time on our hands. I don’t think that’s what Santa wants.” said Blitzen.
Frosty, while at the announcement, declined to make any official comment but did say that he favored a balanced, pragmatic approach, one that would focus on the workshop’s needs rather than a dogmatic approach.
Mrs. Claus had this to say: “Rudolph is very bright. I know he’ll make this work. He knows where he’s going.”
Strangely, the Yeti, was not present. But his footprint could be found in the comments that others made.
Outsiders also came to hear the announcement. The Easter Bunny had this to say: “I understand what Santa’s doing and to be perfectly frank he’s in a different position from us in Easter Hollow. He’s facing some real time to market issues and competition with Mom & Dad, Grandpa & Grandma, and others. His competitors have real advantages in local sourcing, customer relationship management, and technology. Santa just hasn’t kept up and now it’s time for a radical change. I don’t think anything he’s doing is going to change our approach. We pride ourselves on stability of delivery and with a 98.2% market share on Easter…we’re just not facing the same issues.”
The Easter Goose has the other 1.8% of the Easter market.
Merry Christmas agile community. Enjoy your holidays, stay safe, and as always….take care. 😉
Agile universities, certifications, agile consulting, traveling coaches, planning poker card sets, agile software products, agile modeling, agile arm bands, countless agile books and the crazed cycle of agile conferences.
The buzz cycle is in overdrive and it’s electrocuted the business world with the promise of faster, better and cheaper. This article is a plea to stop. Stop all the hype, the opportunistic profiting, and the marketing.
Good Intentions Turned Ugly
What started out as a challenge to the software development community to think outside the box ( invent, create ), abandon a one size fits all model to approaching software development and execute your projects in a pragmatic fashion that takes account of the context you’re working in….has turned into a marketing machine of horrible dimensions.
There was a time when people talked agile and you knew they were on the vanguard; trying to solve the real problems. They cared. They were passionate, deliberate, and informed. Now, when you hear a colleague professing agile…they’re most likely drinking the kool-aid poured by the snake-oil agile coach from Denver or San Fran. The formulaic response to the core problems is all too familiar and draining:
- Poor Requirements – You need user stories and iterations.
- Defects in Software – Continuous integration and TDD will solve that.
- Bad estimation – Use planning poker. It always works.
- Change Management – Break it up into iterations and embrace the changes given in iteration reviews.
I’m not knocking these techniques. Many are novel inventions that do have their place in SD/AD. But instead of being offered as potential options, patterns, techniques to solving a problem among many other potential solutions; they have become a sales pitch by the opportunist preying on desperate CIOs. Buyer beware. Bubbles pop and my gut says the needle to prick this balloon is getting very sharp and close.
Let’s stop agilizing everything. Good ideas, tools, and techniques don’t need the word ‘agile’ pre or post fixed to be worthwhile.
Come Back Home
So turn off the scrum-o-matic. Wipe the agile makeup from your face, and put the kanban sequin dress away. There are still problems to solve. We haven’t unraveled this thing called software development. It’s devilishly vexing and we need good minds focused on it. Become neo-software-amish, come back home to the forest of software trolls and invent/create again.
This article will address a common reaction to those presented with the possibility of adopting agile in their enterprise: skepticism. CIOs, application development managers, directors, and senior architects will glean the greatest insight from this but development professionals and project managers will find interest too.
On Being Skeptical
As a software professional your skepticism is not necessarily misplaced. There are plenty of agile coaches in the market today professing to deliver faster, better, and cheaper on a regular basis. Their message is honey in the ears of the right executive. It becomes even sweeter when you consider the economic climate that many businesses are facing today. There is opportunism here and it would be well advised to vet any agile coach.
How do I know an agile coach is worth the money?
I’ve devised a simple matrix ( below ) to help guide one in validating an agile coach.
|Weight||Coach 1||Coach 2||Coach 3||Coach 1 Score||Coach 2 Score||Coach 3 Score|
|Number of Projects Managed||3||2||17||3||6||51||9|
|Years of experience in SD/AD||2||5||24||7||10||48||14|
|Highest Budget Management Experience ( 1 = true, 0 = false )||1||1||1||0||1||1||0|
|Number of References Validated||3||3||8||1||9||24||3|
|CSM Certification ( 1 = true , 0 = false )||1||1||1||1||1||1||1|
|PMP Certification ( 1 = true , 0 = false )||1||0||1||1||0||1||1|
So let’s talk through this matrix a bit. First, I give pretty heavy weighting to experience here. In truth we’re not just looking for an agile coach we’re looking for someone with the battle scars of being in the AD/SD world and knowing when and where agile works vs more predictive methods.
We also want to know that they’ve actually implemented agile methods in other places hence the need for validating references. The key word here is “implemented”. There are plenty of folks who can regurgitate the agile manifesto and paraphrase the thinking of leading agile theorists, but agile coaches should show a track record of making it happen.
Budgetary management experience, in my opinion, is essential. If they haven’t managed the dollars/euros/yen around a capital project ( or operating costs ) then they may have a very misguided notion of why projects succeed or fail. The CSM or PMP who was merely accountable for a timeline with only a misty concept of how it related to money is ill-equipped to profess a transformation of your SDLC process. Why? Agile techniques profess delivering software in iterative cycles ( every 2 weeks ). If some level of requirements aren’t complete by the end of each iteration you have two options on a fixed bid capital effort:
- Don’t do that functionality.
- Postpone it until you do have the capital available.
This sounds fine in theory, but the truth is that every system has some minimal set of requirements that must be completed for the software to be functionally usable. If the money runs about before the agile projects succeeds in delivering this minimal functionality then your project will be seen as a failure.
Certifications show learning of theory. I weight them low, but still think its practical to have these ( Certified Scrum Master and Project Management Professional ) if an agile coach is selling himself as a professional in software development delivery. They should understand and know agile as well as more traditional management concepts and techniques.
Lastly, you should realize that agile adoption is not just a function of the agile coach. The organization needs to be willing and able to accept the changes agility will introduce.
But my current process works, so why should I switch to agile?
If you have a working process and there is no immediate need to push you to agile then you should take the time to map out a strategy for your development shop. Agile can be beneficial and Ryan Martens at RallySoft does a decent job of articulating when agile methods can benefit a development project. His rendition of the Uncertainty vs Complexity diagram proposed in Stand Back and Deliver gives an AD manager a basic tool for plotting his/her projects along these two broad metrics.
What are the benefits if agile is applied to the right type of projects?
Better Risk Mitigation – Agile methods emphasize iterative delivery of software. A standard cadence and check point to the project sponsors allows for defects, requirements misunderstanding, and general issues surrounding the effort to be mitigated on a timely basis. Couple this with a daily stand up meeting where team members determine how to resolve issues and coordinate work and risks to the development effort are generally better managed.
Testing starts earlier – Agile development emphasizes vertically slicing your application and developing functionality incrementally. This is a technical challenge, but assuming the development team can tier the system architecture this way, then your testers can usually start functional testing much earlier in the development cycle.
Increased Sponsor Satisfaction – Project sponsors are involved routinely through agile. The developers have a direct line to the customers. This continuous feedback loop usually leads to better communication and understanding between the team and customer.
Stronger Team Accountability – It takes time, but as the team culture shifts from command and control to a collaborative effort where developers take responsibility, collectively, for their work; the team begins to see how their efforts help/hinder the project. An adjunct to this is an increased sense of pride in their work and kinship with each other.
What do I need to watch out for when adopting agile?
Cultural Shift – This can’t be under weighted. Agile places greater emphasis on the team managing itself and its day to day activities. Subtly, agile preaches two things:
1. Development team and customer working together. Meaning other managers and IT leadership have a de-emphasized role. Your risking attrition by some of your better players if you ignore this. Proper coaching and preparation for this change and its effect on roles and responsibilities is essential.
2. Team stepping up and coordinating activities among it’s members. This is normally done by a PM or Dev manager or even a senior technical leader. Some methodologies, like Scrum, emphasize a new role ( scrum master ) to take on the facilitation aspects. For developers unaccustomed or uncomfortable with organizing and planning this may be difficult.
“Documentation is not needed” – You may hear this from some agile coaches and theorists. The original agile manifesto emphasizes working code over documentation, but as a development professional you’ll need to decide if this really makes sense for your project. Some of us have regulatory and legal reasons for documentation.
Dogmatic Views – I wrote about some of this in Bad Attitudes of Agile, but some team members will see agile as a very strict set of practices and may twist the theories and methodologies to suit their own ends. By its very description agile is meant to be a flexible approach to software and application development not a rigid set of rules that cannot be altered. There are the pragmatic agilists and then there are the agile zealots. Watch out for the latter.
Benefits can accrue from agile methods. These benefits, for the right projects, should result in better quality, reduced cost and schedule variance associated with requirements misunderstanding and defect management, and a more complimentary relationship with your customers. As mentioned earlier skepticism is not misplaced, but by looking for an opportune experimental project to introduce agile a development manager can assess its applicability for his/her shop.