2012 Predictions

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.  🙂

Advertisements

The “A” Word

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.

The Coming Breakup of Scrum

Introduction

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

10/06/2011 – Scrum Extensions announced – allowing modification to basic scrum.

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 Camps

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.

Summary

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.

Two Agiles

We all know this.  But it sometimes gets lost in the haze of execution.  There are two agiles.  The first is the philosophy, the belief system which is represented by the agile manifesto.  The second is the agile practices that were an outgrowth of the agile manifesto: scrum, xp, crystal, dsdm, etc.  Commonly, when people talk about agile…they’re talking about one of the practices that were an outgrowth of the manifesto.

What should be clear, but often isn’t, is that the agile manifesto doesn’t mandate the use of scrum, xp, waterfall, or one of the others.  In  fact, by blindly adopting one of these without considering the context of your project…you’re being anti-agile.

Predictive *AND* Adaptive Planning

Introduction

If you’ve managed projects for any length of time you understand the truth.  It’s almost never the case that a project is completely predictive ( waterfall ) or completely adaptive ( agile ).  It’s a mix.  There are needs for both in any project.  Those project managers, companies, and consultancies that integrate both approaches into their project management efforts are hybridizing the agile movement and shaping the reality of the future.  Let’s look at some examples that are well known, visible, historical and outside the IT market.  Why?  I want to defuse the agile vs waterfall debate for a moment and abstract things away from technology to help us see the broader picture.

Example 1: Lewis & Clark Expedition

The expedition by Lewis and Clark to navigate the Missouri River and map the western territories was an immense, RISKY, long term project entertained by a focused project team of professionals.  This is a startup.  Their goal was to map a water born ( river ) path to the Pacific Ocean.  To accomplish this goal some level up front planning was required.  You simply couldn’t plop two guys down in St. Louis and say: “For the next two weeks go up the Missouri River, then have a retrospective on what you learned, share that learning with your sponsor in Washington D.C. and plan for the next two weeks of river navigation.”

Lewis & Clark needed supplies, people who knew the land, logistical expertise, some plan up front to start the mission. But while an up front plan was necessary, much was not known.  This is where adaptive planning comes in.  They would need to adapt as maps, events, and people turned out to be unreliable or poorly understood: winters were more severe, the Missouri didn’t go all the way to the Pacific and great Mountain chain blocked their path to the ocean, and accidentally injuries and sickness delayed progress.

While not having an up front plan could have delayed and increased the cost of their project…not being able to adapt along the way would have killed it.  It was an experiment, a gamble, and to make it work required flexibility and persistence.

Standish group would have called Lewis & Clark a failure because they exceeded their baseline schedule.

Example 2:  Apollo missions to the moon.

The missions to land men on the moon and safely return them during the late 1960s and early 1970s in the United States were massive projects of unknown risk and horrible complexity.  Failure would bring down a nation and a philosophy ( democratic freedom).  They closely mirror big ERP implementations or suitably large custom software development efforts in Fortune 500 businesses today.

Could these have succeeded without predictive planning?  It’s hard to imagine they would have.  There were so many variables and unknowns that were required to be nailed down before implementation to ensure success.  In fact, predictive planning to the Nth degree is what made this possible and successful.  Accounting for every risk, having a mitigation plan for every risk, and carefully coordinating all the sub-projects to the common goal would have been hard to accomplish via strict adaptive planning.

This isn’t to say that adaptive planning didn’t play a role in adjusting and dealing with risks/issues along the way ( think Apollo 13 ), but this project was almost completely predictive by necessity at the top-level.  There was too much at stake ( human life and a nation’s perceived status in the world ).

Even though the Apollo moon missions proved to the world that the U.S. was the preeminent technology leader vs the U.S.S.R  and would be revered for decades to come….this project, using Standish’s metrics, would have been deemed ——-> FAIL.

Example 3: Building a Table in Garage with Your Woodworking Equipment.

A more personal, and human project…building a table is something that’s been done many times in the past.  This is like building a new e-commerce site for a company.  It’s been done before, they could have just bought a vended product, but for some business reason they want to build their own.

Ok, since it’s been done before there’s a pattern, and we borrow from it.  We download the diagram, purchase our materials, and define our plan.  This is predictive.  As we begin to execute we discover flaws in the plan or the procurement process.  Wrong nails were purchased or the leg supports were cut too small.   These events require us to adapt.

After building the table we’d dust off our hands and say “Wow, that’s a little over budget and it took some extra time, but I got what I wanted.”   We’d call it a success.  Standish would call it a failure.

More?

I could go on.  What about Michelangelo’s works?  How about building the Dubai Tower?  Great human efforts ( projects ) are vision building.  Successful completion and delivery requires a range of approaches and a commitment to the end goal.

Summary

Hopefully you can visualize the adaptive *AND* predictive elements in these projects.  It wasn’t one or the other.  It was a gradient.  That’s where the present is and the future will continue to be.  Hybridization is good.  It isn’t about agile vs waterfall. It’s about achievement, belief, and success.

Who Should Be the Scrum Master?

Who is this article for?

All software development professionals will find interest in this article, but those hoping to adopt agile, and scrum in particular, will find the greatest interest.

Project Manager or Technical Lead

Who should the scrum master be?  There’s at least two schools of thought that find gravity with this question.   One position is to employ the project manager in this role.  Another position is to have your technical leader tackle the position of scrum master.

Justifications for both can be made.  The project manager naturally has the people and process management skills required to successfully unblock nettlesome issues vexing the development team’s path to productivity.   But on a deeply technical project, unless the PM is fairly technical, he/she could end up at a disadvantage to a more traditional technical lead.  Hence, the argument to have your key development lead be the scrum master is born on the wings of a sufficiently technical project. Of course, this later position has the down side of potentially drawing the Peter Principle forward in all its majesty.  You hired Sam for his technical ability and now your taking him out of his strong suite.   Rarely a good move.

