Agile Accelerate

Leave Nothing on the Table

Category Archives: Coaching


by Leave a comment

Deliver Features to Customers 5 Times Faster

Does it seem to take a long time for your company to get a feature out the door? Have you done a “Five Whys” on the problem? Does one of the root causes seem to be the number of dependencies between teams, or “steps” that it takes to get something out the door? Chances are that it has something to do with the way your teams are structured.

The debate between feature teams and component teams is as old as Scrum is (which is getting to be Keith Richards territory). It usually boils down to:

  • Component teams are more efficient because a small number of SMEs who know the code inside out are the most effective to work on that part of the code. Anyone else interfering in the code will make a mess and create technical debt.

And the discussion about possible restructuring ends there.

It ends because there is also often a hidden reason why leaders don’t want to move to feature teams. If pressed, the following concerns may emerge (if not pressed, they will stay under the radar):

  • “As a leader, I am defined by the component I own, and the team(s) that work on it. I am also a SME in that component, which gives me job security. Moving to a feature team model would be threatening – Would I have a team? Would my people be scattered across multiple teams? How would i have time to attend all of those teams’ meetings? Would i still own a component?” And so on.

We will address these concerns later. But first, let’s look at a real case study…

I was a transformation coach at a large software company that was struggling with exactly this issue. Minor customer requests or enhancements seemed to take forever to deliver. So I worked with a colleague to do a deep dive into the problem. We selected a simple feature enhancement that took twelve weeks to deliver once the work began and inspected every Jira ticket that related to it. The following graphic shows the dependencies between all of the teams that were involved in the solution. It is blurred intentionally of course.

Each swim lane represented a different team – front end, back end, UX, globalization, various components, etc. What was fascinating about this investigation was that the aggregate amount of time expended by all of the teams was six times what a single team could do. Not because any of the teams were inefficient – on the contrary, they worked on their tickets efficiently. But, if it only took a day or two to do their part, it basically sat in the queue waiting for the next team to pick it up. And that was where the end-to-end inefficiency was.

I used the Flow Efficiency metric to get a sense for the level of our problem. Flow Efficiency is defined as Value-added Time/Total Elapsed Time expressed as a percentage. In this case, elapsed time was 6 sprints or 12 weeks (60 working days). The aggregate value-added effort was about 60 staff-days. But this metric is usually calculated on a per team basis, which is a straightforward calculation for a single team. However, when multiple teams are contributing to the Value-added Time, Flow Efficiency would be overstated. One can divide by the number of teams, which in this case would have given us a Flow Efficiency of just 8% or so. But I think that is misleading. So we used a modified metric, which was, effectively, “How long COULD it have taken with a single cross-functional team” versus “How long did it actually take?” With that metric, the Flow Efficiency was 16%.

This data was presented to senior leadership and was considered to be very eye opening. The obvious solution would be to create cross-functional feature teams. Of course, there were concerns:

  • New teams accessing code bases they would be unfamiliar with (of course, this points to deeper issues, like lack of automation and existing technical debt)
  • Loss of ownership of components and people (as mentioned above)
  • Some features might not lend themselves to the approach
  • A general concern about disrupting the organization

To make a long story short, we took an approach that addressed all of the concerns, which consisted of these elements:

  • Start small with a pilot program – we created 6 new teams, which represented only 10% of the org
  • Have a change management process to onboard middle managers and team managers
  • Designate SMEs on the component teams to reserve some bandwidth to help people who are new to the code base with software design decisions
  • Implement a fast-feedback continuous improvement program to quickly address concerns and resolve issues
  • Establish measurable metrics to represent the goals we wants to achieve, along with checks and balances

The metrics chosen were:

  • Flow Efficiency, defined as described above (this is like a lagging KR in OKR parlance to measure the key objective). Because we expected some initial challenges, we also measured how fast the teams ramped up to a steady state level of flow efficiency.
  • Subject Matter Expertise, to measure how quickly new developers got up to speed on unfamiliar components (leading KR)
  • Team satisfaction (balancing KR)

Of course, there were bumps along the way, but by all indicators, the program was very successful and Flow Efficiency was improved by a factor of 5. Across six different initiatives, average flow efficiency for the duration of the pilot was 80%. Even better, the teams ramped up to an average flow efficiency of 89% and this was done fairly quickly – an average of 1.3 sprints, or 2-3 weeks. 

Average team satisfaction increased by 30% over a period of six months, mostly because developers got out of their rut and learned new things. Subject matter expertise improved by 38% on an annualized basis.

Details of the methodology, practices, measurements, and learnings were presented in a white paper called “Winning the Concept to Cash Game with Feature Teams” at the 2021 XP Conference by Martina Ziegenfuss and myself.

Not unlike a stock investment disclaimer, actual results may vary and the variations may be substantial. But if you would like to deliver features to your customers five times faster, there is definitely value in considering an approach such as this.


by Leave a comment

Extending Cross-Functionality to Programs

