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.

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.

Tic and Tie

Many years ago I worked routinely with finance people.  Lately, I find myself in their midst yet again.  On my latest engagement, I've been coming across an interesting phrase for which I haven't been able to find a solid etymology.

The phrase as Tick and Tie. Or maybe Tic and Tie? Or ??

There are many people that use this phrase, managers, accountant types, legal eagles, etc.  They all seem to provide their own subtext and implications, but somehow they all seem to understand what it means by unspoken agreement.  When pressed, no solid answers were at hand.

As best I can figure, it relates to checking the numbers or answers, and relating the specific numbers or answers to their supporting information.  When working a proposal, projection, or model, this is a crucial step necessary for validating that all the information can be defended.  During facilitation we call this  the clarify step.  In computer terms we call it a check-sum.

Lacking a good definition, I'm presenting a bogus history.  Tick as in making check marks (ticks) on each entry. And Tie as in connecting each item back to the supporting documentation from which the number is derived.

If you've got the real one, I'd love to hear it.

Pragmatic Project Principles?

My latest project has some interesting challenges.  Firstly, like virtually all interesting projects the deadline is fairly determined.  It happens to be far away, which is good, but fixed nonetheless.  Next, the resources to meet the tasks are unfamiliar with the technologies we are using, they aren't formally trained in software engineering, and have existed in a culture of complacency for the last several years. Okay, so having resources that are barely competent and lazy is different but not insurmountable.  After all, the best solutions I've ever known have been created by lazy people to facilitate their laziness (and yes, I am known for being mayor of lazytown).  Lastly, it is run by formally trained, highly experienced consultants who have been thoroughly brainwashed and bamboozled into plan-driven methodologies (think waterfall approach and the like).

The main challenge with this is that plan-driven approaches revolve, by definition, around a detailed plan of tasks and schedule, hence the name.  Which works well in environments consisting of relatively known behaviors, requirements, and abilities.  For example, a team of consultants all similarly trained on a project with ample time to define and document the requirements in sufficient detail.  That would not be this project.

To embrace the uniqueness of the environment the approach followed must be capable of supporting the differing levels of resources and abilities, the ambiguous nature of the requirements, and a general resistance to behavioral change.  Simply put, when you have people whose performance you can't estimate, working on tasks that are not fully defined, you really won't have much of a plan to manage against.  And any plan you initially create will invariable fall apart under the speed of which changes are encountered. See Sun Tzu for details.

There are various techniques for operating under these types of conditions, after all we're not the first nor will we be the last to find ourselves in such tumultuous waters.  In following posts, I'll discuss some of these approaches which I have found to be especially effective.  They specifically impact the Document and Design phases of the 5-D Approach which I've discussed previously.