Prioritization is a Symptom

"How do we prioritize all this work?" "What are mechanisms you use to prioritize?" "What if I have a lot of options that are all equal?" These are all valid questions and prioritization is an important function of both home and professional work. However, we find most often that prioritization issues, like trust issues, are a symptom of deeper problems. This video discusses what some of those root causes are and how we at Modus Cooperandi approach them.

Positional Power and Unintended Influence

It's tough to handle this fortune and fame Everybody's so different, I haven't changed ~ Joe Walsh

It was spring. That winter, like this last one, had been harsh. Internally, my client was trying to lead his company to change...to a better tomorrow. He had been working to give his people more autonomy, more agency, and more internal influence. He kept waiting for that cultural winter to abate, for people to thaw out and enjoy working…but it, like winter, happened on a schedule he couldn’t control.

“I don’t know what I’m doing wrong,” he sighed as we ate lunch. “I keep asking people to take responsibility from me. I’m building structures to let them make their own decisions. I am giving people autonomy. But when I get into a meeting with them, they still defer to me. If I offer a suggestion, it becomes a marching order. It’s just a suggestion!”

Recently, another client of mine had a project that gained a rare visit from the CEO. He came and spoke with the team and they had a good time. When he left, the team was energized and excited to keep working. The CEO was excited too.

The CEO was so excited that he couldn’t stop thinking about the project. So, on the plane ride home, he sent them an email saying how excited he was and giving them some thoughts he had about what was going on.

Instantly, people sprung into action - making the thoughts of the CEO the primary focus of the team. The team was excited to please the CEO, but were also a little annoyed. They already had enough work on a complicated project and now they suddenly had to respond to all these new demands. This made people a little uneasy, they were happy to help on the one hand, but annoyed on the other.

Then my client had the wherewithal to actually write the CEO back!

She asked a simple question: “Those things in your e-mail, did you intend for us to consider them or act on them immediately?”

The CEO wrote back, as you might expect, “They were just thoughts, I was excited about the product and our meeting. You guys build what makes sense.”

No one was born a leader. No one was born a manager. We’re all just people.

One of the hardest things for a CEO to accept is that our positional power extends well beyond simply giving orders or being able to fire people or controlling the purse strings.

When we are in management, our words become law much faster than we realize - and this is very hard for us to counteract. Those who are “under” us have to discern when we are having an idle thought and when we are issuing an order. They will usually err on the side of “issuing an order”.

When we have positional power, that power manifests itself as influence. Influence may be something we can wield, but it’s energy. It discharges on its own quite frequently.

Simply being in a meeting can and will alter the ideas expressed and acted upon. Simply writing an excited email, where you are honestly enthusiastic, can have negative repercussions.

One problem I’ve run into many times is that in leadership one of your main jobs is to be constantly identifying options for the future of your organization. You must constantly be devoting time to investigating new markets, products, structures, business models, partnerships, and so forth. Discussing this with “staff” can create confusion, they don’t know if your new thought is some flighty “Hey let’s derail everything and do this!” or just an idle thought or something to be lightly investigated or maybe even just something to ponder.

They are looking to you for actionable advice. They want your words to compel action. That’s all well and good, but enlightened leaders and managers know that they cannot compel all the action, that healthy companies have ideas coming from all directions, and that sometimes a leader needs to just talk.

There is no solution at the end of this blog post other than a call for awareness. As leaders, look to set up intentional structures that let you participate in as much of a peer-to-peer role as possible, but be aware that you cannot ever fully be a peer due to your positional power. Don’t shy away from this. Just understand that that the dynamic is real and impacts your company greatly.

The Ambiguity Business

As I sit here, rapidly nearing my 50th birthday, I look back at the companies and government agencies I’ve worked for and the companies I’ve managed or owned and operated.

I find that work is heaven and work is hell. It’s uplifting and it’s stressful. It’s rewarding and it can certainly be defeating.

Companies are made up of people. We are companies because we are in the company of others. We have colleagues, associates, and friends. We work with these people, each of whom has their own life outside the walls of the office.

