Agile Method

Agile Techniques for Hardware & Software Development

By / / ,
,
Agile Video Cover

Introduction

This white paper presents best practices and techniques to overcome hardware and software development challenges encountered as organizations move towards increased agility. Agile transformations typically start in pockets within the same discipline, such as Software or IT departments. As the Agile teams become more efficient and require increased support from inter-related departments, the supporting functions will likely adapt and begin to use Agile techniques to keep up with increased demand. Expanding Agile across the value stream results in the need for the organization to assess their current state of agility, create cross-functional teams, decide how to scale, craft vertical slices of work, adapt new development techniques, and increase customer involvement. Teams will need to be restructured to allow for end-to-end development, which is particularly difficult for hardware teams.

Team Structure & Composition

Hardware team structures are typically multi-disciplined in very diverse areas of competence. The Agile Coach should analyze the team composition and ensure all skills necessary to fulfill the team vision are present. It is possible for a hardware team to be end-to-end, with the use of techniques such as deployment of people with scarce skills, support from Subject Matter Experts (SMEs) and functional roles at the scaled level to ensure that the team can be self-reliant. If a skill set gap is present the coach can facilitate training, skill pairing, team deployment, or hiring so that the team can independently produce working product.

The first step towards cross-functionality on an Agile team is to pair similar skills together on as many stories as possible. An Electrical Engineer and a Mechanical Engineer would be an example of a natural pairing as their education and working experience have many parallels. As time goes on the team members will break down development barriers that typically exist between departments. This encourages the team members to become more T-shaped, which means deep in one area of competence and knowledgeable in other areas. They will understand the impact of “throwing work over the wall”. They will create more efficient ways to do work. They will need access to tools and assets within their own discipline that have been restricted to one or two individuals. An example of where restricted access may occur is within the Mechanical Engineering discipline. The development team may be separate from the Test Lab team, meaning they share the same discipline but only the Test Lab team has access and training on test equipment.

Software team structures are typically rooted in the same discipline; however, they are segregated by stage of software development and access to tools. For example, you may have a software team that is composed of an embedded software engineer, a software development engineer, and an application developer. Some team members may have experience in legacy products and access to specific tools while newer team members may be focused on new product development. It is much easier to break down inter-departmental barriers than it is to break down cross-departmental barriers.

Crafting Vertical Slices of Product Functionality

Product Roadmap development forms the foundation for Agile product architecture that allows for carefully crafted user stories and slices of work so that multiple disciplines can work on the same scope. The first layer of the roadmap should consist of Epics which are composed of large pieces of scope. Epics can be developed in a modular, phased, or business / user experience approach to help establish initial product architecture that enables teams to avoid regressing to waterfall development techniques.

For new programs, customers can support Agile development approaches by using a Work Breakdown Structure (WBS) that is product based, focuses on outcomes, and is compliant with Mil-STD-881. Customers should play a major role in Product Roadmap Development and ensure that Epics are architected to support vertical slicing and are not sequential/departmental pieces of work. The requirements for technical reviews should be modified to allow for incremental and iterative reviews and will require more frequent participation by the customer.

For existing programs that have recently transitioned to Agile development techniques, the customer should request Agile–Earned Value hierarchy and mapping. The Product Backlog must cover all requirements for the work that is being executed by development teams. The requirements are satisfied by the Stories, Features, and Epics. They should map to the Statement of Work paragraphs and Work Breakdown Structure. The customer should make time for more frequent Product Owner interaction and may need to access the Agile tools to have a better understanding of the Product Backlog and Release Plan. Attending the Release Backlog Reviews and major Release demonstrations will provide the Agile teams with crucial feedback that is necessary for continuous improvement.

Before the Integrated Baseline Review (IBR), the customer should have an in-depth understanding of the Agile techniques, frameworks, terminology, hierarchy, mapping and product architecture that is planned to be used on the program. This will allow the IBR discussion to be focused on how realistic and achievable the baseline is instead of discussing the chosen Agile approach.

Waterfall Epics consist of departmental or sequential pieces of scope. It would be difficult to design, develop, test, integrate and produce incremental pieces of working product using this type of product architecture. Teams would have to complete all Epics to arrive at working product.

