Leadership and Agile

This week I had several opportunities to speak with people about Agile.

As I listened to yet another discussion about Agile there were several things about the conversation that just really stuck out to me. It started with one strong idea of which I just couldn't seem to let go:

Agile is great under the umbrella of strong leadership. If the direction, metrics or criteria for success aren't well understood and broadly accepted across the organization, then returns on investment and efficiencies will likely not be realized.

In high-performing companies the gestalt is achieved when the employees are empowered to self-direction and a feeling of ownership. Even in these companies, that sense of empowerment and value is only powerful as the individual choices and decisions can be aligned to the bigger vision of the organization as a whole. When the vision or mandates of the organization aren't clearly articulated or fail to be fully accepted within the ranks, then organizations experience churn and confusion. Without alignment to a bigger mission, the agendas from the various levels of management tend to begin conflicting and drifting as individual interpretations of value and success criteria are formed. This churn due to conflicting expectations makes it easier for issues to hide and for misalignment to go unchecked for increasing periods of time.

Even in cases where misalignment is uncovered, the process needed to achieve consensus can then take longer and without strong leadership won't necessarily drive the business impact needed for growth or even sustainment.

This then is the crux. Leadership is essential for achieving business value. You can use Agile processes to seek business value, but without strong leadership you will find the criteria for success shifting too often and hiding behind the easy process of consensus building.

To bring this back to the Agile conversations, I was feeling frustration with the reactive nature of those who ascribe to the Agile approaches. They espouse this easy-going attitude of reaction in which direction, strategy, and even the definition of business value are left completely to the client. This zen-like state in which the Agile practitioner responds fluidly to the changing and ethereal nature of the client demands is unnatural and impractical. Business value is unlocked by making the hard choices, by understanding the elements of the business value and capability chain better than everyone else and leveraging that unfair advantage.

The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself.
Therefore, all progress depends on the unreasonable man.
-- George Bernard Shaw

Simply put, it is called work because it IS hard. It's painful and requires discipline. If you are choosing to avoid the hard choices you are inevitably giving up the business advantages, wasting opportunities, and releasing accountability. Live in a reactive mode long enough and you remove the incentive to estimate well, to live up to commitments, and to deliver beyond expectations.

As everyone in technology knows, regardless of how long a task should take, it always takes at least as long as the plan said it should. We don't finish early, we just fill up the extra time with more stuff and junk. We test a little more, refine a little more, increase scope if necessary. If you aren't pushing the boundary and requiring unreasonable attainment, then you'll never get it either.

When it comes to Agile, I embrace the incremental nature. I covet the consensus of reactive expectations. I do not respect the reduced commitment to discipline, the minimization of leadership, or the dismissal of accountability afforded a facilitator. As Harry would say, "If you are going to come, come correct." Harry can be very wise.

Free Code

Lately, I've been really paying attention to how much functionality you can reuse for free from major players. For example, you can check out the various Google APIs (http://code.google.com/)and the Yahoo! User Interface Library (http://developer.yahoo.com/yui/). These libraries are free, released via Open Source licenses, and offer ridiculous amounts of functionality.

As a developer, I love the idea of being able to leverage the work of other people. Most of the time, this is hard to do because so much of the code that everyone else writes is crap. ;-) But seriously, there is even a name for this, we call it Not Invented Here (NIH). The premise being most developers like to know exactly what their code is going to do, so using someone else's code can be hard.

In the case of the big boys like Yahoo! and Google, it becomes a lot easier to trust that the code is going to deliver expected results and not be malicious or buggy. After all, when it is provided (and used) by a company with billions of dollars of online reputation to uphold, you can pretty much bet they've tested it.

Which isn't to say that just because they are all that, you don't need your own bag of chips, they have their issues too. Dependency and version issues, occasional bugs, and warped programming models are abundant. But in the end, you are definitely getting your moneys worth.

The chart at the top of this post is generated using the super cool (and free!) Google Chart API which means I won't be paying for Dundas or ChartFX licenses again. You can find the details at http://code.google.com/apis/chart/.

Why Unit Test?

Recently, I had a down and dirty discussion with a team who is gearing up for a new engagement. This team has been doing Scrum for a while but was struggling with how to fold testing more tightly into their development processes.

The heart of the matter ended up being differences in the purpose and perception of Unit Tests specifically. One camp saw the role of Unit Test as "to find bugs". That's it. They tell you where the bugs are. If they are just about finding bugs, they have more value to new developers than established developers. After all, great developers are much less likely to allow the kind of bugs found by Unit Tests in their code. As a great developer I'm going to catch bad parameters and logic flaws before checking in my code. Integration and functional bugs are probably not going to be found in Unit Tests anyway.

The other camp (read: in my opinion) was resolute that Unit Tests fill a much larger purpose. To my eyes, Units Tests go way beyond just finding bugs. Following are four big ways that Unit Tests can add significant value over and above just finding bugs.

Proving Integration
Today's applications are more distributed and componentized than ever. The number of moving parts has just sky-rocketed with the use of frameworks and new API's, the prevalence of SOA and more component-oriented designs. Personally I see goodness here, but regardless if you like this direction or not, it's happening and is relevant to address. With this fragmentation comes a need to understand when the integration between components is complete. Simple Unit Tests can tell you quickly if the work being delegated downstream of a component is completed and ready. As you are bringing on multiple layers of components the pass rates of the Unit Tests at various layers can quickly show you the level of completeness for the entire integrated system.