There is an excellent rationale for cross-functional teams.  For large programs, that rationale can be easily scaled to the program-level.  But, for some reason, this isn’t always recognized.

TEAM CROSS-FUNCTIONALITY

Let’s say you have a team with the following profile of highly siloed individuals:

xfunc1

This is great if you have a profile of stories that fits it perfectly, as follows:

xfunc2

But what if your set of sprint stories looks more like this?:

xfunc3

In this case, you have a deficiency of analysts, back-end developers, and QA people to implement the stories that your aggregate team capacity might otherwise support.  And, your UX folks and front-end developers will be twiddling their thumbs for part of the sprint.

So, what to do?

Since you are only as good as your lowest capacity component (which appears to be QA, from this particular example), you will have to scale back the number of stories to fit the profile, as shown:

xfunc4

Now, everyone is underutilized, except for QA.  Good luck finding something useful for everyone else to do in the next two weeks.

The net result is that your team is perhaps 30% less productive than it could be (eyeballing the graphic).

However, if you take advantage of standard cross-functional teamwork, your team’s profile may look something like this:

xfunc5

Note that by “cross-functional” we do not mean that everyone should be able to do anything.  There are very valid reasons (education, experience, proclivity, enthusiasm) why certain people are ideally suited for certain kinds of work.  Think of the cross-functional nature of someone’s role on a team as a bell curve (alternatively, some talk about T-shaped employees – the T is just the bell curve upside down, as the Y-axis orientation is arbitrary).  The more the curve is spread out, the more they are able to take on other people’s roles.  On a good cross-functional team, the bell curves overlap “somewhat,” meaning that everyone can take on a little bit of someone  else’s role, although perhaps not as efficiently.  Still, this allows a team to take on a wide variety of “profiles” of sprint work, as will always be necessary.

So, for example, in the case above,

xfunc6

people will adjust to the desired “sprint needs” profile as follows:

xfunc7

PROGRAM LEVEL CROSS-FUNCTIONALITY

Don’t forget that this model can be applied to more than just teams.

For example, there can be a tendency for teams to develop “specific expertise”, due perhaps to knowledge held by certain BSAs or specific architectural or design skills in the development team.  The program may then tends to assign stories based on this expertise under the theory that this is the most efficient way to get work done. Unfortunately, this has the effect of only further driving each team into a functional silo.  It can become a vicious spiral and soon you may hear things like “well, we don’t have generic teams and, at this point, the schedule is paramount, so we need to keep assigning program work according to the team best suited to do it.”  As a result, program backlogs will consist of stories pre-targeted to specific teams, even arbitrarily far out in time.  Imagine what happens when the stakeholders decide to re-prioritize epics or add new features, or a new dependency arises that doesn’t line up with the ideal team at the right time.  The result will be a work profile that doesn’t match the “team profile,” as follows:

xfunc8

Enter a cadre of fix-it people – project managers, oversight groups, resource managers, program managers – all trying to re-balance the backlog, shuffling stories around, adding people to teams, squeezing some teams to do more work, while other teams tend to be idle, therefore resulting in the assignment of less than necessary filler work.  It is the same wasteful resource management nightmare that is so easily solved by cross-functional teams, except this time at the program level.

So, eliminate the waste, and follow the following simple program level guidelines:

  1. Create a fully prioritized program backlog without consideration for the teams that will be executing the stories.
  2. Once per sprint, have a program planning session or meta-scrum (Uber-PO, Uber-SM, team representatives) where the candidate stories for the upcoming sprint are identified for each team.  Include a little more than each team’s velocity would otherwise indicate in case they are able to take on more than their average.
  3. Make it a goal to avoid specializing teams.

All team “profiles” will be identical and program needs can easily be accommodated.

xfunc9

There may be a little bit of short term inefficiency resulting from having the “slightly less than ideal” team work on particular stories, but the more you do this, the more that inefficiency evaporates.  And the advantages are significant:

  • Holistic view of program backlog allow you to focus on what is important – delivering value
  • No need to engage the expensive swat team of fix-it managers to shuffle around people and project artifacts
  • All team members gain experience and learning, often resulting in greater job satisfaction, and higher performing teams
  • No more single point of failure; no more critical path team
  • Far less chaos and confusion, resulting in more focused individuals
  • Extremely easy to manage – program progress is measured by the simple rate at which all teams work through the stories.  Any gaps in targeted scope versus expected scope is easy to identify.


by Leave a comment

Intuition & Innovation in the Age of Uncertainty

“My [trading] decisions are really made using a combination of theory and instinct. If you like, you may call it intuition.” – George Soros

“The intellect has little to do on the road to discovery. There comes a leap in consciousness, call it intuition or what you will, and the solution comes to you, and you don’t know how or why.” – Albert Einstein

“The only real valuable thing is intuition.” – Albert Einstein

“Don’t let the noise of others’ opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition.” – Steve Jobs

Have you ever considered why it is that you decide some of the things that you do? Like how to divide your time across the multiple projects or activities that you have at work, how and when to discipline your kids, where to go and what to do on vacation, which car to buy?

