Timeboxing Is Still Valuable (at least I think so).

In a previous post, I shared a couple of quick thoughts on the need for high-performing teams to have goals.  In this post, I want to focus on the touchy subject that has become timeboxing. It’s become cool for Agilists (including thought leaders) to wax negative on the technique.  The popularity of the Kanban Method – an approach that does not use time boxes (at least explicitly) – has contributed to the unpopularity of timeboxes (and approaches that use timeboxes).  In fact, it is now common to hear teams that still use time boxes as part of their development process described as not being progressive, stuck in the past or not modern.

Let me start off with an assertion.  If you work in a context where time is bounded in some form or fashion, then you are working within a timebox.  For example, if there is some work that needs to be completed by a certain date, we have a timebox.

If you happen to work in an environment where “whenever it gets done, is when it gets done” then this post may not be for you because time isn’t a constraint in your environment.  Time is unbounded.  Then again, you may still get some value from using timeboxes in such environments so feel free to read on.

Not Just An Agile Thing…

Timeboxing is a classic work/time management technique that is decades old.  When we timebox, we are dedicating a specific amount of time to accomplishing a particular goal/task/activity.  It’s really that simple.  If you set aside thirty minutes every day to playing the piano (like I do), that thirty minutes is a timebox. If you set a software release date of this date next year, then you have a timebox of one year.  Timeboxes can be long or short.

Timeboxing, as a time management technique, brings high levels of focus and attention to work that is being done within the timebox.  I was recently reminded of the power of timeboxes in a story someone shared with me.  They had given an associate of theirs an assignment but after several months, there had been very little traction or progress and it was becoming frustrating for everyone.  They had a meeting and decided to assign a  “box of time” to the assignment and then assess progress at the end of the “box of time”.  Before you knew it the assignment that had dragged on for months was completed in a matter of weeks.  The timebox brought much needed focus that had been lacking.  (It should be noted that the inability to assign a “box of time” to an activity is an indicator of the state of the system.)

High-performing teams have goals.  The best goals have a time component associated with them.  When time is involved, we have a timebox present (be it implicit or explicit).  For many Agile frameworks and methods, timeboxing is foundational construct.

Popular in Agile Frameworks…

Agile frameworks and methods such as EVO, Scrum, XP, DSDM all make use of explicit timeboxes.  These timeboxes are traditionally very short periods of time (one to four weeks).  The different methods also prescribe the use timeboxes differently.  Some prescribe fixed duration timeboxes while others allow for dynamic duration timeboxing.

Most of the methods for which timeboxing is foundational associate a batch of work items with a single timebox e.g. completing a set of user stories in a Sprint towards a Sprint Goal.

Having individual work items have their individual timeboxes (fixed date) for is more common in the Kanban Method, which, in my opinion, also uses dynamic duration timeboxing.

There are pros and cons with the different ways that timeboxes can be used.  There are also external factors that need to be taken into consideration when deciding how to use timeboxes.  Be open to experimenting and trying new things if your team works with timeboxes.

In The Wrong Hands…

Any construct can be misused and timeboxes are no exception to this.  The misuse of timeboxes by senior leaders, managers, Scrum Masters, Product Owners etc etc has led to the falling out of favor of timeboxes in many software development circles.  The timebox is essentially used as a weapon against teams instead of an instrument of help for teams. The pressure of the two-week Sprint is something that many teams have come to dread and sadly it shouldn’t be so.

A lot of this misuse has it roots in Theory X thinking where organizations operate with the tacit assumption that people dislike their work and will do anything to shirk responsibility hence external control and direction is required in order to make sure individuals in the organization do work. With this mindset in place, timeboxes are used as a control mechanism by people in positions of “authority” (such as managers, Product Owners and Scrum Masters) BUT not the team itself.

Have you worked in or know of organizations where teams are told by someone outside of the team of HOW much work they need to get done in a Sprint or iteration before they even started and then are measured based on this as the progress?  Some popular Agile scaling frameworks (that will not be named) come awfully close to reinforcing such practice.  In these cases, timeboxes rule the teams instead of the teams ruling timeboxes.

There Is Still Goodness…

