Category Archives: Agile Management

Agile Productivity Measures

Posted on by
Reply

Scott Ambler has written a couple good articles about measuring productivity with velocity.  Acceleration: An Agile Productivity Measure. and Examining Acceleration.

From what I understand, this is a measure of the effect of agile on the relative improvement over time of a team.  I would beg to differ that it is a measure of productivity.  Productivity is value delivered over time.  If team A is delivering $5/week and team B is delivering $5000/week, then knowing that team A is accelerating faster than team B isn’t terribly important, particularly if the market can’t bear to absorb $6/week of whatever team A is producing.

Measuring productivity is hard.  I would love to hear from people who have tried various means to measure productivity.  I measure productivity in our business, but I can do that because we are small and everything we do has a direct effect on the bottom line.  Does your business run with that transparency?  If not, why not?

Changing Patterns of Thought for Defining and Expanding Done

Posted on by
3

“Without changing our patterns of thought, we will not be able to solve the problems that we created with our current patterns of thought.”  -Albert Einstein

“We are what we repeatedly do. Excellence, then, is not an act, but habit.”  -Aristotle

Among leading Agile thinkers, coaches, trainers and practitioners there is a rich, ongoing discourse around a subtly deceptive concept  – the concept of the Definition of Done.  Within this discourse, a singular constant challenge is emerging:  old patterns of thought.

For example, there is an old pattern of thought that tells managers of software companies that at least some part of the Definition of Done must be imposed on teams in order to protect a universal standard.  Rationalizing this antiquated thought pattern seems to have become a rigorous intellectual discipline in and of itself.  One of the most prevalent excuses to which many managers have invested a great amount of mental and emotional energy seems to be around the challenging concept of multiple Agile teams working together on the same project (or product).  Surely, in such cases there needs to be some kind of imposed standard that all teams need to comply with in order to avoid chaos in the main build, yes?  In fact, this is the exact wrong approach to take.

We also seem to become confused at times by our own limited understanding of the words that we use when attempting to talk about things we are or are not trying and learning to do.  The more we learn about doing something, the more we are able to talk about it in practical terms.  Since theoretical discussions around semantics rarely result in appreciably improved behavior/results, we will endeavor here to address this subject with both brevity and caution.

Our old patterns of thought make understanding many words, including the word definition and the word done, problematic.  We tend to think of these words as implying static, rigid, absolute conditions; for example, the way we tend to think of the word definition in terms of the definitions of words.  We like to think that those definitions are relatively stable.  Indeed, there are some real benefits to this.  We can have conversations with people and assume that for the most part their understanding of the definitions of the words we are using are similar to our own.  But even with words, there can be more than one definition, which already makes the definitions of words less static than they often seem.  At some level, one might even ask – who actually decides on the definitions of words?  Is there an actual authority out there (not merely the self-proclaimed “official” authorities) that decides on definitions and hands them down to us?  Some may say “yes, indeed, namely the authoritative texts of the world’s religions,” for example.  On the other hand one could also say that the definitions of words have evolved through the ages (just as languages have) as humanity has received progressively more complex guidance from religious texts according to its evolving capacity (compare, say, the Bhagavad Gita to the Quran).  But that is another conversation.  What is important to acknowledge here is that the meanings of words expand and evolve over time given the capacity of the individuals who use them to develop new patterns of thought and that the energy required to do so is tremendous, even epochal.

An old pattern of thought construct around the word done is equally problematic.  A conversation limited by a rigid understanding of the concept of what done means, is and looks like can quickly take us spinning off into the stratosphere of “nothing is ever done.”  When there is a lack of trust and respect among people, as is generally the case in our society, and since ownership and ego are often entangled with limited and rigid understand, we then find ourselves in situations in which the limited and rigid understanding of a few with arbitrary power and authority take precedence over the understanding of others.  In other words, people in authority are expected to solve every problem and people that do work are expected to be robots.  Both are set up by this arrangement to fail.

Indeed, there is a real problem in trying to talk about things that we do not do, or that we do not sincerely try to do.  True learning, on the other hand, consists in people striving to be truthful and sincere working together  engagement in a continuous cycle of action, reflection and consultation.  Learning also requires us to be truthful – if we think we have all the answers, learning becomes extremely difficult, if not impossible.  If we are not at least trying to learn to define what “done” is to us, we will never be able to actually talk about it in a knowledgeable and meaningful way.  Furthermore, it will likewise be impossible for us to help anyone else learn to understand their own Definition of Done if we haven’t learned through real experience about how to understand our own.

As we engage in a real learning process, through action, reflection and consultation, new patterns of thought begin to emerge and perhaps even crystallize.  These emerging new patterns help us to bring concepts out of the stratosphere of semantics, rhetoric and theory back down to earth where we can actually act and reflect on them in order to implement creative new solutions to the problems of our world.

