Eulogy to the Old Agile
Categories:
Agile
Categories: Agile
| Escorted on stage by a bagpipe rendition of Amazing Grace, Alistair Cockburn, Ph.D., began his keynote address for the Agile 2009 Conference by waxing Shakespearean on the death of agile as we know it: I come to bury agile, not to praise it; The evil methods do lives after them, The good is oft interred with their bones, So let it be with agile. The noble Waterfall Hath told you agile was ambitious: If it were so, it was a grievous fault, And grievously hath agile answered it. (Adapted from Julius Caesar, Act 3, Scene 2. You can read Alistair's full monologue here.) Melodramatic (in a good way) to be sure. But Alistair, an IT strategist and co-author of the Agile Manifesto, doesn't really believe agile has "met its maker" as the saying goes. Instead, he said agile is in transition--it's not the agile of the 1990s. The landscape has changed. It's grown beyond small organizations and is being applied to much richer, much more complex concepts and projects. Agile shouldn't be "new news," he said. "We're focusing so heavily on things that are 15 years old, I want to start focusing on things that are current." He also shared three pillars of 21st century software development: • Software development is a craft: Developers must pay attention to their skills and to the medium--they must relearn every few years. • Software development is a cooperative game of invention and communication: It relies on teamwork, communication and strategies. • Software development should use lean processes: That means small queues, cross-trained people and varied processes. Hosted by the Agile Alliance, the conference has pulled in 1,400 attendees from more than 38 countries. You can follow all of the conference happenings on Twitter. Did you attend Alistair's keynote address? What did you think? More to come. |
Taking On Project Management Myths, Part 1
| I'm going to spend the next several posts discussing commonly held, but, in my opinion, profoundly erroneous tenets of project management. Two esteemed colleagues, David Hampton and Alice Skehan, PMP, rated my list of 10 assertions in order of contrariness to common project management precepts, as well as the extent with which even they disagreed. Here, then, are my numbers 10 and 9: Myth 10: Trying to leverage organizational power to implement project management in the macro-organization is futile. Oh, I know, people try it all the time, and in many cases the ultimate outcome bears a strong resemblance to a legitimately installed project management office (PMO). As I discuss in my book, Things Your PMO Is Doing Wrong, the so-called coercive strategies don't work in the long run for the simple reason that people are being, well, coerced into doing project management. The moment they can opt out of the system, they will, and no reason that can provide reasonable cover will be considered too silly. I once had a project team that tried to use a paperwork-reduction initiative as a reason why they shouldn't have to send along their earned value reports. Really. Myth 9: There is no cost performance management without earned value. Period. No exceptions. And yet, the comparison of budgets to actual costs persists. When I'm instructing new cost engineers in earned value, I like using the following scenario: You're a project manager, assigned to get 2,000 widgets created in two months, with a US$2,000 budget. You time-phase your budget US$1,000 in month one and US$1,000 in month two. At the end of month one, your accountant comes to you and says that your project has spent US$1,100. Then I spring the question: "How are you doing?" Invariably, one of them will say "Poorly, because I'm overspent." "What if I told you that you had made 1,300 widgets?" Obviously, that little fact changes everything. In this instance, comparing the budgets to the actuals was not only useless, it was actually misleading. Management information systems can be forgiven for offering up the occasional jejune tidbit, but never for misleading. And yet that's all you're left with if you don't have an earned value management system. Next up, I'll be taking on the capabilities of the general ledger and re-visiting the bottoms-up estimate at completion debate. |
Managing Project Dependencies
| Projects don't run in silos or in a vacuum. They run in organized, chaotic environments where everyone is working toward the end result. There's nothing wrong with that--it's how organizations achieve multiple results in a short period of time. The key, of course, is to manage all these changes and interdependent projects. But what if you are part of a project that's not a part of any program or portfolio with an assigned program or portfolio manager or director? How do you manage those interdependencies that are not part of your scope? In my view, it's a matter of paying attention and linking yourself to three key areas: • Organization: Culture, processes, standards, rules, events, special blackout periods, etc. • Operations: Operational teams responsible for change management, incident management, delivery and quality management/control • Project Delivery: Such as a project management office or a business committee or unit that's responsible for project delivery No matter what dependencies may exist, they will be manifested through these three main channels. |
Integrity in Project Management
Categories:
Teams
Categories: Teams
| Acting with integrity with other project team members implies being honest with them--and clear about your expectations, intentions and opinions of the work they do. As a project manager, one has to have integrity in order to sell to the project team the need to succeed and deliver the project on time, on budget and within the scope of the project. Not only will the team members buy into the plan of action and your project management methodology, they will also become a solid extension of you and remain committed to going out there and getting the job done. Here are three tips for acting with integrity: Be Impartial: Be fair and objective. Listen to both sides of the story, various opinions, without attaching oneself to any specific one due to prejudice or favoritism. Objective decision-making fleshes out the problems and allows teams to get to the bottom of them rather than patching them. Be Thorough: Finish tasks completely, in a comprehensive manner. I find that being thorough in project planning activities means evaluating project requirements and any gaps in details. It also means validating steps against the chosen project management methodology. This ensures a much more comprehensive project management plan and that supporting documentation is produced. Be Focused on the End Business Result: No matter when team members are introduced, they should verify--within the scope of their project role--initial business requirements and the work that is being requested of them. This allows them to provide their own input based on their subject matter expertise and strengthens the chances for project success. |
The Right Information For the Right People
Categories:
Communications Management
Categories: Communications Management
| My last post highlighted the challenges of designing a project communication system that works. Now I will try to suggest a few solutions. To quote Peter Taylor's book, The Lazy Project Manager, "Reporting is not communicating." Executives don't have time to read fantastically accurate and detailed reports--people are simply too busy to take that kind of deep dive. But at least some of that detail is important. My suggestions to resolve this conundrum are: • Separate push and pull communications. Make the detail available in a repository such as a project portal) where people who need the detail can easily retrieve it (pull). Anything you send out (push) should focus on the highlights and information that requires action. • Separate history from future. Reporting what happened last week is of no value to the project unless it contains information that will influence future decisions. Historical data is needed by accountants and business administrators. project leaders and team members need information that is forward-looking, focusing on what might happen in the future and what needs to be done to improve the situation. • Focus on the needs of the receivers. Make sure you give your audience the information they need to help make the project successful. Team members need to know what work to do in the next week or two. Managers need to know what they have to decide. Achieving this type of communication requires planning and information design. Each element of the overall controls system needs to be elegantly designed to support both management decision-making and the work of the project. More importantly, the communication effort needs to focus on the important stakeholders who influence success: both internally to leaders within the team and externally to decision makers and influencers. (More on this later.) And remember Cohn's Law: The more time you spend in reporting on what you are doing, the less time you have to do anything. Stability is achieved when you spend all your time reporting on the nothing you are doing. |
