Product Security in Agile Organizations: part 2 – Gemba || The Real Place

Product Security in Agile Organizations: part 2 - Gemba || The Real Place

In the previous part we looked at how you can impact product security in agile organisations. By pushing missing security knowledge, perspectives and capabilities into development teams we get an organisation that remains agile AND ships more secure products.

In this part we’ll look at Gemba, a practice that should help you figure out what the security knowledge gaps are in your organisation’s development teams, and what these teams are looking at you for to help them with.

Gemba || The Real Place
Gemba, which is Japanese for "The Real Place", is an activity that encourages people to simply walk around in the place where the work happens. Visiting The Real Place allows you to get a better understanding of the problems and challenges teams face, gather data and look for opportunities to improve or remove waste. The Gemba Walk was introduced in the Lean practicing Toyota factories as an opportunity for staff to take a step back from their regular work and visit the place where value for the customer is created. This allows them to improve their knowledge and understanding of the work, build relationships with the people working there and to identify wasteful activities.

While you may have a lot of ideas how development teams can do better (security) at their jobs, the people in those teams know best how to do their own jobs. It would be foolish not to learn from them. Gemba requires you to be genuinely curious. It is about understanding and improvement, not as a way of interrogating teams about their practices, but merely to better understand them and build relationships.

Being genuinely curious about a team’s inner workings and asking what they need help with is not only great for your understanding, it also build a relationship and increases trust on a personal level. Most development teams will be more supportive and embracing of your efforts if they understand the reasons behind them, and if those efforts fit (almost) seamlessly into their current practices and workflows.

How Gemba works
Gemba is not a silver bullet. It takes time. It is something that you do consistently. Try doing the following:
Walk over to a team’s area, ask them permission if you can simply observe and learn what they’re doing: Code, workflows, processes, all of it.
Ask permission to attend their rituals such as Planning sessions, standups and other regular meetings a development team has: this is where the work itself will usually be discussed at a more tactical level.
Ask teams what problems and challenges they are facing from a security perspective, and which of those they can solve themselves, and which ones they need your help on.
Don’t solve problems for the team, as this inhibits learning and long-term effectiveness. Instead act as an advisor or coach. If problems need to be solved by Security, work with the development teams rather than mandating solutions.
Be sure to spread your attention evenly. It’s not unheard of that a junior engineer or QA analyst turns out to be the biggest Security Champion in a development teams.

Some teams however need more love than only the practice of Gemba. If there are areas in your organisation that are of higher concern, an alternative is to embed one or several Security People into that team for several weeks or sprints. Their focus should not be to fix security challenges, but merely to learn about how the team operates and to act as a teacher and mentor on good security practices so that the knowledge is brought into the team, and the team fixes those security issues themselves.

As you practice Gemba, your understanding of the problems and challenges the development teams need your help on significantly increases. This allows you to identify and focus on the most impactful and valuable challenges that raise the bar of your products’ security level.

Last week one of my teammates observed a Sprint Planning session of a development team in our office, and learned there that the best place to ensure user stories are built in a secure manner is by integrating security in the Acceptance Criteria of their user stories. That was a cool win.

This is a Security Bloggers Network syndicated blog post authored by Koen Hendrix. Read the original post at: Koen Hendrix