Managing Self-Managing Teams

Managing self-managing teams sounds like an oxymoron. I assert that it isn’t. Hear me out.

Central to my position is an understanding of management (managing), self-managing, and the manager role.

Management refers to the collection of activities required for the healthy functioning of an enterprise. These activities include planning, organizing, measuring, budgeting, coordination, etc. We can lump these activities under the umbrella of “managing.”

Researchers (as far back as the 1970s) have described self-managing teams as groups of individuals who can self-regulate on whole tasks. Dr. Richard Hackman developed a typology that includes self-managing teams. Other team types include manager-lead teams, self-designing teams, and self-governing teams. Hackman’s typology below describes teams based on their management responsibilities.

Last but not least, a manager is anyone assigned managerial responsibilities (and not just people with “manager” in their job title). This means that a Vice-President in a software development firm is a manager because they have management responsibilities. I will not wade into the nonsense I consider the manager-leader distinction. That will have to wait for another day.

Bringing this home to product development, a self-managing team has responsibility for executing the team task and monitoring and managing work process and progress. “Executing the team task” requires little explanation and is pretty straightforward to understand—the team has full responsibility for completing the task required to achieve desired outcomes.

Self-managing teams also have responsibility for managing how they get their work done and monitoring their progress on their work. Of course, the team must have the competencies to do this well. It’s not enough to declare a team self-managing and expects that they can now magically “monitor and manage work process and progress” effectively. Self-managing is not without its challenges, and anyone who suggests its a panacea is not being truthful.

(While I have you, let me share that I prefer self-managing over self-managed because it speaks to the ongoing nature of the management activities the team is responsible for.)

Hackman’s model makes it clear that “other-managing” will focus on other aspects of management, i.e., “setting overall direction“ and “designing the team and its organizational context.” A self-managing team is not focused on these aspects of management. These aspects can be the responsibility of a manager. It will be the responsibility of some individual(s) outside the self-managing team.

The effective manager of a “self-managing” team will continually ensure the self-managing teams have the resources needed to succeed. The manager will address external friction impeding team progress. The manager’s role is to provide external managerial support so the team can self-manage. And this is managing—managing a self-managing team.

Now it’s easy to try and establish a clear separation between the focus on the manager and the focus of the self-managing team based on typology. Doing this would be a mistake. While the responsibilities are distinct and can be analyzed separately (to a degree), the responsibilities interact and influence each other.

For example, when direction or organizational context changes (and it will), the self-managing team needs to know to adapt their processes appropriately. Conversely, the self-managing team needs to make its progress transparent so the manager can use this information in direction-setting and organizational context conversations. 

These interactions don’t change the locus of responsibility. Rather the interactions remind us that everything is connected and the importance of healthy feedback loops.

I firmly believe that many product development contexts would benefit from (at least) self-managing teams. We know that the more autonomy people have over their work, i.e., what they do, and how they do it, the more meaning and fulfillment they derive from work. The more committed we are, the more we positively contribute to our organizations.

Self-managing teams are rare in product development organizations despite many senior leaders claiming them. I believe a key reason for this is that many senior leaders in organizations do not understand how to foster self-managing teams. They often give mixed messages. On one hand, they tell teams they want them to be self-managing, and on another, they tell managers they are accountable for “monitoring and managing work process and progress.” Well, what do you think happens? 

Many managers feel a strong desire to control. It’s a natural expression for many of us. Additionally, our organizational socialization leads us to believe the only way to control is to take over the responsibilities of self-managing teams. Without proper training in other management areas, while enabling self-managing teams, managers focus on what comes naturally. So manager-led teams continue to dominate the landscape.

Organizations need managing. While self-managing teams manage critical aspects of their work, they will also need management support if they are going to achieve organizational goals. Managing self-managing teams is not an oxymoron.

Should a Scrum Master Be “Technical”?

This is a pretty popular question in Scrum circles that recently came up on LinkedIn (again).

