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?
We can build machines that cover 140 million miles (225 million km), put themselves into orbit around Mars, nearly pinpoint their intended landing site through a brutal and high risk atmospheric entry and landing, and then traverse a rocky, radioactive environment in search of life or evidence that life once existed while beaming back its findings and data to Earth.
The feat of engineering that NASA undertook with Curiosity and the other Mars rovers reminds me of how well we solve difficult problems. The multitude of different issues that needed to be resolved and planned for to achieve the Mars Curiosity mission is a miniature summation of human progress and achievement. Its an accomplishment that would leave Galileo and Newton with a tear in their eye.
But it isn’t just space that we’re conquering. Our ability to solve the riddles of our own DNA and it’s affect on our health, lifespan, and evolution are unwinding. We can see into the past and determine how we evolved.
Likewise, climate change, a haunting and scary problem, has precedence for resolution. We’ve fixed our planet’s atmosphere before. Remember the ozone hole?
So with all this on our resume….why can’t we solve the problems ***we*** create? We’re not good at this. Our track here is shockingly bad.
We created these problems. We’ve put mechanisms in place to “manage” them. But we really suck at trying to solve these. Why?
A good mentor points out your faults. He tells you, flat out, what your issue is and helps coach you to resolution. A mentor can do this because he’s been there, made the mistake, and lived through its resolution. The accumulated wisdom and experience make all the difference. There are boundaries to intelligence and determination that only failure, recovery and reflection can overcome.
We need NASA. We need them to find a mentor for the human race somewhere in that deep black void that can hold up the mirror and say “See what the problem is now? Now…let’s fix it. Here’s how we tackled the debt crisis on planet Zenon.”
I keep all my receipts and at certain points in the month I can no longer sit flat on a chair. I’m moving to Google Wallet. Please no Seinfeld jokes.
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.
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.
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.
My most recent news item covers the latest scrum extensions and asks a few questions about the purpose and future direction for scrum extensions.
As a project manager you’ve heard and seen this diagram too often in your career. It’s often said that project managers are responsible for delivering on scope, budget and schedule. In turn they are asked to ‘manage’ this.
But how does one do this? Answer: you don’t.
Scope, schedule, and budget are not managed. They are tracked to ascertain proximity to targeted objectives. What’s managed are the things that affect scope, schedule and budget. What are those?
1. Risks – Or the things that could go wrong or right. Threats and opportunities. A project manager that manages these well avoids trouble before it happens.
2. Issues – No one can see everything. In time issues will come up, and part of how well a project is managed is how quickly and completely issues can be addressed.
3. Expectations – grounding stakeholders in reality and guiding them to a course that makes business sense rounds off the rough edges of a project. It keeps everyone in alignment and makes issue resolution and risk mitigation easier.
So, while the PM is accountable for budget, scope and schedule; he/she makes a mistake by trying to ‘manage’ these. Seeking out the handles behind these indicators and using them to affect the outcome is what good project delivery is rooted upon.