Today we welcome back guest blogger, Lisa Grant, who is the CEO of EPM Solutions, which specializes in leading companies to a consistent and effective projectized model through the use of a diverse group of experts. She has influenced and improved project management processes in various industries and functional areas such as Knowledge Management, Healthcare, e-Learning, State and Federal Government, Automotive, Manufacturing, Supply Chain, Human Resources, Payroll, Textile, and Beverage verticals.
Lisa has an MBA with a concentration in Management from Georgia State University, is a Project Management Professional, Advanced Communicator – Bronze, and Competent Leader. She achieved the MS Office Project Blue Belt certification in 2006, spoke on “Lessons Learned” at the 2005 PMI Southeast Symposium and the 2008 PMI Atlanta Professional Development Day, was awarded a Most Valuable Player award for her exemplary service to the Atlanta Chapter of PMI, and is listed in the Who’s Who Registry. You can reach Lisa at lisa.grant@enterprisepmsolutions.com.
Last week I participated in a panel discussion on iterative software development. My portion of the discussion was centered on the Scrum Framework that I am currently using to run my projects. A question arose from the audience regarding how to manage change when using agile or iterative development methodologies. It seems that change is encouraged in these environments because there are review and feedback sessions post each iteration. How do you manage the scope that was approved during initiation if you accept feedback so frequently?
Good question. First, I’d like to dispel the notion of doing agile development means you must have a band of cowboy coders or developers who are coding based on whim and personal interest. To the contrary, since they are focused on specific outcomes for the iteration and the expectation is that it will be fully functional for the review; they work in a focused fashion coding and unit testing to the current specification.
These frequent checkpoints reduce the probability of change in scope because the deviations can be caught early instead of waiting until the whole system is developed. They also highlight the necessary changes. For example, if the design prohibits the development of a certain feature, it will be discovered as soon as that feature is begun versus at the end of the full development cycle. Then the design can be readdressed. Also, the daily and end-of-sprint interaction with stakeholders allows deviations from expectations to be discovered quickly AN, allows the change to be authorized immediatly instead of waiting for the next scheduled change review board meeting.
Change is a given for all projects and cannot be avoided. Accepting that condition and working it into the project operations makes sense. I think the agile doctrine, especially in Scrum, is highly effective for managing change. The Project Manager or Scrum Master must be vigilant, as always, in identifying the change and getting the appropriate paperwork completed; while the cowboys keep on coding.