Figure 1- Waterfall Epics
Figure 1- Waterfall Epics

In the above diagram, the team may be cross-functional and fully able to develop the product end-to-end but the way the work has been architected encourages the team to work within their departmental functions in a sequential fashion.

Epics can be architected into “modules” or parts of a product. Each module or part needs a Known Stable Interface (KSI) between itself and other modules or parts. This helps ensure the integrity of the relationships between them. The Product Ownership team serves as the KSI between modules and handles inter-dependencies and system integration at a scaled level. Modules will need to conform to the constraints surrounding the entire system or product. An example of this would be envelope constraints. If a module needs to fit into an existing product it would have to conform to a specific envelope constraint; otherwise it would not fit.

Figure 2- Modular Epics

In the above diagram, the Epics have been architected into individual parts or modules, so there must be significant focus on integration and system level thinking to avoid extensive re-work. Breaking Epics into modules is one of the easiest approaches that a Product Owner can use to group work because it allows them to visualize and manage the pieces of scope and interfaces in a way that can be easily understood. The weakness in this approach is that the roadmap is not as customer centric as other techniques.

Epics can be architected into waves or “phases” of capability. This is a technique that is best suited for a product that is delivered to a customer in various states or is delivered to multiple phases of customers. The first phase is typically a minimum viable product (MVP). Additional phases build on the MVP to refine and improve the product allowing it to be released to other customers or end users for different purposes. This continues until the product meets the primary end user or customer’s needs.

Figure 3- Phased Epics
Figure 3- Phased Epics

Epics can also be architected as a part of the existing business flow or desired user experience. Epics are organized around the steps the business or customer currently takes, or desires to take, to create or use a product. Epics formed in this manner will draw the organization’s focus to the customer’s desired outcome.

Figure 4- Customer Personas
Figure 4- Customer Personas
Figure 5 and 6

Regardless of the chosen method for Epic development, each Epic can be further decomposed into Features that represent a slice of meaningful functionality to a customer or end user. When the teams are ready to work on a Feature they will break it in to user stories.

Figure 7 - User Story Formation

User stories are typically written in narrative form and should be a testable vertical slice of functionality. The story should encompass requirements, design, development, test, integration and analysis.

Each user story should have a Definition of Done and an Acceptance Criteria. The Definition of Done is a checklist for user stories of similar types and ensures quality and completeness. The Acceptance Criteria helps the team have a clear understanding of the problem they are trying to solve and what test they will have to pass before work will be considered complete. The Acceptance Criteria clarifies the “what” and ensures there is a common understanding of the requirements prior to the start of work.

Vertical slices allow the team to quickly pivot as they learn more about the product they are developing. Because the product is being incrementally tested and vetted by the customer, there is a higher probability that the customer will be happier with the end product and that the product itself will be higher quality. Once vertical slices are ready to be worked by the team, there are many techniques they can use to perform the work with increasing agility.

Hardware Development Challenges

Hardware development is physical in nature therefore it is significantly different from the intangible development of software products. Changes to hardware are generally more expensive due to wasted development efforts, raw material costs, shipping and handling, expediting fees, inventory, and material management costs. Drastic software changes are virtual in nature and so they typically result in re-work and wasted development efforts. This significant difference in the cost of altering a design makes it imperative that hardware teams have less expensive ways to test out their ideas early in the product development process, before ordering more expensive prototype, pilot, or production materials. This is one reason why teams brainstorm many design concepts for components and use virtual modeling, 3-D printing, and simulations to fail the concepts as early as possible, obtaining meaningful customer feedback along the way. They then arrive at the best design solutions and continue to use virtual modeling, 3-D printing, and simulations during sourcing lead times to gain important product feedback about the slice of functionality they are developing. The teams push to build “something” demonstratable to the customer to solicit feedback regardless of prototype, pilot, or production part availability.

Hardware development introduces a special challenge in the form of lead time associated with obtaining a supply of raw materials. As the team rapidly iterates toward developed products, they need a shorter supply chain with vetted and available rapid sourcing suppliers. Adjusting the supply chain to accommodate quick turn suppliers and rapid prototyping takes time. An initial workaround for shortening the onboarding time of prototype suppliers in the Enterprise Resource Planning (ERP) system is the use of purchase cards available to the development team with an associated spend limit. This allows the teams to purchase low cost prototype materials from the supplier of their choice without the red tape associated with getting interim suppliers in the ERP system. A more lasting solution is the development of the sourcing skillset on development teams or the inclusion of sourcing at a scaled level. This will allow the teams to either source materials themselves or access more timely sourcing at the team of teams.

