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: 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?


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 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.



Photo of Tardis: By Rept0n1x (Own work) [CC-BY-SA-3.0 (, via Wikimedia Commons”


Doing Wrong Things Righter

It was the fall of ’98 and I had been in the United States for barely over a year.  It was the beginning of a new semester and I was looking forward to seeing a friend who had been away for the summer. When we finally met, I was  excited and happy and wanting to let her know that I had missed her and that she looked good after the long summer break I proceeded to say:

It is so good to see you, you look so healthy.  It looks like you gained some weight!

Now, before you judge me, you’ll need to understand that I had lived in Nigeria (for a long time) leading up to that and at that time, in Nigeria, telling someone that they had gained weight (which was very different from telling someone they were overweight) over the summer was a compliment – it meant that they had a good summer break.  The school year was stressful and difficult and most of us ending looking a bit worn for wear by the time summer holidays came around.  I was innocently doing something I considered right.

Nonetheless, she wasn’t too pleased with my observation and so I proceeded to tell her what I meant, explaining to her what the compliment would have meant in Nigeria.  Well, as you can imagine, that only worsened the situation.  The more I talked, the worse it became.  Eventually she just walked away.  It took weeks of profuse apologies to get back into her good graces.

Whenever I remember that experience, I think of the Russell Ackoff quote:

The righter we do the wrong thing, the wronger we become.

I had initially said the wrong thing but in trying to right the wrong with my explanations, I just ended becoming wronger.

In knowledge work (and other types of) environments, “doing wrong things righter” is prevalent. It is almost the order of the day.  Many solutions are simply local optimizations with the wrong focus.  When we discover that they are not working and we try to improve (our wrong) solution, it makes the solutions even wronger. These solutions end up hurting both people and our economic goals. Examples of such “wrongs” in product development that I have observed include:

  • Having different roles in a challenged software delivery team fix their problems in isolation
  • Add more QA checks and inspections to prevent defects
  • Improving the estimation of things that shouldn’t be estimated in the first place.
  • Big design upfront in an attempt to lock down things (Agile teams are guilty of this as well, just in smaller time boxes)
  • Top-down driven policies to combat quality issues
  • Adding more layers of management because people need to be managed
  • Adding more people to a team so that things can be delivered faster
  • Scaling – I won’t even go there
  • Etc etc etc

(For the non-product development people who read this blog, I’m sure you can find similar items in your domains.)

So how can we avoid doing wrong things righter?  Well this goes into field of Systems Thinking and I’d encourage you to explore that.  But real quick, here are some thoughts:

  • Be open to the fact that you may have been doing the wrong thing the entire time
  • Understand the problem – the true problem and not just symptoms or side-effects. 5 Why’s can be valuable here.
  • Understand the system or systems in which the problem was discovered – don’t look at things in silos or parts. Be holistic in your approach. Understand the network of interactions; the value stream of work.
  • Attempt to dissolve (not solve) the problem if you can – this means remove the conditions that create the problem in the first place. Design new systems and structures.

Don’t get caught up in efficient ineffectiveness.  Don’t do wrong things righter.  Focus on doing the right things.  It’s easier said than done, but it is the right thing!