However, just because something can be (and is) misused doesn’t mean it isn’t useful. Timeboxes are very useful when used as a technique by teams for their own self-control and self-management.  When timeboxing is used to bring focus to goals and aims, it can be particularly helpful.  When used to ensure feedback is occurs in a timely fashion, it is also beneficial.

In my next post, I’ll take a look at practices that can help teams minimize the need for explicit timeboxes.


Projects Are Temporary…

I recently tweeted the following: 

Projects are meant to be temporary/transient endeavors for creating ‘new’ things. Both the PMI and PRINCE2 definitions of project management makes this very clear.  A review of project definitions show that projects are temporary because they have a defined beginning and a defined end.  The end is defined before we even start the project.  Aspects of the project such as the funding, the team(s) and other resources needed by the project are also intended to be temporary as the endeavor is transient.  Projects are also intended to be unique or as I like to put it, one-and-done type endeavors. When the project is done, it’s (supposed to be) done.

Examples of projects abound.  We don’t need to look very far to find them. Right now, the road that runs through my village in Eastern Nigeria is being tarred – it is a project.  It’s a temporary endeavor with a clearly defined end that was established at the onset of the endeavor.  Other examples include endeavors such as remodeling your kitchen, building a fence, moving servers from one datacenter to another datacenter or helping your 3rd grader come up with a collage of his Nigerian heritage.  You get the point; projects are temporary one-and-done type endeavors.


As the diagram above shows, not all endeavors are “temporary, one and done”.  The category that is of the most interest to us is that of endeavors that are long-lived with repeating activity as most of the software developed in organizations belongs to this category (regardless of whether the software is for external or internal use) as the software is evolved until it is no longer needed or used by anyone.

It’s imperative that organizations understand the nature of their endeavors so that they pick the most appropriate approach for handling them. Long-lived endeavors need an approach that is different from the “project” approach. Treating long-lived software development endeavors as if they are projects yields sub-optimal results.  These sub-optimal results will be the focus of my next post on this subject.

Addicted To The Status Quo

Are we are addicted to the old status quo?  Could it be that all change initiatives we participate in are just a facade?  Lipstick on a pig?  Fun and games?  Could it be that the way it is, is the way we really want it to be? I could get into examples but I’ve decided to protect the innocent today.

How can we tell?  Well, change often implies that we enroll in some way new of thinking.  A different set of values (supposedly) become important to us.  We make decisions based on fresh set of principles.

I get that.  So pray tell, how can we tell?  Ask yourself this: what happens when things get tough?  When things become uncomfortable? Do we revert to our old values and principles?  Do our entrenched mental models step into high gear?  What behaviors emerge?  Old or new?

I often find in organizations (faith-based, social, work etc etc) that we talk a good game about how we want to change and how we intend to act differently.  Unfortunately, our actions speak so loud that no one can hear what we’re saying (Jeff Van Gundy). Our behaviors are unchanged.

I’ve always believed that true change can only come about by assessing if our actions as invidivuals and groups are congruent with our (new) values and principles and then asking for help when they are out of wack.  Change is hard.  Good intentions are not enough.  A lot of humility is required.  The humility lacking in many of us.

Are we addicted to the status quo?

Sequential Agile Software Development

Is there such a thing as “sequential Agile software development”?  Possibly.  Maybe.  Look at your process.  How many phases does a piece of work have to go through before its complete?  How many (in)formal stages does your process have?  How about sign-offs?  How about handoffs?  Interestingly enough, the hallmark of the strawman referred to as Waterfall is the fact that work passes through different phases in a sequential manner just like a bottle of Coke goes through the bottling process.  Until work is completed in one phase, work in the next phase cannot be started.  Is this how your process works?  Is it possible that you have mini-waterfalls occuring in your iterations? #justasking.

But Eb, product development phases have to be sequential you say.  At least that’s how we were taught. Yeah, I remember those classes as well.  But let’s think about it.  Is it possible (for example) that certain test activities can occur while code is being developed?  Can testing commence after some code is checked in even if the story is not 100% complete?  Can different disciplines perform activties on the same work item in parallel?  Can we challenge ourselves to identify how we can all contribute concurrently to the completion of a work item?  Do we even have these conversations?  Please don’t tell me you won’t know when the work item is ready for you to work on it.  What happened to face-to-face conversation and all its 21st century incarnations?

