Today we continue with looking into aspects regarding alignment.
Activities and Interdependencies
There must be alignment in our organisation regarding the work to be done, the wholeness, also including the architecture of the product or service. This is the what to do and when, on all levels in the organisation, but how to solve it is up to the team, the team of teams, etc. We can compare the what and the when with alignment and the how with autonomy, which is used at Spotify [1]; see their alignment and autonomy diagram at 03:06 min, where no one want to be in the bottom right box with low alignment and high autonomy. Unfortunately, too many companies will end up there when they start their agile transformation with independent autonomous teams instead of looking on the whole picture. The high risk with this transformation start of independent parts, is that the autonomous teams indirectly learnt also to be egoistic, which of course never was the meaning, but become a consequence.
A warning can also be put on the box in the Spotify film that all companies aiming for, high alignment and high autonomy, regarding the how. Many scaled agile frameworks interfere with the how by introducing fixed sprint length, takt time, must be Scrum within the team, etc., which means interfering with the teams how and the team of teams how, etc. It is the very high risk of disrespecting our people when their proposals for improvements of the way of working will be neglected even though they know the business best. This is especially cumbersome at a scaled agile transformation, where the old way of working depends on context, but the new way of working suddenly does not need to understand neither context nor business. Of course many people in the organisation react on this and some speak up, but never getting any answers. And reason for lacking answers is because there are no answers when trying to do the impossible; implementing a one size fit all solution, neglecting both context and business.
Regarding the activities, the critical line is always very important so we are prioritising the right activities to do, and have extra margins for them. This is to minimise the risk for a delay, securing a high Flow Efficiency as elaborated on in this series, where this blog post go into details about sprints and their actual low Flow Efficiency, which depends on the thinking that small stories/tasks are good. Also important is to be able to do Value Stream Mapping and remove waste, since it is especially done on the critical line. Remember though, that VSM originates from Lean Production, so be careful in product development so the removal of waste in a team or activity does not affect the wholeness.
As stated above, the critical line is tightly connected to Flow Efficiency, and this blog post digs into the subject about Flow efficiency measurements frequently done in Agile software development. We really need to get these measurements right, so we are not sub-optimising the teams work by mistake, which is the case for the moment, see this blog post for details. The root cause to these measurements are the introduction of WIP limits to try to solve symptoms, which is instead sub-optimising the organisation, where the details can be found here. The reason is that it is impossible to solve symptoms, which can be read in this series of blog posts about problem-solving. Instead we need to get rid of the queues on the Kanban boards and elsewhere in the Agile organisation, which can be found specifically in this blog post where the root causes are found.
We will have interdependencies between the teams when we are working in parallel, so we need to be careful when we are talking about autonomous teams. Sometimes a team with I-competence or T-competence is preferred when solving a particular task, but the interdependencies between the teams need to be planned between no matter their respective x-shape of the teams. Especially T-shaped teams that are working in parallel actually will have new form of interdependencies that an I-shaped team in a traditional organisation does not have (or have very little of), which give queues of activities and will be further elaborated on in this blog post.
Sequential or parallel
Nothing is stated that the alignment needs to be achieved by teams in parallel, it only says if possible, since that is many times better, but not always. Sometimes sequential is better when the tasks are normal routine work. A comparison between production and product development is elaborated on in this blog post, to get a clear understanding of that sequential work, when having fully routinised work, is actually the best. The whole series about sequential or parallel work can be found here.
Incremental
If we see benefits of incrementally making the product, we must do that, so we can get early return of our investment and fast feedback from our customers and users. As stated before in an earlier blog post, a platform with modules in product development is a form of incremental way of working and can be read about in this and this blog posts.
Architecture
When doing the architecture, think about the following:
– try to make the total architecture as some shell at least, to not risk to omit important parts of it. Especially when incrementally making the product, when it is easy to also make the architecture incrementally, which is very risky.
– Remember Conway’s law, so that the architecture and team placement match. And if it does not match, be vigilant.
In tomorrow’s blog post we continue with important aspects regarding the context and also summarise this series of blog posts. C u then.
References:
[1] Spotify’s video about their Culture. Link copied 2018-09-22.
https://vimeo.com/85490944