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.

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.