Sam Parsons

Kaizen

Fri, 03 Jan 2020 00:00:00 +0000

Kaizen - 改善 - Japanese
Improvement, or, literally, “good change”

When I began leading a team for the first time, I had the chance to choose the name for my team. Most of the teams in our organization were named after movies and the like and so I picked some random movie to name our team. Our agile coach, Mark, teased me a bit about the lack of meaning so I started to think a bit more deeply about what we should name it. I thought if it was to be meaningful, it should communicate something of the culture, purpose and way of working our team should aspire to. I chose to name our team, Kaizen. Even now, the timeless ideas packed into the name still resonate with me.

Kaizen is a Japanese word literally meaning “good change”. After WWII a number of US business consultants in Japan helped develop lean manufacturing, where the focus is on eliminating waste. As a part of lean manufacturing, kaizen came to refer not simply to an improvement, but the practice of continuously improving manufacturing processes. Kaizen is an important component of Toyota’s approach and is a part of The Toyota Way. Since then, kaizen and lean manufacturing have been translated into other applications in many industries.

Kaizen is the practice of empowering everyone within an organization, from the CEO to folks on the manufacturing floor, to make changes that help improve the efficiency and quality of the product. Anyone can make suggestions. Depending on your organization, how those suggestions are collected or triaged might vary. In a bureaucratic organization there might be a board that reviews the suggestions and puts them into action. In other situations it may be more organic.

Keep in mind, kaizen might be surprisingly simple. For example, “Let’s move this toolbox next to the person who needs it so we can cut down 3 min, 20 times a day”. Such a change might seem insignificant, but it alone yields a savings of ~1 hour in time every day. The real magic is in the continuous part. As you keep making changes and improvements, these little things add up to create an efficient system that is much better than any that a designer could create on their own.

The marginal savings add up significantly long term, but there’s also a synergy created when individuals are empowered to affect change in their world. This leads to a greater sense of autonomy and motivation (see Daniel Pink’s Drive: The Surprising Truth About What Motivates Us), more engagement in the work, better results and, likely, more ideas for improving the process.

Perhaps what is even more profound is that kaizen starts to create a culture that views the process itself as a product and is always actively improving it. At its best, kaizen can lead to a self-leveling type of culture within an organization. If you want an organization that is resilient to change and can adapt effectively these principles are essential.

As a software engineer and leader I am interested in the application of these techniques and approaches to software engineering. Below I explore some ways that I have applied kaizen within an engineering team.

Ask for ideas to improve

Actively and consistently encourage team members to propose ideas and give them space and time to do so. This should be across the board: in 1 on 1’s, in team meetings, in private messages, anywhere. Some teams have a regular ‘engineering meeting’ or ‘design meeting’ where any member can propose a topic; these meetings are perfect for fostering the sort of space needed to explore ideas.

Leave egos at the door

Don’t shoot down ideas even if you may think it’s not a good idea at first. You must accept that you no longer will be the one with all the ideas, but as a result the team will have better ideas. Allow the team to experiment and explore ideas.

Data-driven decision-making

When it comes time to decide whether to keep a change or not, use data to drive your decisions. Take metrics that are core to your team’s success and make them visible for the team. Use these metrics to make decisions as much possible. Making decisions based on data is a huge win for helping egos stay out of the way.

Praise innovation

Praise innovation and encourage with verbal recognition (and if appropriate and possible, monetary reward).

Retrospect

Retrospectives are gold for kaizen. Steer retrospectives to focus on the process of software development within your team. Celebrate improvements; identify pain points and make real steps to address them.

Don’t lose ideas

Always capture ideas, don’t just let them linger in the air in a meeting or disappear into an abyss. This helps you actually have the ideas when you need them, but has a nice side-effect of communicating to people that what they’re suggesting is valuable to the team.

* * *

Through my experience with Team Kaizen, I found that kaizen is a key to creating a generative culture and helps establish an environment that tends towards success.

A generative team culture

Tue, 27 Aug 2019 00:00:00 +0000

I’ve been reading Accelerate: Building and Scaling High Performing Technology Organizations by Nicole Forsgren, Jez Humble and Gene Kim about implementing DevOps techniques and how doing so drives performance of teams.

One of the chapters introduces Westrum typology – a way to categorize teams based on their culture directly tied to their results. Dr. Ron Westrum identifies 3 different types of organizational cultures categorized by how they process information: pathological, bureaucratic and generative. In his 2005 article A Typology of Organisational Cultures, Westrum describes them like this:

Pathological Power-oriented

Low cooperation
Messengers shot
Responsibilities shirked
Bridging discouraged
Failure leads to scapegoating
Novelty crushed

Bureaucratic Rule-oriented

Modest cooperation
Messengers neglected
Narrow responsibilities
Bridging tolerated
Failure leads to justice
Novelty leads to problems

Generative Performance-oriented

High cooperation
Messengers trained
Risks are shared
Bridging encouraged
Failure leads to inquiry
Novelty implemented

Westrum’s research tied teams with generative cultures to better outcomes. The research presented in Accelerate uses the same model and correlates technical teams possessing generative cultures to better performance. However, it’s not just the research that indicates this, it has a personal appeal too. I take a quick look at what makes a generative culture and I think, “that’s the sort of team culture I want to be part of.”

Interestingly, research that Google conducted about effective teams came up with a similar conclusion. They identified 5 dynamics present in highly effective team – the most important by far being psychological safety.

[Psychological safety] … was the single most important dynamic in an effective team. Psychological safety is about risk-taking and being comfortable with vulnerability. People who don’t feel psychologically safe worry that taking risks will mean they’re seen as ignorant, incompetent, negative or disruptive. Psychological safety means feeling confident about admitting mistakes, asking questions, or offering new ideas.

This type of psychological safety is closely related to what Westrum describes as a generative team. Information is shared freely, no one is punished for failure or bringing to light undesirable information.

Not only is aiming for a generative culture the right thing to do for individuals within a team (hopefully they’ll be happier and enjoy their work and lives more), it’s also the most responsible thing we can do. We can get more done together, achieve better results for our organizations, and enjoy it more by fostering a generative team culture.

I still have a lot to learn about how to foster a generative culture, but I’m fascinated by the far-reaching impacts that are possible by creating an environment that allow others to thrive and information to flow quickly and easily. In the information age, this is what good leadership is all about.

References

Westrum, Ron. (2005). A Typology of Organisational Cultures. Quality & safety in health care. 13 Suppl 2. ii22-7. 10.1136/qhc.13.suppl_2.ii22.

Creating remote-friendly teams

Thu, 22 Aug 2019 00:00:00 +0000

I’ve been working remotely for more than 2 years in multiple roles both as an individual contributor and a leader. Most recently I have been remotely leading a team of 6; 3 based out of an office and 3 remote. As a development manager, I hired 5 out of 6 members on my team and was able to create the team culture from scratch. I’ve strived to created a culture that is remote-friendly and treats everyone as equals no matter where they are located.

Building a remote-friendly team is not just a random collection of things that ends up making remote work better, it actually forces a discipline and clarity of communication that makes your culture and organization stronger, leaner and more productive. If done well, adopting these things can improve the effectiveness even of traditional office-oriented teams and allows them the flexibility to optionally work remotely when needed.

Here are some guidelines I’ve followed to help to create a remote-friendly culture.

All important conversations and decisions are made in a medium where you can join remotely

If you’re in the office and others are remote, resist the urge to just have a quick huddle that excludes those who may be remote. This sort of thing kills a collaborative, inclusive culture and creates unnecessary walls and misunderstandings within your team.

Here’s some ideas of mediums the are open for remote people to join:

Email
Chat services, such as Slack or Mattermost
Video conference calls, such as Zoom or Google Hangouts
Project management services such as Basecamp
Forum threads
Blogs such as Automattic’s P2 WordPress theme

Project details are accessible anywhere, anytime

Project details such as epics, stories and bugs should be kept in a system that allows them to be formulated, refined, prioritized and tracked as the work progresses from anywhere. These artifacts end up forming an archive of the work that has been done. Some ideas of tools that you might explore are Jira, Trello, Basecamp or maybe Github Projects.

If you can access these types of project details from anywhere this equalizes all team members regardless of whether they are remote or not. It allows everyone to contribute and understand the process of how work is determined.

Some teams may have been accustomed to using physical artifacts such as a kanban board on the wall to track work. Although this has some benefits, it precludes remote team members from being first-class citizens.

Discussions and decisions from meetings are documented

Documenting decisions makes a place more remote-friendly, but it does more than that, it actually makes it better and more efficient for everyone. Always be capturing.

Video conferencing is available and low-friction

The team needs to have a way to sync up all together for team events such as refinement, planning, stand-ups, and retrospectives and also in smaller groups at will. This means making sure that there is some agreed software such as Zoom or Google Hangouts for doing so. If you have an on-premises part of your team, they need to have high quality and easy-to-use equipment in conference rooms. If it’s too hard to setup the equipment, that barrier may get in the way of impromptu meetings that need to happen and waste lots of time setting things up. If the video or audio is not high quality it can really degrade the experience for everyone.

Turn your video on

When using video conferencing you should encourage everyone to turn their video on. We all communicate a lot non-verbally through our facial expressions and body language. Capturing some of that strengthens the the human connections between people, helps build relationships and makes for richer communication.

Respect timezones

You should construct a definition of what the core hours for your team are and everyone should know the expectations of when they need to be available.

A note on meal times: within the bounds of the work day, you should be careful, with rare exceptions, to not schedule meetings over meals within other people’s timezones. Allowing time to break for meals enables people to keep steady blood sugar, refresh their minds, stretch their bodies and be more effective. Meal time is a basic need and you need to be careful when working with a remote team to respect that.

To conclude, I think distributed teams can be amazingly effective and I reckon we will find that in the future we’re all working remotely. Putting these principles into place sets up your team for success long term.

Always be capturing

Wed, 21 Aug 2019 00:00:00 +0000

