Agile Coaching

I've moved my blog over to http://rachelcdavies.github.io/

Beyond Coding

Software development on anything more than a pet projects is a collaborative activity. To enable a group of developers to make any headway, some details inevitably need to be hammered out together. However, you probably find that getting agreement within a group of opinionated developers can be difficult at the best of times. Most software developers haven't had training in "soft skills" and you may find it hard to know where to start when a difficult question needs to be thrashed out.

Here are some pointers to areas that you might want to explore beyond the realm of programming languages, methods and frameworks.

Facilitation is all about making conversations easier but even with a clear meeting purpose and agenda, you may find meetings can go around in circles without reaching consensus. To understand some approaches to making group decisions I recommend "Facilitator's Guide to Participatory Decision-Making" which introduces decision making rules. You can also get affordable hands-on training in facilitation from non-profit ICA-UK on Group Facilitation Methods.

Another thing you can do to help meeting participants is to create visible agendas and capture points being discussed concisely. If you want to build more confidence with writing neatly on flipcharts and whiteboards, seek out a course in graphic facilitation where you can pick up tips and practice with other budding facilitators. To improve how you illustrate system dynamics in group discussions, start to practice drawing Diagrams of Effects. Peter Senge's book "The Fifth Discipline" has a an excellent introduction to Systems Thinking and an handy set of system archetypes that you can use in different situations.

There's an old joke: What is the difference between a Methodologist and a Terrorist? You can negotiate with a terrorist! When discussions get heated, it's  handy to know a little bit about negotiation techniques. The Harvard Negotiation Project have put out a few paperbacks and I recommend "Getting Past No: Negotiating With Difficult People" by Fisher and Ury. Another easy read around building trust is "The Trusted Advisor" by Maister, Green and Galford.

Lastly remember that we can improve communication in our teams by starting with ourselves and how we express our own opinions. A good place to start is "Nonviolent Communication" by Marshall Rosenberg. An older book that's worth getting hold of to get a different perspective on the way you share feedback is "The Art of Giving Feedback" by Charles Seashore and Gerald Weinberg.

I hope these resources help you in situations where you need to go outside your comfort zone. Please do let me know if you have other recommended reading to share that goes beyond coding.

Workplace Design: Creating a Home from Home

Last week one of our stakeholders brought his pug dog, Lola, along to our product review meeting. “Watch out, she likes feet!” he joked but she remained quiet and well behaved throughout the meeting. Unruly is not the only place I’ve come across where dogs have been accommodated at work, another had a dog basket in their main board room. I appreciate not everyone likes dogs around but I like working for a company that’s not too stuffy to allow people flexibility to make our workplace more homely.

We’re lucky at Unruly to have a dedicated People & Places team who work closely with our Design team create a work environment that has personal touches. There are many informal meeting places around the building to make collaboration easy and it’s decorated with original artwork reflecting our culture. Little things amaze visitors as we show them around, for instance we created a two-way webcam portal between our London and New York office with a gold antique-style frame, which makes it seem more special and echoes Harry Potter where characters move around. What’s the business case? Creating an environment that allows human expression encourages creativity to flourish in our work.

The design of our workspace is not owned by a central team outside development. We recently reorganised our desks and unlike many companies, where a "Desk Move" is a dreaded logistical nightmare involving packing things up for another team to execute overnight, our developers simply got stuck into disassembling desks and lifting floor tiles themselves to get everything in the right place. Our spirit of collective ownership and taking responsibility for how our code structured seems to extend out to our surroundings. Taking care of our workspace, isn’t somebody else’s job.

Our teams use our walls and whiteboards for practical purposes but with a sense of humour too. Even electronic tools get a bit of customisation, we use Trello for our backlogs and teams can add distinctive backgrounds to make them easier to pick out.

Teams in bigger companies often find that their boards are the easiest areas to start personalising, when you introduce Kanban boards you can involve everyone on the team in designing the layout. Rather than diving straight in to moving things around, you can create a mini-version of the new layout with sticky notes. I think it’s important to give everyone on the team the opportunity to mull the proposed design over and allow time for tweaks. We’ve taken this approach with how we lay out our boards and our desks (as in the examples below).

I appreciate that many people work in organisations that don’t actively support personalisation of the workspace but you can start small with a potted plant, a team mascot, a little whiteboard artwork. You'll likely find personal touches are noticed and soon start to spread around surrounding teams. Another small step that you can take is to adopt iteration names or pictures that pick up on what’s going on in the outside world or reflect metaphorically on current mood within the team. In software development, we spend a lot of time in an office environment, taking care of your surroundings helps to take care of the people working within them.

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!

