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

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,... Continue reading

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... Continue reading

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... Continue reading

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... Continue reading

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... Continue reading

"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... Continue reading

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... Continue reading

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. Continue reading

I gave a talk at Agile Coaches Exchange meet up yesterday and someone emailed afterwards saying: "Rachel mentioned about few questions that she uses during one on one. Those set of questions could help me a lot because I am terrible to start and flow the conversation with my team." So I thought it might be handy to do a quick write-up of what questions I tend use in individual coaching sessions. Continue reading

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 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 Velcoty FAQ as an illustration of working agreements around this. Your team might choose to do this differently and that's okay. Continue reading

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. Continue reading

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. Continue reading

Here’s a very simple tracking mechanism that your team can use for physical story cards to learn more about the proportion of time you spend on different types of work. One of our product development teams (Tabasco) 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 Continue reading

We had a good turnout for our first Extreme Programmers London meetup and gathered plenty of ideas for future meetups. Continue reading

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. Continue reading

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! Continue reading

A story about what I learned from planning walks that may apply to plans for software development. Continue reading

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. Continue reading

I found the talks at The International Conference Of Software Architecture interesting and thought provoking. Continue reading

At Agile Coach Camp Barcelona, I lead an Open Space discussion around the implications of Conway’s Law. 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 Continue reading

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

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 is at the heart of coaching software teams. Continue reading

I took the photo of one of our product development teams yesterday. What I hope you can see from the photo is engagement of everyone in the conversation. It's quite unlike many tedious story estimation meetings that I've been in at other organisations. Often developers are in a room for a long time putting numbers on user stories and gradually losing the will to live. We used to have a similar long session every few weeks to estimate a big batch of stories before selecting those to work on next. Our Product team used to meet with stakeholders and write... Continue reading