The ridiculously slow way to figure these things out is to do an exhaustive analysis on all of the options, potential outcomes and probabilities. This can be extremely difficult when the parameters of the analysis are constantly changing, as is often the case. Such analysis is making use of your conscious mind.

The other option is to use your subconscious mind and make a quick intuitive decision.

flip-coin_5

We who have been educated in the West, and especially those of us who received our training in engineering or the sciences, are conditioned to believe that “analysis” represents rigorous logical scientific thinking and “intuition” represents new-age claptrap. Analysis good, intuition silly.

This view is quite inaccurate.

Intuition Leads to Quick, Accurate Decisions

According to Gary Klein, ex-Marine, psychologist, and author of the book “The Power of Intuition: How to Use Your Gut Feelings to Make Better Decisions at Work,” 90% of the critical decisions that we make are made by intuition in any case. Intuition can actually be a far more accurate and certainly faster way to make an important decision. Here’s why…

The mind is often considered to be composed of two parts – conscious and subconscious. Admittedly, this division may be somewhat arbitrary, but it is also realistic.

The conscious mind is that part of the mind that deals with your current awareness (sensations, perceptions, feelings, fantasies, memories, etc.) Research shows that the information processing rate of the conscious mind is actually very low. Dr. Timothy Wilson from the University of Virginia estimates, in his book “Strangers to Ourselves: Discovering the Adaptive Unconscious,” the conscious mind’s processing capacity to be only 40 bits per second. Tor Nørretranders, author of “The User Illusion”, estimates the rate to be even lower at only 16 bits per second. In terms of the number of items that can be retained at one time by the conscious mind, estimates vary from 4 – 7, with the lower number being reported in a 2008 study by the National Academy of Sciences.

Contrast that with the subconscious mind, which is responsible for all sorts of things: autonomous functions, subliminal perceptions (all of that data streaming in to your five sensory interfaces that you barely notice), implicit thought, implicit learning, automatic skills, association, implicit memory, and automatic processing. Much of this can be combined into what we consider “intuition.” Estimates for the information processing capacity and storage capacity of the subconscious mind vary widely, but they are all orders of magnitude larger than their conscious counterparts. Dr. Bruce Lipton, in “The Biology of Belief,” notes that the processing rate is at least 20 Mbits/sec and maybe as high as 400 Gbits/sec. Estimates for storage capacity are as high as 2.5 petabytes.

Isn’t it interesting that the rigorous analysis that we are so proud of is effectively done on a processing system that is excruciatingly slow and has little memory capacity? Whereas, intuition is effectively done on a processing system that is blazingly fast and contains an unimaginable amount of data.

In fact, that’s what intuition is – the same analysis that you might consider doing consciously, but doing it instead with access to far more data, such as your entire wealth of experience, and the entire set of knowledge to which you have ever been exposed.

Innovation Is Fueled by Intuition

The importance of intuition only grows exponentially with every year that passes.  Here’s why…

Eddie Obeng is the Professor at the School of Entrepreneurship and Innovation, HenleyBusinessSchool, in the UK. He gave a TED talk which nicely captured the essence of our times, in terms of information overload. Figure 1 from that talk demonstrates what we all know and feel is happening to us:

Eddie_Obeng_Uncertainty

The horizontal axis is time, with “now” being all the way to the right. The vertical axis depicts information rate.

The green curve represents the rate at which we humans can absorb information, aka “learn.” It doesn’t change much over time because our biology stays pretty much the same. The red curve represents the rate at which information is coming at us.

Clearly, there was a time in the past, where we had the luxury of being able to take the necessary time to absorb all of the information necessary to understand the task, or project at hand. If you are over 40, you probably remember working in such an environment.

At some point, however, the incoming data rate exceeded our capacity to absorb it; television news broadcasts with two or three rolling tickers, tabloids, zillions of web sites to scan, Facebook posts, tweets, texts, blogs, social networks, information repositories, big data, etc. In our work place, projects typically have many dependencies on information from other teams, stakeholders, technologies, end users, and leadership, all of which are constantly changing.

It is easy to see that as time goes on, the ratio of unprocessed incoming information to human learning capacity grows exponentially. What this means is that there is increasingly more uncertainty in our world, because we just don’t have the ability to absorb the information needed to be “certain,” like we used to. Some call it “The Age of Uncertainty.” Some refer to the need to be “comfortable with ambiguity.”

This is a true paradigm shift. It demands entirely new ways of doing business, of structuring companies, of planning, of living. In my job, I help companies come to terms with these changes by implementing agile and lean processes, structures, and frameworks in order for them to be more adaptable to the constantly changing environment. Such processes are well suited for the organizational context in any case given that organizations are complex systems (as opposed to “complicated” ones, in Cynefin, or systems theory, parlance). But they are also the only kinds of processes that will be effective in this new environment because they embrace the idea of sensing and responding to change instead of requiring rigorous analysis to establish a predictable plan.

