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.


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.

Agile Is Not The Goal

Or is it?

Ok, it isn’t but I’m tired of reading posts or comments via various outlets that try to remind us that business agility  (or whatever) is THE goal and Agile is not.  While there is truth in that, I believe that such statements lead to the proverbial baby being thrown out with the bath water and we end up with faux Agile – afterall it isn’t THE goal is it?

I play the piano.  I’m in the middle of learning a jazz arrangement of “Georgia” and I have THE goal of peforming the piece by the end of the year.  Let me repeat, THE goal is to be able to perform the piece by the end of the year. In order to achieve THE goal, I actually came up with a goal of practicing the piece daily.  (This goal has basically led me to get up at 4am for the past couple of days to practice).  If I don’t meet the goal of practicing daily, THE goal of playing “Georgia” by year end is in jeopardy. Practicing daily is a goal I have to meet if I want to achieve THE goal. It’s that simple.  Now it’s really easy to making practicing daily THE goal and lose sight of the original goal.  If I do that, I probably won’t be performing “Georgia” at the end of the year as well.  So I recognize that “practicing daily” is a goal I set to help me achieve THE goal of performing the piece at the end of year and ensure that my daily practices help me get closer to THE goal.

If you believe Agile (as in Agile Manifesto Agile) will help you achieve THE goal (whatever your goals are), then employ Agile (as a goal) such that it helps you achieve THE goal.  If you don’t think it will help you achieve THE goal, don’t use it.  It’s that simple.

Or is it?

Is Your Oven The Right Temperature?

A large number of organizations attempt to to have their software developments go “Agile” for a variety of reasons.  The sheer number of discussions in Agile discussion groups is a reflection of this craze. Many of these attempts fail and fail miserably.

A careful read of the Agile Manifesto makes it clear (to me) that the signatories anticipated a certain type of environment  for Agile software development to thrive in.  Consider the following principles:

  • Principle 4: Business people and developers must work together daily throughout the project.
  • Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • Principle 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.

Each principle implies a lot about the type of ecosystem in which Agile software development has a chance of being successful. Many organizations that are trying to do or be Agile are only aware of a set of codified practices and are oblivous to the principles that I just mentioned.  Unfortunately, the Agile manifesto itself doesn’t explicitly address the ecosystem needed for Agile to have a chance of being successful.  Organizations that are interested in Agile software development need to actually look to other sources for information on how to cultivate such an environment. Sources such as Argyris, Deming, Drucker, Weinberg, Ackoff, Senge, Hackman, Pink, Mintzberg (to list a few) are a great place to start for anyone who is interested. If you are a manager and most of these names are not familar to you, I would strongly suggest that you look them up.  In fact, if you get nothing else out of this post, I hope you just start a reading list.

The fact, however, is that many (if not most) large organizations have systemic structures (politics, hierarchy, funding models, appraisal systems, control systems etc etc) in place that are at odds with the structures needed for Agile software development to actually succeed.  Several thought leaders in the Agile space have largely given up on “the large organization” and have suggested that it’s waste of human potential trying to create the conditions for Agile to succeed in such environments.  Others have fused other methods such as Lean Thinking and Theory of Constraints to create a more holistic approach.  I’ve especially found the work of Bob Marshall (@flowchainsensei) and Rightshifting to be particular motivating for me in this regard.  Let’s take a look at few examples of organizational structures typically found in the large organization and the challenges they present to Agile.

Political Structures

The larger an organization, the more of an influencer “politics” is.  People protect their territory (which often includes other people) at the expense of the overall good of the organization.  Transparency is lost as a result of folks continually manuvering. Alliances form beind the scenes and nothing gets done.   In a highly political charged environment, Agile will struggle.

Funding Structures

If your organizations sees technology as an auxillary function (a cost center) that provides utility services then technology will be funded in a such a way.  Very often that funding leads to the execution of projects.  I’ve written in the past about projects and products so I won’t rehash that here.  But, in a nutshell, if your organization delivers projects, it may be challenging (or impossible) for your organization to be Agile.  (I realize that the manifesto uses the word, project. Don’t let that mislead you.)  On the other hand, if your organization sees technology as a strategic lever with the understanding that product development is primarily an exercise in discovery, then Agile may work for you as you’ll find that you work be doing projects.