Agile Development Techniques

Many of the agile best practices and techniques that software teams use can be modified and applied to hardware development to create more opportunities for agility along the value stream.

Pair Programming is an agile software development technique in which two programmers work together at one workstation. One person writes code (Driver) while the other reviews each line of code as it is typed (Observer/Navigator) and strategizes about future work or improvement opportunities. The two are both capable of writing code and regularly switch roles. Because the two software team members pair together, bugs are less prevalent and the two are more accountable to efficiently complete work. Many studies have been conducted on the effectiveness of Pair Programming and the results show that pairs have ~15% less defects in their code. However, pairing can become overused if team members spend all day working together and are unable to independently approach work. It can also be distracting to use pair programming for more complex code in which solo work is better suited.

The concept of “pairing” is derived from the Pair Programming technique and can be used to facilitate Development Team Members working together to complete stories for the purpose of shared learning, awareness of the “big” picture, collaboration, and increased knowledge saturation. Pairing is an easy way to start making gains towards a more cross-functional team.

Test Driven Development is a software development technique, also known as red-green refactoring, that requires developers to write and run tests before they write code. The new test is run and subsequently failed to ensure that it captures the necessary logic to be confident in the results. The minimum code is now written to pass the test and the test is repeated to ensure the code passes. If the code fails it will be adjusted until it passes. The code is re-factored, non-functional attributes of the code are improved, and the result is solid code, reduced re-work, and improved quality.

Agile hardware teams borrow from this concept by writing stories with a test in mind and using red-green testing techniques to develop the product to the point that it passes the test. This is often referred to as the Minimum Viable Product (MVP) and it helps prevent over-engineering of the solution. This approach also ensures that work is completely done each sprint and it raises the quality of the final product because the pieces are tested along the way.

Scaling and Infrastructure

Agile development techniques can improve the efficiency within teams; however, there may be dependencies between teams, departments, or supporting functions that need to be resolved in order to arrive at complex, large scale product solutions. Scaling can help address bottlenecks and significantly improve time to market as waste is removed from current development processes. Some examples of organizational waste include handoffs, specializations, multi-tasking, context switching, and decision making by parties not involved in the details of development.

Agile Heat Mapping is a technique where the location and maturation of Agile, lean techniques, frameworks and best practices are mapped out and recorded across the organization. This provides visibility into pockets of Agility and allows for enhanced collaboration, learning, and sharing. It also serves as a baseline for Horizontal Scaling. Horizontal Scaling refers to the spread of Agile approaches across the organization. Teams that are using Scrum, Kanban, various lean and agile techniques, and scaled frameworks can be present within the same organization and yet they are oblivious to each other’s existence. By mapping out the current state of organizational agility, progress can be tracked over time.

Figure 8- Agile Heat Mapping
Figure 8- Agile Heat Mapping

As Agile pockets are discovered and teams push for greater increase in agility, they need to combine efforts in order to efficiently utilize resources and eliminate waste. Value Stream Mapping is an activity where the flow of work through the existing structure is laid out and sequenced. It is all-encompassing from product inception to product production. It helps make inefficiencies, waste, and bottlenecks visible and highlights improvement opportunities that can lean out the value stream. Value stream mapping can provide insight into organizational areas that would benefit from additional Agile infrastructure and scaling. Vertical Scaling establishes infrastructure in the form of an Agile Framework to support development teams as they work. Vertical scaling provides alignment and structure to manage dependencies, resolve impediments, prioritize work and align teams along the value streams. Without this type of infrastructure, the teams are less efficient at system level integration, have more hand-offs, and do not operate as a whole unit with the big picture in mind. 

Conclusion

In conclusion, there are many best practices and techniques that organizations can use to overcome hardware and software development challenges during an Agile transformation. The migration from departmentalization to cross-functionality can be accelerated using techniques such as value stream mapping, skill gap analysis, pairing, and the deployment of scarce skills at the scaled level.

