Agile: The Great Debate
Categories:
Agile
Categories: Agile
| Over the last week or so, there seems to have been a flurry of activity in the blogosphere discussing Agile and waterfall software development, A Guide to the Project Management Body of Knowledge (PMBOK® Guide) and project management. This is an important debate. A letter in the Feedback section of the March PM Network said Agile is not a project management methodology--I agree. Waterfall and various forms of Agile are definitely software development methodologies, not project management methodologies. However, we can learn a lot with an open dialogue in both directions. One common misconception among IT professionals is the assumption that the PMBOK® Guide approach to project management and the waterfall software development methodology are synonymous. Nothing could be more wrong. Certainly you can manage a waterfall development using the PMBOK® Guide processes but nothing in the PMBOK® Guide mandates developing a fully detailed project plan before starting work on development. All the PMBOK® Guide requires is the current phase is planned before starting work. This is absolutely compatible with the Agile approach to iterative development. Another misconception is that any new software development is automatically a project. Projects are temporary endeavors--this means temporary teams. If your IT shop is set up with stable teams working on a prioritized list of jobs using scrum or something similar, it is far more likely to be operational work rather than project work. With these misconceptions cleared, there seem to be three key areas for discussion. (Your comments will be welcome leading into some future blogs.) What are the differences in the way project management processes are applied in an Agile project compared to a waterfall project? Some thoughts: • The need for a much lighter "touch" managing an Agile project • The need for a higher level of trust in managing Agile teams • The need for robust change management and configuration management to track the evolution of the Agile project • The critical importance of developing the correct strategy and architecture at the beginning of the Agile project Can traditional project management learn from Agile? Some of the trends in Agile seem to have wider application in any project involving knowledge work, including: • The need to trust knowledge workers more than manual workers • Success measured by customer satisfaction rather than quantitative outputs • The need to keep the client involved What triggers the choice between operational maintenance and development versus projects and waterfall versus Agile. More later. |
Predicting the Future
| My earlier post, Our Biggest Unused Weapon, posited that the ability of even a basic earned value management system (EVMS) to predict when a project will be complete and how much it will cost at completion is unparalleled in the management information system world. But I also argued it was being under-used by most practitioners. William Goelkel, PMP, responded with: "EVM can lead us to make bad decisions, or forecasts, when the standard against which we measure everything is the plan we baselined at the point in the project's life cycle when we were most ignorant of its requirements." And "I'm not convinced a calculated EAC [estimate at completion] as you described is always useful." I'd like to further my arguments to the contrary while responding to Mr. Goelkel's thoughtful comment. Mr. Goelkel's main example concerns software projects, where "goals change and our understanding of the users' needs evolves." Either this understanding evolution is captured formally and introduced into the baseline, or it is not. If it is, then there's no problem. If it is not, then we have scope creep, the most pernicious attribute of managing projects. Even so, EVMS have a remarkable ability to predict the future, even when the baseline has been turned to rubber. Say you had a US$100,000 project, but "evolving" customer expectations will end up costing the contractor double that, or US$200,000. At the point that the project should be half-done (cumulative budget = US$50,000, and actual costs are at the same level) the task leader assesses that she is only 25 percent done. The calculated EAC will instantly indicate the real EAC of US$200,000, allowing for either elimination of the scope creep or a request for more money. For a more real-world example, try to find a project that (impishly) has a "Project Managers' EAC" column right next to the calculated EAC in their cost performance reports. Ninety-nine times out of 100, the project manager's version is lower than the calculated one and less accurate. It's like clockwork. In my next post, I'd like to tackle how project management trends in the software world--like scrum or Agile--are actually attempts to accommodate the rampant scope creep that so often afflicts those projects. For now, I'd like to hear what other EV practitioners have to say. I'd also like to thank William Goelkel for this discussion. |
The Search Is On
| For project managers out of work or just looking to change gigs, the recession and job cutbacks have made the competition tough. John Thorpe, managing director of Arras People, a project management recruiting firm in London, England, offers some tips for landing your dream job. 1. Focus on you, not your projects. Many people make the mistake of ticking off all their successful projects rather than talking about how they contributed to that success. "People are interested in what you did," he says. "You could have been serving coffee on that project. But if you made the difference in a project's outcome, be loud and proud about it." 2. Experience trumps training. Hiring managers are most interested in a proven track record. Mr. Thorpe suggests you put project experience front and center. 3. Market yourself. Your résumé is your sales literature and you have to sell your experience and education in a way that speaks to the person doing the hiring. "A generic CV is not going give you the best chance, particularly in this economy when hiring is tighter and roles are much more specific," Mr. Thorpe says. He suggests tweaking your résumé for each job, emphasizing your experience in a way that specifically relates to the position you are applying for. 4. Keep it short and sweet. Recruiters have hundreds of résumés to sort through. If yours is 17 pages long, they're likely to pass it by. "You have to grab their attention in the first half of the page or you are not going to make the cut," he says. 5. Consider contract work. Many companies are opting for temporary employees to fill gaps in staff without making a long-term commitment. For those with the right skills, contract gigs can garner decent wages and help you get your foot in the door. 6. Go to networking events. A lot of jobs never even get advertised, so it pays to network. It's a time-consuming but necessary part of the search, he says. "Finding a job is a job. You need to work hard at it and commit yourself full time." Want to know where the hotspots are even in a down market? We've got it covered PMI's Career Track in the May issue of PM Network. We will also have stories on making time for training and moving up the career ladder. And in the 10 April issue of Community Post, PMI members can check out an article on how to highlight your credential when you are jobhunting. |
Lessons Learned
Categories:
Teams
Categories: Teams
| Recently I had a team meeting to discuss lessons learned from a project and how we could document them to help reinforce the positive experiences and avoid the negative ones. As expected, we had a template to document the lessons. We had one team in the room and other teams on a conference bridge and two hours to get it done. Of course, that came with pizza and drinks. How do you manage to collect, assess, validate and populate data in a two-hour window? You have to have this data already present and entered into the system of some kind (whether it's electronic or paper), with such parameters as experience rating, failure points, links to deliverables each item refers to, impacts etc. And you have to have this information ready and available for this special meeting that simply reviews the results of what you've gathered over the course of the life of the project. A system of lessons learned would include or require the following: 1. Lessons learned as one of the deliverables of the project 2. Method/forum for submitting lessons learned to the project management office or senior management overlooking the project or running the functional areas that require changes based on lessons learned 3. Method or process for integrating those lessons into the organization 4. Method of entering the information, such as electronic lessons learned system (web- or network-based) or collection of documents, spreadsheets etc. 5. Method of accessing lessons learned information from past projects, relating to specific areas of the project or organization 6. System to have these items as required components of milestones on the project plan 7. Contribution to the lessons learned from issue reviews in a semi-automated way, so that at the end of the issue review or steering committee meeting you could use the data to post it to the lessons learned system Success of a lessons learned system depends on a buy-in from the sponsor, the steering committee and the organization to all the items above. Have you implemented a lessons learned system recently or participated in a lessons learned review? What was your experience? |
Day by Day
| Managing everyday project tasks is not rocket science. But it is a function of good discipline, time management, prioritization and overall organization. (We are in the project management business after all.) There are ways to organize our time and efforts on key project priorities and--as a result--get things done. 1. View each day as another opportunity to get back on track or achieve more. Erase the shortcomings of yesterday and plan realistically for tomorrow. 2. Accept that you can only handle so much in one day. Achieve your ultimate best by estimating how much and the type of work you can handle. 3. Try to only take on assignments or project tasks that you know you can finish and be realistic when estimating your ability to do a given task within the committed period of time. Your goal is to under-promise, but never to under-deliver. 4. Focus on delivering your tasks with highest quality and before the deadline. Approach each project task or activity as if you were to be audited. With these principles in mind, try the following system--and implement it now, not later: 1. Clear Your Inbox • Process all e-mails in your inbox and listen to voicemails today, instead of putting them off for tomorrow.2. Create and Maintain a One-Page To-Do List • Choose a system that will be your central depository of all of your "to-do's". It can be via e-mail, notebook or a stack of sticky notes, whatever works for you.3. Set Your Number One Goal for Tomorrow • This is the one thing you will complete or will considerably contribute to. It's your highest priority. |
