In the Agile Process 101, we reviewed the agile process and the potential benefits it brings to software development. But how should you assess your agile process in order to spot critical gaps? Many organizations are unsure of how to gauge agile software development processes. Small or large, your gaps could be costing your organization money and unnecessary resources. Here are some recommendations, from our team, on how best to evaluate your agile practices:
- Look at your defect rate. You should see a reduction in the defect rate and an increase in your business delivery value.
- Determine your metrics based on the level of iteration. Write down the input metrics you know and which ones would be desirable to know. Keep track of these metrics. Did they meet your goal? If not, which results were different? Perhaps you had incomplete data when you were planning? Use what you know and what you’ve learned (that’s the agile way, after all) to adjust and improve. If none of the above, then it’s probably a process problem: lack of communication or access to resources, bad prioritization, poor design, etc.
- Evaluate your end users’ satisfaction. Generally, business users should be more efficient when using the software if it is an internal product; better sales if it is a consumer product. By having a working product early on you can get that in the hands of beta testers and get feedback in real time rather than waiting until the end of the project to get feedback.
- Make sure you are driving business value. You want to demonstrate as much value as early as possible so that the project can become self-funding quickly. How you define value will be completely reflective of your own company, application, and challenges you are trying to solve.
- Evaluate lead time and cycle time if you are using Kanban – and evaluate the effectiveness of sprints and planning if you’re using Scrum.
- Evaluate your team and leadership productivity
Your teams should be self-managing and self-motivated. They should strive for collaboration and continuous improvement. Leadership should be involved while not micro-managing. Here are a few questions you might want to consider to evaluate your team’s performance.
- Are your developers putting in overtime? This is a big red flag no matter what process you are using. Your software quality should go up and your developers should be spending less time fixing bugs than they do implementing new features.
- Do you have a reduction in reworking? There should be productivity improvement through reducing rework. You want to be more productive with the same amount of time.
- Is your communication clear and transparent throughout the team? Do you have someone who can speak well to the business?
- Is your team structure flexible? Companies tend to lean toward more dogmatic and rigid team structures, whereas the Agile process tends to deemphasize that to a large degree.
“Part of agile is to form a cohesive unit that figures out how to work together and essentially hits a stride and a certain level of velocity in the way they output software. It is all about velocity. If you are intertwining members in and out, you are just losing that speed.”
-Jurek Dzierzanowski, Managing Director, nvisia
Agile should make you aware of recognizing velocity. Agile doesn’t necessarily make your team work faster, but you do get higher ROI due to high quality and earlier delivery.
Agile software development process – related to communication and code adaptivity - maturity model
Where do you fit?
| Underperforming | Maturing | Best-In-Class | |
| Communication/ Organization structure applied to Scrum |
Characterized by a rigid, hierarchical structure that mirrors the organization chart. Authority is derived from position. Scrum team may need to "ask permission" to access resources. All decisions are made in deference to those in positions of authority. |
Characterized by an egalitarian model of open communication. Business stakeholders advise team on business needs and make decisions related to cost and access to resources based on advice from team. Information is gated between team and business through a product owner and/or Scrum master. Roles are acknowledged as needed but all roles are treated equally. | Characterized by a flat organization structure. Business stakeholders collaborate near constantly with team members to derive requirements and design the product. Access to resources is as needed with no roadblocks. Information is not gated at all but product owners and Scrum masters can act as mediators and recorders of decisions. Roles are fluid depending on need and skill levels. Titles may change as needed since authority is not tied to structure. |
| Code adaptivity |
Software acts as a barrier to business productivity. Because of its low maintainability, scalability, or reliability, IT may spend much of its time trying to keep the software maintained and working to minimal standards. Software provides only basic needed functionality for business with few opportunities for adding value. The addition of new features is slow and painful and regularly leads to introducing bugs. Release deadlines may slip because of delivery problems and extended outages are possible. |
Software supports current business needs with little to no downtime. It is sufficiently maintainable, scalable, and reliable as to have a regular release cycle with bugfixes as needed. Most development work is for the purpose of adding new features to support ongoing business needs. There are still few opportunities for adding value. |
Software serves to drive strategic business goals and provides new growth opportunities. It not only supports all business functions but is sufficiently maintainable, scalable, and reliable to anticipate likely future need. It may support research and development projects and add value by enhancing competitive edge in the market by staying ahead of emerging trends. Releases likely follow a continuous-delivery format with users being largely unaware of release schedules due to seamless integration. |
Make sure to also check out The Agile Process 101. If your organization is looking to improve its overall agile process performance, don’t hesitate to reach out to nvisia.
We’ve also included some resources for you from our team of agile experts:
- “Agile Testing: A Practical Guide for Testers and Agile Teams”; Lisa Crispin; 2008; click here to learn more on Amazon
- “Scrum Handbook: Single Team Scrum”; Dan Rawsthorne and Doug Shimp; 2018; click here to learn more on Amazon
- “Adaptive Code: Agile Coding with Design Patterns and SOLID Principles”; Gary McLean Hall; 2017; click here to learn more on Amazon