Classic Agile task boards are famous for having only three phases: To Do, In Progress and Done (or something similar).  The goal is that everyone should be working together concurrently and collaboratively on the items “In Progress”. Phases should overlap such that there is no value in explicitly calling them out because the work item cycles through each phase quickly and concurrently.  Could your team get by with three phases?  If the answer is no, why? How many phases do you need?  Do your phases foster a true spirit of teamwork and collaboration?  Is this an area worthy of inspecting and adapting?

The essence of this post is not to suggest that every team should have only three (or any number for that matter) phases but rather to spur us to take a hard look at how we’re working as Agile team and consider whether our process fosters as much collaboration as is possible or leaves some collaboration on the table.  Are we dependent on handoffs and sign-offs?  Can we only pick up an item after its completely through a previous phase?  Are we really more waterfall-esque than maybe we’d want to admit?  To start and finish together, the team needs to work on the same things together. Take a look at the image below, which type reflects your current process?  Hopefully at least Type B? Maybe Type C?


Image Credit: The New New Product Development Game – HBR

I’m a Manager, I Manage People

Ok, stop.  I mean it.  Stop this moment.

Is a manager supposed to manage people?  NO.

You, dear manager, are supposed to focus on creating an environment that enables people to excel at their job.  I’m not making this up.  Take some time to read the work of Deming and Senge, you’ll see that I’m not off my rocker.  Then again, as a manager, how come you haven’t read their work?  Oh, that’s right, you were probably just promoted into a management position and asked to figure it out on your own.  Don’t worry, that’s what happened to me as well.  There is hope for us.

I’m sorry you’ve been misled and that the prevailing management theory in use is still from the Stone Ages.  I’m sorry, very sorry.  I have a confession.  I was also brought up (or is it brainwashed) to think and act that way as well.  Yes, I do find myself at war with myself at times as the flesh wants to revert back to “old way”.  So no, I am not judging you.  I’m challenging myself as I challenge you.

Trust me, there is a better way.  A way that makes work more enjoyable for everyone.  I’ve experienced it.  I need for others to experience it.  While we’re at it, let’s stop talking about “empowering people” as well.  I think we can do better.  It doesn’t reflect well on us.  It suggests we have power to give others power.  What’s that?  Hubris?  I used to use that word all the time.  I’ve stopped. I think we all need to stop. And since we’re stopping the use of words, why don’t we quickly add “resource” to that list.  But this could all be wishful thinking on my part.  Old habits die hard, don’t they?

But I got sidetracked there, the point of this post is to remind us (managers) of what our focus should be on if we really want to make a difference in our organizations.  Focus on the system.

What’s In A Hashtag

The #NoEstimates hashtag continues to get a lot of action on Twitter.  It might be something Vegas will want to look into at some point (smile).  I’ve decided to take a break from the Twitter action as I’ve often found the discourse between those who don’t share similar views (including myself) to often border on being petty at best and outright violent at its worst.   However, whenever I have thoughts on the topic, I’ll try to share them here.

So let’s start off with the #NoEstimates hashtag.  I’ve seen a lot of commentary that the hashtag implies either “never estimate” or “no estimation at all”.  I understand how some can interpret it that way.  The definition that Woody Zuill provided as his is:

#NoEstimates is a hashtag for the topic of exploring alternatives to estimates for making decisions in software development.  That is, ways to make decisions with “No Estimates”.

For me, the type of estimate that this primarily covers is the type that the software development teams I’ve worked with are most often asked to provide i.e. developer estimates.  These are generally of the “how long” or “duration” flavor.  I know others experience different flavors but these are mine.  So are there ways we can make certain decisions without having to answer a “how long” type question?  I’ve already provided a story where a team was able to without estimates at a certain level but I hope to go into more detail over the next days/weeks.  This is not to say that this question never needs to be answered. As a side note, there is also a lot of talk (from me as well) about how estimates are misused in many software development shops and while this is true, I don’t believe it should be the focal point of the #NoEstimates discussion except to say that if we don’t need estimates (in certain cases), we reduce/remove the opportunity for the misuse.  A lot of work still needs to be done in using estimates correctly and I think our energies would also be well spent continuing to talk about that as well but I digress.

