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.

Posted in Software Development, Organizational Learning, Leadership | Tagged , , , , , , , , | Leave a comment

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

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

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

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

Not Just An Agile Thing…

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

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

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

Popular in Agile Frameworks…

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

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

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

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

In The Wrong Hands…

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

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

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

There Is Still Goodness…

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

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

Posted in Design and Architecture | 1 Comment

Time-boxes, goals and realizing outcomes

Goal is defined as:

the end toward which effort is directed” or “the object of a person’s ambition or effort; an aim or desired result.

I don’t understand the debate over the Sprint Goal.

I also don’t understand how a teams can function and focus without goals (be they implicit or explicit although I would suggest that there is a danger in not making goals explicit).

If a team carves out a fixed set of time (a time-box) to do some work, they already have, albeit implicitly, established a goal i.e. completing a certain amount of work in a certain amount of time.  I don’t consider this type of a goal to be a best goal we could come up with because it’s output focused and you know I favor outcomes over outputs.  I will concede however, that this type of goal is probably better than no goal at all.

From the Scrum Guide, the Sprint Goal is:

an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

Seems pretty straightforward to me with a lot of latitude for the Scrum team to create their goal.  What do you think?

If your time-boxed work period has no goals, no aims, no objectives, no desired end what exactly is your team doing?  Where are you headed?

(I’m pretty sure some folks reading this are thinking to themselves that time-boxing is an archaic practice and should be dropped altogether.  Stay tuned for my next post).

