Many people who work in software development today have heard of the practice of pair programming, yet it still only has patchy adoption in the industry. One reason for its varying acceptance is that its benefits are not immediately obvious, it pays off more in the medium- and long-term. And it's also not as simple as “two people working at a single computer”, so many dismiss it quickly when it feels uncomfortable. However, in our experience, pair programming is vital for collaborative teamwork and high quality software.

There isn't a simple dichotomy of remote versus co-located work, instead there are several patterns of distribution for teams each of which has different trade-offs and effective techniques suitable for them. While it's impossible to determine conclusive evidence, my sense is that most groups are more productive working in a co-located manner. But you can build a more productive team by using a distributed working model, because it gives you access to a wider talent pool.

Modern source-control systems provide powerful tools that make it easy to create branches in source code. But eventually these branches have to be merged back together, and many teams spend an inordinate amount of time coping with their tangled thicket of branches. There are several patterns that can allow teams to use branching effectively, concentrating around integrating the work of multiple developers and organizing the path to production releases. The over-arching theme is that branches should be integrated frequently and efforts focused on a healthy mainline that can be deployed into production with minimal effort.

Ship/Show/Ask is a branching strategy that combines the features of Pull Requests with the ability to keep shipping changes. Changes are categorized as either Ship (merge into mainline without review), Show (open a pull request for review, but merge into mainline immediately), or Ask (open a pull request for discussion before merging).

Platform teams have a unique reliance on other teams to ensure adoption of their platform - getting code changes into other teams' codebase is critical to their success. There are a variety of patterns for that cross-team collaboration, and selecting the right ones depends on both the phase of platform adoption and the ability of both teams and codebases to accept external influence.

If you use retrospectives, or any kind of meeting where people are supposed to discuss and learn from their discussions, you will have experienced less efficient sessions from time to time. There is no wonder in that, and it happens to most people. This article describes and offers solutions for three of these unfortunate situations: skipping generating insights, getting lost in things you can't change, and being dominated by a loudmouth.

Good technical design decisions are very dependent on context. Teams that regularly work together on common goals are able to communicate regularly and negotiate changes quickly. These teams exhibit a strong force of alignment, and can make technology and design decisions that harness that strong force. As we zoom out in a larger organisation an increasingly weak force exists between teams and divisions that work independently and have less frequent collaboration. Recognising the differences in these strong and weak forces allows us to make better decisions and give better guidance for each level, allowing for more empowered teams that can move faster.

Technology is constantly becoming smarter and more powerful. I often observe that as these technologies are introduced an organization’s productivity instead of improving has reduced. This is because the technology has increased complexities and cognitive overhead to the developer, reducing their effectiveness. In this article, the first of a series, I introduce a framework for maximizing developer effectiveness. Through research I have identified key developer feedback loops, including micro-feedback loops that developers do 200 times a day. These should be optimized so they are quick, simple and impactful for developers. I will examine how some organizations have used these feedback loops to improve overall effectiveness and productivity.

An inception is an activity done at the start of a project to gather together the people involved and set a common direction and working style for the on-going work. The lean inception is a focused form of inception, which can be done in a single week. During this time we understand the key features and customers for the product, and build a canvas to formulate the characteristics of a Minimum Viable Product.

To accelerate means to move faster, to gain speed. Effectively working with data is key for any organization that wants to thrive in the modern world, and Data Mesh is showing organizations how to realise value from their data, at scale. The Data Mesh Accelerate workshop helps teams and organisations accelerate their Data Mesh transformation, by understanding their current state and exploring what the next steps will look like.

A traditional liberal-arts degree provides skills that are highly relevant for a product manager

Get good audio, use gallery view, mute if not talking, and welcome the cat.

We, and our colleagues, are often called on to perform architectural assessments for our clients. When we do this, the architects involved with these systems will talk about the performance of these systems, how resilient they are to faults, and how they are designed to evolve to easily support new capabilities. The elephant that rarely comes up, however, is how different systems contribute to business value, and how this value interacts with these other architectural attributes.

Benefits of pair programming are widely accepted but advice around pair rotation remains controversial. When and how frequently should teammates rotate pairs? And… What if we rotate pairs every day? We worked with three teams through an exercise of daily pair rotation. We developed a lightweight methodology to help teams reflect on the benefits and challenges of pairing and how to solve them. Initial fears were overcome and teams discovered the benefits of frequently rotating pairs. We learned that pair swapping frequently greatly enhances the benefits of pairing. Here we share the methodology we developed, our observations, and some common fears and insight shared by the participating team members.

