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.
Scrum on vain työkalu. Tässä esiteltävä vakiomuotoinen Scrum on lähtökohta, josta on hyvä lähteä liikkeelle, kun aloitetaan ihan alusta. Pidempään yhdessä toiminut ketterä tiimi voi muokata Scrumia loputtomiin, tai vaihtaa toiseen työkaluun kuten Kanbaniin, tai Scrumbaniin. Prosessisuunnittelussa kannattaa ajatella ”Love the problem, not the solution” – rakasta ongelmaa, älä ratkaisua. Tällöin asiakkaan tarpeet pysyvät päällimmäisenä – eivät omat hienot ideat tai idealismit, joihin on aina niin helppo rakastua. Samaa tarkoituksenmukaisuutta ja jatkuvaa kehittämistä peräänkuulutettiin aiemmassa blogissani.
Määrämuotoinen Scrum prosessi on turvallinen ensimmäinen askel ketterään kehitystyöhön, missä isomman tiimin kesken rakennetaan pidemmän aikaa jotain uutta. Scrum ohjaa lyhyen ja keskipitkän aikavälin suunnitteluun, sekä säännölliseen palauteluuppiin niin sisällön, kuin työtapojen suhteen. Jos tehdään nopeampirytmistä ja reaktiivisempaa työtä, niin virtaustehokkuuteen ohjaava Kanban on parempi organisoitumismalli. Jos taas tehdään jotain pitkälle etukäteen määriteltyä, niin voidaan palautesykliä harventaa ja edetä enemmän vesiputousmallin kaltaisella prosessilla.
Scrum itsessään on paradoksi; samalla kun ketterät periaatteet vaativat yksinkertaisuutta, Scrum määrittelee melko mutkikkaan prosessin, jonka käytöstä, hienosäädöstä ja kehittämisestä on kirjoitettu lukemattomia kirjoja. Schwaberin prujussa vuodelta 1997 Scrum kuvattiin alkujaan ytimekkäästi:
- Ennen peliä analysoidaan tilanne ja tehdään projektisuunnitelma; mitä, kuka, milloin, mitä maksaa
- Pelin aikana pyöritetään Scrum sykliä
- Pelin lopuksi julkaistaan, dokumentoidaan ja vedetään yhteen miten projekti meni.
Ja nyt kaksikymmentä vuotta myöhemmin Cockburn taas pyrkii omalla The Heart of Agile kampanjallaan palauttamaan mieliin, että Scrumin ketterät periaatteet ovat yksinkertaisia:
- Kunhan tiimi tuottaa jatkuvasti lisäarvoa, niin prosessilla ei ole niin väliä
- Tiimi päättää miten toimitaan
- Arvioidaan aktiivisesti mitä ja miten toimitaan, sekä pyritään parantamaan
- On olemassa vastuuhenkilö, jonka vastulla on reagoida ilmeneviin esteisiin (Scrum Master)
- On olemassa vastuuhenkilö, joka päättää liiketoimintatavoitteet (Tuoteomistaja).
Scrum perustuu ketteriin periaatteisiin, jotka ovat tiivistettynä:
- Tiimin tuottama lisäarvo muodostuu usein ja säännöllisesti asiakkaalle toimitettavasta, toimivasta ohjelmistosta.
- Asiakkaan prioriteetit saavat muuttua. Projektin edetessä opitaan lisää ohjelmistosta, käyttäjistä, sidosryhmistä ja toimintaympäristöstä. Tämän myötä on täysin ymmärrettävää, että lyhyen aikavälin tavoitteet muuttuvat. Toisinaan myös pitkän aikavälin tuotevisio muuttuu.
- Kaikki projektiin osallistuvat ovat motivoituneita, innostuneita ja tasa-arvoisia. Vaikka projektissa seurataan tiettyä prosessia ja rooleja, niin aktiivinen kommunikaatio on tärkeämpää, kuin itse prosessit.
- Ihminen on sosiaalinen eläin, joka kommunikoi tehokkaimmin kasvotusten. Tämän vuoksi olisi hyvä ajoittain tavata kasvotusten.
- Työssä seurataan jatkuvan parantamisen sykliä, jolla pyritään parantamaan toimintaa, niin ohjelmiston, arkkitehtuurin, prosessien, yhteistyön, kuin motivaation ja innostuksenkin kannalta.
- Pyri kaikissa edellä mainituissa yksinkertaisiin ratkaisuihin.
Sen sijaan, että iso joukko ihmisiä toteuttaa isoa asiaa pitkän aikaa, Scrumissa pieni joukko ihmisiä toteuttaa pientä asiaa lyhyen aikaa, mutta säännöllisesti integroiden kokonaiskuvan kirkastamiseksi.
KUVA: Pilko ihmiset 7 +/-2 hengen tiimeiksi
KUVA: Pilko asia niin pieniin osiin, että ne on mahdollista toteuttaa yhden iteraation aikana, yhden tiimin toimesta. Järjestä osat tärkeysjärjestykseen siten, että eniten lisäarvoa tuottavat ja vähiten työtä vaativat asiat tehdään ensin (weighted shortest job first)
KUVA: Pilko aika lyhyisiin 1-4 viikon iteraatioihin, joista jokaisen päättyessä demonstroit sidosryhmille koodin toiminnallisuutta aidossa ympäristössä
Scrum tunnistaa 3+1 roolia
- Tuoteomistaja vastaa tuotteen työjonon hallinnasta. Tuoteomistajan vastuulla on huolehtia, että tiimi tuottaa mahdollisimman paljon lisäarvoa sidosryhmille.
- Scrum Master auttaa tuoteomistajaa ja kehitystiimiä Scrum prosessin optimoinnissa, sekä poistaa esteet.
- Kehitystiimi on joukko aktiivisia ja yhteistyökykyisiä kehittäjiä, jotka rakentavat toimivan ohjelmiston ja rakentamista tukevan kehitysympäristön.
- Sidosryhmät ovat ulkoisia toimijoita, kuten loppukäyttäjät, hankehallinto tai muut Scrum tiimit.
Scrum prosessissa on 4+1 vaihetta. Vaiheet ovat aikarajattuja, eivätkä koskaan mene yli ajan.
- Sprintin suunnittelu: Kehitystiimi valitsee tuotteen työjonon yläpäästä sen verran käyttötapauksia, kuin uskovat sprintin aikana saavansa toteutettua. He asettavat yhdessä sprintille sanallisen yhden lauseen mittaisen vision. Tämä tavoitevisio yhdessä valittujen käyttötapausten kanssa muodostavat sprintin projektisuunnitelman. Kesto 1h per viikko, eli jos 2vk sprintit, niin 2h suunnittelupalaveri.
- Daily Scrum: Tiimiläiset kertovat vuorollaan
1) mitä saavuttanut edellisen dailyn jälkeen,
2) mitä aikoo saavuttaa ennen seuraavaa dailya,
3) mitä esteitä tavoitteelle on.
max 15 minuuttia, teknisiä keskusteluita voi jatkaa dailyn jälkeen, mutta dailya ei venytetä.
- Tuotteen työjonon kirkastaminen: Tuoteomistaja, tiimi ja tarvittaessa paikalle kutsuttavat sidosryhmät pilkkovat ja tarkentavat tuotteen työjonolla seuraaville sprinteille priorisoituja käyttötapauksia. Tuoteomistajan tavoitteena on kirkastaa seuraavien 2-3 sprintin suunta. Tiimin tavoitteena on auttaa tuoteomistajaa tässä ja ymmärtää tuoteomistajan seuraavien sprinttien visiota. Tämä on luonnollista aikatauluttaa puoliväliin sprinttiä, eli 2 viikon sprintissä joka toinen viikko on sprintin suunnittelu ja joka toinen viikko työjonon kirkastaminen. Kesto 1h per viikko, eli jos 2vk sprintit, niin 2h kirkastuspalaveri.
- Sprinttikatselmointi: Demotaan ylätasolla projektin ulkopuolisille sidosryhmille, kuten loppukäyttäjille ja bisnesihmisille, mitä on saatu valmistuvassa sprintissä aikaan.
- Retrospektiivi: Scrum Master vetää tiimin avustuksella yhteen miten edellinen sprintti sujui. Saavutettiinko sprintin visio, valmistuivatko valitut käyttötapaukset, onnistuiko demo, mikä meni hyvin, missä on parannettavaa. Näistä valitaan muutama parannusehdotus seuraavaan sprinttiin kokeiltavaksi. Kesto 45min per viikko, eli jos 2vk sprintit, niin 1:30h retro.
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 Finland, Germany and the UK – get in touch to find out more