BY: Karam A. Labban, CSP, CSM, SAFe Agilist, ACP, PMP, TKP
Having spent years applying the waterfall methodology, I always had the feeling that it wasn’t right for software development environments, but I just didn’t know what other choices there were. I never felt right with the notion that more templates, more documentation, and more processes on top of the actual work are the answers to every project issue or will guarantee success. More often than not, we hear senior managements, whenever a waterfall project fails, say that what was needed was more documentation, more formal hand-over-the-wall sign-offs, more exhaustive meetings, and stricter management and hours and issues tracking and reporting. They don’t recognize that they are asking for more of the stuff that didn’t work in the first place. And even when projects go well, no one really questions the true effectiveness of the waterfall methodology.
It all changed for me back in 2006 when I was having a conversation with a dear friend of mine and was telling her that even though I was technically doing good as a PM and used to receiving positive feedback from the sponsors, team members, clients, vendors, and upper management, I felt I reached my limit putting up with the processes, documentations and the issues that come with waterfall based projects. I just couldn’t believe that there isn’t any fundamental solution to the problems that accompany stakeholder management, almost always useless and un-timely lessons learned and the utterly impractical and misleading EV calculations and so on. My friend suggested that I look up something fairly new called Scrum and the Agile Manifesto. I jumped on the suggestion right away and my outlook on my professional life forever changed.
Break the Iron Triangle
Let us start with considering the roots of problems that face project managers starting with the famous triple constraints. The holy grail of project management where PMs are requested to adhere to in order to deliver projects on time, under budget, and with all of the scope. And, oh, yes, with high quality.
With the triple constraints in mind, project managers apply a change control process and templates to fend off any scope change, watch like a hawk the hours spent by team members, and translate that into monetary value to compare with the approved budget and helpfully somehow, guaranteeing quality work. The PMs seem to have their hands in everything, but how deep really? Can the PM really guarantee all three aspects without initially padding the estimates of time and cost, and scarify quality and/or burn the team with unreported overtime?
The Scrum answer to the triple constraints predicament is genius in its simplicity and effectiveness. Just admit that the team can only truly guarantee its availability for a specific period of time, and since it would be a dedicated, true cross-functional Self-organizing team with effective governance, as Scrum specifically prescribes, and have been working together for a while on other projects, we can tell their quality of work and throughput (team velocity) and therefore, calculating the total team hourly cost is easy.
User Stories as the Spring Board into Agile
With team availability, cost, and quality settled and for all practical purposes are fixed, the Product Owner who is an empowered and knowledgeable person representing the business side, can then share with the scrum team the scope that is formatted as a backlog of needed features written as user stories (As a _____, I want to ____ So that _____) on Post-It notes or slightly larger cards to force simplicity. The backlog should be sorted and prioritized by the Product Owner based on business value, urgency, and risk. Simple conditions of acceptance would be also written be written on the back of each card by the PO. Prioritizing the features that way allows for the project to fail earlier if no good and practical evidence of success are experienced by the users and taking on risker work first. These evidence of success in Scrum are called shippable increments of the software the business is needing.
The committed Scrum team then starts with the user stories estimation exercise that is done using abstract points (or shirt sizes: S, M, L, XL, XXL) instead of man-hours in order to allow for flexibility and also admit that we can’t know everything at the start of the project. Any additional time spent on estimating to reach preciseness is proven to be overkill and reason for headaches later on because any hours or days based estimate will be taken as a commitment on behalf of the team no matter how many times we call it an estimate or a guesstimate. All story cards and related graphics are placed on a wall where anyone can see. The wall becomes a radiator of information. Using a software tool instead or even Excel will only, in my opinion, contribute to “out of sight, out of mind” mentality and you end up spending time managing the tool and updating fields instead of running the project.
Change and Adapt
Again with time, cost, and scope and to some extend quality, are agreed upon, the team takes on the highest priority user stories that they can do in a time-boxed period of time. These periods are called sprints or iterations. The sprint’s length never changes during the project life and always starts with a planning meeting that bring the team and the business side (called Product Owner) to dive deep in the stories allotted to be done In the sprint. Sprints always end with a demo, retrospective (lessons learned). These lessons learned are applied in the next sprint so the current project benefits form them and not supposedly the next project. The sequence of the sprints and the user stories assigned to them are call release plan.
And since the stories are written as (Valuable, Independent, Negotiable, Valuable, Estimable, Small, and Testable) and sorted based on business value, the Product Owner can easily re-sort the remaining stories, add, or remove them as he/she sees fit to better response to market changes or as the business side learns more about what they really want as they experience demos at the end of each sprint as the product is incrementally being build.
There is always the possibility that the business would decide that they have enough features built, tested, and integrated and they want to go to market with it, the scrum team can then do a release sprint and deploy the features. Or, the business might stop the project all together for any reason, and the ROI in either case is 100% because no one put more effort and time more than what was needed for the features that were done up to that point. Even when you continue till the last sprint with automated re-testing after each increment of the product, most likely your ‘deployment night’ will be eventless. I had the pleasure of such finales and it was sweet.
Roles and Responsibility Where Should Belong
Now, doesn’t it make better sense that those who came up with the scope end up taking ownership of it and controlling it? Does it also make sense to use user stories and not the old fashioned way of “The System Shall Do ….” which is just like the triple constraint, sound very ominous and doesn’t lend itself to flexibility and responsiveness to market changes or collaboration between the different parts of the business. This actually brings up another issue with following a waterfall methodology, the RACI, RASIC, or even RAPID matrix. Because everyone is not really dedicated and talking from behind “walls”, and worrying about their specific part only, a complicated roles and responsibility matrix needs to be developed and people have to sign on it as if it is a legal document. With Scrum, people who matter to the project are physically co-located as much as possible and have the right roles cutting through the bureaucracy and the notion of herding cats.
We can’t finish without addressing communications in project management as it looms heavy over projects with its communication plan like you are about to invade a country, status meetings, testing results, periodic progress updates, templates and so forth. On the other hand, Scrum brings agility and actually more control and openness on the progress status and quality of work being done by having simple wall charts depicting how many points are done per sprint verses original plan when the stores were initially assigned to sprints. You can easily derive other charts showing progress by number of features, cost accumulation, handled impediments, etc. Each of these charts can make any changes to the scope and budget or time easily visible and understandable. When there is nothing hidden, communication becomes more open and to the point.
Even when those who are interested in the project (Other PMs under the same program, general system users, and management folks) they can just walk into the project room and take a look at the remaining backlog, the current sprint story cards, the charts and the notes on impediments, risks and lessons learned. They walk out very informed and feeling not left out of the loop. They can even attend the daily 15-minute standup meeting (daily scrum) where each committed team member states what they did yesterday, what are their plans for today, and if there are any impediments in their way. No one talks till each omitted team member is done with their status.
All Good and Well, But
Now, someone might say that Scrum can’t work in Network, Telecom or construction projects. Not totally accurate. First, as a rule of thumb, if you absolutely have no uncertainty in a project, waterfall approach would work just fine for it, but anytime you have uncertainty, any project can benefit from Agile and lean principles, and from the ceremonies of Scrum and its advocacy for collaborative approach and progress visualization. I know of one large construction project that included theaters, restaurants, hotels, apartments and parks that used the principles and practices of Lean and Scrum to a huge success. Also, keep in mind that Scrum process and agile principles can be adopted at the program and portfolio levels also.
I hope I iteratively walked through Scrum while I sang its praises. Traditional project managers might now ask: what is left for us to do? Actually, what is left is what PMs are truly meant to do. Use their soft skills to build and grow the team, be proactive on risk management, handle impediments faced by the team, and most of all, provide servant leadership.
I am glad PMI embraced Agile and Scrum and now provides the PMIK-ACP certification based on books written by leaders in areas of Lean, Agile, and Scrum. Here are some additional resources you might find helpful:
· PMI Agile Certified Practitioner (PMI-ACP)® bit.ly/1gepOxj
· PMI’s Agile Community of Practice bit.ly/1e8KpCW
· Webinars and resources: www.agiletransformation.com
· The Agile Manifesto: http://agilemanifesto.org
· PMI Learning and Education Community of Practice http://agile.vc.pmi.org
· PMI® Agile Certified Practitioner PMI-ACP Exam Prep Study Group on Linkedin