July 25, 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!”

Velocity Is Like A Helium Balloon

Lately I have had many conversations about team velocity. Most of these conversations have had an element in them about increasing team velocity. Questions and statements like, “How can I get the team to increase their velocity?” or “We must complete an additional 20 points this sprint.” Often these ideas are accompanied by extensive velocity analysis, discussions keeping individuals 100% busy and so on.

Velocity Is Like A Helium Balloon

Attempting to directly manipulate team velocity is risky and often counterproductive. It can result in the team simply increasing their story point estimates or in taking shortcuts of quality and design so they can get a better number. Such actions damage the utility of the velocity as an input to planning and hide reality from the decision making process. Rather than worry and work over making velocity go up, remember this:

Download This Image as a Poster!

Velocity is like a balloon. It will rise on its own if nothing is holding it down!

Share:

Random Issues in the Agile Transformation Bridge

The other day I was thinking about the problems I have been seeing with clients. My thoughts expanded from the current team and organization concerns to more general scope of experiences with other transformations. Below is the resulting list of ideas, in no particular order and without fanfare. Let’s talk about it if you’d like to go deeper on your favorite!

Random Issues in the Agile Transformation Bridge

Tacoma-narrows-bridge-collapse

  • Managing by email doesn’t work well. Leading a transformation by email doesn’t work at all.
  • Documents are important. Leading by example is vastly more important.
  • Before you can scale Agile (or anything else) you have to have Agile (or that anything) to scale.
  • If the business around the teams does not change, the teams will work they way they always have and just use the new labels for what they do. And have more frustration.
  • Policies, procedures and processes send messages. These messages define your culture. To ignore the messages is to ignore culture.
  • Culture eats strategy for lunch. And dinner. And steals your lunch money. Unless culture is aligned with your strategy. Then it gives you lunch. And Dinner. And more lunch money in beautiful greeting cards.
  • Ownership of improvements is better handled by those who need to improve. That means improvements mandated by others rarely create the desired result.
  • If a team doesn’t have what they need to get the work done, asking them to work harder will not help much.
  • For every decision maker or specialized skill that is not dedicated to a team add two days to every request. For example, if the stakeholder needs to approve a feature change it will take at least two days to get an answer. If a meeting is needed, add four days.
  • 99% or more of the time everyone is doing the best they can under the circumstances. Check your system and environment for the root causes of failure, not your people.
Share:

The Release Plan: The Who, What, When, Why and How

The release plan is the team’s current understanding of what features are going into the next release of software, how many effective developers are deployed on it, and the current status of the development effort. But how do you go about planning that release, especially if you don’t know your velocity?

In this video I’ll cover how a team plans a release based on a groomed backlog and come up with an initial velocity of the first sprint. How it works and the results of each sprint will update how the plan is published and moved forward in subsequent sprints. I’ll walk you through the steps on how to plan an entire release.

Want 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.

subscribe

Share:

Securing Successful Deliveries – An Agile Case Study

When it comes to delivery challenges, that’s our speciality! Here’s an agile case study about a firm who hoped to implement agile practices, wanting to reduce overtime and significantly increase on-time deliveries.

Just the Facts:
The Challenge: Launch six agile teams and help them move toward on-time quarterly releases

The Client’s Goals: Use agile development practices to release on-time while working at a sustainable pace

The BigVisible Approach: Understand the current situation, agile understanding and pain points. Design a training and coaching plan to launch first four teams. Learn, adjust, and scale accordingly. Help the client design improvement plans for continued success.

What We Delivered: Launched six agile teams and coached them through two releases. Helped leadership create cross-functional teams along product lines. Introduced product road-mapping and release planning workshops to coordinate work of multiple teams.

Summary:
A cyber-security firm hired BigVisible to help them implement agile, with the hope of reducing overtime, and increasing on-time deliveries. Our agile coach helped the client start with a few well designed cross-functional teams and then expand to a total of six agile teams, each of which was trained in agile, coached in estimation and backlog creation, and aided in learning and improvement. The results have been impressive so far. Features that used to take six months just to be planned are now being planned and implemented in two weeks. Overtime has been reduced from three months to about two weeks, with some teams actually finishing early. Release cycles are down from 18 months to 3 months, with quality up and features more in line with end-user expectations. The best news is, this company is just beginning and continues to improve with every sprint.

WANT TO READ MORE? DOWNLOAD THE CASE STUDY NOW!

download

Share:

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.

subscribe

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.

subscribe

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?”

Share: