Project Management

Project management is a necessary skill for any mid-level operations person. Start with small projects and work the way up to larger ones.

Be aware that project customers, or stakeholders, will often not know what they truly want from a project or they ask for the moon. Review the project management triangle (good, cheap, fast: pick two).

Henry Ford is credited with saying about his customers “If I had asked customers what they wanted, they would have said faster horses.” Whether or not he said it, it still captures the essence of requirements gathering for operations projects. The operations professional is the technology expert. The stakeholders know they want a certain output or service. They may not know what that looks like or how to achieve it. The challenge is to extract requirements from the stakeholders then realize that these may not be the real or complete requirements.

Enter project management. Project management should help to frame the scope, resources, goals, and outcomes for the project. Let’s look at two different project management methodologies as they apply to operations.

Waterfall

Waterfall is a hierarchical form of project management that was adapted from other industries for the software development world. In waterfall, think of the phases of a project as a cascading waterfall. Each phase must be completed before moving onto the next phase. The entirety of the project is scoped from beginning to end including milestones and and final deliverables.

Technologies change, requirements change and scoping a large project over a long period of time with what are commonly incomplete requirements or faulty assumptions by stakeholders leads operations down a path of delivering an incomplete or inaccurate solution at the end. Waterfall breaks down in practice because it requires a promise of delivery that may be several years out.

Also, by requiring each phase a project to complete before moving onto the next phase, bugs and issues are often not discovered until late in the project. This causes delays and sometimes large amounts of refactoring or re-architecting to go back and resolve these issues.

Detractors of the waterfall method point to its rigidity and lack of testing during the development phase. One of the issues in operations and development work is that stakeholders may not have a solid grasp of requirements until they see a working prototype, or iterations of working prototypes during the implementation of the product. It is common for stakeholders in a project not to know what technology can deliver until they see it. Many operations teams are moving to Agile methods for several reasons and one of them is because agile development allows stakeholders to see working bits of the product before the end and to modify requirements before it’s too late.

Agile

Agile is a project management methodology. Agile started in 2001 when a group of software developers created the Agile Manifesto. The Agile Manifesto outlines the 12 principles of agile. Agile is seen most often in the software development world but it has crept into operations because of the obvious benefits over waterfall. Common implementations of Agile include: Scrum, Kanban, and the hybrid Scrumban that was created to meet more operational needs. The idea behind Agile is continuous release or delivery of a product. Instead of creating one big outcome at the end of a project, Agile allows a team to release a partially completed project for stakeholder review and requirements tweaking. Another big benefit of Agile methodologies is the discovery of problems early in the product development cycle when refactoring can be done immediately before the end product is set in a particular architectural direction that would make it costly to change.

Some documented benefits of agile include the following:

• Reduced process overhead

• Improved team and stakeholder communication and collaboration

• Errors and bugs are fixed in development instead of waiting till the product is “complete” to address them.

• Stakeholders see the product as it is shaped and have the ability to adjust requirements during development

• Project teams are empowered

• Can easily be combined with DevOps methodology to improve effectiveness of development-into-operations

• If done well, can increase work output of teams (increased velocity)

• Everyone on the project can easily see where the project stands (e.g. Scrum board or Kanban wall)

One thing to remember when implementing an Agile solution: adapt it as needed. Each of the following has its own simple framework, but organizations can use some or all of the implementation and even combine Agile methods to achieve success.

Scrum

Scrum is the more prescriptive of the included methods. Scrum is recognizable by Scrum boards, user stories, timeboxed sprints, cross-functional teams, Scrum Master and Product Manager roles, the burndown chart used for tracking project status, and the Scrum meetings: daily stand-up, and retrospectives.

Some of the limiting factors of Scrum for operational teams include timeboxing and tracking the burndown velocity of the team.

