Managing Self-Managing Teams

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We Have Come To Deliver Value!

The Agile Manifesto, in my opinion, is a decent document. By no means perfect, but still pretty good. I happen to interact a bit with a few of the principles on social media, and I get the sense that if they had written the document today, they might use different language in some places. But I could be completely wrong about that. Nonetheless, the Agile Manifesto is a pretty good and useful document that anyone interested in Agile should pay close attention to. (Many close “Agile” friends disagree with me on this point – they are all wrong).

Why should we pay attention? Because I believe that wrong, yet popular, interpretations of certain principles leads to some confusion. Case in point, most people I speak with, would have you believe that an Agile principle is “we deliver value.” That sounds like something any reasonable person would want to do. Never mind that the concept of “value” is a bit nebulous. Ron Jeffries, in his book, The Nature of Software Development, defines value as “what we want.” Well, who is “we”? Mark Schwartz, in his book, The Art of Business Value, makes the case that business value can be tricky to define. (Both great books by the way. If you don’t you own a copy; I’m not sure what you’re waiting for!)

The point is that value is hard to define. Value might not even be a fixed target. You know, complexity, double-loop learning, and all that jazz. For example, in an Enterprise IT setting where team members develop internal tools for other team members to use as part of the business processes, how would you define value? Where is the value created? When is it created? Who is the value created for? All great questions that require answers if we’re going to walk around telling people we “deliver value.”

But here’s the catch. The Agile Manifesto says something slightly different from what I hear people say. This is what Principle Numero Uno says:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Wait a second. Valuable software? Hmm. Is value shorthand for valuable software? Is that what people mean when they say they delivered value? Is that what you mean when you talk about value? Not in my experience. I think people have grander aspirations than valuable software. I think they’re thinking outcomes and impacts. I’m thinking it too. In fact, I’m not just thinking about it, I’m writing about it. I want the software I develop to help my organization achieve desired outcomes and have the intended impact. But does software have to create value (whatever that is) before we consider it valuable?

In my opinion, valuable software is software that people find useful or helpful. It’s software that is important. It’s software that makes those who use it more effective at their jobs. It’s software that’s beneficial to the organization. (Yes, I did use synonyms of valuable). It’s software that addresses the needs of the stakeholders. We know our stakeholders, right?

Valuable software may not always (at least not immediately) create value (desired outcomes and impacts) because value is impacted (excuse the pun) by many variables, many of which have nothing to do with software. In other cases, valuable software delivered is not intended to create value (as we often define it). And yet in other cases, connecting software delivered with value is near-impossible or at least extremely difficult.

Just because we can’t easily tie software changes to business value doesn’t mean we shouldn’t care about outcomes and impacts, we should. Our processes should give us confidence that our valuable software will eventually create value. But we can’t wait till it creates value to consider it valuable, can we? I don’t think so.

So what do we do in the meantime? I suggest we focus on delivering valuable software.

Should a Scrum Master Be “Technical”?

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

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

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

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

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

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

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

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

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

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

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

Are We Done Yet?

So is software really "Done" if it hasn't be delivered to those who would like to use it?

— Eb (@eikonne) June 8, 2017

Recently, there has a been a bit of talk about being done in the context of Agile software development.  If I’m not mistaken, as far as Agile frameworks go, it would seem that the Definition of Done as described by Scrum influences many an Agile team. We also know that there are variations on this as well such Done-Done and Done-Done-Done.

But when are we really DONE?

In some regard this depends on how we define done.  Is a movie done when production is over?  Is a presentation done when the slide deck has been prepared?  Is a meal done once it has been cooked?  Is a software increment done when coding and testing are complete?

Teams engaged in real (there is a lot of fake and dark Agile out there) Agile software development are guided by a set of 4 values and 12 principles.  The very first principle in the Agile Manifesto goes as follows:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

When we use this principle to guide how we define done, I cannot understand how we can consider ourselves done until we’ve delivered an increment of value to our customers. Not just deployed (and hidden behind feature toggles or something like that) but delivered such that our customers can interact with the increment in some form or fashion.

So the next time your team debates whether you are done, ask yourselves if your customers are using the increment.

(Thanks to Mia Augustine for inspiring this post).

P.S. IMHO Scrum’s Definition of Done (in the best case scenario) is really (more appropriately named) Definition of Ready To Be Delivered.