We no longer have time to do the rigorous analysis necessary to make the multitude of decisions with which we are confronted on a daily basis. Instead, we increasingly need to rely on our intuition. But, while we often concentrate our energies on improving specific technical or leadership skills, we rarely consider the idea that perhaps we can make better use of that powerful subconscious mind apparatus by improving the effectiveness of our intuition. It seems to me that this is a significantly missed opportunity, one that deserves more and more of our attention with every passing year.

Intuition Can Be Developed

Sounds as if intuition is a skill that could be very useful to hone, if possible. So how do we develop that capability?  Here are some ideas:

  • Have positive intent and an open mind – The first step to any new idea is to accept it. Think of it as “greasing the learning skids.”
  • Put yourself in situations where you gain more experience about the desired subject(s) – Intuition works best when you have a lot of experiences from which to draw. If you continue to do the same thing over and over, you are not building new experiences.  Therefore, the more you depart from the norm and from your comfort zone, and develop experiences in your area of interest, the more substantial your “intuitive database.”
  • Meditate / develop point-focus – Meditation develops all sorts of interesting personal capabilities, not least of which is an improved capacity to intuit.
  • Go with first thing that comes to mind – Effectively, you are practicing intuition by doing this. In time, the practice will lead to more effective use of the capability.
  • Notice impressions, connections, coincidences (a journal or buddy may help) – This reinforces the intuitive pathways of the mind. Neuroplasticity is a well-studied phenomenon whereby your thoughts develop incremental neural connections. Reinforcing the positive ones makes them more available for use.
  • 2-column exercises – Another mindfulness technique, these exercises help to raise you awareness of your mental processes, including your subconscious.
  • Visualize success – Think of this as applying the idea of neuroplasticity to build a set of success-oriented neural pathways in your mind.
  • Follow your path – Following a path that feels right to you does two things: First, it puts you into increasingly rewarding situations, generating positive feedback, which helps with all of the above practices. Second, it is simply practicing intuition, but specifically on what your subconscious mind knows are your best decisions.

I am doing many of these practices and finding them to be very valuable.


by Leave a comment

Lean Time Management: Are You a Slave to Someone’s Calendar?

When you get to work in the morning, what is the first thing that you do? I mean, after getting the cup of coffee and cinnamon-swirl danish.

Do you check your calendar to see what meetings you have to attend throughout the day? Did you schedule all of those meetings? If not, your time is being largely managed by other people.

Do you feel that your attendance at those meetings constitutes the greatest value that you can be providing for your company today? If not, are you satisfied with that fact, day after day?

toomanymeetings

The Problem With Too Many Meetings

I am not suggesting that someone else’s meetings are not important, or that your attendance at those meetings isn’t valuable. But all too often, there are significant dysfunctions that result from a meeting-oriented culture:

    • Jumping from meeting to meeting is context shifting and introduces an element of waste each time you change context; some studies suggest 20% or more.2
    • Meetings are generally aligned to hour or half-hour boundaries and tend to last exactly as long as they are scheduled. Does it really make sense that for a 1-hour meeting, we always have exactly 1 hour of stuff to discuss? If there was really 45 minutes worth of useful discussion that expanded to fit the time allotted, that’s another 25% waste. If there was really 75 minutes worth of useful discussion to be had and it was cut short by 15 minutes, then you will suffer from some serious additional waste.  First there is the waste in calendar time due to the fact that the topic under discussion must wait another week (or whatever the recurring meeting period, or duration before the newly scheduled followup meeting can take place) to make progress.  In addition, unless your attendees are robots, they will forget most of the discussion and conclusions reached by the time the next meeting rolls around and you will all waste time getting on the same page again.
    • Many meetings are perfunctory. They recur weekly or biweekly, regardless of the optimal frequency.  Perhaps they have been on the calendar for a long time and their usefulness is starting to decline, in which case it would make sense to decrease the meeting duration or frequency, but this is rarely done until more time is wasted.
  • Often times, the meeting has the wrong people. One too many is wasteful. One too few is wasteful to the rest of the attendees. You can easily tell when you are in a useless, perfunctory meeting or one which has too many attendees because many of the people will be processing other work on their laptops, thereby only half listening. More waste.

Considering all of these potential dysfunctions, I am simply suggesting the possibility of adopting a different mindset when you go to work&emdash;a mindset driven by the lean principle of eliminating waste.

Lean Time Management

What if you planned each day around the objective of providing the greatest impact that you can possibly provide that day?

Might you find yourself with more time to make a difference?

How would your job satisfaction change?

If everyone adopted that mentality, do you think your company would make greater progress toward its objectives?

What about collaboration – doesn’t this approach run counter to that core agile principle?

Assuming that all collaborators have a similar view of the value of the issue at hand, they will all be meeting the criteria for this principle. And, clearly, if you collaborated as needed and not as scheduled, you would be more efficient.

If you think your department, organization, or company is ready for a meeting reset, consider doing a meeting audit. Or, even better, wipe the calendar clean and start over with a new mind set. I’ll bet you’ll see a positive change.

Notes:

  1. Photo courtesy Creative Commons License, @boetter’s photostream
  2. Original source: Weinberg, Gerald. Quality Software Management: Systems Thinking, Dorset House, 1991.


by Leave a comment

Subtractive Transformation (or “How Improving a Company is Like Improving a Golf Swing”)

After living overseas for two years and not playing golf the entire time, I returned to the states, joined a golf league, and quickly realized how out of practice I was.  I had always had good luck taking lessons or “tune ups” from a particular golf pro in Boston, but now I was living in Florida, and needed to find someone new.  So, I went to one golf pro, who upon analyzing my swing, suggested a half dozen things I should be doing.

golfswing2

I got worse.

I went to another pro, who watched my poor excuse for a swing, and promptly suggested a different half dozen things to do.

I got even worse.

Before giving up entirely, I tried yet one more guy.  After watching me fumble through a couple drives, he said “I don’t know who you have been taking lessons from, but they’ve got your head full of rules and you can’t relax out there – that’s why your swing stinks.  Forget about everything they taught you and just get out there and hit the ball.”  (For those who have seen the movie “Tin Cup”, this advice might sound familiar)

I got worse.  But then I started to get better.

The lesson I learned from this was the power of simplicity. I was trying too hard to do too much.  Removing the impediments to a decent golf swing was far easier that trying to pile a bunch of better rules on top of the foundation of bad habits.

Having worked with companies who are trying to transform in some way, I find that the same guidelines apply.  Your organization may want to become more nimble, more agile, more innovative, more something.  But it is probably full of organizational structures, processes, attitudes, cultures, and leadership styles that represent impediments to the desired transformation.

The mistake many companies make is to try to pile on the new ideas without removing the impediments, a strategy we might call “additive transformation.”  Generally, the new ideas just won’t fit and you’ll have a mess of conflicts.  For example, you may try the approach of implementing a policy of having your designers, architects, and developers work on something “free of constraints” for 10% of their time (a commonly attempted tactic to bring innovative ideas and fresh thinking to a stale environment).  Unfortunately, those people will quickly run into problems, such as project managers or business stakeholders who are still driving to dates without any consideration for allowing time for investments in innovation or process improvement.  As if they “never got the memo.”  Sentiments like “yes, we are all for innovation, but we also have a business to run and important deadlines to meet” will be interpreted completely differently by folks with different levels of agile maturity and will therefore result in mismatched expectations.

Instead of adding incongruent changes, focus on removing those impediments to agility and innovation, a strategy we might call “subtractive transformation.”  By using thinking tools like “Double Loop Learning” and coupling them with analytical tools like “Current Reality Trees” (from Eliyahu Goldratt’s Theory of Constraints) you can uncover the organizational structures, process, cultural elements, belief traps, and leadership styles that are responsible for those impediments to your new organizational vision.  Once you have discovered the roots of those impediments, it may be an easy step to simply remove them or to brainstorm an “environment design” change that will undo them.

The other advantage to this approach is that you can start from the most logical place – where you are today.   You don’t need to do a “reset” and start with a clean slate in order to achieve a transformation.  All you need to do is simplify and improve, via the removal of bad habits.

Before you know it, you’ll be hitting the ball in the fairway again.


by Leave a comment

A Cure for Parkinson’s

Parkinson’s Law – “Work expands so as to fill the time available for its completion”

– Cyril Northcote Parkinson

Your agile team can be following 99% of the principles and practices behind Scrum, XP, and/or Kanban and yet still working at half efficiency, or worse, due to Parkinson’s Law.

There is very little in the prescribed principles and practices that directly address the efficiency of executing tasks, save the concept of eliminating waste, but even that usually centers on eliminating workflow waste, not task or work item waste.

The good news is that while your agile team may have tremendous untapped potential, realizing that potential may be as simple as setting up the right environment for them.

It is a natural human behavior to allow work to fill the time allotted.  We have all done it. The reasons are many and various: Overanalysis, not balancing task elements across the work item, struggling with a blocker without asking for help, procrastination, lack of a desire to work faster, lack of motivation, distractions, not managing interrupts well, multitasking, and so on.

Note that every one of those behaviors can be identified and remedied.  But where to start?

Empowering Agile Teams

The first place to begin to solve the Parkinson’s Law problem is with empowerment.  An unempowered agile team is a team that doesn’t care.  And that is a prescription for a bad case of Parkinson’s.

Here is one recipe for curing Parkinson’s within an agile team.  The order is logical: Start where the answer to the leading question is “yes” and work downward:

  1. Have non-team members (by “non-team members” here, I mean anyone other than the team; it could be any level of management, the client, the business, the PMO, etc.) set an unrealistic goal for the project?  This situation will make people feel that they have no control and that if the project fails, it is someone else to blame.  A solution may be to improve transparency around the release burnup.  Is there a release burnup?  If not, start there.
  • Create a clear burnup from empirical velocity and an agreed-upon backlog and distribute it to all stakeholders.
  • Make sure that the release backlog is reasonably well sized.
  • Make sure that the velocity is based on empirical data, not wishful thinking.
  • Ensure that the burnup accurately reflects the backlog and velocity.
  • Make sure that everyone sees it – client, PMO, business stakeholders, various management levels, other potentially impacted teams.  Obfuscation occurs when different groups use different artifacts to present information, so ensure that they are all using the same artifact.
  1. Are non team-members selecting the stories to be run each sprint?  This can serve to prevent the team from feeling ownership.

