Agile Coaching

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).

Gold Cards and Viking Helmet

You may have spotted that a Viking Helmet has become a symbol of developers at Unruly appearing on our flyers at recruitment events and in our selfie video for Silicon Milkroundabout. I thought I’d share some background as this helmet represents something that is very precious to our teams, protected time for personal learning and research for every developer.

At Unruly, every developer has the option to take one Gold Card day per week. Gold card days are spent working on learning and researching new ideas. Developers often pick something to work on that is directly relevant to work, such as new technology that we want to try out but it can be anything.

As anyone who’s experienced the intensity of pair programming knows, it’s nice to get a break and do some coding on your own but developers sometimes do pair up across teams too.

To illustrate what kinds of things developers choose to work on, last weeks Gold Card topics included: 

• Selenium grid for iPhone/Android testing,
• building a Grunt mini-plugin to help workflow around spikes,
• Gulp,
• using D3 for creating an interactive graphic to show tracking events,
• studying mathematical foundations of type systems,
• writing a custom type and provider in Puppet,
• reimplementing targeting code in Vert.x,
• trying out Robolectric for Android testing,
• investigating big memory, learning Cassandra,
• refactoring persistent queues,
• Ice monitoring tool from Netflix OSS.

I appreciate that our practice sounds inspired by Google’s 20% time but Gold Cards were inherited from XP practices used at Connextra (presented as an experience report at XP Universe 2001). As a member of this team, I still remember the excitement in the team when our Gold Card scheme was announced by John Nolan our CTO (see photo) to the tune of “Gold” by Spandau Ballet.

Although I already did a write up of Gold Cards in “Agile Coaching” book, I thought it was worth another blog post now that I have seen teams at Unruly following this practice for such a long time -- it's a great benefit and part of the magic formula that helps us keep moving our architecture and products forward.

I haven’t worked at Google so I don’t know the ins and outs of how it’s actually implemented but I have heard that it’s often not taken during regular work hours. Please comment on this blog if you have some better information to share. At Unruly, there are ocassional times of hectic busyness when team members decide not to take Gold Cards but if this happens it usually comes up in team retrospective and balance is restored.

Unruly’s practice of Gold cards is different than “20% time” because it’s embedded in our team practice; we cover gold cards in daily standup and track who’s taken them on our team board along with time spent on support.

We also have Gold Card time at the end of the week, where we gather in the dev area with beer and popcorn to share what we worked on with the team. We use a viking hat as our talking token and it’s a good time for us to connect with developers in other teams.

Evolving Extreme Programming Practice

At Unruly, I work with developers who use XP practices every day, it's the way we work and not a novelty. When you've spent years honing your TDD and Refactoring skills, you want to talk about other more advanced topics. Programming languages evolve and new frameworks emerge but meetups that are focussed on a language community often don't make concerns around TDD a core theme.

Our team are generalists and each developer works across the full stack front-end through to databases. We already run in-house lightning talks for developers who work here and in our co-working Hive space. So we came up with the idea of hosting a new meetup specifically for programmers who are already using XP practices and have interesting experiences or insights to share.

To whet your appetite, here are some topics that our developers have given internal tech talks on in the last year:

• Intern versus Dalek
• load testing with Gatling
• ClojureScript
• Postgres foreign data wrappers
• Dynamically tracing java applications with BTtrace
• Types vs Tests
• Promises and Futures
• Vert.x
• AOP in Guice
• Cage Fight: Puppet vs Salt Stack
• MongoDB aggregation framework
• ElasticSearch
• Riak
• Cascalog
• Java 8 lambdas
• R and GGPlot

We've got a great space at Unruly Media in our Clubhouse (see pic) and as we're located just off Brick Lane we thought it might be nice to provide some spicy snacks! We're not attempting to compete with existing meetups like Extreme Tuesday Club or London Software Craftsmanship. So we'll be meeting up once a month on Monday evening (to avoid clashes) starting on 24th Feb. 

Join us to explore how extreme programming is evolving and ideas relevant to software craft looking beyond basic old-school XP/Agile practices (TDD, CI/CD, Refactoring, Pairing). We've included some basic questions before we aprove membership to help ensure that members have some relevant development experience. Hope to see you at Extreme Programmers London soon!

Taking an Iterative Approach to Meandering

Getting out into the fresh air and walking through muddy fields and woods is great way to balance out my daily commute to London. I go out most weekends with a local walking group who take turns to lead walks in the nearby counties: Warwickshire, Leicestershire, Oxfordshire, Northamptonshire and futher afield into Derbyshire Dales, Cotswolds, Malvern and Chiltern hills. We set off early and stay out all day covering 15 miles or so at a moderate pace.

Over the last couple of years, I’ve realised how much I enjoy being outside and seeing plants coming into bud and flowering. I love trees in all seasons and have many photos of them reaching their branches to the sky.

Walking over the fields we see how farmland changes through the seasons; ploughed fields spring green shoots that by the summer are waist or even shoulder high and then cut back at harvest time. We also see plenty of English postcard scenes - quaint cottages, church yards, cricket pitches, country pubs and tea rooms.

All you need to start walking is a stout pair of boots, some waterproofs to fend off the british rain and a small day rucksack. In winter you can add more items to your kit to make walking on chilly days more comfortable - fleece, under layers, thermos flask, walking socks, etc. But walkers are often over prepared, I still haven’t invested in gaiters or poles but do like my banana carrier which comes in handy for elevenses!

I’ve lead a couple of walks now and found that planning them is an iterative process. You need enough basic map reading skills to figure out a roughly circluar route then you are expected to do at least one "recce" (reconnaissance) to check out the route in advance of dragging along the rest of the group. So each walk is developed iteratively.

What's interesting is that you really need to think things through to create an optimal walking experience. Walkers enjoy the walk more when it covers a variety of terrain, interesting landmarks, and panoramic views. Once you have a basic route, you start elaborating on it to weave in some intentional detours to take in the best of the available sights. There’s also a bunch of practical details to work out, such as where the group can park their cars, where to stop for breaks and how to avoid the worst of the mud!

You also have to be prepared to improvise, as I found out on my first walk which followed a night of extremely heavy rain. As you can see from the photo (below), the path I'd originally chosen would've required more swimming than walking!

Luckily, in the previous couple of trips I'd made to recce the walk, I had some idea about the lay of the land and what other paths were closeby. We turned back and climbed up onto a disused railway line, which was raised above the flooded fields, until we reached higher ground where we could connect with the original route. Everyone was able to have an enjoyable ramble in wintery sunshine.

I learned that rambling is all about being prepared to meander. What makes this possible is getting to know the wider terrain around your planned route so you have a more options available when blockers arise. Perhaps the same applies to software..

Taking time to noodle around and research alternatives for each feature request can help us figure out an optimal solution for our customers. When we look into alternative routes, we gain more confidence that we can deliver an appropriate solution without running into any dead-ends. We’re also in a better position to elaborate on the original request and even come up with a better course to take that has more side-benefits.