So while the original definition may be broad and general and while the hashtag should have possibly been something like #SometimesEstimateAreNotNeeded or #HowToMakeCertainDecisionsWithoutEstimates or #WorkingInSuchAMannerThatEstimationAtACertainDepthIsNoLongerNeeded, I think it would be helpful if we can get to the spirit of the topic and focus less on the letter of it.  In the same manner that I’m not aware of anyone who believes NoSQL means “never use SQL” but is a contextual solution,   I’m not aware of  anyone who believes that developer estimates are always needed to make software decisions.  I also believe this is still a good conversation to have as Ron Jeffries pointed out almost a year ago (even though I don’t know if he still feels that way now) in spite of unanswered questions. In my experience, understanding why a developer estimate was needed has provided some enlightening moments.

Here’s to hoping we can move beyond the hashtag and get to the topic.  My fingers are crossed.

Spending Other People’s Money (Responsibly)

One of the comments to my recent post on estimation is that people want to know how much “a thing” will cost.  I totally agree!  They also want to know how long “a thing” will take.  Once again you will find no disagreement from me there!  I understand that people want to ensure that their money is being spent responsibly.  I do too!

The issue is not really about what people want as much as it is about whether you can give them an honest, accurate and beneficial answer.  I believe the nature of the (knowledge) work you do highly influences your ability to do so.

If you happen to provide a service/solution that is highly repetitive, for example, your organization specializes in the development of tele-medicine websites, then the odds are that after doing this for a while, you’ll have enough data and experience to pull from such that if you are asked for a cost/schedule estimate, you’ll be able to provide one with a high level confidence and probably with a narrow estimate range  (this will prevent people from rolling their eyes when you give them estimates).  This doesn’t guarantee that it will cost what you say (because stuff happens), it just means that because you have the requisite experience, you can confidently predict (assuming all things remain equal) the outcome.  I know this first hand, as my basement certificate of occupancy inspection which should have been done in a few days has been delayed due to the polar vortex and a subsequent inspection backlog.

But what if you don’t happen to provide such a service?  What if you happen to be one of the many product development companies out there that spend their days developing brand new stuff? One of the product development companies that is learning what to build based on customer interaction and feedback?  How do prove that you will “spend our/their money wisely”?  Of course, you can fall back on some reliable estimation techniques out there, give them the possibly outcomes and then subject your team to the burden of that.  That is definitely an option.  It’s just not my first (or second really).  I suggest another way.

Tell them you don’t know (yet).  Tell them that that you’d like to take an approach that is focused on learning, risk mitigation and building trust. Tell them you’ll focus the team on the highest priority item(s) for a few iterations and then have an inspection with everyone involved.  If this is a contract type situation, they pay for those iterations only.  Tell them that if they don’t like the progress, then discussions can be had around what can be done better (or even if the team should continue).  Assuming the team continues, over subsequent iterations, the team will learn enough to begin “predict” cost and schedule (if that is truly needed).

I know this sounds unreasonable but progress is dependent on the unreasonable man isn’t it?


After typing this, I realized that the question of “how much” and “how long” could also be an indicator of a bigger dysfunction within an organization, low trust.  In my experience, in high trust relationships, organizations trust that the team(s) is making every effort to get things done as soon as is possible. If you are in an environment of low trust, what can be done to change that?

How About #NoEstimates?

Let’s get this out of the way from the very onset.  I don’t believe estimates (and estimation) are evil and should NEVER be used.  Now that we have that out of the way, let me share estimation stories about two product teams.

Product Development – Commercial

There was a software development team that did annual releases of their software product. The team size was fixed as management realized that it was hard to have more than a certain number of people working on the same codebase at the same time.  Every year they’d spend a couple of weeks estimating items that were to make up the release.  They would decompose big items into smaller items that they thought were easier to estimate.  They would estimate by assigning hour ranges to the items assuming a sustainable development pace i.e. an individual working 35 or so hours a week. The estimators were experts in both the domain and the technology.  These estimates became a commitment of sorts because the plan(s)  for the year that went to upper management were based on the estimate they provided.  In spite of experience of the team, they would always find themselves scrambling at the end of the year, working at an unsustainable pace and having uncomfortable discussions on what needed to be cut.  After a while, the concluded that was just how software development worked.

