This is a question I have been asking myself for a while, and every day I’m a little bit more convinced that a good roadmap it’s key for a team to be self-organized.
First of all you and I might not have the same understanding of what a roadmap is, so before I get into more detail let me share with you what is a roadmap for me.
Roadmap
The roadmap is the tool that shows the outcomes that are valuable for the organization to achieve in some sort of a timeline, you might have quarters in there, or Now, Later, Future, at the end is some sort of mid-term timeline. Those outcomes haven’t been imposed, those outcomes are the result of the work for all people implicated, by implicated I mean people that will be needed in order to achieve them, from developers to anyone else in the organization.
Teams will use it in order to know what they are accountable for achieving and how they know that they are achieving it.
Let’s take as an example a Quarters based roadmap.
If the roadmap is divided into quarters, the roadmap will show a maximum of 3 quarters (from highly detailed in the 1st quarter to low detailed in the 3rd quarter). And teams will deeply inspect and adapt the roadmap at the end of every quarter.
- 1st Quarter: The first one will have information about the Themes, Objectives and Outcomes Key Measures.
- 2nd Quarter: The second one will have information around some potential and solid themes and not yet information on objectives, and no Outcomes Key Measures at all.
- 3rd Quarter: The third one will contain just potential themes.
If you are interested in myself explaining more about what are Themes, Objectives and Outcomes Key Measures, let me know, but is not the main goal of this post to explain it.
None Roadmap Work
The reality of many organizations is that no matter how much you plan, and no matter how many efforts your put on the roadmap it will always be influenced by other areas of the organization, this happens when departments or teams are disconnected and there isn’t anything common to achieve, every department will work on getting their stuff done, and if this means disrupting other teams then they will have to do it.
What I mean with this is that most of the times you will have to deal with it, there is not perfect team with no live incidents, no infrastructure problems, teams without some sort of specialists needed on other areas, all of this is fine, sometimes we just have to live with it, but at least try to make it visible and identify as much as you can recurrent patterns so you organization can somehow tackle them and minimize them.
For instance, if you have a person who is specialist on a specific area, then as an organization you should proactively try to minimize this as much as possible because at the end this person might be slowing down a lot of things because of its dependency.
A Delivery Team and its Roadmap
I don’t think I explained yet properly the title of this post, let’s try to put some examples, imagine that we have a delivery team, the typical team you will find in 99% of the cases in an organization that are trying to have self-organized teams, you’ll have the Product person, you will have software engineer from various levels of experience and also probably just one QA.
The product person: This person should be accountable on bringing the right things to do or problems to solve that will maximize the value of the area where this person has its scope, it’s important that regardless of the size of the scope this person should be able to make all needed decisions, otherwise it will be just a proxy.
Basically, the Product Person has a completely vertical scope of decision making, is not a proxy, and it’s up to this person to make the needed decisions to maximize the value of the area where is accountable.
The product person should own the roadmap, should be who update it, and make it visible for all the rest, all other team members will be also needed when it comes to inspecting and adapting the roadmap, but the owner should be the product person.
Software engineer: is the role in charge and responsible of building the software within the team.
This person will be accountable for the quality of the software that builds, the software engineer is expected to understand what it means to be building software with quality, all the solutions build must be resilient and maintainable.
Will be responsible for the whole life cycle of the software development execution and release to production, it’s responsible for building and testing that the software build meets the quality and functionality expectations.
This person is accountable for the code defects or technical debt that will be introducing in production.
This person is also expected to understand why it’s developing the software that is developing, is expected to be proactive in understanding the business implications and reasons behind any development or bug fix.
Quality Assurance?
I know this might be controversial, but, I think that having teams where there is a lot of focus on practices that foster technical excellence and quality might avoid the need to have a specific person with the QA role in the team, I believe QA can be highly valuable but not for doing 99% manual testing, in my opinion, the industry has changed and a modern software engineer has to understand that his work goes far beyond the “coding”, a software engineer must ensure that whatever that has been build it works and has the needed guarantees in place, such of any automated testing.
To Summarize
Having a delivery team with a strong product person who understands where the team should go in regards of achieving business results, being able to communicate the problems to solve, and being able to generate a roadmap with all this information it’s going to be very important for a team to self organize.
It won’t be enough, a team will need strong technical skills, a software engineer that understands that their responsibility goes much more beyond coding, they will have to be willing to mentor people with less experience, they will have to be willing to deliver great software with quality, and very important, they will have to accept that whatever that goes into a commit no one else will have a look, they have chances before that happens of course, pair programming, etc… but once is committed then will be its responsibility if make other things to break or if does not work at the expected levels of performance, etc.
If those things happen, the team should be reflecting even every day about the things they do and how they are connected to the roadmap, a team 99% of times should not have the need for external people to interfere and tell them what to do, they should understand what they are supposed to be achieving (roadmap), so they can think and design solutions for it (continuously).
I go even beyond, if you have a healthy and visible roadmap with a strong product person and a high level of technical skills then you might not even need sprint plannings or similar, you might acquire the continuous delivery mode, basically working continuously on achieving what is represented on the roadmap, and updating it whenever needed, if things happen that affect the direction of the team then it should be updated with all involved people.
