Operations, Tactics & Strategery

When employing an agile methodology it is important to measure those key activities that deliver value and promote the right behavior. An Agile methodology can be measured with key measurement types such as productivity, quality, timeliness and utilization. As long as the measures demonstrate why and how an Agile method can affect the projects success and business value. 

Do not fall into traditional metrics that promote the wrong behavior or do not align with the project. For example, lines of code per developer week or per iteration or function points developed. This type of measure could promote code bloat as visibility is shed on generating lots of code or generating a lot of effort. Plus the more effort or lines of code in the product, the more there is to maintain. What is really needed is a measure to determine if the functionality was completed. A measure such as features completed versus features remaining. This measure will help determine how much business value was delivered to the customer, if the feature is not complete then there was no value delivered to the customer. The measures should drive the right behavior.

I recently had a conversation with an ex-colleague that now runs a project management organization. We discussed the challenges of measuring an agile methodology such as scrum. This organization just implemented scrum about a year ago. The organization had no baseline to compare against their scrum process. So it was difficult for the organization to determine exactly how much value their scrum process added compared to their old development process. This was a management decision not to spend the time or resources to baseline and normalize their old development process to compare to the new one.  

Instead the resources were spent on measuring their new scrum process. The organization measured everything they could. At the end of the day they were left looking at a bunch of numbers. Most of their metrics were still traditional metrics promoting the wrong behavior. They did not focus on what was important. Six months later the organization conducted the same exercise but focusing on what was important. What was important to this particular team was velocity. In scrum that is, the number of story points per sprint. This was important because the owner of the project needs this information to make release related decisions.

Measure what’s important and delivers value.

Customers define quality. Creating quality software means delivering a product that not only meets customers needs but also their expectations of how it should work. When is the last time any of us read a requirement document that outlined the customer’s perception of quality? I’m sure quality is omitted from a requirements document because it is assumed. Maybe quality is omitted because we are afraid to ask our customers to define quality for us. After all, we position ourselves with our customers as people who have all the solutions to all of their problems. We know everything, so we know all about quality. Right? Maybe we are afraid to ask about quality because we can not truly deliver quality. To be fair, the question probably does not get asked as much as it should because the customer’s definition of quality is always changing.

To meet this moving target we need to be more agile. Many organizations spend a significant amount of time up front gathering requirements. Prior to assigning development resources, the requirements are defined in a requirement document and all development decisions are based off that document. What if the customer’s requirement changes? There is a good chance the customers business landscape will change affecting the requirement. How would development know of this change from a static document that has been defined and approved 4 months ago? There is a good chance the requirement will be developed without instruction, a story or some context of how the customer will use the functionality to meet their changing business needs. How do organizations deal with this misalignment between the customers, their customers business and their own development lifecycle?

Many development organizations have addressed this type of problem by migrating from their traditional code and fix or waterfall methodology to a flexible agile development methodology such as XP, Scrum, EVO, ASD, etc. Agile methodologies promote frequent adaptation through iterative steps called iterations. Each iteration lasts a short period, is worked on by an entire team through a development cycle. The benefits of agile methodologies provide organizations the ability to adapt quickly to customer’s needs and expectations. Many organizations employ a more hybrid agile approach to fit their organization.

Organization’s that employ a type of agile methodology improve their chances at meeting customer expectations and delivering quality in the eyes of the customer versus their code and fix or waterfall counterparts. Even if your organization does not employ an agile methodology find a way to narrow that gap between requirement gathering and user feedback to ensure the product is meeting the customers needs and their expectations. The next topic will discuss measuring an agile program.