Tip: Put the Team in Charge of Their Commitment

  • Stop the practice of external story selection and have the team select only enough stories to get to the point that they feel that they can commit to complete those stories and not one more.
  • Have a discussion around the meaning of “commitment.”  Make sure that this is one of those things that require unanimous team agreement, like a jury.  There are some decisions that can be made by a democratic majority, others that are okay to be made by an oligarchy.  But, commitment to a Sprint plan should be unanimous across the entire team.  Without that unequivocal commitment, unspoken naysay remains unchallenged, that could spoil morale right when you need it.
  • Then, during the planning session, ask for that one-by-one commitment to the sprint.
  1. Is a “chicken” (e.g. project manager who is not part of the team) selecting work for people, assigning tasks, assigning story owners, assigning roles?  How can they possibly know better than each team member how what tasks are needed for each story and how long each will take?
  • Eliminate that practice.  Only when the team selects their own work do they feel ownership of that work.  And it is only when a team feels ownership that they will begin to have the motivation to work at their full potential.
  1. Are story sizes small enough that each person can work on at least two stories per sprint?  Large stories that take most of the sprint to complete can create a Parkinson’s effect.  People get used to the idea that they work on only one story per sprint, and so, consciously or subconsciously, allow each story to expand to fill the sprint.  Sometimes you can have a breakthrough in velocity just by breaking that pattern.
  • Size stories such that at least two or three can be worked on by each person in one sprint.  This gets people used to the feeling of finishing and then pulling something off the backlog mid-sprint.
  • It might be necessary for the ScrumMaster to keep close watch on stories to ensure that they don’t languish uncompleted for days.  Once the pattern is broken, this is usually no longer a gating concern.

OK, great.  The team is fairly empowered at this point and work should be flowing smoothly.  Still, they may not feel full ownership and commitment.  One of the problems is that they team may still be looking to their PO and ScrumMaster as their “leaders,” and consciously or subconsciously feeling that the ultimate accountability for the story or the work item or the task is more with these “leaders” than themselves.

So spread out the “leadership”.

Tip: Spread the Spotlight

  1. Do the ceremonies revolve around the same people?  Is it always the SM or PO that facilitates the planning sessions, retrospectives, and sprint reviews?  Do people talk to the SM during the standup?  Start by broadening the leadership.
  • One method is to have story owners.  Ultimately, it is probably ideal for the entire team to feel fully accountable for all stories, but it can be difficult to get there in one step.  So, an interim step may be to have designated story owners, whose job it is to drive the story to completion.  They should ensure that there aren’t gaps in time between sequential tasks of the story and help resolve impediments pertaining to that story.  This can have the negative consequence of individual team members still not feeling accountable to that story being complete, but at least the feeling of ownership has been somewhat spread out.  Individuals who have been story owners can then spread that feeling of commitment to others on the next stories.
  • Ensure that BSAs, QA, and developers all get the chance to be story owners.
  • Once everyone begins to demonstrate accountability to all stories, the story ownership may be dropped.

And yet still it may seem like some stories and tasks are dragging on longer than they should.

Tip: Use the Buddy System

  1. Do people tend to hand off work to each other via documents?  Do they communicate via email instead of in person?  Lack of collaboration can lead to low transparency silos, which are a breeding ground for Parkinson’s.  It is very easy to hide when no one else interacts with you.
  • Encourage collaboration sessions around story acceptance test writing or reviews, perhaps even kickoff sessions for each story.
  • Make a habit of including everyone involved with a story in ad hoc discussions.
  • Encourage pairing; not necessarily for just development, but any functional area, especially where Parkinson’s might be lurking.  Pairing generally speeds up tasks, and many in the XP world even observe that pairing can even reduce overall net effort on a task.  But even if it doesn’t, the payoff in terms of reducing the Parkinson’s effect will probably offset any net effort increase due to the pairing.

A healthy pattern will be established which should stick.  It is hard to watch your velocity drop and hard to let Parkinson’s set back in to a team, once good collaborative patterns have been established.