Scrum board - An electronic or physical board that is used to track project status, actions that are in progress, upcoming work, and completed work. A basic Scrum board will have three columns: Todo, In Progress. Done. Items in todo are the up and coming work, items in “In Progress” are currently being worked during this sprint. Done is fairly self-explanatory. Assignments can be tracked by sticky note on a white board or via an electronic Scrum board. The Scrum board also has rows. These are referred to as swimlanes. Rows can be labeled with project names and it common to have the very first swimlane titled “unplanned work” for operations tasks that fall on the team.

Electronic Scrum board - Electronic Scrum board software can be great if the team is geographically distributed. All members of the team can see and update the board from remote locations. The downside of electronic versions is getting the team to keep the application open and updated. Burndown can also be computed automatically making it easier for management to see progress.

Physical Scrum board - Often a whiteboard with a grid made of electrical tape. The swimlanes and tasks are marked by sticky notes. The team names can be post-it flags or some other marker. The downsides to a physical board include manual tracking of burndown, stickies falling off the board onto the floor (hint: Buy the Post-It super sticky notes or use tape or magnets), and lastly distributed teams cannot see the board easily. The upside to a physical board is visibility. The board can be placed in a prominent location where the operations staff can see it every day. This makes for easy daily stand-ups. It also allows members of the team to walk up to the board and have conversations with other members of the team about the work in progress.

Sprint - A sprint is a duration of time defined by the team when the work will be done between Scrum meetings. Work is chunked into pieces small enough to fit within the sprint window. A sprint window might be a week, two weeks, four weeks, or whatever length of time seems to fit the team. During the sprint, operations staff focus on the work agreed upon at the beginning of the sprint. Organizations can define how unplanned work will be dealt with during a sprint. Sometimes it is helpful to be able to tell a customer that we can prioritize that project request in two weeks at our next sprint meeting instead of feeling like operations has to drop everything for a last minute request. Sprints are somewhat rigid and can break down with operations because the work doesn’t neatly fit within a timeboxed window. The team will also provide time estimates for each task.

Daily Standup - This is a short daily meeting with the team at the Scrum board (virtual or physical). The person in the Scrum master role leads the daily stand-up by asking each team member a few questions:

• What are you working on?

• Are there any impediments?

• Do you need anything to be successful?

Each member of the operations team now knows what is expected of him/her for the day. Balance the expected work output with other team efforts such as trouble tickets and outside projects.

Burndown - The burndown tracks estimates of time with the actual time spent working on a project’s tasks. The resulting chart will show a project approaching 0 as the level of effort needed to complete the project winds down. Teams get better at estimating with experience. Burndown can also demonstrate if a project is taking longer than planned or is ahead of schedule. Building a burndown chart can involve a spreadsheet or graphing application. It is common to build formulas in excel that will automatically update a pivot chart showing the project tracking. Some burndown charts are very complex and others are simple. The organization has to decide how fancy to get with this tool.

User stories - In Agile software development, user stories can be feature requests, bugs, or modules the team plans to code for a product release. In operations, user stories can be small or large projects. Smaller projects are usually broken down into smaller more easily digestible pieces otherwise a project can park in a swimlane for an inordinately long time bringing down team morale and potentially impacting productivity. Teams should see positive outcomes and accomplishments across the swimlanes.

Cross-functional teams - In a development environment, a cross-functional team could include developers, testers, management, and operations. The purpose is to introduce DevOps to software development by including roles that have a stake in the project at different levels. In operations, a cross-functional team could include people from systems administration, networking, security, and management.

Kanban

Kanban is a much less prescriptive Agile implementation. Kanban can be recognized by a similar task board to Scrum but often there are more columns. Kanban’s strength is the work in progress (WIP) limit. Kanban doesn’t require roles, timeboxing, or burndown tracking like Scrum.

Because there is no timeboxed sprints, work continuously moves across the swimlanes on the Kanban board. Daily stand-ups are critical in Kanban because there isn’t a touchpoint at the end of a sprint to review completed work effort. Kanban boards can have several additional columns to assist in the management of this continuous work flow. An example Kanban board may have “Coming soon” “Review” “Available” “In progress” “Acceptance” “Completed.” The purpose of these additional columns is to enable teams to pull work into the “In progress” column as they finish other work. The “In progress” column and other columns will have what is called a WIP limit. There are a few schools of thought regarding WIP limits. Each organization must experiment with the WIP limit until a sweet spot is found for operations.

In Kanban for operations, the columns can be varied across teams or organizations. These columns are only provided as an example. The organization needs to find the Kanban workflow that works best for the team. There are several good resources that explain various ways of configuring a Kanban board. Sticking with the current example, let’s review the columns in an example Kanban board to understand their purpose.

• Coming soon - these are tasks, projects, or user requests. They are un-prioritized and may be big or small.

• Review - These are tasks that are prioritized by management or the team during the daily stand-up. They are put “in the hopper” as work items that should be reviewed and possibly broken into smaller pieces if they are too large. The downside of too large is similar to Scrum when the user stories were too broad. If an in progress items its in the active queue too long, it takes up a WIP slot and can make it difficult to understand if the team is making progress on that item.

• Available - This item has been reviewed, broken into a reasonably sized task and approved by management or the team to be pulled into the active column at the next opportunity.

• In progress - Similar to Scrum, these are the tasks being worked actively by the team.

• Acceptance - When someone on the team considers a task complete, s/he moves it to this column. Acceptance means it is discussed at the next daily stand-up and possibly accepted as done by the team. Acceptance can also mean stakeholder acceptance. This could also be a testing phase for something that is rolling toward production. If something idles too long in this column, it will hold up other work because of the WIP in progress limits placed on this column.

• Completed - These are tasks that are accepted as completed and put into production.

• Impediments - Some boards might include a small section of a column to identify impediments. Impediments are tasks that cannot begin because of outside forces. Usually management intervention is required to resolve the impediment. By separating these tasks on the board, the team sends a message to management that this work requires outside intervention to move forward.

Work in Progress (WIP) limits WIP limits define the maximum number of tasks that can appear in that column on the Kanban board. The two schools of thought that seem to pervade are:

• 2n-1 - where n = the number of people on the operations team. The reason for this is to enable team members to work together on some tasks but to give enough tasks so team members stay busy.

• n-1 - where n = the number of people on the operations team. The reason for this is to encourage collaboration on the team and not to overwhelm them with too many tasks. If someone on the team completes all of their work, that person should be able to pull the next available task from the “Available” column.

What is the risk of having a WIP limit too low or too high? A high WIP limit might mean the team is taking on too much at one time. Each member of the team may get overwhelmed with the amount of work. Consider these are reviewed daily in the stand-up meetings and team members can pull new work from the “Available” column when current work moves to “Acceptance.” High WIP limits mean that team members are less likely to work together on projects or tasks because each person has his/her own work to complete. A WIP limit that is too low could create a bottleneck, disallowing a team member from pulling new work into the “In Progress” queue because other people on the team have hit the WIP limit with their own work. The WIP limit is a sweet spot that the organization needs to discover through experimentation.

Whenever there is a bottleneck in Kanban, the team can refocus its efforts on the item stuck in the flow in order to unblock progress across the board. WIP limits force this to occur because a column with a WIP limit of 3 on the acceptance column will not allow any tasks to move to that column if there are already 3 items waiting for acceptance. It is a way to keep work moving across the board.

Scrumban

Scrumban is a hybrid of the two previously mentioned methodologies. Operations teams seem to embrace Kanban or Scrumban because of the flexibility of daily re-prioritizing and the WIP limits that keep the team from getting overwhelmed.

A Scrumban implementation would take elements from both Scrum and Kanban. For example, operations might decide to define some roles, keep the review and retrospectives, hold the daily standup from Scrum while enforcing WIP limits and implement continuous work flow from Kanban.

Agile Toolkit

jira