Things rarely go as planned. This is a design flaw in the human brain. We are not very good planners.

But when we do make plans, we put a lot of our hopes into them. The funny things about hopes is that every hope is a solution to a fear. So we also put our fears into them.

When plans begin to go awry, we react emotionally to the collapse of the plan.

I often use this analogy:

Suppose I told you to get in your car and drive down a very long, straight tree lined highway at 100 miles and hour. The car is already on the roadway. It’s pointed in the right direction. The wheels are perfectly straight. I tell you the car is all set. You get in and I’ve removed the steering wheel. I’ve already set the course, all you have to do is hit the gas pedal. You likely wouldn’t want to do that.

This is because there is variation in all automobiles. You know that you’ll have to make little, nearly imperceptible, corrections to the car. The wheels simply won’t stay pointed in precisely that direction.

Steering is part of the system of driving. Constantly making small corrections and, from time to time, making large corrections, is all part of safe driving.

But it’s never been part of safe project management.

There a lot of variation in business and even more ambiguity. We feel that these things are dangerous to predictability, so we try to legislate them away. We create deadlines and budgets and plans … all of which are setting the car in motion with a really great map and no steering wheel.

We have an inherent discomfort with not knowing what’s going to happen ahead of time. That discomfort can manifest itself as healthy excitement and anticipation, or it can become fear and loathing. But, like it or not, businesses that try to ignore that ambiguity and variation are not just forces in business - but primary forces in business - will continue to more slowly and be outpaced by those that prepare for the unplannable.

Further, we need to understand that companies are again made up of people. When plans go astray, we react as people - not as machines. We are disappointed, upset, and even angry. We tend to look for people to blame, rather than acknowledging that variation and ambiguity may be at work.

We are in the ambiguity and discomfort business.

Lunch&Learns Solve Team Training Problems

Do you have limited training budget? Do you have a distributed team? Do you have an immediate training need and can’t spare an entire day or two or three?

Welcome to the real world.

Last year we noticed that most of our clients had at least two, if not all three of these issues, so we started a program we call “Lunch&Learn”. We started getting together with our clients and their teams for 90 minutes on Google Hangout. We would then have an extremely focused training. Then people would go back to work.

It’s been extremely popular, so now we’re introducing it to the world.

The Format:

We meet on Google Hangout. There is a short 30 minute lecture, then 60 minutes of directed conversation. The goal here: To Learn and Immediately Apply.  Afterwards, you get a set of Modus One-Sheets (sample) that describe in-detail a tool or concept mentioned in the lecture. The One-Sheets are helpful future references that reinforce the learning.

Why This is Interesting:

Focus - You pick a topic that is of immediate need to the team. We’ve done topics as broad as root cause analysis and as narrow as  a specific issue raised in a kaizen event or retrospective.

Relevance - Topics you choose are of immediate need to you and your team. You know they need the guidance and so do they.

Immediate Application - The conversation afterwards are geared bolstering the lecture, understanding your context, and helping create ways to quickly apply the learning. Our goal here is to have the Lunch&Learn be so useful that it’s discussed and applied that day.

Real Experts - Modus Cooperandi provides award-winning experts not only to train but directly consult and coach.

Affordable - For less than the cost of admission to an off-site training, an entire team can benefit.

Co-Learning - Don’t just send a select few to go be trained, have the entire team learn together. This is especially valuable for distributed teams who can participate together regardless of location.

Dynamic - This isn’t a one-way webinar, this is a live two-way discussion.  

The First Flights:

Sign up now for a dedicated Modus Lunch&Learn training on:

April 17, 2014

and

April 30, 2014

How We Do Business: Sample After Action Report

When we work with a team for a week, we learn a surprising amount about how the team works, the company’s relationships, the products, and the needs of the organizations. Anyone that’s worked with Modus knows our After Action Reports (AARs) can become quite detailed. Some have been over 50 pages. We thought it might be helpful to show people what a sample AAR might look like. While each AAR is very specific to the needs of the particular client, this one gives a good idea of the range of topics they take on.

