It drives me crazy. I heard an agile consultant this week say, “We’re trying to force the client to track progress they way we want her to”. Really? Good luck with that.
People tell me over and over the things self-appointed agile experts have said, and when you think about it, not only do they violate the spirit of the agile movement, they just sound silly. Tell me if you’ve heard one of these before.
“Our project will succeed only with a full and immediate implementation of an agile methodology, and its associated project tracking software”.
The official definition of the agile movement can be found at agilemanifesto.org, which explicitly values Individuals and Interactions over Processes and Tools.Granted, a shrink-wrapped set of people-friendly policies can be a good foundation for transforming a losing team into a winning team. Indeed, I actively promote both the Scrum methodology and the PMI-ACP certification as good things. But that does not mean just doing those things will automatically improve team performance. Instead, a true agile practitioner will ask simple breakthrough questions: Are we all on the same page? What agreements can the team install and self-enforce, to address those gaps? How can we customize our current methodology to support those agreements?
As I’ve mentioned here before, the methodology doesn’t matter. What matters are the principles you embrace towards delivering your project.
“We’re agile now, we don’t do any project documentation”.
This common myth is seeded in the manifesto’s favoring of Working Software over Comprehensive Documentation. Granted, many projects waste money on piles and piles of reports that nobody reads. But, that does not mean we throw everything out the window.
Instead, a true agile practitioner will seek to understand why those documents are mandated. Sometimes, a better specification can often improve the quality or accuracy of the final deliverable. Sometimes a risk register or Gantt chart can help increase credibility and stakeholder support for a project. The document doesn’t matter; what matters is that we address the underlying need.
“Fixed-price contracts are immoral. All our projects will now be time-and-materials.”
This is a fanciful interpretation of the agile manifesto stating its preference for customer collaboration over contract negotiation. Granted, many projects are launched as the result of zero-sum negotiations leaving a project team underfunded and understaffed. But that does not mean we refuse to have the conversation.
Instead, a true agile practitioner will strive to forge a positive working relationship with her sponsor with deeper questions: What are the client’s concrete business goals for this project? If push comes to shove, can we achieve the goal with only half the features to stay on schedule? Is it possible more budget would be approved for extra safety reviews?
Fixed-price doesn’t matter. Several people have offered agile contracting structures that support what does matter: a positive working relationship around project goals (for more info, see my PMI webinar on the topic of Agile Contracts).
“We’re agile now, so we don’t have to estimate. The project will be done when it is done”
This delightful gem is inspired the value the manifesto places on responding to change over following a plan. Granted, many projects are mindlessly judged on budget and schedule, regardless of how bad or how wrong the deliverable is. But that doesn’t mean we stop planning altogether.
Instead, a true agile practitioner will generate as much meaningful data as possible about our health of our project: Will we run out of money before we achieve our goals? Does our sponsor have enough data to make hard trade-off decisions? As General Eisenhower said “plans are worthless, but planning is everything.”
“That’s not agile.”
Guest what. I don’t care what you think is agile. I care whether we’re going to deliver. In the end, a project is judged not on the mechanics used, but on the objectives met. The agile movement was launched as a reaction against a focus on bad mechanics. If you’re falling in love with your agile mechanics as the silver bullet, then you’re dangerously close to losing your agility.
What about you? What silly things have you heard agile people say, often in direct contradiction to the Agile Manifesto?
[NOTE: This post was originally published as part of my recurring column, “The Agile Project Manager”, printed in PM Network magazine. Other installments and more info can be found here]
Agile experts tell us fixed price projects are immoral and declare that agility can only be delivered on a slippery schedule and budget. But what about the real world? What about fixed deadlines and fixed budgets? What about projects that are selected based on schedule and cost? How do you agile that? This post contains slides and webinars that will help you learn key principles for achieving agility in a fixed-price environment.
The most dramatic cause of project overruns is that we are doing more work than is absolutely necessary to achieve the high-level scope statement. But you can be the exception. Do not simply accept the project plan handed to you. Facilitate true innovation, which is delivering the most valuable business results from the least amount of work.
One of the stereotypes for agile approaches is that they only work for small projects. Ten or 15 years ago that might have been the case, but things are vastly different today. Agile techniques now are used as part of the day-to-day project operations of major organizations around the world. Here’s how they do it.
I’m excited to announce that I’m writing a book to help agile practitioners earn the new PMI-ACP agile certification. 4 years ago, I started by helping PMI launch the Agile Community of Practice. Then 2 years ago, I worked with some great experts on building the certification program. Now, this book is the next step in my journey to encourage project leaders to grow in their understanding of Agile project management.
Also, this book will benefit from a lot of talent. I’m writing the book with my good friend Hiren Doshi. We’ve engaged visual communication experts Take-Action.com to illustrate the book, and have brought on some good editors.
Our target is to complete the book by the start of 2012, but anyone who’s written a book knows there are challenges to that. For example, people are beginning to post their initial feedback on the exam, which may cause a lot of last minute changes to what information is most helpful.
Also, You can go to the official website and download a free sample chapter to see what we’re trying to achieve.
So here is my question: What would you like to see in a PMI-ACP exam book?
Since PMI announced its Agile certification program a couple months back, there has been a ton of activity. Here are some specifics:
- Chatter – The PMI Agile Community about the certification has featured some good dialog (PMI Members only link) about what it means. The most interesting is a webinar debate between Alistair Cockburn and James Shore on the pros/cons of certification. PMI members can download that webinar for free.
- Momentum – PMI’s CIO gave at talk at last month’s Scrum Gathering conference in Seattle, where he revealed that more than 6,000 professionals have already registered for the pilot program. That’s more than triple the number of certification holders for PMI’s last 3 certifications COMBINED (PgMP, PMI-RP, PMI-SP). In case it wasn’t obvious already, people want this.
- Training – Yes, I have built a PMI-Agile curriculum, which is being field-tested right now in India. But there are some other trainers that I am very excited to see also building a curriculum, including Ahmed Sidkey in Egypt, Mike Griffiths in Canada.
- Resources – With a new landscape, comes experimentation. Some early offerings are starting to show up, from flash cards, to practice exams, and even some pre-published books. AgileScout has been reporting on some of these, so keep a look there as well.
As one of the people who helped shape this program, I’m pretty excited about the buzz. Given that the mission for this program is to increase the awareness and adoption of Agile PM, I’m already seeing an ROI on our efforts.
“How much up-front planning should we do? How many people should we hire? How many meetings, documents and procedures do we need?”
No matter what field or what project, we all face the “how much?” questions over and over. To avoid getting bogged down, project managers should heed three golden rules: Just Enough, Just in Time and Just Because. I first heard these from Mike Griffiths, PMP, one of the earliest council members of the PMI Agile Community of Practice, when we were struggling with a lengthy document. After much debate, Mike interrupted with a seminal insight in agile efficiency: “When it comes to documents, I coach my teams to generate just enough, just in time and occasionally just because. I think this document fits the last category. Our client has asked us for this document, and even if we consider it excessive, the project will simply never get launched unless we use it.”
Let’s take a closer look at these three tenets of agile productivity:
GOLDEN RULE NUMBER 1: Just Enough. Only do enough prep or support work to achieve the primary goal of delivering business value. The problem is that we so easily intertwine this work with the bottom-line deliverable weâ€™re paid to generate. With that confusion comes the temptation to do more prep and support work than is necessary or required.
Yes, we need a project roadmap, but rather than spend time building a yearlong plan down to the hourly resource requirements, we’re going to provide just enough detail to communicate a vision to stakeholders.
Yes, our IT staff needs some technical direction, but rather than waiting to architect every layer of every interface of every system up front, we’re going to provide just enough direction to get started.
Yes, we need to pass the certification and accreditation audit. But rather than defensively launching an avalanche of paperwork, we’re going to collaborate with the auditors to deliver just enough documentation to satisfy them.
GOLDEN RULE NUMBER 2: Just in Time. You could be crafting lightweight documents, lightweight architecture and lightweight processes, and still be doing all that lightweight work way too prematurely. Of course we could need that architecture component, but let’s invest the time to implement it only when we know for sure we’ll need it.
Of course we’ll need a detailed action plan for next year’s project phase, but let’s devote time to crafting that detailed plan when we get to that phase.
Of course weâ€™ll need to generate some documentation, but letâ€™s wait until we get the documentation requirements before we waste our time on unnecessary write-ups.
GOLDEN RULE NUMBER 3: Just Because. This is the constraint that keeps us grounded in reality. I know the 40-page template violates “just enough documentation”, but we’re going to use it, just because we won’t get sign-off without it.
I know forecasting the full project cost up-front violates “just-in-time planning,” but we’re going to do it, just because we won’t get funding without it.
I know triple-entering our hours into the timesheet system violates “just enough administration”, but we’re going to do it anyway, just because we won’t get paid if we don’t.
The next time you’re faced with a dilemma over “how much” of something you should do, rely on these three rules to generate an agile response.
[NOTE: This post was originally published as part of my recurring column, “The Agile Project Manager”, printed in PM Network magazine. Other installments and more info can be found here]
I just finished a week of activities at the PMI Leadership Institute Meeting, here in Washington DC. It was an amazing experience that reinforced to me the amazing value of volunteering at PMI.
Leadership Masters Class is “High Class”
My first 3 days were spent participating in the PMI Leadership Institute Masters Class program. This is a year long selective program to build the skills of PMI’s volunteer leaders. This first of three face-to-face sessions featured a bevy of interactive exercises and table discussions, allowing us to dig deep into the leadership question of trust. We also took a personality inventory called Strengths Deployment Inventory (SDI), where I gained some very un-nerving insights into how I respond to conflict.
The program is very focused on facilitating learning through relationships. One of the features was the class broke up into groups of 5 “learning partners”. My learning partner group is committed to building the relationships needed to hold me accountable on my objectives.
One of the more impressive elements of the class was the participation of PMI CEO Greg Balestrero. He explained that his strategy toÂ support and grow it’s half-million constituents includes aÂ focused investment into its 10,000 volunteer leaders. For him, leadership has become a critical strategic competency at PMI. Greg is a very busy man, with a very busy schedule. So, when he spends a morning with a group of 30 volunteers, it means he believes what he says.
In truth, I came to this kickoff event with some initial concerns. Some of my colleagues had heard and experienced mixed results with this PMI program. But I can honestly say I walked away very pleased, having become a more self-aware leader after only the first part of the program.
A New Direction for the PMI Agile Community
I spent a significant amount of time with Mike Cottmeyer, Brian Bozzuto, and Dennis Stevens planning the 2011 direction for the PMI Agile Community of Practice. Indeed, we skippedÂ several sessions and instead had talked through the whole agile PM space, what our members are looking for, and how we can really promote the discipline of Agile PM. Here are some of the key outcomes from that discussion:
- Mike Cottmeyer will be the new Chair of the Agile Community of Practice. For 2011, the roster of our community leadership council will remain unchanged. I will continue to serve on the council along with Dennis, Brian, Ainsley Nies, Bob Tarne, and Mike Griffiths. However, MIke has generously agreed to take the chairmainship for 2011, allowing me a bit of a break. Also, 2011 will be the year we host our first community elections, and transition the community leadership to a new batch of members.
- We have an operational plan in place.Â Yes, many of us are skilled agile practitioners, but our distributed virtual setup really prevented the kind of self-organization we tried to foster last year.ï»¿ This week, weÂ realized on many fronts, that our community volunteers need much more detail around what needs to be done, and how to do it. So, here is the plan to address that:
- 2010 Q4 – The council will do the homework of (a) identifying the key initiatives for 2011, (b) generating the detailed acceptance criteria for each initiative, and (c) researching the how-to-instructions for implementing those initiatives
- 2011 Q1 thru Q4 – Then, we will complete the handoff to more and more volunteers to implement those initiatives on a quarterly basis during 2011.
- This year is going to be BIG for PMI Agile. During the week, we had the chance to talk with the staff at PMI headquarters about the Agile community and Agile PM in general. Already I’m seeing signs at the Congress of PMI’s growing investment in the promotion of agile. Their members are begging for vetted content, and PMI is responding. Also, with a new chair and a new volunteer base coming into place, we have a new infusion of energy to deliver more momentum.
This week was about connecting with leaders. Mike Cottmeyer had similar relections here, and Derek Huether enjoyed happy hour the most. PMI is a great place to find passionate, dedicated leaders, who will partner with you on your mission.Â I made some very good friends this week, and I am finding that it is your friends that shape who you are.ï»¿Â You should strongly consider getting involved yourself, either as a volunteer at your local PMI chapter or with the PMI Agile Community of Practice.
This is a reprint of my column in this month’s PM Network magazine. Click here, and then search for “The Agile Project Manager”
Iâ€™m growing weary of project managers whining about bad requirements. The truth is, no one can possibly be surprised. From research studies to high-profile disasters, we hear over and over that incorrect requirements and poor scope management are key reasons projects fail. If we know this is a recurring problem in our profession, why do we mindlessly continue engaging in the rote repetition of what doesnâ€™t work? Iâ€™d like to share some suggestions to keep us from stumbling over the same mistakes:
Surrender the pipe dream of complete requirements.
Thereâ€™s always going to be one dependency missed, one stakeholder we didnâ€™t interview, one nuance hidden, one more thing we wished we had known. Donâ€™t fall into the trap that more is better or youâ€™ll never get started.
Always assume the initial requirements are wrong.
Sometimes the scope is inappropriately slanted toward one stakeholder or hasnâ€™t been properly vetted. Sometimes the bulk of the requirements are actually â€œnice-to-haves.â€ Todayâ€™s project manager is expected to have the organizational savvy and facilitation skills to get to the root of these problems. To ensure that you yield the right priorities at the right time, take the initial scope statement as a starting point, then work with the sponsor to refine it.
Accept that all requirements change.
Traditional project management culture portrays change as a necessary evil, like traffic laws: If drivers did everything right, we wouldnâ€™t need them. To mitigate the â€œriskâ€ of change, we install intimidating change-control boards and financial penalties. But what if the scope youâ€™ve been implementing for the last two years is no longer relevant to the market? Does it make sense to have your sponsor continue paying for what is now
essentially a useless deliverable? Not in my estimation. If we accept that our requirements are incomplete and incorrect, then we need to edit them to reflect reality. Indeed, A Guide to the Project Management Body of Knowledge (PMBOKÂ® Guide) warns: â€œBecause of the potential for change, the project management plan is iterative and goes through progressive elaboration throughout the projectâ€™s life cycle.â€
Simplify your change-management approach.
Agile project managers explicitly embrace the value of responding to change and institute project policies accordingly. Start by implementing a contract structure that supports authorized change rather than penalizes it. At the start of each iteration, mandate a high-level yet thorough revision of scope priorities. If your sponsor has difficulty determining priorities, coach him or her through the tradeoffs. Once changes are accepted, re-baseline earned value metrics at least every three to four iterations to match the latest scope. And while youâ€™re at it, proactively communicate the latest scope to all stakeholders.
If you consistently find your requirements getting you into trouble, do something about it. Itâ€™s your responsibility as the project manager to be adaptable to your sponsorâ€™s needs. Stop taking the requirements for granted and start equipping your sponsor to make the right scope choices.