Accounting Structures

This is related to the previous structure but it still warrants being called out explicitly.  Cost accounting or throughput accounting?  Your accounting structure can impact your ability to truly work in a Agile way. What accounting structures do you have in place?

Hierarchical Structures

Traditional organizational structures are largely Taylorist in nature. Managers (and this includes all titles involved in the management) are brought in to ensure that people (very well educated and compensated people mind you) are doing the right things.  I’ve also written about this recently and so I won’t repeat what I said.  I’m saddened by how many managers are unaware of the role of the manager in an organization.  Your organization will struggle with Agile if the organizations view on hierarchy and management remains Tayloristic.  If you don’t plan on making a true commitment to enable self-directed teams (see Hackman and Kimball) and network-based structures, then Agile is probably not for you.

Decision Making Structures

Heavily centralized or heavily decentralized ? What is prevalent in your organization? Do people have to run everything up the chain of command for approval before they can actually do their jobs?  Is information centralized in a “special few” (think Director of Agile Coaching) roles in the organization and nothing happens if they are not involved?  Is leadership at all levels promoted or does your organization just pay lip service to such an idea.  Are ideas valuable based on the title of the individual who came up with the idea or are all ideas considered equally?  If your organization doesn’t make a concerted effort to push information out to as many people as is possible to enable quick decision making, Agile may not be for you.

It has been said that “culture eats strategy for breakfast”.   A study of the Toyota Production System reveals how important the culture of an organization is.  I believe the same to be true for any organization interested in the Agile thing. Having teams try to do it on their own is (a) a local optimization and (b) not Agile.  An organization interested in Agile (and continuous improvement in general) needs to make a commitment to changing it’s existing structures if it realizes that its structures impede its ability to “do Agile”.

Your can have the perfect cake batter, but if you don’t bake your cake at the right temperature, you won’t have a cake.  Is your oven (organization) at the right temperature?  If no, what are you doing about it?  Can you do anything about it? Better yet, should you do anything about it?

Have You Seen The System Lately?

Have you seen the system?  Let’s start with a little story..

A father goes into his children’s bedroom to wake them up and get them ready for school. As he pulls the covers off of his daughter, he notices that her eyes seem a little cloudy.  He finds a thermometer and checks his daughter’s temperature.  It reads 101.7 F, she definitely has a fever.  His daughter’s school has a very clear policy that children should be fever free for 24 hours before being brought in to school.  This means Dad is going to have to call his employer and let them know that he won’t be able to make it in because he has a sick child he needs to take care of.  Seems pretty straightforward doesn’t it?  But is it?

Dad’s employer keeps track of how often their employees call in to say that they will not be able to make it in for one reason or the other.  Employees are dinged for not “showing up” and it affects their yearly raise and bonus.  It just so happens that Dad is one ding away from some significant repercussions.  On the other hand, the company does nothing if an employee comes in to work but has to leave because of a situation.  As long as you show up (even if its for just one hour) you are good.

Dad being fully aware of his situation at work, decides to take his daughter in to school fully expecting to be called to come and pick her up in just a few hours. In his mind it’s a win-win situation because he’ll still be able to take care of his daughter and not get dinged for not showing up to work.  What he doesn’t know is that his daughter will go on to spread her sickness to a couple of the other kids in her class.  He also doesn’t realize that the parents of these children work for organizations with the same “call in” policy as his and are also going to bring in their sick children to school.  His decision to take his daughter in to school has just triggered weeks of kids being sick in the class. In fact, his daughter will fall sick again a few weeks from now.

So what’s the system in this story?  Can you identify it?  Many of us might be quick to judge the father harshly for taking his daughter in to school but when you consider the structure(s) that influenced his behavior, you realize that there are a set of interconnected elements working together even though they may not be obvious to the different actors involved.

Wikipedia describes system thinking as:

…the process of understanding how things, regarded as systems, influence one another within a whole.

Dr Deming defined a system as:

…network of interdependent components that work together to try to accomplish the aim of the system

Peter Senge describes as system as:

webs of interdependence.

Russ Ackoff on the system:

A system is more than the sum of its parts; it is an indivisible whole. It loses its essential properties when it is taken apart. The elements of a system may themselves be systems, and every system may be part of a larger system.

and Ackoff advises that we should

