5 Agility Transformation Topics

It was a good week for thoughts, insights, and key transformation insights from reflections, from podcasts, and from discussions with some very smart people inside and outside my place of work across the industry. Here are my very short summaries the five key topics from this week ...

1. Working with service providers when shifting to agile/devops ways of working

For most software organizations (which pretty much all are), working with IT service providers is often inevitable. Generally two main models include (a) outsourcing an entire solution creation as one big contract. Or (b) staff augmentation, i.e. bringing in contractors from the vendor to work in your system, your operating model, your agile ways of of working, and your control. There are other variations on (a) and (b) and each can be used in parts of an org based on the best fit. We all know the worst possible model is functional outsourcing (e.g. outsource testing separate from development, or product strategy separate from execution). Option (b) is recommended if an organization wants to maintain intellectual property and if they want to continuously improve their ways of working for improved agility and sooner time to value. Given the criticality of an organization owning, integrating, and continuously improving their own system of work, outsourcing a portion of that is wrought with risk and extreme ineffectiveness. The more decoupled the organization and the architecture are, not only the more efficient and effective they will be but the more flexibility there is to effectively mix and match the outsourcing models.

Related to this is the build vs. buy dilemma. The best description of this I've seen is chapter 8 of Mark Schwartz's great book, "Seat at the Table". Anyone considering buy over build should absolutely read that chapter.

2. Conway's law looms large in all organizations

Speaking of decoupling, regardless of how outsourcing is done, or if at all, Conway's Law ("organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations") must not only be respected but must be actively managed. Specifically, your system architecture and your organization architecture are tightly interdependent with two-way cause and effects between them. They both must be created and evolved with each other in mind. Both must be designed and improved for reduced dependencies (break dependencies rather than manage them) and optimized for encapsulation over orchestration. In other words, evolve the systems architectures to be increasingly loosely coupled such that teams can own end-to-end outcomes of solutions without needing excessive coordination with other teams.

Teams who try increase business agility by adopting agile ways of working have difficulty achieving ‘sooner value’ improvements without also optimizing and decoupling both organizational and technical architecture and addressing alignment between them.

3. Working in the system vs. working on the system

Many organizations neglect to work 'on the system' and focus solely at working 'in the system'. Some examples: (1)working to deliver features without allocating time to identify and experiment with addressing top bottlenecks to delivering sooner value, (2) work as part of a product or value stream team without focusing on experiments to delivering smaller pieces of value, more rapidly identifying and checking against leading indicators and creating shorter, faster feedback loops, or (3) as a leader, being too busy managing the work, addressing action items and attending meetings without looking to measure and improve the system

4. Theory AND practice

Just as it is unwise to have theory without practice, it is also unwise to have practice without theory. Without both, real improvement is rare. With theory only, absent of specific practice and examples, you've got an academic ivory tower of untested ideas without specific context. With practice only, minus theory, it is difficult to understand the why the practice works and believe in the change, and it's difficult for the team to improvise and make adjustments to achieve the desired outcome.

For example, doing scrum practices with the ceremonies, sprints, standups, etc. without understanding the theory why we do this, teams can go through the motions without results. For instance, when we strive to create working, tested software every two weeks that is potentially shippable, we are able to show customers and/or stakeholders and we can get feedback to make adjustments. We can understand if we are on the right track to achieving the desired value. We are in better position also to have leading indicators as to when the solution will be done. We can make adjustments based on what we learn early on in order to achieve outcome sooner. Going through the motions of agile ceremonies without the theory and the 'why' can be extremely limited.

5. Limitations of velocity and story points

Many teams focus on velocity and story points as their core measures. This is a mistake. These measures have their place, such as within a team to help them get consistently estimate and predict progress against a backlog within a sprint. But beyond that, they are dangerous to use to compare teams. Additionally, velocity measures are often misused, as they mostly measure activity and output rather than value or outcomes, especially without disciplined definitions of done that include testing or when work floats from sprint to sprint. If velocity is used, it should never be the sole measure. Teams should instead have a set of balanced, complimentary measures especially focused on throughput (e.g. lead/cycle times) and ideally include outcomes and quality. In all cases the measures should be owned by the team as means of improvement and feedback loops, not as targets under scrutiny of leaders.