• Coaching/Facilitation
• Consulting/Giving advice
• Mentoring/Guiding
• Training/Teaching

Some Examples

I once worked with a product owner who’s team hadn’t quite jelled. Four days before the sprint end it was apparent the sprint goal would be missed and he asked me if he should abort the sprint and start a new sprint. We talked about about the options and I asked, “What would you like to have happen for the team?” He stated he wanted the team to learn from the experience. Since we both wanted the team to learn I asked the follow on question, “Do you think they will learn more by aborting the sprint, or facing the unfinished stories at the sprint end?” We continued the conversation until the product owner decided to let the sprint continue and see how the team handled the retrospective. (Coaching/Facilitation)

“What’s the best way to keep track of impediments I’ve resolved?” asked a new ScrumMaster. “Hmmm. And why would you want to do that?” “Well” he continued, “I’d like to make sure the team knows I’ve completed the effort, and look to see if there are patterns in the impediments that get mentioned.” We discussed several different possibilities and then I asked, “What is the simplest thing that could work?” “As a PMP, I’m used to keeping track of risk summaries in a spreadsheet. I could use a spreadsheet with four columns showing the impediment, when it was mentioned, when it was resolved, and how it was resolved.” “Seems reasonable to me. Why not start there, and see how it works?” (Consulting/Giving advice)

“We can develop faster if we split the QA functions into a different sprint.” the team’s alpha developer asserted. “Is that so?” I asked. He assured me it was, so we, the ScrumMaster, he and I headed into a room where we started filling the white board with sprints, code and defects. After an hour or so making sure I understood his ideas, and then extending his example, always asking “And what happens to the defects we find here?” I finally asked, “And when can you declare the code is ‘done, done, done’?” The conversation shifted to Chinese and 30 minutes later I was informed “We’ll rotate different developers to help the QA people write their automated tests.” (Mentoring/Guiding)

“Tell me more about how you pair program.” I asked. “The pair works on the same task. One writes the test and the other writes the code. We’re doing TDD.” came back to me. “And they do this from a single keyboard?” “Oh no, each developer has his own machine where he works.” I heard. This may be some sort of co-development, but it doesn’t fit with my experience of TDD (write the failing test, then the code to make it pass) or of pair programming (two developers, one keyboard). Thus started a conversation about how teams use TDD and XP to create high quality code. (Training/Teaching)

Up and Down the Org Chart

Agile coaches work at many levels. They work with individuals, teams, and others in the software development and business functions. Some coaches tend towards technical skills. Others focus more on organizational change issues and collaborative skills. I’ve learned much about being effective at these different levels and skills over the years at the AYE Conference.

Why Would You Want an Agile Coach?

My colleague Esther Derby listed Five Reasons to Hire a Coach for Agile Teams. You should go read it. I’ll wait …

I’d like to offer three reasons in addition to Esther’s.

1. Experience – Agile coaches have been through the change process before. If you don’t think moving to an agile development method involves change don’t worry, you will know it does soon enough. The Satir Change Model graphic at the bottom of Change and Stable Systems shows how people react to change. Having someone who’s “Been there, done that” has a calming effect.
2. Energy – As Esther pointed out, you’ve got a ton of other stuff you need to be doing anyway. Having an experienced person who can coach, consult, mentor and teach reduces wear and tear on you. It also shows the team that management is serious about making the change work.
3. Enthusiasm – The agile coaches with whom I associate enjoy working with development teams and organizations that want to become more effective. We can’t imagine wanting to do anything else. To that end we’re always working on improving our skills becoming more effective helping you become more effective.

These three reasons, experience, energy and enthusiasm combine to reduce the amount of time it takes for your organization and teams to become more effective, there by increasing financial returns sooner. So with sufficient good coaching, you create a increase revenue stream and create continuous improvement, for just a one time payment.

Have other ideas on why to use an agile coach? Drop me an email.

RULE II: START WHERE THE SYSTEM IS¹

