The Power of Planning Ahead

Posted on December 7, 2010 by John

Why do things go wrong? Is it inevitable? To some degree it is, but I think the likelihood, frequency, severity and impact of adverse events can be minimized by several key practices, one of which is planning ahead.

What if you only bothered to look a short distance ahead, say 10 or even 100 feet, while driving your car? Possible ramifications:

  • You might be afraid to drive fast, thus it would take you a long time to reach your destination, and all other drivers would get there long before you.
  • You might decide to drive fast anyway, but would likely crash into something very soon because you will not be able to react in time.
  • You might end up on the wrong road, fail to make a turn, or miss some critical information because much visual information on signs and elsewhere is beyond where you are looking.

Well that was a silly example, but how far ahead do most of us look while we are doing our jobs? There are so many things that can be handled easily today that will become really big and nasty problems – maybe even fatal – if they are put off until “later” or not even considered at all.

So why do we fail to plan ahead so often? The excuses I hear most often are something like: “I’m so busy dealing with all of today’s problems that I don’t have time to think about anything else,” or “If we don’t make it through today, there won’t even be a future to worry about, so I can’t afford any time now.” But people who never make the time to look down the road and start doing work that prepares for the future will be doomed to live in a reactive, fire-fighting world forever.

We live in such a fast-paced culture that it has become strangely unfashionable for most people to be prepared in advance – it’s almost as though taking the time to prepare in advance is evidence that you don’t have enough other work to do. Or it could be laziness.

Our ad-hoc culture is well illustrated by an incident that I witnessed some time ago, in which a person was scheduled to present via Live Meeting to a large internal audience at my company. The presenter joined the meeting 2 minutes late, then kept 115 people (!) waiting for 15 minutes while he fumbled around trying to get his Live Meeting setup working. Now imagine if this one person had planned ahead by anticipating possible problems with Live Meeting and getting it set up in advance – it would have taken 15 minutes of one person’s time instead of 15 minutes of time for each of 116 people.

On a much larger scale, I believe that a lot of the trouble we have on our big projects in development, implementations and upgrades could be reduced or even eliminated by sufficient planning ahead. Even though each project is unique, each instance of the same type of project is substantially similar to its predecessors, and thus we should have to start the learning process from scratch with each one.

Research into traffic safety has found that the safest drivers are those who look furthest down the road, which enables them to develop and maintain the situational awareness necessary for efficient driving and accident avoidance. I think a similar principle applies in technology – or almost any other human endeavor. This is expressed in a number of old sayings which might seem trite today but nevertheless reflects long-standing underlying truths in the human experience:

  • “A stitch in time saves nine.”
  • “A penny of prevention saves a pound of cure.”
  • … and I’m sure there are others.

I’ll leave you with one final thought: Those who consistently fail to plan ahead will consistently have problems.

Next time I will explore some of the other reasons for “Why Things Go Wrong.”

Posted in Execution, Why Things Go Wrong | Leave a comment

A Leadership Philosophy

Posted on January 20, 2010 by John

I think it is critically important for every good leader to have a core set of beliefs about how they go about being a leader – a leadership philosophy.  Having an explicit philosophy provides consistency and purpose to the direction one provides, and helps achieve one’s goals in a way that is understandable to those who benefit from the leadership being provided.  A leader who lacks a leadership philosophy is likely to be inconsistent and arbitrary.

Note that a leadership philosophy is not the same as leadership goals:  Goals generally describe a desired outcome, while a leadership philosophy defines “how” one goes about achieving whatever the current goals are.

Because I have been in management for many years, I have had a lot of opportunity to witness and learn from both good and bad forms of leadership, and had the opportunity to try out various methods and judge their value.

But while I now have a pretty good idea of what I think is right and what isn’t, I have never written my core beliefs down in a concise manner.

Recently I came across an old article entitled Doing a Job: The Management Philosophy of Adm. Hyman G. Rickover that amazed me because it is a pretty accurate statement of what I believe as a leader.

For those of you not familiar with him, Admiral Rickover was known as the “father of the US nuclear navy” and was the driving force behind the creation of the first nuclear submarine as well as the shaper of the subsequent US nuclear navy.

That this article should be such a good statement of leadership philosophy is a bit unexpected:  I would not normally think of anyone in government as a leadership paragon, developing and running nuclear submarines in the Navy is not a typical business undertaking, and something written way back in 1982 might well be considered obsolete today.

