April 16, 2014

All Posts By: Alan Dayley

Agile Coaching Blog

Alan Dayley

About Alan Dayley

Alan brings more than 25 years of software engineering experience to his Agile Coaching practice. Agile Coach, Certified ScrumMaster, Certified Scrum Product Owner, Certified Scrum Professional.

Alan works with teams and management in strengthening the people side of creative work. A volunteer founding member of the Phoenix Scrum User Group steering team, he loves to help people learn and create innovation at their company and in their life.

“When someone is just starting out with Agile and Scrum, they need to define what the desired goal will be. What is the problem to be solved? If that problem or goal is connected to delighting customers, they will have a jump start on success!”

What Big User Stories Could be Telling You

User stories are intended to be a high level description of some functionality. It is, however, common to find user stories growing into specs or large use cases that resemble whatever the organization used to do, back when they did large requirements documents. Comments like “The stories are not detailed enough to start development” or “This took much longer than expected so we should have more acceptance criteria for next time” can become common. There is a balance here that we should watch and adjust carefully. And most of the time we think the solution is more story documentation.

Here is the story card AND all the acceptance criteria, wire frames, specs, use cases, test plans, flow diagrams, architecture...

Why User Stories Get Big

I like user stories as an easy to understand idea for a company to start thinking about a light weight way to communicate needs, features and benefits. It is hard to describe in brief sentences all the forces that pull organizations to keep them thinking in lots of details. A few might be:

  • A culture and history of Big Design Up Front that makes it hard for feature definition to happen just in time.
  • A continued need for long range planning requiring estimates for work that will possibly take months before it actually starts.
  • Skilled technical people who are accustomed to talking about technical details instead of the needs of the user.
  • And more…

Lack of Focus

The most powerful and subtle force to cause “user stories” to grow is a continued lack of focus for the people defining features and those creating the features.

For example, if I am Product Owner of 5-12 products working with 3 teams who are all working on multiple products, I am not able to think of a feature, collaborate on it’s definition as it is built, see it created and then think about the next feature. I have to document my thinking of every feature because one hour from now I have to think about other features that also might not be built right away.

The key to being truly Agile is to finish stuff. The more inventory of ideas, features, undeployed code, etc. that we have, the less Agile we can be.

Have Conversations

In short, Ron Jeffries, the inventor of User Stories, said that the user story should have “3Cs” of attributes: Card (small enough to fit on an index card), Conversation (is a place holder for conversation) and Confirmation (a definition of when we are done, such as acceptance criteria). Most of the symptoms prevalent when stories grow big are likely indicators that the Conversations are not taking place and people are writing stuff down in an attempt to fill the gap.

Don’t write more stuff down. Figure out why the right conversations are not happening. i.e. “Individuals and interactions over processes and tools.” That said, sometimes what we see as an over-documented abuse of the user story is a vast improvement on what the organization used to do. We have to temper our zeal with a dose of client reality as we work to get incrementally better.

Do you see user stories getting too big? If you don’t use user stories, does what you use help or hinder conversations? What is your balance between the ability to deliver vs. the need to document thinking?

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



Video: Thoughts On Agile Design with Dave Gray and Alan Dayley!

Gamestorming is one of the foundational books on interactive and highly collaborative meetings. Dave Gray, one of the book’s authors, has begun working on a new book titled “Agile Design Principles.” He is interviewing various people who work and write about Agile ways of working. I was pleased to be interviewed.

Our discussion ranged fairly wide, as you can see from the topic list below the video. Enjoy!

  • 0:01:00 – What does Agile Design mean?
  • 0:03:38 – The utility of “open plan” offices and what makes them work or fail
  • 0:09:30 – Teams should control how they work
  • 0:10:13 – Good interruptions vs. bad interruptions
  • 0:12:58 – Working before Agile and getting to it
  • 0:14:55 – Technical debt can be the spur to change
  • 0:18:38 – W. Edwards Deming and seeing “the system” when software is ephemeral
  • 0:21:58 – Distributed teams can work by paying attention to communication
  • 0:24:01 – The social part of Agile and how it helps
  • 0:26:04 – Division of labor is not necessarily as good as we think
  • 0:30:52 – Teams of teams keeping coordinated with Product Walls
  • 0:38:30 – Leadership gives the place to start, the framework to catalyze self-organization
  • 0:39:30 – What Agile and self-organization means for managers
  • 0:42:35 – Common obstacles to transitioning to Agile ways of working
  • 0:47:32 – Capacity in full-time equivalent hours vs. empirical measure of capacity
  • 0:52:05 – Definition of Done
  • 0:53:39 – Is there a “no excuses rule” in Agile?
  • 0:56:38 – Empowerment vs. power
  • 0:58:45 – Going back to Deming, the “system” of sports teams and hero experts
  • 1:02:40 – Create a culture of safety and trust in order to innovate

I enjoyed talking with Dave and I hope you can gain some tips and insights from our conversation.

Want more Alan Dayley in your life? Dive in.

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



The Volume Knob

A Parable

Charlie walked into the stereo store. He was looking to upgrade his old home system to something that sounds better. He had a nice budget and expected to be enjoying rich, full sound by evening.

He found a system more expensive than he had ever spent but still in his budget. It had the usual controls with a large volume knob, loudness and so on. It also had equalizer sliders that would physically move seemingly by themselves when he fiddled with some preset mixes. Wow, that was cool! There were also some controls that had to do with echo, which Charlie knew nothing about.

Right then, Dave, a store employee, came over asking if he could help Charlie make a selection. “How do these different knobs control the attributes of the sound?” asked Charlie.

“Good question,” said Dave, with a smile. “I find that the sound output improves if I turn up the volume.”

Just turn up the volume?

Just turn up the volume?

“The volume improves the sound? What do you mean?”

“Well, I don’t really worry about all these other knobs. If the music is loud enough it sounds good enough to me.”

Charlie scratched his head. “Wouldn’t the music eventually get too loud to enjoy?”

“I don’t really understand how these other controls work,” said Dave chuckling. “It gets to be too much work to figure out what I should or should not adjust. So, I just turn up the volume until it sounds good.”

Puzzled, Charlie asked “Then why are all these other adjustments provided on the system? I could just buy that cheap system over there without all these controls.”

“Yep, you could do that,” agreed Dave, adding with a big smile, “But this system is so much louder!”

Is More Better?

Most organizations seem to have a “volume knob” that is the default action to get more output from anyone. And the “knob” is labeled “overtime,” “extra hours” or “startup mode.” Yes, these high quality people will make more output by working longer hours. Seems a waste of talent and creativity. Wouldn’t it be a better use of people to do what it takes to get the best outcome for the least amount of output?

Adjust The Treble

The most powerful way to a great product lies in deciding what to not create. The highlights and beautiful clearness of thrilling features can be muddied by trying to do too much. By adjusting the “treble” of your product, your teams can focus on giving the customer what they really want.

Drop The Bass

Teams running at full speed and overtime don’t have the time to create a technologically solid foundation. Unit tests, automated regression tests and continuous integration provide the “rhythm keeping bass” to your product. Ignoring the foundation of technical excellence leaves your product on shaky standing, no matter how many hours people work.

Watch The Levels

Every system of production has a constraint, that point where the capacity to work is restricted. Like the level display on a stereo, visualizing the flow of work through your teams can reveal the constraint. Changing your system to remove the constraint, even just “moving the equalizer slider” a little bit, has higher long term benefits than working harder.

Surround Sound

The value of being a true team can be unlocked by “surrounding” features and stories together instead of defining ways for individuals to work by themselves. Establish team work in process limits and other work agreements to create collaborative work.

Beyond The Volume Knob

There are many other possibilities to improve the outcome of your work. How about the “tuning” knob of validation, finding out if that feature really is what your users want. Or maybe the “balance” knob of pair programming. There are so many things teams, managers and organizations can improve that allows you to keep a sustainable pace.

Rich and Full, Not Loud

Bad sound does not improve with more volume. More output does not improve the quality nor the richness of your product. It’s just more. Find the “knob” in your organization that will enable “rich and full music” to your customers’ ears!

Pretend you didn’t have a “volume knob,” that people can work extra hours. What other product building adjustments can you make to create an even better “sound?”


Quiet Time vs. Interaction Time

A fellow BigVisible coach started an interesting conversation on our internal email lists the other day. He pointed to a post about the idea of “No Talk Thursdays” which referenced this article at Forbes. The contrast between quiet time and interaction time is a hard balance to make.

As you might imagine, many of us expressed concern about eliminating an entire day of collaboration every week. On the other hand, quiet time can be important. These questions about quiet time, interaction and collaboration are part of environment design. The environment in which we work is a big part of productivity for individuals and a team.

In my thinking there are two main boundaries for quiet time vs. interactive time.

Why Quiet Time

First we can look at the needs of introverts vs. extroverts. We have been recently reminded that introverts are creative and powerful, just in a way not usually rewarded by organizations. Introverts can be largely defined as people who gain personal energy when doing things alone and lose energy when in active groups. A collaborative team is important but must allow quiet time for people who need it.

Extroverts and Introverts both important to interaction

Extroverts and Introverts both need support

When An Interruption Isn’t

Second we look at interruptions vs. working. A highly collaborative team might look from the outside as if everyone is interrupting each other all the time. The goal is to make every interruption about the work at hand, which means team members interrupting each other is actually helpful rather than derailing thought trains of individuals. Agile ways of working attempt to focus a fully cross-functional team on small slices of work. We can also encourage teams to limit the amount of work items in process so that they swarm on a small amount of work until it is done. These and other Agile ideas help make a higher percentage of interruptions valuable instead of distracting.

Finding Interaction Balance

In my highly introvert past I can remember wonderful days of working alone and making progress. I can also remember wonderful days of working with others because our focus was tight on the same goal. I have experienced that, even as an introvert, I can work days without quiet time if most of the “interruptions” are part of getting the work done.

So, what about having a “quiet day?” I would first explore if a policy of No Talk Thursday is an indicator of  too much multitasking, split attention or extrovert-bias. Thankfully someone is trying to address a need for focus with this policy. And they probably need help addressing the root cause of the policy, rather than mandating a fix that may not directly address the real problem.


Will Agile Process Work For My Project? Defined vs. Empirical

As an Agile Coach I often get a question about when Agile frameworks should or should not be used. One of these is whether or not an Agile framework is suitable for a particular project or product. This question is not easy to answer, especially since the one asking the question has more knowledge of the proposed work than I do!

One thinking tool to help make such a decision is to contrast “defined process control” with “empirical process control.” This video explains what I mean.

Is your project or product definable before you start working or do you need empirical data to help build the solution? Looking for more clarification on this topic or anything else agile? Just ask, we will do our best to get you started in the right direction!

It’s kinda nice having a coach in your corner, right?


Agile Planning: Why it’s hard to say when

A couple of weeks ago I was leading a story mapping workshop. As I was explaining the process several questions came up around knowing when things would get done. Since we were just getting started, that moment was not the time for a answering questions of when.

When to Answer When

The work of turning ideas into product features involves many questions, only one of which is when. The trick is when will a feature or set of features be complete is not directly answerable. All the other questions and their answers feed the schedule answer and cannot be ignored. We can answer when only as we answer the other needful questions.


The obvious answer is that you want to get paid, to make a profit. It is possible that the motivations to do the work are more and different than profit. Motivations have bearing on schedule.


Who your users are and the market you are targeting certainly effects when the work needs to be done. Different markets and different users have their own needs for timing and expectations.


What the product does and what value it brings to your customers are among the more important points to understand well.


The development teams answer this question by understanding technology, tools and experience. Estimations are part of the how answer because size of effort is directly tied to the people doing the work.

We can only answer when, when [grin] we have answers from the questions above. When sits in the middle of all the other questions and is directly affected by choices we make in their realms.

See how it is hard to say when?

Agile Planning and When

Part of the power in Agile frameworks is the separation of product questions so that they each get the attention needed. Agile frameworks only work well when feedback from all the other questions helps determine when. Agile frameworks give us two ways of answering when and only one direct manipulator of when.

The first way is fixed date, variable scope: When the date is fixed, it’s still just a day on the calendar. In this case the number of features that will be completed by that date, the scope, is necessarily variable. (Even if we don’t want it to be.) We ship everything that is complete on that date. Since Agile frameworks require that the product be maintained in a shippable state, picking a ship date is not hard.

The second way is variable date, fixed scope: If the minimum marketable feature set is large, meaning we have defined a fixed scope of features, the ship date is variable. When to ship is answered given by the date all of the minimum features are complete.