Nate smiled and wistfully said: “Well, I’m the project manager and ScrumMaster. John will be the Product Owner. He works in our North East office. He should be able to represent the user community. He used to work in it. The tech lead and development team work in Europe.” Pausing he continued, “From what I’ve read, the Pundits suggest we’re doing almost everything wrong. But it’s the reality I’m forced to deal with.”

“So Nate, what do you know about the Agile Manifesto?” I asked. “Oh, the ‘We value Individuals and interactions over processes and tools’ stuff?” Nate replied. “Absolutely, but have you ever clicked on the twelve principals link? No? Let’s take a look at them and see what might apply and help you with your project.”

Like me, the clients I work with want to improve their effectiveness. When I visit clients I’m aware that with respect to their system, I’m both spatially and temporally blind.² I don’t know what has happened with the people and organization prior to my arrival (temporal blindness). The information I do gather usually represents at most a handful of viewpoints on what’s happening (spatial blindness).

Is a radical new start, a revolution the best way to achieve effectiveness? Or would changing just a little now, some more soon, evolving toward the final goal be a better approach? The best answer I have today is, “It all depends.” Nate works in a multinational conglomerate. Revolution will be stomped out faster than the speed of light. But evolution, starting where they are, inspecting and adapting has a chance to work.

We spent the next day and a half working through the twelve principles and how Nate could implement them in his project.

• We started reworking the software architecture list into user stories.
• We talked about Done, Done, Done. We reviewed the various types of testing and how/when to do them.
• Nate planned to have two week sprints. In addition to this, he’s now planning to have an automatic push to the test environment after every sprint.
• Potential system users will interaction with the code in the test environment and provide feedback to the product owner.
• We discussed metrics for the sprints and how he could use velocity to gauge project progress for the releases.
• How to conduct the five Scrum ceremonies.

In the end, the major hurdle remains the team’s distributed nature. Otherwise, Nate’s project embraces the agile principles.

As I was leaving Nate said, “Yes, I know it’s not ideal agile. But it’s where we are. In time, we hope to build on our successes and eventually change how IT projects get identified, defined and funded.”

The flame flickers and light shines.

What’s your experience? Revolution or evolution? Send me an email.

¹Herbert Shepard, Rules of Thumb for Change Agents, 1974 http://www.nickheap.co.uk/articles.asp?art_id=257

My colleague Esther Derby and I will be conducting two one day workshops on Effective Agile Retrospectives. If you want to make the retrospectives you lead more effective, we would enjoy having you participate in the workshop. We’ll be in North Carolina in March.

I recently chatted with a ScrumMaster looking for estimating training for his teams. The teams work on a 4 week sprint cycle. I don’t have all the details, but it seems the teams have problems estimating how much work they’ll get done in a sprint.

The following could be wrong, but in my experience estimating problems result when:

1. The sprint takes an extended work period. It’s more difficult to estimate how much effort fits in 4 weeks compared to estimating how much fits in 2 weeks.
2. Lack of experience estimating. This gets compounded by managers wanting “accurate estimates.”
3. Problems with user stories being too large and / or horizontal functions instead of thin vertical feature slices.

To help teams estimate better:

• Shorten the sprint length. Going from 4 weeks to 2 weeks makes the sprint end easier to keep in focus AND doubles the amount of practice the team gets estimating.
• Remember that an estimate is only that and nothing more. An estimate. And the estimates should get better with time.
• If there are problems with the user stories, work with product owners to write stories that conform to the INVEST pattern.

Do you have a question you’d like to ask? Shoot me an email.

I was flipping through an old work note book and came across the following story.

I spent three days working with a client who had adopted Scrum for project management about six months earlier. On the fourth day I attended a Sprint planning two (user stories to task with time estimates) meeting. As we talked about stories and sizes, George asked the following question. “How do we deal with work that is too big to finish in a sprint?” In all my time coaching teams, I haven’t found a user story so large that it couldn’t be done in a sprint. If there is such a story, it usually an epic that can be further divided into smaller stories.