But even though it is 28 years later and we are not in the Navy designing and building nuclear submarines, virtually every point in Rickover’s article are relevant to us here today.  In fact, one could substitute a few words here and there and it would address software development exactly.

A few specific points are worth emphasizing:

  • “Human experience shows that people, not organizations or management systems, get things done.”  Which means that focusing on employee development and empowerment is one of the most important things a leader can do.
  • “Every manager has a personal responsibility not only to find problems but to correct them.”
  • “Unless the individual truly responsible can be identified when something goes wrong, no one has really been responsible. With the advent of modern management theories it is becoming common for organizations to deal with problems in a collective manner, by dividing programs into subprograms, with no one left responsible for the entire effort.”  (my favorite comment)
  • “A good manager must have unshakeable determination and tenacity. Deciding what needs to be done is easy, getting it done is more difficult. Good ideas are not adopted automatically. They must be driven into practice with courageous impatience. Once implemented they can be easily overturned or subverted through apathy or lack of follow-up, so a continuous effort is required. Too often, important problems are recognized but no one is willing to sustain the effort needed to solve them.”

And much more.  I don’t necessarily agree with the importance he assigns to written reports, but that might an artifact of this being from 1982 or from a military guy.  Or it might be a good idea that I just haven’t embraced yet.

I also liked the following quote – can you relate this to software development?

When I came to Washington before World War II to head the electrical section of the Bureau of Ships, I found that one man was in charge of design, another of production, a third handled maintenance, while a fourth dealt with fiscal matters. The entire bureau operated that way. It didn’t make sense to me. Design problems showed up in production, production errors showed up in maintenance, and financial matters reached into all areas. I changed the system. I made one man responsible for his entire area of equipment—for design, production, maintenance, and contracting. If anything went wrong, I knew exactly at whom to point. I run my present organization on the same principle.

I understand that Adm. Rickover was a very demanding and difficult person to work for, but he was also someone who expected and obtained an extremely high level of sustained organizational performance.  He did this by having – and consistently executing – a very clear leadership philosophy.

A great example for a leader at any level.  Anchors aweigh!

Posted in Leadership | Leave a comment

Everyone Doing Their Job

Posted on August 26, 2009 by John

If every employee in our company did their job (as defined in their job description, most recent performance doc, or whatever), would that make us successful as a company? Of course it would – well, at least in theory. That’s what job descriptions and performance documents are supposed to do. If you added all of them up across our entire employee population, everything should be covered and everything should work fine.

Well, clearly this isn’t true. There seems to be a gap somewhere.

Here’s an illustration: All of us, at any level in the company, get an annual performance review that results in a numerical rating in the range of 1 – 5, where 3 means you did what was expected of you and a smaller number means that you excelled and went beyond. And larger numbers mean that you were deficient in some way. I can’t and won’t quote any figures, but the vast majority of employees at my company are rated as 3 or better, which means that they have been judged to be fully performing or exceeding their assigned duties. (This strikes me as being a bit like living in Garrison Keillor’s fictional town of Lake Wobegon, where everyone is above average.) I guess it means that we have done a good job of hiring and growing our employees, which is the sign of a good company.

But how does this correlate to company performance? My company is really good at delivering good financial results, so that makes sense. But how are we doing on things like quality and customer satisfaction? We are fortunate to have several products that are highly rated, but we also have a number of products that are on the opposite end of that scale. We know that our overall product quality is far from what it should be, and that we have quite a few customers who are not very happy with us for a number of reasons. So the average of our employees’ rated performance does not correlate to what our customers think of us – thus a gap.

Does this make sense?  What’s wrong?

This happens other places, too.  When Alan Mulally took over as CEO of Ford in September 2006, he held an “ops review” in which managers from each of Ford’s business units presented their progress and status. Each reported a status of “green” meaning that each unit felt that they were meeting their defined goals. Mulally looked at all these good reports and then said “We lost a few billion dollars last year.  Is there anything that’s not going well?” because obviously this didn’t add up.

I’m not sure about Ford, but I think what’s missing in our company is an overarching desire by the collective “us” to see the picture from our customers’ point of view and then to act holistically to ensure that everything we do concentrates on a positive end result. I think we have far too many people who are doing their assigned job – and doing it fairly well – yet it’s not coming together well enough as a team effort.  It’s rather like all the baseball players on the field, each really good at what they do and very skilled in playing their assigned positions, but when the fly ball drops in the infield, each player looks at the others, wondering why someone else didn’t catch the ball that fell into a gap. And although each player is excelling at pitching, catching, hitting, etc, the team is still not winning many games.

How to fix this? It is easy to say that management needs to do something about it. In the case of the baseball team that is not winning, perhaps the coach needs to take some action like shuffling the lineup. But it’s not just up to the coach – or management – to get on a winning track. Each employee – every one of us – has a brain and professional skills that can be applied to making things better. It’s simply not enough for each person to just “play their position” well and not be concerned about the overall outcome. Management provides the direction and coaching, but it’s the players on the field who play the play the game and whose efforts result in a win or loss.

So my point is this: Each one of us needs to be aware of how we are performing as an entire team – are we winning or losing the game – and pitch in. If something is happening near you, don’t just assume that someone else will handle it.  Check to make sure that someone “has the ball” – and that they are doing the right thing with it. And when you have the ball and need to hand it off to someone else (beware of handoffs), make sure that whoever you have given it to is handling it with the same efficiency that you did.

It really doesn’t do much good to have everyone doing their job if we are not winning the game.

Posted in Execution | Leave a comment

Complimentary Power

Posted on August 17, 2009 by John

It has been a few years now since I read First, Break All the Rules, but I remember it as one of those books that made an impression on me when I first read it, so I recently picked it up and skimmed it again. I still find it one of the more enlightening and thought-provoking leadership books that I have read.  I won’t attempt to do a full review here, but want to highlight one key item.

First, Break All The Rules The book was based on extensive research done by the authors based on many years of polling employees and managers to see if they could discover any common themes around what good employees need in the workplace, and what good managers do to provide those things. In the course of their analysis they came up with a dozen questions that highly-engaged employees tended to answer positively while less-engaged employees did not. While drawing any conclusions from statistical correlations is always risky, these results are nevertheless interesting, at least to provide leaders with some points to reflect upon when judging their own leadership style.

The 12 key questions are listed below at the bottom.  Some of them might sound familiar, as we have seen some of them on employee opinion surveys (and I have seen them at other companies as well). But of the 12 questions, there is one that has remained etched in my mind:  #4, which I will paraphrase as “Has someone (preferably your boss and/or someone else above you) complimented you on your work recently?”

I will be the first to admit that as a manager myself, I regularly fail to do this, so I’m making a “note to self” at this very moment!

It is hard to think of any action that is so easy and inexpensive to do, yet that has such a positive impact, as paying someone a compliment that reinforces something they have done well recently. The ROI on this must be near infinity.

As an employee, think of how you feel when your boss tells you how pleased he is with something you did recently. Only the most jaded employee would not fail to get a bit of a glow from this, the effect of which usually causes one to do even more of the same and do it even better.

Of course, like any feedback a leader provides to an employee, it is only useful if it is accurate and genuine. Hopefully that wouldn’t be too hard. Any employee who is performing at a level of “3” or better certainly must be doing things pretty well so it shouldn’t be hard to find something to compliment.

Conversely, if you just can’t find anything good to say to a given employee — well, that must mean something, too.

In an earlier post I wrote about adding energy to an organization. If you are a leader, here is a great way for you to do it. Maybe it will even cause your boss to compliment you on what a good job you are doing leading your team.

Appendix – Measuring the strength of a workplace

Here are the key questions which the most engaged employees will answer positively and others will not, according to the surveys done by the authors:

1. Do I know what is expected of me at work?

2. Do I have the materials and equipment I need to do my work right?

3. At work, do I have the opportunity to do what I do best every day?

4. In the last seven days, have I received recognition or praise for good work?

5. Does my supervisor, or someone at work, seem to care about me as a person?

6. Is there someone at work who encourages my development?

7. At work, do my opinions seem to count?

8. Does the mission/purpose of my company make me feel like my work is important?

9. Are my co-workers committed to doing quality work?

10. Do I have a best friend at work?

11. In the last six months, have I talked with someone about my progress?

12. At work, have I had opportunities to learn and grow?

Besides #4, others of these would make fine subjects for upcoming articles.

Posted in Leadership, People | Leave a comment

Ability to Deliver

Posted on August 3, 2009 by John

This is what software development is all about.  So simple in concept, yet seemingly so hard to accomplish. A development organization that can’t deliver what’s needed is a wasteful expense, not to mention a generator of false hope for those who were expecting some output.  So how do we know if any given organization actually has the ability to deliver?

There is really only one answer, which is the most obvious one:  Has it been able to do it consistently in the past?  If “yes,” that’s all the evidence we need. (“Yes” means that whatever was delivered met or exceeded expectations for functionality, quality, and timeliness by both customers and the company). Whatever is being done works, and for an organization with a bad track record or no record at all, there’s just no way to know for sure.

So if a track record is all that’s needed to gauge an organization’s ability to deliver, why are there other methods such as CMMI that attempt to measure development organizations?  Probably they spring from the irresistible urge to measure and classify things, especially for those who subscribe to the idea of “You can’t manage what you can’t measure.”  (I will address this topic in a future post.) Presumably if the assessment method measures the right things, it will help a development organization to do better. So let’s assume that there actually is value in using some assessment method.

There are several assessment methods to choose from.  At one time or another, my organizations have been through formal assessments for ISO 900X, Malcolm Baldrige and SAS70, as well as CMMI.  In my opinion, they’re all pretty much the same: auditors come in and look for “evidence” that your organization has documented its procedures, that people know how to use them, that you have written evidence of their use, and that you are measuring the results. The underlying motivation for all of these is sound, but I find all of these methods deficient because they don’t measure an organization’s ability to deliver, which includes satisfying its customers (Malcolm Baldrige might be a partial exception to this).

So if I were called in to assess a software development organization, after looking at its track record (which would include getting a gauge on customer satisfaction), I’d be inclined to use the Agile Manifesto as my yardstick.  In fact, the 12 principles behind the Agile Manifesto might make a great set of competencies for the “Performance Document” of a development organization (just like many cmpanies do for appraising employee performance, although see my note below). While following them does not guarantee success, I think they come much closer to providing guidance that will result in improving an organization’s ability to deliver than any of the other methods.

Important note: While I have suggested using the 12 principles as a yardstick, it would only be for informal use and not to produce some type of formal assessment score (if that were even possible).  They should be used only as an improvement tool, not a measurement and scoring tool. Following a process is not the goal of development – it is only a means of achieving the goal, which is to deliver the product.

If you haven’t looked at the Agile Manifesto and the 12 principles behind it, it’s really worth doing.  Do your own quick mental appraisal of how well you and your organization are following each one, and then think of what you could change to follow them better. And while following a few of the principles is better than following none of them, I think to be fully effective an organization needs to follow all of them.

Earlier I raised the question of why any kind of assessment might be needed for a development organization other than just a track record, so I will now propose an answer, specifically with the Agile Manifesto in mind:

  • For an organization that is not satisfied with its track record, following the principles behind the Manifesto and executing them well is probably the single best thing that could be done to help it establish a good record.
  • And for an organization that already has a good track record, following the principles will help it improve the effectiveness and efficiency of its ability to deliver, because there is always room for improvement.

In either case, I believe that following the Agile principles will do a better job of helping an organization improve than any of the other formalized assessment methods mentioned earlier.

In the end, it’s only the ability to deliver that really matters for a development organization.

Posted in Execution, Process | Leave a comment

Quality Part 2: Cleaning Up as You Go

Posted on July 27, 2009 by John

Years ago I had an epiphany that has stuck with me to this day. When I went away to grad school, I finally got an apartment of my own and thus had to cook my own meals (this was before microwave food become popular).  Cooking was a messy process; my apartment did not come with a dishwasher; and I HATED to wash the dirty pots, pans and dishes, so I generally put cleanup off until later – much (days) later – until finally there was such a pile of dirty dishes that the sink was full, or I ran out of clean dishes, or guests were coming over.  Then I was forced to deal with washing up a really big pile of dirty dishes, a big job that took a long time.  Having a big pile of dirty dishes to deal with was a liability that hung over me.

Dirty Dishes

The Defect Backlog?

At one point it occurred to me that if I washed every dirty dish immediately – concurrently with the cooking process – I would never have to face a big cleanup job. The cleanup process would be finished within seconds of the cooking process, and thus no backlog of dirty dishes would ever exist. And so cleaning up as I went has been my practice ever since.  (But I admit that when I finally got a job, I made a point of getting an apartment with a dishwasher!)

And so for a development group, I strongly recommend the same policy: clean up your defects as you go, and NEVER let them pile up.