And while this post has focused up till this point on teams working with time-boxes, I will go even further to suggest that any team that is developing and delivering software in support of a broader organizational vision – yes I’m looking at all the teams that say they are using Kanban out there –  that doesn’t have time-bound (see Agile Manifesto Principle #3)  goals is operating irresponsibly.

Goal are very useful.  Use them wisely.  Use them well.

Posted in Software Development | Tagged , , , | 1 Comment

Projects Are Temporary…

I recently tweeted the following: 

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

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

projects-are-temporary-products-are-not-1

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

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

Posted in Design and Architecture | Leave a comment

Predictability in Software Development – Part III

In Part I and Part II of this series, I challenged the popular perspective on predictability in software (product) development and suggested that if an organization needs to respond rapidly to the changes in its ecosystem, it needs to value adaptability over predictability at least “in the large”.  However if innovation is not critical, then valuing predictability over adaptability may be the better thing to do.

What role (if any) does predictability play in product development?  This is especially important because – as mentioned in the first post of this series – many people in positions of significant authority demand predictability from their teams.

Even though it would seem that I’ve spoken against predictability, I do believe that there is often a need for teams to be predictable however I just consider this need to be predictable in the small.  Teams that are predictable in the small consistently complete about the same amount of work over a series of short time periods. Candidly, “short time periods” is dependent on your strategic and operational approaches to addressing business opportunities.  As a rule of thumb, however, I recommend that ‘small’ be 4 weeks or less.

For example, let’s say that a team forecasts the completion of ten items each iteration over the course of four two-week iterations and then has the following results:

Forecasted Delivered
Iteration 1 10 8
Iteration 2 10 11
Iteration 3 10 9
Iteration 4 10 9

Even though the team never delivered exactly ten items, we can see that they completed about the same amount of work in each iteration.  A basic understanding of variation will help us understand that the team exhibits predictability.

But wait a second, this seems to be all about outputs and I thought we were all about outcomes?  Actually we care about both outcomes and outputs and even though we value outcomes over outputs, we know that our outputs are needed for our desired outcomes to be realized.  So, understanding how much work we can complete in the small can help us determine what outcomes can be achieved in the small.

What practices can an organization and their teams adopt in order to help them be predictable in the small? Here are three:

Bite Small, Chew Fast

As a team, focus on value adding items that can be completed in a couple of days. Use techniques such as INVEST (for user stories) to decompose large initiatives into small chunks of value.

Less Is More

Take an essentialist approach to how much work the team takes on.  Less is often more. Minimize the amount of work that is progress.  Team members with different skills should collaborate on work items with the goal of finishing the work items as quickly as is possible.

Minimize Process Loss

Ivan Steiner came up with the equation AP = PP  – PL; that is, the actual productivity of a group equals its potential productivity minus process losses.  Process losses are those things that prevent our teams from being as productive as they could be.  They dampen the good we could potentially do.

Teams need to take the time to reflect on the things that are negatively impacting their performance and then address those things with both rigor and discipline.

(To be fair, these three things are good for any Agile team to pay attention to regardless of whether they have predictability demands or not)

The Conclusion of the Matter

And yet with all this talk about predictability, I’d be remiss if I didn’t make observations about predictability and the potential unintended consequences that arise from pursuing it in an unbridled manner:

  1. Describing knowledge work teams (especially product development teams) as factories or engines needs to be done with care.  Software development teams are not machines that are executing repetitive or pre-programmed activities.  Innovation means discovery.
  2. Just because a team is predictable doesn’t mean they are high performing or that they are delivering value. (Subject of a future post).
  3. Predictability, even in the small, is often at odds with innovation and creativity.  If you are challenging your teams to be creative and innovative and also demanding high levels of predictability from them, something will have to give.  Eventually.

So after three posts on predictability, where have we landed?  Are we adaptable in the large? Are we predictable in the small?  If you’re part of a real Agile organization, then adaptability and predictability are characteristics that your organizational operating model needs to support.  Its critical that leaders provide their teams with clarity on the business landscape and guidance how they need to balance the attributes of adaptability and predictability in software (product) development.

Posted in Software Development | Leave a comment

Velocity is NOT about Productivity

I happen to participate in a couple of Lean and Agile subject matter groups on LinkedIn. This is my way of learning and sharing.  In my opinion, any serious Agile practitioner should join and participate in such types of groups (no it’s doesn’t have to be on LinkedIn). I personally learn more from these groups than from workshops and certifications classes.

I’ve observed over the past year that not a week or two goes by without someone having a question around Agile velocity on one of these discussion groups.  Interestingly enough, their questions are never about how to use velocity for forecasting and/or planning. No, the questions are always about how to increase or improve their team velocity.  As an example, check out this very recent velocity conversation.

Why are so many of the velocity questions focused primarily on productivity?

Unfortunately, many of these well-intentioned posters find themselves in organizations where velocity is considered to be a primary measure of productivity.  Not only do organizational leaders use velocity as a measure of productivity, we find some Agile practitioners (sometimes unintentionally) doing so as well.  I’ve seen postings on LinkedIn where teams are congratulated for increasing their velocity.  I’m saddened and disappointed that in 2016 we’re still talking about velocity in this way.  I’m not sure what got us here but instead of simply complaining, I am compelled to share my thoughts in the hopes that it may help someone or some organization now or in the future.  Paraphrasing Peter Block, start with the room you’re currently in.

First of all, let’s agree on what velocity in the context of Agile software development is. Operational definitions are extremely important and I think defining velocity will do us some good.  Velocity can simply be defined as the:

Sum of effort estimates completed in an iteration (see the Agile Alliance reference for more information of velocity).

Any other usage of the term in an Agile software development context is a redefinition of the term.  Agile velocity doesn’t refer to how fast a team works.  It’s not even the count of items completed in an iteration (that could be throughput). It how much of our effort estimates did we complete in an iteration.  No more, no less.  That simple.

As the Agile Alliance article makes clear, velocity is primarily a planning instrument. Carefully read the article as it provides a pretty good explanation of the purpose of velocity and what it should be used for.  Pay attention to the common pitfalls as well.

(However I must point out that many Agile teams effectively forecast and plan without using velocity.  Stated differently, velocity is not a requirement for forecasting and planning.)

But maybe you still think that we should be able to use velocity to gauge how productive our team is.  Maybe the information presented so far is not convincing enough for you. In that case, let’s take a moment to dissect what it means for a team to increase its velocity.

If velocity is the sum of our effort estimates, increasing our velocity would mean that we have to increase the sum of our effort estimates completed.  On the surface, it may seem that this would be easy to do.  All a team has to do is increase the number of items it completes and their velocity will increase.  However, completing more items doesn’t assure us of a velocity increase because we can’t assume that our estimates are the same or larger than our estimates for previous iterations.  In fact they could be smaller and our velocity could actually decrease and yet it would be a good thing!

For example, let’s assume a team had a velocity of 20 points in Iteration 1, which meant they completed 4 stories each estimated at 5 points.  Then in Iteration 2, they had a velocity of 18 points after completing 6 stories, which were estimated at 3 points each. Were they less productive in Iteration 2 because their velocity went down?  What if they completed 7 stories in Iteration 3 and each of those stories has an estimate of 1 point? Are they still less productive?  How do we know?

Don’t forget that velocity is calculated using “effort estimates”.  Estimates are subject to many factors that I won’t get into in this article and yet its important to remind ourselves that each iteration the team is solving problems they have never solved before. The team effort estimates could go up due uncertainty and complexity and it would have nothing to do with how productive they are.

Determining how productive a team is based on how much of their “effort estimates” they complete totally misses the point.  I think Deming would refer to this as management malpractice.  It’s that bad.

And yet teams can easily increase their velocity.  In fact, it’s not hard at all.  All they need to do is make their effort estimates larger.  I’ve seen many teams do this in my career. I’m not sure your organization really wants that.  Riffing off of Goldratt:

Tell me how you’ll measure me and I’ll show you how I’ll behave.

So encouraging teams to increase their velocity is simply something organizations that are intentionally adopting Agile should not be doing especially if they don’t want their teams to game the system.  I will go further to suggest that using velocity to determine predictability (in the small) is in serious danger of missing the point of velocity as well. There are there better ways to do this and I will be addressing that point as I finish my series on predictability.  If you missed the first two posts, check out Part I and Part II.

After all this talk on velocity, I am moved to remind us that the primary measure of progress for an Agile team (and organization) is the amount of software that has been delivered to users and that the users find valuable. All other measures are secondary and tertiary.  Velocity can be used to help forecast and plan (and there are possibly better alternatives to it) but let’s not use velocity as a measure of productivity.  If you must use velocity, use it responsibly.

Posted in Software Development | Tagged , , , , | 1 Comment

Predictability in Software Development – Part II

My previous post asserted that predictability at the business or organizational level is having teams that consistently deliver solutions that enable desired business outcomes. These organizations and business are predictable in the large.  Predictable organizations have the ability to change course even as the ecosystem they are a part of changes.  Ergo,  my second assertion:

Your company values adaptability over predictability 

This is not to suggest that predictability is not important.  In fact, it is quite the opposite. In the ever-changing business landscape that now confronts us, organizations are required to adapt in order to survive.  In order to be predictable, organizations must be able to adapt.

(I will concede that it is possible that your business cares about predictability more than it cares about anything else.  I just don’t interact with a lot of those organizations these days.)  

Organizations that possess a high degree of adaptability have the capacity to change course in a largely frictionless manner.  They have the characteristic of responding to changes in the ecosystem and changing direction as needed, effectively and efficiently.

An organization can only adapt as quickly as its component parts can adapt.  More specifically, a product organization’s ability to adapt is a function of their individual product development teams ability to adapt.

Agile places tremendous value on teams being able to adapt as change emerges.   In fact the Agile Manifesto states that we value:

Responding to change over following a plan

and backs that up  with following the principle of:

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage value number

Many Agile practices enable teams be in position to respond to change in a productive manner.  Here are a couple of them (in case you’re not familiar with Agile practices):

  • Focusing on the “what” over the “how”
  • Working in small increments of value (days not weeks or months worth of work)
  • Short delivery cycles; weeks over months
  • Stakeholder feedback on a regular cadence
  • Pair-programming/test-driven development
  • Continuously running automated test suites that validate product suite
  • Feature teams developing features
  • (I’m sure you can add more to this list)
  • Etc etc etc

Teams that leverage all these practices (and more) are in a position to respond to change very effectively.  I find however that many organizations that claim to “be Agile” are only partially committed to a few of these practices and then wonder why it’s so difficult for them to change direction.  Coincidentally, these organizations seem to also believe that Agile is about delivering software faster.  (If that’s you, it’s possible that you’ve been misled).  To top it off, these organizations often respond to their inability to adapt by instituting heavy processes and protocols that are focused on ensuring that they won’t have to adapt!

Here is a thought exercise for you: If at this very moment, your team was asked to stop working on a particular initiative and release it into production so that your customer could start using it and the team could start working on a different mission, would your team be able to do it?  How many days, weeks or months would it take for your team to be able to release a product increment at this very moment?  Would you be able to release anything at all?

If an organization desires to be predictable in the large, its teams need to be able to effectively adapt in the small.  When teams holistically adopt Agile-based approaches to software development, they place themselves in a position where they can respond to change in a predictable way.  Could your organization and teams benefit from this ability?

But wait, we’re not done yet.  There is the little matter of predictability in the small. My next post will be about that.  Stay tuned!

Posted in Software Development | Tagged , , , | 2 Comments