One of my core principles for working effectively is to Always be capturing. No matter what I’m working on, even if the work is abstract and conceptual, I want to always be creating some artifact that represents the current mental work and can be shared later. This applies in both an individual and group setting.

For me, this principle and the practices I’ve developed are driven from my desire to remove friction and be efficient – to not lose any information that has been revealed and to make it easy to share with others (and even myself later).

Although some may be more inclined to this principle than others, I contend that putting it in practice can be a learned skill and has some significant returns on investment. Here are some concrete examples of what Always be capturing looks like.

In a brainstorming meeting, get everyone to write down their ideas on post-its with sharpies. Your goal here is to gather as much as possible and you want to make sure that the good ideas don’t just vanish into thin air.

In a technical discussion, document the questions and points brought up as your meeting progresses. People are much more likely to talk and contribute if they see their contributions are being captured and have value. Making the words visible helps keep the conversation focused.

In an architectural discussion, work to collaboratively create diagrams (e.g. sequence diagrams) to convey the concepts being discussed. Don’t let groups talk for a long time without capturing something that reflects the concepts being discussed or proposed.

In a collaborative decision-making meeting that requires consensus, outline the different decisions in a shared document that everyone can see and facilitate gathering pros and cons. Use the document to help work towards consensus. My underlying belief here is that when the options and reasons for/against each are made clear, 90% of decisions are made since the common sense consensus is clear. When the decision is not clear, you have gathered in one place the data needed to make the call.

When refining user stories as a team, capture questions and modifications to the story in real-time and use that live feedback to shape the story together.

In a team retrospective, don’t just let people talk, capture what they are saying. In my team, we sometimes we use a digital post-it-and-sharpie tool (such as Miro or Mural); other times we have someone facilitate capturing the feedback in a text document.

When ideas come up, have a notebook to capture them so that you can come back to them later.

In meetings, take notes on the key points, new information, and action points. Having these notes and being able to refer back to them will prove exceptionally valuable. You can do this collaboratively if you’re leading the meeting, but you also gain a lot of value personally from doing this even if you’re the only one who gets the notes. Having coherent notes is a lot like having a time machine.

When you answer a question, write it up in a way that you can share it not only with the person who asked but also for others who may have that same question. You can then broadcast and multiply your impact with the same effort by an order of magnitude (or more). This idea is practiced by many folks, but I’ve recently heard Kent C Dodds talk about this idea.

When you encounter a topic for a standing meeting, add it to a shared living document for next topics for that meeting.

When you find links that you want to revisit or read later, use a bookmark tool to keep track of them.

When interviewing someone, go through your questions and write down key points from their responses. This allows you to go back afterwards, jog your memory and evaluate responses.

When you find out you are responsible for doing something, add it to your to do list. Maintain this list by visiting it regularly, prioritizing items, and marking things off that are complete.

In general how you do the capturing doesn’t matter too much as long as the medium works well for you and others involved and allows you to get most value out of the artifact later.

Always be capturing is one of the most powerful tools I’ve found to work effectively.

No constraints – WordCamp Edinburgh

Thu, 21 Jan 2016 00:00:00 +0000

In November 2015 I gave a talk at WordCamp Edinburgh called No constraints - building a minimum viable product with WordPress. I told the story of how we used WordPress to build a vision of what the University of St Andrews’ web presence might look like while I was working in the Digital communications team.

The prototype site that we built lead to the development of a major, multi-phase, multi-year project.

Note: The first few seconds of the video is missing, but the rest of the talk is present.

Further resources

Progressive enhancement is not passé

Fri, 15 Jan 2016 00:00:00 +0000

A month ago, A List Apart published Interaction Is an Enhancement by Aaron Gustafson.

Even in the advanced world of 2016 there are still reasons to build web sites that work without JavaScript. Supporting plain HTML without JavaScript to be fair is more difficult, but that doesn’t mean it’s not the right thing to do. I see it as a question of accessibility. Building a website that requires JavaScript for any functionality is like building a new multistory building without an elevator because almost everyone can climb stairs.

To clarify a little…

The site need not be identical without JavaScript. At a minimum we need to merely deliver the same core content or provide an alternative path for those without JavaScript.
Is this product intended for the general public? If not, then we may consider the pros and cons of delivering a non-JavaScript solution.

For example, if we built a JavaScript-required single page application content management system for the general public we should provide an alternative way for people to edit their content. In the spirit of progressive enhancement, build the basic non-JavaScript application first and and then build the advanced alternative experience for those with JavaScript enabled.

An example of this is WordPress.com’s new React JavaScript application Calypso that provides a fresh interface to the WordPress admin. In this case, the existing WordPress admin can operate completely (more or less) without JavaScript – you can add and edit posts or pages and update settings. By building an app on the API, Automattic was able to create a fresh interactive interface that relied on JavaScript while still providing the existing admin for those without JavaScript.

I say all of this not as someone who is against JavaScript, but as someone who daily slings JavaScript in the browser and the server. As digital creators we have a responsibility to ensure our products are as accessible as possible.