In a typical development cycle, the number of open defects keeps growing during the course of development, finally reaches a peak, and then starts a slow decline.  In a true waterfall process where the testing doesn’t really get going until coding is done, the real ramp-up starts very late in the process.  Fortunately, most development groups now start testing well before the feature complete milestone, and for groups using iterative development, the testing can start even sooner.

However, even when iterative development is used, there is danger that dirty dishes will pile up.  This can happen if iterations are allowed to complete with open issues, especially if this happens repeatedly.  So the best practice is that:

All code produced during an iteration should be complete at the end of the iteration – including all testing and fixes.

Said another way,

Each iteration should represent a potentially shippable version of the product.

Whoa, that sounds hard! you say. We don’t have time to do that – we need to get going on the next iteration.  Besides QA is still busy testing code from an earlier iteration.  And we’ll come back later and clean up any defects that they find.  We need to finish cooking the meal, and we’ll wash the dishes later.

But allowing engineers to move forward before the last set of code is “done” (i.e. fully tested) is not a good idea for many reasons.

One of the really big problems with letting dirty dishes pile up is that you just can’t predict how long it will take to do the clean-up, thus putting schedules at risk (or quality, if you are forced to meet a schedule). Getting away from the dirty dish metaphor, until all planned quality verification is complete, you don’t know if there are any bigger issues lurking, and you run the risk of doing your next round of development on an unproven foundation, or greatly increasing the risk of the schedule impact caused by having to go back and do a lot of fixes on code that was supposedly “done”.

There can be a productivity impact to deal with the task switching necessary to put aside current work to deal with issues from “old” work.

And letting the engineers go on ahead effectively makes QA responsible for quality because it leaves them as the only ones standing between the code and the customer because everyone else is done with it unless QA tells them otherwise.

The best way of ensuring that you don’t have a quality problem is to never let one build up.  Wash those dishes immediately, as you go.

Posted in Agile, Process, Quality | Leave a comment

Quality Is Not The QA Group’s Responsibility

Posted on July 6, 2009 by John

Whenever an angry customer complains about a product defect, someone is sure to ask “Why didn’t QA find it?”   That’s a logical question based on the assumption that every product has a QA group whose job it is to create and run enough tests to find all of the defects in the product.

But so long as people believe that assumption and operate in that manner, we’re going to have quality problems.  I don’t believe that “the QA group” is responsible for the quality of our products.

So if quality is not QA’s responsibility, whose is it?  What should QA’s role be?  And do we even need to have a QA group?

Quality is rightfully a hot topic at the moment, so I’ll address these and other topics related to quality here and in follow-on articles.

Most traditional software development organizations have a QA group whose job it is to write and execute tests, the purpose of which is to detect defects in the code written by the Software Engineering department.  In a typical development process, the “product” moves along on a software assembly line from requirements to design to code to test and finally to packaging and shipment.  The last significant step in that flow is “test” and that is always the responsibility of QA, who all too often operate in isolation, both by design and by necessity.  (This is true even in many groups who are doing iterative development.)

Perhaps the most obvious reason that QA is not responsible for quality is that you can’t test quality into the code.  Testing alone can never discover all of the defects in anything but the most trivial piece of code (not more than 60% according to Capers Jones), so QA is on mission impossible if they are expected to prevent the escape of any defects.

But QA typically operates under another very severe handicap, which is their isolation from the rest of the process.

In most development organizations, QA typically is organized as a distinct group, usually reporting to a QA manager.  This is done for several reasons.  Grouping people of a similar discipline, function or skill together is often done for management convenience.  Presumably a “QA manager” is an expert in the job of QA and thus can best manage the work of QA people (and similar for engineers, and for analysts), including providing work direction and doing performance reviews.  And some people believe that QA people must operate at some distance from engineers and analysts so they can be completely objective in their testing, uncontaminated by the biases they would surely develop if they were allowed to fraternize with those other functions.

Another reason that the QA group is isolated from the other development functions is that they are often operating at a different point on the development timeline.  Since test is the last major step of a sequential development process, that’s where you normally will find QA working, while the analysts and engineers have moved on ahead.