Note that this is an actual AAR from an actual week long Launch Ready event. We’ve taken out all the detail that might reveal the client, and left everything else.

Download The Sample After Action Report Here

Modus Cooperandi White Paper: Kanban: Diversity and Optimization of Knowledge Working Teams

Announcing the publication of Kanban: Diversity and Optimization of Knowledge Working Teams – a new Modus Cooperandi White Paper.

Late in 2012, we conducted a Board Walk (a site visit where we meet with teams using kanban or Personal Kanban and help them optimize the board and the team itself) at a client in the United States.  There were 15 individual teams, each of which had its own individually designed boards. Each board had a unique value stream, work item types, policies, and methods for judging completeness and quality.

Both management and the teams were frustrated because they hadn’t yet found a board design that worked for the entire company. They were looking for standardization.

However, each of these boards were, in some way, optimized for each individual team. Each team had its own context and these boards related specifically to that context. Each team was also actively improving their boards on a regular basis – meaning that optimization was continuing.

This white paper contrasts many of these boards, showing the differences in design of each board and the ramifications of those variations.

A PDF of this is available for organizations requiring a bulk purchase. Please write.

Three Questions on Deadlines #2–Jon Moore

We asked our three questions on deadlines of Jon Moore, Technical Fellow and Chief Engineer at Comcast Interactive Media:  

Q1: Do deadlines empower your teams?

I've found that deadlines can cut both ways. On the one hand, an achievable but challenging deadline can really get teams to focus; on the other, a seemingly impossible deadline can crush morale. Having a fixed deadline with variable scope (where the minimum viable product is achievable by the deadline) is a perfectly fine timeboxing mechanism that can line up well with longer lead-time activities that must be coordinated around a big launch--for example, marketing efforts.

Q2: Do your customers expect delivery on deadlines?

Yes, internal customers often expect delivery by negotiated deadlines. In a company with many teams, estimates like ideal hours or story points[1] do not carry well from team to team, but calendar time does. Asking when another team can deliver a dependency serves as a useful unit of exchange.

[1] I have even heard of teams from a different company that estimate in kilograms!

Q3: What are you doing to meet customer expectations (in response to or in lieu of deadlines)?

I've seen have success with tried-and-true mechanisms from Scrum: prepare all the user stories, estimate in story points, then project out based on historical velocity. If the scope/date line doesn't pan out well (or is close), manage expectations with the customer as early as possible to discuss scope/date tradeoffs or risk.

Bio: Jon Moore is a Technical Fellow and Chief Engineer at Comcast Interactive Media, a part of Comcast dedicated to building web and mobile customer experiences.

Three Questions on Deadlines–Asking the industry

Deadlines ... we govern by them, talk a lot about them, gripe about them. But do we use them effectively?

Deadlines are grave ... in fact their original use was quite literal:

… And he, the said Wirz, still wickedly pursuing his evil purpose, did establish and cause to be designated within the prison enclosure containing said prisoners a "dead line," being a line around the inner face of the stockade or wall enclosing said prison and about twenty feet distant from and within said stockade; and so established said dead line, which was in many places an imaginary line, in many other places marked by insecure and shifting strips of [boards nailed] upon the tops of small and insecure stakes or posts, he, the said Wirz, instructed the prison guard stationed around the top of said stockade to fire upon and kill any of the prisoners aforesaid who might touch, fall upon, pass over or under [or] across the said "dead line" .... ["Trial of Henry Wirz," Report of the Secretary of War, Oct. 31, 1865]

~

A deadline is negative inspiration. Still, it's better than no inspiration at all. ~ Rita Mae Brown

Deadlines can be deadly serious. They are set to meet key coordination dates and understanding those real business needs can be the line between success or real business death. Deadlines can help us focus – finding the real value of the work to be done and trimming the waste.

Most of the time, however, deadlines are wishes. They are dates we’d like to get something done by, regardless of all else.  Missing these deadlines has little consequences on customer value, but they cause people to work as if the fate of the company were at stake.

