Agile Coaching

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.

Sprint v Iteration

Chris Oldwood asked me about the difference (as I see it) between the Scrum concept of Sprint and Iteration in XP. Although the terms “Sprint” and “Iteration” are often bandied around as synonyms in Agile world with the basic meaning of a time boxed planning cycle used by a software development team, these terms started out with quite different meanings.

Here’s a quick brain dump of my thoughts on key differences.

The purpose of a Sprint in Scrum is to deliver a product increment - a coherent release not a hotchpotch of unrelated features.

When I learned about old-school Scrum (back in 2002 before Scrum Alliance existed), a Product Owner would work with the team to agree an achievable Sprint goal that the team felt they could commit to delivering in a month. The focus of the team was a achieving a goal defined around what the next product increment would be. The Sprint Backlog was simply a list of tasks defined by the team that would help them achieve that goal. Tasks could be added or removed during the Sprint but the goal remained the same.

Around this time, there was no mention in Scrum about user stories and complexity points, these techniques hadn’t been imported from XP yet. So key concepts in Scrum - a goal for the product, a commitment from the team and a release of a product increment.

Agreeing direction and empowering the team to achieve it removes interruptions during the sprint and allows the team to focus attention on the product under development. Although once a product is released there’s likely to be a stream of defects and support requests to be handled by the team which may slow them down later if they don’t pay attention to quality.

XP is a an approach for small teams developing software in the face of vague or rapidly changing requirements.

Back in the day, a team of developers sat down with their on-site customer to play the Planning Game. User stories were jotted on index cards are laid out on the table to be prioritised by value and risk. To quote Kent Beck "We make the plan quickly so there will be little inertia changing it"

XP does not need and end of iteration ceremony to demonstrate or review an increment because software is released as soon as it is ready. Each story has acceptance tests and is releasable independently of the other stories -- remember Bill Wake’s INVEST.

Teams applying XP are encouraged to “embrace change” to listen to user feedback. There is no sense that an XP iteration is frozen or locked down. It’s possible to make small adjustments to stories as they’re worked on and also to swap user stories in and out of the iteration, if we discover something more valuable to work on. XP teams use Yesterday’s Weather (planning poker and velocity) to help them avoid taking on too much work not to make a commitment.

The funny thing is that neither of these versions of Scrum or XP are commonly practiced nowadays. Perhaps that’s down to the proliferation of Agile training lead by people who haven’t implemented these older approaches and planning tools that place more emphasis on velocity tracking for project management purposes. I see the #noestimates movement as a reaction to the blend of Scrum and XP that bloats the ceremony around planning beyond original ideas.

Software Archaeology, Do You Dig It?

I found the talks at The International Conference Of Software Archaeology interesting and thought provoking. Thanks to Robert Chatley and Duncan McGregor (below) for putting this new conference together and Tim Mackinnon who helped keep things running smoothly on the day.

From wikipedia, Archaeology is “the study of human activity in the past, primarily through the recovery and analysis of the material culture and environmental data that they have left behind, which includes artifacts, architecture, biofacts and cultural landscapes.”

As programmers, it’s natural to use our coding skills to do the digging. We love spotting problems and patterns so trying to see what's been done in the past is pretty facinating. As speakers pointed out, our findings in the code are merely clues to what’s going on outside it. We need to add a lot of context to make sense of it. 

When looking at graphs of various metircs over time I wanted to know more about the organisational structure, locations of people and tooling. Some of the talks correlated source code changes with defects and others with team size and contributors. It might also be handy to know design approaches and modeling techniques that were applied during the lifetime of a codebase, such as TDD and UML. 

Aside from code, there are more potentially rich sources of information that we could dig into that may help understand the culture and environment that code was developed in. Other artefacts that might be interesting:- email, calendars, budget cycles, user feedback logs, support tickets and revised plans. Perhaps these are a little less attractive to explore as they’re more fiddly to analyse with code.

Clearly some of the metrics presented could be used as evidence to support efforts for code improvement. After seeing quite a few visualisations of code over time, I also found myself wondering whether it's that useful to look at shadows of organization in the code. We might get a different perspective from observing and interviewing teams while development is ongoing (ethnography). Although as someone (possibly Nat Pryce) pointed out "Code doesn't lie". 

Snazzy graphs can be useful to grab management attention (as we already have plenty of competing problems to fix such as code that doesn’t work as expected and poor user experience). It's typically difficult to get across to non-technical stakeholders just how complex a codebse is and how messy things have become over time.

As a coach, I’d advocate spending time talking to programmers before crunching the codebase into pictures. Solutions to any problems lie in the world of people - programmers and the businesses that they work in. If we are to improve the code then understanding their current concerns is a useful place to start on improvements. But I would say that wouldn’t I? ;-)

Musings on the Implications of Conway’s Law

At Agile Coach Camp Barcelona, I lead an Open Space discussion around the implications of Conway’s Law. I started the session by stating Conway’s Law as:- "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." More details can be found here. 

We were outside by the pool and it was a little breezy so we taped a single sheet of paper to the easel, I then attempted to squeeze in all of our notes on it. Looking at the photo of those notes (below) it looks like a jumble of words! Here’s an attempt to unpack some of our discussion, I hope anyone who was there will add their own comments to this post.

 

Conway's Law appears an obvious conclusion for anyone to make in organizations where a team is responsible for (and in many cases is named) after a technology layer or component of the system. You’ve probably also worked with organizations where teams are organized around skills with front-end, server-side, and database teams. These organizations often also split out specialist functions such as QA and Support from development and teams are considered resource pools for multiple ongoing projects. When teams and system are organized in this way it’s pretty typical for those teams to try to resolve problems in the area/layer which is easiest for them to influence (the immediate one they have control over) therwize they become blocked on waiting for another team. Such organisational structures often leads to bloat in the code as data/logic builds up in the area the team controls rather than the place it's supposed to be.

Agile software development attempts to combat bottlenecks that build up around resource constrained areas by creating cross-functional teams with access to all the layers they need to change. Agile teams are then free to implement vertical slices of functionality across these layers iteratively. Now teams can more easier put data/logic in the appropriate place as they have access to the full stack and don’t have to wait for another team to help them out.

However, each Agile team tends to invent its own preferred solutions for problems that are common to other teams, such as user login, logging, etc. As each team is encouraged to be “self-organising” communication between teams and to shared stakeholders becomes more fraught. Teams often adopt different favours of agile and tools that impede moving functionality between teams. All we’ve done is turn things sideways!

For larger scale systems, we hit limits of understanding and separate systems more formally so that we can delimit ownership. We might attempt to form Feature Teams that can work across systems to deliver one giant feature after another. However, we then run into a “tragedy of the commons” where no one wants to own responsibility for keeping hairy areas of the code free from cruft. Feature teams tend to be focused on short term functionality not longer term health of the system. Soon “broken windows” start appearing because developers don’t have to live with the code they write. 

We may need to introduce big-picture architects and low-level component guardians to care about the macro and micro state of the code. But for large systems, communication becomes a time-consuming nightmare. Either the code stagnates as decisions take ages to get signed-off or after months or years neglect a system gets too messy to maintain easily. The inevitable slowdown pushes an organisation to consider a big rewrite (everyone wants to work on the new greenfield and choose shiny technologies) or a massive clean-up operation that may stall all new feature requests and require expensive education of developers about refactoring. Annoyingly developers often move on and so neither of these approaches last very long, we’re soon in the same mess again.

On a small scale, I think that it's possible to work with Conway's Law. I’m a great believer that XP practices such as Collective Code Ownership and Pair Programming improve communication and make it more likely for code changes to be made in the appropriate place. However, once you have multiple XP teams you need to pay attention to lines between them and find ways to share knowledge to keep architecture evolving coherently. One technique that we’ve tried where I work is to rotate team members between teams - very slowly (switching a team member with another team every few months).

For Agile and XP teams who work more collaboratively there are other implications that coaches might want to think about. Implications of Conway’s Law go much deeper than comparing org charts and power structures to system architecture. Communication paths which don’t necessarily map to the official org chart are also reflected in our codebases. Going even further than that I believe the quality and frequency of communication between individuals on the same team affects the design. Team size makes a big difference to that as does approach to hiring.

Here are a few more insights and observations from our discussion around the pool. I've tried to summarize as we went off on a few tangents!

• The XP practice of Metaphor is about synchronising the communication with the design.
• Geert Hofstade’s work on cultural differences might be impact the quality of communication and thus the system design. For instance, in Denmark there’s a short Power-Distance.
• Extrovert-Introvert differences within a team might transpire in use of code comments and naming. Extroverts often talk over others and rely more on communication than introverts.
•  The quality of communications with customers may reflect how much an organisation values and cares about system construction/design.
• We have different tastes in design similar to liking different music styles. Rg, heavy metal, techno. Personality differences of individuals can impede communication and be reflected in software design approach taken. Some of these battles between individuals on teams cause a lot of unnecessary churn in the code. Brings up the question of whether teams should be formed of like minded individuals.
• Where we have different native languages this can impede communication and have an impact on the design. This can be an issue where we have some members of a team who speak same native language and others who are working in a second language. Often an organization is working in official language such as English with some team members from local country and others who are migrants but may have other colleagues from their home country with whom they can have richer communication.
• Lines of property/ownership can also bleed into system design when we have long term employees working with contractors who have a short-term interest. Power struggles erupt in the code.

As coaches, we need to understand something about the shape of the systems being built as that gives us insight into where communication may need to be improved. We might even be able to illustrate communication issues with code smell examples.

Going a step further, ask WHY is Conway’s Law the case? Because, our knowledge about the code universe and system/domain universe is what is reflected/mirrored in the system. Conway’s Law all comes down to system/code design depending to what information we have access to (known-knowns and know-unknowns excludes inaccessible unknown-unknowns and the future). As coaches we can create opportunities to share knowledge within and between teams.

As coaches we can help team build a greater sense of ownership so that members can give more consideration to shaping design. Exploring multiple options helps team members understand what stories are worth implementing and when it's time to kill/retire features that are not.