So even if QA really were responsible for quality, forcing them to work in isolation at the end of the development cycle greatly reduces their effectiveness as a defense against quality issues because:

  • Being the last major step in the process, they are under the greatest time pressure to achieve the GA date, exacerbated by the likelihood that upstream groups have had some inevitable schedule slips.
  • The analysts and engineers feel little sense of responsibility for quality because their attention has turned elsewhere, and it’s QA’s job to come along aftwards and find the bugs in the work they completed awhile ago.
  • It prevents QA people from participating in detailed discussion of the requirements and design that take place earlier in the cycle, thus reducing their understanding of the function whose quality they are trying to ensure.
  • Allowing analysts and engineers to proceed ahead of QA inevitably leads to a mounting backlog of defects during the development cycle, whether discovered or (even worse) not discovered.  This backlog represents an unknown quality liability.
  • In general, it creates a handoff.  See my posting on Handoffs to see why this is bad.

So what’s the solution, and who should be responsible for software quality?  Answer:  Everyone in the process must be fully responsible for quality – including the analysts and engineers – together with QA people.  And furthermore, they need to be jointly and equally responsible, not merely “involved” by having performed their assigned job as part of the overall process. (“I wrote code according the the spec and it seems to work, so my job is done.”)

In an earlier post I discussed the use of cross-functional teams (CFTs) as an integral and essential part of the iterative development process.  The use of real CFTs (where everyone on the team sits together, works together, and is jointly responsible together for satisfying the customer) is the strongest method I know of for ensuring that the product that emerges from the development process is of top quality, because it applies the greatest number of brains to achieving that goal, and makes everyone feel the responsibility that results from a feeling of ownership.

Of course we need to test our products, but testing is only one form of defense against quality issues.  Only when all members of a CFT put their minds together will we maximize success.  Working in that way, analysts might point out some functionality that needs special testing focus, and engineers can point out areas of the code that need special attention.  But beyond that, it might be that the engineers themselves should write some of their own diagnostics or tests (the idea of test-driven development comes to mind), the analysts might be able to locate some customer data that would make particularly good input, the whole CFT might inspect the detailed requirements and design docs together, etc.

A few other comments:

  • I didn’t forget about test automation, which is another extremely important tool for ensuring quality.  I rank it second in importance, after the use of CFTs, because all the automation in the world still won’t do the job unless it is testing the right things.  The collective brainpower of the CFT should be applied to devising the automation plan to ensure the best coverage.
  • Quality is not only the absence of defects like crashes or incorrect results.  Quality is when the product works the way the customer wants it to and expects it to.  No amount of testing can ensure that, especially if done by a group that is separated from customers or even those who represent customers (such as analysts).  So the QA function must be an integrated part of the CFT operation.

To return to my thesis: the QA group is not responsible for quality – everyone working on the development of a new product or feature is, jointly and equally.  This is difficult to impossible if QA is organized as a separate function, if QA people are physically or temporally separated from the engineers and analysts, or if the engineers and analysts don’t take joint responsibility. The use of co-located CFTs who work together as teams from start to finish is the answer.

So what should QA’s role be?  And do we even need to have a QA group?  I’ll address these in a follow-up posting.

Posted in Process, Quality | Leave a comment

Handoffs

Posted on June 3, 2009 by John

The more handoffs that are required by a process or organization to do its business, the less effective that process or organization is.  Said another way, there is an inverse correlation between handoffs and high performance.

I think I first realized this in kindergarten, when Miss Fiskerbeck played a game with us one day:  She had the class stand up in a line, whispered something to the first kid in line, and then told him to pass the message along in a whisper to the next kid, who would pass it along again.  When the message reached the last kid, he was to say the message out loud.  As a mode of communication, this method had significant drawbacks, one of which was that it took time for the message to propagate to its destination.  But far worse was the distortion that took place: the message that emerged at the end bore no resemblance to the original, because it was translated and interpreted over and over, each time it was handed off.

That silly little children’s game illustrated something that we still suffer from as adults in a business environment: we create organizations and processes with many boundaries among them.  Each boundary requires a handoff.  Every handoff introduces delay and distortion.

Most development people have seen this cartoon at some point, and no doubt can relate to it because we’ve all seen it happen:

PM_Build_Swing

Every time the original piece of information is handed off from one independent organization to another it is subject to further (mis)interpretation.  Even worse is the fact that most handoff-oriented processes do not include any form of feedback loop to prevent distortion from accumulating.  Can you imagine how the outcome might have been different if only the customer had been shown a sketch of the proposed swing at each point in the process?

