Friday, April 25, 2008

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.

Tuesday, April 01, 2008

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/.