Tip: Focus on Focus

  1. Do people tend to complain about interrupts, or that they have too many responsibilities outside of story work?  Perhaps it is time to retrospect on those problems.
  • Solutions may exist in process changes.  For example, rather than have everyone on the team be interrupted by a production support broadcast, have level 3 support designates that periodically rotate through the team.
  • Practice good interrupt management. Does everyone on the team understand the evils of multitasking, both from the standpoint of flow as well as context shifting?  Perhaps some education is needed.  Spend a sprint recording what you are doing once per hour (set an alarm) and aggregate the results.  See anything surprising?
  • As a Scrum Master, check to see if people are burning down tasks on multiple stories at the same time, rather than working a task to completion before moving on to the next one.
  • Question the interrupt requests.
  • Give feedback to habitual interrupters,
  • Recognize that you are not indispensible and don’t need to always be the hero.
  • Turn off distractions if you can, like email popups.
  • Resist the urge to check email.
  • Manage time in blocks.

There are many more time management ideas that you can find via a few specific web searches.

By now, we should be seeing a healthy buzz of collective ownership and collaborative practices, and Parkinson’s Law should be all but eliminated.

Parkinson’s is all about lack of motivation.  Therefore, it can be cured by taking steps to establish a team environment where motivation comes naturally.  Any steps that serve to improve empowerment, teamwork, collaboration, and the feeling of collective ownership will have the greatest effect.


by Leave a comment

Broadening the Grounds for Self Improvement

We all have our least favorite phrases or questions that come up in day to day coaching.  One of mine goes along these lines: “No one has complained about this, so why change?

 ————–

How many of us complained about not having a PC on our desk before HP created one and Apple popularized it?

How many of us complained about not having a mouse and a point-and-click interface before Xerox PARC invented it and Apple popularized it?

————–

Making changes that address complaints or known problems certainly makes sense.  But doesn’t it also make sense to make changes that simply improve the ability to deliver, even if there isn’t an obvious problem to solve?

For just one example, I have worked with teams who used a big visible task board to track progress on their stories, but the board was so confusing that it didn’t add much value.  Simplifying it and making it more readable generally helped to improve the clarity of each story status and the progress of the sprint, and I would notice people starting to have discussions around the board.  Conversations improved, collaboration increased, and the team performance often went up as a result.  Yet, no one had ever complained about the board.

When a team retrospects, they often focus on the things that didn’t go well over the past sprint.  For instance, they might devote a few collective hours of time to solving a very specific problem that was raised; e.g. “I didn’t have the login credentials necessary to access this particular database that I needed to consult to find out some information for my story.”  But, instead they could have spent time figuring out how to collaborate better on identifying business requirements – an activity not driven by any complaints or problems, but one which could generate significant benefits in terms of velocity or delivering value.

————–

How many of us complained about not having a web interface on top of the Internet before Mosaic?

How many of us complained about not having a smart phone before IBM created one and Apple popularized it?

 ————–

Marcus Buckingham, leader of the strengths movement , notes that a person’s “greatest room for growth” is not one of their weaknesses but their strengths.  Might not this also apply to agile teams?

What if, instead of always focusing our retrospectives on fixing the things that are broken, we sometimes take a critical look at things we already do well, but could get so much incremental value out of doing even better?

Investing in cross training, for example, has to potential to be one of those practices that can generate huge improvements in team productivity, even for a team with already broad skill sets.  A team could become so efficient at being cross functional that they never would find tasks blocked due to the lack of an available person with the right skills or knowledge.  Tasks and stories will flow even better and overall team productivity can only go up.  The same might be said for building foundational principles like commitment and empowerment.

Continuous improvement isn’t about fixing problems.  It is about inspecting everything that you do, good and bad, making decisions about where change can make the most impact, and validating your decisions.


by Leave a comment

Agile Myths Busted

Ever run across these guys?  People whose lack of experience or fear of change cause them conjure up all kinds of reasons why agile won’t work for their project?

Let’s bust those myths!

Myth: Agile Doesn’t Work for Projects in the Highly Regulated Medical Environment.  (The reason usually given is that FDA regulations require detailed requirements prior to project approval; hence, waterfall.  However, in reality, you can develop in phases, with small incremental sets of requirements and the FDA requires only enough documentation to demonstrate your process.)

Truth: Abbott Labs overcame medical device regulation and stringent Class 3 certification and developed the m2000 Real-time PCR Diagnostics System, a human blood analysis tool, with four agile teams.  Compared to the prior methodology in use, this project resulted in a less cumbersome process, fewer defects, a reduction in costs of 43%, and a reduction in cycle time of 25%.

(Rasmussen, R., Hughes, T., Jenks, J. R., & Skach, J. (2009). Adopting agile in an FDA regulated environment. Proceedings of the Agile 2009 Conference (Agile 2009), Chicago, Illinois, USA, 151-155)

Myth: Agile Doesn’t Work in Government

Truth: The FBI overcame a CMMI level 3, ISO 9001, government-mandated document-driven waterfall life cycle and developed the Domestic Terrorist Database & Data Warehouse with three agile teams.  Compared to the prior methodology in use, this project resulted in significant improvements in release planning, developer satisfaction, and a focus on the true goal: “to catch bad guys.”

(Babuscio, J. (2009). How the FBI learned to catch bad guys one iteration at a time. Proceedings of the Agile 2009 Conference (Agile 2009), Chicago, Illinois, USA, 96-100.)

