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.

NOTES

—

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