In order to answer this question, I believe we first need to define terms “Scrum Master” and “technical”.

Merriam-Webster provides this as a definition for the term technical, “having special and usually practical knowledge especially of a mechanical or scientific subject” while the Business Dictionary provides the following for its definition, “pertaining to computers or technology”.  For the purposes of this post and in the context of Scrum as a process framework for the development of software products, technical, will simply mean “understanding the technologies and being able to engage in the software development activities involved in the process of creating software products”. Technical, is not a synonym for “software developer” or “computer science major”.

For the definition of Scrum Master, we don’t have to look any further than the Scrum Guide which provides us with the following as it relates to the Development Team:

The Scrum Master serves the Development Team in several ways, including:

  • Coaching the Development Team in self-organization and cross-functionality;
  • Helping the Development Team to create high-value products;
  • Removing impediments to the Development Team’s progress;
  • Facilitating Scrum events as requested or needed; and,
  • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

I highlighted “helping the Development Team to create high-value products” because it stands out separately from “coaching the team”, “removing impediments” and “facilitating events like retrospectives, refinement, and standups”. What does it mean for the Scrum Master to “help the development team create high-value products”? Pretty vague, isn’t it? It would seem to me that the interpretation is largely left to the Scrum Master (and the Development Team) on what help they can provide. In my opinion, helping includes the Scrum Master to directly engaged in the value creation process.  In other words, the Scrum Master can directly act on the software product as its being developed. (For what it’s worth previous versions of the Scrum Guide said something much stronger when it came to helping the development team: https://webgate.ltd.uk/scrum-guide-2013). In helping the team, the Scrum Master still needs to respect the empowerment given to the Development Team.

I don’t know how a Scrum Master can effectively engage in core software development activities without understanding what’s going on from a technical perspective. In the Scrum community, there is a ton of focus on coaching, facilitating and removing impediments. I have no intention to diminish the importance and necessity of these activities but these activities do not act directly on the product that is being created.

I don’t see a lot of conversation around how the Scrum Master can help with the core activities of software development if need be.  In fact, I read many posts that seemingly discourage Scrum Masters from becoming directly involved in value creation. It’s taboo to ask (for example) if a Scrum Master can test, write stories or even code if need be. I’ve interviewed many a Scrum Master who didn’t really care about how things really got done or worked because they believed that this needn’t be a concern of theirs or as they often put it, “I’m not technical and I was told during my training that I didn’t need to be”.

Maybe we’re compensating for bad practices we observed such as the making of the Lead Developer a part time Scrum Master. However, I don’t believe that we effectively address dysfunction by reinforcing other dysfunctional practices.

So, should a Scrum Master be technical? I believe the answer is yes but that is only if the Scrum Master wants to be able to help act directly on the software product being developed. Otherwise, the answer is obviously no. I encourage all the Scrum Master’s I work with to be as technical as they can comfortably be.  As a Scrum Master, the choice is ultimately yours.

Thoughts on “Managing” Software Development

I’ve written in the past on management and managers and you can find some of those thoughts here however I want to share some additional thoughts.  These thoughts are basically my answer to the question of: what does a Software Delivery/Development/Engineering manager do?

(Even if you’re one of those who believe managers are not needed in knowledge work, I’ll crave your indulgence to read on).

(I do believe that Software Development/Engineering Manager are better role names than Software Delivery Manager but I digress).

It is dangerous to define the job duties of a role without taking into consideration the guiding philosophies of an organization.  For example, let’s just look at the concept of the manager. The definition of management (and hence managers) in an organization that adopts the principles of Frederick Taylor will be markedly different from that of an organization that adopts the principles of Edward Deming.  In other words, roles are not defined in the abstract.  The organizational philosophy ultimately defines the role.

I belong to the school of Deming when it comes to management, and as a result, my definition and description of a software delivery manager is going to be based on Deming’s view on management and managers.  I posit that real Agile and/or Lean organizations take a similar stance.

A software delivery manager is a “manager of software delivery” and if we decompose the role into its component parts we have manager and software delivery.

Douglas McGregor basically describes the Taylorist manager as person who works with the assumption that:

…workers have an inherent dislike of work and hence needs to be directed, controlled and threatened with punishment in order get them to work hard to achieve company objectives  

The Taylorist manager is all about control and external direction ergo this manager focuses on defining how the work should be done by the individuals on the team and then measuring individuals to ensure they are meeting pre-determined targets the manager defined.  This manager leaves little room for individuals and teams to self-direct as these managers need to do all the planning and provide all direction.

So how does Deming describe as the role of the manager?  According to Deming (excuse the gender-specific tone), a manager:

  1. Understands how the work of the group fits with the aims of the company. He teaches his people to understand how the work of the group supports these aims.
  2. Works with preceding stages and following stages
  3. Tries to create joy in work for everybody
  4. Is a coach and counsel, not a judge
  5. Uses figures to help understand his people
  6. Works to improve the system that he and his people work in
  7. Creates trusts
  8. Does not expect perfection
  9. Listens and learns
  10. Enables workers to do their jobs

Deming is not alone in his thinking.  Other management thought leaders such as McGregor, Drucker, Ackoff, and Senge all share the same thoughts.

If I were to summarize, I would say that the role of the Agile (and some would say modern) manager is to:

Create an environment where people and teams can do their best work for themselves and the organization in a manner that is both rewarding and fulfilling

The modern manager realizes that s/he is dependent on their team to be successful.  The team is also dependent on the manager.  In a nutshell, the team and the manager are interdependent.  The manager and the team share in the responsibility of developing and delivering software.

(If you work for an organization that says they are Agile and but exhibit Tayloristic management tactics, I hope for your sake that the organization is in the early stages of Agile cultural adaption.  If they aren’t, you’ve been warned).

So we’ve defined manager but how about software delivery? Software delivery is simply the aim of the system that the manager and their team(s) belong to. This system has the goal of delivering software that addresses the needs of stakeholders.

What then are the duties of the software delivery manager?  Here are a few that immediately come to mind:

  • Provide clarity to team members and teams on organizational objectives and what achieving them entails
  • Define operating constraints and boundaries for teams in which they operate
  • Provide teams with the appropriate authority, resources, information and accountability
  • Provide career guidance and coaching to individual team members and teams
  • Staff teams appropriately within budgetary constraints.  Manage their budget responsibility
  • Partner and network with other managers in the organization in addressing organizational impediments
  • Provide feedback to the teams on the software that is being developed.  Engage in product “inspect and adapt” sessions.

What else would you add to this list?

While we’re talking about software delivery teams, I need to remind us that in Lean and Agile organizations, the work is done by cross-functional teams.  The implication of this is that software delivery teams will often be composed of individuals from more than one functional group in the organization.  A software engineering delivery manager will often need to team up with managers from other functional groups in the organization e.g. infrastructure manager and together they will provide the team the support it needs.

It’s also important to remember that Agile teams (regardless of the framework of choice), as a part of being cross-functional, have a role on the team responsible for championing the product (or something similar to a product).  This role, often referred to as the Product Owner, and not the software delivery manager, decides what the team should focus on.

So there you have it.  These are my thoughts on the Software Delivery/Development/Engineer Manager.  I anticipate that some readers will disagree with me.  Please share your thoughts in the comments.  But as you disagree with me, take a moment to explore why it is that you disagree with me.  In fact, I would implore that you examine the underlying philosophy and mental models that inform your definition. Where do they come from?  Do you know?  Are they based upon Taylor’s Principles of Scientific Management, Deming’s principles or something else?  

Our actions reveal our beliefs.

Predictability in Software Development – Part I

Recently, I’ve been part of few conversations regarding predictability and commitments.  It is the opinion of some that Agile teams should be able to make and keep their Sprint commitments as it pertains to outputs (points, stories, card counts).  It has also been suggested that measuring a team’s consistency on delivering on committed deliverables (outputs) is a good metric.  After all, the thing our businesses values the most is predictability.

Here is the challenge I have with these assertions.  They are based on the premise that the team should know enough about how they will address problems such that they can make a highly confident prediction on what they will complete before they actually start the work i.e. pull it into a Sprint (or do something equivalent).  Is this the case for the problems your teams solve? Is your team highly certain on how to solve problems (both functionally and technically) before they actually start solving them?

The Chinese restaurant around the corner from my house is very good at telling me how long it will take for my vegetable fried rice order to be ready because they do that multiple times a day.  My barber is very good at telling me how long it will take to cut my hair because he’s done it for me for the last five or so years (and I haven’t changed my style).  The folks who change my oil are pretty good at letting me know when to come and pick up my car.  They’ve been changing my oil for almost eight years.  Are your teams solving the same (or similar) problems from Sprint to Sprint?

I often find teams spending a ton of time (days) upfront trying to determine what needs to be done so that they can make and meet their commitments.  If they discover that they will not be able to meet their commitments,they take shortcuts (specifically in code quality) to ensure the commitment is met. When they don’t meet their commitments, they begin to look for someone on the team to blame.  If they can’t find someone on their team, they look for someone on some other team.  Are these the behaviors you want on your team(s) and in your organization?  To be fair, with a heavy dose of upfront planning, a set of stable requirements, stable technology, stable team (and a bunch of other stable factors), you may be able to achieve such predictability in a non-damaging manner.  What are you willing to pay to reduce uncertainty to a point where your team always deliver output targets?

I believe some of the mass movement to Kanban is as a result of the commitment pressure uninformed leaders place on their teams.  The distortion of Scrum – Dark Scrum – has led teams to look for alternatives. Unfortunately, this is the wrong reason to make process changes but people will do what they need to do to feel safe (and in the process mask real problems).

My tone so far probably leaves you thinking that I believe we need to punt on predictability in its entirety in software development and just let things evolve as they may.  That’s not the case. However I do strongly believe that it’s critical that we (especially business leaders) appreciate the uniqueness of software development and the challenges around predictability that it presents.

What does predictability really mean in software development?  Is it that a team consistently completes a certain number of points or stories in a given Sprint?  Would that make them predictable?  Possibly, but that’s not my opinion.

Agile is concerned with managing the unpredictable nature of software development and delivering on business outcomes ergo Agile teams that are “predictable” are teams that consistently deliver solutions that enable desired business outcomes.  My next post will look into this further.

Does Your Agile Process Mimic a Production Line ?

Disclaimer: This post is for individuals, teams and organizations genuinely interested in Agile.

I am noticing a certain trend in software development where teams make their software development process mimic a production line by treating each software development activity as a separate station.  Their “boards” make every activity a separate column.   A number of teams do this in the name of implementing the Kanban Method while others do it because it represents what they are used to.  Why is this the case?

Two reasons immediately come to mind (I’m sure you can think of more):

  • Work items take more than a few days to complete
  • Work items are acted upon in a sequential manner

If your work items consistently take more than a few days to complete, what actions is the team taking to address this?  Have you asked yourselves why?  Is the nature of the work such that working software cannot be completed in a few days?  Everything has to take a few weeks or months?  Is the team focused on too much stuff at the same time?  Maybe everyone is working on their own unique items and is not working together (collaborating) to complete items in a timely manner?  It is a known fact that the less work we have in progress, the more we get done and the less time it takes. In spite of this known fact, many organizations/teams/individuals fail woefully at limiting work in progress.

I still find teams that believe software development has to be sequential (in the small) just like a production line.  Many have described this as mini-waterfall.   Each role on the team represents its own “workstation” and for the work item to be completed, it needs to pass through all the workstations via hand-offs.  A classic indicator of this is a team where the testers complain that they have no time to test in the Sprint (another reason why teams abandon time-boxes for Proto-Kanban).  For example, a user story would “flow” in this manner:

Analysis -> Design -> Code -> Test -> Deploy

(The fact of the matter is that if it takes a few days to complete a user story, these activities would overlap to the point that making them explicit would provide little value.)

What if instead of having work move in a sequential manner we have all the roles performing their activities on the user story concurrently?    What if the work item was the center of the universe with multiple actors acting on it at the same time?  What could happen then?

There are some major implications with this approach.  For starters, it would mean we focus multiple team members and roles on as few work items as is possible.  A business analyst, engineer and tester (for example) all working together at the same time on the same thing.  If you don’t think this is possible, let’s have a chat.  Or perform a Google search.  Or ask an Agile practitioner.

This is a fundamental shift in the way we traditionally approach how we work in software development. (In the first Kanban system I ever designed, it was a rule that more than one person should be working on a item that was in development.  Team members and partners in the other departments initially found it strange as they were not used this but eventually came to appreciate this approach as it enabled us to deliver software more effectively.)

The feedback I receive from people when I bring topics like this up is that things are working just fine and hence they have no reason to do anything different.  No reason to decrease the time it takes to complete user stories. No reason to change the way they work on their work items.   In my opinion, these people have totally missed an important point about Agile (and Lean) and that is the relentless commitment to continuous improvement. The commitment to finding better ways to do our jobs even when the current ways seems to work well.  The commitment to being the best we can be. These individuals, teams and organizations are completely missing a critical component of the Agile mindset. 

So does your Agile process have to mimic a production line?

Respect, Show Some More

I’ve recently spent a lot of time thinking about the notion of respect and its importance in social settings.

How would our interactions be different if respect was present when we engaged?  For example, if we intended to respect all the participants in a meeting, would we still dominate the meeting with our own opinions or would we share the floor with others?  What if a team member wasn’t performing at a high-level?   Would we take the time to try and understand what was getting in their way?

Because I’m actively involved in Twitter dialogue, I’m often saddened by conversations that become “insult parties” when people cannot agree.  As I recently tweeted:

Respecting each other doesn’t mean we have to agree on everything and anything.  In fact, that would probably be unhealthy.  For example, there are a few people in my Twitter circles who have suggested that we redefine Agile or move beyond it to something more “modern”.  I disagree with some of these thoughts (and that’s substance for a subsequent post) and yet I still respect them and respect the fact that they have that view even though I don’t agree with their opinion.

Respect (in my humble opinion) is even more critical when an individual is involved in cultural change (change management) initiatives.  As an Ibo boy growing up in a Yoruba community, I learned at an early age that taking the time to understand the differences in the cultures was an important form of showing respect.  If I wanted to be able to influence, I needed to respect (even if I didn’t agree). Later on in life, I was introduced to the famous Stephen Covey maxim:

Seek first to understand, then to be understood.

(What should we do when we’ve totally lost respect for an individual or group of individuals?  I’m curious to get your thoughts.)

Being respectful of others can be especially challenging in certain circumstances. Let’s keep trying.

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?

sequentia_vs_overlapping.gif

Image Credit: The New New Product Development Game – HBR

Are Projects Your Only Option?

It’s often suggested to me  (via Twitter, LinkedIn, work – thanks Karen),  that I’m anti-project managers in Agile (or Lean).  This is incorrect (although I am opposed to the way many project managers (and managers in general) actually work but that’s a post for a later date).  I do however, have strong opinions on our usage of “projects” in software development.  It is the project approach that often leads to the engagement of project manager.  These feelings are right up with my thoughts on the usage of the word “resources“.

In the loosest sense of the word, a project can be anything.  It can be driving to work, taking a shower or entering time at the end of the day.  But we all know that’s a bit silly, we just call those activities.  The PMI institute has a definition for project which I like but then uses a software development example that muddies things a bit.

So what is a project?  I answer it this way: Is the scope (outputs) needed to achieve the outcome and end investing known – to a large degree – upfront?  If the answer is yes, then it feel project-y to me.  I’ll admit that this is probably incomplete, but it get’s me started in my assessment of what I am working on. For example, if I choose to remodel my kitchen and largely establish what done looks like from the onset, then I believe I have a project on my hands.  How about porting a database from Oracle to SQL Server or moving from Java to J++ to C# (yes I’ve done those things and they are not pleasant)? What about upgrading servers from one operating system version to the next or developing an integration pipeline with a partner so that they send/receive files to/from a system? How about developing and delivering a software solution based on defined scope as is practiced by custom software development shops – and is probably the example PMI is referring too.

These all seem project-y to me as the outputs needed for outcomes to be met and investment to end are known upfront.  The decision to stop investing is largely driven by the fact that certain outputs have been delivered. Hopefully outcomes are met as well.  This doesn’t mean that discovery doesn’t happen during the process (a good reason to leverage Agile and Lean techniques) but the path is largely charted.

On the other hand, what about building out a supply chain solution or a personal health monitoring platform or a tele-medicine platform (my latest project er I mean startup)?  What about starting a blog or having a family (ok now I’m stretching it)?  Are these projects?  Maybe if one takes a very liberal definition of the word yet I think not. These endeavors are journeys where the end is in often vague and obscure.  In a weird way, we actually hope there is no end (at least not soon).  We may have some ideas of the outputs needed but we also accept that we are (hopefully) going to spend a lot of time learning about more outputs needed to achieve our outcomes.   This is exactly why I spent over a decade at one organization developing a single product.  Tell me what’s temporary about that!!  We stop investing when we are no longer learning (or making money or having fun).

Should you be approaching your work a bit differently?  Are projects your only option?

PS: The project approach to software development can lead to a bunch of bad (organizational) habits but that’s for a later post as well.

If You Choose Agile, Do It!

I feel like I may get some pushback for what follows but here it goes….

(You can apply the following to Lean, Kanban, Theory Of Constraints etc etc).

You don’t have embrace the Agile approach to software development.  I’m yet to find a mandate that suggests so.  Please share with me if you have one.  You don’t have to agree with the Agile Manifesto as well.  If any of these things has been forced upon you and you disagree with them, make a change.  You deserve it.  It’s your life after all and life is just to short to be stuck doing what you don’t want to do.  Take care of it.

But if you decide to do the Agile thing, please spare me (yes me) from trying to rewrite the manifesto to suit your own agenda.  Let’s stop giving people a pass on calling anything they are doing Agile.  I’m talking about big A Agile here.  The one guided by the Agile Manifesto.  I’m not suggesting we be judgmental and all high and mighty about this but we need to be truthful to ourselves.  It’s ok to be on your way to embracing the values and living the principles as it’s a journey but be explicit about that fact and stop trying to redefine Agile to suit your situation and instead focus on moving your situation along. Trying to fit Agile to your situation is sort of like saying you are a vegan but you only eat meat on Sunday. Really?  That just doesn’t work and you can do better than that.  Either you are a vegan, working on becoming a vegan or have no intention of being vegan.  All three things are fine, but let’s not be deceptive about it.

It is a curious thing that the authors did not specify a bunch of practices that must be followed.   I imagine they wouldn’t have reached consensus because practices can be a tricky thing.  That’s ok, a number of methods/frameworks/practices that existed before and after the Agile Manifesto are available to  choose from.  You can evaluate how well these practices tie back to the values and principles outlined by the Agile Manifesto and how well they will work in your organization. The body of practices continues to grow as we identify additional ways to effectively deliver software.

Agile is not an exclusive choice.  You can do other things in addition to it if you please.  You can evolve beyond Agile to something else if that’s what you think you are doing.  You have many options here.  Just be clear about what it is you are doing.

Is Agile THE goal?  No.  It is one of several ways to the goal.  If you choose it, then do it.  Don’t redefine it.

 

 

A Town Called Commitment

In honor of Doctor Who being back on, I thought we should talk about a town called commitment.  This is a town where everyone goes around making commitments to one another.  One day, Madame Mayor called for a town meeting.  At the beginning to the meeting, she said, “I commit that we will get through all the agenda items we have today…”.  Just as she finished speaking a blue telephone box with the words Police Box began to materialize in the middle room…..

Tardis Tour Wales 2013 (2)

Recently, I suggested that estimates are not commitments and advised that when teams are asked for estimates, they should make an effort to understand if they are truly being asked for a commitment. Simple, right?  Well, not so fast my friends.  Commitments are an interesting thing with implications and ramifications on both individual and team behavior.

I once heard the story of a man who made the commitment to his dying wife that he would never remarry because he loved her so much.  Years later, he met someone he feel madly in love with.  What do you think happened to his commitment?  If you make a commitment to attend a friends wedding, you are pledging to be at that friends wedding.  You have made a promise (yes a promise) that you will do whatever you can do to be at your friends wedding.  That’s a commitment.  When we make commitments, we are implying that we have a lot of control over the final outcome.  Some of you reading this are probably thinking that I’m taking this commitment thing a bit too far. Um, I don’t think so.  My experience in life would suggest to me that when people say they are making a commitment to something, those who hear the commitment are largely interpreting it as a promise for the individual to do what they have said. This is why there is disappointment and frustration when commitments are not met.

Others may read this and say that anyone who sees a commitment as a promise (or something similar) is making a mistake and shouldn’t. But why shouldn’t they? Isn’t that at the end of the day what a commitment really is?  Why would we attempt to redefine commitment in certain contexts?

Commitments inherently runs the risk of not being met.  That is just a fact of life.  Inclement weather can hit your town grounding all the flights and making it impossible to get to your best friends wedding.  You can meet someone you fall madly in love with and remarry.  What you thought would be a few lines of code changes turns out to be something much more involved.  Things happen.  Things happen every day. It’s important to realize that the more people that are involved in making a shared commitment, the larger the risk of it not being met. (This is another reason for small(er) teams in software development but I digress).  After playing team sports for most of my life at a pretty competitive level, I learned that lesson the hard way.  This is why you’ll rarely see a coach commit to wining a game (outcome) and most players would hedge on doing so.  I mean we all saw how it ended for LeBron and Heat after promising “…not one, not two, not three…”.

Commitments also come in conflict with one another.  Making a commitment to one thing very often impacts commitments to something else. Daily, I have to excuse myself from one meeting I committed to in order to attend another.  Its not uncommon to ask a team to be committed to quality but then also ask them to commit to delivering X number of stories in an iteration – which commitment do you expect them to honor when there is conflict (and there will be a conflict)? The quality commitment or the number of stories commitment?

Commitments made too early can also lock us into a solution prematurely and prevent us from exercising other options that we may have had.  We see this when teams make a wholesale investment in a particular solution to a problem making impossible to leverage any of the other options on the table. (Yes enterprise/solution architects, I am talking to us).

This is the very reason why we should be careful what we make commitments on and when we make those commitments.  In knowledge work (and software development in particular), I suggest considering the following when thinking/talking about commitments:

  • Do not make goals, commitments
  • Have (and understand your) options
  • When (and if) you have to make commitments, make them at the last responsible moment
  • Choose commitments to behaviors and causes over commitments to particular outcomes
  • Consult people before committing them to a cause or outcome
  • Don’t make a commitment  you don’t think you can keep
  • When you make commitments, do your best to honor them

I had started this blog post before I read http://commitment-thebook.com/ but I would encourage anyone who hasn’t read the book to do so.  Some insightful nuggets are contained within it.

Commitments are valuable and precious, use them wisely.  Now that sounds like something the good Doctor would say.

 

Credits:

Photo of Tardis: By Rept0n1x (Own work) [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0)%5D, via Wikimedia Commons”