Good Enough Software Design? Try Testing DX of your Code

Every day writing code we make many design decisions about naming and encapsulation of functionality. Our primary concern is to express our code in a way that can easily be understood at a later date so changes can be made cleanly. To this end, we've learned to organise our code into smaller elements that can be composed neatly to support system behaviours, as where code gets complicated misunderstandings can happen.

When trying to figure out code quality, developers normally lean on software to analyse code complexity and test coverage. Perhaps we might learn more about how good our design is by starting to apply techniques from UX to measure DX (Developer eXperience)?

Developers are primary users of our software design, often working across a vast and complex codebase that's difficult to navigate around. Sometimes our code terrain is too crowded with repurposed junk and other times it's hard to see the wood for the trees with no easy landmarks to navigate by. We could start to measure how easy the code is for developers to navigate. How long does it take a developer to pinpoint the location of code to change? How many places do they look before finding the relevant areas to change? etc.

My interest in DX was rekindled by a recent discussion at SoCraTes on “What is good software design?”.  I sighed inwardly when the topic was chosen by the crowd and if I hadn't been on facilitator duty, I'd probably have skipped the discussion entirely. How wrong I was! I’ll try to sum up the highlights and link to some earlier thoughts I had on topic of DX following a talk at London's Design Museum on the usability of Underground maps.

 

 

 

 

 

 

 

 We ran this evening discussion as a Fish Bowl — you can only comment on the discussion topic, if you are in the 'bowl' — 4 chairs at the front. One chair is always kept empty, to allow anyone in the room to jump in with a question or share some relevant information. The "fish" in this photo are: Chris Jeffery, Mashooq Badar, Steve Hayes but many people jumped in and out of our conversation. Here are some of the points that I found most interesting:

Design is how we layout the code to make it easy to maintain. It may appear that there’s no external impact of software design and it's pretty intangibe how we evaluate one design over another. However, there are measurable external affects on staff retention, ease of change and developer mood. Corey Haines has been working on Mercury App, a tool which can be used by a developer to track their mood over time.

Steve Tooke mentioned Sandi Metz's TRUE criteria for design judgement

• Transparent
• Reasonable
• Usable
• Exemplary

We talked about designing for use and as developers are primary users of our code perhaps we should think more about the developers who come after us. Brian Marick has summarised good code as that which brings joy to those who come after (users and programmers). Maybe we can aspire to bring joy to developers who read our code months or years after we write it! We could apply techniques from UX practitioners to start measuring accessibility and navigability of our codebases. We could use our findings to identify worst pain points, bringing focus to our cleanup attempts and measure whether working conditions have improved through user testing. Dmitry urged us to "Track everything that developers do!"

And Anna Jayne added via #SoCraTesUK twitter stream that we already sort of do in WTFs per min!

All this reminded me that I had some similar thoughts about measuring DX last year. My fascination for maps took me to London’s Design Museum to hear a talk by cognitive psychologist, Maxwell Roberts, who has been measuring the effectiveness of different layouts of underground maps. I thought the same approach might be used to assess the accessibility of different software designs/architectures, sort of UX from a programmer perspective.

I also heard at SoCraTes that DX of API’s is already being tested see this post from Pamela Fox and Jeremiah Lee has also run some workshops on DX at SXSW and Fluent conf

At the Design Museum, Maxwell talked about "information pollution" and how we want to reduce cognitive load for users in processing what they see in front of them. It also helps if a map doesn't significantly conflict with their mental model of the actual topography of the city. Clearly cognitive load must be a big factor in understanding the software design, as we try to figure out where to insert behaviours into a software system. Although we try to use meaningful names to help make code self-explanatory perhaps when a developer is confronted train wreck of long names in a literal programming style iit actually makes it harder to see the structure than using shorter names. We could test this kind of thing using DX.

Also the comparison of a underground map and city topography (people find London underground map easier when the Thames river is shown) might be similar to the software architecture/metaphor matching to real-world domain.

Maxwell's point was that people often use same design rules without thinking about whether they are the best possible for the problem. He's a proponent of a UX technique - Evidence Based Information Design and has been doing testing of different underground map designs for the same city (octolinear/hexalinear vs curves, etc). He takes objective measures: how long does it take a user to do X? Where X might be station finding or journey planning. He also takes subjective measures: how to users rate the map? which map would they choose?

His findings are interesting. Subjective measures on aesthetics don't correlate with which map is quicker to use. People like designs which seem familiar even though tests show that other designs are quicker to navigate. I thought of how conventional/familiar coding styles put developers at ease even though actual design may be a bad fit for a problem.

His design principles for maps were:

• Simplicity
• Coherence (shape/structure)
• Balance
• Harmony
• Topography alignment
• Reduce supplementaty info

When we create maps we want to map topography and reveal structure but we may need to discard current conventions to do so. We should beware following tradition without theory about why it's being applied to this particular problem. For underground maps, people are too hooked on octolinear style (following early success of London underground map in 1930's) but other styles are better for different city geographies. Perhaps in software development we are too used to OOD conventions to see that this can obscure design.

One of the last points made in our discussion at SoCraTes is one from Christopher Alexander, whose work on architectural patterns inspired many software developers to mine design patterns for software. Apparently Alexander’s advice to the software community at an OOPSLA conference was “Don’t extract the humanity” and perhaps by starting to test DX this could be a start of putting developers to the forefront of evaluating good design practice. Let’s try to write better code for the developer who comes after us by testing developer reactions now.

The Folly of Scaling Agile

I’m jotting down a few notes on Scaling Agile software development as Bucharest Agile group invited me to talk about doing this. I have already warned them that I am very skeptical about attempts to apply agile practices on large endeavours. While preparing for our conversation, I thought it might be helpful for me to blog about the reasons why I’m not a fan of Scaling Agile as this may make our conversation easier to follow and help the group to come up with some questions.

When we apply Agile principles, we strip away process so that software developers can work more collaboratively with business people to identify what is the most valuable thing for them to deliver next. We focus on building working software and releasing as early as we can to help us figure out what to build based on feedback from users. Working this way is much harder when a lot of people are involved!

A bunch of things break down as you scale up. The biggest one is not being able to maintain interpersonal relationships through which rich information flows, these are replaced with weaker lossy forms of communication and misunderstandings about what is the right thing to build next follow.

Typical things that become difficult at scale are access to business people and infrastructure controlled by others outside immediate team. Meetings get long and tedious, we start sending a representative from each team, which introduces more secondhand information, emails and documentation.

When a project is big and is being changed by many hands it becomes much harder to understand the whole, we start to introduce hierarchy with a select few looking at the bigger picture and paying attention to separating concerns to allow different teams to work in parallel. As a result, choice is removed from the team and it can feel in teams that edicts come down from on high through a series of chutes and screens that mask the reasoning behind them.

Often the initial attraction of Agile approaches to a business is to reduce delivery timescales and enable developers to work faster with a lightweight approach. Working in small teams allows individuals to feel more engaged because they have some influence on how things are built. When a lot of people are working in parallel coordination becomes harder. Ideally we need skilled people who have enough experience to work independently without the guide-rails of process.

Yes, I have seen plenty of organisations with large systems being maintained, expanded and extended by multiple teams. When each team has to interface to many others decisions take longer to make. Where a large number of people are working on a complex thing, it takes a lot of effort to keep up with what’s happening other areas and most reduce their focus to the work at hand. Once they reduce their focus and interfaces between teams become walls to hide behind. When myopia is easier then teams tend to make local suboptimal changes rather than considering the whole.

A large body people working on a large body of code often feels crazily chaotic or oppressively bureaucratic to work within. In these conditions developer motivation is often dimmed, people leave taking away valuable knowledge of how the system evolved and why things are. New people who need to learn how things work join and struggle to make sense of it all, the situation gets worse.

There are a few agile practices that can help in scaled up situations - such as having reliable automated builds, decent test coverage and teamwork but these are also painful to maintain with a lot of people involved. I’ve seen many large organisations attempt to apply Agile at scale. It’s hard and although it can bring more humanity to work in-the-small, I’m not sure there is much evidence that it is actually better than traditional ways of organising the work.

I appreciate that there are large systems out in the world that need to be supported and evolved to better meet user and business needs. I remain unconvinced that throwing a lot of people at the problem makes things any faster. I believe deadlines driving this behaviour are defined without realising the impact on the maintainability and quality of existing software. Code is an asset and so is the knowledge that software developers carry - businesses can run into costly mistakes if they ignore their value.

Attempting to scale to go faster is driven business greed and ambition - not a bad thing in the commercial world but it’s like seeing a someone blindfold attempting to run along a cliff edge while juggling priceless antique glass vases. Mistakes at scale are costly!

When it seems that scaling up is the only way to go, challenge yourself to think of a smaller simpler thing to build sooner that gives faster feedback. Try to limit your total Work-In-Progess by reducing the amount of development being done in parallel across the organisation. When a smaller group of people is involved in development, choices about which way to go next can be made more quickly and there's less waiting around. Ultimately, this goes back to Agile Manifesto values - focus on better interactions betweem individuals to produce valuable software sooner -- not on a process to enable lumbering projects at scale.