Why Agility Matters

If you build software or work in systems technology (and have any hope for success at this point) you know there is basically one thing that you can count on...that everything you know today will need to change in order to accommodate new technologies, new user expectations, and shifting environmental constraints.

Since my last post, I have dealt with this reality myself, as our organization is going through a period of exciting, energizing, and dynamic change. Suffice to say, when you are in the middle of REAL change, there is not a great deal of time left at the end of the day to sum it up in a blog!

Not that things have slowed yet, but I have come up for air briefly, and wanted to reconnect, because I find myself in the midst of Architecting Work, not as a theoretical exercise, but as a solid, daily reality, and agility is right at the center.

Anyone who has worked in entrepreneurial tech companies has lived with the reality of agility, as opposed to the theory. If you lived through the dot-com to dot bomb, you were multi-tasking long before that was "cool" and building agile before you had a name for your scrum meetings. After all, in entreprenurial companies, especially those that were running lean, you were doing requirements analysis, architecture, QA, sales and services in the course of your job responsibilities, and communicating to your team consistently so you stayed on track. You are familiar with building value in small cycles and getting them out to the market quickly, because that was how you survived. In that kind of setting, the concept of flexibility and change came early in your work. You knew you did not have the luxury to wait until you had a perfect product to get it in front of customers, you had to get out there fast, improve fast, and compete effectively. While larger companies had the luxury of pondering larger projects, smaller companies had to make up in agility what they could not do with sheer market penetration. But hang on, that is changing. Increasingly, we are seeing a shift in larger companies, who are going to have to change...or...can you spell GM?

Today all companies are facing financial constraints, more streamlined and often significantly smaller staff, increased competition for fewer deals, and customers who know that they are in the power seat. Smart companies know they have to change, but they are probably not sure how...and it is very clear that not everyone will be getting on the bus.

Agility matters, but why?

• Change in technology – it’s not just a theory. Consider Moore’s law alone and you should readily agree it is not merely an idea discussed ComSci classes. All around us we see tangible results of exponentially expanding capacity combined with innovation. Everything can change quickly with innovation shifts. Just consider the implications of interface advances like iPhone and Project Natal. Looking back we will undoubtedly see that the phone and gaming impacts were mere starting points for entirely different technology options altogether. Agility is necessary because we are building today using technology that will be completely different in 2-5 years.

• Change in user expectations – As technology becomes an increasingly ubiquitous part of “normal people’s” lives, and increasingly accessible and familiar to the non-techie, expectations increase. If you work in a client-facing role, you probably think this is expanding at some exponential rate, that runs close to the rate of capacity capability already. In short, once people see that a technology can be more flexible or easier to use, they want that ease of use reflected in their systems. Seriously, if I can go online and click to easily do my banking and email, do you think I will be impressed by a poorly designed interface or complex command structure, even if there is some vaguely amazing technology I can't see running behind the interface? Of course not. To the non-techie, the interface IS reality, that other “stuff” is just impossible to comprehend. Agility becomes essential here, because it is almost impossible for the technologist to accurately predict what the end-users priorities will be, and given they are likely to change, including the client in a review process is essential to ensure that requirements and results match to user expectations. Many of us have had the experience of spending weeks working on complex technical issues, only to hear the end-user say something like, “Well, it is really ugly” when we proudly show them the new baby. End-user expectations are not extraneous to your success, and including them in an agile process is critical.

• Change in requirements – Both of the previous factors have a common result, that is the most powerful reason to move toward agility, they change requirements. Building in agile cycles allows you to adjust quickly to requirements changes.

None of this means that the good things that come from established development approaches should be abandoned. Initial requirements gathering and architecture and design continue to be keys to success, and in fact getting a clear picture at the start of customers' true desires and getting the design based on those priorities can result in increased project agility.

But taking a customer-centric approach doesn’t mean that your requirements are not going to change as you move forward. It is not realistic to expect they will stay completely stable. That said, the better job you do of requirements analysis, architecture and design, the more likely it is that the churn of shifting requirements will be decreased. At the same time, the more agile your process, the less likely changes will force significant and costly changes to your architecture.

You can increase the likelihood that your project will be successful relatively quickly by incorporating the following into your process:

• Include customers and end-users. Don’t make the mistake of only including techies here. One of the most common reasons for missing the mark are unstable requirements that result from a lack of quality user input with respect to business needs.
• Improve your discovery and planning approach. This will help you by increasing the effectiveness of eliciting requirements

1. Find out what the customer’s actual needs are
2. Ask detailed questions
3. If the customer can’t answer you, don’t skip your process, find the answers
4. Model the requirements in a use case and review it with the customer. Ideally, have this be graphical, not just descriptive. Even if you are merely showing mock-ups, walk them through the examples to get confirmation that you are on track. Non-technical users can not necessarily "picture" what you are describing.
   

Why Agile? It's all about change. You must ensure your project approach is built to change.

It will.