Creating useful software is a craft. There is no black and white formula for success. Yet, there are certain Agile engineering practices that, if used thoughtfully, have shown to repeatedly add value to a business. In this article, I’ll share 5 specific ways that your business can benefit today from Agile Engineering practices.
(If we use the basic formula of Scrum + Extreme Programming (XP) = Agile, I am referring to the XP piece of the equation when I say Agile Engineering Practices. Things like Test Driven Development, Pair Programming, & Continuous Integration.)
In a brilliantly simple blog post, James Shore claims:
"Scrum is easier and less threatening than XP(Extreme Programming), so I see a lot more people starting out with Scrum. On the downside, the teams that start with Scrum tend to struggle more than the teams that start with XP. The XP teams experience more pain starting out, but then get to a high performance state within the first year."
I agree and have seen this many times. XP is hard. It’s hard because it takes discipline and because the benefits of good, solid XP are sometimes not seen immediately.
My father’s a dentist. He once told me ‘Finding a good dentist is hard. A dentist can fill a cavity or do a root canal, and you won’t know for 5 years if the work was of quality, because the only way you can tell if a dentist does a bad filling is if it breaks down the road. ” XP is kind of like this.
The best software developers I know, and I know hundreds, are the ones that are the most disciplined during high stress situation.
Many developers practice some flavor of Agile/Scrum/Lean/XP. But how many of them maintain their level of dedication to XP when a tight deadline is approaching, or when the team falls behind, or when someone from the business demands the team to ‘work faster’?
There are many XP practices. The most valuable ones for a business are:
- Test-Driven Development (TDD) – TDD is your business’s safety net. Tests are written and designed to fail. They are written before the code is written. Code is then written with the purpose of making the test pass. TDD ensures your product is functional no matter what large or small change the business and tech teams implement.
- Pair Programming – Having 2 developers work on one piece of code, using one keyboard and one monitor. Pairing results in higher quality output because it greatly reduces wasted time and defects, and results in high collaboration.
- Collective Code Ownership & Continuous Integration – Bottlenecks are eliminated when more than one person is familiar with each piece of the code. Code is continuously integrated into one main branch to avoid duplication and mismatched code.
- Refactoring – Code should be written to solve the known problem at the time. Often, teams become wiser about the problem they are solving, and continuously refactoring and changing code ensures the code base is forever meeting the most current needs of the business in the most efficient way.
Yet given that XP is hard, combined with the fact that it takes continuous discipline and time to do well, executives want speed. CTOs, VPs, CEOs say “I want my engineering team to get better at Agile engineering practices so that we can go faster.”
I agree with James Shore that XP is a struggle at first, which in fact goes counter to the idea that Agile helps teams move faster. In fact, XP has a steep learning curve, and by it’s nature, learning takes time and learning XP is achieved by going slower than a team that isn’t doing any learning.
So, if “going faster” isn’t the true value of Agile engineering practices, then what is?
I believe that the true business value of Agile engineering practices is that they allow a company to embrace change in a way that actually becomes a competitive advantage.
Why?
As we enter 2014, the argument could logically be made that all, if not most, companies are technology companies. If that’s true, then it would follow that the companies that can best leverage the process of building software are the ones that will succeed in the next decade.
It is, of course, true that there are many competitive advantages to be gained outside of software and that will remain true. For example, the hedge fund that can best leverage a mathematical formula for tomorrow’s stock predictions will have a competitive advantage. The retail store that can best leverage fabrics and colors to predict tomorrow’s fashion will have a competitive advantage. But, with 24/7 connectivity and global information sharing, the minute you have a truly good idea is the minute your competitors will attempt to copy it.
Which brings us full circle back to the concept that the companies that can best leverage the process of building software are the ones that will have the greatest advantage over their competitors. The key is the word ‘process’. It’s tech stack agnostic. And the key to getting the full benefit of Agile Engineering Practices is having the diligence to uphold a certain minimum level of process discipline when things get hairy. It’s like exercising. If you exercise 5 times a week when you’re on vacation and 1 time per week when you have a tough work week, then in actuality you exercise once per week. If you practice pairing and TDD when you have no deadlines and throw Agile out the window once you have a tight deadline, then you’re not diligently practicing the process of Agile.
Five specific benefits that businesses can gain by using Agile Engineering Practices are:
1. The Flexibility to Turn on a Dime
My firm built an ecommerce platform for a large retailer. The team was 3 months into a 6-month initiative. We were working in 2-week sprints and releasing code to production every 2 weeks. One day, the product team’s competitive intelligence research turned up that a competitor was changing the way they handled sales and credits for returns. Since the code we wrote in the last sprint was fully tested, integrated with the rest of the code, and already pushed to production, we knew our code base was solid and could be changed without any large risk of downtime or defects.
The next day, instead of continuing along building what we had planned, we had a requirements gathering meeting, estimated how long it would take to build the new feature, and reprioritized our stories. In a matter of days, a set of new features was prioritized, scoped, and moved to the top of the prioritization queue and was being worked on by the team. A revised credit card returns engine was pushed to production 2 weeks later. No bugs were found and the marketing team was thrilled.
Thanks to Agile Engineering practices including Test Driven Development, the business knew they could rely on the technical team to turn on a dime and keep up with the competition with minimal risk to the quality of the online brand presence.
2. The Option to Re-Allocate Development Team Members in Real Time
One result of turning on a dime and releasing a new credit card return engine in 2 weeks was that the team needed 4 instead of 2 engineers working on the feature to get it done within the sprint. Since pair programming and collective code ownership allow team members to rotate and work on various parts of the code, we were able to pull a pair that was finishing up another story onto this new high priority story and maintain our velocity as we reprioritized.
With Agile Engineering, the project doesn’t get held up by any one rock star who’s too busy on something else. The whole team can morf to the new requirements. Those best equipped to work on the new feature can be dedicated to it. The team is in constant communication so adding more engineers to a story is fluid and not disruptive.
3. The Comfort of Avoiding Having to Scrap Months of Work
Another benefit of having code completely tested and in production as soon as it’s ready is avoiding having to scrap work. When we identified the need to work on the credit card return feature, we were able to jump right into the newly prioritized feature. There was no work in progress to be scrapped. There was no half finished feature that had to be finished or pushed off before we could begin the new work. All of the code that had been completed to this point was high quality, bug free, integrated and functional.
4. The Confidence of Knowing That the Completed Features Always Represent the Most Important Pieces of the Project
A few years ago, my team was working on a project for a large government agency. The project was a long term one, and we were a year into coding. We had been using Agile Engineering practices so code had been pushed to production continuously.
One morning, a stakeholder changed his mind about priorities for the project. He was anxious that as a result, other important features might not be completed. He wasn’t familiar with the day-to-day project progress and wasn’t yet aware of the business benefits of Agile.
Thanks to the fact that the engineering team had been working closely with the business side to prioritize their work every 2 weeks, the most important features of the past year had been completed, fully integrated, fully tested and were rock solid.
The business was confident that in any point in time, the most important features are being worked on. And, the stakeholders can rest assured that any change to their software, no matter how big is not only possible, but embraced and low risk.
5. The Ability to Plan Marketing Campaigns with Confidence
We’ve all been there. The business plans a marketing campaign. I’ve often worked with teams that are coding software for an immoveable date. Last year, we led a project for an education services firm. A marketing campaign was to be rolled out. It was to an immoveable date: back to school. They wanted to have a huge back to school sale and the features had to go live on August 10th. Since the date was fixed, and marketing had already spent hundreds of thousands of dollars on TV, print and online advertising, the ecommerce site had to have a minimum set of features.
What typically ensues? I’ve seen countless engineering teams that wind up between a rock and a hard place. August 1st hits, the Product Manager realizes there’s no way we’re hitting the date, and the engineering team winds up working 100 hour weeks for the next 2 weeks, to get the product out the door. But, when teams work this much, the individuals get tired and burnt out, and that’s when mistakes are made.
If teams can manage to keep their agile discipline high, and continue to lean on the engineering best practices, then TDD, Continuous Integration, Pair Programming and the other cast of characters will guide the team to releasing on time and with their sleep schedule in tact.
And that’s just what the team did. We kept our Agile discipline high in a time of high stress and we stuck to our guns. The key to using Agile to enable true marketing campaign confidence is – embrace the fact that there are multiple ways to achieve many features. For example, if one feature is video upload to your site, there are (at least) 2 ways to do this. Choice A: Takes 10 days of development work – enable a user to upload any video file in any language and any format of any length. Choice B: Takes 1 day of development work – enable a user to paste a YouTube link into a field.
I don’t know about you but if I’m the Product Manager and it’s August 1st, I choose option B.
The end result was that we successfully released the product on August 10th, with all of the critical features in place. We intentionally built up a lot of Technical Debt, including the choice to build the 1 day video file upload feature. After August 10th came without a hitch, we prioritized new features and the Technical Debt we had built up. Technical Debt was prioritized in put into the story queue along with new features, and away we went, back to our 2 week sprints and sustainable pace.
In summary, the value of Agile Engineering Practices has moved beyond the engineering team and is clearly beneficial for the entire business. Companies that are able to continuously utilize efficient development processes will have the greatest advantage as we head into the next decade. Have questions about the best way to implement Agile Engineering Practices for your team? Ask me any questions you have, I can help and will gladly bat around ideas over coffee or drinks.
About the Author
Debbie Madden is a seasoned executive, strategic advisor, and a connector. Currently, she is the CEO of Stride, providing strategic advice and fractional CXO consulting to executives and entrepreneurs. Debbie believes in people first. Passion, Honesty, Courage and Fairness are the 4 standards she lives and works by. She specializes in leading and advising companies in the technology, professional services and startup spaces. Debbie believes that the process of building software is going to be a company's greatest competitive advantage in the next decade. Agile and Lean Startup drive her thinking. She believes that an iterative, collaborative approach results in empowered teams and aligns individual passions with business priorities. For the past 10 years, Debbie ran Cyrus Innovation. Most recently, she was the CEO of Cyrus and grew the firm from zero into a 60 person, multimillion dollar, 5-time Inc 5000 Fastest Growing Private Companies winner, and Crain's NY Best Place to Work.
