Becoming Agile is not just a process change. That’s the first and probably most common misconception–and pitfall–in an organization’s Path to Agility®. There are several facets of an Agile transformation, and a big one is to improve technical practices.
Below are links to the previous pitfalls if you need a refresher.
- Pitfall #1: Thinking Agile is Simply a Process Change
- Pitfall #2: No Guidance
- Pitfall #3: Not Providing Slack to learn
- Pitfall #4: Leadership Out Of Alignment
- Pitfall #5: Transparency Is Abused
- Pitfall #6: Lack of Feature Teams
From tech best practice to mandatory technical practices
Though begun with the best intentions, an Agile adoption with lackluster tech practice will fail. It’s similar to getting a weight loss meal plan and then chucking it out the window for Big Mac’s. You can say that you’re Agile, but if your organization isn’t embracing the following technical practices, then you can never be Agile.
Test Automation
Tests that would have been/are being run manually should be run automatically and as often as possible. At the same time that code is developed, QA’s and Test Engineers should build tests so that they’re ready to use when the feature is completed.
Continuous Integration and Continuous Deployment (CI/CD)
As soon as the feature has met acceptance criteria, it should be integrated to the system and the entire product should be deployed – and regression tested – to ensure that the addition did not break the product.
Barely-sufficient (“simple”) design and architecture
People in my classes have heard me talk about the red dragon. If a team was tasked with building a red dragon, it’s very possible that the red dragon would soon have horns, talk, sparkle, and have the ability to communicate telepathically because developers are very creative people. In reality, there are only a few characteristics that make a dragon a “dragon,” a lizard-like creature with wings and the fire-breathing capabilities would be sufficient.
Remembering cross-functional requirements
There are additional items that serve your greater infrastructure but can increase the scope of work for all user stories. Here’s a great blog post by David Croley with a foundational list of overlooked cross-functional requirements.
Goldilocks Documentation
Another common misconception about Agile is that it eschews documentation. While too much documentation can be a waste, too little could inhibit cross training and scalability. You need a documentation protocol that’s “just right.” An example includes paragraphs on capturing how a feature is supposed to work vs. hundreds of pages of requirements. It’s also important to write with a clear goal in mind–how would this document help to achieve the project’s overall mission?
The cost of finding a needle in a haystack
Here is a scenario of how ignoring tech best practices like test automation and CI/CD can really add up.
Imagine you had 10 developers working on a project and each developer averaged 200 lines of code every day–that’s 2,000 lines of code/day. One day, a developer makes a mistake causing a bug in the system. Unfortunately, you did not have test automation or CI/CD in place. The time has come to test your product, 90 days in and 10 days before it’s supposed to go to the stakeholders for feedback. Your team discovers the bug.
That’s 180,000 lines of code to sift through.
If test automation and CI/CD was in place, the bug would have been discovered quickly, possibly on the day it was created. Your team would only have had to check 2,000 lines, not 180,000.
ROI of improving technical practices
Set your team up for success and implement technical best practices along with Scrum ceremonies and other process changes. While it takes real time to get a testing infrastructure in place, it’s easy to recoup the initial investment. Therefore, technical practices strongly affect your organization’s ability to shorten the time to market, which is a huge benefit of Agile adoption.
In addition to functional test automation, you can also eliminate waste by adopting test-driven development (which includes a subset of test automation) where tests are written and built before production code is written. If tests are written by developers before they write production code, design is given another look and there’s a smaller chance of developers getting red dragon syndrome. Once all the tests pass, developers stop writing code.
You can read Pitfall #8 of our Agile Transformation series here, where we discuss how focusing on just the team instead of the entire organization can stall your Agile adoption. Don’t forget about the final pitfalls, #9 & 10 concerning team misalignment.
Follow the entire series:
- Pitfall #1: Thinking Agile is Simply a Process Change
- Pitfall #2: No Guidance
- Pitfall #3: Not Providing Slack to learn
- Pitfall #4: Leadership Out Of Alignment
- Pitfall #5: Transparency Is Abused
- Pitfall #6: Lack of Feature Teams
- Pitfall #7: Not Improving Tech Practices
- Pitfall #8: Focusing Only on the Team
- Pitfall #9 & 10: Misalignment between the team, customers, and the IT enterprise organization
For more on our approach to building lasting business agility, you can check out our Transformation Services page.
