The tool is an Excel Spreadsheet, and a smart one at that with sliders to relatively weight 11 criteria from 0 to 100%, red/yellow/green indicators for fit, and smooth bar charts to visualize the results. Someone was obviously well-versed in Excel, it is a 10 on the “cool” factor. You can see a picture of it below…
However, the look and feel of this scorecard is where the “coolness” ends. Evaluating the criteria of the scorecard is where things go south really fast.
Criteria 1: Criticality of the Application
This scorecard indicates that critical applications are not suited for Agile. It lists critical as projects with “high financial, schedule or safety risk require a more rigorous approach (documentation, testing phase once all code is complete, etc.). In my experience, the more critical the application, the more need for Agile to flush out the risk. This scorecard is perpetuating a myth that Agile is less rigorous than “traditional” approaches, when in fact proper Agile is more rigorous with more frequent inspection, integration and test cycles. It also perpetuates a myth that Agile teams don’t document or that final testing phases are not part of Agile programs. There is nothing in the Agile lexicon that inhibits a team from documenting their work and running final regressions once all code is in. We have been running Agile programs in regulated industries like Healthcare for years – incorporating requirements traceability and regression testing practices.
Agile is more beneficial for critical programs because it highlights issues more quickly which provides the team and leadership more time and options to address the issues.
Criteria 2: Regulatory Requirements
This scorecard indicates that Agile is not appropriate for compliance or regulatory environments. Why? It does not say. Again, Agile approaches have been used in regulated industries for over two decades and there is nothing in Agile that prevents a team from performing the activities they need to perform to meet regulatory requirements. In my client examples, the regulatory processes were integrated in the team’s definition of done for most of the routine chores such as documentation and traceability. In functions requiring more external review and approvals, a slightly longer cadence (e.g. every few sprints) was used to keep from straying too far from the a potentially shippable system.
Criteria 7: Complexity of Integrations
This scorecard indicates that projects with more, or more complex, integrations should avoid Agile. Agility was designed for complex environments. When evaluating simple, complicated, complex and chaotic systems – traditional phased-based approaches address the simple and complicated projects relatively well. However, up front planning and design fall apart for complex systems as they are only visible and straight forward in hindsight. Working in complexity is like driving in the fog. While we can plan for and predict that the road ahead will be straight and map out the obstacles, the fog of complexity makes these plans fraught with error. Agile leverages more touch points by more people more frequently to more quickly analyze and identify the road ahead and the roadblocks in our way. Further it leverages frequent integration of components and systems to more quickly identify gaps and missed communication.
Criteria 8: Team Size
This scorecard indicates that projects that require team sizes greater than 10-12 people should avoid Agile. Wow! Sorry SAFe – no place for you here. Sure Agile teams should be 8 people or less. But an Agile project can have more than one team! We have been scaling Agile programs for over a decade. Salesforce.com, one of the most prominent Agile organizations leverages dozens of teams to deliver on their seasonal releases and aligned on a monthly Sprint review cadence. GE Healthcare has two-dozen teams focused on medical imaging systems collaborating in a shared two-week Sprint cycle with quarterly internal and external releases. In fact, it is the exception in my consulting that organizations have only a single team focused on a single project or product delivery.
Criteria 11: Co-location
This scorecard indicates that teams which are not in the same timezone are not well suited for Agile. Really? What are dislocated teams well suited for? Nothing. All teams are hampered by dislocation. Agile teams actually have an advantage here because they communicate and integrate more frequently to make sure that each location is in sync. Co-location is not an Agile disadvantage – it is a program disadvantage. Whether Agile, or any other approach, dislocated teams are slowed down by delays in time and miscommunication. There are many successful dislocated Agile team patterns – the most popular is breaking multiple teams along the dislocation so each project sub-team is mostly co-located.
I could go on and on, and on, and on…
This scorecard goes on to list awareness of, and previous exposure to, Agile are a good thing and will support your Agile choice. I agree, but it does not determine whether I would do Agile or not, it determines whether or not I need to bring in Agile expertise, education and coaching to help it be successful. This would be similar to any knowledge or experience gap my team has. One client told me Agile failed because of a project failure with a team of three interns. I told them that Agile actually predicted that – as the Agile Manifesto proudly states – Individuals and Interactions over Processes and Tools. Nothing substitutes for strong people collaborating strongly.
If you want to evaluate whether Agile is right for you, ask an experienced practitioner. Be wary of flashy Agile Project Fit Assessment Scorecards and dig deeper into what you are seeking to accomplish and if forming an experienced team, or team of teams, around this goal with frequent inspection, integration, collaboration and adaptation would be helpful in achieving this goal. Most often, it is the best approach.