…focus on the interactions of the parts rather than their behavior taken separately.

A team struggling with quality thinks that better or more QA people need to be added to the team or the iteration needs to be longer.  An organization struggling with product delivery has its development team go on an Agile transformation.  Confusion exists around what people should be doing, so an exhaustive writeup needs to be done to clarify this for everyone.  An employee is underperforming so they must be slacking and are put on a performance improvement plan.  There is no shortage of reactive analytical responses that show up in the  workplace on a day to day basis.  Yet these responses really don’t solve anything over the long-haul.  They are at best, cheap band-aids.  We are solving problems with the same mindset that we used to create them (Albert Einstein).  We fail to identify the components and the interactions between these components within the system.

When we take a systems view to addressing problems, we make an attempt to see as much of the whole picture as is possible.  We realize that our development team is part of a large product delivery organization.  We understand that the employee struggling with performance problems just had a new baby and is not getting much sleep at night but is on our most complex project.  We realize that product management is making commitments that are leading our developers to cut corners ultimately leading to poor quality.  A systems thinking view to problem solving causes us to look beyond where we “think” the problems are to identifying the different components and the interactions between these components that is actually leading to our problems.

Let’s be humble enough to realize that we may never see the whole system but at least we’re trying to.  Don’t be deceived, taking a systems view is by no means the natural thing to do because we are taught (from an early age) to break things up and address the individual components independently. I meet many people who say that they are systems thinkers but really cannot see beyond their nose in problem dissolving.  They just don’t know how to do it because they haven’t learned how to.  I’m still learning.  If you haven’t read the works of Deming, Senge, Ackoff and Weinberg (for example), you may want to start there.  We need to learn how to become system thinkers if we truly intend to dissolve our system problems.

Thanks to Bob Marshall (@flowchainsensei) for inspiring this post.

Outcomes Over Outputs

When you plan an event, what are you more concerned about?  The outputs or the outcomes?  At face value, these may seem to be the same thing, but are they?

Think about a soccer team involved a soccer match.  The outcome the team desires is to win the match (although if your Chelsea and your playing away it may be to draw the match).  In order to do that, the team needs to score goals  – that is its output.  Outputs lead to outcomes but in of themselves are not outcomes.  I think its very important to distinguish between the two.  Why?  Because chasing outputs takes our eye off the outcomes we desire.

For the purpose of this post, outcome is defined as “the end result“.  It could also be seen to be the goal or the difference that will be made.   Output on the other hand is the “material produced or yield“. From the definition alone, it follows to reason that outputs are not outcomes. A team can score 5 goals (output) and still lose the game (outcome) because the opposition scored 6 goals.  A delivery team can release software (output) and the customer be disappointed (outcome) because it doesn’t do what was expected.  A messaging team can move e-mail to the cloud (output) and users may not be able to access their e-mail (outcome).

Our analytical way of viewing the world would have us focus on outputs.  We like to break things down into its component parts and specify them in a neat and tidy way.  Outputs are easier to measure.  I was involved for over a decade in the design and architecture of a relatively large Supply Chain solution and have practically spent most of career (till date) designing and building platforms.  I’ve also spent a lot of time on teams where we developed processes to help manage our knowledge work organization and have experienced that process design is often done through the lens of the analytic mindset.  Remember, this is how we are taught in school.  It’s our default way of learning.  We devise solutions via decomposition.   Even though conversations start with outcomes in mind, the process eventually gravitates towards outputs.  Think of all the processes in your organization. Aren’t they by and large outputs trying to ensure certain outcomes?

Focusing on outputs instead of outcomes can prevent us from making the necessary adjustments required by our desired outcomes.  Outputs becomes proxy variables for outcomes.  What happens if you go to the gym every day (output) but don’t weigh yourself (for example) to see if you’re actually losing weight (outcome)?

Even in the wonderful world of Lean and Agile we fall in love with practices (outputs) and forget that the goal is to deliver software that delights the people that use it (outcome). Organizations fall in love with productivity (output) metrics and pay little or no attention to effectivity (outcome) metrics. It is critical to take time to reflect on how an organization is tracking towards its stated outcomes. Unfortunately many organizations spend more time auditing output compliance than they do outcome attainment.