Modifying Agile software development techniques for use in hardware can improve the quality of product and reduce time to market. The difference between software development and hardware development is intangible versus physical product, which can result in costly incremental design changes. Access to virtual modeling, 3D printing, and simulations allows teams to iterate and minimize hardware development expenses.

Customers and contractors can work together to develop the product roadmap and architect work in a way that enables teams to develop vertical slices of functionality. The inclusion of definition of done and acceptance criteria, and the use of user story narratives ensures that the work is completed with higher quality and fulfills all requirements.

Some of the greatest challenges in Agile Transformation surround team composition, product architecture, stable infrastructure, and customer involvement.

Agile Techniques for Hardware & Software Development Read Post »

Agile Manifesto

By / / , , , , ,
, , , , ,

Agile Alliance

On February 2001, seventeen people convened at the Snowbird Ski Resort in Utah to find common ground and develop an alternative approach to document-driven, heavyweight software development processes. The group included representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development and Programmatic Programming. They named themselves the “Agile Alliance” and created and signed the Agile Manifesto which became the cornerstone for the Agile movement.

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and Interactions over Processes and Tools
Working Software over Comprehensive Documentation
Customer Collaboration over Contract Negotiation
Responding to Change over Following a Plan

That is, while there is value in the items on the right, we value the items on the left more.

Agile Streamlines Documentation

Historically, enormous amounts of time were invested in documenting the product for development and delivery. The list was extensive and included technical specifications, requirements, prospectus, interface design documents, test plans, documentation plans, and untimely approvals, resulting in bottlenecks and long cycle times. Agile does not eliminate documentation, rather, it streamlines documentation by providing the developer with just the essentials that are needed to do the work.

People Over Process

Valuing people more highly than processes or tools is easy to understand because it is people who respond to business needs and drive the development process. If the process or the tools drive development the team is less responsive to change and less likely to meet customer needs.

Negotiation vs. Collaboration

Negotiation is the period when the customer and the product manager work out the details of a delivery with points along the way where the details may be renegotiated. Collaboration is a different creature entirely, with development models such as waterfall, customers negotiate the requirements for the product often in great detail prior to any work starting.

This meant the customer was involved in the process of development before development began and after it was completed but not during the process. The agile manifesto describes a customer who is engaged and collaborates throughout the development process, making it much easier for developers to meet the needs of the customer.

Welcoming Change

Traditional software development regarded change as an expense and avoided it whenever possible. The intention was to develop detailed elaborate plans with a defined set of features and dependencies so that the team had a clear understanding of what should be developed and when it should be worked.

Agile welcomes changing requirements, even late in the development and uses rolling wave planning to decompose work just-in-time, without going into elaborate decomposition of the high-level plan.

12 Principles

The Agile Alliance also created 12 principles that support and expand on the four agile manifesto values. These principles have resulted in a number of widely accepted best practices that are used in many agile approaches such as extreme programming, scrum, DSDM, Adaptive Software Development, Crystal, and Feature-Driven Development.

The Agile Manifesto has spread like wildfire since 2001, forever altering the way we develop custom solutions and making impacts far beyond its original software origin.

Visual Representation of Agile Manifesto

Agile Manifesto Read Post »

Developing a Product Vision

By /
Developing a Product Vission

The agile development cycle relies on an accurate understanding of the customer’s needs and the ability of an organization to rapidly develop innovative solutions that best satisfy those needs. A product vision is the first step to defining what needs will be met through the development of a product solution. It gives the company, development teams and stakeholders a unified direction and a common understanding of the desired outcome. Product vision development includes: Identifying and connecting with your customer’s needs, conceptualizing the product features that satisfy those needs, understanding your main competitor’s product and identifying why your product is favorably different. 

To develop a product vision, it can be helpful to first, “Tell the Story”. The story captures the ideal experience your customer will have while using your product and the difficulties they may encounter with existing product solutions.

Here is an example of a user experience story:

U.S. Navy- MK48 ADCAP (Advanced Capability) Securing System