Another thing that can help build confidence to make changes is improving skills around refactoring. Coding Dojos can be safe places to practice gnarly refactorings and bringing legacy code under test.

Simple social events such as lunch together can have a big impact on improving communication between teams and may make it more likely for systems to be built more coherently.

I believe that there are organising principles that we can apply to build maintainable software systems. However, unlike software there are human constraints that we need to pay attention to such as:

• how many people we can maintain relationships with? 
• how many email and in-person conversations we can keep up with?
• how much context switching can a person cope with before their creative problem solving skills are impacted?

This is not an exhaustive list! Please do post your thoughts as I'd be interested to hear from you.

Hierarchy of Developer Needs

At Agile Coach Camp Barcelona, I convened a session on “Hierarchy of Needs” and how this might be used by coaches working with software development teams to understand where to focus their efforts.

The idea of putting needs into a hierarchy was inspired by Maslow even though I’m well aware that the ordering of his model has not been validated by empirical research. However, I'm thinking that perhaps, like Empathy Maps, a hierarchy of needs can be used as a practical tool to tease out factors impacting the team and help figure out what to work on next.

 

Our group started with a simple activity that might easily be adapted for use in team retrospectives. I drew a person-shape on the board and asked our everyone to brainstorm around what developers need to work well. We wrote each need on a sticky note and then I invited the group to sort the sticky notes using a vertical axis from essential(bottom) to optional(top). Here’s what we came up with. 

We found that that many of the essential needs (at the base of the hierarchy) were practical ones such as decent network, version control, and big screens that enable us to write code. Then came the personal needs of puzzles to solve, valuable work, being listened to and trusted. At the top were again more environmental factors, such as whiteboards, snacks, and toys.

In our discussion, we agreed that when working with teams, it's often the essential needs that take a long time to resolve, especially when infrastructure kit is involved. Whereas the needs near the top could potentially be "quick wins". The more personal needs in the mid-section are where coaches tend to focus their attention and perhaps are those requiring coaching skills. We also noted that these issues are more likely to require trust-building between coach and team. See the photo (below) for the full set of notes and some wider perspectives on this.

As a coach you might run a similar activity when starting work with a team - perhaps using different colour notes to show which needs are fully or partially fulfilled and which needs are unmet. Or over time you might build your own checklist of typical needs, to help remember what to look for when observing the team. We also thought that a coach might use this understand and share what your own needs are as a coach and compared with team needs.

When discussing the contentious issue of whether cake should really be at the top of this hierarchy, I was reminded that Kent Beck originally said in “Extreme Programming Explained” that "perhaps the most important job for the coach is the acquisition of toys and food"

Later that same morning Sebastian Schürmann convened a session on Marshall Rosenberg’s Non-Violent Communication and I was interested to hear him reflect at the close that this model might be relevant to the developer needs we discussed earlier. I'd be interested to hear your thoughts on whether this activity is useful.

The Art of Embracing Change

I enjoyed giving a keynote speech at GOTO Berlin about "The Art of Embracing Change". The title of my talk was inspired by the subtitle of Kent Beck's "Extreme Programming Explained" and of course coaching is all about change. Keynotes are supposed to be opinionated and provide food for thought so I gave it my best shot.

At the heart of software development is an important truth "all things must change". Software is an amazing invisible material made of thought that can be changed any time - its softness is a defining characteristic. The available technology (frameworks/languages/libraries) that we can use to solve business problems evolves and business needs also change as the market evolves. Change is something a software developer is likely to grapple with throughout their career. Our instinct is to cope by fighting change, we owe it to ourselves to get better at anticipating change and handling it.

I talked about Conway's Law and how adapting code is affected by the layer of human communication around the code. I believe that part of why XP helps us to embrace change are the social practices of paired programming and collective code ownership which improve communication.

As a coach, I'm guided by a law of my own: "Code reflects the mood of the team" -- when teams enjoy their work, it has more care taken over it. After the talk Corey Haines mentioned that he has also seen this be a leading indicator with teams who measured their mood using MercuryApp.

I hope that we can clear obstacles out of the way so developers find joy in their work. One of the principles of the Manifesto for Agile Software Development is: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. In my talk I presented a hierarchy of programmer needs inspired by Maslow's - this is shown by Michele Ide-Smith in these wonderful sketchnotes.

The basic hygiene factors are a work envionment where developers can code and trust that they will use their time wisely. Team relationships help developers improve their ideas and learn from each other. Code must be valued by our organisation for us to feel it's worth investing our time in and attention to quality improves the ease with which we can work in our shared codebase. Someone commented to me after the talk that this hierarchy of needs has some parallel's with Dan Pink's Drive factors: Autonomy, Mastery, Purpose.

In a nutshell, my advice to developers who want to get better at embracing change is to become a continual learner -- seek to broaden your skills and expand your toolset for solving problems. Try letting go of being the expert and share your secrets. Change your codebase and your team mates, bring what you learned with you -- maybe you can arrange a developer exchange with another company. Seek out the state of Beginner's Mind.