(It is important to note that Agile frameworks do not provide for a way to have both fixed schedule and fixed scope. Neither does any other way of working. It is just that we pretend that we can fix scope and schedule. We in the software industry have been largely failing to do fixed schedule and fixed scope software development for decades. Agile frameworks are empirical processes, where we adjust our work based on the information we gather while doing the work. Fixed answers to when and what are not supported in empirical work. But this is a larger and different discussion.)

The one direct manipulator for answering the question of when is priority. In other words, we can ensure a feature is done before a given date by deciding to work on that feature first. This is why it is so important to take the time to order your backlog with the most important, valuable, risky, etc. features at the top, to be worked on and completed soonest.

Division of Answers

Agile frameworks provide for a division of responsibility in part so that we can get answers to these questions. This way each question is supposed to get deserved focus. For example, in Scrum the Product Owner is the role that focuses most on the question of what should be created. The development team owns the question how. The teams help stakeholders and others answer who and why. These divisions are not walls but areas of focus, as every role informs the other roles and questions. And every question feeds to answer when.

When is in the middle.

When is in the middle.


Agile Transformation: Sustainable Pace

When reading literature about Agile or talking to practitioners we often hear the term “sustainable pace.” Anyone who is overworked might think two things: Sustainable pace sounds wonderful and impossible. Upon discussing the term, many people struggle with believing that the required work could be accomplished under this constraint. Some think that software creation and sustainable pace are mutually exclusive.

A cycling team keeps sustainable pace

Image (CC) by muffinn on Flickr

A long-distance cycling team cannot run as fast as physically possible for the whole race. An organization also cannot continuously drive output as fast as possible and expect to remain viable. Pushing harder and harder for output actually damages the ability to get the needed outcomes.

Sustainable Pace Origins

The Agile Manifesto has several ideas that support the idea of sustainable pace. One of the twelve principles states:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

In Extreme Programming practices the idea of “Sustainable, Measurable, Predictable Pace” is also highlighted.

Positive Attributes of Sustainable Pace

Let’s briefly address the reasons for sustainable pace that are so obvious that we tend to ignore them.

  • Prevents burnout which helps in turnover prevention.
  • Lowering stress has many benefits from increased health, improved state of mind and less absenteeism.
  • Working long hours for more than a week or two leads to less productivity than working fewer hours.
  • Working at a pace that is too high results in decreased quality and more mistakes.

Agile Transformation and Sustainable Pace

As a company transforms to a more agile way of working and move towards sustainable pace, many fear that less work will get done despite the bullet points mentioned above.Here are some additional benefits of working at a sustainable pace.

Sometimes forcing our work pace to slow down despite heavy work loads can reveal places for larger improvements. For example, if we remove the option to work long hours, we have more incentive to improve effectiveness in other ways (continuous integration, automated testing, skill building, clear communication, etc.). If we always just work three days of 12 hours each at the end of every sprint, or several weeks of overtime to finish a release, we are masking places we could improve. Improvements that pay benefits every day of the future.

Sustainable pace also helps focus on empirical data for planning, which brings predictability. The customer or business reasonably wants to understand when some parts of the product will be ready. Injecting periods of long hours into our work stream increases the variability in our system, drastically decreasing our ability to know our own true capabilities. If the team is working at a sustainable pace, the amount of finished work they can deliver in a given period of time is fairly predictable. There will be ups and downs because of life, especially at the individual team member level. But the team as a whole, over the course of some time working together, will have a fairly stable amount of work completed each time box.

Some people, including myself, work better under some amount of urgency. I think of a sense of urgency as “positive” stress. Positive desire and motivation best comes from the fact that the team is engaged in the work. When the work has obvious value, when the team, sponsors and customers are working together to build the future. Always doing the most important and valuable work available provides a sense of accomplishment can be addictive and motivating!

Your Sustainable Pace

A 40 hour work week is arbitrary, though it may be expected or mandated by law. For some individuals it is more time than they can be highly productive and others will want to do more than that. The team needs to find their balance. Worrying too much about filling 40 hours or not going over is worrying too much about cost. Work on maximizing value produced and the hours spent won’t matter so much. A team that is five times more effective could work 30 hours a week and still be producing more value than before they became Agile!

Instead of expecting to work 10+ hours per day, spend some time looking at what you can improve to get even more work done at a sustainable pace.