Chief Hatch watches as a torpedoman performs routine maintenance in the torpedo room while they are underway in hostile environments. The torpedoman struggles as he and a fellow sailor carry extremely heavy cables that are used for torpedo stowage. Due to their weight and material composition, the cables create sound shorts when they encounter other metallic objects in the torpedo room. It is crucial that the submarine navigates the seas undetected because the primary mission on submarines is counter-detection. The frequency of sound shorts, due to inefficient stowing, has been a problem for the submarine force since its inception.

Chief Hatch thought about the number of injuries that had occurred just this past year as a direct result of the current MK48 ADCAP securing system and stowage procedures. The desired solution would be a lightweight, equally strong system that would allow for maintenance to be performed safely by a single torpedoman. Ideally, the material composition would minimize sound shorts, allow for easier maneuverability and substantially decrease the amount of space required to stow and handle cables.

From the above example, it becomes clear that the current MK48 ADCAP securing system is compromising the stealth requirements of the mission and is creating a safety hazard for sailors at sea. The customer’s desired outcome in this story is a safe, easy to use, lighter and more discrete securement system.

The next step in creating a Product Vision is to create personas for your primary and secondary customers. These personas will help you capture what is most important or valuable to your customer.

Primary Persona: Chief Hatch

Torpedoman, Chief Petty Officer, Senior Enlisted, 38 years old

Persona Description:

“Chief Hatch believes that a nimbler and easier to use securement system will allow for smoother and more efficient weapons handling, increased sound silencing, mission stealth and a safer crew.” 

Chief Hatch has been on submarines for 18 years. He has watched as weapons have been updated and modernized throughout his career, except for the torpedo handling gear. He is frustrated with the excessive weight of the archaic securement system, especially when it results in crew injuries.

Goals:

  • Chief Hatch wants to update the archaic MK48 ADCAP Securing System with a light-weight, easier to use stowage system without compromising: strength, stability or efficiency.

Motivations:

  • Chief Hatch believes his junior sailors would have a higher retention rate and fewer safety related injuries if they had a lighter more efficient method of stowage in the torpedo room.

Pain Points:

  • The current securement system straps and heavy material composition creates a cumbersome holding mechanism that often results in fatigue, neck injuries and damaged equipment from improper stowage.
  • Multiple sailors are needed to stow, pivot-load or re-stow a torpedo resulting in strain on the current workforce.

Secondary Persona: Lieutenant Marks

Weapons Officer, 30 years old

Persona Description:

“My best days are when I have 100% weapons readiness, all periodic maintenance and weapons handling has been completed safely and on time and I have received no complaints for faulty equipment or poor storage practices.”

Lieutenant Marks has been in service for eight years and is most frustrated when poorly maintained or out of date equipment must be reused to maintain weapons readiness. To Lieutenant Marks a lighter cable with the same strength rating means, easier to maintain weapons readiness and happier sailors.

Goals:

  • Lieutenant Marks wishes to maintain physical readiness in the Torpedo room.
  • She also wants to increase efficiency, safety and technical readiness using modern stowing equipment.

Motivations:

  • Lieutenant Marks is motivated by personal standing in the command, squadron and group.

Pain Points:

  • Lack of material readiness as a result of outdated or overused equipment. 
  • Failed or degrading equipment due to poor maintenance and improper handling. 

Now that you better understand the desired user experience and what is most important to your customer, think about the following questions when you build your product vision.

  1. Who will use your product or service?
  2. What do they need out of the product or service?
  3. What is the product you are developing?
  4. What category does it fit into?
  5. Why should your customer buy this product or service?
  6. What is your competitor’s product?
  7. What sets your product apart from the competitor?

Here is an example of a product vision developed from the above steps:

ADCAP (Advanced Capability) Securing System Product Vision

FOR: “The U.S. Navy”

WHO: “Need a more efficient, reliable and lighter means of securing weaponry.”

THE: “Mark 48 ADCAP Securing System”

IS A: “Modernized Weapon Securing System”

THAT: “Allows for fast stowing and easy handling while pivot tube loading and re-stowing heavyweight torpedo”

UNLIKE: “The current heavy gauge rubber coated straps with rigid metal ends”

OUR PRODUCT: “Provides lightweight handling, increased material strength and improved flexibility resulting in easier stowage and handling.”

STRATEGY: “Replace fleet wide Navy weapon straps on all existing and future classes of submarines”

