#NoBigProcesses — So Where Do I Start?
So far in the #NoBigProcesses series, we’ve focused on the case for minimizing process, the two key activities behind successfully delivering software, and what to do when you believe you need to add something to your process. This post takes a step back to look at how you can start from the absolute minimum, and what guides to follow when building the simplest process for your group.
Something I’ve learned in my software career is that there aren’t many problems we face that haven’t already been solved by someone else in some way. I’ve found it quite effective to look to how others have solved similar problems in the past, but to ensure that I view those solutions through the lens of modern software delivery approaches.
In other words, learn from the past but get with the times!
Learn from the past!
Despite being written in 2001 when a good portion of internet users still used dialup connections, the original Agile Manifesto of early 2001 was pretty good. I had already become involved in the Extreme Programming community by then, as the ethos of lightweight processes resonated with me. While, by today’s standards, the group that authored the Manifesto wasn’t diverse in any way, they still managed to articulate a common vision not just for the huge processes they were against, but for what represented the best of the various lightweight methods they used.
I’ve encountered people who have written off the Agile Manifesto as fluff, but I believe it has stood the test of time rather well when viewed in the context of delivering software. For those reading this who weren’t actively part of the software development world in 2001, getting software shipped was a big deal! There have been arguments since then that the original Manifesto isn’t enough since the software delivery aspect isn’t enough, and that’s a fair statement. I still encounter organizations, though, that struggle to deliver high-quality software in a timely manner. As such, I still believe it has an important role to play today.
Get with the times!
Modern Agile was created by Joshua Kerievsky of Industrial Logic in 2015 as a refinement of the Agile Manifesto’s original values, updated for today’s software world. Josh, in collaboration with others at Industrial Logic, incorporated over 15 years of real-world experience of training and coaching teams around the globe in agile methods.
The primary focus of Modern Agile is to create an environment that allows agility to occur naturally. This is a fundamentally different approach than simply installing some practices and expecting amazing thing to happen! While that can happen (which I’ve seen), it’s much more likely that a group will reap the benefits of agility when their work environment has been changed in ways that enable people to do their best work without fear of failure. As I mentioned in “#NoBigProcesses — Introduction”, Alistair Cockburn specifically called out that most contemporary processes treat people as “resources” that don’t vary. The truth, of course, is nothing like that and Modern Agile embraces the notion that motivated people are core to being successful.
The four guiding principles of Modern Agile represent a fantastic approach to identify how a group could begin with no process at all and add effective practices when they feel “pain”.
Make People Awesome
In #NoBigProcesses — Two Key Activities, I listed a number of questions the group could ask themselves after shipping in order to help make themselves and their work more effective. A number of those questions would fall under the category of making people awesome!
Those “people” can be the actual users of your software, the stakeholders in your organization, the people on your team… anyone who is directly or indirectly affected by the work.
Make Safety a Prerequisite
A group that’s afraid to make a mistake won’t be terribly motivated to try anything new that might cause issues, and I’ve seen this numerous times while coaching. One product group in particular stands out, in that they didn’t want to start using automated unit tests in case it slowed them down and they couldn’t deliver everything they promised in a sprint. When I dug deeper into the issue, I discovered that the group had been through 10 rounds of layoffs over a period of 8 years. They simply didn’t feel safe in their environment as it was, and despite the value that automated tests could provide, the added stress of being on a team that didn’t complete all their work wasn’t worth it to them.
By making safety fundamental to their environment, your people can embrace new practices that may initially slow them down, but that investment of time makes them more effective in the long run. Similarly, people who believe that they can safely ask questions about the decisions being made around their group will feel more ownership and express more pride in what they do.
Finally, safety enables the ability to Experiment and Learn Rapidly!
Experiment and Learn Rapidly
In #NoBigProcesses — It Needs a Little Something, I wrote specifically about experimenting with your process when adding new activities. Modern Agile embraces that approach when building systems by viewing the work as set of experiments that are quickly run and validated. By having an environment in which it’s safe for an experiment to fail, people are motivated to try innovative approaches that would not be palatable otherwise. They may find ways to avoid having to build anything at all, or even remove features!
In the context of building a process, this approach is critical to finding what’s most effective for your particular for your group, in your business domain, with your technical environment.
Deliver Value Continuously
Modern Agile’s view of Ship Something is based on the premise that work not shipped isn’t satisfying the other 3 principles. If it hasn’t shipped, it isn’t making anyone awesome, it isn’t making anyone more safe, and you haven’t learned anything from it yet because it hasn’t been shipped.
This is why Ship Something is so fundamental to successful software delivery. Note that both the original Agile Manifesto and Modern Agile call it out directly. So, if you don’t believe me, there are a good number of other people who do!
Be principled!
While the Manifesto’s 4 values are reasonably well known, there are also 12 principles based on those values that are just as important. In fact, one could argue that the principles may be more important because they’re less abstract than the values. Let’s dig into them a bit deeper to round out how you can start with #NoBigProcesses.
We can leverage these principles to help guide us on a journey towards using as little process as possible, but just enough to ensure that our group is effective.
Let’s consider, for example, the very first principle from the Agile Manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”
That sounds familiar, doesn’t it. Ship something.
Then you have the last principle: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”
Reflect on how you shipped in order to improve.
Those principles very nicely bookend the message that shipping and reflecting are the most fundamental activities in delivering software successfully. The other principles provide guidance on how to perform those activities.
For example, the 5th principle:
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”
Creating an environment that fosters motivation will absolutely help you ship software more effectively!
Also, the 11th Principle:
“The best architectures, requirements, and designs emerge from self-organizing teams”
This is a direct shot at the large processes of the 1990s which often had separate teams for each of architecture, requirements and design. Indeed, I still see that issue today! There is effectively no value from having different teams perform that work, and I would suggest (based on my experience) that doing so is a relatively good indicator that a project or product will be challenged at best.
When your group is considering changes to their process, the Agile Manifesto’s principles and those of Modern Agile provide superb guidance to your thought process. They’re both excellent resources on their own for ways to improve how a group works, and in the context of #NoBigProcesses they represent high quality references to generate ideas that work in your context.
Next in the #NoBigProcesses series is, “An Example Would Come In Handy Right About Now”.