I am not suggesting that outputs are bad and that we trash them.  Rather I am reminding us that what we often truly care about is an outcome.   We should value outcomes over outputs.  Our work should guided by the outcomes we seek.  Our teams should have a clear understanding of these outcomes.  As we assess our progress towards our outcomes, we should change our outputs to help us get there.


I’m a Manager, I Fix Problems

Well depending on what type of organization you are trying to help create, that could be a problem.

For business agility via Agile or Lean methods (remember methods are NOT the goal) to be highly successful in an organization, the organization must promote the concept of the self-organizing team.  This runs counter to the traditional hierarchical philosophy that is found in many (maybe most) organizations and often prevents organizations from having their teams perform at their highest levels possible.  In the traditional approach, the organization is largely dependent on managers directing their reports and solving the teams problems. Annual goals (and you know my thoughts on performance appraisals) are built around such an approach.   I find it interesting when a manager suggests to me how “Agile” they are and then begin to rattle off how many people they have reporting to them or how often they looked at the teams’ burn down chart or inspected their card wall to see how long things were taking or solved all the problems that the team had.  They are yet to realize that their behavior is not what is desired in the age of the knowledge worker. The manager who “fixes all the problem” is not a plus in an Agile environment.  They don’t realize that they are possibly the biggest reason why their teams will not become high-performing. To quote Drucker on the knowledge worker:

For, once beyond the apprentice stage, knowledge workers must know more about their job than their boss does–or else they are no good at all.

But the fact is that many organizations that are engaged in an Agile or Lean journey have a good number of good people in managerial positions. So what are they supposed to do if not manage team members and fix team problems?  I have a suggestion: focus on the system.  What is the system you may ask? Read this and this for starters.  Can you now identify the system you are a part of?

Management (hence managers) need to focus on creating an environment (system) in which their teams can excel.  This is also known as leadership.  If you are in management and consider your responsibility to be the “management of people” then, from a knowledge worker perspective, you’ve (unfortunately) totally missed it.  If you want to get into to management for the aforementioned reason i.e. fix the teams, please do us a favor and reconsider.  Don’t rob the team of it’s ability to learn and self-organize.  Your focus and attention needs to lie elsewhere.   As a manager, you need to help design a system that allows the teams in your organization to perform an excellent job.  A job that people want to do.  This unfortunately, is quite different from our classical view, understanding and training on management and requires a complete paradigm shift of our mental models.  This transition is not easy in organizations that reward managers for behaving in a completely different way.  So once it again, leadership is required to change the system.  Quoting Deming:

Remove barriers that rob the hourly worker of his right to pride of workmanship. The responsibility of supervisors must be changed from sheer numbers to quality.

Even though many workers are now salaried, the guidance is still relevant.  No Agile (or Lean) based transformation is complete without a transformation in the way managers conduct their behavior. Beware of consultants who peddle solutions that don’t require such a paradigm shift. Be sure of what you want.  Beware of Agile managers who are fixated on jumping into the team and solving their problems.  They are probably getting in the way.

Dear manager, focus on the system.  Fix problems outside the control of the team.  Design an environment that allows the teams in your organization to be successful.

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.



Estimates Are Not Commitments But…

Unfortunately, they very often are.  Recently, during an interview, I asked the candidate what they thought about the notion that “estimates are not commitments“.  The candidates answer was:

Once an estimate is put down on paper, it unfortunately becomes a commitment.

Performing a search for estimates are not commitments returns a good number of results so this is not really a new subject.  Yet, to be fair, it’s important to realize that many of the articles are authored by individuals in the Agile software development delivery space so do we have an agenda?

In previous articles, I’ve tried to define what an estimate is, so I won’t repeat that here but suffice it to say, that an estimate is an approximation of a measure.  On the other hand, a commitment is defined as the following:

  • an act of committing to a charge or trust
  • an agreement or pledge to do something in the future

So its very clear that estimate and commitment are not one and the same thing.  How is it then, that estimates are very often interpreted and/or immediately translated to commitments?  I’m not sure I have a good answer for that yet, but I’d love to your feedback!

What I do think is important is understanding what the the requestor of an estimate is looking for.  An estimate?  A commitment?   The response for each could be remarkably different.  So when you are being asked for an estimate (and let’s just assume for a second that one is truly needed), make sure you understand what you are really  being asked for.

Estimates are not commitments.

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!