Process Methodologies

Waterfall, Scrum, Kanban – these buzzwords have been swimming in my head since I joined the Program Management team in my company back in January. As part of my own self-learning as well as promotion of project management in the company, I’m writing out some of the common questions I had and their answers as how I’ve come to understand them. I don’t have a formal background in project management (PJM), so this is a summary of what I’ve been learning on the spot as well as doing some readings online. I use project names that make no sense to most of my readers, but I’m sure you get the gist. 😉

What is a project management process?

By definition, a process is a series of steps taken to achieve an end. In the context of PJM, a process is the step-by-step actions that need to happen to move a project from ideation, planning, execution, testing, and finally to completion. Sometimes these steps are sequential. Sometimes they are iterative. Here are three processes you should know:

  • Waterfall – a process by which tasks are ordered and must be completed before the next one can begin. An example of this is creating a product that has been fully planned out, such as manufacturing a car by the thousands. One of the goals of a Waterfall process is to anticipate unknown knowns and discover unknown unknowns at the onset of project planning. When potential problems are mitigated at the beginning, Waterfall projects should be able to adhere to set timelines and due dates. AWS cutover project, the works of the creative design team, and about 30% of the Audit Preparation project are all examples of a Waterfall process.
  • Scrum – a process under the Agile family that breaks down a project plan into manageable production chunks to be completed in a given period of time (called “sprints”). Scrum allows flexibility in a project plan, as tasks are not committed until they are pulled into a sprint. Sudden changes and requests are more easily handled in a scrum process, which makes it an ideal process to use in software development because incremental delivery gives time for testing each step of the way. In Scrum, it is okay to not have due dates attached to milestones at project onset; unknown unknowns are okay. This process was designed to absorb problems that arise, but the downside is that a large incident can derail progress. A site-up incident might demand hours away from an engineer’s production time.
  • Kanban – another process in the Agile family. Kanban focuses on completing goals based on the capacity of a team, and time is not considered a restrictive element as it is in Scrum. Each member of the team commits to a predetermined number of tasks and will not shift focus to backlog items until active tasks are completed. A good example of Kanban use is in horizontal supporting teams, such as account management in Sales. Tasks are independent from other tasks on the board, and each member does not commit to more tasks than they can handle. (Ex: A Sales Account Manager does not actively work on more than 5 accounts at the same time.) In Kanban, we know there will be unknown unknowns as well as known unknowns! A goal is to then be able to bucket work to turn unknown unknowns into a known unknown state. For example, a DevOps engineer might be tasked to be on-call (unknown unknown) and when an incident happens at 3:21am, the engineer will be able to turn this problem into a known unknown, at a minimum, and begin solving for it.

Something I’ve come to realize in planning out and executing my biggest long-term project to date, is that a project does not need to fall into one process methodology cleanly. That project was a Waterfall process combined with some Scrum; it depended on what track we were talking about. HR had a lot of policy and program creation that only made sense to be worked on sequentially. DevOps, however, needed to break down their project plans so that it was more focused and manageable, so Scrum was the best process to follow. So while it was not necessary to stick to just one methodology, it was important to understand the pros and cons to take advantage of them.

Interesting to note that the outputs of these processes differ, but the outcome will be the same: HR’s output is a new security online training program for current employees, and DevOps’ output is to create a patch management policy and incrementally install updates. In the end, both teams were working towards completing project requirements and made significant progress towards company goals.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s