In the context of knowledge work and software & digital products development, the rule of thumb is to share all the responsibilities inside a multi-disciplinary team that has all the skills and authority to autonomously do all the work from the concept to when the finished work lands into the hands of the final users, and later for operating, supporting, maintaining and evolving the related product. Therefore, all the responsibilities should remain inside the team.
Traditionally, in industrial mass production, the rule of thumb goes toward a different direction, the direction of specialisation, work divisionalisation in separate functions, outsourcing, commoditization, standardisation, and economies of scale.
Even in knowledge work and software & digital products development, there can also be situations where:
One way to stick to the rule of thumb under these circumstances is to follow an extreme and continuous knowledge & responsibilities sharing. As described in Transcending Cross-team collaboration with shared work.
There are situations tho’ when it may be convenient or easier to go beyond the rule of thumb. See an example inspired by Team Topologies here: Agile cross-team collaboration How-Tos.
For these situations, we really need to understand when, what, and how to effectively move some tasks and/or responsibilities outside the team. For example, delegating them to a Subject Matter Expert, an external contractor, an Agency, a global/shared function, a Team Topologies’ Platform or Complicated subsystem team.
When the work or cognitive load exceed the team capacity or there is a need for a very specialistic knowledge/skillset, or a service/product/component has reached a level of maturity allowing for reuse, the options of moving the related tasks/responsibilities outside the team should be considered only in ways that make such option beneficial and advantageous compared to the status quo.
Below are some general criteria that can help to find ways to ensure that.
This means that moving the task/responsibility outside the team, delegating it, and getting the work done back, should not add more work or cognitive load than doing the work directly inside the team.
For each of such tasks/responsibilities then:
– making an external request for getting the work done should be orders of magnitude simpler than explaining to others how the work should be done, or just asking to get it done,
– the “interface” and “protocol” to ask for each task/responsibility to get done should be simple like it was a black box, therefore should not require knowing or understanding any “internals”.
This requires a clear “separation of concerns” between tasks and responsibilities and knowledge/skills remaining inside the team and those moved outside the team.
Moving a task/responsibility outside the team should not add dependencies other than to that task/responsibility, for example, a dependency of the team on:
– an individual or a knowledge that is not more inside the team,
– a technical dependency on source code, infrastructure, tools or other tech moved outside the team,
– any other resource dependency,
– access and/or authority that has moved outside the team and is not available in the team anymore.
Any of these dependencies would require additional collaboration, coordination and planning that go well beyond what is needed for the tasks/responsibilities moved out, and would typically introduce additional rigidities, complexities and costs that exceed the other expected benefits.
Those taking care of the tasks/responsibilities moved outside the team, must have enough capacity to do the required work without adding delays to the team and without becoming a bottleneck.
The “interface” and “protocol” the team uses to request and obtain the service must remain stable instead of changing over time adding extra work to the team at every request.
The requests must be carried out without the need to change/modify/adapt the “internals” of the service provided overloading the external person or team (especially when they are serving multiple clients) and adding work also to the team, overall causing further delays and adding more complexity.
When it is feasible, the service itself should be automated allowing for self-procurement therefore avoiding all the potential problems just mentioned. Common examples include cloud environment procurement, code integration, final system testing, and deployment.
(Part 1) Part 2 >>
PART ONE
See also the previous post describing how to make Agile cross-team collaboration frictionless and enjoyable or in one word effective: Agile Cross-Team Collaboration How-Tos.
My gratitude goes to Bas Vodde (co-author of Scaling Lean & Agile Development and Practices for Scaling Lean & Agile Development, and co-creator of LeSS) for engaging in a long and detailed conversation on this topic.
Before Agile went mainstream and the focus on Agile technical practices declined, shared work was widespread and very successful. It was adopted commonly by Agile practitioners where the work involved multiple teams.
Chet Hendrickson (co-author of Extreme Programming Installed) points out that:
Since Agile is simple, a scaled version of Agile should also be that simple, or even simpler. Otherwise, it will no longer be Agile ~ Excerpt from The Nature of Software Development, by Ron Jeffries, 2015
The shared work approach, up until now, seems to be the best incarnation of Chet Hendrickson’s statement. What shared work is then?
Shared work can be summed up in two points:
1) Limiting the number of cross-team dependencies by having each team work across all components and disciplines (analysis, programming, testing, …) Therefore each team has all the necessary knowledge and skills to complete an end-to-end customer-centric feature.
2) Transcending any remaining cross-team dependencies by adopting a shared product code ownership where all the teams can work on any part of the product codebase.
On the opposite side of the shared work spectrum, many organisations end up with knowledge silos. They are created, for example, when an individual or a team picks up a novel problem/task, and afterwards all the other similar problems/tasks get assigned to them because they already know how to handle that work. Managers may let this happen because they believe in the efficiencies of specialisation, and a team may let this happen because individual team members may enjoy the feeling of becoming indispensable while others may enjoy remaining inside their comfort zone.
Each knowledge silo tho’ comes with hidden costs such as the creation of a single point of failure and tight constraints on workload distribution and more in general on work prioritisation and planning. To the point that some organisations end up with more managers handling the constraints than those doing the work. In other organisations, the work becomes blocked or delayed most of the time, and people end up multitasking to the point of minimising their productivity.
Since the beginning, Agile has embodied a major departure from this way of thinking about specialisation. It introduced the concept of generalising specialists, also known as T-shaped professionals that add to the depth of their specialisation the breadth of generalist knowledge in areas mostly adjacent to their specialisation.
The Extreme in Extreme Programming (XP) is meant as pushing the boundaries of one practice to the extreme, to find where it stops being effective, discovering most of the time that is far beyond where we thought it would be. Pushing the generalising specialists to the extreme showed that, in combination with Pairing and Mobbing AKA Ensemble, teams and team members can acquire more knowledge, become proficient in a broader set of skills, and be effective in many more areas far beyond where we would normally have believed.
With shared work, learning happens whenever the knowledge or skills needed to complete an end-to-end customer-centric feature are missing, the level of generalisation is lacking, or one specialisation is missing. Learning happens by pairing or mobbing with teammates, doing the work with other teams, or hiring a new team member. The specialists in the team are encouraged to pair and mentor instead of working in isolation. Teams are encouraged to seek opportunities to work together. Most professionals, after having tried this form of continuous social learning-by-doing on-the-job, its effectiveness and its value, usually don’t want to go back.
In conclusion, teams adopting shared work, in addition to being capable of completing an end-to-end customer-centric feature autonomously, usually are:
In the Agile literature, such teams are commonly referred to as Feature Teams.
(Part 1) Part 2 >>
PART ONE
Thanks to those that contributed to this post, reviewed it and made suggestions for improving it:
Jon Kern (co-author of the Agile Manifesto), Matthew Skelton (co-author of Team Topologies), Mark Dalgarno (Agile conferences organiser, Agile professional), Carlo Beschi (Agile professional), Carlo Volpi (Sr Programme Manager), Luca Cicale (Senior Application Architect and Developer).
This post explores why Agile cross-team collaboration is fundamental, why current solutions for cross-team collaboration are flawed, and when Agile cross-team collaboration is really needed. It describes how to pursue good Agile cross-team collaboration. And it concludes arguing whether cross-team collaboration should be embraced or avoided.
Teams and organisations are Human Complex systems where people are the most valuable, adaptable, and essential element. Because of our social nature, the relationships and the interactions between individuals and teams are fundamental. The overall behaviour of such Human Complex systems results from the interplay of the many interactions between people and between teams. Therefore, Agile cross-team collaboration is the single most consequential success factor when pursuing Agility beyond one team and across the organisation.
Let’s take as an example Software development. In Software development, when someone begins to learn how to design a system, they usually start by focusing on the design of the individual objects or functions. They master it.
Then, later, their focus shifts to the most important aspects of the design: the space between objects or functions, their relationships, the messages and information they exchange, their interdependencies, and the way they can be combined.
Similarly, when someone starts learning and adopting Agile, they usually start from the individuals and team and how to make it work well. Then they master it at the team level. Later, the focus shifts to mastering the collaboration across Agile teams, and the intangibles in the space in-between.
See, for example, the general idea here and in particular principle #5:
The current solutions for cross-team collaboration come from the Agile Industry and the scaled frameworks. With the exception of LeSS (that is about de-scaling), they are traditional pre-Agile practices disguised as new, or at best Scrum of Scrums. And none of them works well.
One common solution is the generic 1-size-fits-all Scrum of Scrums. There is much more than Scrum of Scrums that must be considered for a good cross-team collaboration, and at the same time, Scrum of Scrums is too much for what it does. It is, at best, a starting point to be quickly left behind like the starting blocks at the sprint’s start signal.
The other common solution comes from scaled frameworks and some inexperienced Agile practitioners. It boils down to traditional pre-Agile practices disguised as new, that don’t work for today’s Complex problems. These practices boil down to more process, more governance, more roles and hierarchy levels, more upfront top-down planning, more timelines a la Gantt charts, more shared services or centralised functions, or more tools. Not only they are ineffective, wasteful, and lead to very low productivity, but they also hinder the ability of individual teams to work effectively and achieve any degree of Agility.
(Part 1) Part 2 >>
Now imagine that moved by the suffering of those family members indirectly affected by the resulting gambling debts, you start lending them your own money ending up suffering yourself the consequences of the gambling problem you were helping to solve. This would have turned you into a hostage of that person’s gambling problem.
In the past years, I had a few conversations with Scrum Masters and Agile Coaches after they left a job where they have been taken hostage. From it I learned that being taken hostage wasted their time and energy, lowered their confidence, left them mentally exhausted, it did nothing good for their career, but also did nothing good for the teams, departments and the organisation they were supporting. No winner.
Getting out of a hostage situation is not easy at all. Getting out of it well is hard.
Being taken hostage may happen, for example, in organisations that are hostile to the values, principles, and behaviours the Agile professional has been hired to seed and grow. It is something that I and many others have experienced. And below are a few scenarios and reflections from my own experience.
See how we can help.
You, your team, your organisation.
]]>
Gary Hamel is a business thinker. He has been on the faculty of the London Business School for more than 30 years.
In this video Reinventing the Technology of Human Accomplishment (15 mins) he explores the Why and How management and ways of working have evolved and are evolving.
Richard Sheridan is CEO and co-founder of Menlo Innovations and author of Joy, Inc.
In this video Joy, Inc. (20 mins) he talks about the people side of the modern ways of working.
John Seely Brown is a researcher who specializes in organizational studies.
In this video Sense-Making in our Post AlphaGo World (45 mins) he provides a compelling explanation of the dynamics that turn an organisation from a quiet river into whitewater, and what is needed to navigate them.
Stanley McChrystal is a retired United States Army general best known for his command of Joint Special Operations Command (JSOC) in the mid-2000s. Leadership courses teacher and Author of the best seller Team of Teams. On Organizing to Win in a Complex World (56 mins)
David Marquet is a retired United States Navy captain and the author of Turn the Ship Around.
In these short videos #1 Lead with intent (3 mins), #2 The Ladder of Leadership (2 mins), #3 How to Level Up with the Ladder of Leadership (2 mins), he introduces the practice of Intent-based leadership for leaders that want to make their managers/leadership team more proactive and autonomous in solving problems.
And in these two short videos, he articulates the characteristics of the two types of work we usually do at work: Red Work Blue Work (2 mins), Increase The Blue Work (2 mins).
Henrik Kniberg created this short and insightful animation that provides an example of several aspects of Agile ways of working: Agile Product Ownership in a Nutshell (15 mins).
Gary Hamel again: Another insightful video from Gary Hamel is Why (in the context of transformations) Change Management is an Oxymoron (12 mins).
In terms of the books, here are some good suggestions:
– Summer reading list for the (to be) reformed-manager
– Summer reading list for the (to be) reformed leader.
I would add to the list these two books:
Author: Stephen Denning
Title: Radical Management
Author: Stanley Allen McChrystal
Title: Team of Teams
See how we can help.
You, your team, your organisation.
The activities that typically come before the release (new product and/or features development) are considered CapEx, the other activities that typically come after (maintenance, support) are considered OpEx.
While evolving the product (bug fixes, patches, service packs, new minor and major versions) has been a grey area ranging from OpEx to CapEx on a case-by-case basis.
This way of thinking often sees 2 separate software development “project” teams (*):
– one rewarded for quickly creating a new product/features (and new bugs)
– one rewarded for quickly bug fixing, support & maintenance.
Where quickly often can be interpreted as cutting corners.
And where the software development teams are seen as an external function that is subordinate to the business and plays an enabling or supporting role to the business. Outsourcing the teams is pretty common in this space.
Nowadays software and digital products development are released online and frequently updated. They require a constant effort to keep them up to date with the constantly accelerating rate of change of the security threats, the evolution of the tech eco-system they are intertwined with, and the constant evolution of users’ needs, wants, habits and expectations.
While this idea of software ageing is not new (see software ageing) the surface of the ageing (security, libraries, frameworks, services, platforms, business domains and users) and its speed have grown by orders of magnitude, creating a new dynamic that requires a new approach.
Without a new approach of continuous regeneration coming from continuous maintenance and evolution of the software and the product, they would wear out, deteriorate and rot over time, as Giulio Vian has recently pointed out. When this happens, then the software and the digital product needs a form of rejuvenation, as recently pointed out by Uberto Barbini.
This continuous regeneration, which is indistinguishable from new product development, is a capital investment needed to sustain the continuous maintenance and evolution of the product. And this leads to a new approach to transcend the traditional CapEx – Opex separation.
Together with this way of thinking, it is common to see software development Product teams (*) practising DevOps (the real thing, that is a mix of a culture of collaboration across developers and ITOps, automation practices, monitoring and measurement and transparent sharing, not the “DevOps team” theatre). Those teams are taking care of the whole end-to-end life-cycle of the digital product. Here software teams play an essential differentiating role for the business or they are even one and the same with the (digital) business.
Here below an example of how different activities fall in the CapEx or OpEx category:
CapEx
It depends (Middle Earth)
OpEx
Just looking for example at the cloud, its set-up and the design of the solution that employs the cloud, make give us an example of how much design decisions can reduce the CapEx side of that cost (a simplified cloud solution may take less time to be realised and may need less skilled and so cheaper professionals) while increasing the OpEx side (that solution may lead to much higher Cloud bills), or the other way around. Not to mention that the adoption of hybrid cloud infrastructure (using private and public cloud services together) may throw the whole cloud chapter into the Middle Earth.
When someone wants to stop any investment in a product and just wants to keep the lights on, the items in Middle Earth still need to be taken care of, so in a sense they are OpEx.
On the other side when someone wants to continue to invest in a product, without the items in Middle Earth it won’t be possible, so they are also part of the CapEx.
So paradoxically they are both CapEx and OpEx. Or in practical terms at every accounting period, a determination must be made based on what is going on at that time.
Same for the salaries of the product team members that may work both on CapEx and OpEx.
There is no need to track the CapEx and OpEx work at individuals or backlog items level, it is sufficient to sample the backlog, estimate the percentage of the different Items and where they fit in CapEx and OpEx terms and then account for the salary of the whole team in CapEx and OpEx accordingly to those percentages.
Specific accounting regulations, that can typically be late to catch-up with the fast-changing tech world, may apply and may differ from country to country as well as for the type of company (internal software development, embedded software created and used by a product company, a Software house selling software).
Then there are conventions that tend to be even slower to evolve but not mandated by any binding regulation, other than the “we have always done it this way” regulation…
_______________________________
(*) Product over Projects, Projects to Products principles, Journey to Product Teams
See how we can help.
You, your team, your Tech.
What’s the underlying difference?
The 1st instance appears to be a one-off exceptional event that nudged a system out of its stable state. And the fix put it back in place.
The 2nd instance appears to be a status of dynamic equilibrium that require a continuous and ongoing effort.
Nowadays that modern ways of working (Agil-ity) are mainstream, so is its terminology. But people often refer to the same words with very different meanings. Some with the 1st “one-off” instance in mind, someone else with the 2nd “continuous & ongoing” instance in mind.
This is a possible explanation for the persisting confusion and different views around terms like
How do you think about them, as “one-off” or “continuous & ongoing”?
Taking a fun angle, have a look at this Agile Theatre Naming Convention below.
Am I missing something important?
In this image, Theatre is intended as a representation of a fictional reality aimed at hiding the reality itself, and preserving it as it is from any chance of change.
On this topic Ayan Chakraborty shared with me this pertinent quote:
<< What’s in a name? That which we call a rose/ By any other name would smell as sweet. >>
from Romeo & Juliet by Shakespeare.
See how we can help.
You, your team, your organisation.
OKRs are a form of Management by Objectives (MBO) which itself was first popularized in 1954 by Peter Drucker. This leads to an interesting question: can innovation be “managed“?
When one tries to write down the OKRs for the four questions above, the related Objectives would end up being either too generic or too specific.
For example in an Apollo 13 “Houston, we’ve had a problem here” situation, any Objective would inevitably boil down to “Get the crew back safely to Earth.” And how does that generic Objective help to find a working solution to the problem?
Alternatively, the Objective would contain elements of one possible solution, leading to a tunnel vision. Try yourself.
The issue is, how can one define an Objective for opportunities that are still unknown, yet to be discovered or invented? One cannot.
Because most inventions are oblique, unpredictable, emergent, the result of a mistake or of repurposing something novel for a totally different purpose (think microwave ovens, coca-cola, post-it notes, penicillin, gin and tonic, …) instead of being the result of a linear effort to fulfil a predefined Objective.
The solution found for the “Houston, we’ve had a problem here” was to repurpose some of the instrumentation available onboard to achieve an incredible mission. The invention of the car was made possible by the creation of the clutch that allowed standing stars for terrestrial cars. Before that, the internal combustion engine could only be used in outboard boats that in the water did not face that problem.
One way that could work would be to define multiple parallel Objectives representing multiple promising directions of investigation. Yes, but this way would be something different from the OKR technique.
Setting and tracking Key Results for innovation makes things even harder than setting Objectives for innovation.
One way is to set KRs as generic high-level business outcomes and impacts. Those will likely be lagging indicators moving the needle with a long delay after any action. So they will be of no use to inform or drive the innovation. Even more, when an action or experiment fails to deliver the expected KR, that leaves us alone with a blank page to figure out the next experiment, and how to pivot, without suggesting any direction and without giving any indication. The KRs will leave us alone at the exact moment when we need help the most. In this regard, these KRs are useless for innovation, a waste in Lean terms.
An alternative to setting generic high-level KRs is to set KRs that are specific. But how can someone know what to measure and how to measure something that does not exist and has yet to be invented? Even figuring out the unit of measurement would be impossible when one doesn’t know what to measure. That would be like asking how much time it takes to fix a bug, when to answer the question one first needs to find the defect that is causing the bug, and in most cases that already would account for 80÷90% of the time needed to fix the bug.
And even if one magically succeeds in the impossible, predicting the right things to measure in order to drive a specific innovation, KRs have the same problems as any other numeric-objectives system: they tend to get what you measure, not necessarily what you want (e.g. see gaming the metrics), and as the context quickly changes and evolves they quickly become outdated and irrelevant. And otherwise, KRs that change again and again as things change and evolve, once again would be something different from the OKR technique.
Some of the merits of OKRs is to catalyse the conversation around the goals and the vision, to create common understanding and consensus between management and employees, to align objectives across the organization. To shift the conversation from output to outcomes, that has the potential to empower employees.
This sounds great. Is it enough when we are working toward an Agile environment?
OKRs are a form of Management by Objectives (MBO), they are a step forward from a hierarchical-driven organisation, but they still lack the trust and collaborative nature of a people-centred relationship-driven organisation such as in an Agile organisation. This becomes more evident when OKRs are cascaded in a top-dow fashion or when they are connected to individual bonuses and individual performances reviews leading employees to try achieving the set goals by any means necessary, often at the cost of the company.
When OKRs are used for innovation even those merits become fragile. How can an organisation align toward something that does not exist yet? An opportunity that has yet to be discovered? And invention that has yet to be made? And when we try to define the objectives anyway, this brings us back to the first point A from the beginning.
In the end, taking into account all the points above, it is a matter of context. As it is described in the visual at the top.
See how we can help.
You, your team, your organisation.
Automation practices are so important that even when Lean and/or Agile are adopted outside IT, their fundamental benefit cannot be ignored.
Good candidates for automation include standard work, repetitive tasks, and defined processes that occur often, starting from those that are more expensive, require more time and effort, and are more error-prone.
Common examples include various forms of assembling and integrating, testing and reporting, as well as data analysis and monitoring. Also, data collection and integration are good examples (e.g. turning them from manual operations to real-time telemetry).
All the tasks with a high degree of novelty (may involve creating new solutions, designing new things), and in general those that require human creativity and ingenuity, imagination, and intuition, are not good candidates for automation. Nor are those tasks that involve exploring, experimenting, discovering, and guessing.
Also, all the tasks that involve making sense of things collectively, building and reaching consensus and taking decisions, dealing with human beliefs, and dealing with power or emotions, are not good candidates for automation either.
All these tasks deeply involve what I call the human element, and that is why for them a real person needs to be in control, be in the loop, and make the final call.
Step 1 – Documentation
Once a task that is a good candidate for automation is found (usually a repetitive, time-consuming, low-variation task), the first step is to document it for someone else to carry out the task manually, following the documentation.
This will allow someone with limited knowledge or context of the details of the task, to carry out the task anyway. You can think for example about the difference between someone knowing how to create a formula and its proof Vs someone knowing only how to apply a given formula. The latter is all that should be needed to follow the documentation and carry out the task.
The tool used to document the steps should be like a Wiki, a tool that doesn’t make a distinction between the author and the readers, and everyone is an active reader (both author and reader at the same time). Those using the documentation to carry out the task will ask questions to fill the gaps and to clarify any ambiguity in the documentation, and so evolving, updating and improving it.
It is important that this documentation is valuable in itself and it is actually used and useful. This will lead to improving the documentation and will prove that there is a need for help to carry out the task and that the delegation of the task to others actually works. And so a trail of changes to the documentation will be the sign that this first step has been valuable and successful.
Step 2 – Scripting (checklist / flow diagram)
The next step is to streamline the documentation, making the instructions simpler and more straightforward. Eliminating any part that can be subjective. Providing clear unequivocal criteria for every decision that needs to be taken. Bringing down almost to zero the level of interpretation and the judgment calls that the reader needs to make in order to carry out the task. Providing clear instructions also to deal with error conditions that can happen on the way, as well as to deal with variations that there may be in the inputs to the task.
This format of this streamlined documentation is much easier to follow, leaves much less room for error, and requires much less knowledge from the reader. So if it really works, a larger group of people will be able to follow its instructions.
As before, it is important that this documentation is valuable in itself and it is actually used and useful. This will prove that there are not too many variations in the task that make it not a good fit to be automated. And that the instructions to carry out the task have an actual chance to be automated effectively (by an algorithm, a smart robot with physical abilities, or basic cognitive abilities that can be trained into commercially available AI).
Step 3 – The actual automation
After the scripted documentation from the previous step has been proven to work well repeatedly, without tweaks or non-scripted interventions, then it is time for the actual automation.
The process of automation often requires that part of the resources (raw material, or artefacts) used in carrying out the task follow some process of standardisation to reduce variation and make the automation possible and easier.
This step is proof that the automation is actually feasible, that it works well, that is stable and sustainable, and that is beneficial and effective. The automation should be done by those initially responsible for carrying out the task, the experts. Their understanding and knowledge are fundamental in judging the solidity of automation and its sustainability.
Because the work we do and the way we work is in constant evolution, also the automated tasks will evolve over time, this is why the skills to maintain and evolve the automation introduced should be embedded and available inside the team using the automation. There are cases where the automation can be standardised and reused elsewhere, this should be proven by the fact that once the automation is done, no more updates to the automation are needed after then. This is where the traditional approach of doing big-bang automation with standard tools bought off-the-shelf typically fails.
The smaller the initial task to be automated, the faster this step is reached, and the sooner it can be determined if it really can be automated successfully. After that, and only after that, the automation can be extended to automate a larger task.
Paolo Sammicheli author of Scrum for Hardware came up with this metaphor.
Think about software developers, they work on a problem, then they translate their solution into source code written in a programming language, and that source code is consumed by a Compiler that turns it into a software application that can run on your smartphone or your laptop.
Steps #1 and #2 above are like when software developers define and translate a solution into source code, which is like a blueprint.
Step #3 is like when the compiler turns that source code (the blueprint) into a software application like the apps in your smartphone that can run automatically with one touch.
Paolo also made a second example, when a CAD designer thinks about building something and then turn that thinking into a drawing of a mechanical part on the computer screen (this digital drawing is in a sense similar to the source code of the previous example). The drawing then is consumed by Computer-aided manufacturing (CAM) machinery that turns it into production steps that create the part.
Steps #1 and #2 above are like when the CAD designer thinks and then draws the part at the computer.
Step #3 is like when the CAM machinery, like a CNC machine or 3D printer, turns that drawing into an actual part.
What brings together #1-2 & #3 in one example is a programming language and its compiler, in the other is a CAD and a 3D printer. Things that you can buy. When automating something for the 1st time, you may or may not find the equivalent tools that you need, so you may have to build them gradually reducing your initial scope for the automation and expanding it as the tools get developed more.
Before Agile Software Development, automation was often approached with a big-bang top-down large initiative. Or trying to buy silver bullet tools promising miraculous results.
The new approach to automation of Agile Software Development has been a huge leap forward, and very successful. Automation has been driven and created by those doing the work. Starting small and gradually evolving custom-made solutions. The role of the tools has been that of a supporting role, leaving to those doing the work the protagonist role they need to make it work.
Here you can find my suggestions on Agile technical practices outside IT, that are relevant also for automation: Agile Technical Practices outside IT.
You will find in the market plenty of tools sold as a silver bullet that usually omit that the biggest cost is creating, maintaining and evolving the automation. And it is very unlikely that such tools will allow for gradual automation driven by those doing the actual work (that is a key element for this new Agile approach to automation that actually works).
To get it right you want to approach the automation bottom up. First, you need someone in your team that is ambidextrous, a tinkerer, someone for example who not only is good with Excel but that also masters Excel macros and Excel scripting. Or the equivalent for the domain you are working in.
Then you have to allow a small ready-available budget and time from the team to find simple solutions to the challenge of automation.
If after this you still need external support to create the automation, remember to clearly state the fundamental constraint that the solution needs to be maintained and evolved autonomously by those doing the work. And the only way to guarantee that it is not just wishful thinking is to have those doing the work create and evolve the first automation and a few more before the automation tool goal can be claimed to be achieved.
Common reasons for task automation to fail are: some part of the task is too hard/expensive to automate; human judgment cannot be removed from the execution of the task; variations in the task inputs or outputs cannot be removed without losing too much value.
In all the other cases, automation will provide a significant increase in speed, a significant reduction in human errors, and a significant increase in the volume of work that can be carried out. We are talking about several orders of magnitude.
The automation process should be approached gradually, going through the three steps described above, starting with a small task, and incrementally increasing the size/number of tasks automated.
The automation should be maintained and evolved by those using it.
– Agile technical practices outside IT
– Agile at Tesla, Joe Justice
To Paolo Sammicheli, Claudio Sauring, Joe Justice and Carlo Volpi for taking the time to discuss this topic with me, share their insights and experience with me, and give me valuable feedback.
See how we can help.
You, your department, your organisation.
See how we can help.
You, your team, your organisation.
– https://www.infoq.com/articles/practical-application-complexity/
The article key takeaways are
See how we can help.
You, your team, your organisation.
The same is true at the organisation level. I don’t need to tell someone smart like you how the division of labour, standard job-role descriptions and any RACI matrix prevents you from using your full potential. How performance appraisal based on yesterday’s goals and criteria limit your ability to do the right thing today. How traditional Change Management applied to your intellectual work prevents you from expressing your natural creativity and from being innovative. Etc.
Traditional organisations may try to limit individuality (because they are optimised to deal only with standard work, and they may misinterpret harmony as suppression of diversity and dissent), they may try to limit initiative (because they are optimised to follow only standard processes as in the old assembly-line) or they may try to “limit” information and intelligence (because the thinking is delegated only to those at the top).
So what is the Human Element then?
IDENTITY: Among all the people that we know, and every human being who ever was, no two are the same (watch this emotional video). Each one of us is unique, we are heterogeneous. This can protect us from groupthink and blind spots.
INTENTIONALITY: We have free-will, we have agency, we are spontaneous. When we have the freedom, can act, adapt and react quickly.
We are driven by more than instincts, pain or pleasure, needs or desires. But by beliefs, values, principles, sentiments, emotions, intuition, irrationality, and much more.
INTELLIGENCE: We can learn and co-create new knowledge as well as share it. Because we are social.
Social Complexity and Anthro-Complexity study these characteristics of the human element and they study the Human Complexity as well as Human Self-Organisation and Emergence (of common understanding, collaboration patterns, structures, consensus, goals, solutions). Below are a few quotes I’ve collected from Nobel Laureates and world renewed scientists on this topic.
<< This web of life, the most Complex system we know of in the universe, breaks no law of physics, yet is partially lawless, ceaselessly creative >> – Stuart Alan Kauffman
<< Nature is indeed related to the creation of unpredictable novelty, where the possible is richer than the real >> – Ilya Prigogine
<< The future is uncertain… but this uncertainty is at the very heart of human creativity >> – Ilya Prigogine
<< It is this order of interweaving human impulses and strivings, this social order, which determines the course of historical change >> – Norbert Elias
<< We are agents who alter the unfolding of the universe >> – Stuart Alan Kauffman
See how we can help.
You, your team, your organisation.
This is true, especially for Agile practices related to Teams collaboration, Customer collaboration as well as Product/Service development and delivery. Examples include practices such as visualising the work, the planning game, backlog prioritisation, products over projects, estimates or no-estimates, and so on.
On the other hand, Agile technical practices depend very much on what one is doing. Agile technical practices in IT and Software Development are different from those in the automotive sectors, semiconductors manufacturing, Finance or Legal services. And below is discussed why.
But first, business agility, organisational agility and team agility need technical agility achieved by Agile technical practices. All these business + organisational + team + technical agilities are all necessary together. Because without Agile technical practices and so technical agility they would be a table with three legs, unstable and very easily it would fall apart.
Agile Software Development has it, thank you Extreme Programming (XP).
Developing technical practices for other sectors is not trivial.
And new tools may be needed too to enable such new practices. To support the development of such new practices and tools, it is better to share the effort industry-wide instead of a closed commercial approach (see the open-source mindset and “The Cathedral and the Bazaar” essay).
There are three principles that underpin all Agile technical practices in every sector you may be working in. They can guide you while exploring and searching for new Agile technical practices for any non-IT sector. The purpose of all the Agile technical practices is to:
These are a few useful learning, from the experience of the Agile community and XP, to put the previous 3 principles into practice, and can be applied for the development of new Agile technical practices in any sector:
A few more practical tips valid in any sector (industrial, financial, legal, engineering, education, …):
Other practical things that worked in several sectors outside IT, and so worth considering, are: Continuously Integrating (assemble, build, aggregate, produce), Shift-left Testing (start testing earlier in the process, ideally in parallel with development to spot and fix defects when it is cheaper and to avoid the recurrence of similar defects), Automate Testing (to reduce or eliminate the rework and avoid costly mistakes, for example, see the simulators employed for semiconductors or constructions), Small Releases (early, frequent, incremental), Versatile Automation (think about CAD/CAM or the multi-function programmable robots of the new assembly-line).
For multi-domain/multi-workstream products and services development (for example mechanical + electrical + chemical + legal + logistic + … ) consider also:
See also:
– Agile Automation practices outside IT
– Scrum for Hardware, Paolo Sammicheli
– Fabbrica Agile, Claudio Saurin (in Italian, English translation coming soon)
– Agile at Tesla, Joe Justice
Thank you: to Paolo Sammicheli, Claudio Sauring, Joe Justice and Carlo Volpi for taking the time to discuss this topic with me, share their insights and experience with me, and give me valuable feedback.
See how we can help.
You, your team, your organisation.
The epilogue of the book Living Complexity contains a hand-made sketch of a map of the practices in the catalogue. The sketch is an implicit invitation to every reader to draft their own map.
Carlo Volpi accepted the challenge and created his own map. He suggests that a visual map is an essential addition to navigate the catalogue. In the first level Carlo drafted the key overarching concepts:
In the second levels, Carlo added the practices. This below is his map (click to zoom):
The third level of the map contains Carlo’s personal notes, reflections, and consideration, so it is not visible here. You have to draw your own map for that.
Carlo continues explaining that there are multiple potential connections among the practices and a map can be the starting point to draw those non-linear connections.
The conversation with Carlo continues with the realisation that many connoisseurs of complexity theory sometimes struggle with the concept of practice inspired by complexity.
When asked to mention a practice they may for example point to Cynefin that really is a framework (in the same way that Scrum is an Agile framework). Or they may point to Probing or Ritual dissent that really are techniques (in the same way that Dot-voting is a facilitation technique, not an Agile practice).
An example of an Agile practice could be a Retrospective, and an example of a complexity inspired practice could be the Four points method that, while it is based on Cynefin, it has a specific purpose, inputs, outputs/outcomes, and participants.
So Carlo drafted this image to clarify the distinction:
What is your map of Living Complexity?
See how we can help.
You, your team, your organisation.
Living Complexity introduces 15 practical application of Complexity theory, that together with Lean and Agile is one of the three pillars of the modern ways of working.
Through the practices described, the book covers an extensive body of work around Complexity. And shows how the different models and concepts blend together and with Agile.
More posts on the topic of Complexity will follow under the category Complexity: https://www.smharter.com/blog/category/LivingComplexity/
See how we can help.
You, your team, your organisation.
Please give us your feedback! We want to make this a community effort.
#AgileAtScaleGP #GiveUsFeedback
See how we can help.
You, your team, your organisation.
– A blooming industry of services helping consultancy firms fake Agile expertise
– SAFe: a collection of comments from leading experts
Recent updates
Jeff Gothelf coauthor of Lean UX has recently pointed out that the integration of Lean UX in SAFe is flawed in a way that cannot be fixed. This adds up to Scrum practitioners commenting on how the SAFe Scrum version is fundamentally incongruent with Scrum. This cast a shadow on how SAFe integrates other practices and techniques and for those looking at SAFe to learn about Agile and its techniques that means that what SAFe teaches is wrong and would set them on the wrong path.
ThoughtWorks has also recently updated the advice to avoid SAFe based on 6 more years of observations of clients suffering detrimental effects on SAFe.
These new elements added to the previous comments collected move the needle
– from SAFe being useful only in very few and limited contexts and circumstances
– to SAFe being plain wrong beyond repair
– How large successful companies achieve agility at scale
– The results of companies migrating to heavy-weight scaled frameworks and off-the-shelf platforms
– Agile simplicity Vs not-reinventing the wheel
What about the other scaled frameworks
Among the scaled frameworks, SAFe is the most popular and at the same time the most detrimental and flawed.
But all scaled frameworks have their own problems, the alternatives are better than any scaled framework.
If you ask, the less bad are for example
– LeSS (which has a strong focus on the principles but still it is too much Scrum centric and prescribe structures that instead should emerge from the interactions and the experimentation)
– Scrum @ Scale (that is lightweight compared to other scaled frameworks but it also is too Scrum centric and too simplistic with collaboration practices such as Scrum of Scrum that in many contexts is an anti-pattern and the alternative again should emerge from the interactions and the experimentation)
Disciplined Agile is a valuable body of knowledge in presenting many alternative practices, and in suggesting ways to choose among them based on the maturity of the team and based on the team’s context.
But as a framework is too heavy and over-complicated, the prescriptive process and timing to make the selection of the practices is unfit for purpose, and it is simplistic in assuming that the right practice will be one from those listed and not an adaptation or mix-and-match of other existing practices or a completely novel practice.
And then we have the made-up 1-size-fits-all shoes or recipes from the large consultancy companies that show the lack of the most basic understanding of Agile. Some copying the Spotify not-a-model (as if it was a mode), others copying SAFe, others just introducing an Agile terminology to describe well-known pre-Agile practices, and so on.
Please note, none of those consultancy firms has experience using Agile to run their own consultancy firm, they are the first not to believe in what they are selling …
– Agile at scale generative principles
– Agile practices & patterns for the whole Organisation
You may also be interested into these community created guides
– Executive summary for everyone considering investing in Agile: https://bit.ly/AgileInvestingExecutiveSummary
– Information for decision-makers considering the SAFe framework: https://bit.ly/SAFe4DecisionMakers
– Information for decision-makers considering large consultancy firms’ Agile offering: https://bit.ly/agileOffering4DecisionMakers
See how we can help.
You, your team, your organisation.
Heavy-weight scaled agile framework here is intended, for example, as one with a guide of several hundred pages (instead of few tenths), that requires configuration and tailoring-down (instead of being simple and partially incomplete to fit loosely to leave room for adaptation and manoeuvre), with roles that increase the depth of the hierarchy and the hands-over (instead of flattening the hierarchy and supporting self-organisation).
Heavy-weight off-the-shelf platforms and out-of-the-box configurable white label products here is intended, for example, as overcomplicated and rigid third-party products that end-up requiring significant rewriting work, huge and complex data migration, and are hard and difficult to customise to fit the always changing and evolving market requirements.
For FitBit, YNAP and Co-Op Insurance this had very tangible and negative impacts for their business. No tangible impact can currently be measured at Volvo Cars (it is too early to say).
FitBit and Volvo Cars case studies don’t show signs of a strong focus on tech excellence. The technical approach at YNAP and Co-Op was shattering.
None of the four companies shows any sign of alignment to the Agile mindset, that is considered a fundamental ingredient of any successful Agile adoptions, or any sign of autonomy of teams.
Read the full account with all the sources: https://www.smharter.com/blog/the-mixed-results-of-companies-scaling-agile-with-a-scaled-framework/
See how we can help.
You, your team, your organisation.
Agility as being fast, dynamic, innovative, flexible, adaptive, and resilient. For these companies, their agility has been instrumental for their business, financial and commercial success, and for keeping their edge and innovativeness while growing and at scale.
Some of those companies had that agility from the outset and maintained it while they grow (Google, Facebook, Spotify, Amazon) while others at some point in time went through some kind of change or transformation to achieve or recover such degree of agility (Microsoft, LinkedIn, Netflix and HP LaserJet Firmware).
Their pursuit of Agility has been driven both bottom-up and from the top, with a lot of autonomy as well as responsibility for the teams. The balance between the bottom-up and the top drive vary from company to company. People, their autonomy, their mastery, their involvement, and team-work have been fundamental ingredients.
None of these companies even remotely refers to, uses practices from, or takes inspiration from any one of the commercial scaled agile frameworks (e.g. SAFe, DaD, or even LeSS).
None of these companies adhere to just one of the official Agile framework, not by the book, not by imitation, nor in a prescriptive or uniform and standard way for all the teams with a cookie-cutter or cut-and-paste approach.
All these companies have grown their own ways of working internally, in a continuous process of experimentation-learning-adaptation-evolution, in order to suit their specific circumstances and needs (no scaling by imitation, no copycats).
All these companies’ ways of woking take inspiration or are congruent with many of the Lean and Agile principles, values and mindset. With a few exceptions for two of them on sustainable pace, psychological safety, and daily collaboration with the business.
In their pursuit of agility, all these companies have a strong focus on technical excellence with a strong engineering culture. All of them consider the company culture as an important ingredient of their agility.
All these companies’ have some technical practices at scale that have their roots in Agile and specifically in Extreme Programming (e.g. Trunk Based Development, Continuous Integration, Test Automation, Continuous Delivery).
Some of these companies (Microsoft, Spotify, HP LaserJet Firmware) explicitly define themselves as Agile (as in the Manifesto for Agile Software Development). None of these companies talks about scaling Agile (as in any of the Scaled Agile frameworks).
Read the full account with all the sources: https://www.smharter.com/blog/how-large-successful-companies-achieve-agility-at-scale/
See how we can help.
You, your team, your organisation.
Recently the Simplicity in Agile has been challenged by the idea that Agile frameworks, especially the “scaled” ones, should include additional practices, techniques, and processes for not having to reinvent the wheel every time a team/department/organisation starts using an Agile framework.
The other side of the argument is that the Agile frameworks (Extreme Programming, Scrum, Kanban, …) are partially incomplete, intentionally, and fit loosely to leave room for adaptation and manoeuvre to those doing the work on the ground, so they can experiment, learn, adapt and evolve their practices, and ways of working, to fit their specific circumstances. One of the values of the Agile manifesto, after all, is “individuals and interactions over processes and tools.”
So should Simplicity take precedence?
Or should not-reinventing-the-wheel come first?
Is there a good trade-off between the Agile Simplicity and not having to reinvent the wheel every time?
My take is based on one principle and one prerequisite of Agility.
John Gall’s principle from 1975 has often inspired Agile:
A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.
You have to start over with a working simple system.
The idea is that you don’t build from scratch a whole airplane just to try it if it flies only at the end, as someone put it (Giovanni Asproni). When tackling a complex problem, it is more effective starting small and iteratively and incrementally experimenting, learning, adapting and evolving. This idea of iterative incremental refinements permeates Agile.
Even more this principle applies to how teams/departments/organisations adopt an Agile framework and agile ways of working.
For them, the principle means it is not possible to define, comprehensively and upfront, an effective way of working even using a hypothetical omni-comprehensive all-encompassing Agile framework and the wisdom of the smartest “Agile luminary” to configure/tailor it.
This is because, for example, that in every team/department/organisation the fundamental relationships and the interrelations are different and have a huge and unique impact on which ways of working will be effective there. Therefore such effective ways of working can only be discovered by those doing the work on the ground, starting small with a framework that is partially incomplete, and incrementally adding only what seems to be needed and not more, and only when is needed and not before. And observing what works in practice, and what doesn’t. This will also lead to novel practices or processes that are not included in any existing framework.
An interesting and less obvious consequence is that there cannot be a recipes book that can tell upfront how to scale a company. Not an expert can design upfront a way to scale a specific company. Instead the path to the journey of scaling an organisation unfold and reveal itself as you go.
The final part of my take on Agile simplicity is based on Maneuver Agility (also known as C2 Manoeuvre Agility and C2 Maneuverability), a pre-requisite of Agility described by David S. Alberts as follows:
Maneuver Agility Is the ability to recognise the approach appropriate for the circumstances,
and to transition to this approach in a timely manner.
It is a function of the set of approaches available.
It is an ability of those on the ground doing the work. An Agile framework that is as simple as partially incomplete, underspecified, challenges those doing the work to improve iteratively and incrementally experimenting, learning, adapting and evolving their ways of working, since the very start. So they develop this ability to maneuver and they can continue to use it to adapt to the changing circumstances.
An interesting and less obvious consequence is that a scaling initiative cannot be driven and directed from an “Ivory Tower”, instead those doing the work on the ground should be directly involved in shaping and driving the scaling initiative.
In conclusion, John Gall’s principle (start small and grow your ways of working) and the pre-requisite of Agility called Maneuver Agility (adapt your ways of working to your current circumstances) suggest that simplicity in Agile is still essential. An omni-comprehensive, all-encompassing, framework would violate John Gall’s principle and neglect the Agility pre-requisite where a simple and generative, seed-like, Agile framework would honour both.
Simple Agile frameworks exist in the context of a lively lean-agile community constantly innovating, refining and growing a vast and open knowledge base of techniques, practices, and processes and open sets of patterns that complement every Agile framework. See the Present continuous in the ‘Uncovering’ at the very beginning of the Agile Manifesto. See also this funny video from Breaking Bad: https://youtu.be/X4LOuaMb-yI
Those doing the work on the ground should have direct access to the lean-agile community and such knowledge base, without limitations, intermediation, or filters, where they can find options and inspirations they can use to adapt, and evolve their ways of working, with the awareness that their specific problem may not find an answer there and instead they may need to invent novel practices (read here how to get involved in the lean-agile community).
This is what we did in the beginning, about 20 years ago, and more recently this concept has been reminded to me by Al Shalloway.
These below are a few historical examples of the open knowledge base of solutions and patterns from the lean-agile community:
– Portland Pattern Repository: http://wiki.c2.com/?PortlandPatternRepository
– Scrum Pattern Community: http://www.scrumplop.org/
– Top 100 Agile Books: https://www.goodreads.com/list/show/41715.Top_100_Agile_Books
– AgileAlliance on Agile: https://www.agilealliance.org/agile101/
– …
And here a google doc with similar lists: https://tinyurl.com/wholeorg-agile
Chet Hendrickson points out that since Agile is simple, a scaled version of Agile should also be that simple, or even simpler. Otherwise, it will no longer be Agile (excerpt from The Nature of Software Development, by Ron Jeffries, 2015).
SAFe and DaD seem to be in a very different place.
Other less normative and less paternalistic scaled frameworks seem to violate the idea of simplicity too, even if to a lesser extent.
What are the consequences? What is your take on this matter?
Do we really need scaled frameworks then?
The example of these companies tells us that we may not.
See how we can help.
You, your team, your organisation.
The lean-agile community is one of the largest and most prolific worldwide community.
The lively lean-agile community is constantly innovating, refining and growing a vast and open knowledge base of ideas, techniques, and practices, and open sets of patterns that are an indispensable completion for every Lean and Agile framework.
For this reason, being connected to the lean-agile community, following the flow of new ideas and the refinement of the existing ones, and participating actively, are all prerequisites for every Lean and Agile practitioner.
Those doing the work on the ground need direct access to the lean-agile community and its knowledge base of ideas, without limitations, intermediation, or filters.
On top of that, given the social and technical nature of lean and agile, to fully grasp an idea, it’s often useful to also understand who is behind it and what the history is.
The spirit of the lean and agile community is described by the 1st sentence of the Manifesto for Agile Sofware Development:
<<We are uncovering better ways of developing software by doing it and helping others do it.>>
The lean-agile community is both global (worldwide) and local (in your geographic area, and maybe even in your company), you can meet members at conferences, meetups, on social networks, on WhatsApp or Slack groups, on lean coffees or morning breakfasts, etc.
All the links are in this Google Spreadsheet you can copy, download, and distribute the link, as well as suggest any additions/changes using the document: https://docs.google.com/spreadsheets/d/1QyLeL7JwSAevfq2SbO-u6H_Mr-sRIAYQ-FRoSxymmCA/edit?usp=sharing
For your convenience, this below is a preview of the spreadsheet:
]]>I’ve tried several “tools” to support my understanding and those conversations, and to carry out those assessments. I started with the Schneider Culture Model and I’ve experimented with others. I’ve found some model more effective and valuable than others. I’m sharing them here in this post.
From a practical point of view, I find useful this definition of culture, culture is:
The collective narratives that connect people, the set of intangibles that contribute to define a group’s identity and that ultimately influence how the group make sense of things, take decisions together, behave and act.
I find it useful because it connects the culture with the most visible and tangible aspect of it, that is the actions and behaviour of the group.
David Marquet in his book ’Turn the Ship Around’ describes the principle Act your way to new thinking, that means: Change behaviour and this leads to new thinking, to a cultural change.
The only fast cultural changes I’ve seen or heard about, have been traumatic and regressive cultural revolutions, imposed by authority and with a degree of coercion and fear (e.g. of losing the job, status, and privileges).
A positive cultural evolution, especially one beneficial to an organisation transitioning to a modern paradigm of work, is a very different type of cultural change. And that in my experience takes many years before it happens, take roots and become permanent.
In the book Rework the co-authors and founders of the software company 37signals, Jason Fried & David Heinemeier Hansson, suggest:
Culture is the by-product of consistent behaviour
Someone else said:
Culture is like a fine scotch, you’ve got to give it years to develop
Leaders in an organisation have a huge role in cultural change. The leaders create a work environment that is fertile or hostile to the cultural evolution: through their exemplar and consistent behaviour, by the behaviours they encourage, support and reward, and the bad behaviours they tolerate.
The importance of such an environment is highlighted by Joseph Pelrinee referencing the work of psychologist Kurt Lewin: Behaviour is a function of the person and his or her environment or
B = ⨍ (P, E)
How long is gonna take then? I’ve seen traumatic and regressive cultural revolutions happen in less than one year. I’ve seen positive cultural evolutions take 3 to 6 years, depending also on the size of the company. Jennie Naidoo and Jane Wills in ‘Foundations for Health Promotion’ list 6 criteria for a change to have taken place, these three helps to draft a “definition of done”:
Dave Snowden suggests that:
You can’t engineer a company culture.
You can interpret the present, set a direction of travel, and discover useful things during the journey.
To do this, leaders as well as groups and teams, can periodically observe their current behaviours, and the behaviours they want to encourage, support, reward, and tolerate based on which is beneficial and which is not. And they can use visualisation techniques to do this collectively.
For example, Andrea Provaglio created this radar to visualise reflections around behaviours:
The group can add post-its with the related behaviour placed in the relevant quadrant. A possible format for such post-it is suggested in David Marquet ‘Turn the Ship Around Workbook’:
I’ve mentioned before how important are the environment as well as the identity, and roles that may contribute to define such identity. I’ve observed in action a few times this effective technique to influence and reinforce a cultural change:
– gradually forming new teams (adopting a new way of working) and moving them to a new office/building
– gradually assigning people to the new roles giving individuals the right to volunteer for this move and giving priority to those that are willing and ready.
This had the effect to create a completely new environment with a void that brings the opportunity as well as the need to redefine new social norms, new behaviours, and so contribute to a new culture.
I’ve tried several models. Those I’m describing here have been the more effective and valuable because they are very clear, intuitive, quick, and they help to collect easy to correlate data.
As much as they are a very effective support, they are not a magic tool. Most of the intelligence is in the person facilitating the assessment, and most of the information is in the stories told in the conversations provoked by these assessments. The data-points collected and correlated with the support of these models help to make sense of it in a more reliable way.
The first model provides a description of different evolutionary paradigms for organisations by Frederic Laloux (he uses the term Level of Consciousness). Please note that the Teal is an abstract extrapolation, does not come from several observations as per the other levels.
The second model provides a mapping between such levels and different degrees of alignment to the agile manifesto, it comes from Michael Spayd (he uses the term Altitudes). Both are easy for everyone to understand, and help to describe the current reality people is experiencing in their team, department and organisation. The mapping to Agile enables conversations around the current culture and its compatibility with agile ways of working.
The participants to the assessment are asked to dot-vote where they see their organisation (or department or team) among the cultures described by Frederic Laloux and mapped by Michael Spayd:
while the description of all the options is presented to them.
This is a quick summary of the mapping of the Amber culture to the agile manifesto:
This is a quick summary of the mapping of the Orange culture to the agile manifesto:
This is a quick summary of the mapping of the Green culture to the agile manifesto:
This is a quick summary of the mapping of the Teal culture to the agile manifesto:
After the dot-voting and the counting of the votes, participants comment on the results and are encouraged to openly discuss it. This typically leads to a lot of interesting conversations, and interesting and relevant stories are shared.
The organisation culture has a big influence on the processes used by the organisation too. So talking about the processes provides useful additional data-points and often leads to other interesting conversations. The upside-down triangle below is used provokes such conversations.
On the top, there is a line that goes
– from the left vertex representing an improvisation approach to processes that I call “Ad-hoc, NIKE’s Just do it”
– to the right vertex representing a highly predictive, prescriptive and bureaucratic approach to processes.
In the middle of the line on the top, between the left and right vertex, there is an area representing a flexible and adaptive “agile” approach to processes.
Try it online https://scratch.mit.edu/projects/445690099/
When the approach of the organisation to processes is close to the left or right extremes, and the circumstances the company is facing do not match well with such approach, it is common for an organisation to temporally swing their approach to processes to the other extreme like a pendulum. This typically suggests a lack of manoeuvre agility: the ability to recognise the approach appropriate for the circumstances, and to transition in a timely manner to this approach. And it is the opposite of the flexible and adaptive “agile” approach to processes. The vertex at the bottom marked with “Panic swing” represents such case.
Participants to the assessment are asked to dot-vote where they see the approach to processes in their team, department or organisation. They are asked to place a dot proportionally closer to the vertex that resembles the most the process approach they have observed, and proportionally far away from the vertex the resemble the less the process approach the have observed.
After the dot-voting and the identification of clusters of votes, participants comment on the results. Again a lot of interesting conversations happens and useful stories are shared.
The result of the first dot-voting (Laloux-Spayd), the second dot-voting (processes triangle) and the comments and stories shared all together contribute to create a good picture of the organisation culture. In order to better correlate the stories and the data collected with the organization’s culture in a reliable way, It is useful for the facilitator to run this assessment in several different organisations and spend some time there observing the actual behaviours.
See how we can help.
You, your department, your organisation.
Agile Alliance
History – https://www.agilealliance.org/a-short-history-of-agile/
Time-line – https://www.agilealliance.org/agile101/practices-timeline/
Martin Fowler
Post – https://martinfowler.com/articles/agileStory.html
Podcast – https://agileuprising.libsyn.com/manifesto-co-author-interview-martin-fowler
Alistair Cockburn
Post – https://web.archive.org/web/20170626102447/http://alistair.cockburn.us/How+I+saved+Agile+and+the+Rest+of+the+World
Video – https://youtu.be/EYBpGvSHXCI
Podcast – https://agileuprising.libsyn.com/manifesto-co-author-interview-alistair-cockburn
Notes – https://siamchamnankit.co.th/history-some-pictures-and-pdfs-of-the-agile-manifesto-meeting-on-2001-a33c40bcc2b (documented by Prathan D.)
Dave Thomas
Post – http://pragdave.blogspot.com/2007_02_01_archive.html?m=0
Jim Highsmith
Post – http://agilemanifesto.org/history.html
Podcast – https://agileuprising.libsyn.com/manifesto-co-author-interview-jim-highsmith
Mike Beedle
Article – https://www.infoq.com/news/2018/03/mike-beedle/
Podcast – https://agileuprising.libsyn.com/manifesto-co-author-interview-mike-beedle
Ken Schwaber
Podcast – https://agileuprising.libsyn.com/manifesto-co-author-interview-ken-schwaber
Stephen Mellor
Podcast – https://agileuprising.libsyn.com/manifesto-co-author-interview-stephen-mellor
James Grenning
Article – https://medium.com/pragmatic-programmers/i-went-for-the-skiing-87cb79e64a29
Podcast – https://agileuprising.libsyn.com/manifesto-co-author-interview-james-grenning
Ron Jeffries
Podcast – https://agileuprising.libsyn.com/manifesto-co-author-interview-ron-jeffries
Brian Marick
Podcast – https://agileuprising.libsyn.com/manifesto-co-author-interview-brian-marick
Andy Hunt
Podcast – https://agileuprising.libsyn.com/manifesto-co-author-interview-andy-hunt
Notes – https://coalition.agileuprising.com/t/another-snowbird-artifact-andy-hunts-notes/542
Arie Van Bennekum
Podcast – https://agileuprising.libsyn.com/manifesto-co-author-interview-arie-van-bennekum
Jon Kern
Podcast – https://agileuprising.libsyn.com/manifesto-co-author-interview-jon-kern
Notes – https://coalition.agileuprising.com/t/agile-uprising-original-manifesto-meeting-notes-open/225
Bob Martin
Post – https://sites.google.com/site/unclebobconsultingllc/the-founding-of-the-agile-alliance
Podcast – https://agileuprising.libsyn.com/manifesto-co-author-interview-bob-martin
Jeff Sutherland
Podcast – https://agileuprising.libsyn.com/manifesto-co-author-interview-jeff-sutherland
You may also be interested to read:
– A collection of principles, theories and models relevant to Agile
– Would we still have Agile today, if the Agile Manifesto had never happened?
– Freshen up Agile Manifesto
See how we can help.
You, your team, your organisation.
Below you find a few anecdotes that seem to draw a trajectory inevitably leading to Agile Software Development. And the reason seems to be the nature, ubiquity and exponential progress of software and communications technologies and the related Cambrian explosion of (social, technical, financial) interconnections driven by the evolutions of the world we live in. The anecdotes below also reveal a broader perspective on Agility beyond software development. That perspective suggests sources and a repertoire of lessons that can be applied to Agile Software Development too.
A Gordian knot is a metaphor and an early reference to intractable problems. In the 18th century intractable problems were of exceptional rarity.
Robert McNamara and the Whiz Kids had an astonishing rise to success after WWII thanks to the emergence of computers and operational research methods and their applications in mass-production manufacturing and well as in the US armed forces. They applied their expertise in using cutting edge technology and research to solve complicated problems (problems that require subject matter experts to identify the relevant best practice to solve the problem; they are quite different from Intractable problems tho’).
Thanks to this success McNamara become United States Secretary of Defence and later World Bank President. In these positions, he had to deal with intractable (AKA wicked, AKA complex) problems such as the Vietnam War and international cooperation.
He tried to solve these intractable problems using the same solutions that made him famously successful when he was dealing with complicated problems. As a consequence, he spectacularly and repeatedly failed, to the point that a fallacy was named after him, the McNamara fallacy. Quite an ironic paradox isn’t it?
Around the 60s those working in international cooperation and conflicts had to deal with intractable problems more than once in their lifetime if ever. Who else was facing intractable problems back then? Very few.
Almost during the same time, after WWII, the industry and mass productions grow as did industrialised cities and their population. Approaches similar to those used by McNamara to solve complicated problems were used in urban planning.
In the 60s and 70s top-down and strictly quantitative methods were used in Urban Planning to plan for the use of the land, to design urban areas, to plan the consumption of natural resources, to design transportation and infrastructure, and to design spaces for the communities. The human factor, that may turn a complicated problem into a complex one, was ignored by the mainstream Urban Planning architects and intellectuals. Nowadays we know well that cities are complex, even more complex than the weather systems.
This mismatch between the complex nature of the problem and the approach for complicated problems being adopted, lead to repeated failures. Jane Jacobs, a journalist, author, and activist who influenced urban studies, sociology, and economics, in 1961 was one of the few to observe this mismatch and its consequences. This is an excerpt from Jane Jacobs:
In 1959 the Chicago Area Transportation Study describes the Desire path AKA Desire lines. It is a path created by human foot-fall traffic on the most easily navigated route, as opposed to promenades planned ignoring those they should serve.
Christopher Alexander, architect and design theorist, like Jane Jacobs was one of the few to realise the impact of the human factor on the category of problems faced by architecture and design.
At the University of Oregon the protest of students against the process used to design their spaces led to the involvement of Christopher Alexander to design a different process by which the community of the university could create its own spaces (the human factor and the consequent complexity of the problem were in a way recognised). That work at the University of Oregon became the experimental testbed for material that later became the Christopher Alexander’s, bestselling book ‘A Pattern Language’.
His work on patterns influenced also software development, leading to the book Design Patterns: Elements of Reusable Object-Oriented, the creation of the Wiki, and it also influenced agile software development.
In the 60s and 70s only a small group of people had to deal occasionally with such complex problems of urban planning. In that group of people the majority ignored their systematic failures and the real nature of those problems. With the exceptions of Jane Jacobs and Christopher Alexander.
During this period of time some scientists started to face some complex problems when studying economy, public health planning, weather forecast, environment, and politic. It was still a small group of people, and those problems were still uncommon.
In 1967 C. West Churchman mentioned, in a Management Science journal’s article, the term Wicked Problem to describe an intractable/complex problem that often eludes the solutions identified by Operational Research methods. In 1973 Rittel and Webber gave a formal definition of a Wicked Problem from their studies in social policy planning.
In 1985 Warren Bennis and Burt Nanus introduced the definition of a VUCA (as Volatile, Uncertain, Complex, Ambiguous) world (a world where complex problems are becoming common and frequent for a lot of people) when discussing leadership theories. Two years later, in 1987, the acronym was introduced. Also the U.S. Army War College used the term in relation to the multilateral world problems emerging at the end of the Cold War.
Ralph Douglas Stacey is an organizational theorist and Professor of Management. He noticed leaders, policymakers and managers facing complex problems in all organisations, where traditional planning and forecasting approach led to bad decisions and unintended consequences. So from 1991 he started to apply chaos theory and the models of complex adaptive systems (CAS) to organisations and management. This work led to the formulation of Stacey’s Matrix in 1996 to integrate mainstream management theories with the notion of organisations as complex adaptive systems.
During this time complex problems were gradually becoming more common for leaders of medium-large organisations. This was still a relatively small group of people. And such problems were not the norm yet.
In 1999 David Snowden, a management consultant and researcher in the field of knowledge management, created the Cynefin framework (with contributions also from Cynthia Kurtz, Max Boisot and Alicia Juarrero) to support leaders in sense-making and decision-making when problems can have various characteristic including being complex. Cynefin framework contributed to formally define complex problems.
Scientists are facing complex problems more often and the study of complex problems intensifies. In 2008 Stuart A. Kauffman (theoretical biologist and complex systems researcher) comments on the ontological limit to predictability:
“My claim is not simply that we lack sufficient knowledge or wisdom to predict the future evolution of the biosphere, economy, or human culture. It is that these things are inherently beyond prediction.”
Stuart A. Kauffman
He also points out that physicists too are in a quiet revolution and he mentions Nobel laureates Philip Warren Anderson, Robert B. Laughingstocks and Isan Newton Media Leo Kandoff that are questioning the adequacy of reductionism.
NATO too is increasingly facing similar challenges, complex problems, in its multi-national military operations. During 2003-2013 David S. Alberts studies Agility for the military.
Complex problems are starting to become common for everyone.
During this time the Internet brings to everyone and everyday life the globalisation of ideas, information, and communication. This in turns amplifies the already ongoing globalisation of goods, services, financial transactions, travel, and work outsourcing. This expanding network of connections, frequent interactions, and interdependencies create complex dynamics that gradually brings the reality of complex problems into everyone and everyday life.
The complex problems that were experienced by the leadership of large organisations are gradually becoming a reality for everyone working in every-day life and in every organisation, especially those technologically more advanced and more connected to the Internet and its technological eco-system.
The constant evolution of the world we live in has created a reality where complex problems are common, frequent, and experienced by everyone everywhere. Tech companies have been at the forefront of this revolution and as such were the most likely to tackle this problem first.
Evidence also shows that in a variety of disparate areas and fields, others were tackling similar problems too. So it is safe to say that if the Tech industry and the co-authors of the agile manifesto would have not created agile, someone else would have developed an equivalent solution because it was valuable and necessary to do so.
Lucky enough the co-authors of the agile manifesto created agile and they did a great job. The inevitability does not make it less valuable, important or useful:
– that “whole” they created (bringing the lightweight methods together and give them a home) is *much much* more than the sum of its parts
– the connections of ideas and people (the agile alliance and the agile community) were instrumental in provoking the irreversible phase change that turned that underground minority movement into the new mainstream we have today.
The list of anecdotes above also suggests many fields and sources in addition to those traditionally referenced in agile software development with valuable learnings that can be reused and applied in software development too. See also: A collection of principles, theories and models relevant to Agile.
See how we can help.
You, your team, your organisation.
See how we can help.
You, your team, your organisation.
Mastering Agile and becoming a great Scrum Master is a never-ending quest. It is a path of continuous improvement, a journey toward constantly experimenting and acquiring new skills, making new experiences and learning new things.
Talking with a buddy (as a more sr Scrum Master or a peer) can help you become aware of your strengths and identify areas of potential improvement. This can lead to identifying improvement actions. Feedback can be collected to track progress.
This can happen in a very fluid and informal way, but if you are new to it, if you want some structure to get it started, or if you want some suggestions on the skills and competencies to explore, than you can try this Scrum Master self-assessment kit whose content is congruent with the many learning objectives and the course objectives of Scrum Alliance and Scrum.org (Scrum Foundations, CSM, A-CSM, CSP-SM; and PSM I, PSM II, PSM III).
You find the kit here with the instruction: The Scrum Master Self-Assessment Kit
See how we can help.
You, your team, your organisation.
The result of the study contained the benefits of coaching as perceived by the clients, in three main areas:
The infographic here details the first two points.
See how we can help.
You, your department, your organisation.
Facilitating, mentoring, teaching and coaching individuals, teams and the organisation to develop an agile mindset, to enact agile principles and values, and to achieve agility in order to seize opportunities and tackle the challenges.
But then how do you define that coaching bit of the above definition? In order to draft below a definition of coaching that suits Agile Coaching, I’m taking inspiration from Sir John Whitmore (Author of Coaching for Performance) and the International Coach Federation:
Individual Coaching
Partnering with a person in a thought-provoking and creative process that inspires them to maximise and unlock their own performance. Helping the person to learn rather than teaching them.
Team Coaching
Unlocking team’s potential, maximising their performance improving the team’s members ability to collaborate, share information, make sense of things, build consensus, and decide together.
Organisational Coaching
Coaching teams and individuals from all parts of the organisation, including the leadership, toward a holistic view of the organisation as a living organism, and with a focus on the organisation’s strategy, principles, values, mindset, and culture.
In comes to my mind this quote often attributed to Socrates:
<< I cannot teach anybody anything, I can only make them think. >>
If you are interested to know more details about lean-agile coaching, you may find this interesting: lean-agile coaching self-assessment radars.
Now that we have a definition of coaching, how do we define and measure success for Agile Coaching?
The best way to measure it that I’ve found is to use a combination of internal and external measures, like those listed below:
External measures of success for Agile Coaching
Internal measures of success for Agile Coaching
See how we can help.
You, your department, your organisation.
Being assertive means that everyone, regardless of gender, race or religious affiliation, is entitled to all these things in the list.
See how we can help.
You, your team, your organisation.
Individuals and interactions over processes and tools.
The same is true in Lean, as this quote from Eiji Toyoda highlights:
Complexity Science shows how a myriad of local interactions and how they come together to form population-wide patterns, or not, is what defines the outcomes, more than the individual behaviours of the agents in the system.
Ubuntu is a Nguni Bantu term meaning “humanity”. It is sometimes translated as “I am because we are” and also “I am because you are”, or in other words:
In my quest for the people-centred Agile, I’ve identified these six principles and the related quotes that bring the principles to life:
Openness & curiosity
A repertoire might be more useful than a conviction; especially if one wants to keep in mind that there are many kinds of good life – Adam Phillips
Respect people & humanise the workplace
Even in a hierarchy people can be equal as thinkers – Nancy Kline
Empathy
You never really understand a person until you consider things from his point of view, until you climb into his skin and walk around in it – Harper Lee
Deep listening
The quality of your attention determines the quality of other people’s thinking – Nancy Kline
Appreciation & compassion
A person who is impartial, fair, calm, gentle, serene, accepting, and openhearted is indeed a refuge – Karen Armstrong
Growth mindset
Intelligence can develop, effort leads to success – Carol Dweck
See how we can help.
You, your team, your organisation.
Team vision and discipline over processes and tools
Delivered value & validated learning over formalities
Stakeholders and customer collaboration & discovery over contract negotiation
Initiating & responding to change over following a fixed plan
We welcome emerging requirements, even late in development.
We harness change and make the most of it
for the stakeholders and the customer’s competitive advantage.
We validate learnings and we deliver improvements, working features,
and business value continually, from a couple of weeks to a couple of hours,
with a preference to the shorter timescale.
Stakeholders, product/service people, developers, designers,
and all the parties involved have a voice and work daily together
throughout the delivery effort and the product/service lifecycle.
Build digital products/services around motivated stakeholders and individuals.
Give them the clarity, the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of conveying information
is face-to-face. Use the best communication means available,
that is suitable for the complexity at hand.
Business value delivered, working features,
delighted stakeholders and customers
are the primary measures of progress.
Agile ways of working promote sustainable workload.
The stakeholders, developers, and all the parties involved
should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design
enhance technical agility and are a prerequisite for organisational and business agility.
Simplicity –the art of maximising the amount
of work not done– is essential.
The best business outcomes, digital products/services, architectures, requirements, and designs
emerge from a team in a self-organising system
that supports and amplifies beneficial outcomes.
Continuously the team reflects on how
to become more effective, then tunes and adjusts
its behaviour and ways of working accordingly.
See how we can help.
You, your team, your organisation.
In the beginning, to answer these questions, we referred to the 4 values and 5 principles of Extreme Programming (later developed into 5 and 13 respectively), and the 3 pillars of Scrum (later supplemented with 5 values). From 1991 we had Crystal Clear that evolved to 7 properties. Then from 2001, there were the 4 values and 12 principles of the Manifesto for Agile Software Development. Later we referred to the 7 principles from Lean Software Development as a “theory” for Agile. Then we used The Wicked Problem definition from Rittel and Webber, the Ralph D. Stacey’s Matrix, and the VUCA world definition, to understand and explain why Agile works better. Finally, we turned to the Cynefin framework from David Snowden, the theory from Complexity Science, human Complex Adaptive Systems, and the 6 characteristics and 3 variables of Agility with its definition from David S. Alberts. Here a more comprehensive list.
The three pillars of Agile consolidate all the knowledge and theory from these sources and express them in a short and clear form easy to understand. Here they are:
– Co-creation: Is a form of deep and fluid collaboration across functions and disciplines, and a shared ownership of artefacts and outcomes, that minimise hands-over and delays, take advantage of the diversity of ideas and multiplicity of points of view, and enable fast feedback loops.
It usually involves a pair or a group of people synchronously working together, sharing their creative space and thought process, while creating and gradually refining a shared artefact.
When the work in novel, ambiguous, uncertain, or in a single word Complex, co-creation becomes a necessity in order to overcome individual fragmented understanding and reach some degree of common understanding.
– Co-evolution: Is a double act where the understanding of the problem and the discovery of a solution gradually evolve in concert. It continues until a good-enough working solution is discovered and developed, and only then the problem is fully understood.
It is in the doing of the work that we discover the work that we must do. Doing exposes reality
~ Woody Zuill (Mob programming)
– Simplicity: All Agile frameworks, and many aspects of agile, are intentionally incomplete, they are the simplest possible starting point, because they expect people doing the work to continuously experiment, learn, adapt and evolve to fit their unique and always changing circumstances. It is about growing things by letting them emerge. So you could interchangeably name this as Emergence.
BTW these three pillars are the results of many years of refinement through simplification. Out of curiosity see how this list looked like more than 10 years ago (a lifetime) in its first 11-items version: link.
You need all three of them at the same time to have Agile and pursue Agility. They can help you to get a deeper understanding of the essence and spirit of agile. You can use them to guide your decision-making when practising Agile. And finally they can help you spot counterfeit/fake or fundamentally misunderstood agile (for example see here).
See how we can help.
You, your team, your organisation.
More books here:
Here you find three more books that describe and explain the challenges of this volatile, uncertain, complex and ambiguous world. They provide an updated map of the new world leaders are facing.
You can find them here: Summer reading list for the (to be) reformed manager.
Two more blog post:
These blog posts contain more insights into the latest paradigm shift our world went through in recent years.
– The two key components of the Agile paradigm shift.
– Gartner you got it wrong. The new Lean-Agile Waterfall is not cool.
See how we can help.
You, your team, your organisation.
The first one is from the Agile Manifesto, and points to professional coaching and facilitation for individuals, teams, and their interactions.
The second one is the Lewin’s equation, suggested to me by Joseph Pelrine, and points to Complex Adaptive socio-technical Systems and Agility, and its tools and models to tweak the environment in order to amplify the emergence of positive outcomes and dial down the negative ones.
The intersection of the two points to agile/lean mentoring and training.
What else can we infer from those equations? What else can we learn from it?
On the same topic, look at the lean-agile coaching self-assessment radars.
See how we can help.
You, your team, your organisation.
If you are in a hurry you may want to jump to part two now.
In 2016 Gartner published the diagram of a process that combines Design Thinking, Lean Startup, and Agile.
I was initially attracted to it because it combines different approaches and practices instead of contrasting them with the goal to pick one in the end.
It was only later while I was reexploring the foundations of lean and agile that I realised Gartner’s process was in reality Waterfall in disguise, because of three underlying fundamental misunderstandings about Agile.
This below is a cut-down view of the Gartner’s linear and sequential process, that starts to highlights the flaws.
It should be read from left to right, from the initial need/goal (left) to the product delivery and operation (right). The overall process is a sequence of sub-processes loosely connected.
Can you guess what’s wrong with it? The answer is here: Part two.
See how we can help.
You, your team, your organisation.
I started to learn and experiment with the technical practices, to later move into collaboration and team practices, and so on.
Beside my observations of what was working and what wasn’t, there was no other means for me to check if I was missing something fundamental, if I was practising things as intended, if I fully made the switch to the new paradigm and the new mindset, or not.
A similar situation was described by a philosopher in an interesting thought experiment also known by the name Mary in the black and white room.
Mary is a scientist who knows everything there is to know about colour.
But she was born and raised in a black and white room, and her only contacts with the outside world are black and white television monitors.
One day Mary exits the black and white room and experiences for the first time colour.
Does she learn anything new about colour? What did she not know before?
The answers to these questions have a name: Qualia.
A few years later, just like Mary, I left my black and white room of agile’s rainbow, to find out and try to conquer my agility qualia.
I joined Scuderia Ferrari F1 racing team, a fast-paced and turbulent environment where I could put to the test my agile practice.
I learned and experienced a variety of agile frameworks and practices, in a variety of different teams, industries, and organisations. I joined ThoughtWorks, a longtime advocate and a leader in lean and agile.
During this time I collaborated and worked with many agile experts that invented some of the practices your team is probably still using right now.
A subtle but important consequence of Mary’s experiment, indeed, is that:
There are no other means to become a proficient agile professional, let alone an expert,
then a direct experience of what good *really* looks like in agile.
And for that, one needs to join a talented and experienced agile team
and be involved hands-on in the delivery, for long enough.
Books, conferences, training, and previous experiences,
are all necessary complements.
But they cannot, by any means, be a substitute.
Nowadays Agile is mainstream. As a consequence, most organisations feel compelled to do agile because everyone else is doing it. Often without really embracing the mindset and the way of working.
Therefore the vast majority of those involved with agile in the last years, have been exposed only to a partial, watered down, and often fundamentally misunderstood, version of agile.
In these circumstances, almost no one has a chance to experience what good really looks like in agile, not even once.
Consequently, even the smartest, the most passionate, and the authentic and genuine practitioners, are held hostage in the black and white room of agile’s rainbow. This leads to an incredible amount of raw talent lost, lost opportunities for professional development, and for increases in organisations’ productivity and competitiveness.
But there are ways you can try to escape the black and white room and experience all the colours of the agile rainbow. Here are a few ideas:
And here the second part of the video:
See how we can help.
You, your team, your organisation.
I used many times this question “what’s the main purpose of a lean-agile coach in your team/department/organisation?” to start the conversation and explore the role in the context of an organisation. For example during a Community of Practice meeting or with a client. And it proved to be quite an effective starting point.
This week I made another experiment and I asked to the Lean/Agile Coaches in my Linked-In network and on Twitter, exactly that same question.
The comments about the Agile Coach role, in comparison to the comments about the Scrum Master role (see the previous post), so far show some similarities and some differences:
People – Way of Working – Delivery
– The comments highlight a bigger focus on the People side of things, compared to the Scrum Master comments that focus more on the Way of Working.
Scrum – Agile, Lean, etc. – Mind-set
– The comments highlight a bigger focus on a holistic view, with few mentions of the mindset, continuous improvement, and more generally on Agile, while comments on Scrum Master role focus more on Scrum.
Individuals – Team/Teams – Whole organisation
– The comments highlight a bigger focus on Individuals (usually senior people and managers and leaders) and the Whole organisation, while comments on the Scrum Master role focus more on Team(s).
Thanks to everyone for their comments and contributions!
If you are interested into the compentency areas, and the skills of an agile coach, you can view and download the Lean/Agile Coach self-assessment radars.
Thanks to Ryan Behrman for the image of the different levels of intervention.
You may find interesting comparing the system of lean-agile coaching purposes with the hierarchy of consulting purposes from this Harward Business Review article: Consulting Is More Than Giving Advice.
See how we can help.
You, your team, your organisation.
This week I made an experiment and I asked the Scrum Masters in my Linked-In network exactly that question.
From their initial answers, I noticed some trends:
Join the conversation here.
Below you find some of the answers collected so far.
Here you can also find a radar with competency areas for the Scrum Master. It is just an example! Based on the conversations that emerge in your company, you probably want to create a personalised one.
Download it and start from here: Scrum Master self-assessment radar.
Thanks for their comments to Arian Shehu, Bankole A Dada, Christoffer Westberg, Deon Louw, Gabriele Mancini, Gangadhar Vasanthapuram, Glenn Bowering, Govind Hari, Ilker Işler, Jack Reed, James Willis, Jem D’jelal, Julian Bayer, Karim Harbott, Luca Vettor, Marijn van der Zee, Michael Küsters, PiyushRahate, Ram Srinivasan, Sam A. Kishaish, Shaaron A Alvares, Shadreck Mudziwepasi, SolangeLalji, Sven Ihnken, Syed Amanulla Hussaini, Thoralf J. Klatt, Todd Adams, Venkatesh Rajamani,
Wanja Krah.
:
People – Way of Working – Delivery
– Helping people to deliver valuable products and grow great teams.
– To help the team and the organisation get better at delivering value.
– Helping others achieve new heights.
– As a craftsman applying the empirical framework and helping others to apply it.
– The scrum master makes the process more fluid, facilitating teamwork.
Scrum / Agile, Lean, etc.
– The main purpose is to ensure the team follows the Scrum process.
– Enabling teams and Organisation to naturally live with the values of Scrum.
– To coach/guide the team on the progression of their Agile journey.
Team/Teams/Individuals/Whole organisation
– Help the team no longer need you to help them.
– helping teams in their journey to become more collaborative and self-organised.
– Servant Leader to the team.
– A mirror to reflect back what the system is doing…or isn’t.
– over time, make themselves redundant to the team, to the PO and ultimately to the organisation.
Thanks to Ryan Behrman for the image of the different levels of intervention.
See how we can help.
You, your team, your organisation.
You probably want to go to the updated version of this post.
The paradigm shift that brought us lean-agile has swept across many fields such as architecture, art, literature, philosophy, and ultimately science. It has been a confusing, scary, wonderful and stunning wide-scale far-reaching cultural & social change started at the beginning of the twentieth century, and with many roots in the past.
Software developers have been among the firsts to wait for it and to enjoy its appearence, embracing it.
This shift took all of us from the industrial age into the information age, from the manufacturing mass-production task-work into the creative knowledge-work.
Before that, in the society, in the arts, in the sciences, in philosophy, and in software development, we lived under the tyranny of the illusion of a “rational design” by an omniscient designer that has all the information needed and enough time to analyse all of it, that knows it all, and that controls everything. And we lived under the illusion of a single law that entails and governs everything that happens.
This illusion influenced organisations’ structure and culture, their governance, management approaches, job roles, and way of working, in ways that never fitted modern software development.
The new paradigm shift came across with the awareness that there is no omniscient designer, we don’t have all the information or enough time to analyse all of it, we don’t know it all, and we can’t control everything.
It came with the awareness that, in professional software development and in the design of interactive digital products and services, there are not even first principles nor a single law that govern everything. Instead we learn as we go.
And still, we can make decisions effectively and take actions comfortably, at work as well as in our life: we participate in a human creative endeavour in a process of continuous experimentation, discovery, adaptation, and refinement, where the finale is not written until the end.
These are two key components of this exciting paradigm shift that replace the omniscient designer and the single law entailing everything:
– Co-creation: a form of deep collaboration where a pair, a group, or a crowd of people work closely together in a sequence of very short and focused iterations, sharing the creative space of their thought process, producing, reviewing, testing, and refining the outcomes of their collaboration;
– Co-evolution: a human creative endeavour where the understanding of the problem and the discovery of a solution evolve in concert. A solution is gradually developed and delivered to improve the understanding of the problem itself, that in turn leads to the next discovery of a new refined solution. This double act continues until a working solution is fully discovered and developed, and the problem is fully understood.
Co-creation and co-evolution combined together, enable us to effectively make sense of the many problems we face nowadays in software development.
The experience of collaborating and creating something together, with another human being, in a safe and creative space, is a wonderful, energising, and liberating experience. Once you have tried it and you have seen it at work, you don’t wanna go back to the old world anymore.
Co-creation and co-evolution, together with continuous learning, context awareness, and compassion, are among the social abilities and skills that are unique to humanity and are alien to artificial intelligence. All those very human abilities will be at the core of the next paradigm shift and the next revolution.
]]>You probably want to go to the updated version of this post.
Team vision and discipline over individuals and interactions over processes and tools
Validated learning over working software over comprehensive documentation
Customer discovery over customer collaboration over contract negotiation
Initiating change over responding to change over following a plan
We welcome emerging requirements, even late in development.
Lean-Agile processes harness change
for the customer’s competitive advantage.
Deliver value and validate learnings continually,
from a couple of weeks to a couple of hours,
with a preference to the shorter timescale.
Business and product people and developers and everyone else must work
together daily throughout the delivery effort,
from concept to cash.
Build products around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a business, product, and development
team is face-to-face conversation.
Delighted customers and business impact are the primary measures of progress.
Agile processes promote sustainable development.
The sponsors, developers, users, and all stakeholders
should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design
enhances agility.
Simplicity –the art of maximising the amount
of work not done– is essential.
The best products, architectures, requirements, and designs
emerge from teams in an environment that supports
and amplifies positive outcomes from self-organisation.
Continually, teams reflects on how
to become more effective, then tunes and adjusts
their behavior accordingly.
Reference: Horst Rittel and Melvin Webber, Jeff Conklin, 1967-2008. See http://en.wikipedia.org/wiki/Wicked_problems and http://www.cognexus.org/wpf/wickedproblems.pdf
Reference: Watts S. Humphrey, A Discipline for Software Engineering, Addison-Wesley, 1995. See http://en.wikipedia.org/wiki/Watts_Humphrey
Reference: H. Ziv and D.J. Richardson, May 1996. See http://www.ics.uci.edu/~ziv/papers/icse97.ps
Reference: Peter Wegner, Why interaction is more powerful than algorithms, Comm. of the ACM, May 1997.
See http://www.cs.brown.edu/people/pw/papers/ficacm.ps
Reference: Meir M. Lehman and Laszlo Belady, 1974-1996. See E-type programs in Programs, Life Cycles, and Laws of Software Evolution
and see http://en.wikipedia.org/wiki/Lehman’s_laws_of_software_evolution
Reference: McConnell, 2006. See http://en.wikipedia.org/wiki/Cone_of_Uncertainty
Reference: W. B. Langdon. See also http://www.cs.ucl.ac.uk/staff/W.Langdon/
See how we can help.
You, your team, your organisation.
The second book is:
Obliquity: Why our goals are best achieved indirectly
by John Kay.
Here you find suggestions on decision-making and suitable approaches to wicked and complex problems.
You also find historical notes on traditional management, from the rise of traditional management techniques in complicated domains during WWII and in Ford during ’45, to their fall in complex domains during the Vietnam war and in Ford during ’68.
You can find it here: https://www.johnkay.com/product/obliquity/
The third book is:
Coaching For Performance: Growing People, Performance and Purpose
by Sir John Whitmore.
When dealing with wicked and complex problems, in a socio-technical system, people are at the centre. Directive approaches with people are not fit for purpose here. This book provides alternative ideas and approaches, that are fundamental in today’s prevailing servant-leadership style.
You can find it here: https://www.performanceconsultants.com/coaching-for-performance-book (I prefer the 2nd and 3rd editions.)
The fourth book is:
The Solutions Focus: The SIMPLE Way To Positive Change
by Paul Z. Jackson, Mark McKergow
This book focuses on the alternative to directive approaches, especially for domains facing uncertainty, unknowns, novelty and change. The parallels with Agile are overwhelming.
You can find it here: https://www.johnmurraypress.co.uk/titles/paul-z-jackson/the-solutions-focus/9781904838067/
See how we can help.
You, your team, your organisation.
I’ve seen software developers arguing passionately and endlessly about trivial topics such as spaces vs tabs (coding style standards) without coming to a useful conclusion. Code quality is a very controversial topic indeed, but I’m sure you won’t pay for those arguments!
Nonetheless, in a quite useful turn of events, in the last 15 years the agile movement contributed enormously to expand the understanding of quality in IT.
Now our quest for quality can count on patterns (PoEAA, GoF, GRASP, etc), principles (SOLID, Demeter, Simple Design Rules, etc), heuristics of good and bad design (loose coupling, high cohesion, rigidity, fragility, etc), diagnostics (metrics such as cyclomatic complexity, Sandi Metz’s TRUE , etc), and practices (described in the previous post).
On the other hand, that understanding expanded so quickly, that the vast majority of the industry has not caught up yet. Most are still at the imitation phase.
Indeed, even in recent years, I’ve seen some business people systematically cutting down quality up to a point of bringing the project or product to its knees, and I’ve seen some technical people asking for time and resources to improve quality and then failing to produce the promised benefits. I’m sure you can also recall some epic IT failures from the news. You would not want that either, for your money.
Mastering those patterns, principles, heuristics, diagnostics, and practices – software craftsmanship – is the best way we know today to pursue the quality in the code. But it is not the whole answer! They all are a means to an end.
What is the end goal of code quality, what is the meaning of code quality for the business?
Here are few examples of end goals of code quality that support key tangible and beneficial business needs/wants:
This is the code quality that matters to the business as well as to IT. But how to achieve such quality?
When one blindly applies those quality patterns, principles, heuristics, diagnostics, and practices – that is what I call code quality cargo cult – it doesn’t work.
This is because practices are contextual. Principles, heuristics and diagnostics are broad and blind, abstract, and generic. Quality is elusive, subjective, relative, at times intangible, and it is in constant evolution, always changing in unpredictable ways.
To achieve the quality that enables exactly the business goals needed for the specific product/service, for its users and clients served, for value to be created, and for the current circumstances, one has to select and apply those quality practices in context, each one with the right dosage and the right timing.
The way to do this, is to try to improve the code quality in the best way we know today, measure the impact on business goals, learn what’s working and what’s not, and loop again.
That is the quality that’s valuable and meaningful for both IT and the business!
Thanks to Paul Eastabrook, Praveen Karadiguddi, and Uberto Barbini for their useful feedback and comments.
See how we can help.
You, your team, your Tech.
This deck linked below provides a complete list of competency areas that a great CTO needs. It includes the description of each area.
It also provides a radar to self-assess CTO’s strengths in those areas, and identify which area can be targeted next for further improvements.
– View and/or download the deck on Slideshare:
CTO’s self-assessment radars
Bonus track: The competency areas listed in the deck are related to the key responsibilities that a CTO has. So they can also be used by the CTO to verify that she/he is given both the authority and the means required to take on those responsibilities.
Bonus track two: The radar can also be used in a recruiting process, to describe the expectations and needs of an organisation for its CTO, and compare it with the CTO profile.
Now you can download the deck, self-assess where you stand, decide in which area you want to improve, identify which actions you can take to improve in that area, and find out what feedback you can collect to measure your progress.
See how we can help.
You, your team, your Tech.
State of DevOps Report 2017).
New technologies emerge every three to six months and a new paradigm shift happens every year or two.
Every new generation of IT professional wants to start from scratch, ignoring the past and creating new trends.
What yesterday was true, right, and good, today may seem wrong, disputable, or controversial. Which certainties can a CTO rely on?
This short booklet introduces fundamental building blocks of software development done right: a minimum set of practices for software development and IT departments that you should never neglect in professional software development.
You’ll find also references to conclusive scientific research studies, industry opinion, suggested reading material, information for assessing if each practice is properly in place or not, and suggested actions to improve in each area.
See how we can help.
You, your team, your Tech.