What does Agile bring to an organization? Why bother with this or any other lifecycle management process, anyway? The answer, of course, is that the process is only a means to an end. The end is the better business value proposition that a company produces, not the process used to achieve it. Of course, the Agile Manifesto Principles speak to this directly. We look at Agile engineering practices that IT leadership should understand, regardless of the software methodology being used in the organization.
The difference between doing Agile and being Agile
Nowhere does the manifesto ever say that to achieve agility we need to implement Scrum, Kanban or any other particular methodology. There’s a difference between doing Agile and being Agile. Doing Agile means following a particular set of observable behaviors, such as exactly 900 seconds of a particular script read while standing done every day at the same time, called a Daily Scrum. Being Agile means conforming to the mindset of the manifesto and molding process appropriately.
Be it good or bad, some organizations will never be able to conform to a traditional Agile process, such as Scrum. Like it or not, some will remain stubbornly Waterfall in nature due to the company’s customs and culture. Does that mean that they can never be Agile? Hardly. But the point of this tip is to say that such companies should not just throw in the towel. There are still things that Agility favors, which will aid even Waterfall shops to get better results in their bottom lines. And what are some of the things that an organization can do that allows them to BE Agile to the extent that it can be? These would be what I call Agile Engineering Practices, which are the essential elements of eXtreme Programming (XP).
The Agile Manifesto principle of “Continuous attention to technical excellence and good design enhances agility” reminds us that everyone can become a little more agile by concentrating on the XP practices. For brevity, I will list these in an order that combines the ease of doing them with the value of doing them.
- Coding standards
Think of a lightweight one-page artifact that defines things like the curly brace style to be used, the capitalization convention in use, guidelines in naming convention and the way the repository taxonomy works.
The rationale here is that the computer can understand code any way you write it. Even without any white space! But how well will the code be understood by the next person who reads it and tries to update it? That’s where your expense is!
- Collective code ownership
By breaking down the walls of ownership, we allow anyone in the organization to make any changes needed to implement features, rather than wait for people to complete “their piece on the assembly line.” Everyone is empowered to make any and all changes in the code needed to implement features. And, when we find that the code was left a mess, we clean it up and act like Boy Scouts. We leave the area cleaner than when we got there. We help each other by making the code easier to read and understand for the group, rather than just constantly vilifying individuals. Yes. Help them understand why cleanliness is next to godliness. We take pride in our collective work, not just how great we are as individuals.
- Small releases
The quicker that we get to working software, the faster we get feedback of how we’re doing. We don’t want to spend six months developing and find that we did a great job, but developed the wrong thing. Better to spend six days and then find out that we were off track, so the rest of the development goes more smoothly!
Automated testing is the secret sauce that gives an ALM the ability to achieve better and better quality continuously, while at the same time reducing the maintenance time that occurs when defects are found in the code. When we take our automated tests and couple them to an automatic build process, we immediately get a huge win that allows a fairly small investment in practice to yield big results going down the road.
- Simple design
Simple design is anything but simple. It recognizes the fact that computers really don’t care what the code looks like. Computers will blindly execute whatever the compiler produces! And if it all works and we release it, we’re good, right? Wrong! To maintain and/or extend the software, humans have to understand it again. And that’s where the costs are. Spending time writing good code pays off big time. Recognize that getting there can be demanding. The remaining XP practices, which we’ll look at next, tell us how to accomplish simple design.
When we make the assumption that we can understand all of our requirements up front, we are fooling ourselves. Except for the most trivial of products, we can never know what the real requirements for our product will be over its useful life. So, why try to build complex software for the ages when we can build good software for the present? The secret is to do a good job with sound simple designed software now, add the code to meet the new requirements, and then refactor our code to make it simple again. Couple continuous integration into the mix and we can always be certain that we never regress as we refactor, keeping the costs low as we move forward.
- Test-driven development
But how do we know what to refactor? How about putting everything on the table and allowing anything to be refactored? That’s going to require complete test coverage of our code. And that’s what test-driven development is all about. Kent Beck said it best when he tells how to do test-driven development: “1) Never write a single line of code without a failing automated test. 2) Eliminate duplication.” In other words, use continuous integration on and refactor code that has complete test coverage (because you don’t write the code until you have a test for it). Great idea, but, honestly, hard to stick to. I would compare it to sticking with a diet. You know you use test-driven development just like you should stick to your diet, but that crème brûlée makes it tough to stay on the diet wagon.
- Pair programming
Pair programming is potentially the best XP practice out there. Design and code reviews make sure that we stick to our principles and create software using all those best practices all the time. Imagine if we reviewed all the code all the time, and never allowed bad code to exist for even five minutes. That’s what pair programming can do for us. Productivity skyrockets, but it takes a business that is not afraid to make a bold investment in faith to “use two people for one person’s work.” In reality, the two people will do the work of three in the long run, but you’re going to need forward thinking to embrace this.
Follow us on Twitter at @SoftwareTestTT and let us know what you thought of this article.