Product Development – Internal Use

There was an internal IT software development team building a product to support a new service that the company would be providing.  Even though business leaders had a “general idea” of what the product needed to do, there was uncertainty as to exact pieces of functionality that needed to be provided and the order that these features would need to be provided in.  In other words, the “requirements” were fluid because everyone was still learning about the new service that was being offered.  The organization determined how big the team size would be based on a set budget and then set the team off the work.  For two years, this team worked without estimates, rather they would identify the work item of highest priority (note that these were the smallest slices of functionality that provided value) and would focus as many people they could (swarm) to complete the item as quickly as was possible.  When the organization decided that more needed to be delivered, more individuals were added to the team.  Over time, the team learned that in the worst case, in 6 weeks an item of value could be delivered.  At a certain point, there was a change in leadership and the new management team wanted the development team to provide single point estimates for a long (pages) feature list to which the team obliged.  This new management was uncomfortable with single point estimates returned and that led to a lot of back and forth with the development team until the team decided to give management what they wanted to hear/see.  As the saying goes “nine women cannot have a baby in one month”, and the team members told themselves that it was going to take whatever it would take regardless of whatever numbers they had provided. 

I realize that these two scenarios do not capture every product development scenario under the sun but that’s not the point.  The question in my opinion is this: Is estimation required all the time?  Should we just provide an estimate every time we’re asked to do so?  Some would say yes, but I beg to differ.  The act of estimation should provide value, in many cases, significant value.  If it isn’t, it’s most likely a waste of time and cause of much (unnecessary) pain.  It’s been suggested that professionals just provide estimates.  I disagree.  Professionals create/provide value and if an activity is a non-value add then it should be okay to have a discussion about the necessity of that activity.

 In the first story, we see that the team, estimated all the time.  But did they really need to?  Both cost (team size) and schedule (yearly releases) were practically fixed and they knew the items of highest value that had to make the release.  Could they have operated without estimating at all?  I’d venture to say yes.

Then there is the question of when something will be done.  Well, as we see in the second story, if we get into the practice of delivering working software in regular and frequent intervals, we can actually predict more effectively yet differently.  The team in story two was able to predict that in the worst case, after six weeks, they would deliver something of business value.  Note however that they did not predict when ALL the business value would be delivered as that’s a different game entirely.

There are those who believe that cost and schedule must be determined upfront at all times via estimates.  Is this true?  Are there not situations where cost and schedule are pre-determined via other methods as identified in the stories?  Isn’t it a concern if decision making is solely driven off of estimates?  It may surprise you to find out that this is very often the case in software development shops because its the easy (lazy) thing to do.  This results in teams often working on the shortest job with the least amount of value.

If we estimate, it’s because we need this information as an additional input into our decision making process.  The estimate must be of value and the more valuable the estimate needs to be, the better our estimation approach needs to be.  However, this requires that we’ve already estimated the value of the initiative we are undertaking ( when we have no estimate of the value of initiative, why are we estimating how long it will take or how long it will cost?  Of what value is the estimate in that particular scenario?)  and are trying answer questions such as the following:

  • Is the effort required to create something worth it?
  • Will the job complete on time for us to realize the value we estimated on it?
  • Which job should I start since I have two jobs of the same value?

If you believe that in your situation you need to answer the questions mentioned above, then I’d suggest the following:

  1. Read a good estimation book like How To Measure Anything before you start
  2. Use mature estimation techniques like Monte Carlo
  3. Gather a decent understanding of variation and how it applies in  your context
  4. Realize the output of mature estimation techniques is the probability of a set of different outcomes
  5. Plan based on the set of outcomes (and not just one outcome)

This applies to those asking (managers) for estimates and to those providing (development teams) estimates. Unfortunately many senior managers (vice-presidents, general managers, C-level execs etc etc) that I’ve come in contact with are not as educated as they should be about estimating in knowledge work.  This is extremely unfortunate as a manager with a misunderstanding of estimation, is unfortunately a very dangerous manager.

