When people feel they have no influence on the organizations goals, they become disconnected from the products they build and won't perform at their best. Many organizations try to compensate this by applying pressure to force people to conform to processes, hoping to achieve better results. More standardization means less individual influence, which in turn leads to further disengagement and is typically countered by even more standardization and pressure. What could be done to break this vicious circle? Join me in this second part to review the twelve Agile Principles and see how they form the foundation for a sustainable, engaging corporate culture.
A lot of organizations develop their products with a project mindset. Projects have a defined start and scope, which they deliver when they are finished. PMBOK [1], The Project Management Body Of Knowledge, describes itself as the Standard for Project Management. In its PMBOK GUIDE it provides processes, models, methods, artifacts and tools to plan and execute projects. "Follow the plan in order to produce the output the organization desires!" could be seen as the motto when applying PMBOK.
So is planning and standardization a bad thing per se? Not at all. The Agile Manifesto, however, states the preference of 4 different values over those found in today's project-minded organizations:
- Individuals & Interactions over Processes & Tools
- Working Software over Comprehensive Documentation
- Customer Collaboration over Contract Negotiation
- Responding to Change over Following a plan
Shifting the focus to these 4 preferred values, provides a basic idea about the changes needed to build an engaging sustainable culture. It, however, isn't very specific in terms of day to day practices. Enter the Agile Principles [2].
Twelve agile principles
- It's all about delivery
- Embrace change
- Deliver frequently
- Close cooperation
- Trust and motivation
- Face 2 Face
- Working software
- Constant pace
- Quality is a mindset
- Keep it simple
- Teams self-organize
- Inspect and adapt
It’s all about delivery
Our highest priority is to satisfy the customer through early and continuos delivery of valuable software.
Trust is the basis for successful cooperation. Oftentimes, organizations attempt to compensate a lack of trust by formulating lengthy contracts regulating details of the cooperation they are about to enter. These attempts seldomly succeed, for various reasons, some of which have been discussed in the previous post. Delivering a working, valuable (even if only a little in the beginning) version of the product to your customer goes a long way in regards to establishing and building trust as the basis for your relationship. By handing over working software at the agreed upon point in time, you demonstrate reliability. You made a promise and you kept it.
By making the product valuable for your customer you also show an interest in the success of your customer. Both are core ingredients of building trust. Continuosly doing so will strengthen this foundation of your relationship to withstand the fiercest conditions imaginable.
Embrace change
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
As stated in Part One, changing requirements are nothing but enablers for building a better product. Formulate the wording in your contract so that it becomes easy to incorporate change without harming any of the parties to the contract. Giving our customers competitive advantage is a key ingredient to Developing Digital Champions here at iteratec.
Deliver frequently
Deliver working software frequently, from a couple of weeks to a coulpe of months, with a preference to the shorter timescale.
We have established that by delivering valuable working software, we build trust and strengthen the relationship with our customer. By delivering frequently, we can remove risk from developing new kinds of products by shortening feedback cycles. As soon as we are able to provide our customer with an updated version of the product, they can start collecting feedback to evaluate if the changes we made positively affect the end users’ appreciation of the product. Shorter intervals in delivery mean smaller changes requiring less investment. Little investment with rapid validation drastically reduces risk.
Close cooperation
Business people and developers must work together daily throughout the project.
Sadly, this remains an ideal in my experience so far. From those instances where I had the chance to work with actual users of the systems we were building I can however say that any specification written by the most proficient analyst pales in comparison. Admittedly, at times you’ll face impediments due to different ways of thinking and the resulting miscommunication but these can typically be resolved with nothing more than constructive, solution-oriented communication. Close cooperation, ideally on a daily basis, means establishing super fast, turbo-charged feedback loops. On steroids.
Without the close cooperation the people building the product are forced to either defer work back for clarifiaction, or make assumptions about omitted details. Deferring back introduces delays, which leads to dissatisfied customers and users. Working based on assumptions results in baking these assumptions into the product. This can lead to significant rework when, at a later point in time, it turns out that the assumptions were not (entirely) correct. Both Delays (“Waiting”) and Rework (“Over Processing”) are considered waste or muda in lean manufacturing/software development which is based on the kaizen philosophy.[3] The band for implementing Close Cooperation can range from inviting business people into cross-functional teams for intense cooperation, to a lightweight model of making business people available for answering question while they continue their regular work.
Trust and motivation
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
A couple of paragraphs above I argued that it is important to establish trust as the foundation of successful partnership between parties entering a contract. The same obviously is true within your organization.
By providing a working environment where people can contribute their ideas, views and values to the project they are working on, you foster identification with the product being developed. This identification is what sparks intrinsic motivation, which leads to people bringing more of their ideas into the project, thus, creating a virtuos circle. It is however important to note, that for creating such a self enforcing positive feedback loop you can’t rely on external motivators like money or promotions. They can take you a couple of steps along the way but in contrast to intrinsic motivation you need to up the dose regularly in order to retain the motivational effect. Also note, that delegating responsibiliy like described here, requires people being ready to accept it. If you start out in a culture, where people have been conditioned to defer responsibility to processes, you first need to work with them unlearning these unhealthy habits.[4]
Face 2 Face
The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation.
As human beings we rely on pictures and language to convey information. Looking at how information flows in a typical setup, it becomes clear how misunderstandings find their way in almost any spec I have ever read and/or written. There is the proverb that a picture is worth a thousand words. However, it seems that the higher the precision or the more abstract the information we want to convey is, the more we are inclined to rely on language.
In order to transport information from one individual to another, the sender must build a mental concept of what they want to communicate. This mental concept must then be described using words. Ideally, we would use the language we are most proficient in for that, more realistically seen that will not be the case in our global economy. So by translating that mental image into language for transmission of the information we are bound to lose some of the information contained in the mental image.
The recipient then repeats this process in reverse order. They process the language to build a mental model from the encoded information. This translation is most likely also not lossless, since the recipient can only use their own context of experience for decoding the message. Will the mental image the recipient has reverse engineered be the same as the one the sender had in mind? Most likely not.
The tree swing comic is a famous example that depicts this nicely. It dates back to the 1960ies, and shows different interpretations of the same information being passed from individual to the next.
Tree swing cartoon as an example of information drift caused by passing through multiple proxies
By ensuring there are as few intermediates as possible, we can reduce the loss of information transmitted and, thus, increase its quality. Ideally the communication is direct.
So far we’ve discussed indirection caused by introducing proxies. Another way of impeding the flow of information is by solely relying on written information. Writing something down can be helpful for remembering or looking up details about information one already had available. It is however, no sufficient substitute for face-to-face communication, as it only reliably transports the factual side of communication, but is omitting or distorting the self-revelation, appeal, and relationship sides of communication.[5] While the actual content of the message is transported via the factual side of communication, the instructions for how to interpret the content are usually embedded in the other 3 sides. Omitting them, forces recepients to make assumptions about the meaning of the message from which they are expected to reverse engineer the mental concept.
Working software
Working Software is the best measure of progress.
When one organization, or part thereof, contracts another to develop a product, it is only natural that the contract issuing party will want to be kept informed about the progress of work. Afterall, they not only want to see their money put to good use, but need to plan their own business based on the state of the development. As the contracted party you could compile sophisticated reports painting a picture of good progress. These reports, however, might or might not be worth the paper (or email) they are conveyed on.
Observing your typical orginazation you’ll find that the view of the state of a project becomes skewed, intentionally or not, by being reported up the chain. Managers higher up in the hierarchy, or customers for that matter, oftentimes learn about problems only when it is too late for them to act. The best they could do is take the blame and hope that people closer to the project will fix things.
Doesn’t sound like the type of manager or customer you know? You’re probably right. But can you honestly blame them? As long as information is hidden from them, they are left empty handed with no means to take corrective action. The term Watermelon Reporting[6] has been coined by Marc Löffler to describe reports showing projects as green on the outside, while they are red with a coulple of sprinkled black spots on the inside. Such reports could be compiled intentionally, out of fear of repurcussions, or unintentionally by omitting details that are perceived as irrelevant. If however, the current version of the acutal product is being used as the measure of progress, there is no intentional or unintentional skewing of the status.
Be aware that this can scare the living daylight out of people who are used to hide behind such reports or processes. Transparency can be brutal.
Constant pace
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Wait, what? “Sponsors, developers, and users” are mentioned in the same sentence and are as one referring to constant pace? Well, in contrast to the traditional customer vs. vendor roles relation, in agile we believe in and foster close cooperation between business people and developers. Sponsors channel their demands in an agreed upon way to the Developers, who is converting them into product features on which users provide feedback. In order to achieve constant pace, there must be a constant stream of information flowing from business (new features, respectively more details on product features to be improved) to development, to users and all the way back to the sponsors. The inability of the three to work in sync, severly impedes the continuing development of the product. Think what would happen, if no new requirements were communicated to the development team, for example.
But there’s another reason to aim for constant pace. When it comes to predicting delivery dates and scopes, we typically rely on previous experiences and project based on these when work will be completed. Apart from a steady flow of information, there are a lot of factors that contribute to variations in pace. Some can be controlled directly, e.g. (re-)assigment of team members, steady flow of information. Others can be influenced, e.g. people leaving the company due to unhealthy working atmosphere, or excessive crunch time. Then there are a few that simply are beyond our control, e.g. team members falling sick. If we have a steady base for a reference, our predictions will be pretty reliable. If, however, our reference is all over the place, the variation will transfer to our prediction. Of course, we could fall back to statistical tools like calculating the average, but when was the last time you communicated the statistical error of your prediction along with a delivery date?
Quality is a mindset
Continuous attention to technical excellence and good design enhances agility.
Coming from the traditional definition of quality as the absence of bugs or flaws, you might be wondering what technical excellence and good design have to do with quality? While the absence of bugs is a given, a high quality product is so much more.
Imagine you start working on a new product. You have a vision of what your product will be. This vision is the basis of your initial design. Along the way you learn from the feedback you are getting that some of the initial assumptions were not spot on and need to be adapted.
This most likely means that you also need to adapt the product you have built so far. As long as you paid attention to good design and executed development with technical excellence, this should not be too complicated. If however, the features you added to your product so far were just patched onto each other, you will most likely have a hard time separating the parts you want to drop from those you want to keep.
Another side effect of good design is testability. Testability here refers to automated testing. Having a suite of automated tests which covers the relevant aspects of your product provides you with the confidence needed to even make the most extensive changes to your product, because you can rely on the tests to tell you if the parts you wanted to keep are still working as intended.
Keep it simple
Simplicity – the art of maximizing the amount of work not done – is essential.
Read on if the part about maximizing the amount of work not done hasn’t already sold it.
The enhanced definition of quality from above, as a system that can easily be changed with high confidence, is obviuosly easier to achieve for products with less features. This is where simplicity comes into play. Another way to put it is fit for purpose. Does the system do what it is expected to? If so, stop working on that feature. Anything you add increases complexity and introduces the risk of malfunction.
The YAGNI principle (You Aint Gonna Need It)[7] is a good measure to avoid clutter as a result of preparing your products for features to be built in later. Obviously, there are some choices you have to make in order to move forward that have a greater reach than the feature you are currently building. In software these are referred to as architecture.
And while you might be tempted to go for the bigger design, in order to be prepared when the other features will be approved, you should ask yourself how likely it is that the decision will be made in favor of enough of them to justify the bigger design along with the cost incurred to maintain it until the decision is made opposed to keeping it simple and adapting when necessary. More often than not you will find that simplicity is essential.
Teams self-organize
The best architectures, requirements, and designs emerge from self-organizing teams.
When teams self-organize they formulate a plan for how to complete all tasks required to reach the agreed upon goal until the agreed upon point in time. They then execute said plan by following up on who is doing what. By doing so, not only are they in a position to make multiple decisions in parallel, it’s also the people with the deepest knowledge taking the decisions.
Compare that to a setup where the team would need to consult a manager for approval on each decision. Approvals could only be given one after the other, after the expert on the topic has briefed the manager during which they would most likely give a recommendation anyway. In addition, these briefing and decision meetings could only be held when said manager has time. Everybody else needs to wait, i.e. we’re introducing delay[3].
This could be a necessary compromise in a situation where your are transforming from a command and control type organization to an agile one, where teams and individuals would need to re-learn taking responsibility for their actions.[4] In that case regularly review and adapt the level of delegation to move to self-organization on the fastest possible constant pace. In an organization with self-organizing teams, managers manage the system not the people.
Inspect & adapt
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
In addition to feedback-based learning about the product we are building, the same principle is applied to the processes and tools the team uses. Afterall, we not only want to build better products, but become better at building them as well. Potential areas for improvement range from tools used, to processes and rules to be followed, to team dynamics. Teams either self-organize or fall back on coaches or similar functions to facilitate the room for reflection and adaption.
This wraps up the recap of the principles, ideas and intentions of Agile. They are the rationale guiding my actions when I work with customers and development teams, as well as in private contexts. Now is the time for you practitioners to take a hard look at yourself in the mirror. Are you part of the agile industrial complex, just hording credentials? Are you a true believer, walking the walk one transformation at a time? Or is it too early to tell, because you are just not sure how to bring the Agile Manifesto and principles to life in your work? Fear not! I’ve got you covered.
In the final part of this series of posts "Applying The Power of Basics" we’ll have a look at where and how the agile principles are applied in Scrum.
Quellen
[3] See The Seven Wastes | 7 Mudas for a brief overview of the 7 wastes associated with manufacturing.
[4] You can turn to Management 3.0 and the unFix model for tools and guidance to redesign your organization and its culture.
[5] See das Kommunikationsquadrat, Schulz von Thun Institut (available only in German) or Four-sides model on Wikipedia for a brief summary in English language.
[6] See Watermelon Reporting on Marc Löfflers Blog
[7] See Yagni on Martin Fowlers Blog for more information
Christoph Murczek - works at iteratec as a passionate Product Owner and Scrum Master by conviction. He is the founder and main organizer of the Vienna Scrum Meetup, a forum for discussions about agile ways of working with more than 2.500 members from India to California, resp. Sweden to South Africa.