For another example, the U.S. Department of Defense developed the Strategic Knowledge Integration Website utilizing three agile teams.  Compared to the prior methodology in use, this project resulted in improved quality, fewer defects, better teamwork, and a 200% productivity increase.

(Fruhling, A., McDonald, P, & Dunbar, C. (2008). A case study: Introducing extreme programming in a U.S. government system development project. Proceedings of the 41st Annual Hawaii International Conference on System Sciences (HICSS 2008), Waikaloa, Big Island, Hawaii,USA, 464-473.))

Myth: Agile Doesn’t Work for Large Products

Myth: Agile Doesn’t Work with Distributed Teams

Truth: Google’s AdWords product busts both of these myths.  With 20 teams and 140 people across 5 different countries, this large agile program was a groundbreaking success at Google and resulted in more predictable releases, higher quality, and an improved ability to accommodate changes, as compared to the prior methodology in use.

(Striebeck, M. (2006). Ssh: We are adding a process. Proceedings of the Agile 2006 Conference (Agile 2006), Minneapolis, Minnesota, USA, 193-201)

Myth: Agile Doesn’t Work in the Regulated Telecom environment

Truth: British Telecom moved their entire IT department to agile, starting with 2000 people from 2004-2007.  This large transformation resulted in an improvement from 10% value stream effectiveness to 55%, created an attitude of delivering real value to the business through IT, and shifted the company’s perception of IT from a service provider to an integral part of the business solutions.

(http://www.agilistapm.com/casestudy-british-telecom/. http://scalingsoftwareagility.files.wordpress.com/2008/06/scrumbt-v14.pdf)

Myth: Agile Doesn’t Work for Client-based projects

Myth: Agile Doesn’t Work for Fixed Price projects

Myth: Agile Doesn’t Work well when integrating a Third Party Product

Truth: I coached an agile team at a prominent consulting company through a project with a client who was a well known record label.  They built a new, fully rebranded, eCommerce website using open source CMS and Search engine, and a third party eCommerce provider.  The site included product bundling, integrated music player, and social networking integration.  It was implemented using Scrum/XP with a single team of about 12 people over 5 months.  The result was an award-nominated site that improved conversion rates dramatically, ultimately profitable for and considered a strong success for both the agency and the client.

Myth: Agile Doesn’t Work for Manufacturing Vehicles

Truth: Wikispeed developed a 4 passenger, 100 mpg, street-legal road car in 3 months using modular, off-the-shelf, carbon-fiber body construction, with no capital investment, and no paid employees.  Agile processes were utilized with a single international team.  The project went beyond the prototype phase and cars are available online.

(http://www.solutionsiq.com/the-agile-ceo/bid/51480/Agile-Innovation-or-How-to-Design-and-Build-a-100-MPG-Road-Car-in-3-Months)

What else ya got?

(note: leads for some of these case studies came from David Rico’s presentation on Lean & Agile Project Management for Large Programs & Projects)


by Leave a comment

The Math Behind Agile and Automation

Every once in a while, we encounter individuals on our teams who have a healthy dose of skepticism about these new Agile practices they are learning. For those who tend to be scientifically-minded, or need more evidence than just a good story, I have found that it is important to give them real data to look at.

As an example, it is interesting to combine the usual Cost per Defect curve for a software project with a histogram that maps the probability or frequency of finding defects to the corresponding project phase. The result is mathematical support for both Agile as well as the value of Automation and good Agile QA practices.

Figure A below shows the typical Cost curve for a waterfall project (source: The Economics of Testing, Rice Consulting) along with an overlay showing the probability of finding defects in various phases of the project.

Cost of Fix per Defect - Waterfall

As can be seen, most defects are found during the testing phase, as one might expect. Using some industry standard numbers, the cost to fix per defect is about $490.

Note, however, what would happen if you are able to find defects earlier in the process.

Cost of Fix per Defect - Modified Waterfall

Figure B shows the same cost curve, but the histogram representing the probability of defects found is pushed earlier in the process. The kinds of practices that might result in such a change include collaborative QA and developer testing, pairing, and automation (which helps prevent the defects from being found in the expensive tail of the curve). This doesn’t mean spending more on QA, just utilizing tighter feedback loops that help prevent defects from getting to the later phase of the project. So, even with a waterfall process, or a non-agile iterative process, one can easily see how collaborative testing and automation can reduce the cost of defects considerably, in this case down to $220 per defect.

The Agile cost curve is actually a little different, as shown in Figure C.

Cost of Fix per Defect - Agile, automated

There is still the hockey stick effect when the software goes into production, but the rest of the cost curve would be flat, since the cost of fixing is pretty much the same from iteration to iteration. The defect frequency histogram is drastically different and is flattened and spread out across the entire life cycle of the release.

In this model, Agile practices alone, such as sprint-based functional testing and having QA and developers working off of the same requirements, are responsible for about a factor of two improvement in overall cost of defect fixing per release. Automation and good collaborative practices are responsible for another factor of two, which gets the overall cost per defect down to about $130.