Developing a Product Vision Read Post »

EVMS and Agile Implementation FAQ’s

By / / , , , , , , , , , ,
, , , , , , , , , ,
Title Image - EVMS and Agile Implementation FAQs

These are some of the frequently asked questions we receive when discussing EVMS and Agile implementations within the same company or on the same project. 

Question 1: What documentation do you have that I can use to help me understand EVMS and Agile and how they are implemented?

Answer 1: There is expansive EVMS documentation, and the EVMS guidelines are well documented. On the other hand, there is little in the way of Agile documentation since the Agile mindset is to be lean and not to document unless absolutely necessary. The DOD released an
EVMS and Agile Program Manager’s Desk Guide that can be used for quick reference. H&A has done the homework and has created training for EVMS and Agile.


Question 2: What is the comparable Agile term or artifact for this EVMS artifact (for example the WBS)?

Answer 2: There is no roadmap between EVMS and Agile that is hard and fast. The best approach would be to identify “similar to” situations or likenesses. For example the EVMS WBS is similar to the Product Backlog within Agile. The Steering Committee of The World Congress in Computer Science, Computer Engineering and Applied Computing reported on Constructs to Support Agile and EVMS


Question 3: What roles within the PMO are there for EVMS and for Agile and how do they relate?

Answer 3: In Agile there is no real “management” role. So the PMO roles that are management titled are not germane to Agile. And in the opposite direction, the Agile roles do not really exist within EVMS. For example the Agile “Product Owner” is a person with a customer view of the product and speaks for the customer. In a stretch this could be a high level Software or System Engineer with requirements responsibilities. The Scrum Master is a facilitator on the Scrum team and there is no corresponding EVMS role. The team members organize themselves so there is no team lead like the Control Account manager in an EVM System.


Question 4: Since the Sprint in the Agile/Scrum approach is defined as a time-box with a fixed end date, how do you reconcile that with the EVMS approach of working the task until it is done?

Answer 4: The EVMS baseline can be set above the Sprint level and can correspond to known “mandatory” delivery points such as release deliveries. This will then align the Agile deliveries to the EVMS structure and the two can work together.

Question 5: Does the fact that Agile/Scrum Sprints have very short durations cause a problem with EVMS performance measurement?

Answer 5: Not at all since teams update their progress daily. But it is preferable if the Sprints are four weeks or less and align with the cut-off dates for the EVMS. In that way the EVMS can pull the stated performance from the teams and use it as the input for the EVMS without any translation work. If a Sprint crosses an EVMS period, that would need special consideration.

Question 6: Since Agile work is not really budgeted, how does that reconcile with the EVMS need for budgets and budget control?

Answer 6: Budgets will be held in packages in the EVMS based on the plan for the Sprints and the teams doing the Sprints. The Agile weighting of work will be within the same packages but is not considered to be budgeting; it is weighting of milestones, if anything.

Question 7: We do not like the idea of the 0/100 EV Technique even with milestones. At our company we have an allowance to earn partial credit for milestone work. How does that fit into the EVMS and Agile implementations?

Answer 7: Agile wants to measure work when done. The work should be in such small stories, or tasks, that they are in-process for only a matter of days. Partial credit should not be needed in this situation; if it is, then perhaps there are issues with work definition.

Question 8: Agile applies to software development, but can we use it for other types of work?

Answer 8: Yes. It is a misconception that Agile is for software only. If you are creative you can find ways to use Agile Development in many areas. One company reports it uses it for circuit design and breadboarding resulting in significant time savings. 

For additional information about EVMS and Agile see the blog post: 

Agile/Scrum Ceremonies and Metrics Useful in EVMS Variance Analysis and Corrective Action

EVMS and Agile Implementation FAQ’s Read Post »

EVM (Earned Value Management) vs. Agile Project Management

By / / , , , , , , , , , , , , ,
, , , , , , , , , , , , ,

This article provides an introduction to the differences between an Earned Value Management System (EVMS) and Agile approaches on projects, and isolates the challenges of implementing an EVMS on a project where the project management has chosen to follow an Agile approach to the development work. The article explores the principles of EVMS and of Agile, and contrasts them to show where there are inherent conflicts. The article then discusses how the conflicts can be mitigated so that the benefits of both the EVMS and Agile can be obtained from a joint implementation.

