Agile Coaching

Broadening Developer Horizons

XP is an approach that helps us to deliver valuable software iteratively, to apply it we need to setup our teams to make releasing change to customers as easy as possible. We avoid waiting around for individual team members to make changes, by applying classic XP practices -- Collective Code Ownership and Pair Programming. Each pair of developers is free to change any code that they need to without anyone vetting their changes, they ensure that all tests pass and keep code relatively clean by refactoring as they go. We share knowledge across the team by rotating pairs daily. If a pair runs into difficult decisions regarding design choices, they can call for a huddle with their team mates, sitting together in an open workspace means that's quick to do. This XP way of developing code is liberating as we can easily make changes in the right place rather than working around organisational barriers. It can be also be humbling, as our code is often improved by other developers as they pass through.

To work this way, we find it helps to build teams of extremely capable developers who can work on any area of the codebase rather than hiring a mix of frontend/backend/DBA specialists. Developers who only know enough to work in a single layer of the codebase limit who's available to pair on the piece of work which is most valuable to pick up next. At Unruly, we only hire “full-stack” developers, this gives us confidence that any pair of developers can work on any area of the codebase (within the products that their team is responsible for) without experiencing hand-offs and delays waiting for developers with a different skill set. It also helps avoid some of the friction that can spark due to single-layer thinking.

To make collective code ownership easier, some product teams select a homogeneous stack such as Clojure with ClojureScript or JavaScript all the way down using Node. At Unruly, our developers need to be fluent in JavaScript and Java with a smattering of Scala. Full-stack developers are bright people who can keep pace with developments in multiple languages and frameworks rather than immersing themselves in a single core development language. Being a full-stack developer is more than being able to write code in different languages, you have to understand idioms and patterns for UI, middleware, database realms too.

Being a full-stack developer is also much more than becoming a polyglot programmer. Laurence Gellert’s explains in his blog that there’s a greater breadth of skills that a “full-stack” developer needs. You’ll need to appreciate the environment that your live system runs within and have the technical chops to be at home with making environment changes. You'll also need to broaden your horizons beyond thinking about code and get to grips with developing a fuller understanding of the business you work in! Michael Feathers recently gave a talk in London where he used the term “Full Spectrum Developer” which neatly captures the idea that there's much more than being able to work across different software layers in a given architecture.

As the software craftsmanship movement has brought to the fore, serious developers need to take personal responsibility for improving their skills. Of course, becoming a full-stack developer is more than reading the odd business book in your spare time and writing toy programs in obscure languages when you get home from a long day at work. You can also get together with likeminded developers on a regular basis to hone your skills through Code & Coffee sessions outside work and work on pet projects like building games and mobile apps at home. But in my opinion, this only scratches the surface - you will only get to grips with being a full-spectrum developer by working in an environment that allows you to get your hands dirty across the full stack and interact directly with users and stakeholders. Typically these are startups or small companies that practice agile software development. If you take a look at our current open roles, you’ll see they’re much broader that you’d typically find in a large corporation.

As an agile coach working with product development teams at Unruly, my focus is on how we can support developers to expand their horizons, to gain a better understanding of our business and how they can help figure out the most valuable software to deliver iteratively. Our developers take responsibility for researching different strands of product development and identify the most valuable ideas to take through to implementation (I'll write-up more about how we do this in another post soon).

We also recognise that build learning time into our work week is essential for developers to stay abreast of new tools and frameworks. All of our developers get one day per week to dabble and learn new technologies — see my previous post about Gold Cards. We recognise that industry conferences can be places where you hear about new trends so developers get three days and an annual allowance to spend on attending any conference they feel is relevant to the personal development at work. Our developers also take turns running weekly coding dojos (during work time not through their lunch) to get hands-on practice time with new languages such as Go, Scala, Rust and mobile phone application development. Developers get the opportunity to share what they learned to other teams through lightning talks and this gives them practice in presenting too. All of these things are ways that organizations can support developers in broadening their horizons while at work rather than eating into their early mornings and evenings.

There are a few things for developers to weigh up when considering whether to specialise deeply or broaden their horizons. What do you sacrifice when following one path versus rewards to be gained? The main reward for full-spectrum developers is building greater confidence to dive into different technologies; you may spend less time writing code but become more able to deliver end-to-end solutions that hit the spot. As generalists, you likely have a wider choice of companies to work at and are more resilient to industry trends. As specialists, you gain the pleasure of total immersion in a particular sphere of software while you build tolerance to the frustrations of waiting around for others to do their bit. It's up to you!

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.

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.