Wanting to be helpful I said, “Well, split the story into smaller stories.” Mentally allowing that I haven’t seen all the possible user stories in the world (and there /MIGHT/ be one story so large it couldn’t be finished in a sprint, I continued … “If that doesn’t work, pull the work into the sprint and burn down as much as possible. You don’t get velocity points, but if the backlog is properly ordered you’ll have work done for the start of the next sprint.” Hoping to point to some future perfect day where the team was burning down faster than anticipated I added, “It’s just like when the sprint burns down faster than estimated. You pick the next story from the Product Backlog and start work on it.”

George replied “We’d never do that. We get graded on how well we complete our stories. If we have unfinished work it counts against us.”

The Fundamental Software Development Process

The fundamental software development process looks like:

This system dynamics drawing² varies somewhat from the Diagram of Effects (aka Causal Loop Diagram) I often use by showing the stocks (levels) and flows (rates) associated with the development process. User stories flow into the Product Backlog. The team converts the user stories into Implemented Features at some rate (Velocity). By and large it’s how everyone develops software. Steps may have different names and take more time to complete (or not) but we take what user’s want and give them software that performs those actions.

An important aspect of the Fundamental Software Development Process involves recognizing it’s an open loop system and open loop systems are inherently stable. User stories come in as they will and become part of the Product Backlog. The team works at some natural development speed based on their abilities, the story complexity, and their intrinsic motivation. The Implemented Features accumulate and eventually the software gets released to the users. Based on the Product Backlog size (in story points) and the team’s velocity (in story points) it’s possible to calculate when the next releasable set of Implemented Features will be ready to go to the users.

But what if that date isn’t soon enough?

Add Some Feedback

The conversation with George happened my last day on site and I had meetings stacked the rest of the day. But on the flight home I started wondering, “Why would someone want to ‘grade’ the teams on how well they completed the stories?” One answer is to build confidence in team’s velocity value. Another possible explanation would be a behavioral assumption that the developers tend to avoid work and a way to make sure the developers don’t shirk is to compare the sprint results with the estimates made during the sprint planning.

Whatever the reason for “grading” the sprints, the action of “grading” has created a feedback loop in the system. Adding feedback means taking a system output and sending that output (or some portion there of) back into the system input. I wrote about feedback control loops in Multi-Use Model. Feedback loops provide the opportunity for control, aiming the system at some new target such as a new delivery date. Unfortunately feedback also provokes instability in the system. Unless great care is taken, the system becomes dysfunctional at best and destructive at worst. The Fundamental Development Process now looks like:

The “split” rectangle means management has a choice at this point. They can choose to “grade” sprint results or not. If the grading happens, the rest of the reinforcing loop happens. In a nutshell:

• Team members want to look good. I don’t know if “counts against us” includes performance evaluation, but it could.
• Since the team wants to look good, they’re not likely to take risks. Not taking risks could mean:
  1. Not bringing additional work if they finish early.
  2. Inflating story points for user stories during estimating sessions.
• Since the team won’t take risks, measured velocity won’t decrease (and indeed may increase) while actual velocity (the rate of delivering implemented features) may decrease. As Robert Austin notes:

Boomerang Measurement

I confess I’m doing a certain amount of mind reading now since I didn’t have a chance to talk with the person who decided grading the sprint results would be a “good thing”. But I can’t wrap my mind around the concept that they explicitly set out to slow the development process. But they did, we have another boomerang measurement.

Truth be told, I believe the person thought they were (are?) doing the best possible actions to help the developers be more efficient. I’m serious. You can’t make up stuff like this.

For more information on how management goes astray with measurements I recommend reading Measuring and Managing Performance in Organizations by Robert Austin and Slack, Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom DeMarco.

Got an example of a boomerang measurement? Drop me a note.

¹I first heard this line from Jerry (Gerald M.) Weinberg
²http://en.wikipedia.org/wiki/System_dynamics
³Measuring and Managing Performance in Organizations Dorset House Publishing, ISBN 0-932633-36-6, page 38

I’m not going to say how long I’ve been around, but I have two copies of The Mythical Man-Month. I have the Anniversary Edition and the 1982 edition of the original 1975 book. I’m not sure why someone on Amazon is trying to sell the 1982 book for $ 129.95. The Anniversary edition contains four chapters not in the original edition including “No Silver Bullet”.

Brooks concludes “No Silver Bullet” with Promising Attacks on Conceptual Essence. His four major points are:

• Buy versus build.
• Requirements refinement and rapid prototyping.
• Incremental development – grow, not build software.
• Great designers.

Here’s what he as to say about these points.

Buy versus build

“The most radical possible solution for constructing software is not to construct it at all.” pg 197.

Requirements refinement and rapid prototyping

“… For the truth is, clients do not know what they want. They usually do not know what questions must be answered … Complex software systems are, moreover, things that act, that move, that work. The dynamics of that action are hard to imagine. So in planning any software activity, it is necessary to allow for an extensive iteration between the client and designer as part of the system definition.” pg 199

Incremental development – grow, not build, software

“The building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be accurately specified in advance and too complex to be built faultlessly, then we must take a radically different approach. … Some years ago Harlan Mills proposed that any software system should be grown by incremental development. … One always has, at ever stage in the process a working system. I find that teams can grow much more complex entities in four months than they can build“. pg 201

Great designers

“The central question of how to improve the software art centers, as it always has, on people. … Great designs come from great designers. Software construction is a creative process. Sound methodology can empower and liberate the creative mind; it cannot enflame or inspire the drudge.” pg 202

Agilista or Not?

I find it interesting that Brooks originally published “No Silver Bullets” in 1986. That he nails the agile techniques of build only what you must, iterative and incremental design and delivery, and focus on people amazes me. In the next chapter “No Silver Bullet” Refired, he reviews many of the more serious comments and in the end concludes: “Net on Bullets – Position Unchanged.” pg 226

Such are the joys of 20/20 hindsight. So what do you think? Agilista? Forward thinker? I’m spending too much time reading meanings into what I’m re-reading? Drop me a note and let me know.

Reading Better People, Better Process may make it seem like I’m one of those touchy-feely “people over process” types. I confess I have a fondness for people but I’m also a big fan of process. Luckily, people and process don’t exist as either/or. People and process exist as both/and. Here’s a process that can both improve your other processes your people, and the process itself.

Another Multiuse Model

This model is another Multiuse Model. This process tells what to do in a retrospective. Retrospectives occur when we stop, think, and decide what to do next. We call a one person event “introspection”. A software development team may have a facilitator for their retrospective. Retrospective permutations abound. Here are the steps for a successful retrospective.

1. Set the stage – get focused
2. Gather data – create a picture of what happened
3. Generate insights – why? And what could be done differently?
4. Decide what to do – what one thing to do, and what is the first step?
5. Close – decide how to document and plan for follow-up.

You can learn more about this process by reading Agile Retrospectives. If you are a person who would like to go from good to great, and/or work in/with teams and/or organizations who you’d like to go from good to great, stop reading now and order the book. I’ll wait.

Back already? Wonderful.

So why do a retrospective? Retrospectives involve the Learning Loop. By continuously learning to improve our process, we can learn to improve ourselves. As we improve ourselves we can improve the retrospective process. A conscientious facilitator does a their own retrospective for every meeting they facilitate. George Dinwiddie and I facilitated a two day product owner release planning meeting. After each day we met to discuss what happened that day, what it might mean for the product owners (and us), what we could do to improve, and what changes we would make for the next meeting.

Hints and Suggestions – Three Possibilities

As a bright shiny new ScrumMaster, my retrospectives always included: “And what one thing would we like to work on to improve during the next sprint?” As I prepared for one retrospective, I thought, “Wow. All I ever do is ask what they’re doing wrong. What would happen if I asked about doing more of something they’re doing good?” Based on the what the Gather Data and Generate insight steps reveal I vary the question to focus on:

• Improve (change) something you’re currently doing. Based on their retrospective, one team decided they were making too many assumptions and needed to get the product owner’s input.
• Do more of something you’re doing well. One team noticed the developers were finishing the sprint in good shape while the testers struggled to complete the manual and automated tests. The team decided to have developers work with the testers earlier in the sprint to increase the teams over all velocity.
• Add something you’re not doing. I worked with one team that decided to schedule a meeting with the product owner mid-sprint to update the product owner with new information and verify the team had the spriint goal still in focus.

For the most variety ask the team to create possibilities for all three categories.

Only One Thing

Choose one change to work on. I’ve observed a some details over the years:

1. Teams generate many possible change items.
2. In a team of equals, some team members are more equal than others. This may be due to experience, longevity, or just plain loudness. I deal with this by giving each team member two votes and then call on team members for their votes making sure not to call on the “more equal” team member first. The item with the most votes gets proposed for the “do this” for the next sprint.
3. Any change can create instability. Too many changes at once will push the system to instability and dilute the change impetus pretty much ensuring nothing really gets changed.

Buy In

The team needs to buy into the decision. I recommend using the team’s norm for group decision. I’ve seen the “Fist of Five”, “Roman Thumbs”, head nodding, and probably a couple I’ve forgotten. The point is to get everyone to agree with the decision. If the whole team doesn’t commit to make the change happen, it probably won’t happen.

Follow-up

Pay attention to the change during the sprint. If I don’t see evidence the team is working on the agreed change, I ask a question at the end of the daily meeting about how the team is doing with the change. During the “gather data” portion of the next retrospective I include a question about how the team feels they did on their change idea. Failing to follow up on the topic teaches the team that constant improvement isn’t important. All you get from then on is grand ideas and lip service.

The Unaimed Arrow Never Misses

If you’re the facilitator, structure the retrospective as neutrally as possible. This is easier said than done if you also serve as the team’s ScrumMaster. It’s critical for the team decide what change they’re going to attempt. Structuring the retrospective or guiding the conversation to your predetermined result will result in less commitment if not out right rejection from the team.

What’s Next?

The basic cycle is do, inspect, adapt. Doing starts the cycle. So do something. Then inspect, adapt, and repeat as necessary.

If you don’t have Agile Retrospectives I’d suggest you start by reading the book.

I’ll be leading a session at this year’s AYE Conference involving Introspection. The conference still has 8 openings.

Why is it so?
Jerry (Gerald M.) Weinberg chose to use Brook’s Law in Quality Software Management: Vol 1. Systems Thinking to demonstrate non-linear feedback systems. Combining Fig 5-1 (page 78) and Fig 6-4 (page 93) gives us:

Brooks' Law

I describe how to read Diagram of Effects here.

In essence adding manpower affects the system by:

1. Creating more communication paths. The number of communication paths is n*(n-1) where n equals the number of team members. This says increasing from 4 to 6 members increases communication paths from 12 to 30.
2. Adding new team members creates a training load on the existing team members. This in turn reduces the productive work finished.

These problems get exacerbated when managers decide to add “extra” manpower just to be sure the project doesn’t slip any more.

Communications and Sharing Information

Tools to support software development methods have changed since Brooks’ Law was introduced. We now have information radiators for sharing information in parallel. By simply walking around your office it’s possible to learn information about the project. Additionally wikis, build systems, source code management are types of information magnets. They hold pertinent information that can be searched, sorted and reviewed.

There’s a sliding window of opportunity where manpower can be added to a project and not negatively impact the schedule. This window closes when the additional productivity achieved by adding more staff isn’t enough to offset the lost production due to training them. According to Israel Gat, BMC Software staffed the two releases with 80-95 developers compared to other companies who staffed similar sized projects with 25-35 developers. This staffing level resulted in product delivery in 4.5 – 5 months instead of over a year. This rapid delivery creates problems for the downstream organizational activities such as marketing, sales, revenue recognition and the back office. BMC Software recognizes this problem and is currently working on synchronizing the activities.

How to Beat Brooks’ Law

The state that invokes Brooks’ Law is “late”. To beat Brooks’ Law all you have to do is avoid having late projects. What are some ways to avoid late projects?

• Staffing – BMC Software avoided late project delivery by aggressively staffing when they started the project.
• Cross functional teams – This keeps the project delivery from being derailed when something happens to a “key” developer.
• Incremental and iterative development – Customers rarely need all the new functionality at once. Delivering the highest value functions sooner relieves the pressure for a “big bang” delivery. The customer can decide to stop the project early if/when their needs get met.
• Fast feedback – This naturally flows from incremental and iterative development. Every two to four weeks the customer provides information on how well the development is doing at meeting the customer’s needs.
• Continuous Improvement – At the end of each delivery cycle, set aside time to learn from the cycle’s activities and events. What went well? What could be improved? Select something from the “What could be improved” list and work on it the next delivery cycle. Be sure to ask at the end, “Did we implement the improvement?” Some things take more than a single delivery cycle to get right.

• diminishing returns. The more improved a process becomes the less room for improvement exists. Eventually the process will be as good as possible.
• over adaptation. The development process becomes highly adapted to the existing system leading to problems when the environment shifts.

I say if you want to improve your process, improve your people. It’s impossible to provide specific advice but try for improvements in three basic areas:

1. What they know. Use seasoned developers to help mentor newer developers. Both learn in the process.
2. What they don’t know. Software development extends beyond the code editor and compiler. Requirements, scheduling, and testing all play a part in the process.
3. How they work with others. With very few exceptions, software development requires a team effort and interfacing with other people in and out of the organization. More effective interactions lead to better software.

The Second Law of Consulting states:
“No matter how it looks at first, it’s always a people problem.”

Inverted the Second Law becomes:
“No matter how it looks at first, people are always the solution.”

So if you want your software better, faster, cheaper, improve your process by improving your people.

The hardware & integration project to produce that client was much-delayed, under pressure, and more than a little out of control. I didn’t need a PM. They already had more “help” doing that the normal way than anyone could stand. What I needed was a kind of “un-PM” to coordinate and focus what the execution team was doing, mostly by filtering out the noise from above and across, and maybe injecting somber reality checks into what we said was happening. I needed someone with perspective on the technologies & manufacturing, a grasp of project execution, and a delicate touch with people. I needed someone honest, fearless and gentle about both without losing the need for real data, for he and I to respond to. Taking the culture and history into account, I needed some magic in “just in time” coaching and OD-on-the-sly, to help these people grow into the jobs they were supposed to be doing, without making too big a deal about it. I needed to help these people loosen up while staying focused on the job at hand.

Don has the gift of retaining the child-like quality of enjoying what he does despite decades’ experience with technology development, and a butt-load of training in OD and human systems. He’s serious where need be, but never solemn. With his other skills and gifts, he was perfect.

Don slid-in, and within a week we were tracking to reality of what was done and he’d cleared the underbrush so we could see what remained all without making anyone’s head explode. The product went beta the day I had predicted a couple months earlier, received all certifications and approvals, and worked as advertised. One of the crustier software engineers said: “It’s the best hardware we’ve ever shipped.”

So, what did Don contribute, beyond his background in hardware development, software development, and projects?

• Gentle leadership.
• Sense of fun.
• Just enough Command & Control which was mostly less in detail than there had been, and more in direction
• As a bonus, Don was able sometimes to explain to the more interested members of the staff what I was doing with the organization and how. That conversation is a complicated one to have when you are the boss, as I was.
• And Don engaged in some just in time coaching and almost mini-workshops on tools and techniques of working well together, general systems in particular.

Don and I have since threatened to offer a workshop on general systems applied to development work. I’ve been the slacker on this. But, if we pull it off one day, it should be a riot. I’d like to do that because the one regret I have about working with Don at Padcom is that I didn’t get to spend as much time with him as I’d have liked to.

Jim Bullock – February, 2007, Seattle Washington