In her Agile 2007 presentation The Role of Leadership in Software Development (http://www.infoq.com/presentations/poppendieck-agile-leadership), Mary Poppendieck offers powerful insights into the history of patterns of thought around leadership and the emergence of Agile thinking out of the wisdom of Lean Manufacturing.

As with all Agile methods, Scrum is a framework for learning in which new patterns of thought that began to crystallize in Lean Manufacturing practices have been adapted and applied to software development practices.  It then follows that the Definition of Done in Scrum is consistent with a specific Lean Manufacturing practice, namely Standard Work.

In his book Workplace Management, Taiichi Ohno, the father of Lean Manufacturing, defines Standard Work as such:

“There is something called standard work, but standards should be changed constantly.  Instead, if you think of the standard as the best you can do, it’s all over.  The standard work is only a baseline for doing further kaizen [change for the better].  It is kai-aku [change for the worse] if things get worse than now, and it is kaizen if things get better than now.  Standards are set arbitrarily by humans, so how can they not change?

“You should not create these away from the job.  See what is happening on the gemba [shop floor] and write it down.”

Based on the assertions of the previous two paragraphs, we must conclude that just as standards should be changed constantly in Standard Work, so too should definitions change constantly in the Definition of Done.

How, then, does our work benefit from a Definition of Done that is always changing?  This is a deceptively simple question, as it is an example of a problem posed by old patterns of thought that can only be solved by new patterns of thought.  In order for the old patterns of thought thinker to be helped to form new patterns of thought, he must be accompanied by the new patterns of thought thinker to develop the capability to adopt new patterns of thought.  In other words, in order to really learn, people need to be accompanied by those who have more experience.  Such an exercise is far beyond the scope of any article and requires a completely different venue – namely the coaching relationship.  More about capacity-building and accompaniment later.

For now, suffice it to say that the point of having a Definition of Done that is always changing is to allow for kaizen – the Definition of Done, therefore, like Standard Work, is only a baseline from which we constantly change for the better.  In other words, the Definition of Done is the record of what we are actually doing now. It allows us to be absolutely confident that we know as much as possilbe about what we are actual doing now so that we can make real, concrete, and confident decisions about actual improvements to our work.

Actually doing the Definition of Done, as Ohno tells us is simple:  “See what is happening on the gemba [shop floor] and write it down.”  For many of us though, this simplicity is deceptive in that it is actually often very difficult – both the seeing and the writing.

The ability to see what is actually going on is clearly vital to the capability of defining done.  It is valuable, therefore, to examine more closely the sense of sight:

We have physical eyes that see.  What do our eyes see?  Light.  Is this what Ohno is talking about when he says “see what’s going on” – literally seeing light – or is he talking about a different kind of sight?  Clearly, what he is talking about is what we might call true sight, or the ability to see the truth.  We can think of truth, therefore as being like light.

Is it our physical sight that sees the light of truth?  This, of course, is impossible since our physical eyes only see physical light.  So what is the sense in us that allows us to see the light of truth – in other words, what is true sight?   Some may say that it is our sense of justice.  One must have a strong, developed sense of justice in order perceive truth, especially in environments like software development in which the truth can be easily hidden.

Writing down the Definition of Done with accuracy and clarity requires us to be both truthful and precise.  This is very difficult to do well in our present environments of opacity, defined roles, command and control management, fear of failure and general distrust.

Clearly, we can see now that the Definition of Done, challenging to understand in its subtlety as a concept, is far more difficult to apply effectively in reality and therefore fully realize its value in practice.

The concept that allows for the value of the Definition of Done to be realized is the concept of expanding the Definition of Done.  Expanding the Definition of Done in Scrum and Agile is the equivalent of kaizen in Lean Manufacturing.  In order to expand the Definition of Done, the actual Definition of Done needs to be well understood.  In other words,  “Where there is no Standard there can be no Kaizen.”

Ohno says:

“When creating Standard Work, it will be difficult to establish a standard if you are trying to achieve ‘the best way.’  This is a big mistake.  Document exactly what you are doing now.  If you make it better than it is now, it is kaizen.  If not, and you establish the best possible way, the motivation for kaizen will be gone.”

This brings us back to the initial problem created by our old patterns of thought around our understanding of the Definition of Done – namely the misconception that at least some of the Definition of Done must be dictated by management in order to have consistency across teams working on the same large project.  The solution to this problem is challenging yet simple:  It’s irrelevant.  An organization is a living, breathing entity.  When management makes room for kaizen by not dictating standards, kaizen has more power to pollinate the entire organization and transform the way people think and work than imposed standards could ever begin to hope for.  Dictating standards, in other words, is limiting while kaizen harnesses the creativity of all.

Again, Ohno says:

“We need to use the words ‘you [the worker] made [the standard]’ as in ‘follow the decisions you made,’  When we say ‘they were made’ [for you] people feel like it was forced upon them.  When a decision is made, we need to ask who made the decision.  Since you also have the authority to decide, if you decide, you must at least follow your decision, and then this will not be forced upon you at all.

“But in the beginning, you must perform the Standard Work, and as you do, you should find things you don’t like, and you will think of one kaizen idea after another.  Then you should implement these ideas right away, and make this the new standard.”

Changing our patterns of thought requires creativity, but who’s creativity?

Ohno:

“Years ago, I made them hang the standard work documents on the shop floor.  After a year I said to a team leader, ‘The color of the paper has changed, which means you have been doing it the same way, so you have been a salary thief for the last year.’  I said ‘What do you come to work to do each day?  If you are observing every day you ought to be finding things you don’t like, and rewriting the standard immediately.  Even if the document hanging there is from last month, this is wrong.’

“At Toyota in the beginning we had the team leaders write down the dates on the standard work sheets when they hung them.  This gave me a good reason to scold the team leaders, saying ‘Have you been goofing off all month?’

“If it takes one or two months to create these documents, this is nonsense.”

People on the shop floor or the Scrum teams need to be given the freedom and authority to figure out how to do their work better and change the standards of their work as they learn.  Ohno was really first and foremost a master coach who knew how to accompany people to develop their capabilities to perceive truth and generate and apply their own knowledge and creative solutions to challenging problems.

Gary Hamel, in his article “Management Innovation” in the February 2006 edition of the Harvard Business Review, wrote:

“Only after American carmakers had exhausted every other explanation for Toyota’s success- an undervalued yen, a docile workforce, Japanese culture, superior automation- were they finally able to admit that Toyota’s real advantage was its ability to harness the intellect of ‘ordinary’ employees.”

In Scrum, the Team itself defines Done by what it actually gets done.  The ScrumMaster removes obstacles so that the Team can expand its Definition of Done (kaizen).  Scrum assumes that all Team members are dedicated to expanding the Team’s Definition of Done from Sprint to Sprint and that the Team will achieve this as long as organizational obstacles (such as managerial control fetish) are not impeding it from doing so.  When a Team is empowered in this way to expand its own Definition of Done (as well as empowered in other ways, according to the rules of Scrum), it will have the space it needs in order to grow into a hyper-productive Team.  That is to say that no one outside of the Team (i.e. management) dictates any part of the Team’s Definition of Done (a common management practice that results in kai-aku).  The Definition of Done is one ingredient in the remedy for curing our culture’s leadership disease – the failure to learn.

“…your failure is an internal disease…You firmly believe that sound management means executives on the one side and workers on the other, on the one side men who think and on the other side men who only work.”  -Konusuke Matsushita

(Shameless Plug: we offer excellent Certified ScrumMaster Training and in it we discuss the Definition of “Done” in the context of people’s actual problems.)

Report average velocity and fail 50% of the time

Posted on by
3

The question of “expected velocity” and long-term planning has come up at more than one client. A recent client conversation got me thinking, however, questioning how to interpret velocity when estimating and plotting a roadmap based on a current backlog of features. Assume, for a moment, a backlog of story-pointed features, and 10 good iterations (consistent team, no odd occurrences that would affect velocity). Mathematically average velocity (well, a mean really) is a 50/50 proposition for any subsequent iteration. Some organizations don’t find this level of confidence acceptable. What velocity should be reported as expected for iteration/sprint planning and roadmap forecasting, and how should it be used?

Context

Interpreting velocity, before anything else, requires some context. An agile organization that sees estimates as hypothetical might find this article is of less use. In fact, a good question is whether estimation is even a value-added activity. For this post assume an organization that sees strong value in estimation and planning.

Culture

The biggest piece of context is to know the organizational culture. This is important in two respects, and both of these cultural factors are important because they impact how Velocity is understood within the organization.

What is Failure?

First is the meaning of failure in the organization. Is failure to deliver what was committed to by the planned date considered a failure of the team, or is it simply a fact to be understood and accounted for in future planning? Even in Agile organizations, the former is often true and a hard habit to break. If not delivering to expectations is considered failure and has negative consequences, then that means that estimation is being treated not as estimation, but as prediction and contract. Velocity is therefore a commitment, and should therefore be used conservatively.

Consistency or Speed?

The second item to know is whether consistency and predictability of delivery is of a higher strategic value than the actual rate of delivery. This is often un-stated. Usually people want fast and consistent delivery. The truth is that you can get consistent, or fast software development, or a balance between the two. Lack of trust is usually a strong motivation to encourage consistency over speed, or a history of quality problems, etc. In this case, as well, Velocity is more of a boundary than an indicator.

Emotional Loading in Estimation (or why not Low-ball?)

If estimation is seen as binding, contractual, or limiting, then additional emotions get overloaded. Trust, promise, and betrayal are words used in such organizational cultures. Distrust is usually a strong factor, especially between silos (business vs. technology, company vs. project management vs. customer, etc.). So when people are asked to give estimates, even using agile-friendly mechanisms such as story points, there is usually a process of cementing that estimate into a part of an accountability model, so estimates start to get conservative. People are then accused of low-balling, others are accused of irrational expectations… we’ve all seen this. The language clearly becomes one of contention and blame. Even the term low-balling is often an outright pejorative term for estimating too conservatively.

This doesn’t happen only in agile environments, and project managers in traditional PMBOK frameworks have long factored risk into “contingency budgets”. Interestingly, however, if a Project Manager were to factor risk into the task estimates, they’d be “low-balling capacity,” yet if they were to factor it out and layer it on top of the project work, it’s “contingency budgeting” (At least in a few experiences I’ve had). Either way, someone’s adding a factor for uncertainty, based on the need to predict conservatively or liberally or somewhere in between.

That’s the point of the article: how can Agile projects use velocity to estimate as conservatively (or liberally) as is appropriate?

An average is a 50% chance to succeed (or fail)

Velocity is not a constant. It’s a set of instantaneous values on a curve, with instances being iterations. That means that it varies, and is therefore only meaningful statistically. So how do you reasonably use velocity statistically, and improve confidence? One way is to stop delivering against “average” velocity.

A lot of coaches use average velocity over the previous N iterations. This is not helpful for all sorts of reasons, if estimation is a commitment. By definition, average (well, actually a mean, but they’re close) is a 50/50 proposition. If you report the average team velocity (assuming it’s accurate), then about half the time the team will be under and about half the time the team will be over, statistically. So basically an average is a crap shoot, when taken in any given instance. It’s can only be good in the long run. For this to work, the long-haul has to include permission to fail and a lot of trust. Teams need to be able to go miss dates but will sometimes exceed dates and it should all wash out in the end. In organizations such as I’m describing, that trust isn’t there, so. Additionally, if the language of commitment is around meeting instantaneous iteration commitments (as opposed to delivering high-quality customer value as quickly as is sustain-ably possible) then you aren’t playing the long-game, you’re playing a very short-game.

Simulate Velocity, not work

In a PMI training course I took when I was at Sun Microsystems, we were nicely informed that two point estimates of tasks are a perfect way to fail half the time, per the above logic. One point estimates are just idiotic. Three point estimates were better. We simulated with a monte-carlo algorithm and found a curve and a distribution, and then determined a confidence level yadda yadda. Well, we’re trying to avoid wasting a lot of time estimating up-front, but one way to start representing velocity properly is to do the same kind of statistical modelling done in traditional product management, only simulate velocity, not work items.

In this approach, you take the last N iterations (say 10). Determine the maximum velocity (optimistic) and the minimum velocity (pessimistic), and then the mode (the velocity value that seems to occur most frequently). Then you do monte-carlo simulation so you get a statistical pattern. Now, you actually can determine an answer based on confidence. If you want to be right with an 80% confidence, you pick a velocity where 80% of the simulated runs were successful. (Note – there are a paucity of excel templates to do this math automatically, and often they are for sale. It would be nice to have a few functions with arbitrary distributions based on min-max-mode to help this along.)

It’s not perfect, and it’s a potentially huge amount of administrative overhead. Elsewhere I’ve referenced blogs that entirely oppose any estimation at all, but if you are gong to, then working statistically with simulation is the only way to take small sample numbers meaningful.

Commitment Velocity: Low-Ball as a policy.

Another approach, one perhaps controversial, but taught by some Scrum trainers is to pick the lowest historical delivered velocity. This is a commitment-based approach, on the assumption that building trust around consistent delivery is critical to building sound relationships where product owners and teams can safely state their needs and get things done with a minimum of contractual behaviour. By taking the minimum, you force a low-ball capacity, which means you can have high-confidence of success after a few iterations. You have, likely, after a while, some spare time on your hands. Teams can then choose to pull more work in (without adjusting their commitment velocity), work on “technical debt”, improve their skills, etc. A team could raise their commitment velocity in certain inflection points in the project. A new team member is added that provides a necessary skill not previously available, and after a few iterations the team is consistently hitting a higher number, but this is a careful process to ensure that they are committing, and if they don’t make their new number, it goes down to what they got accomplished.

Indemnify teams’ learning

An arguably healthier option, if you have built enough trust, is to simply indemnify a team from failing to meet the estimate. Since you’re doing mathematics on actuals to generate an expected future number, everyone can acknowledge that past behaviour is no guarantee of future behaviour, and simply use it for capacity planning. In this case, estimation is actually estimation, not commitment or contract. The team is expected to be ahead sometimes, and behind sometimes. The upside of this is that a lot of extra time isn’t spent playing with fictional numbers. Teams are spending their efforts on delivery as quickly-yet-sustain-ably as they can, and the organization treats them as trusted professionals in this. The temptation to assume you can predict the future is seen as folly, and the estimates are used to guide overall direction, not to make outward customer commitments.

Don’t be mindless

There may be other approaches, I’m sure. The agile community is certainly not short of people who love this topic and can talk for hours on “proper” estimation. The point of this post is merely to point out some options, and ask you to look at your organizational culture, team culture, customer culture, the meaning of terms like commitment, failure, success, consistency, speed, etc. As you understand the culture, balance consistency vs. speed, trust, and other factors to choose a method of estimation that meets your goals. Don’t do estimation based on your own, internal cultural assumptions, as you may have developed or been taught techniques that are useful when and where they were taught, but may no longer be so. Or maybe they weren’t so useful then either. Regardless, this because estimation cuts at the heart of the dialogue between producer and consumer, and establishes parameters for that discussion, it’s critical that you think your choice through.

[Christian also blogs at http://www.geekinasuit.com/]

The Importance of Questions

Posted on by
2

I’m currently doing some coaching work with Regina, a new project manager working with a small team of web developers at a community development organization in Toronto.  We had our first session last week. Regina was having trouble getting started on a particular project and I shared with her some of the Agile methods of creating a prioritized Cycle Plan, breaking it down into small tasks, etc.

Regina seems to be finding Agile methods helpful in general, but there was a special kind of interaction that we had around removing an obstacle that was particularly interesting for me.  It had to do with an email she received from Peter, a developer working on one of the websites she’s managing. Regina shared a concern that she didn’t know some of the technical terms Peter was using.  So I had her read through the email and form questions around the points she wasn’t clear about – i.e., “what are buttons?” and I wrote them down as she was speaking.

I then suggested that she compose a reply email containing the same set of questions.  Regina’s eyes opened wide and she exclaimed, “Oh yeah – that’s so obvious!”  I went on to mention that another option would be to go and do some research on her own but that there were some valuable advantages in asking Peter directly, particularly in terms of team-building, that may not be as immediately apparent as asking the questions solely for the purpose of having them answered.  Here are a few:

First, it’s a way forRegina to remind Peter that she does not have a technical background and that he should not assume that she is familiar with web-lingo.  Second, it also reminds him that she is a different person from the last manager he was working with and subtly reinforces that it’s important that they get to know each other as two individual human beings and learn to work together effectively.  Third, and perhaps most importantly, it gives Peter an opportunity to help someone else on the team learn something new, and by doing so, contribute to the culture of learning on the team.  Fourth, and perhaps most obviously, it promotes open lines of clear communication on the team.

(Of course, if the team was colocated, which it is not, lack of communication would be much less of an obstacle!)

Asking questions in the interest of learning makes it visible to others that you don’t know everything.  For some people, this presents a dilemma.  What makes it a dilemma is that asking meaningful questions is something that many people aren’t able to do well.  The ability to ask meaningful questions is a learnable skill requiring the capabilities of truthfulness, humility and courage.  Such capabilities – let’s call them moral capabilities – can themselves be developed through conscious, focused effort.

Someone in the position of a newly hired manager, or a veteran manager with a new team, who lacks these capabilities may feel that it is important to present to a team a persona of all-knowingness.  But, of course, this is false and the truth of one’s degree of knowledge and capability, or lack thereof, soon becomes apparent anyway.  Clearly, this person needs to do some honest hard work to develop some humility, but truthfulness and courage are still often major factors.

Or maybe you’re the kind of person (like Regina) who just doesn’t want to bother anyone.  In this case, humility is not necessarily lacking, but truthfulness – and perhaps most of all courage – may need some attention.  Concepts around moral capabilities deserve much more elaboration, but for the sake of brevity, I’ll leave it at that.

To sum it up, if you are open and clear in the way you ask questions, people will tend to appreciate it and will trust you more in the end.  Moreover, it can have a transformative effect on the environment of the team.  When your team members realize that you are not afraid to ask questions and be truthful about your lack of knowledge in a certain area, it will encourage them to be more truthful about their own capabilities.  Not to mention that most people feel good when they are able to help others.  When your team members feel safe to ask for help and free to help each other, it is empowering for everyone.

Asking meaningful questions, therefore, is an essential aspect of learning together, and nothing is a more powerful contributor to the success of an organization than a team that learns as a team.

Why we like working at Berteig Consulting

Posted on by
Reply

From Paul Heidema:

Most people despise the end of Sunday. This means that Monday, the dreaded start of the work week, is just around the corner. Most people don’ have a team that they trust at work. Most people are unable to be truthful with their boss, or even truthful with themselves about their work.

Fortunately, I am not one of those people. I work with great people. They are kind, honest, caring, and very professional. I work at Berteig Consulting. My team is made up of four people, one of which is me. Travis, who is very gifted in the arts is also very professional and down to earth. Mishkin is an ideal boss who cares deeply about his co-workers, and treats us all like brothers and sisters. Laila is pure and able to make others feel completely at home (she is also my wife).

I never know what will happen each week but I do know that I will be happy and enjoying the experience with such a wonderful team.

From Mishkin Berteig:

Every day that we start work, I’m happy to be here.  It’s a bit cliche, but I love the people I’m working with.  I also love the work we are doing.  The vision of the company is maturing and our focus on education has already changed the way some things are being done.  I like our work environment: there are three of us “crammed” into a small office room – we are constantly collaborating, discussing options and problems and reminding each other of work to do.  Hiring Laila to work with us part time has been an incredible change.  She thinks systematically about our way of working and makes suggestions in such a loving way that it is impossible to feel like we were even doing anything wrong in the first place.  For me personally, having Travis focus on the role of Process Facilitator (ScrumMaster) has also been a huge relief for me.  He keeps us in line with a lightweight agile process and I’m loving it!!!  Finally, for me, focusing my own efforts on business value has been great – with the help of Paul, Laila and Travis, I now have the mental space and the actual time to devote to this critical part of running a business.  I’m still learning like crazy, and it’s great fun!  I wish everyone could work in an environment like this… which is, of course, why we offer the services that we offer! :-)

From Travis Birch:

At Berteig Consulting, we practice Agile.  I am currently working in the role of process facilitator for our new team of 4.  We work in 1-week iterations.  As a couple of the team members have a 4-day work week, we have our retrospective on Monday mornings at 10 AM, followed by the planning meeting for our next iteration at 11 AM.  The remaining work days begin with a daily stand-up meeting using the reporting methods of a daily Scrum (each member reports 3 things to the team – “What I did yesterday”, What I’m doing today”, and “What are my obstacles”).  We work in a collocated team room, with items, tasks, obstacles, definition of done and burn-down chart all up on the walls.  We just completed our second iteration.  As part of today’s retrospective, team members actually did some demos – Mishkin showed us some of the great changes he’s made to his course material and Paul demoed our beautiful newsletter.  Laila even demoed some travel tools that she’s been working on for the trainers.  We also decided to each write our reflections in order to share them with those who might find it useful as a way of wrapping up the retrospective for this iteration.

Visibility of work and openness of consultation feeds an overall feeling of excitement and optimism in the team!

From Laila Heidema:

Having worked at Berteig Consulting for merely two weeks, I already feel that I am part of a team. I feel that I am contributing in helping people with their business in an environment that is creative, supportive, joyful and cooperative. I know that each week will bring interesting new tasks that will not feel like a mundane set of work, or carried out in order to finish the week. Rather, each project is completed with a sense of contribution towards the company’s quest to be the best corporate educator for humanity. Were it not for Berteig’s positive atmosphere and team dynamic, this would not be possible.

Measuring Process Improvements – Cycle Time?

Posted on by
1

One of the challenges with agile methods is to get a clear perspective on how to measure process improvements. I recently had a brief discussion with a C-level executive at a small organization about this. His concern was that cycle time was meaningless because it depended so much upon the size of the work package. So how do we use cycle time as a meaningful measurement? What else can we use to measure process improvement?

Let’s look at the difference in measuring cycle time in an agile vs. non-agile environment. Then we’ll get to other measurements.

Cycle Time , Waterfall and Agile

First, let’s define cycle time. From iSixSigma we have:

Cycle time is the total time from the beginning to the end of your process, as defined by you and your customer. Cycle time includes process time, during which a unit is acted upon to bring it closer to an output, and delay time, during which a unit of work is spent waiting to take the next action.

This definition is important because it gives us a clue about the potential difference between a waterfall vs. agile method of delivering value. Let’s imagine the typical process used in a waterfall environment. The following are the high-level steps:

  1. Customer / User / Stakeholder sees a need, validates it and submits a request to have that need fulfilled. This is when we start the clock on cycle time.
  2. The fulfillment organization (IT, Product Development, R&D) puts the request in a queue, backlog or requirements management system.
  3. Along with other requests, the fulfillment organization schedules the work on the request, usually by creating a project to fulfill it and other related requests. The project is estimated at a high level, the current status of in-flight projects is noted, and the new project is prioritized relative to other projects.
  4. At some point, based on the schedule and the reality of the work on other projects, the project containing our customer’s request is started. Here, “started” means that detailed requirements are gathered.
  5. After sufficient requirements are gathered, a detailed technical analysis is done including architecture, high-level design, risk analysis, etc.
  6. Development begins. (Note: many people mistakenly start measuring cycle time here.)
  7. Developers and testers work to validate the results of development and fix any problems discovered.
  8. Final acceptance testing is done.
  9. The results of the project are deployed to users, sold to the client, or in some other way passed back to the original requestor. This is when we stop the clock on cycle time.

So from the start of the customer request formally submitted to the time that the fulfillment of that request is made is our true cycle time. There are a few important things to note here. First, there is a queue of work based on requests made but not yet scheduled. There is another queue for work scheduled but not yet started. We know that if we can reduce the size of these queues, we can improve cycle time in a general sense. Second, we know that most organizations of any significant size will have different queues based on the urgency of the request. For example, a high severity bug discovered in the production system of a company’s largest client will be treated differently than a wish list item for a small not-yet-client. These two requests won’t even go in the same queue: the high priority problem will be quickly escalated to a support or development team that can work on it immediately. Third, it is tempting for the development group to measure their local cycle time. This is a Really Bad Idea since it leads to sub-optimizing behaviors. For example, it is easy for the development team to improve their cycle time by sacrificing quality… but this just causes the QA cycle time to increase, and probably the overall cycle time (true cycle time) is affected more than the local improvement in the development group’s cycle time.

Now let’s look at the steps that occur in an ideal agile environment:

  1. As before, the Customer / User / Stakeholder sees a need, validates it and submits a request to have that need fulfilled.
  2. That request is immediately placed in a ready state for the next iteration (cycle, sprint) of a delivery team. Elapsed time: maximum one month.
  3. Team completes the request including all work to actually deliver/deploy and work is delivered to the stakeholder at the end of the iteration. Elapsed time: maximum two months.

So the ideal method of doing agile has a maximum cycle time of two months to deliver from the time a request is made… how many teams are doing this? Not many.

The ideal is extremely difficult to accomplish. Getting to that state requires that the development organization catches up to the business side so that there are zero pending requests at the start of each iteration. It also requires that the business side users and stakeholders are able to articulate their requests so that they are small, and appropriately detailed for the team doing the work.

A realistic agile implementation actually is a lot more messy. Depending on the type of request, the cycle time for a piece of work can vary widely. Some low priority items may take years even in an agile environment. A low priority request is made and approved but then never quite makes it into a project… and then once in a project never quite makes it to the top of the team’s product backlog. This is interesting to look at sometimes, but it points out another important aspect of measuring cycle time: mostly we care about average cycle time (or some other statistically interesting aggregate measure).

The predominant factor in most organizations’ cycle time is the number and size of the queues they use as work is processed. In most organizations there are several queues and most of them contain large numbers of requests or bits of work in process. Queues represent huge amounts of waste. It is easy to see that queue size and cycle time are closely related: the more items in a queue, the longer the cycle time.

This leads to a simple conclusion: regardless of lifecycle approach, reducing the size of an organization’s queues is one of the easiest ways to reduce cycle time. What are some common queues? There are often queues of projects, queues of enhancement requests, queues of defects to be fixed, queues of features, queues of tasks, queues of email (large inboxes), queues of approval requests, queues of production database changes. The number of queues increases the more an organization is oriented around functional groups, and the number of queues decreases the more an organization arranges work to be handled by cross-functional teams.

Cycle Time and Work Package Size

This is where queueing theory and agile methods intersect really well. Cycle time is related to the load on your system, in particular your units of work processing. In most organizations, teams are created to handle work. The more work given to a team simultaneously, the higher their utilization level. Many organizations like high utilization levels because it gives them a guarantee that people are doing valuable work all the time that they are paid to work. This is a completely false benefit and in fact is extremely destructive to overall productivity. From queueing theory we know that the cycle time for a piece of work increases exponentially to the utilization level. We see this whenever we over-load a server… but for some reason we fail to see this when we overload a person or a team or an organization even though it still happens.

Cycle time is also related to the variability in the size of the work packages. Low variability means that the exponential factor related to load is low, and high variability means that the exponential factor is high. In other words, if you have a highway that only allows motorbikes, you can have a very high load without getting bad traffic jams. On the other hand, if you have a highway that allows anything on it, you get traffic jams even with low levels of load. This is why HOV or commuter lanes and the left lane in multi-lane highways don’t typically allow transport trucks and buses. This result from queueing theory is not intuitively obvious so it is even harder for us to apply to software development.

But apply these two ideas, load and work size variability, we must if we wish to create a high performance development organization. The simplest way to do this is to have a single team work on a single project at a time and use iterations to ensure that the work being done is always exactly the same size – the size of the iteration.

Improving Cycle Time

It is possible to have very short iterations and still have a long cycle time. Many organizations make a few common mistakes with agile that cause this. If the work done inside each iteration is restricted to pure development work and everything else is done outside the iterations, then cycle time likely stays long. A common example of this is having the QA folks remain separate from the development team and do their work after a development team releases their work.

There is really only one way to avoid this: have a comprehensive definition of “done” that is met by the team every single iteration. This ensures that all work from idea to release for a given customer request is done inside a single iteration. A side effect of this is that all the pieces of work need to be small. It also gets rid of all the queues except one: the queue of ideas approved for delivery. With a single queue to manage, it becomes easy to measure cycle time, and therefore easy to improve it.

Improving cycle time can now be done in a few ways:

  1. Put a cap on the number of items in the work queue. Since cycle time is directly related to the size of the queues in a system, this is a sure way of putting a maximum on cycle time.
  2. Go through all existing requests and throw as many away as possible. This can be tough to do, but if you are able to do a cost benefit analysis, you will typically find that older items in the queue are no longer worth while.
  3. Provide more stringent gating functions for allowing requests onto the queue. The few items added, the faster the size of the queue is reduced.
  4. And of course, increase the performance of your team(s) so that they go through items on the queue more quickly.

Productivity and Cycle Time

Once you have control of cycle time, it is possible to make reasonable measurements of productivity and two more metrics become extremely important (not that they weren’t important before, but they are easier to work with now). The first is Return on Investment (ROI) and the second is customer satisfaction.

ROI is in its simplest form a measure of how much benefit there is to doing something as compared to the cost of doing it. It takes into account the importance of time and timing, the importance of other options you may have, and of course, hopefully takes into account the business reality of your work. It also takes into account costs.

In software development, the primary cost is the cost of the staff doing the work, and the time factor is your cycle time (Ah! that’s where we use it). If you have a consistent team working on iterations that are always the same size and if you have little or no work being done outside of the iterations, it is very easy to calculate ROI in a useful way. Simply measure how much value a given iteration worth of work will generate and divide by the cost of the team for an iterations (and if the team is not yet doing work as it comes in, take into account the time value of money since the work might not be done for several iterations). Now, productivity is simply a measure of the Return for each Team-Iteration. Dollars/iteration. Simple. If the team’s productivity goes down, you can ask some really simple questions:

  • Did the expected return of the work go down? If so, is there more valuable work the team should be doing? This becomes an opportunity for product improvement.
  • If not, what caused the team to get less done? Was the work harder than expected? Was there a skill gap? Was there an organizational obstacle that was revealed? Was someone sick? This becomes an opportunity for process and team improvement.

Customer satisfaction can be measured in many ways. If you have already started using agile practices, there is a good chance that your customers will already be more satisfied than they were before. This will show up informally through word-of-mouth. However, it is good to have a more systematic way of measuring customer satisfaction. One of the simplest and most commonly used methods of measuring customer satisfaction is the Net Promoter Score. From WikiPedia:

Companies obtain their Net Promoter Score by asking customers a single question (usually, “How likely is it that you would recommend us to a friend or colleague?”). Based on their responses, customers can be categorized into one of three groups: Promoters, Passives, and Detractors. In the net promoter framework, Promoters are viewed as valuable assets that drive profitable growth because of their repeat/increased purchases, longevity and referrals, while Detractors are seen as liabilities that destroy profitable growth because of their complaints, reduced purchases/defection and negative word-of-mouth. Companies calculate their Net Promoter Score by subtracting their % Detractors from their % Promoters.

The Net Promoter Score is closely linked to quality including the hard-to-measure parts of quality like responsiveness, ease of use, and fitness for purpose.

Cycle time also affects customer satisfaction. The faster you can respond to requests by customer, users or other stakeholders, the more likely they are to be satisfied. This happens for two reasons: fast response time means that solutions are more likely to still be useful and correct when actually delivered, and it also gives more opportunities for feedback.

In fact, if we look at these three measures, cycle time, ROI and customer satisfaction, we see that they form a mutually supporting and cross-checking system of ensuring productivity and effectiveness. Measuring anything else muddies the waters and can cause sub-optimal behaviors. The real challenge for most teams is realizing that all their local measures of performance and effectiveness may actually be causing harm (unintentionally) because they draw the team’s attention away from the three organizationally important measures.

Cycle time is the measure that is most closely related to process improvements, but ROI and customer satisfaction should also be used to ensure that process improvements don’t accidentally harm the organization.

The Best Agile Practices to Implement Now (Highest Return on Investment)

Posted on by
1

Everywhere I go, there are three practices that make the biggest difference in overall productivity for teams and organizations. All three practices are part of agile methods such as Scrum and Extreme Programming, but you don’t need to be doing these methods to take advantage of these practices. All of them are relatively inexpensive, and the return on investment for these practices is HUGE!!! Without further ado…

1. A Proper Team Room

This is astonishing: you can expect a 60% boost in team productivity from this single practice! The cost of re-stacking your cubes or office spaces is trivial compared to the benefits. If you are going to do this, do it right! Do the research, hire an agile coach or consultant, but make sure it is done well. One organization I worked with was very excited about their new team room setup. They had a nice open-concept layout with lots of windows etc. But they had also made some big mistakes including that all the developers on a single team would have a low wall separating them from each other. Because of poor layout that would block communication paths, their new setup would actually be worse than their old setup! Some research has shown that you can expect as much as a doubling of productivity (reference). This is one practice you don’t want to let your competitors pick up before you do! Here are some tips on agile team room setup.

Example Agile Team Room

2. Short Iterations

Once you have set up your team room, it is critical for your team to have something to do! The fastest way to get your team doing something is to start using short cycles of work (iterations, sprints) to deliver valuable results such as working software. Many software development projects use iterations that are two weeks long or even a month long. I strongly recommend iterations that are only one week long. Again, the benefits are incredible: your team will move through the stages of team development (forming, storming, norming and performing – reference) much more quickly than with longer iterations or no iterations… thus leading to high productivity much sooner. The value here is in the time gained. This chart demonstrates how this works:

short iterations boost team productivity

The short iterations provide a certain type of pressure that forces team and project crisis to happen quickly. However, because iterations deliver working, valuable results, the pressure is not demoralizing, instead it motivates teams to get through the crisis and reach the norming and performing stages of development quickly. Again, to make this work, there are some critical success factors including methods of allowing team commitment, self-organizing and obstacle removal.

3. Test Driven Development

There is a myth that speed and quality are mutually exclusive. This comes from the idea that you need to slow down to make stuff high quality or that you need to sacrifice quality in order to go fast. It is true that initially you might get gains through these approaches. The really amazing thing happens when you try, deliberately and systematically, to do both high speed and high quality work. In software development this is best done through test driven development. In informal polling I’ve done with teams I’ve worked with, test driven development produces a noticeable long-term productivity gain as well as a simultaneous increase in developer and end user satisfaction due to a substantial reduction in defects discovered after the code leaves the developers. I have seen teams doing this that reduce defect rates to 5% (or less!) of what they once were prior to test driven development… while at the same time delivering projects faster than expected. Since substantial expense is squandered on defect management (tools, support teams, user training, lost productivity, etc.) and since staff turnover is also high in IT and high-tech, the results of test driven development on the bottom line are substantial.

Benefit of All Three Practices

If a team and an organization adopt these practices, get through the initial cost of learning them, then I would like to suggest that your teams can easily double their productivity if not more. For a team of 5 people working on a 100 day project this amounts to shortening the project to 50 days (save $200,000) or get twice as much work done. Clearly, an organization that adopted these practices and perfected them would save huge amounts of money and would be able to crush any competitors not doing this.

Previously I wrote a more general treatment of the benefits of agile and an article that lists other resources discussing the benefits of agile.

Any discussion of benefits should at least say a few words about how exactly to measure those benefits! However, I’m out of time. How do you measure the benefits of agile?

Hey folks, if you found this useful, could you please “Digg” and “Reddit” this article?  Thanks!

Not getting the benefits of agile? Consider the Agile Clinic!

Agile is NOT a Silver Bullet

Posted on by
Reply

The recent growth in the popularity of agile methods such as Scrum is gratifying. However, I am constantly encountering people looking for the Silver Bullet of software development. In the paper written by Brooks, No Silver Bullet[pdf], he describes “accidental” and “essential” complexity. Agile in no way changes his arguments. What agile methods do is to help remove the accidental complexity associated with people and their interactions. This can lead to substantial increases in productivity, but it does not change the hardness of the underlying problem that is being solved by building a particular software system. In fact, doing a good job with agile methods, in particular Scrum, is extremely hard work due to the deep cultural shifts that must occur in order to get the full benefits.

Agile becomes Easier with Useful Tools

Posted on by
12

For the last 3 months I have been lucky to work with tools and in an environment that is agile. My job requires lots of small projects and tasks and my job title is clear but my work is every changing. I like new challenges and creative tasks.

Recently our small team has been using http://cardmeeting.com/ an online tool to add ideas, set up tasks, and keep track of what the whole is doing and what still needs to be done.

I am looking for more tools to make our agile practices more streamlined and efficient. Any suggestions or ideas?

Scaling Scrum and Agile – Seven Online References

Posted on by
Reply

I’m working with a number of companies using agile methods that have between 10 and 20 teams all working on the same product/project/program. They didn’t start small. These aren’t cases of organically growing from one good agile team to many good agile teams. Rather, these are organizations that have grown up in a non-agile approach and now want to reap the benefits of agile with their many teams. What is interesting is that these organizations all have some common problems and then all have some unique problems. There isn’t an obvious prescription for how they should be doing their agile implementations. I hope to write a few articles about scaling agile and scrum, and this one is our starting point: what reading should you do if you find yourself in the situation of trying to build a large agile organization.

Continue reading →

Estimating Software Projects

Posted on by
2

There is an interesting article called “Software Estimates and the Parable of the Cave“. It starts out well. The cave parable is effective and clearly conveys the problem with estimating software work. However, there is a big section of the article called “Applying this Wisdom” which I think does a dis-service to everyone. Let’s look at this closely…

Continue reading →