Monday, October 25, 2010

I don't know whether you have begun to participate in the trend of communicating through "skits" rather than Keynote or MS-PowerPoint presentations, but I would just like to recommend if you do it, you should dramatize "Jeapordy" with questions relative to your message ("What is ... VELOCITY?"). That is easy to do, and always a winner. If "Jeapordy" is not possible on your budget, then next best is to have a large group of normally dignified people traipse around on stage in herd formation, as is so often done in Gilbert and Sullivan.

I couldn't help but notice this morning that on our small commuter jet from Chicago to Atlanta, there were 50 seats, only six of which were in first class. As I sat in the airport lounge waiting to board, I noticed there were 38 of us waiting to be upgraded. 38! And only one unfilled seat. So eventually, we all tried to board, and that's when I noticed we were all pulling carry-on sized black rolling luggage along with a smaller bag. We each dutifully tagged the bag with a green label and left it at plane-side. We all crowded onto the plane and resented the people in the six first-class seats. After all, virtually the whole plane had been placed on the list! Then we all herded off the plane and waited for our nearly identical black rolling luggage to be delivered back to us.

There was something so lemming-like in this operation, I couldn't help but be charmed.

Thursday, October 14, 2010

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis." As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously). And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques. We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently. We assert that along the way of course we're also delivering value. But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording story value points during iterations. But this is only one piece of a larger puzzle. From a business value point of view, we have five main opportunities to identify business value and tune projects to deliver on it faster, better, and cheaper.

At investment time: "Someone from the business" (let's call her the "product owner") makes the business decision to start the project and ponies up money for it. <== We can optimize project value here by ensuring the project is based on some actual business case whose predictions are quantifiable in some way, and can be measured during and beyond project delivery.

During story creation: At a project's inception, a product backlog or master story list is built, outlining the pieces of business functionality to be written in sentences in the format "as a <>, I need <>, so that <>" <== We can maximize value here by ensuring stories are indeed designed to capture individual pieces of valuable functionality, and that value is captured at analysis time. I'm frightened to report that I've had the business owner of a project create stories like: "as the system, I need a user interface layer, so that I can input and output values to the database." Creating stories which capture end-to-end business value in small pieces is very hard to do in practice.

During story prioritization: The product owner prioritizes the stories (a process which can be repeated before each iteration, as the business climate changes) <== We can and should insist that we have a full product backlog which is being revisited by the business owners of the initiative before every iteration, and we should be keeping tabs on what has actually been delivered, as it is delivered.

While we are delivering the software every two weeks (or continuously)! <== If we were using techniques such as a "value burn-up" as opposed to an "effort burn-up," we could actually see the value accruing over the course of the project. We should do this!

As the business collects returns on the investment: the new software translates into some actual benefit for the business (the business sells the software, or the software improves the business's operation in some key way). <== If long-term statistics on ROI are collected, we could quantify actual delivered value over time.

In our Agile IT writings and trainings, we tend to relegate steps 1, 2, 3, and 5 to specialized "product owner" or "business analysis" functions which require "soft skills." Often we decide to put our training dollars into learning how to do pair programming, automated testing, or continuous release management, and we simply decide to let the business carry on as it always has. I think this is a mistake. At the end of the day, we're not paid to deliver software--we're paid to deliver value. It's not just strategically superior for us to insist on meticulously optimizing and measuring the value our projects deliver--in a tough economy, it's simple self-preservation.

Sunday, October 10, 2010

You will be amazed to learn that Army Field Manual number 6-22 is entitled Army Leadership, Competent, Confident and Agile. If it weren't for the small word, "Army," at the beginning of this title, any aspiring lean/agile leader might eagerly browse through this readily available text for tips and tricks to warm the heart and increase the team velocity. In case there's any suspense, I'm going to suggest that despite the title, you do exactly that.

Of course, in the world of the Army Field Manual, command-and-control, like gravity, isn't a guideline--it's the law. And we in the agile/lean community typically frown on command-and-control right along with "waterfall," "big modeling upfront," and using pens smaller than sharpies. See, for example, this impassioned description from the "Energized Work" blog:

Command and control elicits compliance to enforced processes through management by policy. Focusing on process fixates management on the means rather than the result. Emphasis is placed on building hierarchies, formalising roles, and people are viewed as resources. All this amounts to bureaucracy and adds no value. Hierarchies introduce protracted decision-making. Decisions made up the hierarchy typically don't involve the people who will be tasked with fulfilling the decisions. And consequently, the support from these people for the decisions is absent. These decisions aren't easily reversed. All this nonsense doesn't exactly set the project up for success. I can't think of a better way to demotivate people and reduce productivity.

Interestingly, however, although FM 6-22 is uncompromising in the matter of the leader's authority and concomitant responsibility for the results achieved by her team, it describes a philosophy and practice which would add a lot to any agile work environment. It turns out that although the ideal Army leader works within a command-and-control framework, her leadership style is the opposite of that outlined by the Energized Work blogger. For example:

People versus process: in FM 6-22, leaders (and soldiers) are defined by character, knowledge, and application, or "BE-KNOW-DO" for short: results come first from who you are, second from what you know, and third from what you do. FM 6-22, in fact, is uncompromising about the fact that people are always more important than process: "Respect for the individual is the basis for the rule of law—the very essence of what the Nation stands for. In the Army, respect means treating others as they should be treated. This value reiterates that people are the most precious resource and that one is bound to treat others with dignity and respect." (4-18)

Means versus results: FM 6-22 outlines ten ways for leaders to influence their teams which are better than simply issuing a direct order. "Compliance-focused influence is not particularly effective when a leader’s greatest aim is to create initiative and high esteem within the team." A good leader is a person focused on results, not process, and who knows how best to work with her team to achieve that result (options include "pressure," "legitimate requests," "exchange," "personal appeals," "collaboration," "rational pursuasion," "apprising," "inspiration," "participation," and "relationship building.) (7-3 to 7-17)

Developing the team: agile theory is pretty silent on this matter, and indeed in practice, companies love to hire young people infatuated with software but who won't throw their weight around when it comes to making decisions. FM 6-22 puts "developing the team" front and center as a responsibility of a good leader, and provides an entire chapter on how to choose your team and how to counsel each individual to help her advance.

Certainly, FM 6-22 occupies a world foreign to what most of us experience in the "trenches" of corporate America, where good leadership can literally mean life or death to a large number of people. Certainly I have no knowledge about how the ideals of FM 6-22 are applied on the ground by actual Army leaders. Likely, they are as bad at "command and control" as our own corporate commanders. Certainly we in the agile/lean community embrace an egalitarian philosophy that says the person doing the work knows more about the problems at hand than a Vice President eight levels above her. Certainly we don't want to put as much energy into organizing our hierarchies as the Army has done over the past 200 years--picture what that would do to our deadlines.

But this field manual is a gold mine for suggesting how to be a leader, how to scale leadership techniques, how to motivate, counsel, and talk with other people. I can't do it justice in a blog. Please think about reading it.

About Me

Elena is a Principal Business Architect for ThoughtWorks, London. In this capacity, she focuses on transforming business architecture to better support digitally enabled retail clients. Prior to ThoughtWorks, Elena was a Program Manager and Chief Agilist for the Treasury Services vertical at JPMorgan Chase, followed by projects which measurably improved scalability and productivity in IT processes for the Corporate and Investment Bank (CIB) and the Consumer and Community Bank (CCB). In addition to business architecture, Elena’s areas of professional interest are value chain mapping, change management, and non-annoying IT productivity strategy and measurement tactics.