So what’s the lesson?

  • Minimize the need for handoffs in your organization or process.  Each handoff is bad because it introduces delay and distortion.
  • Because it will not be possible to eliminate handoffs completely, be sure to incorporate feedback loops in each step to minimize distortion.

OK, the theory is great, but how can this be addressed in practice?

First you need to understand where the handoffs occur.  In whatever you are doing, make a quick sketch that shows each distinct participating organization, and arrows to show the process flow across these organizations.  By “organization” I mean any group or individual that operates with some degree of autonomy as a team.  Traditionally an organization is defined as a group of people under a single manager or leader, because typically each one operates somewhat independently with its own goals.  On your sketch, every time a process flow line crosses an organizational boundary you have a handoff of some kind, but there could even be handoffs within an organization.

Now finally we come to the punch line for development:  The traditional waterfall process practically enshrines boundaries, as work progresses sequentially from product managers who collect requirements and define product strategies, to analysts who create product specifications in response, to engineers who build software that attempts to meet the written specifications, to QA who tries to figure out if the code works.  Each group is whispering sequentially in the ears of the next group in line, and we know what that causes.

Note: In software, interface boundaries between systems are common so we might be tempted to use such interfaces as an example of how handoffs should work across human organizations as well.  But humans don’t work like computers.  The information transmitted across software interfaces is usually concise, structured and factual, while the information conveyed in a handoff between human organizations is verbal, complicated and not well structured.  Obtaining a “signoff” at each handoff does little to prevent distortion or ambiguity because every document ever written is subject to interpretation (hence the existence of lawyers).

Part of the answer to this is to use an agile process such as iterative and incremental development.  Why does this help?  Most obviously, it provides a feedback loop.  At the end of each iteration, the resulting code is publicly demonstrated (even to customers) so everyone can see how the product is shaping up, and corrections can be made in subsequent iterations.  Long before delivery the customer can see that the swing is not suspended in the air, and that isn’t going to work, so it needs to be corrected in a subsequent iteration before delivery.

But iterative development alone is not enough!  There are several other essential elements of minimizing handoffs in software development:

  • Cross-functional development teams.  I have blogged on this before.  Development teams must be organized cross-functionally, with the analyst, engineer, and QA person working together as a team, and NOT doing their work sequentially.  This alone eliminates several of the handoffs that exist in the waterfall process.
  • Product Management must be tightly engaged as part of the development process, and must not stand apart as outsiders.  They must act as and be treated as part of the overall development team.  There cannot be any gap between Product Management and Development.  Many product organizations have a big gap between these two groups that is caused by the organization structures and apparently by tradition, and I firmly believe this gap causes the biggest handoff issues in the whole development process.  Product Management must be part of the feedback loop, and must be strongly connected with the daily development operations. This can be done, and is being done in some product organizations.

Handoffs are bad.  Teamwork is better.

Posted in Execution, Process | Leave a comment

Adding (or Subtracting) Energy

Posted on May 29, 2009 by John

Do you add energy to the organization, or do you absorb energy from it?  Or maybe you don’t do either one.

I started my blog a long time ago with the intention of focusing primarily on leadership, but most of my posts have been on other topics.  With this article I’ll try to get back to leadership for once.

In response to my initial question, I suspect that most people would say that of course they add energy.  But what they probably mean is that they add value to their organization because they produce something.  Hopefully everyone who works here actually does add value of some type, but that’s not what I am talking about.

Have you ever been in the company of someone who makes you feel so good that you feel your own level of energy and enthusiasm growing whenever you are in their company?  What was that person like?  Very likely they were confident, enthusiastic and positive. They are brimming with ideas, and see opportunities everywhere.  They were emitting energy, like rays from the sun that warm up and excite everything they encounter.  That’s what I am talking about.

On the other hand, do you know people who are pessimistic, who always need to be told what to do, who are always quick to see all the bad aspects of any situation?  They need to be pushed constantly, otherwise they will slow down and stop.  Spend a little time with people of this type and you are very likely to feel “down” yourself.  These people are absorbing energy from an organization.  They are actually taking away capacity and are eroding its ability to perform and move forward.

A complete taxonomy would include a third category, that being people who are neutral: they do not have any obvious or inherent tendency to either add or subtract energy.  Usually they just do what they are told.

Now let’s examine these.

