Mapping “Projectized” Work to DevOps-Style Workflows

Catherine Perry Thu, 09/07/2017 - 09:12

Project managers have many challenges in our fast-paced IT software development environment these days. Challenges such as getting features delivered on time, keeping costs down, and meeting customers’ needs are just a few. Inherent problems with traditional project cycles such as unclear front-end definitions of project scope and lack of communication among all the team players result in inefficiencies and waste. The problems in a traditional IT organization create an environment where project management becomes an exercise in frustration and can be a no-win proposition.

Adopting principles of Agile and DevOps in the development cycle can solve the traditional problematic issues that result in poor customer satisfaction and budget overruns. In this article, we discuss the issues with the traditional approach to projects, the solution using DevOps principles, and how the project manager can affect change by mapping project work to DevOps workflows.

Problems with the Traditional Approach to Projects

Before looking at the solutions for these challenges, first we need to understand fully the problems with using the traditional approach to projects.

The “Iron Triangle”—Triple Constraints Pyramid

If you are well versed in project management, you are aware of the “iron triangle” that illustrates the 3 key factors of scope, cost, and time. Each is represented as a vertex in the triangle that needs to be monitored and maintained in order to produce quality work. In converting a traditionally run project into an Agile or DevOps-style project, you have to think differently about these 3 factors.

 

    Image removed.

    In his book “Agile Project Management,” Jim Highsmith (ThoughtWorks) labels scope, cost, and time as “enablers” and postulates they are in fact constraints that inhibit the production of high-quality work. When we set these upfront, we are limiting the parameters that define the project and, therefore, limiting the quality of the end product. Highsmith says that project managers and stakeholders should instead look at what their capabilities are, what time is available, and what budget is available. By assessing them in this way, projects can begin and operate within the availability of resources.

    A Simplified Look at Enterprise IT Projects

    When we analyze enterprise IT projects, we find these to be the main stages in the project cycle:

    1. Business Analysis
    2. Application Development
    3. Testing & Quality Assurance
    4. Release
    5. IT Operations

    Simplified Look at Enterprise IT

     

    The main departments involved in projects are 1) the business customer, 2) application development teams, and 3) IT operations and support production.

    In the traditional project, much time is taken upfront in analyzing and defining the project scope, time, and budget. Afterwards, development begins; work is then passed on to testing and quality assurance. Feedback passes back to development, resulting in possible re-work, and then passes to testing and QA again. Eventually, the product is released and IT operations and support get to work with it.

    This model leaves many areas where errors are introduced, not to mention lengthy timeframes where work isn’t getting done. Much of the time, by the end of the project, the product doesn’t even meet the customer’s needs anymore.

    And, in the end after release, IT operations is left with trying to make it work on legacy systems that can be pre-historic to the dinosaurs. Legacy hardware and software pose issues, with a high risk of something breaking.

    If we really think about the goals for these two departments, we see a misalignment of incentives between application development and IT operations and support--application development is geared toward meeting the deadline while IT operations has to make sure it is working on all available systems. These goals don’t always work together synergistically.

    Functional Batching and Waiting Waste

    When everything is funneled into a centralized testing and quality assurance silo, there is a lot of room for misunderstanding. Inevitably, important information about the goals of the project is lost, making an environment where the “left hand” may not know what the “right hand” has done or intended to do. Because of this practice, problems are introduced during unit testing that may either take a long time to discover or not be found at all. The further along in the project cycle a defect is found, the higher the cost. This is especially true after release.

    Additionally, when all the work is put into a centralized funnel, we experience high-value work and low-value work being mixed together and given equal weight. This means everything has to wait in line and is queued up for testing and QA to occur. In the traditional project, a high-value feature may wait for a majority of the time, resulting in high costs for the project and unhappy customers. Time spent in line waiting is wasteful in time and resources.

    Issues

     

    A good resource regarding this topic is Joshua Arnold’s website “Black Swan Farming.” He uses the 80/20 rule to apply to projects, saying that a few features (20%) result in the most value (80%).

    Additional Project Management Challenges

    Here are additional challenges inherent in the traditional way projects have been managed:

    • Projects don’t keep up with needs
    • Functional batching causes slowness and waste
    • Massive security problems
    • Attaching monetary value to conceptual value
    • Unclear responsibilities for overseeing the overall flow
    • Inefficiencies of estimating and planning
    • Cost of delay

    It becomes easy to see that we need a different method of project management.

    The Application of DevOps and Agile as a Solution

    Agile and DevOps came as a result of the dysfunction in traditional project management. Both principles create environments that address and solve the challenges by enabling:

    • Better communication across functions
    • Shorter cycles
    • Early error detection
    • Flexibility and adaptability

    Better communication

    Agile is a cross-functional discipline that composes teams with players from all the stages of the product cycle—business analysis, application development, testing, quality assurance, release, and production support. This solves the potential for miscommunication because all are on the same page. By the business analysts and planners being on teams with the other players in the product cycle, communication opens and the cycle becomes iterative with the flexibility to change and adapt as needed.

    Cross-functional teams correct the “fuzzy front end” that Jez Humble talks about in his book “Continuous Delivery.” The “fuzzy front end” is where the study, approval, designing, and planning occur. Thereby, the product is defined more clearly in the beginning but can be adapted as needs change. This is imperative in quickly producing a product that is of high value to the customer.

    (Note: If you want to understand more fully how a DevOps project is run, read “Continuous Delivery” and “The Phoenix Project.”)

    Shorter cycles

    Agile and DevOps shorten the cycles during development and testing. By having cross-functional teams, shortening the cycles and working in short spurts, you find problems and defects much earlier in the cycle. Short cycles--many organizations adopt the 2 week sprint--create a more manageable way to develop, test, and provide feedback loops quickly

    Automation

    Automation plays a critical role in mapping work to DevOps-style workflows. Automation allows your operation to quickly find problems so you can pivot to solve them. Automation is the way you can build software that is maintained in a continuous state of release. All deployments are automated, which prevents human error and stress. And the infrastructure setup is automated for version control and change management, making the job of operations and production support go more smoothly.

    Application Delivery

    Flexibility and adaptability

    The ability to be flexible in adjusting to customer requirements and changing the scope in a project results in quicker response to customers, while providing more value and incurring lower costs. The use of Agile and DevOps changes the way an organization realizes value because the focus becomes the delivery of the product. That is where the value is. The ultimate goal should be to build software such that it is maintained in a potentially releasable state.

    The Role of the Project Manager

    Of all the players involved in product development, the project manager is in a position to improve the paradigm the most because the project manager’s job description encompasses the total cycle.

    Implementing change is not always easy or fast. The best way to begin is by starting where you are and incorporating small adjustments. Here are some tips for a project manager to start mapping work to DevOps.

    • Projectize work in order to attack bottlenecks, waste, and cultural barriers. Look for places where you can reduce waiting time and waste. 
    • Orient work around flows of values & outcome-focused teams.
    • Talk to downstream IT teams and teams that can implement DevOps practices.
    • Engage in a continuous improvement mindset and spread it to your teams. Do better with each sprint. Do version control better. Have testers come over and work with developers.
    • Enforce the equal priority for both non-functional and functional requirements.
    • And finally, invest in the delivery (release and IT operations) because value doesn’t happen until delivery!