Review of "Agile Coaching" by PragProg press

Cross-posted from my github pages blog.  Rachel Davies, one of the author’s was kind enough to comment there.

My manager let me borrow his copy of Pragmatic Programmer’s Agile Coaching. I’ve read a good number of Agile process and management books. I’m partial to the Pragmatic Programmer publishers due to their consistently well-written books. I also started using stickies instead of pens/pencils when I read my books. Mainly because they stand out better and allow me to find my notes quicker. The other reason is because I can remove them when I give the book away (which I’ve done a good deal lately. Of course, not with this book since it was my boss’). The stickies I use are these and can be found at most office stores.

Anyways, back to the book. The authors, Rachel Davies and Liz Sedley, do a good job explaining the different ways to start/continue agile coaching. The format of the book, multiple sections relevant to the chapter, Hurdles, and Checklist, worked very well for me. They share their experience, pain points, and give you a list that you can contain in your short-term memory.

I enjoyed reading this book because it made me, once again, focus more on the people aspect of software development and less on the coding. I haven’t focused much on that part because I’ve assumed the people I work with are all professionals. Unfortunately, I’ve forgotten that they are human, too and need to be approached as humans and not machines. I’m still convinced that all software developers are control freaks. Our computer does what we tell it to. If it doesn’t, it is usually our fault.

I highly recommend this book.


Chapter 1 – Starting the Journey

Developing a Coaching attitude

  • Lead by example – follow the agile principles yourself
  • Keep your balance – never take criticism personally
  • Set a realistic pace – patience, change takes time
  • Mind your language – stay professional, of course, but use terms like “our/we/us” instead of “I/you/they”.
  • Learn as you go – most powerful lessons are learned from mistakes, expect to make them

PrOpER cycle

  • Problem: Pick a problem to work on. Watch how the team works. What needs to be improved
  • Options: Consider your options. What could you try that might influence the situation for the better? List at least three options
  • Experiment: Pick one option to try
  • Review: Review the outcome. Did you improve things? Even if things haven’t improved, have you learned something?

Credit the Team

  • Don’t expect to get recognition
  • Supporting Role
  • Success – credit goes to team
  • Failure – commiserate with the team

No Experience

  • Uknown situation – be open about it to the team rather than bluffing.

Chapter 2 – Working with People

Yes, I’m Listening

  • Create space
  • Be open
  • Show interest
  • Affirm

Gradient Scale for building agreement

  • Endorse
  • Agree with reservations
  • Mixed feelings
  • Disagree but go with majority
  • Block

Chapter 3 – Leading Change

Five Whys

  • will usually help you get to the real problem

When Not to Ask Questions

  • Take care not to ask questions when you actually want to give guidance.
  • If you ask a question, you have to accept the answer, even if you disagree, and this makes it harder to give the advice you wanted to give.

Chapter 4 – Building an Agile Team

If people feel really unsafe—for example, if the are scared that they will lose their jobs—you won’t be able to do any Agile coaching.

Not Too Easy, Not Too Hard

  • Foster a culture where is’s OK to experiment to learn more about a problem that the team is trying to solve.
  • Although, developing more than one solution may feel like a waste of time, it can be a quick qay to learn and a cheap way to mitigate the rise of making the wrong decision.

Find a Compelling Goal

  • Once they understand that they don’t need to wait for permission, it can free them to make a start.

Time For Innovation

  • If they don’t get time to explore new technology or experiment with innovative product ideas, teams become demotivated. Make time in iteration plans for them to explore new ideas. This can do wonders for motivation—and for the product.

Teams Aren’t Cross-Functional

  • Some companies organize teams by discipline, such as analysts, designers, testsers, software engineers, and so on, with separate reporting lines. This is a serious blocker to becoming Agile because a fundamental Agile principle is cross-functional teams with different disciplines working together to build the best software.

Chapter 5 – Daily Standup

For the Team by the Team

  • Standup is for them to synchronize their work.
  • It is not held for a project manager or team lead to gather progress from the team or give feedback on their work.
  • Encourage the team to direct their answers toward other team members.

Establising a Team Focus

  • Asking questions in the daily standup could cause members to focus responses to you, avoid this.
  • If response are continually directed at you, deflect them like this: “Please, can you direct your replies to the whole team? The daily standup is for you all to work out what you need to do today, not me”. Worst case: do not attend the daily standup at all
  • Avoid giving praise during the stand-up, again to avoid focus of work and responses on you

Handling Issues

  • Parking lot of issues on the whiteboard

Forget the Formula

  • Don’t let the rules, which are there to help you get started, become a straightjacket once you are more established.
  • Don’t let the stand-ups/scrum lose it’s meaning

Hurdle: Dail Standup Isn’t Wanted

  • …if the whole team objects to the daily standups, you have a more serious problem on your hands. It is possible that they’re struggling to work as a team or that the meetings are being badly run. We suggest you discuss their concerns in the retrospective.

Chapter 6 – Understanding What to Build

Life Cycle of a User Story

  • A story is a placeholder for a conversation and eventual task breakdown.
  • Ron Jefferies summarizes the critical aspects of users stories as the 3Cs
  1. Card
  2. Conversation
  3. Confirmation

Story Templates

  • Purpose is to help team improve their understanding rather than a form to be filled in.