Many people use deadlines, inappropriately, to motivate. They often do this because they have no other way to inspire their workforce or they really do believe that deadlines work for this.

We thought it might be a good idea to ask around – and find out how people are using deadlines. Where are they working? Where are people finding other ways to motivate their workforce?

In this series we have:

(these links will go live as we release the interviews over the course of the week)

• Jason Montague – Director of Application Development at R.W. Baird
• Jon Moore – Senior Developer and Technical Fellow at Comcast Interactive Media
• Jabe Bloom – CTO at the Library Corporation

If you would like to be part of a future interview series, please let us know!

Three Questions on Deadlines #1–Jason Montague

As part of our Deadlines Interview Series, We asked Jason Montague, Director of Application Development at R.W. Baird in Milwaukee, three questions about deadlines:  

Q1: Do deadlines empower your teams?

Wow.  You went right for the jugular on this topic, didn’t you.

Unfortunately, the short answer is YES, I do feel deadlines empower our teams, but NOT in the way you might expect.  Deadline empowerment can lead to wildly varying, primarily negative, outcomes.

To begin, most organizations don’t have a good sense of how to manage software developers or “value” in software projects.  So, instead of working on a way to manage more effectively, they use a very handy (and simple) proxy…deadlines.

For most business leaders who don’t have the time, patience, or inclination to learn about software development, understanding the nature of these projects and all the variables at the disposal of project teams is daunting.  In many organizations, much of the complexity is ignored, or worse, dismissed.  In these organizations, software teams and their importance in the business ecosystem is marginalized and quickly become more order-takers and less partners over time.

So then, what do deadlines “empower”?

Development teams, like any team of people, are motivated intrinsically to do a good job.  If “doing a good job” becomes more about WHEN you deliver over WHAT, HOW, or WHY you are delivering, then those teams will move heaven and earth to deliver ON TIME, ignoring some key concerns.

Common missing components in deadline driven projects:

• (WHAT/HOW) The deep complexity and craftsmanship needed to build a sustainable, resilient, manageable product that will grow and thrive over time.
• (WHY) Why are building this?  Is there a better way?  Can we help make this any simpler?  Should we build it all?  Some of it?  None of it?

When teams are faced with a deadline, the typical response is to focus on the deadline and deliver (no matter what).  This is definitely empowering, and seems like a reasonable arrangement, until you realize the incredible cost associated with missing the WHAT, HOW and most importantly the WHY.

(I can elucidate those costs in another post.)

Q2: Do your customers expect delivery on deadlines?

Yes they do.  And sometimes it is completely rational and unavoidable.  Market pressure, response to regulatory mandates, legal requirements, etc., all require rapid, time bound responses to delivery.

However, in my experience over the last 17 years in (primarily) IT shops in financial services, insurance, banking, and even packaged software products, these deadlines are largely imposed by “managers” as a proxy for leadership.  Customers, and IT managers, simply don’t know what else to do.

Q3: What are you doing to meet customer expectations (in response to or in lieu of deadlines)?

We are attempting to teach a new way of working.  There are a few key steps we’ve taken to help our organization realize that deadlines, although sometimes helpful, can also cause mayhem and colossal long term costs if placed in the center of our work.  These costs can be predominantly avoidable.

Here are some key tenets:

• Ensure your decision makers (the “business”) are engaged and partnering daily, and understand tradeoffs related to their choices.  With good decision making and partnership, we tend to maximize what we don’t build.
• Educate the organization on the virtues of software craftsmanship, and why high quality software is crucial to reduce costs and to go fast.  Architecture is then “baked in” to the process and we find ourselves leveraging our software versus fighting it.
• Teach the organization to “shrink their bets”.  Massive projects take on a life of their own.  And living things tend to create antibodies to change.  With large projects, too much is riding on the vision, plans, and promises of the project and its stakeholders.  When that happens, human nature is to “press on” and achieve project deadlines (even if the project or company is destroyed in the process).
• Teach organizations that learning is the most crucial, and scarce aspect of projects, not money or capacity.  With smaller deliverables, teams can learn how to deliver high quality software extremely fast, and learn a great deal along the way.  Rapid learning allows teams to change course quickly and achieve stunning results in the process, without massive investment in expanded capacity.