Controlled Planning with EVMS

Controlled Planning with EVMS

Earned Value Management (EVM) Background

Earned Value Management is a 50 +/- year old methodology based on widely accepted principles that applies documented, systematized practices to support the processes of organizing, planning, directing, and controlling large complex projects, of any nature, which contain a high degree of uncertainty.

An EVMS is structured compliant to 32 guidelines that define what a project management information system should be capable of doing to support the program management team. Within the 32 guidelines there is a subset of generally recognized core principles. The core principles are:

  1. Organize the entire scope of the project using a Work Breakdown Structure (WBS).
  2. Organize the project team using an Organization Breakdown Structure (OBS).
  3. Integrate the project work with the project team to create management control points (Control Accounts).
  4. Schedule the project work in the Control Accounts across the entire project duration at the appropriate level of detail.
  5. Establish time-phased budgets for the scheduled work in the Control Accounts.
  6. Establish the scope/schedule/budget baseline as the Performance Measurement Baseline (PMB).
  7. Authorize the scope/schedule/budget and control the start/stop of work.
  8. Periodically measure the schedule and the value of completed work and determine the Earned Value.
  9. Record direct costs (actual costs) and summarize into the Control Accounts.
  10. Compare planned, accomplished, and spent to analyze the performance and associated variances.
  11. Develop realistic time and cost estimates for the remaining effort in the Control Accounts.
  12. Rigorously control changes to the Performance Measurement Baseline.

The EVM concept presented in these guidelines is a sound management approach, that once incorporated on any type of program, whether research and development, construction, production, etc. provides all levels of management with early visibility into cost and schedule problems.  Earned Value Management now appears as a contractual requirement on programs world-wide.  Primary EVM users include the United States, Europe, England, Canada, Australia, China, and Japan. It is a requirement of many U.S. Government agencies, including the Department of Defense (DoD), the National Aeronautics and Space Administration (NASA), the Department of Energy (DOE), the Intelligence Community, the Department of Homeland Security (DHS), the Federal Aviation Administration (FAA), the Department of Transportation (DOT), Health and Human Services (HHS), and others.

EVMS has been adopted by companies in situations where it is not a contractual requirement so that they can gain the discipline and benefits of the structural management approach discussed in the guidelines.

 

evms 2

Flexible Planning with Agile

Agile Background

Agile is a 20 +/- year old approach to applying a mindset that values the use of small, empowered, self-organizing, multi-functional teams, mainly in software development, to establish a test driven product development effort. This uses a series of short, rapid incremental builds within projects with a high degree of uncertainty to achieve shorter development times, lower costs, and products more closely aligned with customer requirements.

Agile does not usually appear as a contractual requirement. The concept is adopted by companies and organizations with the belief that a better product will be produced faster, and with less expense, using this approach than if traditional approaches were followed.

There are a core set of principles for Agile that were initially established in the copyrighted Agile Manifesto. These delineated core principles are:

  1. Early and continuous product delivery.
  2. Deliver working software (product) frequently.
  3. Expect change and respond positively to change.
  4. Developers and project business organization (PMO) work together.
  5. Product-focused build teams are at the core.
  6. Support self-organizing teams – trust among peers.
  7. Encourage face-to-face discussions (involve the user/customer).
  8. Working software is the measure of progress.
  9. Maintain a constant sustainable pace of development.
  10. Simplify the process and the product.
  11. Put the highest value on technical excellence.
  12. Improve team effectivity.

So How Does Agile Work?

The Agile mindset or approach is implemented through a process of defining the product backlog into smaller and smaller subsets of work that are structured in a top down fashion. At the lowest level of product backlog, the work elements or requirements can be prioritized and assigned to teams. The self-organizing teams pull work from the backlog and work the tasks to completion in a series of short, time-fixed Sprints or iterations. Sprints are often from 2 to 4 weeks long.

Because the teams are self-organizing, there is no team manager or team lead. The teams work as a group and only pull from the backlog at the last possible minute, and do minimal planning for each Sprint. If the product backlog is properly deconstructed and defined into user stories, then the planning meeting for an entire 4 week Sprint can be accomplished in a few hours.

