Modern Agile Principles: Agile work made easy
Everyone is talking about agility. And between you and me, the subject has become rather confusing, hasn’t it? Recently, Felix Stein collected 240 agile certifications on his blog, in what is certainly not an exhaustive list.1 And to understand Deloitte’s overview of agile methods, you almost need a university degree.2
Perhaps it’s worthwhile at this point to put all these methods, processes, frameworks and certifications aside and focus on what really matters in the end – the axioms of agile work, so to speak, the basic beliefs that guide all further thinking and acting. And as Simon Sinek has already summarized so succinctly: we should “start with why”.3 So – why work (more) agile?
Even if terms like “market leader” or company ranking lists suggest otherwise, you can’t “win” business. After all, winning requires an end, which is obviously not the case with economics – that’s where the game continues. Whether we were first or last in the table last year is of no interest at all for the coming year. The best possible result for any company can only be to survive in the long term, in an environment that is constantly changing and placing new demands on it.
Not being able to meet these external changes in the long term means the end of the organisation, usually through insolvency and/or break-up. One of the most important characteristics of a long-term successful organisation is therefore adaptability.
Principle beats rule
If adaptability is our goal, rules (in the sense of “if-then” instructions), regulations and processes must always be viewed with caution. After all, we can only regulate what we can imagine – but very few companies have been destroyed by foreseeable events. Instead, by over-regulating, we force people into a dilemma at every major surprise – do they ignore the change and risk losing touch with the market? Or do they ignore the rules and risk disciplinary consequences?
To put it a little sharper: The mere fact that employees bypass the rules and structures of the company on a daily basis keeps companies capable of acting and thus surviving. An organisation in which every work step and every communication follows predefined procedures is neither feasible nor desirable.
Rules are therefore by their very nature unsuitable for dealing with changes in the market. They are replaced by principles guiding action. A principle requires interpretation in order to be used, so the question must always be asked what the principle means in the given situation and how it should be applied.
Instead of regulating all possible procedures in inflexible processes and thus making people largely interchangeable, we proceed exactly the other way round: the intelligently thinking, situationally acting person moves to the centre of the action, decisions are made individually, locally and according to need. In other words, different people act differently in different situations, the balance of power in the company shifts in favor of customer-oriented, decentralised areas. We not only accept this, it is even the logical consequence of a consistent situation and customer focus.
Against this background, an ideological debate about concrete methods then seems a bit silly. Agile methods like Scrum are tools, and like other tools, they are used in a situation-specific way to solve a concrete problem. To “convert” all teams to Scrum is just as meaningless as to let all carpenters work with a jigsaw. The method has to fit the problem, i.e. it has to be chosen and applied by the people who best understand the problem to be solved locally. Instead, it is important to jointly agree on principles that guide action and provide orientation towards customer and result focus in unexpected situations – and then leave the concrete implementation of the principles to the teams.
Modern Agile
Let’s look at an example: When my current team was founded about two years ago, we jointly selected the four “Modern Agile” principles4 as operating guidelines. For those who don’t know it: Modern Agile is an open community, created by Joshua Kerievsky at the end of 2015, which refreshingly does not require certifications or consultants. The four principles of the community describe the cornerstones of agile work at the personal and team level, and have since then had a decisive influence on our work. In my opinion, however, they are not sufficient as a basis for complete agile organizations; here I would refer to ideas such as the BetaCodex5.
Principle 1: Make people awesome
The central factor for economic success is people. Especially in one of two decisive roles: People who buy our products and services when they solve their problems – we call them customers. And people who develop and offer these products and services when they find a suitable working environment – we call them employees or colleagues.
We inspire customers by solving their problems accurately and elegantly – we make employees great by creating a working environment in which they can focus on solving customer problems together. I would venture to put the thesis into perspective: if you have enthusiastic customers and great employees, making money will be a solvable problem for you.
This all sounds banal now, but in practice it is a demanding task. Among other things, we have to find out exactly what problem our customer has. If you think it’s trivial, think about why a person buys a drilling machine, for example – usually not because they want to drill holes. Neither do people book plane tickets to fly, or buy a milkshake because they want a drink.6
Making customers awesome means understanding their problem deeply and comprehensively, and solving it in a way that fits effortlessly into their everyday lives.
To ensure that company employees are able to solve customer problems in a great way, it is important to provide them with everything they need quickly and easily – whether it’s work materials, information, time, money, decision-making authority, support or a framework. Any hindrance to their work, for example in the form of bureaucracy, regulations and processes, needs to be found and removed, or at least reduced to the legally required minimum. An easy way here is to view employees as “customers” of the central administration – typically they know very well which products and services of the organisation they want to use as valuable support and which not, if they are allowed to use them.
If you don’t want to stop here yet, in the first principle there is still enough food for further improvements:
- For example, what can you do yourself to make your colleagues outstanding?
- How can the organisation support its partners and suppliers in their work?
- Could it perhaps even be advantageous to support the competitors, for example to build up a common market from which everyone would benefit?
The elbow mentality is not required here, the aim is rather to develop a prosperous ecosystem around itself. “If you want to travel far, then travel together”.
Principle 2: Deliver value continuously
No matter how good a solution to a customer or employee problem may be, it can only begin to create value once it is up and running. A new product or service is therefore largely worthless until the moment of first use. My friend and colleague Tom Strube puts it slightly differently: “Business value is only a hypothesis until it is confirmed by the market.” This means that unusable products and services represent a considerable business risk, which becomes even greater the longer and more complex the work phase before the first customer contact.
In order to reduce this risk, new ideas therefore need contact with the “real” world as soon as possible, so that they can be further developed early and continuously through customer contact. A simple product on the market is therefore preferable to a powerful product on paper. Or even looked at in a different way: Products can and should be in development and live operation at the same time. Here we see obvious parallels to ideas like Scrum (“Software in 30 Days”) and concepts from Lean Startup (“Minimum Viable Product”) and New Work (“Permanent Beta”), even if these methods are often misused to implement far too large projects without customer contact, but in small steps.
Principle 3: Experiment and learn rapidly
At this point we should not fall into the trap of thinking that we know the problems of customers better than they do. In all probability, we have not even understood exactly what problem customers want to have solved, let alone how the solution must fit into our customers’ everyday lives. So the third principle is to remind us to constantly review our assumptions and procedures, to reflect on our thinking and actions, and to constantly work on our own improvement.
In order to promote joint learning, it helps to validate assumptions and hypotheses with small, manageable tests – not in the sense of an unreflected “just do it” actionism, but consciously, intentionally and well-considered. Early and continuous involvement of users in product development is a sensible application of this principle, as are regular, joint retrospectives to improve cooperation. Users and development teams interact directly with each other – the days of project and account managers as “interface” to the customer are over.
Principle 4: Make safety a prerequisite
Extensive planning, fixed procedures and detailed role descriptions are not suitable for long-term success in complex, volatile environments. But turning away from these tools means increasing uncertainty for those involved: decisions are made as late as possible, nothing is ever final, everything has to be negotiated individually. Questions about how to deal with risks arise in a completely new way: Is our money really well invested with the new partner, even if the delivery object is not precisely defined? How well does the project team understand the customer requirements? Can we be sure that our actions will be goal-oriented even without a long-term plan?
This makes it all the more important not to let uncertainty turn into insecurity. On the contrary: in order to be able to adhere to the other three principles at all, it is crucial that the environment is as free of danger as possible for the people involved, i.e. that people do not have to worry about their money, their lifetime, their health or their reputation.
Safety therefore means psychological safety at work, for example in the sense of a Prime Directive.7 But it also means not simply calling for more courage and a “culture of error”, but to assume in principle that mistakes will happen and to actively shape the environment in such a way that they will be noticed early and cause only minimal damage. None of us wants to become the next Knight Capital8, no matter how appreciatively a disaster of this kind is handled internally.
Practices from eXtreme Programming, such as Code Reviews, Pair Programming, Test and Deployment Automation or test-driven development show how software development can be made safer – for other areas of the organisation there is certainly something to be learned here as well.
The four principles only work in combination. Without safety, no rapid joint learning process can take place. Without a learning process it will be difficult for us to deliver valuable information on a regular basis. Without delivering value, we will not be able to make customers awesome. Without safety as a basic requirement, the principles will collapse like a house of cards.
Conclusion
Why principles-based action? Especially in view of the current popularity of methods, consultants and certifications, I would like to take up the cudgels for self-thinking at this point.
In an environment in which the four principles mentioned above are consistently applied together, the choice of the “right” agile method is of secondary importance. For a team that acts confidently, learns quickly, and makes clients great by continuously delivering valuable results, detailed questions such as estimation poker, user story formats and sprint lengths are of little interest. And we can clearly see in practice that these tools alone do not automatically lead us into an economic El Dorado.
But what I personally find most charming about the principle-based approach is that it has no preconditions. None of us need approvals or resources to be able to act according to our own principles – and whether our organisation, or even that of the customer, is “ready for agile” is not important either. All we have to do is constantly align our actions with the principles:
- Does it help people to be awesome?
- Does it contribute to delivering value on an ongoing basis?
- Does it support our mutual learning process?
- Is it safe for everyone involved?
Acting together that meets these four conditions can only make us more successful in the long run. And success, to complete the circle, is ultimately the reason why we do this with agility in the first place.
Notes:
Additional German articles by Kai-Marian Pukall can be found at Inspect & Adapt and LinkedIn.
[1] 240 agile Zertifizierungen im Blog bei Felix Stein
[2] Overview of agile methods from Deloitte: https://medium.com/tech-sojourna/7-things-wrong-with-deloittes-agile-tube-map-641192e20068
[3] Simon Sinek, Start with Why
[4] Modern Agile Principles by Joshua Kerievsky
[5] https://betacodex.org/
[6]Understanding the job: Milkshake
[7] Prime Directive
[8] Knight Capital
Kai-Marian Pukall has published more posts on the t2informatik Blog:
Agile risk management – do we need it?
Clarifying roles in the team
Decision-making ability – the success factor of teams
Kai-Marian Pukall
Kai-Marian Pukall works as an organisational consultant for Seibert Media GmbH. He has been accompanying agile teams for many years, always with the aim of making collaboration valuable and professional, simple and people-friendly. He prefers to apply the Lean principle “Eliminate Waste” to everything that smells like method and business theatre.