The Real-Life Adventures of AgileMan

Debunking Some Start-up & Software Myths

2011-06-12T08:45:00.000-07:00

I saw a great article by Tim Ferriss quoting Rob Mee of Pivotal Labs thanks to someone I follow on Twitter, and thought I should mention it here. It's rare that I read an article on a topic like this and agree with it 100%, but it happened in this case. I encourage you to check out the post itself, but in order to whet your appetite, here are the 7 Myths he describes:

You have to hire "ninjas."
Programmers need to work in quiet, without interruption.
Start-ups run hot, so we're just gonna have to burn everyone out.
Looming deadlines necessitate shortcuts.
Developers should take ownership of their code.
You need a quirky hiring process.
Specialization is essential.

As I say, it's a very good read and excellent food for thought!

Agile 101: A Workshop

2011-04-16T11:34:00.000-07:00

It's been ages since I posted anything here, but now seems like the perfect time to end that drought. Yesterday, I spent the morning and part of the afternoon at a large local company that wanted to get an introduction to Agile. Since one of the people involved with that initiative is a friend and former co-worker of mine, she put out the call to AgileMan and I was more than happy to answer it!

To accommodate the request, I designed a two-part session that lasted 4 hours. There were 22 attendees, along with two colleagues of mine (my wife, Vicki, and another friend). The first half was a presentation called "Agile 101: An Introduction to Agile", in which I did my best to describe what Agile is, and what it isn't. I started off with a very high level definition of Agile (from Wikipedia) in order to provide at least a notion of what it is, and then talked about why we decided to "go Agile" at the work place where I gained the AgileMan moniker.

Next, in order to put some more flesh on the initial definition of Agile, I took the approach of looking at Agile from several different perspectives, specifically trying to capture what people often assume Agile is when they first hear about it:

a response to the historical high failure rate of software projects
a loosely-knit collection of lightweight development approaches
a way of doing iterative programming
a mitigation strategy against ever-changing customer requirements
a commitment to quality and customer satisfaction
the latest buzzword, fad or silver bullet

Taking that path into Agile allowed me to acknowledge what I suspected were some of the impressions already floating around in the minds of the attendees, and it seemed - based on some of the vigourous nods I saw - as if I hit some nails on the head.

I then spent a consider amount of time going through some of the more common principles and practices in the Agile community, such as:

Inspect & Adapt
Empower Teams
Size Relatively
Co-locate teams
Work at a sustainable pace
Don't compromise quality
Automate your testing

and several others. There were lots of questions during this portion, as people began to wrap their heads around just how different an Agile work place is from a traditional one. Most of the questions were asked in an inquisitive, interested manner, but of course there was the odd individual who made it perfectly clear by his wording that he thought this was all rubbish. No surprise there.

I had to go at a brisk pace through the presentation because we had a full-on activity to do after the break, and that unfortunately meant that I couldn't spend as long on some of the questions as I'd have liked. By this point in my career, it's gotten very easy to tell the difference between a back-and-forth that may eventually lead to a resolution and one where the other person has already made up his or her mind on the subject. I tried to keep the former type going while cutting the latter ones off, but I'm sure I did an imperfect job at that in the final analysis.

After a 15-minute break - during which time I was inundated with more questions, which is always a good sign - we began the hands-on portion of the workshop. The 22 attendees were split into 3 groups of about 7 people each, and each group got one of myself, Vicki or our other guest as their Product Owner. All 3 groups were tasked with "building" (on paper only) the Meal Planner application, based on a visionary set of requirements (lacking in specificity, by design). The deliverables for each feature included screen design/diagrams, test conditions and help texts, and the teams were given four 20-minute iterations in which to do as much of it as they could.

Interestingly, all 3 groups started off working in smaller groups - screen UI vs testing vs help - only to realize, by the end of the first iteration, that they hadn't known enough about what their teammates were doing to be able to do an effective job on their stuff! We had short planning sessions to start each iteration, followed by the doing, then a hand-waving "demo" to the Product Owner and a quick Retrospective before beginning the next iteration. This exercise worked extremely well, as it provided everyone with a taste of what Agile is like: short cycles, lots of adaptation, emerging requirements, high degree of collaboration, etc. As far as I could tell, everyone in the room was fully engaged in the activity, and there was a palpably-high level of energy present for those eighty minutes!

After the 4th iteration, each team briefly presented its "application" to the others, along with what they'd learned in their mini-Retros. Then we wrapped things up, at which time several attendees offered quick testimonials about what they'd learned and how much they'd enjoyed themselves, which was very gratifying to me and my two helpers.

As I usually do in workshops, I handed out a very short, 1-page survey to encourage the attendees to provide feedback on the session. I asked them to rate three things:

how effective the presentation portion was at introducing them to Agile
how effective the hands-on activity was at introducing them to Agile
how effective the Product Owner had been in helping them understand Agile

The results were extremely good, as we received average scores of 8.4, 9.1 and 9.2 (all out of 10), respectively! Those are some of the best numbers I've ever gotten on a workshop! There were also a couple of comments along the lines of "Best workshop I've ever attended", which obviously makes me day!

It still remains to be seen whether I'll be asked to do any more Agile consulting for this particular company, but the signs are promising at this point. Several topics were mentioned as potential areas they'd like help with, including estimation skills, breaking large features up to fit into short iterations, Retrospective facilitation and Product Owner-type training or consultation.

All in all, it was a great day and it took me back to my initial two years as AgileMan!

Agile Metrics

2009-11-06T16:33:00.000-08:00

I'm only partway through the video (it's about 2 hrs long) but so far I'm really enjoying and agreeing with what Dave Nicolette had to say about Agile Metrics at Agile 2009. If this is a topic that's of interest to you - especially if you're a Project Manager! - then I recommend you give this video a watch.

Is Agile Just A Placebo?

2009-11-03T18:19:00.000-08:00

A good friend of mine is a big fan of Linda Rising, and so anytime Ms. Rising's name pops up, I tend to take notice. This 15-minute video of her speaking about the Placebo Effect is quite interesting and typical of her style.

The First Retrospective

2009-10-31T17:18:00.000-07:00

Last week I spent Thursday morning facilitating a project Retrospective for a local development group who'd never held a Retro before. As part of my engagement, I was also asked to do some "training the trainers" in the sense of working with a couple of people there who were interested in taking on the facilitation role in the future. The thinking on the part of the executive sponsor was that they wanted to bring an expert in for an early Retrospective (or more) but not be reliant on him forever, which is a sentiment that I totally agree with and was happy to support.

The preparation for the session started several days beforehand, as I e-mailed questions to the sponsor and also had a phone conversation with him. I'd sketched out a possible structure for the Retro prior to that, and then the two of us hammered out the final details during that call. One of the most important factors we talked about was duration, which ultimately ended up being 2.5 hours. I would have loved to have scheduled it for longer since it was covering an entire 6- or 7-month project. However, the flip side of the coin was that this was going to be everyone's first Retro, and there was concern that being subjected to a full-day session first time out would be too much, too soon. That led to the decision for a meeting running from 8:30 to 11:00 a.m.

When I got on-site Thursday morning, I met with the future-facilitators for an hour and described what would be happening. The three of us got the room ready by putting up some large sticky notes (a mostly-blank timeline, ground rules and the agenda) and I provided a few thoughts on what I believe the facilitator's role to entail:

keeping the group focused on events and learning, not on people and blaming
warming up 'cold' rooms and cooling down 'hot' ones
nipping any personal attacks in the bud
avoiding ruts in the proceedings by keeping things moving forward
making each of the attendees feel comfortable with the process itself

I'd planned a warm-up activity that went well (got people talking, generated some light-hearted laughter, felt like fun) and then we drove headfirst into the agenda.

Most of the attendees were slow to open up very much, as you'd expect from people in their first Retrospective. Nothing too contentious came out until more than halfway through, and even then it was offered up fairly tentatively. By the 2.5-hour mark, though, things were getting much more interesting... just as time was up! As one of the trainee facilitators pointed out, it was all we could do to get several of the attendees out of the room even half an hour after it was over! And these were very busy folks, some of whom were missing other commitments in order to stay a little later and chat with us about what they`d just gone through. That sort of thing is really rewarding to see!

The results of the 1-page survey that I handed out at the end were very positive (scores averaged between 8.2 and 9.0 out of 10). In our 1-hour debrief after the session (half of which was chewed up by the hanger-on-ers!), the two trainees did a great job cleaning up the room (while I was waylaid with questions) and then talked about how interesting it had been for them. They were concerned about being able to do what I had done, but I assured them it was easier than it looked! In fact, the toughest part for me was that I was on my feet for nearly the entire two and a half hours, an amount of standing well beyond anything that I've done in the past several months. I'd had the presence of mind to bring a big bottle of water with me so I wouldn't get parched, and yet I didn't think to sit down for more than about 2 minutes over the course of the meeting!

I don't know yet whether or not I'll be invited back for additional work, but this first contract was very enjoyable, indeed. The participants were committed to the process and willing to open up in front of each other and a stranger, and you can't ask much more than that!

This Looks Like A Job For... AgileMan!

2009-10-26T13:08:00.000-07:00

Later this week I'm scheduled to facilitate a Retrospective for a local development group. This will be their first ever Retro, and so they've decided to bring in an outside expert to lead it. I haven't done one in a while, but back in the heyday of my AgileMan stint I was facilitating about one per week. Of course, that was with people who I knew (to some degree or another) and this is with strangers... but I'm hoping it's like riding a bicycle, regardless of who makes the tires!

So in preparing for this engagement, I've been working with the executive sponsor to sort out the logistics for the event (what type of room, duration, number and makeup of attendees, etc) as well as to determine what kind of format might work best. Because it's a Retrospective for a recently-completed project that ran for nearly half a year, we're going to do a Timeline as our main source for gathering data. In an ideal world, a session covering this long a period of time would probably be a full day in length. However, since these folks have never been in one before, we opted for a shorter format (2.5 hours). Because of that, I want to get as much data out on the table as quickly as possible, and a Timeline seemed a good vehicle for that.

Once we've completed that activity and found a few hot spots (via a voting mechanism), then the plan is to use the Force Field Analysis process to uncover what forces have worked for and against whatever it is that we're discussing. From that I hope to be able to lead the team in agreeing on a few Action Items that can be applied on the next project to either weaken some of the opposing forces or strengthen the supporting ones.

It's not the most elaborate agenda I've ever set out for a Retrospective, but I'm trying to remain mindful of the fact that this is something new for this group. I don't want to run the risk of overdoing it on the first step of the journey, and these activities seem appropriate for striking a balance between sophistication and simplification. Of course I won't really know how well I did until I hand out my 1-page Feedback Survey at the end of the session, and then review the results. That's always been my best metric for these jobs, and I've learned a lot from what people given me on them.

And naturally, if you're looking for help with a Retrospective yourself, or any other sort of assistance with an Agile topic, don't hesitate to contact me (AgileMan@sympatico.ca). I'm always on the lookout for jobs for ol' AgileMan (superhero at large)!

Good Reads On Pair Programming

2009-09-29T12:26:00.000-07:00

Just a quick link to this blog entry from someone who feels very passionately about the benefits of pair programming but doesn't believe that most software organizations could pull it off. He even provides 10 reasons why.

And then for the opposite view, see this, a much shorter article that argues, in rebuttal of the first, that pair programming could be for everyone.

Getting The Requirements Right

2009-09-10T07:19:00.000-07:00

Apparently this amusing blog post was recently making the rounds at my old workplace. In it, the author imagines what designing a new house would be like if architects had to deal with the same sort of loosey-goosey requirements that software developers typically do. One of my favourite lines is "With careful engineering, I believe that you can design this [75-foot swimming pool] into our new house without impacting the final cost." As programmers, we're well familiar with the "keep the design open-ended so that all possible future requests can be done quickly and cheaply" model of thinking.

My wife Vicki is currently finishing up a contract position as a Business Analyst. While the exact particulars of that role differ from place to place, in this case it means that she splits her time between the product folks and the development team. In effect, she's the liaison between the two groups, responsible for taking "business-speak" and translating it into requirements that can be implemented by software types. It's a challenging tightrope act to pull off, because if she drifts too far in either direction she runs the risk of ostracizing the other group and thereby losing their trust and confidence. In her current environment, all of this is done in a fairly traditional (Waterfall) manner, meaning that she's spending inordinate amounts of time getting down - in writing - what the two areas of the company have agreed upon, long before the first line of code is written. And for many years, that was considered to be the optimal way to perform the requirements gathering portion of software projects.

The pitfalls to that approach are well known to anyone familiar with Agile:

developers tend to focus on fulfilling the stated requirements rather than looking for ways to provide maximum value
the product owners don't get any opportunities to try out what they've asked for before it's locked down, thereby missing the chance to make it better
all features get started more or less at once, and any deliverables that end up being abandoned late in the project (when things inevitably run long) have usually had considerable work done on them, all of which was wasted effort that extended the project timeline unnecessarily
there are all kinds of openings for aspects of the requirements to be "lost in translation" between the Product Manager and Business Analyst, or between the B.A. and the Programmers
the development team is often kept at arm's length from the product team, reinforcing the "us vs them" mentality and denying both groups the opportunity to put their heads together and design something better than whatever each could come up with on their own

and so on.

When you consider all of the obstacles standing in the way of success in a scenario like this, it's sometimes mind-boggling that any traditional software projects ever succeed (about 1/4 to 1/3 do, last I checked). All you need is a Product Manager like the one being parodied in the link above, or a Business Analyst who's weak in business-speak or requirements-speak (or both), or a Developer who isn't all that good at adhering to a written specification, and you end up with a delivery of functionality that isn't going to make anyone happy... assuming it ever emerges out of the Quality Assurance phase at all, after dozens or hundreds of last minute changes have been made to it once people actually got their hands on it outside the development team.

While an iterative approach might not work all that well when designing and building a home, it has a lot of advantages when it comes to software. For example, it's a rare product person who wouldn't relish the opportunity to touch and feel a new set of features early enough in the proceedings to allow for alterations. The trick, of course, is to get such a person's head around the notion that you'll be delivering their requirements in bits and pieces (in priority order, assuming that you can get them to sit down and actually prioritize their wish list!). Some people in that role have become so accustomed to an "all or nothing" setup that showing them one subset of finished functionality incorrectly conveys the impression that it's all done! I've also heard product representatives claim that they didn't have time to review features as they came out, which of course raises the question: what in your job description could possibly be more important than ensuring that the best possible features show up in your product(s)? That kind of thinking just seems nutty to me, but I'm sure they must have their reasons.

For the last big programming job I had, I was lucky enough to have the perfect business person. The project was the creation of our Meal Planner Application, which I wrote in our basement over the 2004 Christmas holidays. And Vicki was my "customer." She had a good idea what she wanted by way of functionality, and I just kept showing her what I thought she'd asked for, until we got it right. If she'd been forced to write out in full what she imagined she'd need, before I ever started coding, I doubt that we'd ever have gotten that thing off the ground. But instead we did it iteratively (long before I'd ever heard of Agile) and ended up with a product that's still being used today, almost 5 years later. It's really too bad more organizations can't see the value in working that way.

What Motivates Creative Thinking?

2009-08-27T13:27:00.001-07:00

A friend and former co-worker of mine pointed me in the direction of this video of Dan Pink speaking at this year's TED (Technology, Entertainment, Design) Talks, in which Mr Pink (not to be confused with the character from Reservoir Dogs!) provides some evidence-based thoughts on motivating creative thinking. I encourage everyone to go check it out.

After watching it, I started thinking about my own experiences in the software industry. Pink's Autonomy-Mastery-Purpose summation certainly matches what I've seen in the best of scenarios. And, of course, those three characteristics mesh perfectly with the principles of self-organization, continuous learning and prioritized backlog that Agile are built upon.

From what I've seen, it's definitely no easy feat to create and sustain a culture in which all three of them are:

valued in word,
valued in deed,
committed to at all levels of the organization, and
not sacrificed in the name of "expedience" or "meeting a schedule".

Some simple examples of where I've seen them compromised would be in management clawing back control from teams whenever they're unhappy with the outcomes, pressure being applied to produce substandard work rather than allowing a maintainable design to be implemented, and failures to provide a consistent vision or message for a project or product. Those are all leadership shortcomings, but you can also see it at the developer and tester level when individuals on teams refuse to take responsibility for their mistakes (the "downside" of autonomy), become lazy about following through with Retrospectives, communities of practice or just general inspection-and-adaptation, or give up on their principles at the first sign of resistance. Like I say: it's much easier to fail at autonomy, mastery and purpose than it is to succeed.

I don't believe that those who fall down in the attempt, however, realize just how much they're losing by not trying harder. For one thing, you only get so many chances to introduce that kind of culture, after which you lose your credibility for a long time to come. Even when we were introducing Agile to our company in 2006, I met considerable resistance from folks who'd been there long enough to remember previous attempts at reorganization and empowerment, and were thus doubly skeptical of the results. There's also the flawed "we can't afford the schedule hit" aspect to failure in this area. One executive I came into contact with was always saying, "We'd love to build that kind of culture but there just isn't the time." Ironically, of course, whatever deadline was being worked feverishly toward would be missed (and missed and missed) anyway because of all the problems being ignored, meaning that the much-needed improvements were put off for no reason in the end. It becomes a vicious circle that's awfully hard to break out of.

The most creative work I've seen has always come from those who are given the latitude to wander down many paths, the tools and training that they themselves believe they need, and a general - rather than specific - direction to follow (so, "what", but not "how"). In some companies, I suppose, that sort of revolutionary work may not even be necessary or desired. But for the rest of the IT world, leaders do themselves and their organization a terrible disservice whenever they believe, as Dan Pink illustrates so capably, that they can simply dangle a reward in front of their heavily-supervised employees' eyes at random points in time and achieve greatness. When you do that, you end up with the most unimaginative of solutions, like a candle stuck to a wall with pushpins, dripping wax down onto your table.

The Relationship Between Trust And Leadership

2009-08-12T09:00:00.001-07:00

An article I was reading this morning got me thinking about how the quality of leadership within an organization relates to the level of trust that you'll find there. I'm not sure that it's a perfect model that I've come up with, but it seems to fit most of the scenarios that I've observed in my travels.

Basically, the relationship seems to be quite simple: the better the leadership, the more trust exists. This is one of those situations where you can perceive the effect (trusting and trustworthy players vs distrust between parties) in direct proportion to the causal factor (effective vs dysfunctional leadership), but it also can work in the opposite direction at times. I dedicated an entire chapter to this in my second AgileMan book (Issue # 46: Who Do You Trust?) but I think that I was still too close to the proceedings at that point to really see just how tightly tied together the two things were.

For example, a leader may start off willing to extend a great deal of trust out to his or her employees, only to feel "betrayed" by them if the same good faith isn't extended back. Imagine a team promising to complete some vital feature, giving "thumbs up" reports on it throughout the Iteration, and then falling well short of the goal in the end. That kind of result can cause a well-intentioned leader to change gears and begin compromising principles: becoming more of a micromanager, reducing the amount of freedom allowed to the team, or just generally dictating more of "how" on future work. In one way, I suppose, we could still characterize that unhappy outcome as being the result of poor leadership. After all, in an Agile environment at least, we expect leadership to emerge within teams, as well. So in my sample scenario, the team that "green-shifted" their situation right up until the end failed to demonstrate the type of maturity, honesty and transparency that we'd expect from a well-performing Agile group.

Just as likely, though, it's the manager or executive who failed to fulfill his or her responsibilities that leads to the breakdown. I certainly saw numerous instances of that in my role as Agile Manager, and in each case the result was a weakening of the bonds of trust between the organizational layers of the corporate pyramid. If a Product Manager promises to be available but isn't; if an executive fails to provide a vision of where the company is going; if team members are blamed for dropped balls that were actually someone else's responsibility... each of these qualities of poor leadership eat away at the foundation of trust within the organization. And that's not just a bad thing on paper, either.

Among the many ways in which a lack of trust hurts an organization, I saw:

time wasted as people (in both groups) sat around and bitched about how they couldn't trust the other group any longer
wasteful defensive measures planned out and enacted as ways to guard against the possibility of being let down or thrown under the bus by the other group
the baggage of past betrayals brought up, again and again, in almost every new interaction, making it nearly impossible to ever achieve a fresh start
a complete reversal of the empowerment model that Agile depends on, as more and more of the conversations would devolve into "contract negotiation" as each side would want detailed recordings of exactly what was discussed in order to fend off future allegations of failure
a very unhealthy "us vs them" attitude that benefited no one and drove morale to continually lower levels everywhere

I suspect that superior leadership can overcome many of these threats, but it's definitely not easy. Each time I was a Feature Lead, for example, I felt the unmistakable pull of distrust exerted between me and my new team. They weren't sure that I wasn't there to take over and remove their decision-making powers, and I was never quite confident (at first, anyway) that they would do what it takes to get the job done. I'm pretty sure that's a typical place to start, and it's no wonder that so many people in leadership roles find it impossible to resist that gravitational force that's urging them back to familiar, top-down approaches.

What that tells us, of course, is that choosing your leaders in an Agile environment is all the more important, and not something that should necessarily be done by the same old rules of the past. If you make that mistake, chances are you'll be dealing with trust issues for years to come.

Why Transparency Matters

2009-07-22T07:27:00.000-07:00

Sometimes it astounds me just how much transparency exists in the world today, and how much benefit we derive from it. In some cases, it's the incredible access to information that we have, mostly thanks to the Internet, while in others, it's simply how willing people are to share what they're doing.

As examples of the former, I started making a mental this morning of some of the data that's now almost literally "at my fingertips" that would have, even a decade or so ago, been at least a phone call or trip somewhere away:

animated radar images of the current precipitation patterns in my locale, so that I can plan my biking forays accordingly
real-time, up-to-the-minute sports scores, including details like who's pitching, who assisted on what goals, and how many shots have been taken
specifications for devices like pool heaters and DVD players that you may have long since lost the paper copies of
forms, as well as forums, related to topics like Canadian Income Tax, immigration policy and travel destinations, just to name a few
dictionary and encyclopedia content enabling anyone to write a factual, typo-free essay (or blog post) without having to even get up out of their chair
transit system schedules so that you know exactly when to be where to catch what (bus/train/plane)
and thousands and thousands more

Similarly, we're able to get much greater insight into, say, the creative process behind a television show, movie or comic book than we ever could in the past, thanks to creative folks who "put it all out there" for the world to see. Not that long ago, much of that would have been closely-guarded secrets, or simply considered too pedestrian to warrant the time to write it down and the cost to publish it. Now, however, it's just a few clicks away.

So what does any of this have to do with Agile, or software development in general? Well, I think that we're realizing many of the benefits of transparency in the 21st century (as touched on above), but that doesn't necessarily always get applied to how we run our development projects. In an Agile culture, we strive for transparency in some very big ways - Burndown Charts, strictly-prioritized Product Backlogs, Retrospectives - all of which are important and positive. If you compare that to a more traditional (Waterfall-style) software project, though, you can see that the same degree of transparency is seldom achieved there. Team members may seek to hide some of what they're doing out of fear that the work won't be approved if the bosses find out about it. Project coordinators may talk about, or even hope for some sort of post-mortem to be held after the product finally ships, but rarely do those mythical meetings actually happen. Status reports all too often end up being "green-shifted" by those responsible for providing the data, in order to keep the alarm bells from sounding early on. These are all instances where the lack of transparency hurts the success of the project.

Even in an Agile environment, however, there can still sometimes be a resistance to openness. I certainly encountered many situations in my two years as Agile Manager that spoke to this point. Whether it be shutting down conversations or blogs that are bringing to light unsavoury failings among management, or a reluctance to share with others the challenges that are being encountered (because it might be used against you later), it's no easy task to adopt a culture of transparency. Politics can get in the way, as can pride, fear and an exaggerated sense of self-preservation. None of those are trivial obstacles to overcome.

Unfortunately, in virtually every case this tendency toward hiding facts ends up doing more harm than good. Decisions end up being made based on faulty data, morale problems develop thanks to a cloak of secrecy that seems to always inspire conspiracy theories much worse than the reality of the situation, and people waste time going through hoops trying to find "the person with the answer." When I think about how efficiently I can use my time today, thanks to the wealth of information available to me, compared to what life was like when I first started working... it's like night and day. And that's because, given quick access to the necessary data, it's always easier to make a reasonable, informed decision. That perspective sometimes gets lost in the heat of the office battles, though. Those of us in the Information Technology industry need to remember that, as we go about our day-to-day business of cranking out top-notch software products, information is king. And the king belongs to everyone.

So if you're reading this from your desk at work right now, ask yourself: what bit of data are you holding on to right now, that would better serve the company if it were shared? Don't betray any confidences (personal or professional), but rather look for something that you've simply been lax in getting out there, or that you know would help someone else if you made the effort to tell them about it. Sometimes that's all it takes.

Learning May Actually Help Keep Us Young

2009-07-14T16:46:00.000-07:00

I'm reading a book called The Brain That Changes Itself, by Norman Doidge, M.D. In it, the author describes many different examples of the human brain's neuroplasticity, which is to say: its ability to change itself based on various stimuli. For decades, the belief was that each part of the brain had a certain, unchangeable function to perform. This implied that an injury to any part of the brain meant the loss of that type of functionality, forever. More recently, though, neurologists have begun to uncover many examples where the organ inside our skulls is actually much more adaptive than that rigid model would allow for.

One of the topics that Dr Doidge covers which certainly applies to Agile is the importance of continuing to learn, even after completing the scholastic period of our lives. In studies that have been done with those in their sixties and beyond, there's clear evidence that elderly individuals who seek out ways to engage their mind - such as by learning a new language or dance, taking on a new hobby or even just visiting locales that they've not been to before - are less likely to suffer from dementia and other symptoms typically related to "the aging of the brain." New neuro-connections continue to form as we get older, but only if we exercise our mental facilities during that latter stage of life. As Dr Doidge points out, it's still possible that it may be a correlation rather than causation relationship, or even causal but in the other direction. In other words, those who are actively keeping their minds fine-tuned may only be able to do so exactly because they aren't losing their edge (rather than the activities being responsible for the sharp minds). But research is making that seem less and less likely, and so I'm inclined to believe that there is more of a positive cause and effect relationship at work in those scenarios, and certainly the rest of the book is a tour of amazing brain-alterations that have been observed by researchers.

So if we accept - optimistically, perhaps! - that learning really does help to fight off some of the effects of aging (such as senility and dementia), then how do we adopt a way of life that promotes learning? In my capacity as Agile Manager between 2006 and 2008, I encountered a lot of individuals who truly epitomized the answer to that question. For them, the focus was always on discovering new ways to make their product better. Often, the people around them (especially in management) were fixated on "hitting a date", which often translated to "cutting corners." The friction caused by the intersection of those two very different approaches was probably healthy, in the final analysis, although it rarely felt that way at the time.

In life, though, we're less likely to constantly run into schedule pressures in quite the same way as we do in our vocation as software craftspeople. Granted, there may never seem to be enough time in the day, but we still get to decide - within reasonable bounds, set by family obligations - just how to spend our spare time. Do we "veg out" and turn our brain off every chance we get, or do we look for ways to stimulate our mind and imagination? Are we always satisfied with the way things are, or do we look for paths to improvement? Have we locked ourselves into a comfortable pattern, or are we still growing in ways not related to our waistlines?

I obviously have a lot more free time now than I did just a year ago. Even so, I've made a conscious effort to spend significant portions of it reading, writing and generally trying to bring my overall understanding of the world around me to a higher level. I'm also finding that my "second career" as a Math tutor is requiring no end of learning on my part (how's that for irony?) as I discover that every child really is different, and therefore no one approach works for every situation.

Will any of that do any good? Am I still destined to end up senile (or, as AgileBoy would put it, "more senile")? I don't have any answers, but I think it's important that we all all keep asking questions.

How Can Productivity Really Be Increased?

2009-07-02T07:06:00.001-07:00

As our current Recession continues to wreak havoc across the employment ranks, one topic that we'll all surely hear more of is "increasing productivity." It's the conjoined twin of "reducing costs," after all, which has already proven to be a popular refrain since last Fall. Once a company gets to the point where it doesn't believe that it can effectively reduce the workforce any further, the next logical step is to look for ways to get more out of whatever employee base remains. I suspect that that's already happening; if it isn't, then it probably soon will be. (This, too, shall pass... but maybe not anytime soon.)

I want to say right off the top: increasing productivity by making people work longer hours isn't the answer. It may work in the very short term, but it certainly doesn't over the long haul. All kinds of studies have proven this, to the point where I'm not even going to bother citing them here (this stance against sustained overtime should be accepted by now, I hope).

So how do people become more productive? Since this is an Agile blog, I'm talking here about the so-called "knowledge worker" industry, rather than something more manual-based, where productivity improvements often take the form of automation. It's much harder to replace a Computer Programmer, Project Manager or Business Analyst with a machine or a piece of software, so just how are productivity boons realized?

The answer that was already floating around when I first hit the industry back in the mid-80s was, "Work smarter." Now, it was also the case that not too many people had any notion of specific ways in which to accomplish that, but it was still a worthwhile goal. What I learned, over time, was that working smarter required a certain amount of reflection and adaptation, both of which fit quite nicely with the principles of Agile. Specifically, you could increase productivity if you were willing to root out, and then call out, parts of your process that were inefficient. The Toyota Lean Manufacturing approach essentially crystalized this mindset and represents the most pure application of it that I've yet encountered. It's one of those things that's easier said than done, though, and it requires a superior style of leadership that's quite frankly lacking in most organizations.

But even if you work in an environment that's not based around Lean, I think that you can still apply some of the same principles. Some of your success will be limited by how much empowerment exists, since making change in an empowerment vacuum is, if not impossible, at least ridiculously difficult. Therefore assessing the latitude with which you can effect change is probably the first step to take.

Assuming that you really do want to become more productive and you have at least some wiggle room within which to operate, then the next thing to do is look for obvious inefficiencies in your current processes. In Lean, I believe these are referred to as "waste." One way to spot these opportunities involves doing some sort of workflow analysis, paying particular attention to items that either introduce delays, or which seem to have limited value. There's more to it than that, but generally speaking you're taking a critical look at "how stuff gets done" and trying to identify those areas where the effort required isn't exceeded by the reward delivered.

As an example, imagine a process in which one step requires a meeting between representatives of several different departments, during which the various attendees provide feedback, and ultimately approval, on Business Requirements. It might be the case that setting up such a meeting often introduces a delay of up to several weeks, due to the lack of availability of the players. Therefore, you might actually be able to shave a project's timeline considerably if you could find a way to gather that same feedback and approval without requiring everyone to physically attend a meeting. Perhaps it could be done electronically, or in two or more smaller groups... regardless, the goal would be to see if it was possible to accomplish the same outcome without incurring the large elapsed-time cost.

In my capacity as Agile Manager, I saw something like this done with Code Reviews. The acquisition of a product called Code Collaborator enabled two improvements to occur: first, a dramatic increase in the amount of peer reviewing of code changes (thus, improving quality of the delivered product); and second, allowing developers and testers to review code at their desks, during breaks between other activities. The win-win nature of this change, whereby both the product's quality and the impact on the schedule were positively affected, made it an outstanding success story.

One of the biggest challenges to making changes toward improved productivity, of course, is that it involves change. As anyone who's ever moved to Agile knows all too well, change is hard. Some people resist it, and many of those individuals are quite adept at throwing up obstacles to any change that they feel threatened by. The introduction of Automated Tests, for example, may represent a huge peril to anyone who's built a career around manual testing. The trick, of course, is in helping those people see what sorts of operations Automated Testing is appropriate for, as well as re-purposing the human brains that used to do that work to something that can't be automated. It's not easy, but it can be done... and the end result is improved productivity.

Other types of change that may meet resistance involve switching up how others do their job. Even something as seemingly trivial as moving from a big meeting room setting to doing something electronically may cause some folks to recoil in disgust. They may actually like attending meetings, for one thing. But beyond that, they may have legitimate concerns about how effectively a set of requirements can be reviewed without the back-and-forth discussions that they're used to in those meeting rooms. How you handle those objections will go a long way toward determining how far you get toward your goal of productivity increases. As someone well acquainted with "inspect and adapt" these days, I recommend that you set up any alteration as an experiment, and then monitor the results so that everyone can see whether it's working out or not.

I think a basic question to be prepared to ask at every step is, "What value are we getting from this part of the process?" That can be an unpopular query to pose, especially when you get to the part where, for example, Bob's entire raison d'etre is called into question. You can bet your bottom dollar that Bob will have a handful of justifications at the ready for why filling out that form in triplicate (two of which get shredded) is a key component to the checks and balances of the entire company. Being able to handle situations like that require more tact than I could ever advise on, so don't be afraid to seek out your best diplomat in management if you find yourself down that path.

The bottom line, I guess, is that you can make productivity gains, if you put your mind to it. It just requires an analytical approach and a willingness to change. One of the alternatives, of course, is that all of your jobs get outsourced to a country where the knowledge industry works at less than half your rate... and nobody wants that, I'm sure!

The Software Development Cycle

2009-06-17T13:53:00.001-07:00

With my recent contract now complete, I thought I'd post a few non-specific details about what I did during it. While it's not completely germane to Agile, you'll see a few places where there was some overlap, at least.

There were basically three parts to complete as part of the contract:

review the organization's current software development process
compare that picture to what a more standard development process would look like
provide recommendations on changes or enhancements that could be implemented to make things even better

Initially there had been some thought of doing a fourth part, as well: implement some of the recommendations, alongside the development team. However, virtually none of that came to be, through a combination of factors the most relevant of which was that the developers were in the middle of a high priority project that couldn't be delayed at the moment.

In order to get a clear idea of how development happened in this company, I read over a fair number of documents that related either to standards, or to recent projects, within the organization. From that exercise, along with a few strategically-timed interviews with personnel there, I was able to figure out what type of artifacts were produced, as well as which practices were followed. I'd describe what I saw as a fairly lightweight model, which is what I'd expected to find, given the age (fairly young), size (6 to 8 developers) and position within the company (an Information Technology group within an industry that's far removed from being an IT provider). In some areas, it was really only rigour that was missing; in others, there was simply a lack of experience with "best practices for large-scale software development", let's say. And that's the sort of thing you bring a consultant in for, anyway.

For the comparison aspect, my boss suggested a Gap Analysis in the form of a spreadsheet, which I thought was quite appropriate. The U.S. arm of the company had previously brought in-house a very comprehensive System Development Life Cycle model for the American IT groups (which are considerably larger than the Canadian one located here), and I was happy to use that as my baseline for the comparison. This model was very thorough (and very gated, as befits a Waterfall approach) and so it provided an excellent "ideal" for me to measure their setup against. There were roughly 150 artifacts or activities included in it, and so I was able to evaluate my clients' methodology in terms of which of those items they included, and (in a few cases, at least) how their versions measured up to the baseline.

Once the Gap Analysis was complete, I identified what I believed to be the highest priority gaps. This ended up being just over 20 items. For each, I then wrote up a Recommendation, in the following format:

Recommendation: xxx
Benefits: xxx
Approach: xxx
Effectiveness Metrics: xxx

In other words, I provided the what, the why, the how, and some notion of how to measure the results to make sure that they weren't wasting their time making the change.

That Gap Analysis spreadsheet, which included the 20-some Recommendations, was the primary deliverable from my contract. However, in talks with my boss we decided that a couple other concrete artifacts would be desirable to come out of this, as well. The first was a Microsoft Project Plan that was essentially a skeleton Plan that included all of the steps from the "ideal" SDLC model, customized somewhat to their environment, in order to make it easier for all of the steps to be remembered in the future. Also, because I considered a thorough and comprehensive Release Plan to be a prime example of where some additional rigour would help them out, I provided a template for that, too.

Those three documents were reviewed with most of the development staff on my last day there, and were extremely well-received. I had tried to incorporate as much feedback from the staff as I could in the content of my deliverables, and I think they appreciated that. One example was the inclusion of a recommendation that features be planned in a way that allowed them to be completed more serially than they had in the past, so as to allow at least some testing of some of the features before being passed on to the business area (who, in that environment, act as "QA"). That, and some of my unit testing suggestions, definitely benefited from my two years as Agile Manager!

All in all, it was a good learning opportunity for me, and I think that the clients received good value from my 22 years of IT experience. I think that if the timing had been different, such that the people there who needed to play a bigger part had had more time available, then it could have gone better and more immediate gains might have been realized. But as the poker enthusiasts say: you have to play the hand you're dealt, and that's what I did.

Separating The How From The What

2009-06-07T09:33:00.000-07:00

Poor AgileBoy!

One of the most common forms of "oppression" that I used to hear about in my role as Agile Manager involved Product people (or other representatives of management) going well beyond their mandate of providing "the "what" as they ventured into the thorny territory of "the how". I doubt that it was ever intended maliciously, no matter how much conspiratorial spice was attributed to it by the development team members... but if that's true, then why did it happen?

First, though, I suppose I should explain what I'm talking about. In most Agile methodologies, there's a principle that says that the Product Owner indicates what the team should work on - in the form of a prioritized Product Backlog - and the team itself figures out how best to deliver it. Thus, "the what" is the province of Product and "the how" is up to the team. It seems like a pretty sensible, straightforward arrangement, and yet it often goes off the rails. Why?

One cause for a blurring between the two can be Product people with technical backgrounds. We certainly had that in spades with our (aptly named) Technical Product Owners, most of whom were former "star coders" who had moved up through the programming ranks into management earlier in their careers. I'm sure it must have been very difficult for some of them to limit themselves to "the what" when they no doubt had all kinds of ideas - good or bad - about what form "the how" should take. In the most extreme cases, I suspect that there were times when our TPOs actually did have better ideas on how to implement certain features than the more junior team members did... but dictating "the how" still wasn't their job. In that sort of setup (where the Product area is made up of technical gurus), what would have been preferable would have been an arrangement where those TPOs could have coached the team members on design principles and architectural considerations in general, as part of the technical aspect of their title. That healthier response would have still accomplished what I assume was their goal - leading the team to better software choices - without overstepping their bounds and causing a schism between product and development.

Another factor that can result in people not responsible for "the how" trying to exert their influence on those who are, is a simple lack of trust. Again, I saw this in action many times as the Agile Manager. I'm not going to paint a black and white picture and pretend that it was always warranted, nor that it was never warranted. But the important point here is that dictating "the how" downward in that manner usually did more harm than good, and it certainly did nothing to close the trust gap. For one thing, having "the how" taken out of their hands gave those developers who were already skeptical about management's support of Agile more ammunition with which to say, "See? It's all just lip service! We're not really being empowered here!" It was also true, in some cases at least, that "the how" being supplied wasn't particularly well suited to the new development environment that was emerging. What with all of its automated tests, refactoring and focus on peer reviews, the code was resembling what "the old guard" remembered less and less with each passing Iteration. I experienced this first hand, as I'd make some small suggestion about how to tackle something that I thought might be helpful, only to get a condescending look and "Uh, it actually doesn't work like that anymore" from someone half my age. Yeah, that's tough on the ego, but it's also completely the right response.

As for why the trust gap was there in the first place, well... as both of my AgileMan books lay out in gory detail, lots of mistakes and missteps were being made. It wasn't exactly smooth sailing, let's say. The result of that, however, was that some among management apparently felt that the teams couldn't be trusted, and so they attempted to exert more and more control over them, in whatever ways they could. Had they simply applied that energy to improving the requirements gathering techniques being used within our organization, though, it would've benefited us more. Providing clear sets of Acceptance Criteria and good, well thought out constraints would certainly have done more to improve the product features that our teams were developing than any amount of "meddling" in the mechanics of the software development process itself ever did.

I imagine that it's often difficult to keep "the how" separated from "the what" as you work in an Agile environment, but it's critical that you do. After all, the people doing the work are in the best position to know how to do it, and that principle has helped make Toyota one of the premiere auto manufacturers in the world. We could do a lot worse than to follow their example in the Information Technology business!

Agile Is In My Blood

2009-05-23T08:22:00.001-07:00

It's striking to me how different my perspective is these days, as a result of my time as the Agile Manager at my previous job. I'm currently working in an environment that's not in the least Agile, and yet I still seem to perceive what's going on around me with Agile-Vision, as it were.

For example, I've spotted an instance where the separation between the business people and the development team has caused some issues, and so it seems fairly clear to me that that gap needs to be bridged somehow. It seems to me that there are lots of options available to be considered, even outside of an Agile methodology.

I can also see where delivering what's promising to be a fairly large feature set for the current project in smaller chunks will almost certainly help, even if the "delivery" here simply means working on the features in such a way as to allow the business folks to play around with them as they "come off the line". This won't be the Agile practice of working within short Iterations and having each small group of features "done done done", but at least it'll open up the possibility of getting feedback on many of the pieces before the development cycle is complete.

And finally, I've begun tossing around the idea of using something akin to a Retrospective for areas where the general consensus is that not enough is being learned or improved upon. That may apply to relationships between groups, or to preventing the same mistakes made in Phase N of the project from being repeated in Phase N+1. When I described what a Retrospective was to a few people, they seemed to like the idea ("like a Post Mortem, but focused on improving and learning instead of blaming and arguing"). So we'll see how that flies.

It's certainly odd to be back in a work environment that's so strangely different from what I was used to and yet still experiencing many of the same challenges. Go figure!

A Horse Of A Different Colour

2009-05-09T08:26:00.000-07:00

I'm venturing back into the work force on Monday, but with a twist. After 22 years of full-time employment, this will be my first experience as a contractor. Also, the work I'll be doing looks to be at least somewhat unlike anything I've ever done before.

I'll be performing a review of the development environment of a local company, in order to provide some guidance as they continue to refine their practices and processes. I think that I landed the contract on the strength of a couple factors in particular: my rather far-reaching involvement throughout my last employment as the Agile Manager, as well as the general breadth and depth of my resume, to date.

On that former point, it seemed relevant in the job interview that I had had some recent experience bringing change to an organization. I talked about how much I'd learned in the process, especially regarding the importance of being patient with people as they absorb information and evaluate it through their own personal filters. There's also naturally an element of trust required in something like that. I likened it to the expression about leading a horse to water but not being able to make it drink. My job often seemed to involve repeating that process, over and over again, until the horse finally trusted me enough (or maybe just got thirsty enough!) to take its first sip. (Not that I think of co-workers as horses! It's just an analogy!!)

By the same token, I think that the wide-ranging roles that I've performed over the past two decades also helped get me a foot in this particular door. I've worked on big mainframes and small client/server infrastructures; I've coded procedural algorithms (COBOL, C, Assembly language) as well as Object-Oriented solutions (C++, Java); I've been a "do-er" and a manager ("do-nothing-er"?); I've worked within well-understood roles but at other times had to define my own job. In fact, my resume, when I take the time to actually look at it (usually when I'm updating it), speaks volumes about the fact that I like new challenges. I've tended to change "jobs" (but not employers) at a pretty predictable rate of roughly every two years or so! And that's been true all along, showing that even as a wet-behind-the-ears programmer back in the 80s I was always looking for change as soon as I got comfortable with what I was doing. I think the pattern usually went: a few months of being a newbie, a year or maybe two of competence or better, and then on to the next thing. That cycle has given me a lot of varying experiences to draw on by now, it seems.

At any rate, I'll definitely be learning about a whole new set of parameters, starting next week. I'll be comparing what I see in front of me to my mental backlog of best practices. I'll be discovering what strengths and opportunities are in effect in an environment that's quite different than anywhere I've worked before, and making recommendations on each. And I'll be building up a bunch of new relationships, right from scratch. All of which sounds like something that should be right up my alley, I hope!

No AgileMan At Agile 2009

2009-05-03T12:58:00.001-07:00

I got the official word in the middle of last week that my proposed session for the Agile 2009 conference, "The Real-Life Adventures of AgileMan", didn't get accepted for inclusion in the program. In fact, of the 11 proposals that were made by people within my circle of friends (including my own), only one of them made the cut. Therefore either we're all very inept at writing up interesting session descriptions, or the competition was very fierce this year.

I don't know that my own efforts at "selling" my session idea were all that impressive, but I figured that I'd done OK. For the sake of posterity - and to let the readers of this blog judge for themselves - here's what I had written up:

Overview

What’s really involved in “going Agile”? While every Agile adoption has its own unique challenges and rewards, I’ve written 2 books about my company’s experiences moving from Waterfall to Agile. My focus is always on lessons learned, and we had literally dozens of those by the time we were done! In this session, I’ll be talking about early successes, what surprised us, where we dropped the ball, why role definitions turned out to be so important, where coaching would have helped, and many other similar topics. I think anyone considering a move to Agile would benefit from attending.

Process/Mechanics

In the 2+ years that I spent as my company’s Agile Manager, I was involved with every aspect of our transition to an Agile methodology. I worked closely with the Project Managers, Development Teams, Product Owners, Information Technology and the company’s Executives over that span, and also had several stints as Agile Coach to some of the teams. I’ve written two books (“The Real-Life Adventures of AgileMan (Lessons Learned in Going Agile)” & “More Real-Life Adventures of AgileMan (Year 2: Easier Said Than Done)”) about our experiences, describing our lessons learned so that others might benefit from what we discovered.

Each of my AgileMan books contains 32 chapters, covering a range of topics related to Agile adoption, all told in a conversational tone from the perspective of someone who went through it all first hand. As reflected by the Learning Outcomes for this session, I always regarded our 2-year journey of “going Agile” as having a narrative thread to it. That perspective made it quite easy for me to transform what might have otherwise been fairly dry material into what ended up being a very entertaining series of stories (I’m told). The focus of the books is always firmly on what was learned, even to the point that each chapter ends with a Lessons Learned summary page recapping the key insights that were gained on each particular topic. I believe that the material would therefore lend itself quite naturally to a 90 minute (or longer) interactive PowerPoint presentation in which I recount the key experiences that we had, following the narrative flow from the books, and answer questions from the audience. I’ve done this same sort of thing for various university Computer Science classes here in Ontario and have had great results to date. Obviously the treatment would, by necessity, be somewhat different within an Agile-centric environment like Agile 2009, but I would imagine that anyone attending the conference because they’re considering a move to Agile would find such an in-depth experiential discussion invaluable.

For the conference, I plan to do the following:

introduce myself in terms of background
explain why I wrote the two AgileMan books
provide context for how the material in the books is organized
spend about 5 minutes on each of a range of topics from my books, including fielding questions from the audience

Although the final set of slides will depend on the session length, I would expect to cover many of the following topics, as I run through the chronology of our experiences and what we learned from them :

the pitfalls that may develop when Agile is mandated down from the top (rather than beginning as a grass roots movement)
some early signs of trouble (role confusion, under-staffing, shaky legacy code)
considerations around team composition
areas where management may send the wrong signals by only “talking the talk” without “walking the walk”
the challenges involved with promoting a cooperative (Agile) environment while still employing compensation systems that are essentially competitive
the pros and cons of co-location
what to look for in a good Agile Coach
where metrics can do more harm than good
the role of an Agile Champion
areas where teams may struggle with providing good estimates
what can happen when you consistently try to do more with less
the perils of redefining job titles when not everyone has bought into the new system
the problem of bug debt
what it may mean if your team members begin talking about “zone time”
what a team may look like when it’s sticking to its principles even in the face of opposition
how to build up trust within the organization, and what can happen if you don’t

I typically first describe the “story” aspect of the topic - what was going on in the workplace as it relates to that subject - and then provide a bullet-point list of the lessons that we learned. Tailoring the material to the length of the session (90 or 180 minutes, for example) is simply a matter of expanding or pruning it down to the appropriate number of topics, based on importance and target audience.

Learning Outcomes

Why we believed that Agile was the right solution to our problem
How we went about transitioning to Agile
What the early surprises were
Where Agile produced the biggest rewards initially
Which areas of the company struggled the most with Agile
How Agile was received and perceived by different parts of the company
What Agile can reveal about an organization’s culture
What roles proved the most difficult for us to get right
Where we needed help (and often didn’t seek it out)
What we might have done differently

While the e-mail notification that I received indicated that I could check my proposal for more feedback on it, there actually wasn't anything there to indicate why it wasn't accepted or what might have made it more attractive.

Oh well... I'm sure it would have been fun to do, and that any attendees in the audience who were either considering an Agile adoption or just starting down the path of one would have gotten a lot out of it. Heck, I wish someone had provided some of the insights that I intended to include in the session back in 2006 when I attended my first Agile conference!

Experimentation Takes Discipline

2009-04-24T06:27:00.000-07:00

One of the key principles of any Agile methodology involves "inspecting and adapting." For those who are in the position of Agile Coach or Scrum Master, that sometimes gets represented in the mythical handbook as "encouraging experimentation." I personally think that it's one of the least understood and (perhaps accordingly) most poorly-applied Agile concepts, for a variety of reasons.

For most of us, success is almost always a goal. We want to do well at whatever we take on. And why not? Our performance reviews focus on how successful we were in various aspects of our job; our sense of self-worth is often dependent on how successful we believe others perceive us to be; and it just simply feels much better to "win" than to "lose." Unfortunately, though, experimentation brings with it the ever-present prospect of at least the appearance of failure, especially if one isn't careful about how one approaches such things. For example: if you take a bit of a gamble on something new in the course of your job (or personal life) and can see only two possible outcomes - it either works, or you're screwed! - then it's not hard to imagine that a "bad" result might make you less likely to ever again try something like that in the future. The problem could be that there was simply too much riding on the outcome to justify the risk in the first place, or that you didn't frame the experiment properly. For the latter case, a better setup would have been: "either this works and I have my solution, or I learn something valuable that gets me closer to finding the right answer." As long as learning and moving forward from your new position of greater enlightenment (what some short-sighted folks might indeed call "failure") is an option, then experimentation is a good avenue to go down.

What that implies, however, is that there's at least some degree of discipline involved. Randomly trying things until you find one that works, for example, isn't experimentation. What's required are some parameters that say, right from the start, what you're intending to learn from the experience. Determining whether your current architecture can support the new load that you're considering adding to it is an experiment that you might undertake, but ideally you'd like to get more than simply a "yes/no" answer from it. "Yes" is fine as an outcome (woohoo!), but you'd really like to elaborate on "no" with some results that provide insight into "why not?" and maybe even "where's the problem?" And therefore you'd design your implementation of the experiment with that in mind. Similarly, if you were on an Agile team and were going to try out pair programming as a possible practice, you'd want to establish a way of gathering results that provide you with lots of data. Subjective observations from those involved would be good, but so would some form of productivity measurement that would allow you to see - more objectively - whether pairing up team members causes the team's velocity to go up, down or stay about the same.

The final thought I have on this topic involves the notion of sticking with it long enough to actually get a result. That may sound obvious, but I've lost track of the number of times I've seen people start to try something new and then abandon it partway along. One way to avoid this is to establish, right at the outset, what the duration of the trial will be, as well as how the results will be gathered and measured. Among other things, that sets expectations and can prevent the impression of thrashing that might otherwise form in the minds of those who didn't realize that it was only an experiment in the first place. This could be a team trying something new and making sure that their Product Owner understood that it might "only" lead to learning, or a group of executives trying out a new organizational structure with the intention of re-assessing it after six months to see if it was working.

When I was asked at a recent speaking engagement whether I thought Agile was suitable for industries outside of software development, I mentioned that I thought scientific research, for example, had always been "very Agile." The very nature of good scientific work, after all, is to form a hypothesis and then conceive a test - or series of tests - to either prove or disprove it. The best scientists understand that sometimes you can learn more from a "failed experiment" than you can from one that gives you the results that you expected, and that that's a good thing. But that's only true if you're still paying attention by that point, rather than giving up or banging your head against the wall.

The Story Point Workshop

2009-04-15T06:47:00.000-07:00

I've been meaning to write up a description of the Story Points Workshop that I designed and delivered in 2007 and 2008, but hadn't gotten around to it... until now. I figure that there's always a chance someone will stumble across this blog and be interested in getting some training on Story Points, and so I really should have something here by way of a sales pitch. If you're reading this and would like to know more, please contact me at AgileMan@sympatico.ca and we can discuss it further.

The workshop that I created is intended to be appropriate for anyone involved in the development of software: programmers, testers, integrators, project/program managers, product owners, team coaches and even executives. In other words, you have to possess at least a basic understanding of the process of software development in order to be able to complete the exercises. Note, however, that you don't have to be of a technical bent, as there's nothing in the workshop that requires you to design, program, or even debug any software.

My goal in providing the workshop has always been to increase the attendees' understanding of, and comfort with, Story Point estimates. At the end of the day, I want everyone who took part to feel confident that they can use Story Points themselves - either as producers of them, or consumers - as part of the release planning process.

To get a large group of people, often with disparate skills and perspectives, all the way to that goal, I use a format that's proven to be both effective and fun (based on the results of feedback surveys that I've done at the conclusion of each session). Basically, the day-long workshop goes as follows:

Part 1: Introduction of Story Points

Here I cover the concepts of relative sizing (as compared to absolute) and what Mike Cohn characterizes as "Estimate size; derive duration." I do this through a combination of slide presentation and interactive exercises, the latter of which allow the group to do some estimating on things not at all related to software (eg. figuratively moving piles of dirt). This 60- to 90-minute section ensures that everyone has a solid foundation of understanding around the conceptual portion of Story Points before we move on to applying that knowledge.

Part 2: Estimating in Story Points

For this part of the day, which takes up the majority of the workshop, I introduce a new application called "the Meal Planner." This is a Java program that I wrote years ago, but the attendees don't really see it or any of the code for it. Instead, what they see is a description of what it is, as well as a set of additional features for it. Because the Meal Planner is a simple and fun concept that anyone can grasp within a few minutes, it provides a perfect backdrop to use in understanding how to Story Point items. No one in attendance has any history with it, and therefore it's unlikely that anyone would dominate the proceedings based on any real or imagined "expertise" with it.

The attendees are then broken up into smaller groups of 5 to 7 people and physically separated (by team) as much as possible. Each team is tasked with coming up with Story Points for each of the items on the Meal Planner's product backlog. I serve as the Product Owner for each group, running back and forth between them in order to answer questions or offer clarifications to the requirements that they've been given. This exercise typically takes between two and three hours to complete, as the teams often get off to very slow starts while they go through the "forming/storming/norming/performing" cycle.

Part 3: Comparing the Results

When all of the teams have produced their Story Points for the complete set of backlog items, I bring everyone back together, post their results up on the walls and encourage each team to review what the others came up with. Then I have a representative from each team briefly go through their rationale for each estimate, allowing the other teams to comment or question them. Sometimes the teams will have arrived at similar estimates; often they'll be quite different. We discuss what sort of factors contributed to those results, and build up a list of "What Worked and What Didn't" that help the attendees understand what sort of things contribute to better estimating versus what works against that goal. I usually will also provide my own Story Point estimates (after everyone else has), based on having written the application. All told, this section usually requires about an hour to get through.

There's a slight variation on the above that I've done in one instance, which proved quite insightful for all involved. I had 2 groups in that case, and so I decided to spend most of my time with one, at the expense of the other. Also, I'd planned it so that the "AgileMan-starved" group got a different set of requirements than the other group, with slightly less details in it. The results of this disparity were striking, to say the least: in many cases, the "starved" team produced estimates that were completely at odds with what both the "better-fed" group came up with as well as the "expert's Story Points" that I provided. I think this sort of thing is probably only appropriate if the workshop is being set up for an environment where the product people are struggling to fulfill their responsibilities (as was the case where I did it).

It's possible to get all of the above done in as little as about four and a half hours, although that's awfully rushed and not very conducive to learning. I prefer to schedule it for either five or six hours, in order to allow for regular breaks and to give people the opportunity to reflect on developments as we go along. Something like a 9:30 start, with lunch brought in, and a wrap-up by 4:00, works best. I've done the workshop with as few as a dozen people, and as many as 25 attendees, and both extremes seem to work fine. With fewer than 10 to 12 people, it's difficult to get 2 groups that can compare results. More than 25 would provide quite a logistical challenge for me to facilitate once the smaller groups are formed.

When I took this workshop on the road to a company in the San Francisco area in late 2007, I did 3 sessions there (one per day) and received an average score of 8.7 (out of 10) in terms of "overall quality." One of the company's Vice-Presidents recently recommended me to a colleague based on those workshops, saying that I had "received the most positive reviews from folks that any trainer has at our site, and we've had quite a few." So I like to think that it left a good impression!

"My Life As A PM Is Over: The Company Just Went Agile!"

2009-04-10T11:44:00.000-07:00

Last night was my presentation on Agile Project Management to the local chapter of the Project Management Institute, and based on the electronic polling results that were collected right after I finished, I think I did fairly well. Each member of the audience was given a handheld device about the size of a small calculator and then asked to respond to a series of statements along the lines of: "The topic presented by tonight's speaker was informative and interesting" and "Tonight's speaker appeared to be well-prepared" by selecting, on their device, either "1" (strongly agree), "2" (agree), "3" (disagree) or "4" (strongly disagree). For those who were having trouble figuring out how to work their new toys (since this was the first time they had tried this approach), I helpfully offered the advice, "Just press the button labeled '1'!" In most cases, I received scores where the total of "1"s and "2"s put me at or above the 80% mark, which was gratifying to see.

As for the material itself, I had worried that I had too much to cover in 2 hours, but somehow it all worked out, even with a 15-minute break midway through. I spent the first half introducing Agile, and then called for a short break. However, I asked that, during the break, everyone write down how they thought they might react if they went into work on Monday and their boss walked up to them and announced, "Guess what? We're going Agile in a month!" Just before resuming, I collected their responses and read them out for everyone to hear. Here are some representative samples of what I got:

"Agile? Can we get the Functional Managers to support it?"
"Good, [but] first educate the clients."
"Let's go!"
"Can we still perform accurate Earned Value analysis?"
"Great, but how do I co-locate with my global team?"
"1 week cycles??"
"But what's wrong with RUP?"
"Great, let's try it. As long as we follow ALL of the steps, not only parts of it."
"How do we break deliverables into iteration-sized chunks?"
"Risk of scope creep."
"How do you budget??"
"What are the signs that we NEED Agile?"

and my personal favourite:

"Do Agile? We don't even do Project Management!"

What impressed me most about these results, aside from the variety, was that it was pretty clear that everyone had been paying attention to what I'd been saying up to that point and attempting to rationalize it against their own experiences and work environments. Virtually no one was writing off the notion of "going Agile" as some crank thought experiment that they could laugh off or simply ignore. Also, I'd say that about 1/4 of the responses were of the "Let's go!" variety, showing that there was at least some buy-in among a group that was mostly hearing about Agile for the first time.

During the Q&A session at the end, many of those same concerns were expressed once again. One woman was sure that no budget would ever be approved without a guarantee that the work done would match what was being approved, to which I said, "If that sort of arrangement is working out for you right now, then I don't know why you'd ever want to move to Agile. The organizations that move to an Agile methodology are the ones where things change considerably between initial concept and final installation." Another fellow was understandably concerned about how to create automated tests to replace the extensive manual testing that they currently do at the end of each project, and I said that that was one area where you'd want to allocate time in order to research the new products and services that are coming out on the market for that purpose. "But in the end," I said, "you really don't have any choice: you need to have automated testing, or you'll never be able to do short cycles." I also got asked whether Agile was really only appropriate for "UI companies", to which I was able to describe some of the very-different types of organizations I've heard of - or seen! - doing Agile.

The moderator eventually had to call an end to the Q&A, as I think it might've gone on for quite a while longer otherwise. I received a $25 Chapters gift card for my troubles (which was nice, and unexpected) and eventually took off home to unwind. Sadly I didn't make any book sales, despite having several copies with me for just that reason. Maybe next time!

On The Technical Debt Topic

2009-04-03T19:36:00.000-07:00

Just a quick note to point interested readers toward this very good post on that subject. It's well worth the 5 minutes or so that it'll take you to read.

The Project Manager "Problem"

2009-04-01T07:33:00.000-07:00

I've been invited to speak at the next scheduled meeting of the local chapter of the Project Management Institute. It was requested that I make my presentation "about Agile" but the rest of the direction was pretty much left to my imagination and questionable discretion. As such, I've come up with material under the banner of:

"My Life As A PM Is Over: The Company Just Went Agile!"

Now, that title is most certainly intended to be attention-grabbing, humourous and perhaps even a little ironic. That latter characteristic stems from the slightly-nebulous view in which some in the Agile community hold Project Managers. At one extreme fringe of perspectives on the topic is the one that says, essentially, "Now that you've gone Agile, you can get rid of all your PMs!" A more moderate stance shows up in some of the Scrum literature, which advocates for having most or all of your Project Managers transition into the Scrum Master role. All the way at the other edge of possibilities lies the approach that I saw undertaken while I was the Agile Manager in my last job: keep the PMs as PMs, and figure out how to make that predictive, deadline-focused paradigm work in an iterative, adaptive environment. (Those who've read my two AgileMan books will recall that, many good intentions notwithstanding, we struggled greatly in integrating those two very different world views.) Even with that attempt to keep things somewhat as they were in the PMO, though, I think all of the people involved would agree that the PM role changed considerably as we moved through our Agile transition. Therefore, in all cases, there's some bitter irony to saying, "My life as a PM is over..."

For my material, I'm starting with what I presented to the 3rd year Project Management course last November. There's quite a bit of overlap, it seems to me. In both cases, I need to start off by describing what Agile is, under the assumption that some won't have even heard of it. Then, I'd be foolish not to acknowledge right away that many of the principles and practices of Agile can, and probably should, strike some project management types as idealistic, at best, and heretical, at worst. And finally, I want attendees to get a sense of how the role can still add value and be rewarding within an Agile framework. The biggest difference, of course, is that next week I'll be talking to people who have presumably been out in the real world actually running projects for a number of years now. That should mean that they're even more cynical, or at least skeptical, about the practicality of an adaptive approach. Will customers/product areas ever really sign up for a system in which change is expected throughout the process? Won't scope creep simply cause projects to run on forever? How can you let those developing the software also test it? And so on.

In providing feedback to Mike Cohn on his next Agile book recently, one of the places where I really challenged him was around his treatment of what to do with Project Managers. I thought that the draft version I reviewed made too light of the problem, not acknowledging just how much of a leap of faith is required in several aspects of his recommendation. If a company's culture has a strong dependency on micro-tracking of deliverables, who's really going to take that up if the PMs are re-purposed to other duties? Will most PMs, some of whom have spent considerable time and money getting their PMP certification, really want to risk losing it by directing themselves to activities which won't keep them current as PMs? How many individuals in the PMO really want to become Scrum Masters / Agile Coaches? I think those are just some of the vital questions that need to be addressed on this topic, and I believe too many of us have glossed over them in the past. I may not know the answers, but at least now I'm aware that the discussions have to happen.

It should be interesting to see how all of this goes over with the group next week! If you never hear from me afterward, you can draw your own conclusions...

Bugs Happen!

2009-03-25T10:09:00.001-07:00

A friend of a friend (who actually follows this blog, I believe) e-mailed me yesterday, asking if I had any advice on how to handle a situation that his Agile team kept running into. Apparently they'd had several instances in the recent past where high priority production bugs had come to the team in the middle of a (Scrum) Sprint. In each case, it was considered unacceptable that the defect resolution simply wait for the next Sprint, and so they had tried a couple of different approaches to address the urgency of the situation:

Include the bug-fixing activity in with another feature in that Sprint that was somewhat related
Add the bug fix as a deliverable for the Sprint, with a higher priority than everything else

I was told that neither of those had worked all that well, either in terms of successful completion or from a morale point of view.

As I said in my e-mail response, both of those were reasonable ways with which to try to accommodate a difficult and frustrating scenario. However, I could easily imagine - even without knowing any of the people involved - how each might've gone awry. So instead I offered a different tack to consider next time, and it's the one that most Agile purists would likely always push for. But before I get to that, a few thoughts on the general topic of "bugs from the field."

Since I don't personally believe in "defect-free software" (having never produced, used or purchased any examples of such a mythical creature of legend second only to the unicorn), I go about my day under the strong assumption that there are always going to be problems found in production that weren't caught prior to getting there. Of those, some will be of a truly urgent nature that need immediate attention, and many won't be (but may still be initially prioritized as if they were); most almost certainly could have been detected and corrected before getting out the door had enough time and energy been expended in the search for them, and a few probably couldn't have been. In other words, they come in all shapes and sizes, but regardless: they come when they come! So, for me, the important question to be asked of any bug when it arrives back at our doorstep is, "What can we do better in the future to make production defects less likely." And if you're getting a significant enough quantity of showstopper bugs following release, then clearly you're not asking or (more importantly) answering that question adequately. Some serious and ongoing "inspect and adapt" discussions and tasks need to be happening if "stop the presses!" types of live bugs are more than an occasional occurrence for you and your team. That's one particular problem, and it's discreet from the one that was being posed of me.

What I was being asked was what to do in the short term, potentially high-pressure situation of dealing with the here-and-now of a bug's arrival and its effect on the current Iteration or Sprint. And, of course, the by-the-book answer is that you either cancel the Sprint and plan a new one to include the bug fix, or (somewhat less drastically) get the Product Owner to remove something from the Sprint in order to make room for the bug fix. I prefer the second approach because I'm not a big fan of bringing everything to a halt simply to accommodate something new. It may be that the bug in question is going to suck up so many of the resources for so long that you'll determine, while sizing it, that you're going to have to effectively cancel everything else anyway, but I'd prefer that an outcome like that simply remain an option, rather than the default response. In either case, though, you're taking actions that clearly send the message that fixing this bug is "not nothing." And that's critical because, among other things, it can sometimes result in the bug fix suddenly not being deemed as important as it had been when it had no price tag associated with it. It's like the free coffee and pop at my last workplace, which a few misguided souls there tended to treat rather disrespectfully (open can, take sip, leave remainder there for cleaning staff to deal with). When something's thought to be "free" that isn't really, it often gets some poor assumptions made about it.

Now, one argument against what I've just written that sometimes gets made goes like this: "Since the team didn't find the bug in the first place (but should have), then it's up to them to figure out how to fix it without jeopardizing everything else that they've committed to in the Iteration/Sprint." Honk if you've ever heard that one before! (Honk! Honk! Honk! Honk!)

There are a number of reasons why that's a silly stance to take, and I couldn't possibly think of them all in one sitting. But among the most obvious problems with it are:

it encourages teams to fix things in the most slap-dash manner possible, since every minute they spend on the resolution is taking time away from what they were actually expecting (and expected) to work on
it drives home the belief that the team is going to be penalized for every mistake they make, thereby making experimentation less likely (which is appropriate if you're programming a system for the Shuttle or a pacemaker, but in most cases...?)
it flies fully in the face of the reality that even software organizations with tens of thousands of employees ship code with bugs

So for those reasons and others, it's unreasonable to expect development teams to "suck it up" and absorb critical bug fixes without removing any other work (unless the team decides, of course, that it's a small enough effort and can be added in with no impact).

Getting back to the question of "how often does this happen?", I think that what I've outlined above works fine as long as the scenario we're talking about is the exception, and not the norm. However, if it's happening on a more frequent basis, then in addition to figuring out why (and doing something about it that should reduce the occurrences in the longer term) you may need to set aside a small percentage of the team's velocity every Iteration for critical bug fixes. As I said in my e-mail response, you really want to make sure that any time that's allocated for that use be limited to actually dealing with high priority bugs, or bringing work in (off the product backlog, in priority order) if no urgent defects come along by, say, the midway mark of the Iteration. It definitely should not become a "slush fund" that can be used to soften the blow related to under-estimating, get work in on pet projects or simply to provide a cushion for the team. (You may, of course, want to allow some Slack Time for the team to dream up process improvements or new tools, but that's a different discussion.) If you can do it right, the team will regard that extra time correctly, and no one outside the team will have any reason to resent it or try to eliminate it, because they'll see the value of it, either in terms of showstopper bugs being fixed quickly or additional features being delivered.

Of course, it's easy for me to offer advice when I'm not in the middle of the fray, but that's just the way the ball bounces at the moment. Maybe someday I'll be back in there, swinging for the fences...

It's All Relative

2009-03-18T08:03:00.000-07:00

A friend of mine was recently describing his workplace to me, and I couldn't help but evaluate it (in my head) as if it were supposed to be an Agile environment (which it isn't). I realize that that's a bit of a strange reaction to have, but it happened nonetheless.

So here's a thumbnail sketch of what I envisioned as I heard more about the office in question:

Leadership style - From what I could tell, it sounded like a very Command & Control setup, although I was interpreting from just one person's comments. The managers keep a very tight grip on all of the decision-making, to the degree that the expression "micro management" kept coming to mind as he related some of the day-to-day occurrences. In his view, this level of hands-on guidance was completely normal and expected from management, but I marveled at how unaccustomed to that style I'd become in recent years.
Trust - People in the office are all on fairly short leashes in terms of working hours, as one example of where trust is lacking. Even back in my pre-Agile days as a manager, I think I established a fairly easy-going attitude when it came to things like people needing to shift their hours around or take time off for personal stuff. Therefore it was quite eye-opening to hear about a white collar shop, in 2009, that still operates under very rigid rules in that regard. When I asked about it, I was told that "someone in the past had abused [flex time], and so now they don't allow that sort of thing." Rather than simply penalizing the person in question and extending trust to the rest, I guess the decision was made not to trust anyone with that kind of latitude.
Transparency - The funniest example I heard involved some data that was being gathered about productivity within the group. At first I was excited to hear that metrics were being used, but then it turned out that the information wasn't going to be shared with the "rank and file" because of fears that they'd adjust their behaviour (in the wrong direction) if they saw the data! That was just mind-blowing to me, but it probably shouldn't have been. After all, transparency is certainly not the norm, no matter how much we might want it to be.
Empowerment - Because it's always been a favourite topic of mine, I tried to ask the sort of questions that would give me some sense of how empowered employees were at this company. The impression I got was that some of the leaders play what I like to refer to as "the false empowerment game", which goes as follows: I tell you to do something but I don't tell you how or give you many details. When you proceed to do what you think I wanted done, then I look at the results and say, "That's not right. I want it to be more like this." After a few more iterations like that, we finally end up with the correct product. (So, in one sense at least, they're doing iterative development!) The problem with that approach is that it wastes a lot of time and teaches the staff not to make decisions.

Now, as I say: this isn't an Agile office that I was hearing about, so there's no reason why they should be expected to live up to Agile principles. And yet I couldn't help but wonder just how much better they might be doing if it were, and they were.

The Latest Lecture

2009-03-11T11:14:00.000-07:00

Today I did my third iteration of the "Introduction to Agile" university lecture for second year Computer Science students. The class size was around 30 this morning (out of a possible 38), which was bigger than it's been in the past. I'd love to chalk that growth up to the AgileMan reputation spreading across campus and bringing them in from far and wide, but I think it's actually just a larger enrollment this time around.

Since my material tends to be the same each semester, what distinguishes the different sessions are the questions posed by each group. Today, one student asked whether Agile only worked for smaller companies, as it seemed to him that it wouldn't scale well. I explained that it had been fairly common for people to assume Agile wouldn't work in larger companies, but that books had then started to appear that provided insight and guidance on how to scale the practices without losing the principles. Because time was limited, I didn't go into any of the examples, such as the Scrum of Scrums (or even Scrum of Scrum of Scrums) concept to facilitate communication between teams, or Communities of Practice to share learning and discoveries. But I thought it was a good question and showed that the young man asking it had been thinking about what he'd been hearing.

Another question was, "With Agile, do you see more instances of burn out?" As soon as this was raised, I realized that nowhere in my slides do I mention the concept of "sustainable pace." I'll have to correct that for future lectures, but in the meantime I explained what's meant by that term. Then I described how you have to reinforce that principle, in both words and actions, and that failure to do so can quickly lead you down the path to an endless series of death marches.

I was also asked what tools are available to use if you decide to go Agile (I rattled off a few, and mentioned that since Nature abhors a vacuum, there were new ones showing up on the market all the time) and what sort of projects would be better suited for Waterfall (a question I've gotten before, and to which I always offer up "heavily-contractual, government and/or highly-specified work where the customer doesn't typically change their mind midstream").

As happened with the third year, 3-hour lecture last November, this one ran out of time before we'd exhausted all of the questions. That's always a much better feeling than what's occurred with previous incarnations of this second year course: few or no questions and a palpable sense of relief from the attendees that it's over! I'm not sure what to attribute the difference to this time around, but it just seemed to flow better all around.

What Can We Learn From Video Games?

2009-03-05T12:52:00.001-08:00

When looking for insights into how we can all work together more effectively, there are worse places you could go than into the online environment of video games.

The sorts of games that I play, at least, have many of the same attributes that we value in the best workplaces:

a focus on teamwork makes a difference - many squad-based setups only reward the individual players with experience points and movement up the ranks if they work together toward team-oriented goals; lone wolf tactics in team games are generally unsuccessful, and sometimes even penalized
adaptability is a must - while a select few may be naturally gifted at the art of gaming - or software creation! - most of us discover quite quickly that we can only achieve respectable results if we adapt to each new environment; adopting an attitude of "that's just the way I am!" rarely works very well in online competition, just as it's severely limiting in Life
clear goals can work wonders - there are few things quite as frustrating as not understanding what you're trying to achieve, and video games are becoming increasingly aware of that fact; you may be informed of your objective(s) in any number of ways (icons on a map, voice-over instructions, or even a small on-screen display of the current score) but the point is to keep everyone's eyes on the prize... which is equally sage advice for the workplace, as well!
metrics and other forms of feedback are powerful - just as important as having goals is the understanding that reporting results will affect how people behave; one of the ways video game companies capitalize on this is by providing lots of statistics to their players; if you know that you're doing especially well with one type of weapon, for example, that may inspire you to use it even more and try to rise to the very top of the leader boards in that category; conversely, you might decide to direct your energy toward an area where you've discovered that you're below average, now that you have that data in front of you; in all cases, having more information empowers people in ways that ignorance never will
leadership always reveals itself - if you've ever played online and watched a really good player take over a game, making the entire team better through a combination of outstanding strategy and technique, only to later discover that you were following the masterful guidance of a 12 year old kid, then you know that leaders come in all shapes and sizes; those who can, lead; those who can't, need to learn how to follow... and video games often make that distinction readily apparent in ways that questionable promotions and titles at the office seek to obscure

While admittedly somewhat tongue-in-cheek, I still hope that this post will nevertheless make all of us consider just what might be gleaned from even the most unlikely of sources... including video games!

Risk Assessment Is An Underappreciated Talent

2009-02-26T07:53:00.000-08:00

Any project managers out there, upon encountering this blog post, are probably looking at the title and saying, "Yeah! You better believe it!" In many software development organizations (perhaps most of them), it officially falls to those in project management to worry about risk. In reality, though, risk identification and mitigation are two concepts that every one of the project participants should care deeply about.

To draw on a current real world example, look at the state of the financial industry in America right now. No one in their right mind would describe it as anything less than disastrous, no matter how much people may disagree on the exact root cause. One of the main contributors to the meltdown, we've been told many times, was unbridled optimism. Whether it was home owners taking out mortgages that they couldn't afford (but all of whom believed that they could), real estate speculators assuming that housing prices could only continue to go up, credit businesses refusing to consider the consequences of a market downturn, or the public in general failing to set aside much in the way of "rainy day savings," the result was the same: once the first domino fell, all of the rest were lined up in a perfect, catastrophic pattern behind it. In other words, a lot of folks misinterpreted a variety of "best case outcomes" as being virtual certainties.

In the world of software, we face a very similar problem. When we create a plan - whether it's a traditional Microsoft Project plan for Waterfall environments or an Iteration plan for an Agile team - I've too often seen what I can only describe as that self-same unbridled optimism. In one way, that's a commendable attribute: after all, it's indicative of a "can do" attitude that's much preferable to a bunch of nay-sayers who won't even try, for fear of failing. But it still has to be tempered with reality. At the very least, any group involved in this sort of planning activity has to spend some time discussing what might reasonably go wrong, and what the impact(s) for each would be.

That's the identification part of the equation, and I'd say (from my own experience) that programmers in general tend to grade somewhere around a C- at that. You'll get some who are really good at it, and others who apparently can't see anything at all in front of them except the Yellow Brick Road that leads directly to Oz. Team members with a testing background or responsibility are usually better at this, perhaps because their stock and trade is stuff not working the way it's supposed to. I'd say the average test-inclined person maybe scores a B- at risk identification, although, again, you'll certainly get all sorts of results. Some testers, for example, only think in terms of bugs in the code, rather than considering "bigger picture" hazards like environmental issues, requirement ambiguity or dependency failures.

When you bring that programming perspective together with the testing POV - either in a meeting, or as Agile tends to do, in one person or a close-knit team - I think the discussions often provide some very good risk identification. The two views feed off of each other, and pretty soon you'll hear some very creative ideas of "what could go wrong." This is more of a refreshingly-effective B+ effort, if you can make it happen. There can almost be a gallows humour aspect to those talks that may cause the unseasoned project manager/stakeholder to run for the Pepto-Bismol! (So, yeah, it can be fun!)

For risk mitigation, though, I think the software world in general really lets our PM friends down. I'd even go so far as to say that we probably earn a solid F in this particular area (or perhaps it's simply an "Incomplete"). In part, the bad performance here stems from the fact that mitigation is often as dependent on the corporate culture as it is on anything else. As an example, consider the classic case of an external dependency not being met. In some companies, such an event would be regarded as reason enough (some might say "excuse") for the greater initiative to fail. Therefore, there might be little stomach for planning any mitigative actions for that possibility, as the blame would be laid squarely at the feet of the non-deliverer. End of story. But in other environments, there can exist expectations - spoken or otherwise - that those involved in the local project can somehow work around unfulfilled external deliverables. Those two scenarios are very different, and it behooves everyone on the project to know which type they operate within. And that's something that makes this whole "what do we if this risk becomes reality?" question hard to answer, especially when you consider the unspoken expectations that often go along with the handling of these risks.

Another challenge to good risk mitigation is that old favourite of mine: empowerment. If a company has a consistent and well-understood empowerment model, then it's easier for a group of programmers/testers/product reps to tackle what to do about each potential hazard. In a top-down model, you may be able to simply kick the problems upward, and comfort yourself in the knowledge that your job is to identify the risks and then escalate them. Again: end of story. Where teams are more empowered than that, then they'll probably look for creative solutions that may involve spending money (buy additional hardware, set up network redundancies, increase bandwidth) or moving human resources around (get temporary expertise from elsewhere, increase headcount on the project), with some reasonable assumption that their time wasn't wasted in considering those options. Where the empowerment model is muddy - maybe one type gets lip service paid to it but another is found in practice - then the job of risk mitigation becomes that much more difficult.

As someone who worries a lot about risk - maybe too much, according to my wife! - I can't help but wish that it got more consideration in the minds of others. When things are going well, there's a natural tendency to expect that delightful state to continue forever. But it's our ability to imagine just what might come along and turn all of our plans to mush that gives us an advantage... if we remember to use it! Otherwise, we end up with situations like the cratering American financial sector.

How Do Incentives Really Work?

2009-02-17T19:28:00.000-08:00

In many of the write-ups of the financial woes gripping the world right now, it's pretty clear that certain incentive programs were put into place over the past decade without any clear understanding of what their logical outcomes would be. For example, people in the U.S. were encouraged in many different ways to get into the housing market: through income tax breaks relating to their mortgage interest, through low interest rates in general as well as - in some cases - even lower start up rates (deferring the higher rates until later in the life of the loan), and through changes in the banking laws, intended to help lower income families get into their first homes. All of those forces acted at cross purposes to set up a scenario where lots of folks would have mortgages that they couldn't really afford, which was at least one of the catalysts for the larger financial mess that we're in. And no matter how harshly one thinks of the last couple of administrations in the U.S., no one in their right mind would suggest that what we see around us today was the goal of those actions!

So why is it so hard to get incentives to work out in the way that you intended? Part of it, I think, is that you need to have all of the players aligned with the same goal. Going back to the sub-prime lending fiasco, there was a clear disconnect between the objectives of those involved. Many of the financial companies doing the lending, for example, didn't care whether or not the recipients of the mortgages stayed in their homes (they'd already repackaged the debt and sold it off to others to worry about) as their focus, in the form of compensation, was on volume, not stability. The recipients of the loans wanted one of two things (or possibly both): a long-awaited entry into the ranks of home owners, and/or an investment that they believed would net quick profit. Finally, many of the original statutory changes were aimed, in one way or another, at getting citizens who had sub-standard credit rankings but were otherwise viable mortgage holders their own slice of the American Dream. There's very little alignment there. More than that: the notion of "quantity over quality" (on the part of the lenders) was often completely at odds with the goal of housing viable mortgage-holders. Hence the unfortunate results.

In a software organization, the stakes are usually a little less earth-shattering (thank goodness!). A typical case might be a yearly or quarterly bonus program in which the portion realized by each employee is dependent upon how they themselves, their team, their department or the company in general (or any combination, thereof) does against certain objectives. That sort of thing rarely causes the worst case outcome of clashing goals and carnage. Instead, the most common result seems to be a relatively benign disconnect, in that the average employee may feel that he or she has little influence over some of the broader metrics. In that case, the setup has simply been ineffective, rather than counter-effective (whew!).

Better programs and initiatives, however, actually manage to inspire results that might not have come about without their inclusion. While admittedly small potatoes, I've seen and heard of nice results coming from something as simple as establishing rewards for suggestions that end up saving the company money. It becomes less about the money itself - is anyone really that motivated by a $20 gift certificate anymore? - and more about the recognition, the feeling of accomplishment, and the confidence that comes from believing that you're operating within a system that values improvements. It can actually create a cultural paradigm shift, away from "Why bother complaining, since nothing ever comes of it?" and toward "If something's broken, let's fix it!" And that can make a world of difference, although it may happen so gradually as to slide under most peoples' radar.

I think a lot of incentive programs never come into being because there's a decision made, at some point along the way, that it'll either be too expensive, or too susceptible to gaming. The cost issue is always a thorny one, and perhaps the only way to deal with it is to budget a certain amount, broadcast that fact, and then see how it goes. If you end up running out of money before you run out of time (or ideas), then either it was a success and you should attempt to increase your budget for the next period, or you got very little value out of it and it's time to re-tool. Either way, you can adjust and go forward.

The gaming concern is a different problem to solve. First, I came to the conclusion years ago that there will always be someone in any group of ten or more (just to pick an arbitrary number) who will attempt to get something for nothing. And that's what gaming is, after all. The person who hears, "Our bonus is tied to how many test cases we write because management wants our test coverage to improve" and thinks, "I bet I can make more money if I make all of my test cases really trivial and small" is hoping to get something (a bigger bonus) for nothing (doing no work that will actually improve his company's situation). But the number of employees who react that way will, generally-speaking, be inversely proportional to the quality, relevance and clarity of the goal. Most people, given the proverbial "SMART objective" (specific, measurable, attainable, realistic and timely), will enthusiastically put their back into it and work toward it... especially when there's money on the line. Therefore, it seems to me that time is better spent by those in leadership establishing the goals, including the metrics and rewards, rather than worrying about what gaming may occur. Even if a few bad apples work against the spirit of the program, the vast majority will produce more than enough of the good stuff to overshadow them. And eventually peer pressure, as well as the sense of accomplishment coming off of those really doing the work, will transform the culture into something in which gaming isn't abided at any level.

Of course, as always, it's easier said than done. But that should never stop us from trying!

Where's The Happy Medium Between Gold-Plating And Shoddy Work?

2009-02-11T17:22:00.000-08:00

I think sometimes the line between "not good enough" and "better than it needs to be" is about the width of a razor blade (not that I know all that much about razors!). And that slim of a margin for error is not a very easy target to hit, especially amidst the chaos, pressure and distractions of most software projects. So what can we do to make the situation better?

Well, first I think that we need to examine what's really happening whenever accusations of "gold-plating" come up. I've seen it often enough in the past 22 years to at least have some ideas on it by this point in my career. The most common culprit always seems to be time, in the sense of there never being enough of it. When a customer, or project manager, or really any stakeholder with their ass on the line has their eye on the calendar, "finishing touches" can quite easily take on the appearance of "make work projects" or "endless tweaking" (and I don't mean the kind that requires amphetamines!).

To appreciate that perspective, just imagine that you've gone to pick up your car after a repair. You're in a hurry because someone's waiting for you and you told them that you'd be there by now, only to take longer than expected to get to the garage and then find out that the car's almost-but-not-quite ready. You then catch a glimpse of the mechanic busily doing what looks for all the world to you like a polishing job on your hubcaps! Of course you'd be frustrated at that scene, because as far as you're concerned you'd much rather get where you need to be right now with dirty hubcaps than arrive there later with 'caps that look brand new. But what if what was really going on was that the mechanic was checking out your tire pressure and using a rag to clear the tire well enough that he could read what the pressure should be? Most people would agree that having your tires checked is hardly "gold-plating," but you may not even know that that's what is actually happening from your vantage point. And on a more relaxed schedule, you'd simply trust that the mechanic knows what he's doing rather than jumping to any unfortunate conclusions. Start the clock ticking, though, and that whole willingness to extend trust may go right out the window... unless we make a conscious effort to be aware of that trap, and avoid it.

Now, that first point assumes that it's a simple lack of understanding that's creating the conflict. The software developer, in that case, is engaged in some activity that he or she has every reason to believe is required, in their expert opinion; meanwhile someone less involved leaps to the wrong conclusion about it being unnecessary. That's certainly not going to be the only scenario that can result in "gold-plating" charges being thrown around, though. Another possible cause is that there actually is work being done that is above and beyond what's needed to complete the job satisfactorily. So how do developers know when they've reached "good enough" with a piece of functionality?

One obvious way to answer that question is to ask another one: "What's the likely result if I don't do this next bit of work?" If that query can be posed and subsequently answered honestly, then I think we'd have far fewer confrontations of the sort discussed in this blog post. Most of the time, though, I suspect the question's not even being asked; and of those times when it is, then all too often the answer offered up is at least somewhat disingenuous. Why would a developer not honestly answer it? Because they may have an agenda (hidden or otherwise) that's not necessarily related to customer satisfaction. Some examples would be:

"This code is too hard to work with unless I change it to look like what I'm used to."
"The customer might ask for this functionality in the future so I need to put it in now."
"I've thought of a case that will probably never happen, but if it did this code might possibly break so I'd better rewrite it."

That's not to say that any of those responses are categorically bad; just that they might not be reason enough to dictate that something's not ready, and therefore delay a release. And even a whiff of that sort of thing can cause the cries of "Gold-plating!" to go out.

So there we have two of the many ways in which this unfortunate situation can arise. To guard against them requires greater transparency, communication and honesty than we might naturally demonstrate if we just went about our business with our heads stuck in the sand. Living up that higher standard is a lot to ask of us all, to be sure; but as skilled professionals who take pride in our work, we can do it... can't we?

The Story Of My Life

2009-02-04T16:13:00.000-08:00

Ron Jeffries, one of the better known authorities on eXtreme Programming (XP), recently posted an article on his XP blog that really resonated with me. He calls out, for what is certainly not the first time, the idiocy of adopting an Agile methodology without doing the whole thing and then faulting Agile when it doesn't work out for you. Readers of my 2nd AgileMan book will recognize that I witnessed that first-hand, and the results were just as Jeffries describes them.

The following paragraph, in particular, paints a compelling portrait:

"Well, my dear little children, I’ve got bad news for you. It is your precious context that is holding you back. It is your C-level Exeuctives and high-level managers who can’t delegate real responsibility and authority to their people. It is your product people who are too busy to explain what really needs to be done. It is your facilities people who can’t make a workspace fit to work in. It is your programmers who won’t learn the techniques necessary to succeed. It is your managers and product owners who keep increasing pressure until any focus on quality is driven out of the project."

Setting aside the condescending tone, it all sounds eerily familiar. In a funny way, I guess it's sort of comforting to know that what we went through was far from unique in the annals of Agile. But only sort of.

What Should We Really Expect From Our Leaders?

2009-01-28T10:13:00.000-08:00

One week into his new presidency, Barack Obama is still one of the most talked-about people on the planet. It's hard to go anywhere - even to websites dedicated to the discussion of comic books! - without bumping into references to the 44th President of the United States. And where once the focus tended to remain on the historic significance of an African American ascending to the highest office in the land, now the talk has turned to the more familiar territory for U.S. presidents: is he doing the right things? It's still much too early to draw any conclusions on that question, but I think we're beginning to at least get a better feel for the man.

One trend that's become apparent in Obama's actions, so far, is that he's focusing on the future, not the past. His Inauguration speech had several mild jabs at the previous administration, but they were made in passing, and only as a point of contrast for what he hopes to accomplish in the future. Consider this passage from the speech:

"But our time of standing pat, of protecting narrow interests and putting off unpleasant decisions -- that time has surely passed. Starting today, we must pick ourselves up, dust ourselves off, and begin again the work of remaking America."

The lasting images from that small section are not the ones that he begins with - that of lobbyists dictating government policy for a powerless electorate, and infrastructural and environmental concerns being shunted off to the sidelines by those in charge - because he quickly declares that period to be over, and instead paints a more encouraging portrait of the classic indomitable American spirit that built the country in the first place. In this way, he acknowledges the problems that exist currently but couples that with a commitment to address them. That's great leadership.

In another part of the speech, he says:

"The question we ask today is not whether our government is too big or too small, but whether it works -- whether it helps families find jobs at a decent wage, care they can afford, a retirement that is dignified. Where the answer is yes, we intend to move forward. Where the answer is no, programs will end. And those of us who manage the public's dollars will be held to account, to spend wisely, reform bad habits, and do our business in the light of day, because only then can we restore the vital trust between a people and their government."

Perhaps most telling in that quotation is the admission at the end of an existing trust gap between the government and those whom they govern. I think back to my former workplace and wonder, "Would any of our leaders there have been bold enough to own up to that in public?" It seems highly unlikely to me, and yet Obama does so on (literally) Day One.

While still somewhat lacking in specifics - and one would shudder to imagine what an Inauguration speech that was laden with minutiae would sound like! - that previous section of the speech lays out a blueprint for how the Obama administration plans to re-calibrate the American government. There's reflection, in the form of determining, for each existing program, whether it's working or not; there's accountability promised on behalf of those in charge; and there's an implicit commitment to transparency. Toward that final point, one need only visit the new and improved White House blog to appreciate what a new day has dawned in Washington. (Can anyone even imagine the Bush-Cheney administration operating within a similar aura of forthrightness?) Again, these are all indicators of great leadership.

One of the most-cited portions of the speech went as follows:

"To those who cling to power through corruption and deceit and the silencing of dissent, know that you are on the wrong side of history, but that we will extend a hand if you are willing to unclench your fist."

To fully grasp just how different a tone was set by these words, compare them to what George W. Bush said in his infamous "Axis of Evil" address:

"States like these, and their terrorist allies, constitute an axis of evil, arming to threaten the peace of the world. By seeking weapons of mass destruction, these regimes pose a grave and growing danger. They could provide these arms to terrorists, giving them the means to match their hatred. They could attack our allies or attempt to blackmail the United States. In any of these cases, the price of indifference would be catastrophic."

Bush offers no olive branch, but instead exclusively peddles the commodity that would later get him re-elected: fear. He paints the world in the sort of stark black-and-white terms that only a small child would buy into: that of pure-good versus pure-evil. "You're either with us, or you're a terrorist!" That's cowboy leadership.

Obama, on the other hand, acknowledges the threats that are still out there, but also provides hope for eventual peace. History may prove that he was too naive, but I think that we've already seen enough to conclude that Bush was too divisive in his approach. (Which is quite ironic, considering the man characterized himself as "a uniter, not a divider" during the 2000 campaign!) The world has been growing increasingly more dangerous for decades, but vilifying your enemies while keeping your populace cowering in fear can't possibly be the right response. Barack Obama, it appears, understands that there's no eventual outcome from such an approach that can jibe with the ideals so proudly proclaimed in his country's constitution. He has, at the very least, presented his people with a path that is no longer at odds with their espoused values. At the risk of beating a dead horse: that's great leadership.

Reflection, honesty, accountability, transparency and an alignment of actions to values (some might call that "integrity", I suppose)... those are all attributes that have already exhibited themselves in some of President Obama's words and actions in his first week in office. They also show up in many of the books about Agile, as well as in discussions of leadership. I happen to believe that those are all traits that we should commit to, ourselves, and that we should expect from our leaders. Anything less should simply not be acceptable.

Giving Feedback

2009-01-23T08:52:00.000-08:00

A couple of recent events have gotten me thinking about feedback.

The first incident was an offhand comment that a friend in management made to me while we were talking about something else. In mentioning that he'd just had a one-on-one with a staff member, he casually tossed off the fact that it had gone very quickly "because that person is doing a great job." That got me thinking about how we sometimes perceive meetings with employees as being issue-driven. In other words, a manager might consider that her only responsibility in a one-on-one is to respond to anything that the employee brings to her attention. To be sure, that's part of it: if someone who reports to me expresses concern that he doesn't have the equipment that he needs to do his job, has a conflict with a co-worker, or demonstrates a desire to get training in a particular area, then it behooves me to take that information away and do something about it. That's what I tend to think of as the reactive aspect of management. Any manager who doesn't pull off at least that much of the role is really hurting (in more ways than one) and should consider either stepping up his game or moving to a less-senior position in the company.

But less obvious to some is the proactive part of people management. Going back to the example above, someone who's "doing a great job" is every bit as deserving of feedback as the employee who's got a beef, is visibly struggling or has been causing problems for others. The reality, of course, is that often the "great job" folks don't get much attention from their managers because they don't represent the proverbial burning fire in the way that the more reactive situations do. While that may make some logical sense - at least to those of us who've been in management and experienced the "crisis du jour" scenario in all its glory - it's also kind of ass-backwards, if you think about it. After all, here are the stars and superstars of your organization, and they're the ones that you basically leave to their own devices, while you focus all of your attention on everyone else. It can certainly be a tough trick shot to pull off, but what's really called for in that situation is that the manager spend a non-trivial portion of her time providing morale-building feedback on those areas that her best performers are excelling at, as well as coming up with new goals and challenges that will excite, inspire and motivate them to grow even further.

And if you can do that, then it's unlikely that any one-on-one get-together will ever be particularly short!

The other recent trigger for feedback thoughts was the time I spent earlier this week reviewing a draft copy of Mike Cohn's next book. This is something I've been doing, on and off, since late last year. I'm a big fan of Cohn's previous works, as well as a two-time attendee of his Agile Estimating workshop series. Because of that, I was more than happy to set aside some time to provide feedback on a selection of chapters within his upcoming Succeeding with Agile book.

Despite having no professional experience whatsoever in the field of editing, I happen to think that I'm pretty good at it. (That could, of course, be entirely delusional on my part!) For material of this sort, what Mike usually gets from me are comments that fall into the following broad categories:

booboos: typos, spelling mistakes, grammatical errors, wrong words used
flow problems: poor transitions, leaps of logic, unsupported conclusions, contradictions, wandering points
missing bits: unaddressed concerns, partial lists, problems with no solutions
suboptimal choices: examples that seem weak, repetitive wording, sentence structures that sound wrong if read aloud
positive reinforcement: places that really worked, humourous parts that made me laugh, sections that especially resonated with me

In each case, I give specifics (pg #, some piece of text that can searched on easily, and whatever point I'm trying to make) because I want him to at least understand what I'm saying... whether or not he agrees with it, is up to him. It's an easier relationship than the manager one that I wrote of up above, because there's really no onus on me, in this case, to convince Mike to change a single thing in his draft. That's not my role here, as he's not working for me and I'm not in any way responsible for the contents of his book. But that still doesn't mean that I should take the task of giving feedback lightly (which I don't), or that I should simply throw a bunch of vague, generalized observations his way and let him make of them what he will.

As someone who's recently been on the receiving end of review feedback (not just once, but twice!), I know first-hand just how valuable it is when it comes in the form of specific, clear communication. I was pretty lucky in that regard, but then again I chose my reviewers fairly carefully. In general, I'd strongly recommend that if you're ever asked to provide that sort of thing in the course of your travels, simply put yourself in the other person's place, and then give the kind of feedback that you'd consider the most valuable were you receiving it. (That old Golden Rule just turns out to have so many applications, doesn't it?)

By the way, if you'd like to similarly review some of the chapters of Mike's book, you can do so here.

Great Leaders Don't Play The Blame Game

2009-01-18T19:59:00.001-08:00

Watching a Sunday morning news program today, I heard an expression that took me back to my days as Agile Manager. The comment was made in relation to the current economic woes facing the U.S. (and the rest of the world) and was in response to the question of whose policies really caused it. The answer given was, "There's plenty of blame to go around!"

I don't dispute the factual veracity of that assessment, as it's almost certain that multiple parties failed in various ways to carry out the responsibilities of their positions. It wasn't just the banks that screwed up, or the legislators, or the people who are supposed to enforce the rules, or even the people borrowing more money than they should have. It took all of that misbehaviour and more to bring the world economy to this point.

At my last job, the same thing was true. We didn't typically experience failures, whether large or small, because of just one person somewhere dropping a single ball. Instead, it was usually a more widespread problem, involving roles like Vice President, Project Manager, Product Manager, Product Development Leader and Product Development Team member. I honestly don't believe that any of us in those types of positions were "without sin" and therefore free and clear from accepting a share of the blame for how things went.

However... Where I didn't always see eye-to-eye with some of my peers and superiors on the topic of the Blame Game was in the relative weight that should be borne across the players. Rightly or wrongly, I've always operated under the assumption that management needs to be held to a higher bar. I felt that way before I joined the management ranks, and I've continued to subscribe to it since then, as well. One small indication that perhaps I'm not so out there in my thinking comes in the area of the law. As anyone who's been a manager knows, you only get that title with the accompanying caveat of a greater legal responsibility (and liability) should something go wrong within your work environment. For example, managers who allow a poisoned work environment to form around them, regardless of whether they actually contributed to it or even condoned it, can be held every bit as accountable for what happens within it (sexual harassment, violence, racism, etc) as the perpetrators of those acts. That's a very high standard, and it can be quite intimidating to learn that you're suddenly in that position upon promotion. Talk about a "good news, bad news" scenario!

But it works that way because the bar is higher. Pay scales are generally elevated, you're going to influence more people simply by virtue of your title and position, and expectations around your behaviour and composure are going to be greater. Those are all part and parcel of the package that comes with moving up that rung of the organizational ladder.

With that in mind, it's apparent to me that when things go awry, it's always going to be the higher-ups who must assume the lion's share of the blame. That may be perceived by some as being every bit as "unfair" as the example above within a poisoned work space, but it's also every bit as appropriate, as far as I'm concerned. In fact, it's something of a telling trait (to me, anyway) when a person in a leadership role complains about the seeming inequity of it. The best leaders understand that it comes with the job, I think, and they don't waste time talking about how "there's plenty of blame to go around." Instead, they accept that all problems are theirs to address (directly or indirectly) and a failure by anyone below them on the org chart is still a failure on their part. It can be a bitter pill to swallow - and I say that from experience - but it's also a component of what separates great leadership from those of us who just hold the title and collect the big paycheques.

Bringing this back to U.S. politics, my take so far on Barack Obama is that he is, and will continue to be, a leader who sees the futility of the Blame Game and knows that the buck will always stop with him. I think he'll spread credit for successes around liberally (another great leadership trait), but will conversely accept the blame for the failures himself... at least, I hope that he will!

Learning From Mistakes

2009-01-12T16:44:00.000-08:00

In my experience, most people seem reasonably capable of learning from their own mistakes, although a select few of them are doomed to keep repeating the same errors in judgment, over and over, while optimistically expecting different results each time. Someone who falls off a bicycle and scrapes a good patch of skin off their forehead just might be more inclined to start wearing a helmet on subsequent trips; a person who fails to file their income tax on time and ends up forking over a big late penalty as a result is more likely to make an effort in the future to get that annual task done earlier. I suppose, in a way, those sorts of events are just more sophisticated versions of the scenario in which a small child reaches out and touches a hot stove element (despite parental instruction against it). Put simply: pain can be an excellent teacher!

But I wonder just how well most of us do at learning from others' mistakes? In that case, the pain part of the equation is either removed entirely, or at least dulled considerably. For example, would the story of a friend being pulled over and charged for drunk driving have enough of an impact to make me adapt my own behaviour around that sort of thing? (I don't drink, so this one's purely hypothetical!) As someone who simply hears about this incident, I don't actually experience any hardship myself, but can I still learn from what happened to my buddy?

Thinking back on my experiences as Agile Manager, I worry about just how difficult it is for one Agile team to learn from the mistakes (or successes, for that matter) of other teams. There's an obvious driver for wanting that sort of thing to happen: what organization would prefer to incur the cost of several teams all skipping merrily down the same garden path that leads to nowhere (for example)? By the same token, if a team tried a variety of approaches to solving a particular problem, many of which were deemed utter failures, before finally arriving at what they found to be a very viable solution, isn't it better for everyone if that eventual panacea is shared with all, and as soon as possible?

One of the hurdles that may get in the way of such a happy outcome, of course, is that one group of people may not accept another group's solution, for any number of reasons: ego, a "not invented here" mentality, an incomplete understanding of the problem and/or solution, an ignorance around how the lesson actually developed, or simply personal preference ("We just don't like that approach"). As Agile Manager, I saw abundant examples of each of those in action.

But even worse than lack of acceptance was the lack of communication. In many cases, each team simply had no insight into what their counterparts were learning, and therefore didn't even have the opportunity to benefit from or reject the revelations happening elsewhere. Various attempts were made to remedy this, including holding "Scrum of Scrum" type meetings, using the Product Development Leaders in that capacity, and even having AgileMan blog about whatever he discovered teams trying in his travels. I wouldn't say that any of those worked especially well, though, as our largely-stovepiped Feature Teams / Product Development Teams proved. As such, I have no magic recipe for how to fix this.

What I do know, though, is that there's a hierarchy in life where learning from mistakes is concerned, and it goes something like this:

Top rung: Learn from mistakes around you, whether yours or others'
Middle rung: Learn from your own mistakes
Bottom rung: Never learn from mistakes

We're a species who attained our current "top of the food chain" status thanks to our opposable thumbs and all of the nifty tricks that we discovered we could do with them. Adaptation is what's gotten us where we are, and it's just as much of a game-changer now as it's ever been. And that means that how high you climb, as an Agile practitioner or even just as a human being, depends on how willing you are to inspect and adapt at every opportunity. And that's no mean feat!

Competence And Confidence Go Hand In Hand

2009-01-10T07:23:00.000-08:00

Following up on my last post, I saw this great commentary about the relationship between competence and confidence in a recent Time magazine article. The piece is about Obama's plans for what to focus on first when he takes over as President of the United States. This particular paragraph falls in the middle of a section about the dire straits within the financial market right now, and what the new President will need to do in order to right the ship:

"Just like its banks and its carmakers, America's shattered confidence is in serious need of a bailout. And the thing about competence is that it nourishes fresh confidence. 'Yes, we can' is both an affirmation of optimism and the essential claim of the competent. When the slogan is rooted in a record of accomplishment - when tomorrow's yes-we-can is backed up by yesterday's yes-we-did - confidence and competence begin to feed on each other. This virtuous cycle of possibility isn't the whole of leadership, but it is an important part and perhaps the element most needed in today's sea of troubles."
- David Von Drehle, "Why History Can't Wait", Time magazine, Dec 29/08 - Jan 5/09

I think that's a very key perspective on leadership, and one that I wholly subscribe to. Nothing rattles the confidence of people quite like the fear that their leaders aren't up to the job. George W. Bush's record, especially over the past couple of years, illustrates that point painfully well.

For anyone in a leadership position today, my advice (for whatever it may be worth) is this: Establish a record of saying what you're going to do and then doing what you say. In other words, as the preceding article put it so eloquently, work hard to ensure that tomorrow's yes-we-can rah-rah speech is in fact given some weight by yesterday's yes-we-did track record. That simple feedback mechanism, implemented in the form of weekly updates, All-Hands meetings, newsletters or whatever, will build up so much confidence among those whose fortunes you're in charge of, that you'll soon find that they'll follow you wherever you lead. Failure to do so, on the other hand, as we've all observed so many times in our travels, will lead to situations like we have in the U.S. financial sector at the moment.

Competent, Not Complacent

2009-01-08T19:04:00.000-08:00

Of all the controversial bits that I wove into the fabric of my two AgileMan books, it's probably true that nothing else was as likely to fan the flames of disgust - in certain quarters, at least - as my none-too-subtle questioning of the competence of some of those among our leadership group (myself, included, at times). It's not at all surprising that unflattering categorizations such as "borderline incompetent" would upset some, as they in fact did. Frankly, similar views expressed on my work blog (at the time) received the exact same chilly welcome, and that eventually led to me shutting down that particular avenue of communication (as described in More Real-Life Adventures of AgileMan, Issue # 45, Can We Not Talk?).

It was with great interest, then, that I read the following section in Barack Obama's book, The Audacity of Hope:

"[I value] competence. Nothing brightens my day more than dealing with somebody, anybody, who takes pride in their work or goes the extra mile - an accountant, a plumber, a three-star general, the person on the other end of the phone who actually seems to want to solve your problem. My encounters with such competence seem more sporadic lately; I seem to spend more time looking for somebody in the store to help me or waiting for the deliveryman to show up. Other people must notice this; it makes us all cranky, and those of us in government, no less than in business, ignore such perceptions at their own peril."

Now, I'd never be so pretentious as to compare myself to President-Elect Obama. After all, he's a great man who's overcome incredible odds to reach the highest office in the most powerful nation on Earth (and is the author of a couple of best sellers), while I'm an unemployed schmuck who was unable to get Agile successfully implemented into a mid-sized company (and had to self-publish his two books about the experience). And yet... if nothing else, we two have in common, apparently, a dissatisfaction with the laissez-faire attitude toward incompetence that others seem to exude when they encounter it.

Beyond that, much of what Obama writes about in his second book revolves around the notion that even unwelcome viewpoints should be discussable in our society. In his context, that can mean Democrats and Republicans being ready, willing and able to sit across the table from each other and talk productively about hot-button topics like abortion, regulation and health care without either side shouting down the other or shoving their fingers in their ears. I suspect that Mr Obama is the sort of man I'd enjoy working for or with, although I have my doubts as to just how well I'd live up to his obviously-high standards. At the very least, though, I doubt that he'd adopt a stance of "I agree with what you're saying but just don't think you should be saying it" as I experienced (on a few occasions) during my time as Agile Manager.

I also agree with the "ignore such perceptions [of incompetence] at [your] own peril" sentiments with which Obama closes that section. That head-in-the-sand attitude was clearly an issue in my former workplace at times, and continues to contribute to morale problems there even now (despite the most obnoxious voice of dissent - mine! - removing itself from the mix). Just as children naturally expect their own parents to be perfect authority figures, most people in subordinate roles desire to be led by not just competent, but hopefully "superior" individuals (in terms of skills such as decision-making, job knowledge, reliability, trustworthiness, etc), safe in the knowledge that everyone involved is doing their part (or more) to ensure success. Great leadership inspires everyone around it; anything less has the opposite effect, unfortunately.

The further I get into The Audacity of Hope, the more impressed I am with the character of its author and the leadership qualities that he embodies.

Getting What You Asked For

2009-01-04T11:55:00.000-08:00

Sometimes I draw inspiration from the strangest of places!

In this instance, it was reading about how some well-intended school testing backfired on those who'd introduced it. In their fascinating book, Freakonomics, economists Steven D. Levitt and Stephen Dubner describe the results of some deep analysis that was done on 3rd to 7th grade testing within the Chicago Public School system around the end of the 20th century. Even prior to President Bush's No Child Left Behind initiative, the CPS had instigated city-wide testing in order to ferret out the lowest-performing schools. The worst offenders faced suspension or even closure, and individual teachers could see rewards and punishment ranging anywhere from promotions to demotions or even job termination as a result of how their students did. All of which makes for a very interesting incentive scenario, indeed!

Levitt and Dubner make a good case for how such a setup can often cause the exact opposite effect compared to what had been intended. I'd written of something similar in the 1st AgileMan book (Issue # 22, Who's Measuring What Now?), where Call Centre agents were graded by how quickly they got through each call... thereby encouraging some of them to hang up on the callers! In the case of the Chicago Public Schools, what a certain (non-trivial) percentage of the Chicago teachers did as a result of the new standardized testing wasn't any more surprising: they cheated!

Specifically, these counter-incented instructors found ways to make their classes' results better than they should have been. That included prepping their classes exclusively for what would be on the tests, giving them extra time, helping them figure out the right responses during the tests, or even changing the results on individual student's answer sheets! Freakonomics provides a highly entertaining recounting of how the cheating teachers were found out (hint: it involved some awesome data-mining!) but what's relevant here is the lesson that can be learned about how you really do need to align your incentives (positive or negative) with your over-arching goals.

The school testing was put in place to improve the education system in Chicago, but because it was implemented in a less-than-perfect way, many of Chicago's elementary school teachers were being encouraged to behave in a manner that actually made things worse! Not only were some of the struggling students, teachers and schools not being identified (thanks to the cheating), but it was also bringing out the worst tendencies in many of the people charged with molding the next generation of Chicago-ites. Just imagine what students learn while watching their role model cheat on their behalf on a city-wide test! That's the kind of damage that's hard to undo!

A better incentive plan, I have to assume, would be one where the measurement is both better-monitored (in order to reduce the opportunity for cheating) and more targeted toward helping, rather than punishing, those found wanting (thereby removing the motivation to cheat). Of course, it's always easier to "Monday morning quarterback" other peoples' mistakes than it is to get it right yourself!

Trust Isn't An Option... It's The Only Option!

2009-01-02T10:50:00.000-08:00

I was reading an article on the woes of "The Detroit Three" (automakers) this afternoon, and came across this fascinating bit about the New United Motor Manufacturing Inc (NUMMI) plant that was a joint venture between GM and Toyota, starting in 1984:

"The plant had [previously] been one of GM's worst; the Toyota system made it one of GM's best.

Detroiters made the pilgrimage... en masse to see the miracle of NUMMI. Some dismissed what should have become a model for the entire industry. True, the technology wasn't that innovative. But Toyota made the workforce integral to improving the system. Workers were not mere labor inputs. GM had no problem understanding the just-in-time inventory system Toyota used, but executing it required a buy-in from the shop floor so that everyone was dedicated to improvement. The Toyota system, says John MacDuffie, a manufacturing expert at Pennsylvania's Wharton School of Business, 'relies on contributions from employees. It feels vulnerable, but your willingness to be open to that vulnerability is what helps you make it work.' In the 1980s and part of the 90s, the top-down culture of the Big Three could not absorb that kind of deep trust."
- Bill Saporito, "Is This Detroit's Last Winter?", Time magazine, Dec 15/08

Those who've read the 2nd AgileMan book, especially Issue # 46, Who Do You Trust?, will perhaps recognize that the preceding description bears at least some similarity to what I observed in my role as Agile Manager. Lean manufacturing (as Toyota created and mastered), like Agile software development, requires that a greater degree of trust be extended to the "rank and file" than many traditional management types are ready, willing or able to accomplish. It sounds like the Big Three suffered from that, and I certainly saw lots of evidence of the same issue in the workplace over the last several years.

So just how can you place trust in the employee base and be comfortable in doing so? Well, we didn't pull it off all that successfully, but I still believe I learned a thing or two along the way. Here's what I think it takes on the part of those in charge:

Clearly communicate what's expected of those you're entrusting. In our software environment, that means telling everyone "the what" and empowering them to come up with "the how". I personally think it's unreasonable (and doomed to failure) to dictate both "the what" and the "by when", but others may disagree with that.
Establish how the results will be measured, make them well known, and then follow through on what you established. Metrics are tricky business (as I wrote about in the 1st AgileMan book), but just because they're hard to do right doesn't mean that you get off the hook for producing them! The temptation to shift around the measurements as time goes by is often very strong, but also completely unfair to the people whose hard work is being evaluated. The onus is ultimately on management to set the yardsticks and then to live by them. Failure to do so causes the staff to believe that you're changing the rules as you go... because you are!
Treat the inevitable failures that will occur as opportunities for learning. This is another tough pill to swallow, because those who live by the Blame Game rules (and who have long since mastered "Cover Your Ass" as an integral skillset) will find it difficult to re-wire their brains to this new way of thinking. Finger-pointing and general CYA attitudes, however, do more to erode trust than just about anything else you can throw into the mix.
Celebrate successes, large and small. This was perhaps the biggest disappointment for me in my previous job: the focus always seemed to be on what had gone wrong, rather than on what had gone right. If one Feature Team did really well, management would only want to talk about the ones who were still struggling. If a team got their bug count significantly reduced, the focus would go on to how "late" their new features were. Despite providing hundreds of features in our first 2 years of Agile, I repeatedly heard executives say, "We haven't delivered a single thing since we started Agile!" That sort of skewed perspective is certainly not a good way to build trust between the layers of the company!

If you can pull those four areas off, you'll probably do very well in creating an empowered, high-performing environment in which everyone will succeed. If, on the other hand, you regard trust as an optional add-on, like power windows or leather seats, then you'll probably be sorely disappointed in the results you get each time you "cheap-out" in that regard.

Happy Holidays From AgileMan

2008-12-29T14:01:00.001-08:00

Here's hoping everyone is enjoying a wonderful break right now before launching into another exciting year... I certainly am!

Not All Change Is Good Change

2008-12-23T15:29:00.000-08:00

Ever since taking on the Agile Manager role two and a half years ago, I've become much more cognizant of examples of adaptation occurring around me than I ever had been before. I see it lots of places, from online surveys that I receive (and am more inclined to fill out than I had been in the past) to friends imparting insight that they've gleaned from training of one sort or another. I stepped into this whole AgileMan gig several years ago as someone who was traditionally very resistant to change - and wasn't afraid to admit it! - but what I've come to realize since then is that I'm really only opposed to bad change. So what do I mean by that?

I think there are several types of bad change, and looking at a couple of them even briefly as I'll do in this post will undoubtedly shed some light on some of what can make change a more positive experience. One obvious example of the wrong sort that comes to mind is "change for change's sake." This might come in a case where someone (or some group) is unhappy with the way things are but won't spend the time or energy to figure out why. I had one friend, many years ago, who left a job because he didn't think that it was fulfilling enough for him. When I asked him what specifically had been missing, he couldn't actually come up with anything concrete ("It's just a feeling"). The job that he moved to, however, turned out to be even worse than what he'd given up. Before long he became extremely nostalgic about the old job, and subsequently did everything that he could think of to try to get it back. When he failed in that attempt, his misery just intensified. From what I could tell, he had made a change without having any real idea what the driving force behind it was, and ended up quite unhappy as a result.

Another type of bad change is "throw away whatever I don't know and replace it with what I do know", which is really an anti-change for the person driving it. This can often exhibit itself in the form of a management type who either wants to make his mark on an organization or only knows one way to work, for example. Often such an individual will therefore rush to sweep out whatever "the last guy" implemented in order to either avoid having to learn the old system or just to re-shape it into something he's more familiar and comfortable with (or maybe both). While such a change may ultimately prove to be the right move for the organization, it's a poor approach to take for several reasons. For one, you end up throwing out the baby with the bath water, since you have no idea what working processes may get kiboshed in the process. For another, you run the risk of alienating those in the organization who liked or even believed in the old way of doing business, without first giving them a chance to draw attention to the working bits.

A common thread between both of those preceding examples is lack of data. And that's really what's often missing when the wrong kind of change is introduced. There's the data about what's currently going right and what isn't, and there's also gold to be mined as far as what effect any change you introduce is actually having. "Adaptation", as distinct from the more general purpose "change", requires that there be a feedback mechanism in place to provide that data and allow those involved to evaluate and respond to it. There's an old joke about a guy going to a doctor and saying, "Doc, it hurts when I go like this" (waving his arms up and down like a chicken)... to which the medical expert wisely replies, "So don't go like that!" The patient wasn't adapting to the data that he was receiving (pain while doing something silly), but doctors are all about paying attention to data. They listen to what the patient says, to what the patient's medical and family history tells them, and what various test results indicate... and then they respond accordingly. Smart, adaptive patients follow their doctors' directions on matters of health; the rest of the population keeps smoking/drinking/not exercising with no regard to what the effects might be, and then get eulogies that speak of how their lives were cut unfairly short.

As I said at the start of this, I've been seeing bits of adaptation almost everywhere I look now, and I think that's a very good thing.

In The Black

2008-12-15T18:17:00.000-08:00

That's right! Thanks to the kindness and generosity of our many readers, the two-pronged publishing project that included More Real-Life Adventures of AgileMan (Year 2: Easier Said Than Done) and The Complete Real-Life Adventures of AgileMan (Two Years of Lessons Learned in Going Agile) has now achieved profitability! It took a few months for that milestone to arrive for the first AgileMan book, but less than a week this time around (the difference that not providing a couple dozen comp copies can make!). And I'm not counting the 8 copies that were pre-ordered but not distributed/paid for yet, which means that I'll soon have taken enough in to pay for another (smaller) print-run if there's ever enough demand for it.

Many thanks to all who've purchased either book, and especially to Jamie who bought four copies to give away (once again)!

The Leadership Game

2008-12-06T18:00:00.000-08:00

One of the concepts that I first came across when I began reading up on Agile (waaay back toward the end of 2005) was that of servant leadership. There's a nice Wikipedia entry for it here, in case you want to know more about its origins and interpretations.

While I served as Agile Manager for two years, I tried to embody the notion of servant leadership, with admittedly mixed results. In my first tenure as a Feature Lead (in those initial month-long Iterations with the group that I nicknamed the "B-Team" in my books), I tried to drive home the point that, even though I was an Engineering Manager, I wasn't there to tell them what to do. I was there, instead, to help them succeed. My job was to serve their needs in the best way that I could. Similarly, in some of my other roles during that period, I tried hard to reinforce that same message. Not everyone bought into that kooky approach, though, with some still preferring to defer to me at the drop of a hat. As well, some of my fellow management brethren believed that a heavier (or perhaps, just steadier) hand was required on the steering wheel and thus found fault with my style.

I suspect that such reactions may have stemmed from the fact that some of those same leaders weren't ready themselves to do much more than perhaps pay a bit of lip service to the cause of "leading by serving." Thinking back on it now, I can come up with several different reasons why that might have been so, which would likely vary by individual:

Sometimes egos are just too large to allow a person to think of himself or herself as "serving others" as a member of management. If you're career-oriented, after all, you probably worked hard to achieve that lofty position, and so why would you lower yourself (back down) to the point where your success could be measured in terms of how much you help others succeed?
Some people, sadly, have little or no natural ability to influence and thus their leadership style is strictly Command-and-Control because nothing else ever works for them! In that situation, relinquishing some degree of decision-making onto subordinates and then filling your time supporting them in their efforts would be frightening, at best, and incomprehensible, at worst.
Along the same lines, I think that a few of the managers and executives quite simply don't trust those below them on the org chart. How can you commit yourself to the service of others if you suspect that they're incompetent, unmotivated or just plain lazy? Believing in people often requires a huge leap of faith, and I'm not sure that all of my peers and superiors have been willing to take it.

There were other factors at play, as well, I'm sure. But when I conjure up images of some of the "worst offenders" (as measured against this particular leadership bar, that is), those reasons above seem to be the most common.

Something I read recently talked about how important humility is in a great leader, and I think that fits perfectly with servant leadership. Being humble often gets a bad rap... Clark Kent, after all, is described as "mild-mannered" but most of the time that's used as a knock against him. "Why can't you be pushier, like Lane is?" editor Perry White would demand of him. "Nice guys finish last, and don't get the by-line!" I happen to believe that humility's a virtue, because (among other things) it tends to keep your eyes and ears open a lot more than arrogance or even pride ever does. If you accept that you can always do better, for example, then it's more likely that you just might! On other hand, if you're already convinced of your own greatness, there's really nowhere to go (but down).

So if I were building up a new team of leaders today, I'd be looking for at least some healthy amount of humility in each selection. When I took part in the task of finding several new Product Development Leaders (Agile Coaches) for our company earlier this year, I certainly factored that into the search criteria that we used. Anyone exuding a sense of born leadership, for example, was facing an uphill climb, as that attitude seems to suggest that there isn't much to learn in becoming an effective leader (with which, I must most humbly disagree). If a person came across as looking to finally get their chance to wield some power over the folks who were always disagreeing with them, I'm afraid they were similarly at a disadvantage. While some degree of self-confidence is obviously required to lead, we also recognized the need for a healthy dollop of modesty in our candidates, and I think the ones who eventually made the grade all demonstrated it. If all of the current leadership had been screened with an eye toward that attribute, we might have actually fared better in our Agile journey... although that's certainly open to debate. A better Agile Manager would've similarly helped, but we didn't get that, either.

With the U.S. election just barely a month behind us now and a new President-elect in the process of transitioning into power during a frightening economic meltdown, the word "leadership" is getting a lot of play in the media at the moment. I suspect that Barack Obama is the type of man who understands the job in front of him, and gets that the only chance he has of success involves him inspiring great things in others. He comes across as someone who has a vision of how to turn his country around, especially in terms of how to take it into the 21st century (after his predecessor tried hard to send it back to the 19th). Because of the office he's assuming, he'll naturally make many decisions and give lots of orders; but his greatest achievement, if I'm right, will come from empowering not just his cabinet and fellow politicians but also the American people in general. He's smart enough to realize that he can't possibly fix all of his country's problems alone, and so part of his job will be to remove obstacles and thereby enable several million other people to contribute to the solutions. I wouldn't be at all surprised if he ends up providing a model of servant leadership that we all could learn from.

If you're currently in a leadership role (at work or elsewhere), it wouldn't be the worst thing you could do to stop, take a moment, and consider: what am I doing that's actually in the service of those "below" me? If you have a tough time coming up with a very big list, then maybe it's time to shake things up a bit and see what happens!

The Books Are On Their Way!

2008-12-04T18:27:00.000-08:00

I just received e-mail notification from Lulu that the initial print-run of More Real-Life Adventures of AgileMan (Year 2: Easier Said Than Done) and The Complete Real-Life Adventures of AgileMan (Two Years of Lessons Learned in Going Agile) has been completed and several dozen copies are now winging their way here! It's always a bit tricky guessing exactly when they'll arrive, but I'd say Monday or Tuesday of next week looks promising.

If so, I should be able to get books out to my former co-worker buddies who pre-ordered sometime later next week, which would be excellent (several weeks earlier than I had planned). I still need to figure out how to accomplish that mass distribution (and currency collection), but now that it's starting to seem real, I'll put more thought into it!

Another publishing cycle nears its exciting conclusion...

Book Publishing Running Ahead Of Schedule

2008-11-29T07:32:00.000-08:00

I was very happy to see this week that Lulu, where I print my AgileMan books, was able to produce and deliver the print drafts of More Real-Life Adventures of AgileMan (Year 2: Easier Said Than Done) and The Complete Real-Life Adventures of AgileMan (Two Years of Lessons Learned in Going Agile) in less than a week! I ordered them Sunday afternoon and they arrived the following Friday! That's quite impressive and in fact exceeded my expectations by about 50%. (That's the good news; the bad news is that even their cheapest shipping option is now more expensive than it used to be, meaning that they've already started eating into my profit margin before I even sell the first copy!)

After Vicki and I checked over what had arrived, I made a few minor tweaks and then placed an order large enough to cover all of the requests that have come in to-date plus a handful of extra copies of each book. Based on the estimate provided by Lulu on the order, I would think that they might arrive sometime during the week of Dec 15th, or possibly earlier if I get really lucky. It's hard to predict just how much things will slow down in December because of holiday-related activity, though. It's still possible that the books won't arrive until after Christmas, which would be more in line with what I imagined when I planned out the self-publishing schedule leading up to this.

In any event, we're on the last leg of the journey for the 2nd AgileMan book, and those of you out there who are eagerly awaiting it (c'mon! stand up and be recognized, both of you!!) should know that it won't be much longer before you have it in your hot little hands. I still have to figure out, logistically, how I'm going to get copies to all of those people at my former workplace (I can't exactly book a meeting room for it, after all!), but I'm sure that we'll figure something out.

New Mike Cohn Agile Book In The Offing

2008-11-27T16:45:00.000-08:00

I stumbled across this link to a website where you can download and preview a few draft chapters from Mike Cohn's upcoming book, Succeeding with Agile. I'm not sure which excites me more: the fact that Mike has a new book coming out, or that he's providing the option for interested parties to preview the work and give feedback on it ahead of publication!

Anyway, I definitely encourage other Agile enthusiasts out there to do what I'm about to: visit the site, check out what Mike has to say and help him make the book even better!

Let History Be Your Guide

2008-11-26T08:39:00.000-08:00

I was asked an interesting question yesterday, thanks to the magic of Instant Messaging. One of my friends at the company that I used to work for (in my capacity as AgileMan) wondered if either my wife or I had ever heard of something called "empirical forecasting." We hadn't, but as he told me more about what he'd been reading (and even shared some of it with me), I realized that it was something that I'd been practicing during the final few months of my employment. It's also a topic that I wrote about briefly in More Real-Life Adventures of AgileMan (Year 2: Easier Said Than Done), although you'll just have to take my word for that until the book actually comes out! I just hadn't had a fancy name for it, until now!

Basically, that style of forecasting or planning involves using the empirical (or observed) data that you have, and only predicting what can be extrapolated from it. In other words, you only expect to get results that match what you've gotten in the past. That may sound obvious to some, but in my former company, it was rarely the way planning occurred. I sat in countless meetings in which statements like the following would be made:

"Our owners need ______ (some set of features) by ______ (some date in the future) so now we need to figure out how to deliver it."

Put another way, we'd start at a desired outcome and try to work our way backwards from it. I completely understand why we always felt that it was necessary to do things that way, but repeated failures of that approach should have incontrovertibly shown the folly of it at some point. Instead, it continued to happen.

What works much better, I believe, is to base your schedules on what has been proven in the past. For example, our development teams each had a certain average velocity (in Story Points) that they'd worked at for the past N Iterations (where N could reasonably be any integer between 3 and 6, let's say). Realistically, if that's what they did in the past, it's likely going to be close to what they'll do in the future. Therefore, you should expect about the same productivity going forward, and anything beyond that is just wishful thinking. If a team has 100 Story Points of work left, for example, and they work at an average velocity of 15 Story Points each Iteration, then you could reasonably assume they'd finish all of the features in roughly 7 more Iterations, with the caveat that the "remaining work" doesn't change dramatically in the meantime. What would happen all too often in my former workplace were frantic meetings in which endless discussion would ensue as to how to shorten that timeframe down to 3 or 4 Iterations. In the end, of course, it would still take 7 Iterations, or even possibly longer, if enough churn had happened in the process such that it actually made additional work for those involved!

In my conversation yesterday, the other person even talked about using simple line graphs to predict when the work remaining would hit zero, including accounting for features that have been added or removed. I think that sort of graphical representation can certainly help in such matters, as some people relate better to pictures than to words. In either case, though, your expectations are limited to an extrapolation of what's already happened, rather than relying on the time-honoured "... and then a miracle occurs" (as we all used to fall back on for those impossibly-hard university math exam proofs!).

In order to use this sort of technique, of course, you need development teams that can become fairly good at providing relative estimates (such as Story Points). That's no easy challenge, but it's also a big enough topic to warrant a separate blog post, and so I won't tackle it here!

2nd AgileMan Book Nearing Completion

2008-11-22T09:02:00.000-08:00

I'm now into the home stretch on More Real-Life Adventures of AgileMan (Year 2: Easier Said Than Done), as I'm about to embark on a final read-through before beginning the self-publishing process. I'm still awaiting feedback from one of my reviewers, but that seems to be par for the course in this sort of arrangement (the same thing happened with the first book, even though the set of reviewers this time is completely different). Depending upon when it arrives, this final array of comments may - or may not! - end up being reflected in the finished product. As tempting as it might be to hold things up and wait, I'm keenly aware (after 22 years of doing various types of projects) that it could end up being a long delay. So onward and upward we go!

Vicki and I spent some time toward the end of the week (after we'd concluded our Project Management guest lectures) designing the covers for the 2nd book and the collected edition. The former will use a standard Lulu cover image, just like the 1st AgileMan book did, but I'm doing something special for The Complete Real-Life Adventures of AgileMan (Two Years of Lessons Learned in Going Agile). And yes, that means I finally decided on a name for the collection! I've had 5 pre-orders placed for the bigger volume so far, and I think those generous souls will be amused, and maybe even pleased, to see what their book's cover looks like! I still have one more extra in mind for that edition that I'll probably take care of tomorrow.

If things go well this weekend, I hope to be placing an order for one copy of each of the two new books sometime very early in the week. With the American Thanksgiving holiday looming on the horizon, I imagine it may take more than the (now) standard two-week turnaround to get them, but I'll optimistically say that we might have the first proof copies in hand toward the end of the week of December 8th. If so, that would work out well for having the first big shipment arrive in time for early January distribution (an even luckier outcome would have the books show up before Christmas, but I don't see that as likely at this point).

Project Management In An Agile Environment

2008-11-20T13:54:00.000-08:00

Last night, my wife Vicki and I traveled to our local university where we'd been invited to provide guest lectures to an evening class made up of third year Computer Science students, all of whom are enrolled in a course on Project Management.

Vicki wanted to go first, and so she took up the first forty-five minutes (of a 3-hour class) describing several of the jobs that she's had over the years that didn't, at first glance, appear to be related to Project Management... and yet were! The overall message of her talk was that there are more types of PM jobs out there than you might think, and the students seemed both interested and encouraged to hear that viewpoint! Although she was nervous going in, you'd never have known it to watch her... and she's now much more confident of her own ability to present on that topic.

My portion of the proceedings ended up taking close to 2 hours, in part because I had more material to cover (more on that in a moment) but also because I got asked a lot of questions! Although a handful of the inquiries were slightly skeptical in nature ("Could you really get a customer to approve spending money if you're not promising to deliver on time?"), most were more obviously related to them beginning to connect the dots. Which leads nicely into what my talk was on.

I broke it into 2 parts: What is Agile?, and What do PMs do in an Agile world? Because I had to assume that they had no knowledge of Agile prior to this (which turned out to be mostly accurate), it seemed critical to me when I was planning my lecture to give them a sufficient grounding in it before moving on to the Project Management angle. Based on how things proceeded, I'd say that was a wise choice.

Because it was a PM course, and I'd taken a look at their curriculum online, I decided that it was appropriate to frame Agile within the context of how common it is (and has been, for decades) for software projects to fail... a topic that I knew they were well familiar with. I provided some ideas of my own as to why the failure rate has always been so high, and then showed how - if done properly - Agile might address some of those factors. An actual PM from my former job was in the audience, and was nice enough to offer up some good observations to the class about areas where Agile had actually helped.

Before I moved into the second half of the material, I decided to get everyone up off their butts in a goofy little move where I had them stand up and give me an enthusiastic "but but but" as I launched into some of the more obvious reasons why Agile, as I'd described it up to that point, might seem like pure poison to a group of project management enthusiasts. You never know how that sort of thing is going to fly, but at least they played along and it kept them having to sit still for the entirety of the 2 hours!

I had 8 aspects of Project Management that I discussed, in turn, showing how a PM would add value in an Agile organization while doing the role in a manner different than what they might expect:

Requirements Gathering
Task Estimation and Tracking
Project Planning
Personnel "Management"
Quality Assurance
Customer Relations
Status Reporting & Milestones
Scope Management

Each of these prompted questions from the students, none of which were silly or indicative that they didn't understand the subject matter. They were simply absorbing it all, quite quickly, and beginning to draw conclusions or anticipate problems. Fielding all of their questions, including several by the course instructor himself, was definitely the most challenging part of the evening for me. That also, of course, made it the most rewarding!

Both of our presentations appeared to go over very well, and we came away feeling as if we'd done a good job. Those of you who know people in the course are free to seek out differing opinions, though!

A Few Updates On The 2nd AgileMan Book

2008-11-10T16:11:00.000-08:00

I've begun soliciting pre-orders for More Real-Life Adventures of AgileMan (Year 2: Easier Said Than Done), starting with the list of people who bought or expressed interest in the 1st book. I've had nearly 20 positive responses so far and that's an encouraging result after just a couple of days!

Since I've decided to produce a collected edition of the two books, I'm also looking for pre-orders on that (I have 2 so far!). I've been working on the bonus material for it recently, making sure that anyone who buys the collection gets a little bit of extra, fun stuff beyond what's in the two regular editions. I'm still noodling over the sub-title for that book, to go along with The Complete Real-Life Adventures of AgileMan. Ideas I've had so far include:

(Two Years of Going Agile)
(Two Years of Lessons Learned)
(Two Years of Agile Lessons Learned)

Anyone out there have any better suggestions?

The online prices at Lulu.com will be slightly higher than what I'm about to quote, but for in-person sales I'm expecting to charge $30 for the 2nd book and $45 for the collected edition (the latter of which is compared to $25 and $30, or $55 total, for the 2 books individually). For anyone in my neck of the woods who'd like to get a copy from the author himself on Launch Day (sometime in January 2009), please let me know now so that I can be sure to print enough copies!

While the actual writing of the books could at least conceivably be considered "work," I have to say that doing the various extras for them comes almost entirely under the category of "fun!" I had a great time dreaming up the comic strip captions that I used in The Real-Life Adventures of AgileMan (Lessons Learned in Going Agile), not to mention the minor thrill that I felt in creating the artwork in the first place! While I don't want to give too much away ahead of Launch Day '09, I will say that I'm having every bit as much fun this time around! I also tended to laugh out loud quite a bit as I came up with the contents of "AgileBoy's Glossary of Terms" for the 1st book, and I have an idea for something similar to use in the 2nd one. I really enjoy flexing my creative muscles on things like that, and if the people who buy the books get a kick out of them - as a few readers have told me they did - then all the better!

As for timing, the reviewers have until Nov 21st to get me their feedback (some of which has already come in) and then I hope to be starting the printing/publishing process shortly thereafter. I might manage to have the first print draft in my hands as early as the first week of December, if all of the stars line up and nothing goes wrong (I know: what are the chances?)

And that's where things stand today.

One Lecture Down, One To Go

2008-11-06T14:50:00.001-08:00

So I gave my first of two November Agile-related university lectures today. This was for a 2nd year Computer Science class (I'd mistakenly thought it was a 1st year course but was happy to learn my mistake!) and the goal of the presentation was to introduce about 20 - 30 young minds to the notion of doing development in an Agile organization.

In the fifty minutes that I had available to me, I covered the following:

Why do most software projects fail?
Where did Agile come from?
How are the Agile methodologies different than traditional (Waterfall) ones philosophically?
How do Agile and Waterfall contrast each other more specifically?
What does life in an Agile environment look like?
Where might Waterfall be better, and where would Agile be more appropriate?

I was pleasantly surprised by how interested almost all of the students were in what I had to say, and I got a lot more questions at the end than I'd gotten the last time I did this dog-and-pony show. I asked how many of them think that, when they've graduated and are out in the work force, they'd enjoy working in an Agile company. As far as I could see, they were all nodding in response to that question (nodding in agreement, that is... not nodding off)!

I also put a push in for my former employer, telling them that they should all apply there when they graduate, if they want to stay and work in the same city where they attended university.

All in all, it was a very enjoyable and rewarding hour for me.

Information Radiators: Could They Help Save The World?

2008-10-31T12:41:00.000-07:00

As I was riding my bicycle today (in 17 degrees Celsius weather, despite there being snow on the ground... in October!), I had a thought:

What if the most important metrics around Climate Change were in everybody's face on a daily basis, like gas prices are (just to use one example that I notice most people around me talk about all the time)?

To see what I mean, consider the following hypothetical (and possibly impractical) scenario. Imagine that the current level of carbon dioxide in our atmosphere (one of the many worrisome statistics that get bandied about in most environmental discussions these days) was being measured every day, and today's value showed up wherever you went. You start up a browser... there it is, up in the corner. You turn on your TV... each network displays it, translucently, like they do their logo or call sign. You go out shopping... and it's on the ever present LED displays, along with notices of sales and special discounts. In other words, it becomes as commonly-known to the general public as the price of gas, thanks to the use of an Information Radiator model.

If that were to come true, would people be more likely to not only change their own way of living but also make more of a point to push their elected officials to make systemic changes at the municipal, state/provincial and national levels? I don't know the answer, but it struck me as interesting thought.

Agile On Campus

2008-10-30T14:56:00.000-07:00

While I continue to try to find some time to put material here relating to either of my two AgileMan books, I thought I should mention that I've now firmed up two November university lecture dates.

I'll be talking to a first year Computer Science class next week as I try to provide them with a very high level introduction to Agile. Then two weeks later my wife Vicki and I are taking on a third year Project Management CS class for an evening. She's going to cover some of the ways that project management shows up in areas other than software development, and I'm going to present some of the PM challenges that can come along in an Agile environment.

While it doesn't pay a lot (or anything), it's still fun to get out there and sing the praises (and lament the pitfalls) of Agile with a bunch of hungry young minds.

Welcome!

2008-10-19T12:36:00.000-07:00

This is a new blog, called The Real-Life Adventures of AgileMan, which I hope to use in promoting and discussing my two AgileMan books. You can see the front cover of the first book along the right side of this blog, and you can click on that image if you'd like to read a preview of it or even order a copy from Lulu (for a mere $27.50 plus shipping).