“I can tell how much this story means to you. It makes me wish I could’ve experienced that with a Development Team”. This is what another Scrum Master told me after we took turns during a recent training to share a success story about a Development Team. I’ve heard this many times before.
What does this say about Development Teams out there? Why is there such a strong emphasis on the people needed for the process and so little on the people doing the work?
Agile software development started with developers. These days, it seems to be more about Scrum Masters, Agile Coaches, Product Owners, and other “process roles”.
Agile software development was started by developers. These days, it seems to be more about Scrum Masters, Agile Coaches, Product Owners, and other “process people”. Just look at the number of people showcasing their Scrum Master, Product Owner or coaching certificate on LinkedIn. Most companies are eager to send people to classes for Scrum Masters and Product Owners, but they’re not willing to pay for professional development for developers. Or fail to see how important the quality, tools, and skills of developers are.
I’d wager that a good Development Team — one that cares about their users and delivers high-quality software frequently — can compensate for a mediocre Scrum Master and Product Owner. But I doubt the reverse is true.
As a passionate developer, this strong focus on “process people” hurts my heart. The best experiences I’ve had with Scrum were with teams that lived a strong “Developer Culture”; a shared understanding of why software craftsmanship matters. Which is also the reason why we’re going to do something about that at The Liberators (scroll the to the bottom if you want to know more).
In this post, I share my personal story of an organization — NowOnline — where we shaped a strong “Developer Culture”. Instead of a dry, theoretical post, I opted for a more personal approach. I went through my archive of the pictures I took from my work at NowOnline and wrote the post around the collages I created.
A bit of context on NowOnline
NowOnline started somewhere in 2001. Starting out with a strong focus on website development, I built my first site for them in 2002, first as a freelancer later as an employee. In 2010 we started a second location in Utrecht that focused on developing HR-related & mission-critical software for brands of our largest customer (USG, Unique, StartPeople, CapitalP). We worked with .NET (first VB, later C#) from the very start. Initially with one Scrum Team, later with three, I doubled as a developer and Scrum Master. This branch of NowOnline later transitioned into HROffice.
Please note that although I write in past-tense as I have since departed, both NowOnline and HROffice still exist. And many of the members referred to in this article still work there. We all look back on our time there an awesome experience overall.
1. Have fun together & make personal connections
The best (Development) Teams I have worked with spent time and effort to have fun together. At NowOnline, some of that fun happened during work, with practical jokes and having a laugh together, while others happened outside of work, during trips, barbecues, and team activities.
Practical jokes in our software (top-left) to having drinks after work (bottom-left), sharing a barbecue outside our office (bottom-right). One of our bars is shown in the bottom center.
One thing we always took care of at NowOnline was to create an environment where having fun was possible and encouraged. For example, there was always a video game console nearby. After lunch, people would frequently crash down on couches and bags to play Grand Theft Auto, Unreal Tournament or other games. The company invested in an excellent espresso machine and a stocked bar as a centerpiece of the office. People trained each other in how to make good espressos and cappuccinos, often gathering around the bar to chat about work and other things. With the bar being close to the entrance, visitors (such as customers and users) joined the social chat upon arrival. Lunch was also shared. Every Friday, most of the team stayed around for drinks and snacks at the bar. The founder of NowOnline — Thiery Ketz — played a pivotal and enabling role here, valuing personal connections, empathy and the social aspects of work.
2. Continuous [everything]
Way back in 2003, I set up the first continuous integration server at NowOnline. Using CruiseControl with some hefty ANT-scripts, and connected to a red and a green lava lamp, it was easier to tell if our code was still compiling after a commit. Not much later, we started using Visual Studio’s ‘Web Deploy’ to simplify a push to staging or production. The purpose was always to get feedback (does it work? does it deploy?) sooner.
Over time, we extended and improved our tooling to continuously integrate, test and deploy our software. We used TeamCity and AppHarbor for a while but eventually settled on a combination of AppVeyor and Octopus Deploy. The entire deployment pipeline was set up and maintained by the Development Teams, and included the servers behind them. If we thought we could benefit from another tool, we could buy it.
There was a strong understanding among developers that automation was a good way to neutralize excuses to not do something that we knew was important, like running tests or deploying to production more frequently. One of our larger products was so complex that deployment was often done late at night on low-use evenings, usually taking between 2 and 3 hours and requiring the Development Teams to stay up late. Obviously, the release rate was low for this product. But once automated, a new build was released every Sprint (sometimes multiple times). This drive to automate, and refactor codebases to allow it, was always championed by Development Teams.
An early version of our uptime monitor, showing the status of the various API’s, endpoints and services. The monitor would perform various checks, like SSL expiration, uptime and response time.
Finally, we had a lot of fun creating additional tools to show what was happening with our products. One of those was an uptime monitor that pinged and tested the various endpoints every couple of minutes. Another was a buildmonitor that showed recent builds & deployments. Or a live logging console that showed traffic and events on all our servers. Because our “developer floor” was open, we positioned monitors in a central spot so that everyone could see (or hear) what was happening. Most of these tools were created and improved in the evenings, during weekends on Friday-afternoons.
3. Create an environment where you can take risks
At NowOnline, we made sure to create an environment where people could take risks. Writing code is often difficult and risky, especially when you try to refactor dense, convoluted code or when you try to automate something.
Most of our products required complex calculations to determine how much money to invoice to clients of our customer or to pay out to flex workers. Products also had to conform to regulations set out by law and unions. Having a large battery of automated tests made it easier to refactor or change these calculations. If we didn’t have any, we would start with high-level calculations to verify if the output was what we would expect based on the input and the calculations. Several people in our teams were quite adept at creating and verifying these calculations, and writing the automated tests for them (with Specflow).
Scrum also allowed us to take calculated risks. For example, one of our products allowed flex workers to track their hours and send them in for approval (and payment). Based on feedback from users, we used one Sprint to develop an improved user experience for filling in hours (note: this was the Sprint Goal). We offered the new version as an option for users, keeping track of who switched back to the old version and why. This allowed us to learn more about how people used the software and what they liked.
4. Make your work transparent
Inspired by the concept of stigmergy — or how we need to surround our environment with visual traces of work done and to be done — we always tried to keep our work as transparent and physical as possible. We had several movable whiteboards that we carried with us to wherever they were needed. When we worked with customers to refine the Product Backlog, we did so physically on a wall. On the way out, people updated their happiness for that day on a small whiteboard near the door.
Some of the things we made transparent in our work environment
Although we often used JIRA to track work done during a Sprint, and sometimes moved Product Backlogs in there as well, I always preferred the visual, transparent approach of being surrounded by stickies. Writing down something in a sticky and putting in on a wall near you always seems to leave a stronger trace in your memory of what you wrote and what the conversation was about then when you enter it into JIRA.
5. Developer Hygiene
At the peak of my work at NowOnline, we had three Scrum Teams consisting of around 15 developers. With most of our products being mission-critical, there was a strong emphasis on writing clean code and applying practices from Extreme Programming.
Although all developers cared about writing good code, some of us emphasized this more strongly. These developers — perhaps only three or four — developed a natural leadership by using a positive, optimistic style where they practiced the behavior they were they were going for. One of the developers frequently invited others to “pair up” with him to write a feature, swapping the keyboard around and sharing coffee when things started working. Another developer took pride in carefully checking the quality of code and offering feedback to others (usually constructive, though not always). And yet another happily removed commented code wherever he could find, knowing full well that version-control would keep track of those blocks anyways. Generally speaking, we all subscribed to the “Boyscout rule”; the idea to leave any code you touch behind in a better state than you found it in.
A Daily Scrum taking place (top left), a developer pairing up with a designer (top right), creating the Product Backlog together (bottom left) and knowledge-sharing sessions and retrospectives taking place.
Several things helped create awareness of what constitutes good code. The first was that we spent time reading books about craftsmanship together. For example, we organized several sessions about the book “Clean Code” (by Robert C. Martin). Several developers prepared a session on one of the chapters from the book, sharing what they learned and discussing the chapter. Another thing that helped was that some of us continuously refactored existing pieces of code as we went through implementing new features, and then happily showed it to others to demonstrate how much cleaner the new code was. This was spurred on by the increased understanding of when and how to apply design patterns (like singleton, strategy, factory, mediator, facade, builder etc) as we worked our way through important patterns from the famous, difficult book from the Gang of Four on Design Patterns, much like we did with “Clean Code”.
When we deployed a breaking bug or when the software crashed, our phones would ring.
Most crucially, I think, was that the Scrum Teams took care of supporting the products they built. When we deployed a breaking bug or when the software crashed, our phones would ring. This included products that were in active use 24 hours a day. We’ve spent several nights (using WhatsApp and telephone to communicate) debugging breaking issues on production. This incentivized the teams to test thoroughly before deploying. But it also encouraged us to automate as much as possible, making it easy to deploy a hotfix.
6. Learning new things together
Learning new things together is one of the hallmarks of a good developer culture. One way we did this was by always having two or three interns at the company. Although interns often had to work on special assignments for school, we made sure they were an active part of one of the Development Teams. They would help with testing or pair up with different developers. With few exceptions, all interns wanted to (and often stayed to) work for NowOnline. It was a good source of new members for our teams and a good way to embed our developer culture in them from the very start.
An impression of some of our Tech Talks. Most of them hosted by developers or interns from NowOnline / HROffice, others by guests such as Wim Heemskerk, Bert Willems, and Gunther Verheyen. The agenda of upcoming Tech Talks is shown in the middle.
We also organized weekly “Tech Talks” where one developer or a special guest would cover a specific topic. I frequently brought in guests from companies we worked with or people I’d met. But more often than not, people from NowOnline would share a new design pattern, a book or show some of the code they’d been working on. Although the focus was mostly on technology, we also covered communication styles, how to give feedback, conflict resolution and how to work effectively with customers.
7. Engaged directly with users and customers
I believe that a good developer is someone who takes joy in solving problems for users (with code). You can’t do this if you never talk to users. Since the very start of NowOnline, the founder always made sure to bring developers with him to customers. This gave a face to the person expressing the needs on the Product Backlog and allowed developers to better understand their context.
One of our developers pairs up with an employee from StartPeople to see how they use our product in their day-to-day work. Not visible in the picture, are six other pairs.
We continued with this approach as the company (and our customers) grew in size. Often, developers would participate in sales meetings or travel with the founder or Product Owner to customer sites. On several occasions, we visited customer sites with the entire Development Team. This allowed us to better understand how people used our products. We often split up and paired with actual users, seeing and learning from their use of the product. On the ride back we shared observations and improvements. On one occasion, we observed how users would often use our software while on the phone. This meant that they ended up looking at information on their screen at an angle. We had received complaints about the small font size before, but always discarded it as a ‘nice to have’, but when we observed difficult the angle made it to read the screen and how often this happened, we fixed it that very evening.
Results from a retrospective on how to increase the quality of our products and what we could measure to keep track of that
Another example was how we frequently reflected on the quality of our products and services as a whole, with everyone who wanted to participate. The founder was always open about financial challenges and opportunities and what was happening strategically.
8. Shared identity and history
The picture wall in one of the earlier offices. In one of the pictures, I can be seen ‘wearing’ a fluffy orange octopus. This was the ‘octopus hat of shame’ for when someone broke the build — which I did on occasion.
Being a fairly small company, there was always a strong connection to the history and identity of NowOnline.
One example of that history is a picture wall of team activities, former employees and memories to keep around. In the most recent office, this wall lines the stairs leading up to the “developer floor”. When new employees or interns started, this always resulted in nice conversations and recollections.
Over the years, NowOnline moved to a new office several times. Each time, everyone was involved in moving to the new location, painting and decorating the place. This made the office itself a collaborative effort and increased the sense of shared ownership. We frequently spent a day together at least each year to purposefully clean up the office, throw away old things and freshen up the place.
Not perfect, but an awesome experience
What we did at NowOnline was really cool. I enjoyed my time there tremendously, as I know others did as well. It certainly wasn’t perfect. We once spent a year building a really cool product that turned out to be a bit of a dud upon release. Although we used something that looked like Scrum, it wasn’t as empirical as it should’ve been. Over the years, we struggled to balance the many products we developed with our small teams. It was quite stressful at times. I’ve spent many evenings writing code. Not because anyone forced me to, but because I was committed to solving user problems. This is also the flipside of a strong “Developer Culture”; it can be intoxicating and unhealthy if you don’t have the discipline to reign it in.
The reason why I left had nothing to do with any of that though. I left after ten years of building this company with its founder, Thiery. It was time for me to move on and create space for myself and others. My focus shifted towards Scrum, Scrum Masters and Liberating Structures. But the more Development Teams I meet, the more I realize how fortunate I am to know what is possible when you have an awesome Development Team. I wish this for every developer out there.