The teams design, code, test, integrate, and deliver functionality in every Sprint. Since tested product is output every few weeks, all on the project can see the product being created and can contribute along the timeline, as needed, to provide a complete finished product.

The product owner embodies the customer’s perspective and either accepts or rejects the team’s work.  At the latter point of each Sprint, the tested product is demonstrated to the product owner.

High Level Side-by-Side

The two approaches are contrasted in the chart shown below. The EVMS is a methodology that is highly documented and highly systematized, while Agile is just the opposite. It is more of a mindset than a methodology with the preference not to have significant process documentation.

The EVMS is applied to entire projects and contracts, while generally Agile is applied to software portions of projects.  However, it could also be used on other development work.

The EVMS is usually a contractual requirement with significant implementation and operation constraints while Agile has none of these. As a contractual requirement, the EVMS carries with it the option for customer reviews and the threat of non-compliance, which entails penalties.

EVM Agile
Methodology Mindset
Documented Self-defined
Systematized Self-defined
Any type of project Software development (mainly)
High degree of uncertainty High degree of uncertainty
Applied to the entire project Applied to portions of the project
Often a contractual requirement Adopted not required

Lower Level Side-by-Side

In addition to the high level side-by-side, there are significant differences within the details of the two approaches. These are shown in the side-by-side table below.

Agile EVMS
Minimal documentation More documentation
Plan at last moment Plan ahead to end of project
Scope is flexible Scope is baselined and controlled
Expect and embrace change Avoid and/or control change
Schedule (Sprint) is fixed.  Timebox ends the Sprint. End the package when the work is done.
Budget is secondary Budget is baselined and controlled
Cost collection is not mentioned. Cost collection at the right level is critical

Accommodate and Capitalize on Differences

It is possible to implement Agile along with an EVMS if the EVMS application is set up to accommodate the differences and capitalize on them.

For example, the main reason that Agile’s embrace of change is a potential problem within an EVMS is because often the EVMS is used to plan too far in advance, and then reacting to change is difficult and expensive. If short term planning in the EVMS can be coordinated with the Agile planning, then the two can coexist.

The Agile free acceptance of scope changes within the backlog runs counter to the EVMS imposition of baseline change control. But if the EVMS baseline can be carefully set at a work level above the busy lowest level ups and downs, the impact to baseline change control is manageable.

A surprising chance to capitalize on Agile, within the EVMS, is found in the Scrum team approach in Agile where the team breaks work down into tasks far below what would normally be done in an EVMS, and then meets daily to update progress and provide corrective action. This low level constant attention means that the EVMS benefits from a better look at real progress as assessed by the real performers.

Not all the compromise needs be on the EVMS side of the equation. The Scrum team operations will often be defined to have the least possible recording of what happens during the Sprint. Since the product is king, then only the product really matters. But that misses the opportunities to capture the actions of the team for analysis, and use in upgrading their skills later. Necessary compromises would include some additional recording of the daily actions of the team and capturing the progress and problems. These would then be used in the EVMS functions of performance measurement, variance analysis, and corrective action planning.

One other compromise in the Agile realm that would be needed is the adoption of some minimum documentation of processes so that team operations can be repeatable and stable. Even a self-organizing team cannot change the way they work every time it wishes. That would raise the risk of a chaotic work environment.

These topics are recapped in the table below.

Agile EVMS Accommodation
Scope is flexible Select a higher level package for the baseline
Change is expected and embraced Have the shortest possible planning horizon
Plan at the last possible minute Have the shortest possible planning horizon
Daily Scrum Stand-up Meeting Collect the data and use it for performance measurement
Sprint Review Meeting Use for periodic measurement and analysis
Sprint Retrospective Meeting Use in Corrective Action Plans
Lack of documentation Add minimum documentation to stabilize team operations

Bottom Line

Implementing an EVMS is a challenge itself. Implementing Agile is a challenge too; perhaps a more difficult challenge. Implementing the two approaches side-by-side can seem impossible. But it is possible and even beneficial if done in a way the makes needed accommodations in both arenas for the project’s benefit.

EVM (Earned Value Management) vs. Agile Project Management Read Post »

Scroll to Top