I am a true believer in the power of team retrospectives (aka retros) – regular feedback simply helps to make things better, and to embrace what already is good.
Based on my experience, the main asset of a retro is to make people seen and heard. This breaks down assumptions and builds trust. When having retros as a routine, you definitely make things much less complicated because you bring up issues before they grow to be a huge monster. With retros, there is less guessing and more harmony, and people are empowered by being able to directly impact their daily work. Things don’t escalate because they are spoken up and are investigated regularly.
But I have not always perceived those only in a positive way. Retros need to be a continuous routine for the team and “easy to access”, not a thing that is organised only at the end of the project to reflect on what went wrong. A retro’s power is to glue a team together, not to be the tool to discover failures. If retros are conducted only when the need is to “learn from what went wrong”, they start to have a negative aura around them. That is my personal experience too – “Let’s have a retro for this sometime soon” has been an indication for me that things are not well, and it’s not nice waiting for the session. Especially when the issues could have been tackled much earlier in a more organic and more positive way.
Smart people want to make things work, together
But as an approach, convening a retro is also a great methodology to utilise, for example, in cases where we notice there is some tension between team members. In such cases, a well facilitated retro makes everybody heard, and as the goal is to find ways together on how to improve the situation, it tends to be an inclusive and successful way of figuring things out. Smart people want to make things work. These kinds of retros put a lot of emphasis on the facilitator, so it is good to choose the right person for this. Team members need to feel safe in order to be open and honest. The facilitator has a big influence on ensuring the environment for this and for the routine of having retros with a low-threshold – it should be hassle-free. Actions and other to-be-done things must be transparent and agreed together. Otherwise people might end up still pondering the roots and causes of issues after the retro.
Finding new business opportunities
Retros also speeds up finding new business opportunities and leads to experiments. I coached a team that started a routine of bi-weekly team retros and soon it became a successful vanguard for the rest of the organisation. They regularly expanded a team retro into a project retro, and while already having built trust and transparency, they were able innovate and growth hack as a kind of a side dish to a team retro. And as they had become a really self-organised team, it was easy for them to also run experiments on their projects and to add value to their client.
Retros help to cultivate the organisation’s culture. In every organisation and in every team, there is always room for improvement. Investing one hour regularly to bring people together, to discuss how could we do better, prevents making the same mistakes over and over again. When teams inspect their own work regularly and agree to change their behaviour in order to improve, they become more self-organised and self-directed. Teams being able to be open about the good, the bad and the ugly, creates transparency and trust. Organisational culture needs to be built on those.
Who can do it?
It is not only development teams that benefit from retros. Since retros are a powerful tool to cultivate organisational culture, management should do them too! Demonstrate how you want your company to tackle issues! Also, multidisciplinary teams should be brought together regularly; inviting other teams to join every now and then creates transparency and a sense of belonging for everyone within the organisation.
Who then can facilitate the retro? Take turns! You might first have a more experienced person to facilitate them, to get the routine up and running, but then start having rotating turns. By doing this, you uncover fresh perspectives and learn various ways to run a retro. Also, people again gain a sense of ownership for their own progress.
So, what can you do to improve your team and to add value for your customers?
- Book a regular slot in your team’s calendar to have the retro. Start with one hour but remember that retros get quicker as the routine repeats! 15 minutes is better than nothing!
- Google a suitable format for team retros, there are plenty to choose from. An easy way to start is by asking 1) what should we keep, 2) what should we do more of and 3) what should be do less.
- Start doing it.
- Remember to memo and share your learnings!
- For the management team also!
Also remember to utilise retros as soon as you notice that some people might need to clear the air between them! React quickly – don’t wait, highlight the goal of finding ways to improve together, and ask a kind and wise facilitator to host the retro in a safe and inclusive environment!
And the power of retros? Having retros makes people seen and heard. By doing so, people solve issues and improve things. This helps to cultivate resilient and innovative organisations, characteristics crucial for success, especially today.
Digital transformation coach
During the past two years, I had the luxury to be a part of a large-scale program that involved several development teams across the world. As an agile coach and scrum master of one of the teams, together with my colleagues, we built a development team that ended up being one of the best crews I’ve been working with so far. However, we didn’t get it right on the first – or even on the second try. There were some important lessons to be learned. In this posting, I’ve listed my three most important takeaways.
Encourage active and respectful face-to-face communication
Ideally, all the teams should be co-located. There is no better way than to simply walk to another person and to start asking those questions. This overcomes any other means of communication. However, in a global environment, this is not always possible. Thus, it’s crucial that, if there are multiple teams in different locations, you really need to go out there and meet those people. Or, alternatively, fly them over to your country and make them feel comfortable. This is a must and we learned it the hard way. If you don’t have the travel budget, pick it from your own pocket – I can assure you it will be one of your best investments for the project.
After you have made acquittances, use video conferencing tools as much as possible in everyday communication. It might feel awkward in the beginning, but again, it will improve how the teams communicate. If the other team does not have the equipment, it’s a great idea to buy them a proper webcam as a gift when you pay a visit.
Meeting people in person, having a laugh and working together, side-by-side makes all the difference. This will also enable people to establish common rules for working together more easily. Different cultures have different customs and e.g. ways of saying things. Like it or not, we also all have sub-conscious stereotypes of different countries and cultures. If the people you’re interacting with daily are mere virtual icons in your teleconferencing tool it easily becomes “us and them”. This is definitively not the setup to be in when you have to deal with more difficult issues.
So, in essence,
- Co-locate the teams, or fly them over to visit as soon as you can
- Get to know people, then use video conferencing tools and encourage relaxed communication
- Beware of “us and them”
Enable the team to evolve and remember to have a safety net
Preferably, the team’s composition should not change too often. Effective communication within the team, building an identity and your sense of humor will take some time, so be patient. Yet, setting the team composition in stone from day one might be problematic. The skillset the team needs at the very beginning of the project is usually different from the skills team members require over a longer period of time. In the beginning, you may need to have more specialists working with, say, concepting and service design. Later on, as the product evolves, the team might gravitate more towards operations or security-related topics.
An experienced team can identify these needs themselves, but it’s worth making this clear from the very beginning: changing the composition of the team is natural as the project evolves and everyone should keep their eye on whether the team has the best fit to deliver at a given time. Of course, the team is usually very capable of learning new things and sharing skills, as long as there is a decent time frame for this. Sudden changes will affect the psychological safety of the team, so avoid hasty decisions – involve the team, they know best what is required.
The chemistry within the team is something to look after. Even the brightest minds don’t work well together if the way of working simply does not match each other. Active discussion and even strong opinions are quite all right, as long as the team can work things out. However, very strong personalities can sometimes dictate discussion, even unintentionally. In this case, there’s a great danger of losing valuable insights and ideas. To overcome this, the team can take advantage of a plethora of tools available ranging from online anonymous feedback systems to tools used in retrospectives. Also, having an external coach to facilitate these discussions can prove to be valuable. The team should be coached towards non-violent communication and you should lead the example. As a last resort, don’t be afraid to make changes to the team. Having a fruitful working environment weighs more in the longer run, even in the case where the team might temporarily lose some technical talent.
Lastly, the team should take care of easy and fast onboarding processes. You will never know when one of your team members finds the love of her life or even a better job opportunity – which is on the other side of the world. For a highly efficient team, it’s a great safety net to make sure that whenever new team members are joining, they will get going as quickly as possible. It will improve the ability of a team to get back in the normal pace and reduces the anxiety of a new member of the team starting anew. Make sure everyone knows how to get started, where to obtain credentials and access rights, where to look for introductory tutorials and so on. And when the new team member joins the team, her insights and perceptions of the project might prove very valuable – especially with regards to the on-boarding process, but also on the project in general. The team might be blind to things and habits that have lost their value a long time ago.
Three key points regarding team evolution:
- Encourage people to step outside their comfort zones to learn new things – remember that changing the team composition should not be the first choice
- However, the skills needed in the project might change over time – involve the team to determine what is required at a given moment and then proceed
- Even the best teams will also face unexpected attrition, so be prepared
Be curious, challenge the status quo and empower the team
The same way as a newcomer to the team can see things differently, so the whole team can see the new project in a different light. There might be something very evident blocking the team on its way to success, which the team can immediately spot. So, challenging existing structures and the status quo should be encouraged.
When it comes to these blockers, there are many sayings, such as “it’s better to beg for forgiveness than to ask for permission”. With this kind of thinking it is often tempting to start from a clean slate. “Things would be so much easier and more fun if we simply ditched this box here and recreated it ourselves”. Sound familiar? Honestly, if you don’t need it, get rid of it. Still, it’s good to think twice before blindly overhauling all the existing processes and tools already in place. They usually are there for a reason. Before making any big changes, the team needs to understand how the underlying system of work works.
The other point of view is that a fresh team does not yet carry the weight of the organization. Hopefully, the team is free of any strong opinions regarding other departments in the organization. As no bridges have yet burned, the team might be able to approach different parts of the organization in a more neutral way and thus learn more this way. This should be encouraged.
The point is to actively seek the actual users of the system, even if (and especially when) it has not been the custom, or when there is a proxy entity representing actual end-users. What are the users really trying to do – do they actually need this system? This is often overlooked, or users are misrepresented by some other entity. There might be existing tools or structures, parts of the system, that are then, once again, recreated. But the team can easily go on for a long time before really understanding what it is actually building and for whom – or does it even make sense? Once the team really understands the real needs, it should be empowered to make even bold decisions regarding what really should be done next.
In the end, it comes back to active communication. Perhaps it’s about pointing out the elephant in the room no-one else is willing to see. Then, having the right people expressing themselves in a polite but decisive manner – and at the same time being able to express and reason themselves clearly – will make a world of difference.
- A new team has “fresh eyes” – try to benefit from it
- There might be existing structures that, in the end, serve no real meaning
- Understanding the system, i.e. what users are trying to achieve, is the key thing
From my experiences, I can guarantee that building a highly-effective team from scratch is challenging and will require some trial and error. If you work with a global customer and with different cultures and time zones, things will not get any easier.
There are many things to keep in mind, but always make sure that you communicate your intentions, what the team is currently doing and where you are heading next in the clearest and concise way possible.
Do your best to find the most suitable composition for the team. Try to keep changes to a minimum, but always remember to think ahead and have a plan B ready, if and when you are forced to change the team.
Encourage the team actively to seek a better way. Usually, things are in place for a reason and they can always be done differently. The trick is to know whether the features the team is implementing are actually taking the product forward from the real customer’s point of view or are they merely feats of engineering. And finally, always remember to ask why.
Have you ever been really into your work but didn’t have anybody who shared your enthusiasm when you started gushing about it? Do you work as a specialist in a multi-functional team and don’t seem to have direct support for challenges related to your specific domain? At Gofore there might be a guild that could help, or maybe you need to start one?
About a year and a half ago the project I was working on restructured which lead to our scrum master leaving and me transitioning to the role of scrum master. Our product owner was also replaced by a team of three product owners. Simultaneously the project goal changed from a proof of concept to get a release of the product out in three months so the number of developers was also ramped up. Because our team was made up of experienced developers already familiar with the product I found myself in a situation where most of my time was focused on getting the product owners on track with their roles. After a couple of sprints I realized that I hadn’t had a chance to even assign myself a ticket, I had transitioned to a full-time scrum master position. While I have several years of experience as working as scrum master and developer I quickly realized that being a dedicated scrum master was a very different role.
My perspective drifted away from the product I had been building in the proof of concept phase and I started focusing on how the team was working not what it was working on. I wasn’t as interested in what decisions the product owners were making but on how to get them to make any decisions at all. And then I realized I was the only person on the team focusing on these issues. I started wondering how similar issues were handled in other projects at Gofore and how I could ask our more experienced scrum masters, product owners or project managers about these issues, so I invited them to lunch.
Since I had been working in project management roles earlier I had a company credit card and reserved a table at a nearby restaurant for lunch and invited everybody working at the Helsinki office who I knew had worked or was working in a scrum master role. I think the offer a company-sponsored lunch combined with curiosity led to around seven people coming and we shared news and thoughts about our project work. Since everybody didn’t have a chance to talk about their project I decided to have another lunch or breakfast the following month and I promised to organize a doodle for the date. This quickly became a monthly thing.
I didn’t ask anybody’s permission to organize these lunches, I just used my own judgement that they were needed. Being true to the Gofore spirit of transparency I was as open about the costs and the time I spent organising the guild lunches as I could be. From the beginning, our lunches were a bit fancier than your regular working lunch, because I thought that it is important to communicate that we as a company value learning from each other. Also having the meetings outside the office gave a sense of detachment that you don’t get in a familiar meeting room.
I happened to mention about these lunches we were having to our Lead Coach Heini while I was visiting our Tampere office and she informed me that I had started a guild.
On the train, on the way back from meeting Heini in Tampere I changed the name of the page recording our lunches in our confluence to the Agile Leadership Helsinki Guild. There are some other guilds in our company but their role hasn’t been strictly defined. Each guild is a bit different in how they work, but they all relate to professional development. Ever since the beginning, sharing and sparring project-related challenges have been a staple of our lunch meetings. At some point, I stopped doodling and we agreed that our lunch date would be on the last Thursday of each month. It was easier that way, and knowing the lunch dates several months earlier makes it easier to reserve the time needed to be away from the client.
We started having short introductions to agile related subjects at the beginning of the lunches. This was a great way to share experiences when somebody attended a conference or external training. At some point, Anu joined me as the champion for the guild and having a dedicated person with whom to share guild related ideas with made guild work a lot more fun. We started organizing training sessions outside of lunches that were directed to guild members as well as open for others at Gofore. The latest thing our guild has done has become a platform for helping members go to conferences and on external training courses.
I gave up the position as guild champion at the beginning of the year and the current champions are taking the guild forward and doing stuff I didn’t have time for. I am still actively involved and enjoying having a community to reflect my project work, Agile Finland work and Agile Transformation and Lean capability work.
Lessons learned from starting a guild at Gofore
While I had a useful experience from working with volunteers in the scouts and in university organizations, this was the first time I had started a completely new organization or community. This gave me the chance to reflect on my previous experience in volunteer leadership, combined with formal academic knowledge from Knowledge Management studies at university and professional project management experience. At Gofore we have many social clubs (or Glubs as we call them) where like-minded colleagues come together to discuss everything from investment opportunities to the latest beer to be launched. Guilds help unite people over professional interests compared to glubs leisure focus. If you have an interest, professional or extracurricular, starting a community around it at Gofore is a good way to network with your colleagues. There are now many guilds covering a wide variety of software solutions and related fields like design. Below are my experiences of setting up a guild for Agile leadership, but they apply for setting up glubs as well.
- Having a personal need to fulfil when starting a new project helps when you need motivation or need to pivot.
- A guild is a community so starting one is really hard.
- Starting a community is basically a culture change or creation project.
- When starting aim for consistency with minimal effort.
- You can never over-communicate or over promote guild related events or issues.
- Culture change projects need a champion so don’t worry about things being personified to you.
- Because it’s voluntary don’t be afraid to make choices and do the work even when you don’t get feedback.
- It is great to have a community for sparring your project work and personal development.
- The strength of the guild comes from the fact that even though participation is work time it still voluntary so people participate from their intrinsic motivation.
- The biggest obstacle for people participating in professional self-development work like guilds is loyalty to the customer and interesting customer projects.
I believe it is important to keep up to date with developments in your professional area of interest. Gofore guilds are a great way to, not only keep up to date with professional developments but also to network with like-minded colleagues. It’s great that Gofore actively support and encourage guilds and glubs. Connecting with your co-workers over shared interests is a great way to contribute to the collaborative and supportive working environment.
Dave Snowden says that human intelligence is especially based on utilizing patterns. “Our ability to link and blend patterns … gives us the ability to adapt to a rapidly changing context and, critically to innovate”. Metaphors, patterns and stories are the most powerful tool of explanation, knowledge transfer and teaching. We have a limited capacity of information processing capability, but it is not the basis of our intelligence. One group of people make decisions purely based on information processing, and they are autistic. Whether you are communicating a feature in a software project, or a marketing vision of a large enterprise, the best way forward is to communicate it as a story or as a metaphor.
A best practice is a method or technique that has been generally accepted as superior to any alternatives because it produces results that are superior to those achieved by other means. You may find best practices for example in agriculture, medical and manufacturing. Software development has its own best practices. Agility, continuous improvement, prioritization, active communication, design patterns, QA and CI/CD. Agile manifesto itself is a list of best practices. For a seasoned expert, these sound like a no-brainer. Well, how on earth do projects still fail?
While working as a Scrum Master, one realizes that while pursuing well-known best practices, the same bad practices keep popping up again and again. These bad practices form a list of common pitfalls, which are called antipatterns or in an Agile context ScrumBut. The antipatterns can be used as-is, but they are most effective when used side by side with the best practices. Work towards the best practices. Work away from the anti-patterns.
Sprint is too short or too long
- Too short a Sprint (less than a week) increases the ratio of bureaucracy beyond an acceptable level. Too long a Sprint (a month or more) makes it hard to react to customer requests and the feedback loop becomes too long.
- The best practice is to keep the Sprint a bit on the short side, so the feedback and correction frequency stays fast.
- Too long a sprint also allows one to create mini waterfalls inside a sprint
- Often is better
Sprint produces nothing working
- Whatever was developed during the Sprint must be running in at least the QA-environment at the end of the Sprint.
- When software is not integrated, tested or deployed during the Sprint, work will overflow to the next Sprint. This means that it is impossible to change direction between the Sprints. One must first pay off the technical debt that has been created in a form of non-functional code. If nothing new works after the Sprint, the speed is 0.
- Often the “almost ready” features require days of work to finish. You can speed up the completion of difficult tasks by having daily status checks. In the most critical situations, the best way is to set up a “war room”, where everybody concentrates only on finishing or fixing a single feature.
- The best practice is to finish the earlier task before starting a new one.
- Stop starting and start finishing
No (real) Product Owner
- The Product Owner prioritizes and clarifies.
- The Product Owner provides a list of the most important Use Cases and a detailed description of each. The task of a Scrum Master is to tell if those features fit into the next Sprint. The less you start, the faster you finish.
- A common malfunction is a customer who wants software to be developed but doesn’t commit to the development process. Either there is no Product Owner, or the person is too busy/doesn’t know the domain/doesn’t have the authority to make decisions. In this situation the Scrum Master should coach the customer; book a weekly meeting with the customer representative where the roadmap is being clarified and broken down into detailed tasks.
- The best practice is for the Product Owner to have a detailed plan for the next few Sprints.
- The task of a Product Owner is to maximize the value of the Agile team
Requirements are not communicated
- A big up-front requirement specification helps nobody.
- Use Cases must be communicated between the Product Owner and the development team before the development work starts.
- The development should never be based only on a document. This will always cause the first version of the software to come out as unsatisfactory. It is much faster to clarify the details over a telco, than to code-test-integrate for weeks and to find out that the requirement spec wasn’t top notch.
- Coding a non-communicated requirement creates useless technical debt.
- The best practice is to have a clear and shared plan for the next few Sprints
- Prioritization forces the team to have important discussions regarding the content and their importance. What user group to serve first? Non-functional or functional first? New features or regulations? The common symptom of “no estimates” is that the Sprints produces nothing functional.
- It’s the team that estimates the stories being planned for the next sprint, and it’s the team that commits to do their best meeting the sprint goals.
- When the Use Cases have estimates, it is easier to prioritize and plan their development. It is also easier to identify the cases, which need to be divided into more fine-grained Use Cases. Estimates are created semi-automatically when the requirements are communicated to the team. When the Product Owner clarifies the Use Case and the team divides it into technical tasks, estimates will emerge. Estimates will also inform the team velocity. If you divide all stories to roughly similar sizes then you can skip estimation and just count the number of stories.
- The best practice is to have a clear and shared plan for the next few Sprints
- No prioritization usually leads to starting too many Use Cases. This leads to Sprints that produces nothing.
- Incorrect prioritisation also delays feedback on critical decisions, while the team develops something irrelevant.
- The best practice is to have the product backlog prioritized for the next couple of Sprints. It should be fairly easy for the Product Owner, Scrum Master or the Architect to explain the Use Cases of the next few Sprints.
- The best practice is to start nothing new before something finishes AND then start the highest priority task.
- Less is faster
- Each Sprint should provide the team with feedback. The customer gets the demo. The team gets the retrospect. Each Sprint is a step towards better practices. One aspect is the project management tools with their analyses and reports.
- The best practice is to produce a functional demo and have a Sprint Retrospect. Repeat, the best practice is to have a retrospect after every Sprint.
- Reflect regularly
- The best way forward is to support or coach the inefficient team member. Usually, people are not lazy but too busy. Mentoring and coaching are good ways forward.
- The best practice is for everyone to keep developing and improving.
- Each team member must allocate time for self-development
- The team must be able to self-organize. Team members must be able to work individually, but more importantly they must be able to work as a team. Shared ways and common rules. Cherry picking when choosing tasks, coding too low or high quality, forgetting the common rules etc. are signs of a hot-shot not able for teamwork.
- The team must allocate time for team development
Doing the right things at the right time
Agility means making the right decisions at the right moment. Traditional management models are more interested in doing things right. This leads to an inside-out way of thinking. “We have a CMMi5 level quality standards”. And still, the customer gets no additional value. Such management creates tons of additional bureaucracy without creating anything useful. Agile development advances with the best possible speed towards the best possible direction. Speed and direction are revised constantly when new information and feedback emerges. In sports, one improves agility by doing neuromuscular exercises in a well-rested condition. The same goes for knowledge work. Stress, fatigue and haste kill agility; Work becomes stiff and laborious. W. E. Deming stated that 95% of performance issues are caused by the system itself and only 5% is caused by the people. Even talented people will fail if the system does not give them room and freedom to prosper. Organize outside-in. Customer first.
Exploring ScrumBut—An empirical study of Scrum anti-patterns
A fixed project always fails
Why to scale Agile
How to scale Agile
Reflect the ways of working in your organization
I’ve recently attended Agile events where world-class gurus state that Scrum is broken, the Product Owner is a waste, or LESs is better than SAFe. Tools are built for a purpose. You can use a tool for a certain purpose only in a certain context. When the context evolves, the tools also need to evolve.
What does not change, are the underlying principles. Misuse of a tool is easy if you don’t understand the principles. There are tons of studies regarding ScrumBut, where the Scrum tool is abused. Where the (Agile) principles are not followed, even if the (Scrum) tool is in use.
Maturity of the Organization Defines the Context
According to Reinventing Organizations by Laloux, in today’s predominant organizational model the leader in the hierarchy turns a cog that directs the workers below. Planning and execution are strictly separated. This leads to silos, rigidity, no innovation, no responsibility, no ability to advance meaningfully in the career. Laloux divides cognitive, psychological and moral maturity into five levels*. Higher levels build on top of the lower ones.
|Tribal – “Red”||A simple hierarchy to steer work and a wolf-pack mentality||Mafia and Startups|
|Agrarian – “Traditional”||Large organizations with numerous roles and steering mechanisms, like long and medium-term planning. Planning and execution are strictly separated. Control what and how. Thinking happens at the top, doing at the bottom. The underlying worldview is that workers are mostly lazy, dishonest, and in need of direction.||Church, military and government|
|Industrial – “Orange”||Profit and growth are the most important measurements. Achieved by the means of innovation, accountability and meritocracy. RnD, Marketing and Product Management departments are invented. Control what. The underlying worldview is based on material success.||Multinational companies|
|Information – “Green”||Focus on culture and empowerment to achieve high employee motivation. Highly sensitive to people’s feelings. All the perspectives deserve equal respect. Where Industrial level seeks to make decisions top-down, based on objective facts, expert input and simulations, Information level strives for bottom-up processes. Information level brings opposing points of view to eventual consensus. Where Industrial level views organizations as machines, the dominant metaphor of organizations in Information level is the family. It seeks fairness, equality, harmony, community, cooperation, and consensus.||Culture-driven organizations|
|Adaptive – “Teal”||“Post-postmodern consciousness”. No bosses, no competition. In this mindset, ego is viewed from a distance. We can see ego’s fears, ambitions, and desires: In the Tribal level, a good decision is the one that gets me what I want. In the Traditional level, decisions are determined by social norms of what is right and wrong. In the Industrial level, effectiveness and success are the yardsticks. In Information, matters are judged by the criteria of belonging and harmony. We use measures of inner rightness: Does this decision seem right? Am I being of service to the world?||Network organizations|
Summary of Laloux’s levels of organizational development. The names and colour codes come from Lalouxs’ book, however, they were different in the original work of Beck and Wilber.
Both consciousness and adaptability grows with the maturity of the organization
According toLaloux, in the highest level of maturity (“Adaptive”) we don’t pursue recognition, success or wealth. We pursue a life well lived. Still, the consequence might be recognition, success, wealth, or love. Adaptive organizations reveal three major breakthroughs: evolutionary purpose, wholeness, and self-management. These major breakthroughs make organizations prosper given the right context. Companies like Buurtzorg, Patagonia or Zappos show strengths of the Adaptive level:
- Employees thrive
- Salaries above market rates
- Grow year in, year out
- Achieve remarkable profit margins
Adaptive level brings three organizational breakthroughs:
- Principles driven decision making. Rather than trying to predict and control, Adaptive organizations try to sense and respond. Similarly, as the Cynefin framework describes working process in the complex environment, that consist of “unknown” factors. The output cannot be planned predicted, but one must proceed with principles driven decision making in an environment where it is safe to fail. Like Stephen Covey says “There are three constants in life: Change, choice and principles”.
- Wholeness creates an environment of safe conversations. Safe conversations invite deep listening, authenticity and vulnerability. It is assumed that everyone seeks for the common benefit, even if their opinions seem different. Conflicts are dealt with understanding. This will create smarter networks, unleash creativity and bring higher employee satisfaction. Like Douglas Stone says “The urge to blame is based.. on the fear of being blamed.”
- Minimum Viable Management does not mean a free-for-all. It means form-follows-need: Roles are picked up, discarded, and exchanged fluidly. Power is distributed. Decisions are made at the point of origin. Innovations can spring up from all quarters. Meetings are held when they are needed. Temporary task forces are created spontaneously and quickly disbanded again. The leaders of self-managing organizations feel, that it is less risky to deploy self-managed teams. That self-managed teams make better decisions. Like Bruce Lee stated “It’s not the daily increase but daily decrease. Hack away at the unessential.”
These three principles enable the organization to better handle uncertainty, complexity and magnitude of nowadays Agile business. Adaptive organisation work efficiently and fast, while fewer power games and egoism is in the way of creativity. More effort is used on improving individuals and organizations.
Where to Start
Team of Teams by McChrystal underlines the idea of creating nimble, transparent, and horizontal organizations. Organizations which empower their people to execute based on the concept of ‘shared consciousness’. People are empowered to trust their gut and use their best judgement based on their training and knowledge of organizational goals. The book gives good ideas of
- Break down organizational silos by sending liaisons to other teams
- Empower everyone to make decisions, don’t act as a decision bottleneck
- Hold frequent sync up meetings to disseminate information
- Set up cross-disciplinary open-plan workspaces
- Enable people to make decisions at lower in the hierarchy and get to know their counterparts in other teams
- Be a gardener. Plant and provide water and nutrients. No heroic micromanagement
- Monitor data and real-time information, but stay away from control-freak and micromanagement.
From hierarchy to networks (Team of Teams way of drawing the idea)
Need for Speed
- Formal: the official organizational chart and the job descriptions
- Extant: how things actually work and who really makes decisions
- Requisite: a setup that would be most natural and best suited to the work and purpose of the organization.
The Idea of The Holacracy is to achieve the requisite organizational structure. Holacracy’s systems and processes are about helping the organization find its own unique identity and structure. In Holacracy, a pyramidal hierarchy is replaced with “circles” dedicated to specific functions. Each of the circles has a “lead” who, like a traditional manager, is responsible for assigning work and seeing that it’s completed. They, however, are not responsible for determining how the work is done. A kind of company-level crowd-sourcing.
From hierarchy to networks (Holacracy way of drawing the idea)
Fit For Purpose
There are no good or bad ways to organize. The question remains whether the structure is a good fit for the task at hand. Mature levels are better suited for the purpose of more sophisticated work, with high complexity and high skill set. And lower levels are better suited for crisis situations. The organizations are far from consistent and are a mix of both. The maturity of an organization is influenced by the context and by the leader of the organization.
Back to Scrum
Scrum is not an absolute value. Just a tool. Originally Scrum was a counterattack to Waterfall. From fixed scope to work decomposition, fast feedback, retrospectives and being close to the customer. The idea of Agile is to create high value to the customer by means of collaboration, demos, improvement and being open to change.
In this context Scrum is a process to take an organization to the next level of maturity. Scrum gives the management a feeling of top-down control by managing the product backlog. Simultaneously Scrum provides the team with a freedom and safety to make bottom-up decisions. At some point, there is no more need for the safety provided by the hierarchical Scrum mechanism. Similarly, you may evolve from component teams to feature teams.
What makes the tools like Scrum, Kanban or SAFe work are the underlying principles like
- Agile (https://gofore.com/agile-transformation-action-part-1/ )
- Lean (https://en.wikipedia.org/wiki/Toyota_Production_System )
- Systems Thinking (https://gofore.com/en/what-is-systems-thinking-and-how-should-i-use-it/)
- Cynefin (https://en.wikipedia.org/wiki/Cynefin_framework)
Agile is about adapting to an unclear situation by using regular feedback loops and prioritization. Lean is about regular retrospectives and improving the ways of working. Systems Thinking and Cynefin teach about system dynamics and how to operate them.
Keep the principles in mind and use them as your guiding force. Build on strengths and potential. Understand the context where you operate. Each context presents different dynamics. Keep in mind the ‘fit-for-purpose’ of each tool. Any tool can be abused if it is used following the wrong principles. Consequences are governed by principles, not by the tools. Therefore, value principles.
* The evolutionary model presented comes originally from Don Beck, whose work was borrowed by Ken Wilber.
In the software business, the (project) management role is useless. You need a high-level visionary who states the (business) vision. Let’s call her a product owner, and you need a change catalyst who makes the stuff happen. Let’s call her a scrum master. Two levels. No middle-anything. You don’t need middle-level, mid-term planning.
Culture of experimentation, MVP and overall agile principles lead to early value creation and early failure. You don’t have expensive software project failures because they fail early. You have finally learned to manage successful software projects. The only secret is to skip the middle-term planning. Just create a long-term vision and start experimenting.
Men are naïve
Men are driven by the need for certainty. This results in an inflated need for middle-term planning. “What are the 1H2018 features being delivered, their exact schedule and budget?”. Nobody can answer truthfully. You could state honestly “we will aim to fulfil the basic features of vision X during the next 3-6 months with the current team”. Or you can act like a professional project manager and come up with a detailed feature plan and exact estimates. We all know, such a plan is as trustworthy as the six-month detailed weather forecast.
There is no room for old school project management. Project management in a sense of deciding up front what, when, how and how much it will cost. The main reason for project management existing in the current software business is for sales reasons. Fixed price projects are nice to sell and easy to buy. That’s called a pig in a poke.
Reductionism is reductionist
Reductionism means that you can solve a problem by breaking it down into smaller parts, solving the small problems and then putting it all back together again. This works in a simple environment. In a complex environment, the pieces of the system are not the sum of the parts. When you have a complex problem, you need trials. Try and fail until you find a satisfying solution. Small investments can be made into safe-to-fail experiments in a balanced portfolio before we commit more resources. Cynefin explains in detail the different environment types.
Correlation does not imply causation
The assumption that past practice leads to a future deterministic solution is valid only within an ordered system with common context and stable, known constraints. You must understand the difference between correlation and causality. With enough data, you can find a correlation between anything. “More people drown when they eat more ice cream”. You can use data-driven decision making only in a simple environment where you know the constraints. Problems arise when work is based on wrong assumptions. Don’t ask: Has this worked before? Ask: Is this the right direction to take? This question forces you to stop and reflect on the situation.
Manage high and low
You need some management. There is no such thing as a self-organizing organization. However, you need to choose wisely what and when to manage. You must constantly evaluate the outcome of the latest short-term sprint and keep an eye on the long-term vision. Don’t spend your time planning mid-term roadmaps of how to achieve a near-term vision. At the best such roadmaps are useless and at the worst they are deceptive. No mid-term planning what so ever will help you in the future.
Stop and think
Today, more than ever, proper management is needed. You need to think and reflect on the situation daily. If you allow yourself to get caught up in the bureaucracy to the point where you don’t have time to stop, think and reflect, then you are damaging not just yourself but the whole organization. Being busy is not the same thing as paying attention. Requiring status PowerPoints doesn’t steer the work or create transparency. You cannot create objectivity in a complex environment, your own subjective judgement is required. Requiring simple reports is laziness. Understand the needs of management and acquire the needed information. Preferably through intelligent conversations.
As a manager, you can either spend quality 1-on-1 time with the people in the downstream, or you can wait for things go south. Stop and reflect regularly. Not just when it is a New Year.
Simplicity at the Heart of Agile:
Dave Snowden’s 12 Shibboleths of Christmas:
How Google Sold Its Engineers on Management:
FURTHER READING FROM THE GOFORE BLOG
We are always on the lookout for skilled developers to join our award-winning team. We have exciting projects running throughout 2018 in Helsinki and Tampere – get in touch to find out more