It has been suggested that any estimation is better than no estimation.  Um, I don’t think so.   At least, that’s not my experience.  Estimation done poorly, improperly or recklessly is harmful as unrealistic commitments are often its product.  Stress and de-motivation and a shoddy product follow shortly thereafter as its by-products.  

Some of us have gotten very good at gaming estimates and as a result have convinced ourselves that we are good estimators i.e. we are always spot on .  But let’s be honest now.  How about the extra hours you made the team work by reminding them of the estimate?  If your estimate is correct, how come the team did not work at a sustainable pace throughout?  Why did you decide that certain features can be deferred to the next release?

If you are the business of doing projects (hard start/stop dates) then I can also understand how the idea of always estimating may be essential to you.  But if you are in the business of developing and growing a strategic product over decades, then I believe there are other approaches that can be leveraged.  After all, the decision about whether to build the product has already been made.

I respect the fact (and the people) that some (many probably) within my profession believe that we must always estimate but I simply disagree with them.  I would hope that they could respect my opinion as well.  I will suggest you take a look at your particular situation and determine if estimates are critical to being successful at what you do.  Conduct an experiment of working without estimates if its possible.  If estimates are crucial to your success, then I charge you to estimate responsibly and if they aren’t, well how about #noestimates?

Learning In Small Batches

How do you learn?  Have you ever taken the time to think about that? Do you learn in large chunks or small batches?  Do you think it matters?  As one who cares a lot about how people learn, I believe your approach can influence the effectiveness of your (and others) ability to learn.

In the last eighteen months, I’ve had the opportunity of teaching music of comparable difficulty to a choir.  (Disclaimer: I am not a music teacher).  I was pretty excited about this opportunity and wanted to make sure that the choir learned the song as quickly as was possible.  I figured that the best way of ensuring success was to go over as much of the song as was possible during each practice session i.e. learn in large chunks. Um, bad idea!  At each practice session, it was evident that we were not making much progress as we spent significant time reviewing what we (thought) we had learned in previous practice sessions, in fact, we would find ourselves starting from the beginning again.  This pattern repeated for many months until we learned the song and performed it.  In spite of eventual success, I couldn’t shake the feeling that there had to have been a better (and easier) way that I could have facilitated the learning experience for the choir.  Did it need to be this difficult, painful and long?

Fast forward a couple of months later and I was presented with another opportunity to teach another songpiano2 to the same group.  I really wanted the experience to be different but I didn’t know what to do differently. One morning, I was up early, practicing a piano piece that I was going to perform and as I practiced I began to reflect on how I was practicing.  It dawned on me that I practiced the piano piece measure by measure i.e. I would repeat a measure until I was comfortable with it and then proceed to the next measure in the piece.  I never really attempted to play through a new piece at once.  In fact, I only played the entire piece once I was pretty comfortable with all the measures leading up to the very last measure.  Could such an approach work with those learning to sing a new piece of music?

I decided to put this approach to the test.  When I started teaching them the new song, we started with the first section and just practiced (repeated) it until we had mastered it.  Only when we had mastered the first section did we move on to the next section.  Our practice sessions started by reviewing sections we had mastered previously and then we would go on to learn a new section.

So how did things turn out?  Well, in a month and a half, the choir had learned the song and was ready to perform it.  It basically took half the time to learn the second song as it had the first song with the major difference being the way we had decided to learn.  By learning in small batches, we had completely changed both the learning experience and the eventual outcome.  What had really happened here?  Without going too deep into the science of it, at least a couple of things:

  1. By (seemingly) learning less per session, we  did not over the overload the short-term memory in the brain and made it easier for everyone to remember what we had gone over.
  2. “Repetition deepens the impression” – because we repeated the same (smaller) section multiple times, we kept re-entering it into short-term memory and as we did  so, it was facilitated the process of having the information transferred to long-term memory as the section became more important.

My readers with a knowledge of Lean or Agile thinking will know that the concept of small batches is not something new.  We talk about it all the time with regards to the flow of work in product development (and knowledge work in general).  It seems quite obvious, doesn’t it?  Yet, do you actually (explicitly) leverage small batches in learning?

