#NoBigProcesses — An Example Would Come in Handy Right About Now
Previously in the #NoBigProcesses series, we identified how to start when building out a process customized for your group. Now, let’s explore some examples of how this approach has been applied in real businesses.
Brian Marick is one of the authors of the Agile Manifesto, and contributed heavily to what became the Agile community. In the many discussions on the mailing lists and Ward Cunningham’s original wiki, Brian would inject a bit of reality when a conversation strayed too far into the realm of the theoretical. His catchphrase was, “An example would be handy right about now”. I can’t count the number of times this happened, or the number of people who still use the phrase as a result, but Brian was an expert at “keeping it real” and helping us ground our thoughts in actual practice.
With that in mind, I’m going to present some examples of organizations which built out processes based not on paring down something large but rather by building out from next to nothing only when necessary.
Example 1 — The Genesis of Extreme Programming
While this isn’t specifically an example of an organization building a process out from nothing, it does represent the same thought process.
In 1996, Kent Beck was retained by the Chrysler Corporation to help perform some performance tuning of a payroll project that was using an object-oriented approach with Smalltalk. After reviewing the system and the progress in delivering it, Kent advised Chrysler’s management that the existing project was in terrible condition and no “tuning” would help. Instead it needed to be restarted from scratch.
Chrysler’s CIO at the time, Sue Unger, accepted that conclusion with the caveat that Kent had to lead the team that would perform the rewrite. She did, however, assign one of Chrysler’s best teams to the effort.
Kent reflected on the work that he had been doing over the previous years for inspiration on how to coach this new team for the Chrysler Comprehensive Compensation (C3) system. He drew on experiences while working with Ward Cunningham (the inventor of the original WikiWikiWeb), and his collaboration with people involved in the Design Patterns world.
Kent decided to leverage the practices and patterns he had used and observed previously with which he had had success. The key difference was that he decided to “turn the knobs up to 11” (in homage to Spinal Tap) for all the key practices.
For example, if working closely with the Customer was good, then that “knob” was turned up to 11… the Customer sat with the team, or team with the Customer. If collaboration within the team was good, then crank that to 11! The team sits together in the same space. If close collaboration with your peers works well, up to 11 with it! Pair programming is born. If testing your code is good, then not only will we test all the time, we’ll write tests before we even write the code!
[The practices] had been drawn from the experiences of those original practitioners and honed through reflection into what worked best for them
When I spoke to groups about Extreme Programming back in the early 2000s, almost every time someone would say, “But none of these practices are new!” That was absolutely true, because they had been drawn from the experiences of those original practitioners and honed through reflection into what worked best for them.
The C3 team’s practices evolved constantly via reflection from the initiation of the project in 1996 until the project ended in 2000. That team’s approach and practices were codified in the book, Extreme Programming Explained, released in 1999. Extreme Programming continued to evolve afterwards as more and more practitioners discovered different and better ways to achieve the desired results in many different domains.
Extreme Programming originated with a small set of “things that had worked”. It evolved by having the team reflect often about how they were working, and what was helping them and what was hindering. XP was based on shipping something, then reflecting in order to improve.
In February 2001, the Agile Manifesto was written, with 5 out of the 17 authors having either been on that original C3 team or had done work with them that influenced their process. The Manifesto starts with the following statement:
We are uncovering better ways of developing software by doing it and helping others do it.
“Agile” as an approach to delivering software, therefore, is fundamentally based on shipping something and reflecting
Example 2 — Shopify
In 2004, Tobi Lütke had a problem. He, Scott Lake and Daniel Weinand had decided to build an online store called Snowdevils to sell snowboards and related equipment. However, when Tobi explored using existing software as a service (SAAS) solutions, he couldn’t find a single one that wasn’t difficult to use, of crappy quality, or both. So, like many software developers before him, he decided to build the solution for Snowdevils from scratch.
He started by using the web development framework, Ruby on Rails, which itself was in its infancy. As the Snowdevils store was being built, Tobi, Scott & Daniel realized that they could extract the core functionality of Snowdevils’ platform into a product that would allow other merchants to build their own online stores. The primary goal was to make it as easy as possible for someone to get their store online. With that decision, Shopify was born.
When they started, the 3 founders worked together in a coffee shop. They built the Snowdevils store in a few months, and then shifted their focus to building out the platform that became Shopify. Because their team was so small and they sat together while building it, they didn’t need much with respect to a process. Their guiding principles were “GSD” (Get Shit Done) and “Don’t solve problems we don’t have yet”.
Once they released the Shopify platform and merchants began to sign on, the company experienced rapid growth, doubling in size every year. Of course, this necessitated renting office space to hold the growing staff. Each move included significant, deliberate thought on how people would collaborate in the company, since they wanted to retain the high fidelity communication they had with 3 people sitting together in the coffee shop!
Similarly, as the organization grew they put a lot of thought into the structure of the teams building the platform. When I visited them in late 2011, each team typically had 2 or 3 developers and 1 designer. This was a team composition that had evolved over time and worked well for them. One important characteristic to note here is that each team had its own design person, meaning there wasn’t a back & forth over people being shared across teams.
No two teams used the same approach. This, in my mind, is a true representation of agility!
From the perspective of their process, from my initial visit in 2011 to when I actually joined the company in 2012 and to when I left in early 2014, no two teams used the same approach. This, in my mind, is a true representation of agility!
What existed (and still exists today) in place of any formal process is a culture that relies on:
- The original guiding principles of GSD and “Don’t solve problems we don’t have yet”;
- Common practices across the organization, such as the use of Github and the Pull Request approach of Github Flow as well as a cohesive set of Ruby on Rails idioms to be followed;
- Informal communication and collaboration instead of formal process.
While this approach wasn’t perfect, it was certainly effective! Shopify has done nothing but grow and is now over 5000 employees, greater than $1B USD in revenue annually, and has surpassed eBay to become second only to Amazon as the largest eCommerce platform in the US.
Example 3 — You.i TV Roku/Cloud Platform Team
Youi.tv is another Ottawa-based company like Shopify. It was founded on the idea that the rich user experiences we see in video games should be available to consumers everywhere! Over time the company’s purpose morphed into providing that rich experience specifically to video applications on any platform that supports streaming. This was driven by the advent of smartphones, TV streaming boxes and smart televisions as well as the recognition of the importance of those platforms by media companies.
I was involved with You.i as a manager of their core SDK team, which handled code that could be deployed to 14 different platforms at the time (2015), from iOS and Android devices to gaming platforms such as Playstation and XBox and more. This core allowed their product to use the same application code and user interface on all of these platforms with minimal differences to accommodate screen dimensions and specific platform requirements.
There was one glaring omission in the platform support, though. Many clients were asking for their applications on Roku devices, due to the popularity of that platform. Roku, however, is an extremely closed platform that allows development only using their proprietary SDK and language called BrightScript. This meant that You.i’s C++ applications couldn’t be directly installed as they are on other platforms.
The company’s R&D team discovered an obscure Roku feature that could possibly be used to allow us to remotely create a “scene” and then send it to the Roku device to be rendered. They created a barely functional proof of concept, which I inherited as leader of the newly minted Roku/Cloud Team! I was told to make it work for real, and get it on “the Cloud”. I should note that there were people at Roku who didn’t believe we’d be able to build something that would meet their certification criteria. There were also those at You.i who had their doubts as well!
Given the experimental nature of the work, the team was needed a completely different approach than any other group at the company. Literally every day for the first few months consisted of one experiment after another as we fleshed out more functionality. As a result, it was impossible to estimate any of the work, and the pace of prior work couldn’t reliably be used as an indicator of how long future work would take.
So, we effectively began with no process at all. We had a list of “stuff to do” and some rough idea of how to do it. One thing we did, and did well, was collaborate. We sat together in the same area and were constantly bouncing questions and ideas off of each other.
As we built a better defined and more representative proof of concept application, we began to understand more about what we needed to do. We held retrospectives to understand better how we needed to work together, amplifying the positive and working to improve the negative.
We were then presented with the challenge of shipping the first “real-world” app for one of You.i’s clients. The app had already been built and delivered on several other platforms, so it was something of a known quantity in the company. As such, early on I was asked for an overall, ballpark, back of the napkin, insert-euphemism-for-wild-ass-guess-here estimate for how long this effort would take. I simply said that I had no idea due to the still experimental nature of the work. We knew far more than we did a few months earlier, but we were still in the realm of “if we can do this” and not “when we can do this”.
While that answer created significant consternation among many people in the company, the carrot I dangled in front of them was ridiculous transparency. In short, I promised:
- Twice weekly demos internally, once weekly with the client;
- Anyone from the company could attend our daily standup;
- Access to our Trello board* containing the work was given to everyone in the company.
* The team decided to use Trello instead of a physical card wall. Although I was the manager, I wasn’t going to dictate a solution for that!
The first internal demo showed some basic working software. The first demo for the client showed a bit more. During that session with the client, I asked the main customer what he wanted to see next in terms of functionality. He responded and we set about working on that.
We continued this approach, building out the app towards the full functionality seen on other platforms. Over time, we dropped one of the internal demos because no one attended them anymore. We had built enough trust within the company that they believed that we were on the right track. We also changed the weekly client demos to weekly drops of the app so that they were able to play with it and provide feedback.
When the time came to go live with the app, we first had to submit it to Roku for certification testing. We had given them a “pre-certification” version to review in order to determine if there were any real show-stopping issues. The feedback was almost all positive, and we had convinced the naysayers that our approach was indeed viable. The actual certification process went smoothly, and the app went live.
All of that was completed without sprints, backlog grooming, sprint planning, task breakdowns, release planning beyond discussing with the client what the minimum set of functionality should be. Our process had been pared down to “ship something, and reflect on how we shipped”. It was light enough to stay out of the way of getting work done, but had enough meat to provide real benefit to the team and the company.
In each of these examples, groups started with little or no process and only evolved beyond the bare minimum when it was obvious that more was needed through the team’s reflection on how they worked. This empirical approach has shown to be far lighter than the opposite of beginning with a full process and removing what is believed to be not necessary.
Don’t go away yet… there’s more to come in the #NoBigProcesses series!
