Agile Coaching

No Magic Words

I gave a talk at Agile Coaches Exchange meet up yesterday and someone emailed afterwards saying

"Rachel mentioned about few questions that she  uses during one on one. Those set of questions could help me a lot because I am terrible to start and flow the conversation with my team."

So I thought it might be handy to do a quick write-up of what questions I tend use in individual coaching sessions.  

Well just to be clear, I don’t follow an exact format or set list of questions -- I’ve been coaching for so long that questions seem to come burbling out of my mouth without much premeditation or forethought. Here's what I think I ask but this might actually differ a lot depending on the person or current issues.

Before we head off to our meeting, I check “Is now a good time for you?” and I’m fine to move to another time or skip the meeting. Coaching is always optional. 

Once we sit down, I tend to start with open questions like:

• “How are you doing?”
• “Are things going well at the moment?”
• “Are there any issues you want to discuss?”

This tends to open out topic areas that we kick around -- discussing root causes , trying to see events from other perspectives and identifying possible courses of action.

I also look back in my notebook to see whether we talked about any specific issues at our last meeting:

• “Last time we discussed pair rotation in your team, is that working better now?” or
• “You facilitated a retrospective for the ABC team last week, how do you think that went?”

If they led a meeting, I ask if they’d like any feedback from me.

I might also mention current events such as team or process changes:

• "We have a new developer joining your team next week, have you thought about how she's going to get to know the system?"
• "We've changed the story time meeting format to run it with both teams together, how do you think that's working out?"

If the conversation dries up then we move onto specific areas such as personal development:

• “What research projects/Gold Cards have you been working on lately?”
• “Got any plans to give a lightning talk about that next week?”
• “You mentioned that you were planning to submit for XYZ conference, have you sketched out an abstract?”

I usually check at the end “Are there any other things you wanted to discuss?” and let them know that I’m around to discuss further any time.

There are no magic words or special incantations that I’m aware of. The main thing is to focus on what the other person has to say and try to listen carefully to what they’re experiencing and changes they wish for. I care about whether they’re happy at work and hope that talking will help them stop worrying about things that are holding them back and start acting on their concerns and ideas.

Calculating Velocity FAQ

Sometimes people get confused about velocity and edge cases of what gets counted or not. It doesn't matter greatly except it helps to do this consistently over time. I wrote a FAQ for our teams at Unruly because these edge cases come up infrequently and developers often don't remember what rule to apply. I'm sharing a slightly abbreviated version of our Velocity FAQ as an illustration of working agreements around this. Your team might choose to do this differently and that's okay.

The purpose of this FAQ is to clear up any confusion about counting team velocity before story prioritisation.  We average our velocity over past 3 iterations to level things out. Also we make adjustments if we know that team members will be on holiday during the next iteration.

1) Should I partially count a story if we did some work on it but it hasn’t been finished? No

2) Should I count a story if the code is all live but we haven’t had the story approved by stakeholders or sent out the release email? No because sometimes more work is discovered through doing this.

3) If we extended or shortened the iteration should I adjust the velocity to match the usual iteration length? Yes. 

4) If the story was signed off and complete and then later we discover it has problems, Should we add another story for the extra work to fix it? No. If the implementation has a bug or we broke or clearly failed to deliver on the story we will fix it without an additional story, even if it was accidentally signed off.

5) My stakeholder says that she really wanted something extra than the story we’ve developed. Do we expand the story to do the extra things? No, this can be a new story if wasn’t agreed with other stakeholders. It helps to note the acceptance criteria clearly in the story and check them with stakeholders before starting work on development.

6) We had to do some story work in an iteration that wasn't planned in because the story was not finished from a previous iteration (due to any reason including dependency on other team). What do we do?

Step 1: Send stakeholder email or let them know in planning that this is happening and may impact stories currently lined up for current iteration.

Step 2: Fix the problem and then count the full estimate of the original story when its finished in the current iteration

Do not create an extra story for the remainder of the work and estimate it as extra work as this will result in artificially inflating the velocity.

7) We did an extra piece of work it took about 2 points worth, it was never planned in or estimated can I count it now because we did do it?

No. New pieces of work even if they come up mid-iteration, even if they are ultra urgent and should be done immediately should always be discussed, broken down and estimated BEFORE we start work on it. We need to warn stakeholders we are putting it in. So this situation should never ever arise that you only estimate a story after you completed it! If it does happen you should not count it. and discuss what went wrong in the process.

 

Estimates Considered Useful

Despite the current #NoEstimates trend, at Unruly we still estimate our user stories. The way we do this is in small informal meetings in our development area. Why do we find this useful? Because estimates of development costs inform decisions on what to develop next.

At Unruly our teams are all working on multiple product streams. We don’t have long-term project or release plans. We deploy features as soon as we can rather than to hit a release date. We agree the next set of priorities with our product stakeholders every few weeks. The team makes a proposal of what seem to be the most valuable stories to work on next and we also offer our stakeholders a list of alternative options as estimated stories. There’s a bit of shuffling in the meeting, which typically takes less that 30 mins. We are not making a commitment to deliver exactly those stories as something more important may come up.

As we whittle down our proposed list of best value stories in the lead-up to story prioritisation with stakeholders, developers make two kinds of estimate. A rough “ballpark” given by a lone developer is used to figure out whether to bin the idea or do further investigation. A “full estimate” is given by the team when the developer investigating that story has gathered enough information to bring a proposal to the team. We only put full estimates on stories that are strong contenders to present to stakeholders for next iteration.