Tips For Working Without Timeboxes

My previous piece on timeboxes led to a fair amount of dialogue on Twitter.  Some of it was positive and some of it was critical.  However, a particular tweet (that led to some back and forth) stood out to me.

https://twitter.com/davekershaw/status/843472842150821888

In the absence of “real deadlines”, do we need to timeboxes to rein in our development teams?

As promised in the previous post, I’d like to share some approaches that teams I have been on have used to reduce their dependency on timeboxes.  I do want to be very clear that I have also used these techniques in conjunction with timeboxes.

Ruthlessly Delivering Small Increments Of  Value

Regardless of whether you use stories or not (all our work does not have to be represented as stories), I will encourage you to decompose your work into small bites of customer value.   The INVEST method (associated with user stories) is a good guide to use. Each ‘increment of value” should take a few days to complete. 

There is a common misconception that I often encounter which suggests that the bites of value a team works on should be exactly what will be “released” to the customer.  I believe this to be a grave mistake.  Let me illustrate with a common example.

Imagine a team is developing an API that supports GET, PUT and POST as methods.  Let’s also imagine that the team decided the API will not be made available to customers until all three methods are implemented.  Should this be treated as one bite of value or three bites of value?  Most technology folk I know will argue that it should be one bite of value because it will not be released until all the methods are supported.  I probably would have argued for this earlier in my career as well.  Well now I beg to differ.

It is clear (at least to me) that there are least three units of value available with this API and while it is true that all three methods need to be implemented before the API is made available, each method can independently be developed and validated for proper function. If each method was treated as its own “story”, we’d find that each story meets INVEST criteria.

But what difference does it make?  After all, nothing will be released until all three methods have been implemented.  That is fair point.  And yet I’m compelled to ask the following questions:

• Why would we delay (internal) feedback on the first method just because the second and third methods haven’t been implemented?
• Why would we couple the the release of value with deployment?
• What if it so happens that we learn that we can release the API progressively?
• Why would be knowingly limit the options of how we approach the work?

As I learned many years ago, “bite small, chew fast”.  There are many tips on how to split/slice stories.  Google is our friend.

Limit Work-In-Progress

Timeboxing, done right, helps us to be extremely selective about what we want to accomplish in a given timeframe.  We take the time to understand the capacity available to us and then select the most appropriate work that we think we can get done in that time period.

The good news is that we shouldn’t require a time constraint to explicitly limit our work in progress.  It’s a proven fact that the more work we have going on concurrently, the less we actually get done.  Unfortunately many organizations don’t pay attention to how much they have going on and instead attempt to ensure that they are operating near 100% utilization which invariably slows things down and ensure.  Teams are primarily rewarded for how busy they look.  I see many Product Owners struggle with limiting work in progress.

A word to the wise about limiting work in progress. If we don’t limit the size of the unit of value as well, we’ll still be working on items for an extended period of time with little to show for it.

Quantifying Desired Product Qualities

I am a fan of the work of Tom Gilb, EVO and Planguage.  If you’re not familiar with any of these, you should probably look them up (and also watch this talk by Tom).  I believe that there are ideas from Tom’s work that can be of help to those of us in the business of developing software products..

For example, when we say that our API should be fast, what do we mean by fast?  Or when we say that the website should handle a lot of users, what do we mean by a lot?  These are qualities that our solution is supposed to have that are often simply described in qualitative terms.  Qualitative attributes leave up to the imagination of whoever is responsible for ensuring that product has the desired quality.  In the absence of explicit quality attributes, teams succumb to pitfall of gold plating.

Specifying in quantitative terms what “goodness” will look like is critical if we want to stay focused and avoid going down rabbit holes.  One could argue that this is the Specific (S) and Measurable (M) from SMART Goals applied to our work items.

In summary, while I’m still a fan of using time boxes, there are ways of working that can reduce the dependency of a team on explicit timeboxes.  Regardless of whether you use timeboxes or not, you will still benefit from adopting these techniques as you do your work.

Should A Scrum Master Have A Goal To Make Themselves Unneeded?

It has become quite common to come across articles or posts that state that the goal of a Scrum Master should be to make themselves unneeded or as a colleague recently put it, “put him or herself out of a job”.  I disagree.

The role of the Scrum Master is clearly defined in the Scrum Guide.  To summarize, the Scrum Masters provides service and help to the:

• Product Owner
• Development Team
• The Organization at large

Suggesting that the goal of the Scrum Master is to make themselves unneeded is to suggest that the Scrum Master should be focused on either ensuring that (a) the services they provide are no longer needed and/or (b) someone else besides them provides these services.  In other words, ensuring that they are temporary!  In my opinion, this completely misses the point, is an unnecessary distraction and a potential source of much frustration.

The goal of every team member should be to make a contribution to the team in support of its quest to be successful and this includes the Scrum Master.  The goal of the Scrum Master should be to provide the help needed so that the team can effectively and efficiently deliver software that is valuable.  It is not to make themselves unnecessary.

How about coaching? Is that a permanent thing?  The Scrum Master coaches three distinct groups and even if the Product Owner and Development Team arrive at a point where they no longer need coaching, I’m not convinced the “Organization at large” in a complex environment (ever) arrives at such a point.  Never mind that the Scrum (Agile) body of knowledge continues to evolves, rarely ever does the system remain the same.  If you know of any organizations that have arrived at such point where they could no longer benefit from continued coaching, please feel free to share.

But for grins and giggles, let’s agree that it is actually quite possible for an organization to get to the point where (a) the help provided by the Scrum Master is no longer needed or (b) other roles in the organization can effectively and efficiently provide this help as it changes (because it will change).  In my opinion, this then is simply a by-product of the Scrum Master’s continued service to the organization and is not a goal that is defined upfront.

And yet, if you insist that the goal of the Scrum Master is to make themselves unneeded, then I have a book recommendation for you.  Check out  Obliquity: Why Our Goals Are Best Achieved Indirectly.  It might be beneficial to you on your journey to make yourself unnecessary or unneeded.

Modern or modern Agile?

I’m a sports geek.  I love sports. I love watching sports. I love playing sports. I love most things sports.

For my birthday last year, my wife gave me a wonderful sports book titled:  On the Origins of Sports: The Early History and Original Rules of Everybody’s Favorite Game.  If you’re a sports geek like I am, you’ll probably enjoy reading it.

 

The book takes a look at 21 different sports (including soccer, football, hockey, fantasy football and many others sports) in society today.  What’s wonderful about the book is that it guides the reader through the evolution of the different sports, from their origins to their current (or should I say modern) day form.

While there were many things that I learned while reading the book, a particular theme stuck with me.  In spite of the changes that occurred in a given sport, be it in the rules, the size of the playing surface, the nature of the equipment, the number of players etc. the essence (soul or spirit) of the sport remained the same.  The moment the essence changed, a new sport emerged.

What do I mean by the “essence” of the sport?  What is the “soul” or the “spirit” of the sport?  By essence, I’m referring to the core values, objectives and aims of the sport.  For example, in soccer, it’s kicking a round leather ball into the opposition’s goal and in basketball its bouncing and shooting a round ball through a hoop.  Regardless of how the infrastructure of the sport may have evolved, the values and principles of the sport were preserved.  American football has evolved since its invention in 1800’s and yet its essence has remained (largely) the same.

This brings me to my thoughts on the Modern Agile movement. First of all, I think there is a difference between “Modern Agile” and “modern Agile”.  I do like the things I see promoted as part of Modern Agile. I think Modern Agile may be attempting to define a new soul. I think Modern Agile may be a completely new game. I may also be completely wrong.

On the other hand, I consider “modern Agile” to be the evolution in the infrastructure that is used to play the sport of Agile.  In other words, it is the change in the practices that we use in support of Agile values and principles.  The essence of Agile is found in the Agile Manifesto and curiously enough, the Agile Manifesto actually starts with “…uncovering better ways…” and a principle that requires continuous inspection and adaptation. So Agile at its core demands evolution.  (Now I know that there are some who believe the Agile Manifesto has outlived its usefulness and if that’s you, then you’ve probably already moved on to a new sport).

The moment we decide to change the essence of Agile, I’m not sure it remains Agile. This could be the right thing to do. It could be that we actually need a new sport.  And we have recent examples of this such as the Lean Startup.  But even though both table tennis (ping pong) and (lawn) tennis have similarities, they are clearly different sports.  One is not the “modern” version of the other and it’s important that we recognize this.  Who says we can’t play more than one sport?

What say you?

 

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.

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.

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.