When the above conditions are met, customer expectations move away from simplistic models where DATES are the only thing they understand, to active partnership where RESULTS and VALUE once again take center stage.  It’s not that deadlines are all bad.  We understand they will always have a place in our work.  We simply try and make them less important in our daily lives, and treat them as exceptions rather than the rule.

When we do this effectively, we find that deadlines take their rightful place in the background of our work versus in the center of it.  The transition is tough and takes time.  Over the years, we have found it becoming easier and easier to implement due to years of deadline driven management and all the dysfunction and unintended consequences it creates.

Lean Coffee–Value Through Flexibility and Democracy

In late 2012, Modus Press will be releasing a book on Lean Meetings.  At the core of this is a tool we use called Lean Coffee.

Where it came from

In 2009, Jeremy Lightsmith and I were sitting at a coffee shop wondering about how to start a new Lean-thinking community of practice in Seattle. This sounded like a great idea, but neither of us had enough time to devote to running yet another professional organization.

So I suggested that we make it self organizing. We find a place, a time, and an open-but directed, format.

Value Through Flexibility

Each Lean Coffee Meeting works like this:

• Framework: Draw a Personal Kanban
• Personal Agendas: Invite attendees to write their topics on sticky notes
• Democratization: Giving them two votes each, ask attendees to vote on the topics on the table
• Group Agenda: Prioritize the sticky notes
• Discuss

There are three main things happening here:

1. There is a tight enough framework for focus
2. There is a loose enough framework for new ideas to appear, and
3. The framework gives everyone ownership.

Why is this important?

In a Lean Coffee style meeting, no one “owns” the agenda – it is created on-the-fly. A meeting is called with a topic and maybe a few item to be discussed. This format allows the good brains you invited to your meeting (I hope you invited good people) to extend the agenda in useful ways. Since the group votes for items discussed, chances that people will drone or or otherwise hijack the meeting are much less.

Where We’ve Used It

Since launching the Seattle Lean Coffee group in Seattle, we’ve brought Lean Coffee style meetings to organizations including, RW Baird, The Library Corporation, Comcast, Nordstrom, and The United Nations (in offices worldwide). In the corporate setting, we’ve found the lean coffee format to greatly lessen the amount of time wasted trying to “get on the same page,” and greatly increase the productivity and effectiveness of the gathered group.

What This Means

Getting On The Same Page – Most meetings waste a lot of time discussing background to issues that everyone already knows. The Lean Coffee format asks people to write what they wish to talk about on sticky notes and place them into a to-discuss area. When everyone sees the gathered topics, they get context of the topics individually and in relationship to other topics. Seeing this, attendees can quickly align around the topics, their meanings, and the goals of the meeting.

And if they can’t? Well, then we’ve just discovered something valuable to discuss.

Increased Productivity and Effectiveness – Meetings tend to waste a lot of time talking about talking. We will go over the agenda, we will discuss how the agenda isn’t perfect, we will rigidly stick to the agenda. People are frustrated with meetings not because they don’t want to work together, but because they view them as ineffective and, therefore, as interruptions in their day.  With a Lean Coffee, groups can create a relevant agenda designed to quickly achieve value.

Heroes Are Just Alright With Me

 

It's three o-clock in the morning and you’re awakened by the unwelcome beep of a text message. You don't even have to look at your phone to know what it’s about. Good news always sleeps ‘till noon, as the saying goes, and so you surmise (quite rightly) that somewhere - somehow - something’s gone wrong with the servers and the site is down. Your business is based entirely on global eCommerce. Every minute the site is down customers are annoyed and sales are lost.

You stumble out of bed and make your way to your office downstairs. Your wife sleepily yet pointedly reminds you on your way out that this is the fourth time this month. This is not news to you. And to be honest, her count may even be on the conservative side. For months now, the site has been springing leaks on a weekly basis. The team is disgruntled. Some have left, while the ones who’ve remained are feeling powerless. The issues are too numerous. They simply can't keep up.