I wonder if #NoEstimates approach is effective when there’s no significant value tradeoff being made around strands of work (sets of small user stories) and that we find estimates useful because we’re looking for the most valuable stories each time and development cost is a part of that. I think it’s because we’re in a #NoProjects context that we find estimates useful, I’d be interested to hear your thoughts on this.

No Sprint Demo Needed

Over the years I’ve done lots of work with Scrum teams and I appreciate that Sprint Demo/Review meetings can be a useful way to give stakeholders visibility of features implemented prior to pushing out a product release. Teams that find this way of working helpful typically work in larger organisations, where they don't have the capacity to make frequent software releases due to restricted access to servers or a heavy reliance on manual regression testing. However, the ceremony of Sprint Review may be propping this system up allowing teams to work in a pseudo-Agile way placating stakeholders while delaying the release of valuable software.

Nowadays I work at Unruly with XP teams who don’t hold such demos because we practice continuous deployment. Code is deployed to live environment at the earliest opportunity and often in use within our business a couple of days after planning. Where we don’t want all of our users see new features, we can put in a toggle to restrict visibility. When features are already live, the ceremony of getting together in a meeting room with stakeholders is pretty pointless. Although we do ensure that stories are signed-off by business people, often a single story owner who we’ve been working closely with during development. 

How do our wider stakeholder group (Sales, Marketing teams, etc) know what product features are currently released and find out details of how they can be used? As each story finished, developers send a release email out to internal users and organise education sessions for whoever needs to know how the new feature works. We also took some inspiration from Joe Walnes’ Testing on the Toilet and Aimy (our product manager in New York) creates newsletter-style posters for our company washrooms to illustrate and explain new features now available. We have even tried Release-Email Driven Development for a few stories, where we write the release email before starting development to ensure we've thought things through from a user perspective.

The only situation we might consider holding Scrum style demo meetings is when we are working on a totally new unlaunched product. But even then, our practice has been to make a live version available to a restricted group of internal stakeholders so they can access the product and play around with it themselves. Last year, for our Unruly Analytics product we even integrated wireframes and sketches (see pics below) into the evolving product as placeholders for screens that had not been implemented yet to provide some context for the live features.

 

 

 

Dot Counting

Here’s a very simple tracking mechanism for physical story cards that your team can use to learn more about the proportion of time you spend on different types of work. One of our product development teams at Unruly has used this approach for tracking time spent on things for at the last year and a half. As a team, we don’t typically do any deep analysis of the data gathered but it does help us understand what’s going on when our velocity dips. This data also helped the team push back on minor support requests over new features when this became an issue

Here's how it works. We use coloured cards to represent different types of work:-

• White cards are used for stakeholder facing stories. Blue half-cards are sub-tasks for stories and don’t get counted separately
• Green cards are technical tasks such as upgrades of infrastructure
• Red cards are support tasks such as bug fixes and data requests
• Gold cards are developer research. Although we don’t represent these using physical cards, instead we put them on our team calendar so that we know which day they’re planned for. We also use this team calendar to track the time spent in meetings.

The different colour cards have swim lanes on our team board and get prioritised in different meetings. Stories are prioritised by stakeholders every week. Red and green cards are prioritised by the team on a weekly basis.

At standup time, we apply a dot to the cards on the board based on how many developer days were spent on them the previous day. One dot represents a single developer day so cards that were paired on get two dots per day, etc. Then on Friday, someone from the team crosses out the dots on the cards and sticks the data into a shared spreadsheet. From this information, we can see that we rarely spend more that 50% implementing user stories and that we have spikes in green and red when there are outages. It’s also good to see whether we’re ensuring the developers are making time for their research.

Note, I don't think we've tried plotting velocity over this data but perhaps it might be interesting to do that some time.

Who counts the dots? We take turns to do this at the end of the week guided by our dot counting rota and checklist.

You don’t need any special stationery to get started because you can draw dots with a marker pen. We additionally use a date stamp to mark when story cards get started and finished. We also have a record card box to put completed stories into.

I guess to Kanban folk this might sound like we have no defined classes of service and corresponding limits. We find that pair programming and small team size puts enough of a limit on these for us. In a team with 3 developers we can only run one pair per day on features/stories and then the person who's not pairing figures out whether to dedicate the day to research or a mixture of green/red cards.

Future Topics for Extreme Programmers Meetup

We had a good turnout for our first Extreme Programmers London meetup hosted at Unruly and gathered plenty of ideas for future sessions. 

 

Here's some of the suggestions of topcs came out of group discussion:

• Hiring process
• Experience reports where XP hard to apply
• Pairing with unpairables
• How to accelerate feedback loops
• Internal knowledge share in XP teams
• Quality / Productivity
• Global, distributed teams
• User stories
• Techniques to make Continuous Deployment easier
• Helping product understand technical debt and avoiding it
• Teaching advancing TDD
• XP 101: discuss each practice - still relevant? successes?
• Test driving the hard bits eg, security, resilience
• Object callesthenics
• Show 'n' tell - learnings from retrospectives
• Interconnectedness of things
• Things we used to do in XP
• Modern XP for concurrent f() world
• Embrace Change vs sticking to trad XP

We are probably going to vary the format from month to month with shorter presentation and longer discussion slots. Next time we'll have 2 short talks plus a Fishbowl Book club session on Extreme Programming Explained, first edition (the white book).