Sample Code
One of the difficult parts of delivering a complete software product especially when the product is a framework or an API, if the product is extensible or supports programmability. In these cases specifically, Unit Tests can serve as great examples of how to utilize the API or exercise the programming model. They can often be directly consumed as documentation and sample code for SDKs or in knowledge transfers throughout the life of the product. Building this from outside the team without relying on the author of the component is extremely costly and difficult. However the returns are typically the most valuable.

Proving Design
Designing and building components is easy with the current toolsets. The downside of this is that we can create classes and objects so easily that we don't always think about the bigger picture. Taking time to write code that exercises a new component or interface can act as a sanity check to ensure that the component is easy to use and meets the programmability desires. It's quite often that I see a single API that requires two or three different programming or data interaction models. Some quick Unit Tests would have shown the designer how difficult and inconsistent the usage of the API had become.

Change Management
As a great engineer, it might be totally natural for you to write code that has few bugs. Are the engineers who take up your legacy as experienced? Will the engineer who will open the code in six months to add some features or fix an integration issue be as comfortable knowing how to change things without breaking anything? Would you? Being able to run regressions over time adds a wonderful safety net in the identification of the impact of changes upstream, downstream, or inside your code. It doesn't mean you will (or can) catch everything with Unit Tests but it can sure give you a head start and a level of confidence.

So perhaps this is more about semantics or expectation setting, but I think it helps to keep in mind the variety of purposes Unit Testing can serve. When you expand the contributions made by Unit Tests hopefully you will have an incentive to get even your experienced engineers to spend time writing them.

Are You Sure?

It is a pretty normal day for me when a friend says they want to accomplish something and yet they have no idea how to go about it. They want to start a business, but aren't sure what kind of business. They want to make more money, but aren't sure how. They want to get certified/learn new technology/become famous/[insert random goal here]. In all cases, they have an ambiguous idea but not a specific agenda.

A man with a watch knows what time it is. A man with two watches is never sure. -- Segal's Law

In our era of The Paradox of Choice, it is the amazing potential we all have to stand on the shoulders of giants and achieve greatness that is most often our downfall.

We have to choose every day as engineers which technologies to support, which languages to learn, which certifications to pursue. We are bombarded with choices for what social networks to participate in, which email system to rely on, and should we use an Mac or PC? Is it IPhone or Windows Mobile?

As an architect, the most valuable thing you can do is be deliberate in your choices. The hard part is being deliberate quickly. Digesting the massive amounts of ambiguity at a breathtaking pace to synthesize answers and clarity as and when they are needed, usually well before the obvious answers have become apparent. If being an architect was just about picking the obvious when it became obvious, then everyone could do it. (Which probably explains why everyone thinks they can do it.)

If you want to get out there and do something, first narrow down what that something might be. Perhaps start by writing down what it isn't. Then start writing down the attributes or identifying characteristics for what it is. If you can describe what the world looks like when you've achieved your goal, you'll be a good way towards deciding what road will get you there.

Or don't.

It's your choice.

Offshoring for Rank and File

I've been doing offshore work as long as the next guy, if the next guy has been doing it for almost a decade. There are successes and failures and lots of learning along the way. It's hardly the only thing I've done, but it's a good share of the pot.

Recently, I was asked to speak with some gents about how their offshore effort was going. Which is usually code for "We don't think it's going well". And by all accounts from the team, it wasn't going all that well. It helps when everyone at least starts from the level of dissatisfaction.

Whenever we start to talk about the concept of managing work efforts in more than one location, everyone spits out the same mantras. Communicate, be sensitive to cultural differences, etc. The thing is there aren't all that many that have moved past the theory into practical application. I should say demonstrably successful application. A big part of this shortcoming, from my perspective, has been that while we can have concepts in our heads like cultural differences, and detailed communication plans, we miss what can be the subtle point of these guidelines.

Let's borrow from a recent experience at Big Redmond Software Company. Companies (like Microsoft or Google) don't really run tight ships. Not in the way the unfamiliar would think. At the foundation, they expect individuals to be very self-sufficient and to work with minimal communication. Contributors are expected to bridge gaps in their own style. These companies are impactful because they have leveraged the ability to walk down the hall and say "Build this" while pointing to the contents of a Visio diagram or the corner of a whiteboard. The resources are expected to be accountable for the applicability and context of their solutions, not just the code or outputs they produce. The business value driving the work should naturally be taken into account by the self-reliant resources who are tasked with unlocking that capability.

When you start moving that work to different geographies and timezones, suddenly that level of communication isn't enough. The expectation on all parties is to minimize communication since that is a cost both parties share. But how they each tend to approach that goal is often different. Remember that the sender is expecting to point and grunt and have accountability and context magically shift. They'll be available for questions, they expect to review the progress and deliverables and throw stones along the way. But if it takes more than [insert arbitrary threshold here] energy and time commitment, then it just isn't working out. It would have been easier to do it myself in house.

Meanwhile, the receiver of the work has an expectation that the work will be fully-formed, coherent, and that they will not have significant decision-making requirements. Give me enough information up-front to be self-sufficient and yardstick with which to measure success. I'll come back when the output meets the success criteria. My accountability only extends to the output according to the specifications and acceptance criteria. If those have been ill-defined, that is the senders responsibility.

Obviously, I over simplify a little and as always YMMV. But in practice, understanding the different accountability and communication expectations we place on resources on different sides of a pond (or client-facing fence) will help you be more successful at leveraging offshore resources.