You get into your office, boot up your laptop and find two team members chatting about the problem. Dave has already isolated it, and is in the midst of fixing it. That indicates it's a problem with the fulfillment system. Dave knows his way through that code better than anyone. If it were a problem with search, Ryan would be all over it. If it were with transaction processing, Mei would take care of it. As for the other parts of the site, well, they don't break.

For now.

The six other team members no longer bother responding to pre-dawn texts. They assume (quite rightly) that whatever problem’s presented itself relates to one of the three typically problematic systems, and that one of the three aforementioned “heroes” will take care of it.

As the team lead, you just have to wake up and be present – but the heroes will get the job done. Soon it's just you and Dave in IM, though you're not even talking. Then Dave types, “Try it now.”

You run through a quick perhaps even haphazard battery of tests, and everything looks fine. You know Dave’s fixes work.

You close your laptop, and go back to bed.

The next morning at work, everyone’s busy fixing bugs. No one even mentions the problems that arose in the middle of the night. This is the status quo.

~

While it may seem depressing, many on-line businesses will find this scenario familiar. It is not an edge or extreme case. When teams create complex software and a lot of hastily released code, they end up with something called “technical debt.” In essence, technical debt is releasing something (and it can be anything -  from software, to a car, to food in a restaurant) that can work most of the time, but is likely to be returned.

When teams release software with a lot of technical debt, a few things happen. First, the team becomes unhappy, knowing that they've released a questionable product and that bugs are going to come back. Second, if the bugs are numerous and severe (causing outages like those in the story) heroes show up to save the day.

Heroes tend to be armed with razor sharp, double-edged swords.

The Edge that Solves

On one edge, they quickly cut through to the heart of the problem: they fix the code, and get the site up and running. While that's wonderful and everyone can be is relieved for the moment, it’s just that - for the moment.

The Edge that Cuts

The second edge of that sword cuts into the team. While the hero gets the site up and running, no one knows what he did or why. His code was never vetted, tested, or“refactored” (a fancy word coders use for “edited”). So in the end, the hero has created undocumented code that no one else can go back and work with. Every time the hero touches the system, they fix the symptom (the outage) and exacerbate the problem (technical debt).

That's not optimal, and everyone knows it. But frequently organizations suffer from so much technical debt that focus is placed on putting out fires at the expense of creating value. More fires equate to more undocumented code. More undocumented code makes it more difficult to fix the root causes of the problem. If the root cause remains, we continue spending time and money responding to it.

In Agile, we've declared hero culture to be a detriment because it creates and perpetuates technical debt and introduces inefficiencies. The Agile solution to team heroes is to cross-train – to make sure that many people on the team have the capability to fix the code. That solution is backed up with coding standards, unit tests, and other practices designed to avoid sloppy code and remove the need for heroes in the first place.

So, we have our solution. Simple! But wait - what about all the technical debt that remains? We still have heroes. We still have not found our coding nirvana.

Why?

Because coding is inherently messy, and it always will be. If it weren't messy, it would be automatically generated by software writing software. If it weren't messy, coders would make $35 an hour. If it weren't messy, we wouldn't need Agile to begin with.

So, technical debt is a fact of life. Heroes are a fact of life.

Should they be?

Nope.

So let's think about this a minute.

We have a group who knows their product. We  have individuals on the team who have hyper-specialized in response to the reality of the system. We have a system that is breaking often and requiring emergency repairs.

Many Agile coaches would put systems into place that removed the heroes from their stations and cross-trained others in the group. Is that the right solution? Maybe.

Maybe not.

The other people on the team are overworked just keeping up with all the technical debt hitting them in the face. Catastrophic failures currently require immediate intervention by someone with specific knowledge. Every minute is worth millions of dollars. This is NOTnot the time for cross-training.

It's hero time.

So, in a traditional system, the hero's tasks would be lost in the shuffle. The code enters the system, patches the problem, and people go on about their work. That's not good either. Hero time cannot be blind-faith time.

