For years, I’ve fulfilled the role of Scrum Master for many different organizations and Scrum Teams. These teams were mostly focused on software development. I’ve been in the fortunate position of having worked for some great organizations. These organizations were able to attract the smartest developers and create products customers loved. Everyone enjoyed going to work and looked forward to learning new stuff, helping each other solve tough problems and engage with the users of the product.
I’ve also worked for organizations where people struggled to create such a culture. For them, it was difficult to keep the high potential developers on board and hire new ones. Often, after only having worked shortly for such an organization, I already felt what the problem was: they lacked a “Developer Culture”. In the beginning, it was only the smell of the place that made me conclude this. However, over time more tangible examples popped up. Everyone agreed on how serious this was. The organization was full of people discussing “what” needed to be built, the problem was that there weren’t any people that could actually build the product. For these organizations, creating a Developer Culture isn’t a nice to have, it’s the only way to survive!
“Creating a Developer Culture isn’t a nice to have, it’s the only way to survive!”
In this blog post, I’ll share examples of how I experienced a Developer Culture. Now, what I don’t want to do is write a vague article about culture full of fluffiness that might sound interesting but doesn’t provide any clarity. I’m simply going to share my perspective as a Scrum Master working closely with developers. That’s not going to be a technical perspective. Although I did try being a developer, I failed miserably… To be clear, whenever I write “developer” in this article, I mean everyone involved in writing software and building products. So this can be a developer, analyst, tester, designer or architect etc.
Sprint Review at Schiphol Airport with lots of stakeholders
Examples of a Developer Culture
Examples that I’ve experienced and consider part of a Developer Culture are…
- Development Teams are considered the most important part of the organization. Everyone that’s not part of the Development Team is there to support them. Not the other way around. HR, Finance, Sales and Management should be focused on making the life of developers as convenient as possible. Don’t let Development Teams get lost and stuck in the organization’s hierarchy.
- Developers are paid really well. I’ve always considered it strange that in organizations everyone agreed that developers were crucial for the organization’s existence, but were nevertheless paid poorly (compared with others in the organization). If you truly consider developers that important, put your money where your mouth is. It seems however that whenever the work being done becomes more tangible, the salary decreases. Wherever the work becomes vaguer, it’s the other way around.
- It’s about the outcome, not output. It’s about building valuable software for the customer, using the least amount of time. Not about finishing as many tasks as possible, of which the value isn’t clear. Also, involve the Development Team in determining the value. This will help them build the right things, and build it right.
- Development Teams choose their own metrics to measure progress.These metrics are focused on the outcome. Examples are cycle time, customer satisfaction, team happiness, innovation rate, return on investment, and total defects. Avoid metrics that focus on utilization and efficiency. They encourage local optimization, are easy to manipulate and are often used to control individuals.
- Everyone is in contact with the customer. The real customer. Not (only) stakeholders that know a customer. I mean the person using the product. If this means that developers need to leave the office to visit a customer: awesome! I’ve once hired a mini-van and took the entire team to a customer. This proved to be a nice team-building activity as well.
- They can choose and purchase their own gear. With gear, I mean screens, desks, chairs, headsets etc. I’ve experienced organizations where developers were doing multi-million projects, however having two screens or a decent headset wasn’t possible. This was against company policies. The result: unhappy developers that try to sneak in their own gear from home. This created a culture of fear, secrets, and fighting “the system”. I can’t imagine this is the culture organizations want to have.
- A budget is provided for having some fun. How & when they spend it: that’s up to them! It might be visiting an escape room, organizing a LAN-party, having a bbq, playing paintball or going on a boat trip. As long as it helps them gel as a team. Nothing beats a good team activity!
- A suitable environment is offered in which they can do complex work.Many organizations still use “flex-desks” and “open-office space” where everyone is sitting together. For developers, this is often a nightmare. Lack of focus, no feeling of having a team space and continuously being distracted doesn’t help with solving complex problems or doing innovative work. If they want, give them their own team room. Let them decorate the room however they want. Provide whiteboards. Lot’s of whiteboards. If a team room isn’t possible or necessary, simply involve them in creating their own environment in which they feel comfortable.
Random pictures of our PHP Elephant collection, walls of transparency, team manifesto, baking pancakes for my team
- Development Teams take responsibility for hiring new team members. In The Netherlands, within the development community, everyone knows each other. They know exactly when someone becomes available and if they would fit in the team. This is a far more powerful approach compared to what a recruiter can achieve. Sure, a recruiter a network as well, but the really good developers have already switched jobs/assignments before a recruiter is aware of this. They’ve already been approached by another developer during a local meetup. Really, developers can be your best recruiters!
- Tools like JIRA, TFS or any other work-tracking system are only used if the Development Teams considered it useful themselves. Not because it is such a convenient tool for others in the organization to track the progress. This will only create a culture of fear in which Development Teams feel they are being monitored.
- Developers are encouraged to contribute to the wider community. This can be by writing articles for tech sites, speaking at seminars, attending meetups, offering to coach and/or mentoring. Every community depends on the contributions of its members. Being part of a thriving community, will help developers gain innovative ideas, solve problems with peers and expand their individual networks.
- They take care of their own “HR Process” by given each other feedback, provide tips for personal growth opportunities. I’ve worked with teams that even took care of salary increases and how a bonus should be divided. Although this didn’t always work out ideally, the signal the organization provided, “we trust you”, did create a culture of ownership where self-organization more easily occurred.
- Attending training and workshops is strongly encouraged. Taking days off for this wasn’t a painful and even humiliating procedure by asking for permission. I’ve always encouraged developers to attend public workshops and classes. Instead of in-company training. By participating in public classes they meet other developers, learn about software development in a different context and opened up for new ideas.
- There is sufficient time for R&D. This could be jointly reading a book or watching a video and share findings among each other. Organizations that have Development Teams fully scheduled with “customer work” will eventually pay the price. Stress-levels increase, quality drops, and innovation will fall apart. We’ve always scheduled roughly 1 day per week for R&D. Sometimes we used a fixed day for this, for example, the Friday. I’ve also been part of teams that preferred R&D weeks.
- Pair programming is stimulated and not considered a waste of time. Pair programming has lots of benefits. For example, it stimulates collaboration, shared understanding and improves the quality of the code. In my experience, by doing pair programming you deliver better products even faster because you’ve got less re-work or bug fixing afterward. So it’s definitely a practice I strongly recommend.
- They choose to use Scrum themselves. Or Kanban. Or XP. Whatever supports them the best in doing their work. The framework or methodology should never be the goal of itself. It should be an enabler. Involve the Development Team in creating a way-of-working that benefits them the most.
- They have fun. Lots of fun. This should be part of any kind of culture. Some organizations have become so serious nowadays. Have a bit of fun. We’re spending so many hours together at work, why don’t just have an awesome, fun and useful time with each other?
Random pictures of close collaboration with the customer, pair +1 programming, team activities, doing a Sprint Planning
These are examples that in my experience help grow a Developer Culture. The order is completely random, it’s how it appeared in my mind. As mentioned earlier, if software products are your core business, growing such a culture isn’t optional. It’s crucial for the existence of your organization!
What’s your view on the importance of growing a Developer Culture? What are the examples you have experienced?
See how you can support us at patreon.com/liberators