Agile Coaching

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!

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.

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.