People build products, not processes

By Siddarth Ramaswamy

In the last decade we’ve had Agile and XP methodologies revolutionise the way we develop and deliver software. Two of its core principles have always been the emphasis on people over processes and the role of collective ownership and collaboration.

But in practice there’s far more importance given to the process of delivery, rather than the people involved in this process. This debunks the whole philosophy behind Agile and XP. Below is a list of patterns I’ve observed across teams and some solutions that may come in handy:

Agile / XP == Mindset

Problem: Getting designers and engineers to collaborate together in building our mobile app.
Solution: We use zeplin as a documentation tool on what needs to be designed, giving feedback and all other collaboration that is needed for getting design finalised. Instead of working with stories and points, this tool was the communication medium on which work needed to be done.

The extreme programming guide, or the agile manifesto, isn’t about implementing processes, but the behaviours/principles you would like to see in a team. We aimed to get team members to collaborate and deliver user value by not following user stories and points. Instead, we used something that worked for the team.

Behaviours && Processes

Problem: Lack of interaction in planning meetings and long winding meetings
Solution: Kill presentation via software and move to physical cards on the table. This is far more engaging and people prioritise what needs to be done. It also ensures the entire team works together to get the cards ready before the meeting.

In the above example we had a process that wasn’t working for us. There were a few team members who questioned and chose to change it to improve how we collaborate. Generally with teams we blindly follow processes without asking why we are doing things or how we can develop an existing process. This type of behaviour leads to a processes being a chore, rather than solving a problem.

There is an excellent interview on processes from none other than Steve Jobs. Highly recommended viewing.

Standups Suck, and Here’s how to fix them is another excellent example of questioning the importance of standups.

Educate Team Members

Chef has created an industry move called DevOps Kungfu. It talks about DevOps culture and how to adopt it. In doing so, they invited other community members to fork it and update it based on what they feel is right or pledge on it if they totally believe it. This is a great example of how you can onboard a team member to your culture.

While onboarding new team members, you should:

• Talk about your team culture — Super important, not practised enough.
• Ask their opinions on your team culture, and modify behaviours accordingly around their suggestions.
• Ask them to pledge to the culture once they have a buy-in — and not a rule, but voluntary after discussions.

Sometimes an external member from another company brings invaluable insights and learnings. Don’t set anything in stone, instead, pick the best practices.

Product Members != Resources

It helps not to call people “human resources”. They’re people, and as it turns out people like to be treated as people. Go Figure.
- Dharmesh Shah (Founder HubSpot)

It’s standard practice for management/business professionals to call product members as resources. People are not numbers in a financial spreadsheet. But this is far from the case — product members are people, they have emotions, perspectives. They are diverse, complex and not just another number in the organisation structure. It’s the collective ideas of these “human resources” that build great products.

Cargo Cults

A cargo cult is a belief system among a relatively undeveloped society in which adherents practice superstitious rituals hoping to bring modern goods supplied by a more technologically advanced society.
- Wikipedia

Another behaviour present in organisations is the existence of Cargo Cults. This happens when a majority of the society has come from a specific belief system/background/influence, and the minority is forced to follow the belief system as a rulebook, rather than explaining the need for certain behaviours.

Micro Management != Process Efficiency

At the bare minimum by communicating the movement on execution (team velocity), business (customer value), technology (the state of the platforms delivering customer value) we have historically seen a trend on how the projects are executed. It’s not enough to present data but tell a story with the data :)

All teams require regular cadences and information flow which communicates the present state of the project also known as the project heartbeat. Most times the implementation of the control is a result of a lack of data visibility to the right stakeholders. If you have a process/ system/dashboard conveying this information, it needs to be re-evaluated from time to time to ensure stakeholders are getting the cadence they require and delivering the right narrative.

Data != Value

Recently, I was involved in developing a plugin which provided contact information from emails received. It showed heavy user acquisition. To test this theory, I ran a small engagement activity which debunked the acquisition metric and clearly showed there was no user value being driven.

Depending on the acquisition number and reporting that number would be as good as reporting any other vanity metric. A product needs to deliver constant and consistent user value. Else, there is no use in any form of product development.

Often people are happy seeing dashboards and metrics and forget about the value driven to the user. You need to continually question this and reiterate it on a dashboard to make sure you only see what drives value to the user.

In conclusion

Don’t consider posts/books/sermons as bibles, they are nothing but perspectives

This holds true even for this post. Listen to your team for the behaviours you want to exhibit. Solve problems as a team, rather than a command and control mechanism. And most importantly, one that makes GO-JEK a great place to work — always question. ALWAYS.

Define — Measure — Iterate — Redefine — Rinse Repeat.

This is not to say we follow everything to the T. We make more mistakes than we can imagine, but we’re learning and growing. Come help us scale faster as we expand across South East Asia. Check out gojek.jobs for more.