Here’s a very simplistic view: We’ve all heard the expression “Lead, follow, or get out of the way.”  Let’s hope that those who add energy are the leaders, that those who are neutral are the followers, and those who subtract energy will not be allowed to impede anyone else’s progress.

It’s absolutely essential for everyone in a leadership position to be a net source of energy, and not one of the other types.  To be a good leader, you need to add energy to your organization.  If you are in the neutral (follower) category, you are adding no value.  And let’s not even think about the possibility of someone in a leadership position being an energy absorber, but I’ve seen it happen.

Think for a minute about how others see you in this regard.  Would they say that they find you to be a source of motivation, ideas and encouragement, or would they have to think about it?

We’ll be optimistic and assume that you pass the test and people find you to be a source of energy.  But there is one more qualification:  That energy needs to be of the right type and directed in useful directions.  If you emit lots of energy but it causes others to chase their tails or jump through hoops, you are just confusing motion with progress.  Just stirring things up is not necessarily useful or even good, especially if it detracts from accomplishing the mission.  So your energy needs to be aimed in a useful direction.  Being a personification of Brownian motion might make you seem energetic and you might be applauded for it, but if you are not directing that energy towards a goal it’s a waste.

Oh, one more thing:  Being a source of energy does not necessarily imply that you must act like a human tornado or that you work 80 hour weeks.  One of the frequently-forgotten aspects of leadership is that whatever you do (good or bad) is amplified by the organization you are leading.  If you love your job so much that you work furiously at it for long hours, that’s great.  But the leader who adds energy to his organization will see that energy amplified and multiplied by many others, and that leverage is where the payback comes.

If you are a good leader, you need to add energy to your organization.  Be radiant, like the sun, adding energy to others wherever you go.

Posted in Leadership | Leave a comment

Is Software Development Fun?

Posted on April 20, 2009 by John

This is a question that I really hadn’t thought about explicitly until I came across it in a book recently.  While it might seem to be a trivial or even irrelevant question at first, it takes on greater meaning when one thinks about it for a bit.

When I first started programming – many years ago – in FORTRAN – using punched cards – on a machine with 8K of memory and a 512K hard drive – I did it because it appealed to me and it was … fun!  Nobody told me to do this – I just wanted to do it.

I suspect that a similar story (differing in some of the details) could be told of most people who work in software development.  I’ve never seen any figures, but I doubt that many people decided to get into software development because it was “just a job” and they could have just as easily chosen to be a car salesman or a cop instead.

And it is also the case that virtually every activity, no matter how much fun it inherently is, has aspects that are not so much fun, or can be managed in such a way as to maximize or minimize the fun.  For example, cleaning up after a fun project is usually not so much fun, and if you are on the baseball team, you’d probably rather be batting than doing pushups.

Why, then, is this relevant?

If programmers are creating software because they think doing it is fun, and because everyone here (programmers, managers, sales people, etc) wants to see more software produced, it follows that we should try to maximize the fun parts of software development while minimizing the “non-fun” parts.  So which is which?

According to the book I just read (as well as my own personal experience), I would classify a few things as follows:

Fun Not (as much) Fun
  • Writing code
  • Learning a cool new technology
  • Designing something
  • Writing more code
  • Seeing someone use my work and think it’s cool
  • Did I mention coding?

Generally, fun things are those which are creative and which resulting in constructing something useful.
  • Writing documentation
  • Testing (see below)
  • When someone finds a bug in your code
  • Fixing the bug in your code
  • Doing things other than coding
  • Going to meetings on some dumb management topic

Things that are not fun are those things which are perceived as bureaucratic or that appear to stand in the way of getting the code done.

This is not all that scientific or complete, but I think it generally rings true for most tech people.

It tells us why CMMI and similar initiatives are not well received by software creators – it is because they emphasize and require bureaucratic work such as documentation and meetings that most programmers find to be obstacles blocking the way to the creation of code.

Testing is an interesting thing.  All programmers realize that it is necessary, but few like to do it in anything other than tiny quantities.  That being the case, we need to find ways to get it done as quickly and efficiently as possible.  Automation comes to mind.

Agile methodologies tend to be preferred by most programmers because they minimize the creation of non-code artifacts and allow the practitioner to get down to the “fun” stuff as quickly as possible.

I’ll quit here and leave your imagination to triage some of the activities we face in development to figure out if they are fun or not (what we can do to maximize the fun – and thus the output and job satisfaction).  I think that software development should be fun.

Posted in People | Leave a comment