The Agile Architect

How I Won the Battle but Lost the War: An Agile Saga (Part 2)

How does a project get late? One day at a time. Our Agile Architect shares some common pitfalls plus 15 sometimes seemingly contradictory tips that will help you win the war.

• By Mark J. Balbes, Ph.D.
• March 11, 2014

More on this Topic:

• How I Won the Battle but Lost the War: An Agile Saga (Part 1)

In my last column, I told a tale of a game show contestant who did everything right but still lost in the end. And no, I haven't lost my mind. That story did have a point and it is related to agile. Or, and this isn't too much of a stretch, I have lost my mind and what you are about to read is totally nutso. You be the judge.

17 Tips To Win the War
After the tragic ending of my last column, I thought I'd share with you my do's and don'ts on how to win the software war without having to win every battle. And, as is true of many things in agile, this requires a redefinition of what battles we are fighting, what war we are trying to win, and how we do both.

1) Do Build Only What the Customer Wants
Too many times, we as Engineers fall in love with our own ideas. We build things that we are sure our product owners and users will love. If we aren't careful, we can spend a lot of time on a totally useless feature. I know from experience the thrill of showing off a new feature to a user that I spent hours, days or weeks building only to have them tell me, "Looks nice but no one will ever use it." To avoid this, make sure you have a rough product roadmap that you continuously vet with real users. As you get closer to developing those features, some quick mockups or paper prototypes can ensure that users are on board with what you are building before you build it.

2) Don't Build Only What the Customer Wants
Don't be so focused on a few available customers and forget that there's a bigger world out there. Also, customers are not software developers or UX designers. They may tell you very emphatically what needs to be built and how but it often mimics their current workflow. We as software developers need to look past that to understand what they are trying to accomplish and build something better. We had a customer that kept their data on a single spreadsheet. They came to us to help them build what was essentially a Web-based spreadsheet. Instead, by working with them to understand their real needs through the agile evolution of the product, we built a much more powerful system that looked nothing like a spreadsheet. (And they were extremely happy!)

3) Do Focus on the Big Picture
Know where you think you are going. As developers we make many micro-decisions each day that affect the design and workings of our software. By understanding where we are ultimately going, we can make better choices.

4) Don't Focus on the Big Picture
When building a feature only focus on what you need now. Leave details and polish for later. Building for tomorrow often leads to bloated or unused code that has to be supported but provides no value.

5) Don't Polish Your User Experience
In the end, the user experience can make or break your application. However, it doesn't have to be there from day one of development. Craft your product like you would a statue or a painting. Rough it out first. Make sure the functionality flows and the user can accomplish what they need. There will be time to polish closer to the release date when the high-risk code is mostly written and tested and there is finally time to fix those high-value, low-risk issues.

6) Do Polish Your User Experience
If you are on a fast release cycle, of course you have to keep your application polished at all times. There is no tomorrow because the product is almost continuously being released.

7) Don't Design for Tomorrow
One of the common causes of a project being late is when teams spend too much time architecting and designing features that they aren't immediately implementing. They often find that they never actually build what they had thought. Either requirements change, technology changes, or they learn and get better ideas. When teams spend too much time designing on paper, they aren't building the system and learning from it.

8) Do Design for Tomorrow
One of the common causes of a project being late is when teams take the mantra of "Design for today" too far. Certainly you don't want to spend too much time designing things you aren't going to imminently build. However, it's great to have some architectural and design direction to give the team something to steer towards. Just don't be afraid to change course when the evidence tells you to. Remember that the farther out you make your plans, the more likely they are to change.

9) Do Fail Fast
Too many times, developers get stuck trying to implement a specific solution to a problem. They can't figure out how to make it work, but they won't give up on it. Instead, think like a venture capitalist. Place lots of small bets and see which pan out. If you aren't sure of a direction for your software design, explore multiple directions but be willing to abandon the ones that aren't bearing fruit. Spikes are a great way to quickly fail a lot. Thomas Edison once said, "Negative results are just what I want. They're just as valuable to me as positive results. I can never find the thing that does the job best until I find the ones that don't."

10) Don't Fail, Period
Too many times, I see developers try to solve a very hard problem, only to give up and code around the real issue. Eventually the core unresolved problem comes back, usually when it is even harder to solve because the product code base is more mature and ingrained. If you have a hard problem that has to be solved, solve it!

11) Do Adapt for the Project Release Cycle
Different project have different forces on them. A project that releases every week has a different cadence and different needs from a product that is released every 6 months. (And before you remind me that a 6-month release cycle isn't agile, many military projects cannot afford more than one or two releases a year because of the extremely high cost of training involved.) Release as often as possible but not more.

12) Don't Adapt for the Project Release Cycle
There are certain things that we do as agile software developers that maintain the high quality standards needed to maintain an adaptable code base. Don't compromise on TDD, continuous integration and all the other practices that make an agile project successful no matter how "fast" you try to go.

13) Do Make Time for Automation
Automating redundant or error prone tasks is a great way to give your team more time to spend building the product. Investment in infrastructure for even a modest project is usually time well spent.

14) Don't Waste Time on Automation
Don't automate something until you can do it manually, whether it's your build process, testing, or deployment. Once you build the automation, it locks you into a specific process and it's harder to change. Decide on how you want things to work first by refining the manual process, and then find the automation tools that will support it. For example, I've seen teams adopt electronic Kanban tools, thinking it will make their lives so much easier, only to find them to be a huge time sync providing little or no value over a manual Kanban board.

15) Do Increase Intrinsic Quality To Go Faster
This is my most counter-intuitive advice but it is absolutely true. Most project managers will tell you that in order for the team to go faster, they have to sacrifice quality. In fact, this will have the opposite effect. The lower the intrinsic quality of the code, the harder it is to create new capabilities with it. The higher the intrinsic quality of the code, the easier it is to refactor, extend and embellish.

Final Thoughts
I hope the advice above is useful. They basically boil down to "Do keep your eye on the ball." and "Don't take your eye off the ball." The common mistakes I see people making on their software projects are each well intentioned but cause delays in shaping the overall product, lead to bloated features or create beautifully polished code that never gets used.

There's one more thing we have to do. I just can't leave our hapless game show contestant from my last column in such dire straits. After all, as a software developer I like to solve other people's problems, not create them. So we are going to add to the ending of our tale from last time just a bit:

"You look at the monstrosity you've created and, as the ending buzzer goes off, you realize that you've failed. You've utterly failed. As you drop your head into your hands, ignoring the bits of clay matting down your hair, you suddenly feel an intense heat on your back. Bright flares of light stream through your hands, blinding you. You look up. Through tear-stained eyes, you see the judges smiling at you.

"The judges are so impressed with your expressionistic interpretation of Jimmy the Clown, bringing out his inner sadness and turmoil, his featureless head punctuated only by the nose that brought him both fame and loneliness, that they award you first place. You've won!!!"

This time our story has a happy ending. In the art world, unlike the software world, things don't have to be realistic. So much for fiction. Don't do that in your code!