A Way of Working (WOW) is the way that we approach our work, described using principles, tools and guidelines, developed and refined over many years of experience. Now that we have a definition, let’s take a look at how to establish a Way of Working.
The first thing to do is to make a declaration about your Way of Working (whatever it is). Simply record how your team(s) is working right now. For example, we have a Codebots’ Way of Working that we publish for you to use if you wish. But first, start your own Organisation’s Way of Working. It is an interesting process to ask people questions about the way they work. You will find glaring holes and amazing gems! To do this well, make sure everyone knows what is happening and why. I have seen many coaches fail in organisations because they try to introduce a new methodology without finding out how their people currently work.
The next thing to do is to establish an experimental framework. The idea behind the experimental framework is to allow anyone on your team to propose an experiment to help evolve your way of working. They run the experiment and present the results to your Jedi council. The Jedi council then decides if the results from the experiment warrant a change to the way of working, or are too ambiguous and need further research.
Once you have declared your way of working, established the Jedi council, and set the experimental framework in motion, you have the beginnings of great things! The last ingredient is to incorporate your organisation’s values and/or manifesto. This will serve as the rudder to help steer the ship. Now, it is time to set the Way of Working in motion.
Across the axis of time, you have provided your people with the opportunity to participate and influence this process. It cannot be understated how powerful an effect this can have. In the Agile world, a retrospective is done at the end of each sprint as a way to have the team self-improve. In a similar way, an experimental framework is your self improvement loop that empowers everyone involved. All the best strategies have one.
With your Way of Working, you are free to experiment with concepts from whatever methodology, research, or original ideas which are available. You can look at fixed length sprints from Scrum if you are struggling to get consistency from your team; look at introducing some automation ideas from DevOps if the time between development and deployment is taking too long; look at some of the ideas behind Extreme Programming (XP) to help with higher quality of life for the development team. Or maybe one of your people has something that has never been heard of? How cool would that be. There are so many great ideas out there that could help you right now.
Five steps to your Way of Working
There are five key steps to establish your way of working. The philosophy behind the way of working was outlined above and the 5 key steps are listed here:
- Declare your organisation’s Way of Working
- Establish an experimental framework
- Form a Jedi Council
- Incorporate your organisation’s values and/or manifesto
- Set the Way of Working in motion!
There is a lot of wiggle room inside these steps and it is recommended to have a look at our Way of Working to get some ideas about how to document your own. Some good questions to ask for your organisation’s Way of Working are:
- What is the structure of the development team?
- What software development methodology(s) do you use or adhere to?
- Do you have different types of software projects like greenfield and brownfield?
- How do you scope a software project?
- How do you estimate a software project?
- What software technologies are allowed? Not allowed?
- Is there a preferred software architecture to be used?
- What are the ceremonies or sessions that are run throughout the software project?
- Who is responsible for quality and testing, and at what stages?
- Who is responsible for deployment, and who has to approve the release?
- Who is responsible for support and maintenance?
… and the list goes on and on. You can use these questions as a start but I can assure you will discover a lot more. The Codebots Way of Working can be used as a reference and it is open for you to use as you see fit. We have also published our Experimental Framework and you are welcome to use this one or establish your own. Make sure you have a hypothesis statement and collect data or design experiments to bring evidence to the Jedi Council. For the Jedi Council, strive for diversity on all fronts. The council will fail if it ends up being an echo chamber. The key question you want to ask a candidate for the council is, are you open to change?
Next up is to incorporate your organisation’s values and/or manifesto. This can provide a north star and give you some direction. For example, our values at Codebots can be seen in the following image. One of the things I like most about them is the balance. Being a Star Wars fan, it is a balance in the force where power comes from.
Does your Way of Working have to be Agile?
Agile is awesome and it has made its way into the common language of organisations (and not just in software teams). It is great to see it reach so many people and it is an important part of the software industry history to be knowledgable on. If you have never read it, take a look at the Agile Manifesto. It specifies four values and twelve principles to be Agile. Personally, I really like and respect the sentiment behind it. The signatories of the Agile manifesto put something in motion that was needed at that point in time.
However (and this is a relatively small however), in recent history it seems that something has started to detract away from Agile. In so much that Ron Jeffries, one of the original signatories and co-founder of XP, stated that developers should abandon Agile. He believes Agile has become big business and has lost its way. But in his article, he still believes the original manifesto is the best way he knows to build software. There has also been other great initiatives like the Kanban method, with its roots in a Lean philosophy, that give us signals that Agile is good, but could there be something better?
The Agile manifesto was written in 2001, 19 years ago at the time of this writing. That is almost two decades. I would suggest (and hope) that the software industry has improved since then and possibly, just possibly, some of the values and principles are not as relevant today as they were back then. It is important to acknowledge that in 2001, people were still trying to move away from waterfall methodologies (and some still are).
Here is one example that I am not the biggest fan of: the Agile value of working software over comprehensive documentation. I am totally on board with the idea of releasing working software often. It is the sacrifice of comprehensive documentation that I am not ok with. The loss of knowledge is one of the root causes of legacy systems, and lack of comprehensive documentation is a major contributing factor to knowledge loss. At Codebots, we believe that by minimising the waste associated with legacy systems (both people and technical) we can have a positive impact on the planet. So, is the Agile value of working software over comprehensive documentation contributing to waste? That is a big question and there is very little chance I could scientifically justify this, but my spider sense is telling me something could be there. There is enough in the logic to warrant asking the following question; does your Way of Working have to be Agile?
No, it does not. It is recommended that you incorporate your own organisation’s values and manifesto. If your organisation does not have these, by all means, go ahead and use the Agile manifesto. It has done an amazing amount of good for our industry and is a great starting point. I would say the Codebots Way of Working is rooted in Agile but has evolved to fit our organisation’s values and manifesto, and is more Lean than Agile these days. It is more current to what we are facing here and now, but most importantly, is not static, helping us to be equipped to face the challenges of tomorrow.
Summary
Your organisation currently has a way of working. Some of it is known and could be documented, some of it is unknown and is not recorded. Do you know where to find your organisations way of working? No matter the current state of your way of working, the first step to improving it is to make it official. Declare it as official and put the good, the bad, and the ugly in there. Some of the ugly could be a blank page where no one has an answer for one of your questions. It’s ok to admit that you do not know the answer to something, modern science is founded on this. Once you acknowledge the limitations of your organisation’s knowledge, then you have the foundations for making improvements.
We have learnt a lot of lessons and run many experiments that are already incorporated into the Codebots Way of Working, and we will continue to make improvements and publish new versions as we grow. The next challenge for us is to help you on your journey of way of working self-discovery. We hope that people (like yourself) will be willing to share the results of their experiments so we can all learn together. Where will this take us? We are not sure but we are looking forward to the journey and the challenges that lay ahead.
Part of our manifesto is to help you discover a way of working that works for your organisation. One of our favourite proverbs is; give a person a fish and you feed them for a day, but teach them how to fish and you can feed them for a lifetime. So, I will ask you my favourite question, how can I help? Email me using eban.escott@codebots.com and put in the subject header [WoW].
Written by Eban Escott
Founder of Codebots
Dr Eban Escott received his Doctorate from UQ (2013) in Model-Driven Engineering and his Masters from QUT (2004) in Artificial Intelligence. He is an advocate of using models as first class artefacts in software engineering and creating not just technologies, but methodologies that enhance the quality of life for software engineers.