How do you approach learning in your personal life?  In your relationships? Big or small batches?  For those of us that are coaches, managers or leaders, how do you encourage learning in small batches on your teams?  Does a monthly retrospective with the team or a yearly performance review with an employee lend itself to learning in small batches?  Does a three day course in [stick your favorite method here] facilitate learning?  Do you throw ten new practices at a team and expect them to learn them all at once?

I challenge you (in a friendly way) to ask and answer these questions for yourself.  The scary thing is this – if small batches are not involved in learning, it’s very possible that learning is not happening at all.  As we step into 2014, maybe its time to revisit how we learn.  As a former boss of mine used to say:

Remember, bite small so that you can chew fast.

Happy 2014!

What can we learn from the Indianapolis Colts?

The Indianapolis Colts are 0-5 and for one major reason – their star quarterback is hurt. Peyton Manning (who has been a symbol of durability for over decade) is out after having neck surgery and that has translated into five consecutive losses and my inability to watch the Colts play this season in essence making the NFL season non-existent for me (well except for a little thing called Fantasy Football).

Is there anything to learn from the Colts debacle? Possibly. Minimize silos and specialization as much as is practically possible. Create a culture of cross-functionality.

American Football is a sport that thrives on having specialists. It is rare to see a player actually play more than one position consistently except in special defensive packages and/or on special teams. In fact, player height and weight can be radically different depending on what position is being played. Offensive lineman are much bigger than tight ends.  Defensive backs and safeties are not very tall. Because injuries are common place, teams have backup specialists for each position. When a starter is hurt, especially in a key position like quarterback, it can have serious ramifications on the success of the team. (Did I mention the Colts are yet to win a game.)

Let’s look at another sport for comparison. Football (or soccer as it is referred to State-side) is another sport with defined positions. However, strictly speaking, there is really only one specialist – the goalkeeper. Field players generally can play different positions and be quite decent at them. Arsenal (my favorite club team) had to deploy Alex Song, usually a defensive midfielder, into a center back position due to injury for a couple of matches. Barcelona has done the same thing with Javier Mascherano. But beyond that, and this is even more exciting, during the course of a game, players change positions all the time. Fullbacks “overlap” into a winger position, midfielders make runs into a striking position (a technique Barcelona has perfected) or drop back to cover a fullback that has pushed up. Teams like Barcelona and Arsenal are renowned for the fluidity and movement of their players as they change positions on the field. The ability of the players to be cross-functionality allows quick adaption even during the course of a game.

I see software development being more like soccer than football.  The Agile movement made popular again, the notion of “cross-functional teams”. Instead of having a bunch silo-ed specialists on a team, adaptability and flexibility comes from having what one could call a “team of generalists”. A group of people with the ability to wear multiple hats and perform different roles. In fact, I believe it was for this reason that some Agile methodologies use only the “developer” title for members of the development team. A “team of generalists” can respond to team changes such as vacations, departures or even the simple need to swarm on a given initiative in much dynamic way than a “team of specialists”.

Beyond just having generalists on a team from a skill perspective, it’s also important to have generalists from a domain knowledge perspective. All too often, teams will have generalists from a skill perspective only and still promote specialization in aspects of the application.  For example, Susie is the only developer who works on the invoice module.  Well what happens if Susie is out?  While specialization may seem more efficient, it reduces the ability of the team to respond to change and change is certain.  Remember, that in knowledge work, the concept of a backup is more of a fallacy than a truth.  If you are not actually doing the work, then you don’t know how to do it.

So how do we develop cross-functional teams? It’s critical to establish the culture of cross-functionality especially considering that it goes counter to prevailing reward systems that esteems specialization. Teams need to be educated differently. Practices and techniques like pair-programming, rotating work assignments, cross-training, wikis, documentation, collaborative design sessions should become part and parcel of way of life for the team.

As an exercise, take inventory on both who knows what and who can do what on your team. This will show how cross functional your team really is and where the team is exposed.  Fill those gaps, you don’t want to end up like the Indianapolis Colts.