In Software Engineering Respect for People is Trust

Today we speak with Jason Yip, a principal consultant with Thoughtworks. Jason helps companies interested in improve how they develop software. In this interview, you’ll learn the following:

After over a decade of helping organizations develop better software, why some things have changed and why some things remain the same.
In software engineering, why “meeting where people are” is an instantiation of Respect for People.
Why Visual Management in knowledge work an attempt to make visible the invisible.

Enjoy the interview and learn more about Jason immediately after. Enjoy.

Hi Jason. Can you tell me audience a little about yourself and your work?

I’m an Electrical Engineer by training but I’ve focused on software since realising that I preferred that to other activities. Over the last 13 years, I’ve had various roles related to software builds and development but these days what I mostly do is consult with companies who are interested in adopting Agile and Lean approaches to software delivery, IT operations, and product development.

As a principal consultant for Thoughtworks, you’ve spent a lot of time consulting with client companies. Over the years, have you seen a trend in what methods software development teams are adopting?

Some things haven’t changed, in the sense that some of the methods are becoming mainstream so it’s more of a continuation of a trend. “Some of the discussions I’m having about Agile today are very similar to the ones I’ve had back in the beginning. I notice this “more of the same” phenomenon mostly in the context of internal-facing software development.

There have been some changes in what technologies or technology approaches are being advocated and some have implications on how teams are structured, for example micro-services and DevOps.

The biggest trends that go beyond what we would have already advocated in the early days, and this is usually in the context of consumer-facing digital teams, are the twin forces of Continuous Delivery and what we might call Continuous Design, that is the application of design and customer-centric approaches in a rapid, iterative way.

Software development processes have undergone quite an overhaul in the last several years. On this blog, we interviewed Mary Poppendieck back in 2007 on Lean for Software. Can you help explain the difference between Agile, Kanban for Creative and Knowledge Work and Lean for Software?

I would say that Agile is an umbrella term that refers to a set of methods that share a few key assumptions about what makes software development more effective:

Closing the gap between problems and problem solvers

Taking smaller steps

Validating every step

Improving as you go

Lean for software development is partially a reinterpretation of Agile approaches through the lens of Lean principles and partially an extension of Agile approaches by borrowing from Lean insights and tools. Practically, I find people who identify with Lean tend to have a more holistic view of systems and processes, and are more likely to seek insight from other industries.

Kanban Software Development I’d say can be described in two ways: 1. an evolution of Agile towards a more continuous flow approach; 2. an incremental change approach to improving software delivery

Many companies talk about culture and sometimes cite the Respect for People pillar at Toyota. Can you share with us how Kanban might support that pillar in the Toyota Production System? Specifically, can you share an example of a company you’ve worked with that exemplified the principle of Respect for People within a software development context?

Kanban, specifically the incremental change approach, and further the idea of starting where you are, I think most clearly reflects Respect for People, both in terms of meeting people where they are as well as trusting that they are capable of their own improvement given the appropriate support and structures. But the most frequent example I see within the software development context is simply when the relationship between business owners and development teams shifts from one of giving and taking orders to one of collaboration. This means that it is not just a business person asking the development team to build something but also development team members proposing and/or improving ideas.

We know that visual management is a critical aspect of Lean. In software development, why is visual management especially important? Can you share a specific example of how software development teams have adopted visual management to help them in their work?

In software development, like any form of knowledge work, the work is essentially invisible, especially to non-technical stakeholders. It is very difficult for observers to realise that people are overburdened, that work is bottlenecked, or any other problem that is relatively easier to see if the work was physical. The most common example of visual management that you’ll see in Agile, Lean, Kanban teams is the card wall or kanban board, that is a physical representation of the workflow and the work using index cards. This is not the only type of visual management useful in software development teams though. There are also things like build lights that show whether recent integration and test runs worked, various charts showing progress and software quality, and broader issues like upcoming demand in the portfolio.

If you get down to the essence of visual management being used to make problems easier to see, I would also say that coding standards and syntax highlighting are a low-level example of visual management in the software development context akin to 5S in a physical factory.

We’ve seen software development go through phases: waterfall to agile to lean for software. And now, Kanban software development. Where do you see software development processes going next?

With Continuous Delivery, I think we’ve kind of reached the end of delivering more frequently. There are still going to be improvements in programming and technology approaches of course, but that’s not really a process thing. The next frontier in process I see will be less about delivering faster and more about delivering better products and services. That is all the activity happening with Lean Startup, Lean UX, Jobs-to-be-Done, etc. And then approaching that at scale.

What are some good methods or practices you’ve seen that can especially help distributed software teams?

In my opinion, the most critical practice for distributed software teams is to humanise the “other side”. It is too easy to forget that you are dealing with humans when you don’t see them, don’t hear them, don’t learn about the many “irrelevant” social details that remind you that you are working with real people. This means flying people around, always-on video conferencing, always-on chat rooms, etc. anything to ensure that communications are not just transactional.

Another important practice is structuring the work such that you reduce the amount of communication required across distributed boundaries. So oddly enough, I’m encouraging people to both increase interaction across distribution boundaries to humanise relationship AND encouraging people to structure the work such that the ongoing work does not require frequent interaction.

Thanks Jason. Appreciate you spending some time with us and in answering our questions.

About Jason Yip

Jason has worked at ThoughtWorks for the past 13 years as a buildmaster, developer and currently as an organisational Agile / Lean / Kanban coach. He was one of the early committers on CruiseControl, the first Open Source Continuous Integration server, and is a prolific blogger and tweeter on Agile, Lean, and Kanban topics. Jason used to own the entire first results page on Google until some Hong Kong actor showed up.

Other Interviews you might enjoy: