Agile coaching

13 Dec 2009 – San Antonio

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

Card
Conversation
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