I was asked recently by someone I greatly admire and respect, “Wouldn’t you rather plan for risk than react to the circumstances that befall your project?”
At the time I was stumped. Yes I guess I would, but we can’t see everything can we? At least I can’t.
In reflection my answer is: I would rather do both. See and plan for those risks I know and use a daily scrum-like meeting to capture what I cannot plan for.
What are your thoughts?
Is Agile a management fad? Is its blistering adoption throughout the world rooted in a proven value driven approach or the hysteria of the masses clamoring for a new trend to profit from and identify with?
Fad – defined
According to Wikipedia a management fad has certain characteristics. Let’s look through these defining elements and see if Agile can fit this definition.
1. New Jargon for Existing Business Processes? Seems that there are plenty of examples that fit this like:
Manifesto = Mission
User Story = Requirement
Planning Poker = Estimating
Daily Scrum = Daily 15 minute meeting
Scrum Master = Coordinator/Facilitator with no authority.
2. External Consultants Who Specialize In the Implementation of the Fad. Would anyone deny that agile has these in abundance? Agile consultants are everywhere and firms specializing in agility are in no short supply.
3. A certification or appraisal process performed by an external agency for a fee. Yep. Many of these exist. Although they don’t all agree with one another on the merits for earning that certification, CSM, CSP, PMI-ACP, and the icAgile body of certifications represent a diversity of vehicles for achieving formal certification.
4. Amending the job titles of existing employees to include references to the fad. There could be room for debate on this one, but a short search on monster.com or dice.com show a plethora of ‘agile project manager’ versus ‘project manager’ positions. Equally, we’ve seen software developers that specialize in agile practices now called “ninjas” and there is the “agile scrum coach” that now replaces the old title “application development manager”.
5. Claims of a measurable business improvement via measurement of a metric that is defined by the fad itself. Velocity is the most prominent measure that comes to mind. Further velocity is defined in increments the fad defines: story points.
6. An internal sponsoring department or individual that gains influence due to the fad’s implementation. Organizational Agile Coaches, or an Agile Center of Excellence are two examples that have become common.
7. Big words and complex phrases. This one is kind of subjective, but YAGNI might quality. SolutionsIQ even published an agile glossary so you can keep up with all the terms & definitions.
Fad? Yes. Value? Yes.
So by this definition agile is, well,…a fad. But does that mean agile practices have no value? Here’s some of the things we’ve learned ( or re-learned ) from agility:
1. Daily communication among team members really matters when the work is complex.
2. The people doing the work must be accountable for it. Don’t let them hide behind a project manager. Let them take pride in what they do.
3. Requirements require constant communication, clarification and understanding. It’s a continuous phase communication cycle, not a document.
4. Regular, timely feedback on work improves quality and job satisfaction.
5. Teams need help coordinating, facilitating and communicating between themselves and others.
Agile’s popularity is still growing. Clearly some of us see benefit even as the marketing machine twists agility into something it never really was or will ever be. Like management fads before it ( Six Sigma, TQM, and CMMI ) agile has made an impact on how we create value.
Is there a cult following? Of course. Everyone likes being popular and making money. But the end state of the agile bubble will be a reconciliation back to reality. There’s no silver bullet. Problems still exist and we’re never fast or perfect enough for the shareholders or customers. Room for improvement is omnipresent.
Summary
The fever pitch of the fad is a beacon. Full value has been realized, copied, marketed and redistributed without concern for the result. While time exists and there is still competitive advantage…the crowd still gathers. But, the drivers of innovation have long moved off the curve of agility, hybridizing and envisioning new methods and tools for further improvement. Another wave will again crest and break onto the shores of software management and leadership bringing the promise of ultimate productivity and quality, but delivering only incremental improvement.
Introduction
Container shipping transformed the way goods were transported across geography and channel. Instead of having many diverse payloads in differing container configurations for different modes of transport; a standard was defined for a rectangular container that could, through a set of standardized connection points, be bolted to ship, train, or truck. The result of simplifying the container configuration meant that transferring cargo between modes of transport became easier, shipping times were reduced from port, to rail, to truck. Handling and management costs also went down because there was less variation in the cargo.
In the same way agile is standardizing the time-boxed delivery mechanism for software development. Widely, today, the iteration is seen as that container. In the majority of agile shops the 2 week iteration with a daily stand-up, front end planning session, and back-end review session; is the norm. The channel of delivery might be scrum, xp, lean/kanban, or some hybrid of these. The choice of which channel to use is deeply dependent on the business environment surrounding the software shop. But regardless of the rails the iteration rolls over; it has become the choice for time-packaging completed requirements.
What are the implications of this to business and development groups? What changes does this standard for team delivery impose/challenge the modern organization with?
Finance and Accounting
How capital projects are financed for internally used software has not followed the train of direction the iteration has brought forth. Traditionally, project estimation is bottom up and we derive funding by establishing a level of effort ( LOE ) across the project, with some breakdown into work packages. Iterations have the capacity to be the bricks of capital financing upon which projects are funded.
The challenge to IT finance groups is to derive the cost accounting for an iteration ( essentially a two week productive work team ) and then establish capital planning policies and procedures that estimate, plan, track and account by those iterations.
At first blush this sounds simple. Why not just figure out the appropriate team composition: say 3 developers, 2 qa folks, 1 product owner and 1 team leader. 7 people X 50 hours a week = 350 hours X $70.00 per hour = $24,500.00 per iteration. So now we just need to figure out how many iterations we need. Right?
But wait….
What if I need a DBA, Infrastructure Person, or support analyst engaged? How about software licensing, pc costs, PTO ( paid time off ), employee rates vs consulting rates, and other indirect costs? What about the funding mix for any iteration? Surely not all of it is CAPEX. Some of it may be OPEX. But what mix of a typical iteration should be OPEX vs CAPEX? Should certain iteration models exist depending on what the team is doing?
These questions begin to explode the subtlety. By standardizing delivery on iterations, the finance group and IT leadership can standardize the IT shop and its costs. Should success be achieved, CAPEX and OPEX planning should become less complex and more routine; fundamentally reducing the infrastructure, roles, and process associated with this annual event while simultaneously establishing a standardized point of accountability and process planning.
This also changes the very nature of estimation from detailed to relative. We’re now looking at value creation, rather than cost control. The challenge back to the business will be how much value is derived at various cost points and at what point cost becomes too much. Project costing becomes a negotiation toward shared value based on relative targets achieving a defined set of NPVs.
Management and Leadership
In an iterative organization the control, power, and operation are at the iteration team level. Influencing those groups will require a leadership and management structure that is comfortable with fluid and mobile adaptation of resources to project needs. Leadership truly begins to shine in this type of paradigm. No longer dependent on a static formal organizational structure to derive power, the real leaders will begin to exert influence over these mobile iterative pods.
Those succeeding in such an organization will be gifted in the art of servant leadership, coaching, influence, and mentorship. Command and control will be reserved for extreme HR issues alone.
Innovation
Iterations also change the shape of R&D and new innovative initiatives. Iterations demand transparency, accountability, and risk reconciliation. The iteration opens things up and standardizes the cycle of delivery. To many this may stifle the idea of invention and creation by putting it on a disciplined cycle, but does it? In plain english: business demands a return on its investment. Research for research sake is a university concept.
Org Charts & Structure
How is organizational structure affected by the expansion of iterations? While most IT shops today are familiar with the matrixed organizational structure, the iterative organizational structure groups teams into standardized pods for delivery.
The pods would favor generalists who are good at a multitude of IT functions but perhaps are not perfect at all aspects. This structure would be fluid and adapt to organizational need. An example iterative structure is below. In this way the iterative POD is responsible to the director as a team. All individuals in those pods report to him/her.
Personal Career Growth and Development
Iterations have already had an enormous influence on personal career development at software shops. It’s not enough to be just a code whiz. Iterations place emphasis on teamwork, personal accountability, and decent communication skills. Flexibility is also a key aptitude sought in the iterative individual.
Good delivery PODs are ready made hired guns. Teams of professionals that could potentially write their own engagement. In this way staffing by placement firms and consulting groups changes from individual placement to team sourcing.
Summary
The transformation of the shipping and distribution industries to containers wasn’t a simple overnight change. Standardization requires upheaval and new ways of thinking, approaching old problems. Organizations that adapt to the standard IT container and see it as more than just a ‘development thing’ are best positioned to yield the benefits that this change could bring.
I’ve been hanging out and posting at the ASPE SDLC blog. Yes…I have their permission to do that. Geesh. Check em out Gilbert:
Six Things To Avoid When Reporting Project Status – Project status is about the facts and your strategy to address and manage those facts.
This Daily Standup Is a Joke – This article details some challenges associated with daily stand-ups and some potential strategies for dealing with these.
An Axiom of Project Success – What’s the common thread to project success? We’ve seen projects that should have died. We’ve also seen projects fall apart that seemed like they were in the bag. This post attempts to nail the overriding factor.
That’s Great…But How Does Agile Benefit Our Shareholders? – Selling agile to key leaders in your organization takes more than just a thorough understanding of story points, and time-boxing. This post brings it home for those wanting a bigger bang for their agile swang. Whatever that means.
Projects are about getting things done…right?
Uh-Uh.
They’re unique, collaborative, human efforts endeavored to achieve success. Success is can be defined with certain goals. Success has a point, a place we reach and can say “Ah-ha!….we did it!”. There’s a finish line. Done, on the other hand, is never done. Excuse the pun. And the rhyme.
Done is an endless backlog.
Done is a never ending series of requests.
Done is code that’s never perfect.
Done is test cases that still need to be refined.
The fog of “Done” can envelop the project and the minds of our teams. It obscures the truth. We’re not looking to get everything “done”. We’re looking to succeed. Within success there is room for variation on “done”.
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.
Pragilematic 