But what if we're using a kanban on this team. For the non-heroes, we have a simple value stream of:

And that works fine, because those coders are doing things by the book. Their code has unit tests, it meets coding standards, they are pairing, have code reviews, and so on. The legitimately generated new code has ample safeguards for quality.

The heroes, however, are responding to a threat-in-progress. Their task is to code it and forget it; get the site up and running at all costs. To make matters worse, these heroes are brilliant problem solvers. This means that their code is not only undocumented, it's completely confusing to read. It works, but no one can tell how it works. They saved the day, but left this nugget of ingenious-yet-impenetrable code gristle for people to chew on later.

At the time though, and this is important, they successfully got the system up and running immediately. They routinely save the company from ruin. And that's a good thing.

So let's rationally solve this problem. Let them be heroes, but give them a different value stream that gets the fix in and then responsibly refactors and integrates that fix with the rest of the system.

The new hero-embracing value stream might look like this:

So we extend our hero metaphor a bit with some familiar characteristics.

1. Above The Law: The hero is uniquely gifted with the ability to release production code without any testing. The goal for the hero, when invoked, is to fix the problem and get the system running asap, no questions asked.
2. Jimmy Olsen is Needed: Immediately upon release, the hero teams with a normal human being to refactor their genius code into something that is maintainable, readable, and avoids future technical debt.
3. Bat Caves & Arctic Fortresses: Heroes need to be introspective. “With great power comes great responsibility,” says the Batman. After a situation where a hero action is invoked, the team or even part of the team should meet and discuss the issue, why it happened, and how to strike at its root cause and ensure it does not reoccur. This gives the crime fighter the ability to stop the next crime before it starts - really taking advantage of their gifts.

Number 1 in this list ensures that mission-critical problems are dealt with immediately and decisively. Number 2 ensures that the hack is not the final solution. Number 3 ensures that the team learns and quickly sets out to improve the system to avoid future calls to the hero.

Ultimately, we'd like to build systems with no technical debt. Our processes are, of course, aimed at that lofty goal. But like it or not, we do have emergencies that necessitate rapid fixes. We have but two choices – boldly stand up and face reality, or continue to solve technical debt with more technical debt until the software implodes.

Which do you choose?

("Superhero Down-Time" Photo by Jason Stanley)

Spechetti

When coders have crazy unreadable code its referred to as “spaghetti code.” Single strands of code are impossible to trace through the tangled masses coders can weave. When this happens, it becomes incredibly difficult to understand the original intent of the code, the order in which changes were made, and how to go about making things better. This creates something known as “technical debt”. As time goes on, the difficulty in interpreting the code makes it time consuming and expensive to expand upon or to fix bugs.

It strikes me that this is very similar to the specifications that I have seen through the years. At project conception, one person might sit down and write a spec. Between conception and the start of coding, any number of people might edit that spec, introducing, editing, or removing features from the project. As the project begins and progresses, the spec is altered even more. Change orders occur. Off-line detailed conversations are hastily added to the spec or worse yet, included as an addendum. Soon we have spechetti - a document that has been through the hands of many, with differing intents, reflecting dozens of unrecorded conversations.

Spechetti creates a type of “legal debt.” Teams are required to satisfy difficult-to-decipher legal code that can be easily interpreted differently by others. Conflicts grow as interpretations diverge. Interpretations diverge the more granular (and difficult to find) operational clarity is in the spec. This makes the product time consuming and expensive to finalize.

The goal for projects should therefore not be to create a comprehensive spec that can be argued about at completion, but to create a legal and management system that actually drives agreement, clarity, and good business decisions while the project is in-flight. To do this, emphasis is placed on contracting for operational imperatives and not implementation specifics.

Existing contracting mechanisms create legal debt as a matter of course. We need a new kind of collaborative, non-punitive contracting system that replaces mounting legal debt with a mechanism that actually creates social, creative, and business capital.

Well, that sounds easy doesn’t it?

Tune in next time for what will kick off a series on Agile Contracting.