What about a CSM?

With the emergence of the Certified Scrum Master ( CSM ) credential software development directors are asked whether it makes more sense to get a professional scrum master to do the job.  This seems logical, and in some cases may present the right option.  But for those with experience and discernment, a certified anything is only a guarantee that the individual has at least passed some training and testing.

CSM’s may come to the role with the theory locked down, but it would be advisable to ensure they’ve ‘done it’ and can ‘prove it’.  A heterogeneous grouping of experiences and project types would be a good background for any CSM.  Awareness of any subject matter is important, but knowledge gained a priori has its limitations in the field of software development, indeed most worldly pursuits.  Experience counts deeply, and those who’ve been salted through the mine fields of time and circumstance can and do turn tricks the books don’t tell.

Rotate the Scrum Master Role Among Developers?

This seems like an interesting idea.  Seems is the optimal word here.  Rotate the role among developers and give them a chance to self organize.  After all, this is one of the scrum principles.

Boldly, we did this in my shop.  I can tell you first hand…it doesn’t work very well.  The results were not disastrous, but mixed and inconsistent.  The scrum master is there to facilitate and unblock key issues and risks.  By nature, most developers are not wired for these skills.  In most cases their preference is to solve deep, but abstract problems and/or utilize their creativity to bring their imagination into the world.  The scrum master’s world is never abstract and the problems rarely have a logical conclusion.

Here’s some examples of what occurred during our rotation experiment:

Developer 1 would take all blockers to the development manager and ask him to unblock them.  Dump and run.

Developer 2 saw the scrum master role as a break from developing software.   He was increasingly sick of writing code.  He’d often take over the other developer’s turns as scrum master and before long became the defacto scrum master….just because everyone else didn’t want to do it.  But he wasn’t good at it.

Developer 3 just wouldn’t do it.  When asked why…he gave the perfectly logical answer: “I wasn’t hired to do that job.  I won’t be good at it.”

Developer 4 was great at staying on top of all the details, and orchestrating/facilitating the scrum process, but his natural timidity meant he found it difficult to press upon others for project needs.

Qualities Not Titles and Credentials

So what are we left with?  If job titles, credentialing, and current software development roles offer no guarantee of a successful scrum master than what does?

Here, I would contend, from experience, that the qualities below are essential for a successful scrum master.  These may differ from more traditional scrum teachings, but I offer them up as opinion and reflection to the agile community.

A Driver – First and foremost the scrum master should be a bulldozer.  The person filling this seat should feel comfortable pushing issues forward and untangling gray, often ambiguous problems unaided by higher-ups.  I do believe this differs from the views of Scott Ambler, Ken Schwaber and other scrum proponents.  When they speak of a ‘coach’ one gets the sense the ideal candidate would be equally comfortable leading a Little League Baseball team.  But organizations with size and high market caps are serious and very adult places requiring thick skin and persistence forged in steel.

Detailed and Organized –  This really goes without saying.  A scrum master that is uncomfortable with the details of the software architecture he/she is helping to birth into the world is headed for trouble.  One doesn’t need to be reading the code, but it would be beneficial to have the skills to speak with developers on their level and translate those into business speak.   Being organized is also a natural quality for a scrum master.  As orchestrator of the scrum process he won’t gain any points from the team if he forgets that today is iteration planning or can’t recall which stories are resolved.

Honest With Himself/Herself – No one likes a liar.  It’s easy to be honest in the face of fair winds and successful deliveries.  But, when the rice pudding hits the fan and the scrum master and team are to blame:  a solid scrum master will set the example, take responsibility for the mess, apologize, and find a corrective course of action.  In a nutshell: lead.

Politically Astute – The nuances of human behavior and relationships inside organizations that scale to 3M and GE proportions are not to be trifled with.  A bulldozer needs to know when and where to stop plowing and let a more suitable piece of machinery take over.  Further,  the scrum master should have a bag of tricks.  He should be comfortable in the art of persuasion, know the hooks and hot buttons that pull and push his key stakeholders, and see the organizational hierarchy as a tool rather than an impediment.

It’s Personal and I’m Fully Invested – In my experience, aloof scrum masters don’t do well.  They should see their role, project, and career as intertwined.  Their reputation should be at stake and success to them should be more than just a good stand up meeting, or a well orchestrated iteration review.  None of that matters should the product miss its goals. They should take this personal, and invest themselves fully in the project.  Again, this is leadership. Projects rarely fail because money, time or ideas are lacking.  Their usual course to being shipwrecked starts with….belief.  People need to believe the project will be successful and the scrum master should be its evangelist.

Humility – Lastly, I agree with most other scrum theorists that the scrum master should be humble.  I think this is called ‘servant leadership’ by them, but I’d chalk it up as just good leadership skills.  A good SM won’t boast or take credit for other’s work, but place credit where it is most surely due.  Let me be clear, I’m saying ‘humble’ not ‘without backbone’.

Summary

The picture that emerges for a good scrum master candidate is a leader; not a secretary or a bureaucrat.  My view on this differs from traditional scrum thinking.  Where they see a helper of the development team, I see the scrum master as an active, engaging and dynamic person with a big stake in the game. He or she could have certain titles or credentials to his or her credit or not.  Like so many other leadership roles the core of  what that person accomplishes will be manifested through who they are….rather than what hard skills they may possess.  When interviewing and reviewing potential candidates I would keep this question in your mind: Will the development team and stakeholders believe in this person?  Your project may rest on the answer.