Agile Coaching

Conference Club

"The first rule of Conference Club is to talk about talking at conferences"

Presenting at conferences is a great experience where you get to consolidate your knowledge and connect with other people passionate about the same things. But speaking in front of your peers can be a scary prospect for developers and they often underestimate the value to others of what they know. For instance in our teams, we have lots of experience with XP, Continuous Delivering, UX and JS testing frameworks. Does that mean we're all experts? Not necessarily but we can share practitioner experiences and that's a valuable to people who're only just getting started with new approaches.

Back in January, I started a lunchtime meeting called "Conference Club" for anyone in our team at Unruly who wanted to learn more about the steps they need to take to present at industry conferences. Five months later, I'm pleased to see that several of the people who came along have submitted sessions to calls for participation and been accepted as speakers.

• Alex and Benji presented on "Scaling Continuous Delivery" at Pipeline conference in London
• Vikki presented a comparisonof front-end acceptance testing frameworks at JsDay in Verona
• Arber will be presenting on "Extreme Product Development" at Agile North
• Mike will be presenting on "Zombie Personas" at Agile2014.

We only had a few meetings of Conference Club but it was enough to explore people's worries and share some practical tips on how to get over them.

Basic Steps

1. TOPIC: Identify topics you are interested in and know something about
2. BIO: Update your profile on LinkedIn / GitHub / blog / Twitter to reflect your interest/experience
3. WHERE: Find meetups / conferences that might people go along to discuss that topic which have open space or CFP (call for participation)
4. DATES: When do you need to submit a proposal by, these can be upto 6 months before the conference date
5. FORMAT: consider what format is best fit for you and conference (workshop, talk, experience report, etc)
6. PREPARE: design material slides or exercise to lead session participants through subject of interest.
7. PROPOSE: put forward your idea to organisers
8. PRACTICE: do a run thru of session with small group to work out any glitches

One basic thing that speakers need to do is practice so we have a fortnightly lightning talks forum that can be used to build confidence speaking to an audience. Unconference events are also great places to explore a topic as you figure out what you want to present to a wider audience.

Homework Assignments

1) Write a bio for someone else at the meeting using Scott Berkun's tips on how to write a good bio

2) Prepare an answer to one of the following questions from Noel Rappin's blog 

3) Write an abstract for a new session you'd like to propose for a user group or conference.

Useful Blogs

• Conference speaking HOW-TO
• Confessions of a Semi-Amateur Speaker
• Debricking yourself as a speaker
• Kent Beck on how to write a conference abstract
• Chad Fowler on how to give a keynote
• Podcast on slowing down pace
• Presentation Skills Considered Harmful
• http://speaking.io/
• https://news.ycombinator.com/item?id=7059303
• http://www.linkedin.com/today/post/article/20140107225219-172811-presenters-don-t-go-the-way-of-michael-bay
• http://www.duarte.com/blog/public-speaking-for-introverts-6-essential-tips
• https://www.coursera.org/course/publicspeak 
• Dealing with stage fright
• Presentation Zen summary
• Breathing for voice projection
• How to project your voice
• http://speaking.io/
• Triangle Method for eye contact
• http://www.annashipman.co.uk/jfdi/conference-speaking.html
• http://weareallaweso.me/
• http://rckbt.me/2014/01/conference-proposals/
• http://seb.ly/2014/05/how-to-ask-to-get-paid-to-speak/

 I also recommend following Callback Women to pick up upcoming call for participation.

 

Developer Exchange

Last year Unruly ran a Developer Exchange with 7digital. We're both companies with similar levels of experience in XP/agile development but working in different technology stacks. Our aim was to provide a mutual learning experience and pickup some ideas for improving the way we work by seeing how another company does things.

What we did was to arrange for a developer swap -- Imran a Java developer from our team went over to work at 7digital for a week then Raoul a web developer came over to work with our teams for a week. The swap was staggered so we did not swap Imran and Raoul on the same week. Each developer had the opportunity while they were at the host company to pair with developers on different teams. They were also welcome to attend team meetings such as standups, planning and retrospectives. Imran even facilitated a few of retrospectives at 7digital.

It was helpful for Unruly to swap with 7digital as we were approaching a point where we were about to split a large team that worked on a monolithic application and 7digital had already implemented something similar. I think 7digital were interested to see how we approach our Continous Deployment and approach to product development.

Now that a year has elapsed, we're planning to do another Developer Exchange with 7digital. Unruly is also looking to do this with some other companies, such as Red Gate and Mendeley.

A prerequisite for us is that the exchange partner has developers who already practice XP to enable pairing. It's less important to be using the same technology, our developers are used to working across full stack from front-end to database. We have three teams to pair with and an assortment of languages and frameworks including:- Java, Tomcat, Spring, Play, Javascript, Angular, Node, Grunt, Mocha, Vectorwise, Postgres, Hibernate, Cassandra, Puppet, Cascading, Mockito, DbUnit, Jasmine.

So if your company are already experienced XP practitioners and the idea of a swap sounds interesting to you, please get in touch.

Retrospectives: Appreciations & Commiserations

A common technique for retrospectives is to invite Appreciations from the group, which provides an opportunity to acknowledge individual efforts have not gone unnoticed by their teammates. Appreciations are described by starting with the person's name followed by a short description of what they did which you appreciated. When inviting appreciations, I ask the team to write a post-it note for each team member and list one helpful/useful thing that you personally appreciated.

However, sometimes developers can find it uncomfortable to work in postive-mode as they normally prefer problem solving. I think it makes Appreciations easier when you couple them with surfacing some Commiserations. Where a commiseration is "one thing that a person in the team did that you wish could be avoided". 

Inviting the team to call out commiserations is a practical way to connect heroic efforts with areas for potential improvements. You can then use the commiserations as a stepping stone into identfying areas to discuss how they might be avoided in future.

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.