Confirming the Details

  • Another common term for story tests is acceptance criteria

Hurdle: No User-Facing Functionality

  • Still use your story templates and not short ambiguous task names

Chapter 7 – Planning Ahead

Decomposing into Tasks

  • …if the team already has a clear idea of the work, decomposing into tasks may be overkill.

Arriving at an Estimate

  • Use a story card matrix (grouping story cards with similar estimates into columns) to help the team keep their estimates consistent.

Keeping Track

  • Noticed that putting tasks in a tracking tool can lead to micromanagement.
  • Remind the team that stakeholders will be interested in whole user stories being finished rather than tasks because tasks aren’t deliverables.

Hurdle: The Team Is Asked to Overcommit

  • Try to convince the stakeholder or others in charge of the hard date, that all deliverables may not be delivered.

Hurdle: Plan Changes During the Iteration

  • Expect the team to create some additional tasks for a story as their understanding of the problem grows, but watch out if the tasks change a lot—that is a sign that the team didn’t come to grips with what needed to be done in planning.

Hurdle: Planning Doesn’t Make Sense

  • Rather than waste time on planning iterations during times of low resources due to vacation, training, etc, or many bugs, create a prioritized queue of work on the team board.
  • If this happens a lot, then consider moving to a kanban style of development, which doesn’t depend on iteration timeboxes to limit work in progress.

Chapter 8 – Keeping It Visible

Agile Planning Software Won’t Help

  • Adding “agile” software to an already broken process will only hinder communication further

Electronic Boards

  • Electronic tools don’t need to break down to tasks, as their lifespan is only as long as the story is being worked upon.

Chapter 9 – Getting to “Done”

Defining What “Done” Means

  • “Done” means the customer is happy with what has been developed, and all the story tests pass.

Managing Bugs

  • If story test is failing, it needs to get fixed before the story can be considered as “done”
  • Team disgression on other bugs that come up during the iteration

Chapter 10 – Driving Development with Tests

Test-Driven Development

  • …encourages a developer to think about solving one small problem at a time

Unit Test Rules by Michael Feathers, Object Mentor

  • A test is not a unit test if:
  • it talks to the database
  • it communicates across the network
  • it touches the file system
  • it can’t run correctly at the same time as any of your other unit tests, or
  • you have to do special things to your environment (such as editing config files) to run it

Don’t Force Toys on the Team

  • Team rituals spring up naturally
  • Don’t inflict the team with a forced, cute build token

Chapter 11 – Clean Code

Agreeing On a Way Forward

  • possibly use an outside expert, therefore, focusing on the issues and not the personalities

Pair Programming

  • when driving, don’t just type code in silence. Explain what you’re doing and why.

Chapter 12 – Demonstrating Results

Everyone Plays a Part

  • During the demonstration…take notes unobtrusively on index cards rather than writing them up on a whiteboard because this can distract from the demo

Chapter 13 – Driving Change with Retrospective

Looking Back

  • Possibly use a timeline, having each member fill in items with sticky notes, will provide a “clear” picture of past events.
  • Art gallery – have each member draw a picture (metaphor) of what the project/iteration felt like to them.

Mining for Gold

  • Dot voting – choose three most critical topics. Each member gets three votes. Prioritize critical topics based off dot summation.

Designing a Retrospective

  • example of how to break down the time:
  • Review the goal of meeting, and remind the team of the ground rules (5 minutes)
  • Create a timeline (15 minutes)
  • Mine the timeline for insights (15 minutes)
  • Select the topics to focus on (10 minutes)
  • Review the progress on previous actions (5 minutes)
  • Generate ideas for improvements (15 minutes)
  • Action planning (15 minutes)

Prime Directive

  • Ground Rules:
  • no laptops
  • cell phones on silent
  • taking turns to speak
  • Prime Directive: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, give what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
  • prime directive also helps counter fundamental attribution error, which is the human tendency to explain the actions of other people as deliberate choice and downplay the situational fears.

Retrospective Prework

  • email querying attendees to gauge direction

Chapter 14 – Growing You

Ways to Grow What You Know

  • Commit to read one technical book per month
  • Start your own blog
  • Contribute to an open source project
  • Post one a day to a community mailing list
  • Listen to a podcast on your way to work
  • Spare one evening a monh to attend an interest group

Making a Plan

  • Invest in your knowledge
  • Do not expect your employer to pay for you
  • your plans need to achievable, bear in mind your other commitments

Personal Reflections

  • write down your thoughts to help articulate your feelings

Take a Break

  • If you don’t take time to unwind, you will be unable to put events into perspective and context. If you are stressed, everything seems bigger, worse, and more important that it really is
  • Try to get a sense of perspective. What are you stressed about? When you look a year from now, will it still seem important? If not, then is it important enough to worry about now?

Getting Comfortable

  • Agile Coach == thick skin
  • Not everyone likes being challenged and stretched, and they may take it out on you

Be Kind

  • Don’t judge others harshly
  • assume everyone is doing their best and that they do everything for a reason
  • Don’t guess and then judge and gossip — go talk to them, find out about them

About Jason Meridth

Continuously learning software developer trying to not let best be the enemy of better
This entry was posted in agile project management, Books, pragprog. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

Comments are closed.