A while ago I was chatting with a post-doc on his way to an academic career. He was asking me about research topics wanting my input as he felt I could inform him on what would be research of practical use. I wasn't very helpful, but I did mention that the best way to do this would be to spend some time in industry to get a feel of how software development works in the wild and what problems could do with some research effort. His answer to this thought was very troubling.

Alignment maps are organizational information radiators that help visualize the alignment of ongoing work with business outcomes. The work may be regular functionality addition or technical work such as re-architecting or repaying technical debt or improving the build and deployment pipeline. Team members use alignment maps to understand what business outcomes their day-to-day work is meant to improve. Business and IT sponsors use them to understand how ongoing work relates to the business outcomes they care about.

When people use the term 'software architect' they are using a metaphor from building construction to help people understand the architect's role.Ironically in doing this they misunderstand the actual role of a building architect.

With the growing interest in data analytics and visualizations, we're seeing more effort put into interesting visualizations that allow people to draw insight from data floating around in an organization. Most of these dashboards are aimed at individual usage, but there is a growing tendency to use them for a more communal purpose.

Here's a common misconception about agile methods. It centers on the way user stories are created and flow through the development activity. The misconception is that the product owner (or business analysts) creates user stories and then put them in front of developers to implement. The notion is that this is a flow from product owner to development, with the product owner responsible for determining what needs to be done and the developers how to do it.

Agile software development has broken down some of the silos between requirements analysis, testing and development. Deployment, operations and maintenance are other activities which have suffered a similar separation from the rest of the software development process. The DevOps movement is aimed at removing these silos and encouraging collaboration between development and operations.

From time to time during a meeting or workshop, it's good to get votes on a number things in order to rank or choose a subset. A quick and nice way to do this is dot voting.

Open Space is an approach to help you put together self-organizing conferences. I was first introduced to it by Norm Kerth in 1997 and have since seen it used, and used it myself, many times. It seems to work well in small scales, groups of a dozen or two people, and at larger scales of one or two hundred. I've seen it for periods of one to three days. I'll describe it with variations I have seen: Crested Butte is a small annual workshop of around 20 people, Agile Universe 2002 had about 100 or so at the conference with Open Space in one track (they've continued to do this since, but I've not been able to get there), foocamp did this with a couple of hundred people. The technique was developed by Harrison Owen and is well described in his book.

Pair Programming is a software development practice that has the developers work in groups of two. All serious code is written by two programmers, typically sitting side-by-side with a single monitor, often with a single keyboard. As they add code, they discuss each step together.

A bunch of common misconceptions about Pair Programming.

Improvements in communications technology have led an increasing number of teams that work in a Remote-First style, a trend that was boosted by the forced isolation of Covid-19 pandemic. But a team that operates remotely still benefits from face-to-face gatherings, and should do them every few months.

All agile methods stress the importance of direct interaction between the developers of a system and customers who are its eventual beneficiaries. The agile manifesto said “Business people and developers must work together daily throughout the project”, which is there to stress the high frequency of interaction. Extreme Programming stresses this through its practice of OnsiteCustomer.

When people think of code reviews, they usually think in terms of an explicit step in a development team's workflow. These days the Pre-Integration Review, carried out on a Pull Request is the most common mechanism for a code review, to the point that many people witlessly consider that not using pull requests removes all opportunities for doing code review. Such a narrow view of code reviews doesn't just ignore a host of explicit mechanisms for review, it more importantly neglects probably the most powerful code review technique - that of perpetual refinement done by the entire team.

A project timeline is a valuable thing to produce during a project retrospective. A timeline should show the various events that occurred during the project, and how they affected the project.

A common thing you find in agile projects is that the development team sits in a single open team room. It was advocated early on in Extreme Programming and called out as one of primary practices in the second edition. Agilists favor a open team room as it promotes lots of informal and deep communication between people on the team.

If you're using XP style planning, you need to get rapid consensus estimates from developers. Throwing the estimates lets you quickly tell when developers have same similar views on an estimate (so you can note it and move on) or if there is disagreement (when you need to talk about the UserStory in more detail.