Scrum is all about Risk Mitigation
"All events, rules and roles are about risk mitigation. It helps to learn this to help organisations manage their risks better. Sadly, people generally don't see this simplicity of Scrum and treat it bigger than it actually is. This is done by implied other agile practices that are thought to be Scrum, but in reality they are optional practices. The framework has been designed to have add-on practices, and novices don't see this divide. The reality is Scrum is simpler than most people think it is. In essence it is creating frequent inspection points which allow conversations to change. It puts ownership and risk in the right places (product ownership, process ownership and development. It tries to get the best out of professionals and not treat them like workers. My recommendation is to all is really learn the simplicity of Scrum."
-- Brett Maytom, Professional Scrum Trainer
Leadership buy-in not optional
Early buy-in is obligatory for success
It is my opinion that you will need CEO level involvement at a very early stage. The Scrum Master needs to demand a position for Scrum Mastery, Agile Quality Analysis or Agile Coaching to be created and a seperate position for lead development. Do this at very early stages. You will need a leadership buy-in or you can save yourself the trouble and quit even earlier than you did.
Force Transparency upon the ones dwelling in the shadows
In case Product Owner or Team Manager do not foster the transparency of the project and especially technical debt - which is management debt - you should install whatever information radiators you can think of.
- Physical Scrum Board (we tried next-gen Smart-TVs in every room, conclusion: digital does not radiate at all)
- Newsletters (Reach depends on size of Company)
- Intranet Blog
- Talk openly about problems, point out successes and why
- Involve CEO level at Sprint Demos early on, if need be, against the will of laggards, like Product Owner or Team Manager
Try to achieve early SCRUM-level certification, even though the costs may be 1-2 of your monthly wages. Point out what such certification can do for the company, what it is worth for competitors and that they need to change in order to stay competetive.
You can do the scrum.org certification online for only about $150. But - you will not get the real-world experience like you get when completing the 2-day pathway with a certified coach. On scrumalliance.org you can only do the 2-day option, which will set you back about €2K. In the case you have an employer who is willing to pay for it, I would suggest you go that route, since you can even take the course with Jeff Sutherland, which tends to be excellent.
This is the first thing I did with my colleague in Sprint Zero, that openend both our minds, will and hearts that something new is to come. It truly empowered us to listen beyond the chatter of unit managers, to see beyond the masks of team leads, to start listening to each other in a different way and start forming a team of equals. If you don't do any retrospectives in your company, I suggest you drop everything right now and prepare one - and well prepared they must be. I suggest a practical handbook as source where you can get fresh and original coaching ideas, that will help open your colleagues up and will help everybody to find the real issues and impediments that keep you from performing. If you never heard of retrospectives, chances are extremely high that you are part of a low-performing team, where everybody works his ass off, but results are dissapointing nontheless. Nobody wants that, so I suggest you Agile-up and do something about it.
In our first retrospective, we drew little smileys that showed the state of happyniess of each worker. Everybody was unhappy. After the closing statements of the retrospective we drew another smiley and it still was unhappy one from every colleague. The real achievement here was honesty and transparency.
In our fifth Retrospective, we shut out the Product Owner from the retrospective again, because he literally behaved like a control-freak on steroids and everybody closed immediately up. The fifth retrospective was quite successful, because we had onboarded a new team-member who was a senior and from him many new inspirational demands arose. We identifid must-have learning sessions, team rules since managers left and came to our meetings when ever they pleased, without notice. The most important re-structure was to single-out Sprint Planning I from Sprint Planning II in order to make meetings shorter
The Burndown chart turned out to be the most interesting tool for our Product Owner and I am very glad he used it - to some extend. If he would have been smart he could have easily calculated the time we would have needed to deliver a minimum viable product. I estimated all Epics for him and he could have easily cross-checked that with the velocity we actually took for finished Epics. He didn't. So it is safe to say that he just used the Burndown to have a sense of control over the process, over the team. He only used it for stampeding in our office when the burndown did not go as expected. Every end of the quarter he claimed to CEO level that the software is finished now. So instead of embracing true reliable metrics as a chance to deliver and communicate transparency, our Product Owner chose to ignore the data, to continue in his absencing mission or on whatever mission he was on. Needless to say that the team started to present features that weren't ready, that the Definition of Done got blurred and technical debt rose. This shows how important it is that you have CEO-level on board. The highest level needs to dictate to those who only know dictating, that they need to embrace change or leave.
Burndown chart. Used by Hundreds of thousands of companies today. Really nothing out of the ordinary.
Below chart shows the Story Points achieved in each sprint. But since I wanted to show fluctuations of velocity when team members left or new ones onboarded, I called it Team Velocity Chart. The 5 Phases of team building: Forming, Storming, Norming, Performing, Adjourning have been typical to the fluctuations of our team. The failure to involve development team members in the hiring process and failure to keep high-potentials in the company resulted in a rather dissapointing sideways performance. But, having said that, we did rise from 30 SP to 60 SP in about 6 weeks, that is 100% increase of work performance even with all the obstacles put in our way by unit management. That's a win for tediously planned Retrospectives, Estimation Games, Sprint Plannings and other Agile methods that promote transparency, openness and honesty.
Release Burndown or as we called it, Team Velocity Chart.
Becoming a High Performance Team
Once we had the team manager shut out as SCRUM describes it, since he did not deliver one single line of code to the project, and his dictatorial, negative and fear-inducing methods were gone with him, the team started to perform. Ideas started to flourish and creativity sparkled. Everbody could see it that something great was in the making.
Just one of the many architectural changes my team came up on its own, after we started to do meetings without the team manager. The Team Manager almost always behaved cocky and hierachical and did not provide any space for the team to become co-creative. His deconstructive and insulting behaviour was identified by everbody as impediment in the very first Retrospective.
Connecting to the Ecosystem
Meetings with other companies that already did the switch to partly or 100% Agile and Lean Organisations of Trust, Transparency and Performance were absolutely obligatory in the success I achieved within the company that hired me. The ability to connect and learn from the big Pros of the business like from Wibas GmbH or Nadine Haertel helped and motivated me a lot to not give up and continue to mature processes and enhance team performance at my company. I am still in contact with many people from Agile Munich via the meetup.com Website and I highly suggest meeting with other companies and exchange experiences and best-practices. Oh, and it's absolutely free, thats how awesome the Agile community is.
Nadine Haertel, formerly Agile Change Manager at the Deutsche Telekom AG on her European-wide "A Coach on a Waltz Tour"
Wibas GmbH, one of the Ninjas when it comes to Large Scale Scrum. This company did the change to Agile for Volkswagen IT, Boston Federal Reserve and other well-known corporations.
Above graphic shows how old management wants to build a product. But its a dream, because the car in the end will be full of flaws and bugs because the process of roll-out, quality management and failure-handling never got matured. Thus, Agile builds upon delivering small increments of running products where Quality, Integration and Risk Managemetn has matured with each increment.
Software Projects start to slow down and even fail because management allocates time and plan from the beginning and the need to grow with changing business requirements is not recognised. Minimal arrangements like reading material for that coffeebreak are most of the time possible, but with growing project complexity and spectrum of requirements the knowledge of the development team is not growing fast enough to face these complex challenges.
"Analysis, Design, Construction, Testing", this order of working procedures works for classical product manufacturing, like tables or chairs, but with complex products and processes it fails. In conclusion complex development processes like software development is not a production process, but a development process, a process in which human and software absolutely need to constantly get enhanced and be refined.
Usual hierachical organisational models do not allow for teams to refine themselves beyond the usual individual review that takes place once a year. In these hierachical Industry 1.0 organisations there is no chance for teams to independendly learn along the way in a substantial fashion, make corrections in team culture and product or process, widen or narrowing the product's capabilities in order to react to the ever-shifting underlying business processes. By failing to achknowledge that the business world is a highly dynamic, multi-stake holder environment and the false assumption that a software system and the team building do not need to be highly dynamic such businesses that still organise in Industry 1.0 hierachies are rather sooner than later doomed to fail. The latest prominent example of failure to react to the surrounding ecosystem and failure of management to adapt to these changes is VW.
So how do we get a re-usable value out of a unplannable process, which is constantly evolving? The approach that works successfully for hundreds of thousands of companies is to clearly and boldly depriorise plannability, security and forecasting and prioritise the yield of innovation, adaptibility and changeability. This is today's premier approach to get a surplus value out of a development process in order to further mature it.
To succeed at this intensive task, leadership will not be able to continue to ignore the vast spectrum of each human's own ressources. The task at hand is to let go of responsibility and hierachy. Leadership must involve each employees ressources, and not only on a skill-level, but also on a management level, a creative level and a motivational level. Leadership and must convince middle management to let go of fear and let go of hierachical approaches of the past.
Agile offers multiple methods in order to activate each team members potential. First of all, get rid of impediments like people that are not actively doing any project work, let it be team managers or let it be project managers. This is why Agile needs the active support of highest leadership levels, because chances are that middle managemetn will resist to let go of legacy control structures that inflict fear, nurture lies and nurture egosystems.
When middle management accepts to serve rather than lead, you can start to do meetigns after meetings, so called retrospectives, where the team itself identifies impediments to the daily work and collaboration. The Scrum Master now can approach Middle management, or the team lead to get rid of these impediments. There are of course other meetings and brainstorms within the team where the important thing is to listen, listen, listen. Let the team members come up with ideas, architectural choices, important decisions and invovle them also at the hiring process. The credo is to invoke in each and everyone servant-leadership, the ability to respond, activation of own thinking-processes, the offering of co-creative spaces, in a physical and metaphysical sense. All this will help your team to shift from ego- to ecosystem and become a team become a real team and not just a phrase.
Agile does offer all this and helps you to become a high-performing team that delivers feature after feature without fear of any obstacle that may and will come along. Agile was co-developed by Toyota, the Grameen bank and Thoughworks. Jeff Sutherland and Ken Schwaber developed the Agile Manifesto. These people earned 1973 the peace nobel price for their works with Agile. Companies that employ Agile today are Spotify, Stylelight, Deloitte, Deutsche Telekom and mayn others.
Yearly Reviews of Scrum Masters in Hierachies
In my experience, yearly reviews serve as means to remind the guy being reviewed who pays his bills. There is absolutely nothing I ever took away from a review, than that, what I just mentioned. In all my reviews I was not only better prepared than my superiors, but also be prepared to give him feedback and insights into everything that is going on. Where is the sense in having true achievements that emerged throughout the business year, checked against a year-old matrix that was not just out-to-date, but legacy and downright stupid.
In Agile you do reviews in a co-creative, meditative and secure space, every two weeks and get out of the retrospective meeting with real achievements and outcomes for everybody and the business. I openly suggest to my colleagues, superiours and even interns or the leadership level to free themselves from the stigmata of being paid or be the payer and behaving as this would give them or their superior (superior in what exactly?) some strange god-given right to asses and judge you.
How exactly will it help an employee to tell him that goal xyz was not achieved during the financial year and he needs to do better. If you retrospective every two weeks on the other hand it will not only prevent your team from missing any targets, but it will come to constant re-alignment of goals and in the end of the year, most likely, to overperformance of these goals.
For instance, Deloitte now abandoned yearly reviews, because they recognized that they serve zero purpose - except giving the superiour a stage for displaying their monetary power over employees and thus the infliction of fear, alignment to outdated goals and nurturing of inflexbility and ignorance.
No lessons to be learned from such kind of review, no collaboration nurtured by them and no awarenessshift happening through them.
In my reviews, I usually just write down the goals that I accumulated in our highly-dynamic, multi-stakeholder business over the course of a year and put a tick next to each. Sometimes a cross. While my superiours' template has had always only two dozen and very vague goals listed, my template has had about over 50 goals listed and I can discuss them in detail, why they had become a necessity, where the benefit for the business lies, for the team, for product and process maturity, and weather there have been any problems or overachievements of these dynamically accumulated and matured goals.
After these kind of yearly reviews I conduct with my superiours it has always been my superior who leaves the meeting with deep insights and learnings, hopefully strenghtening team resilience, and business, at the very least it was a meeting making good use of his time. The day your superior can do that for you too - namely engage and inspire you in meaningful retrospective meetings, and laying off their stereotypical and boring roles of being a "Joker", a "Connector" or a "Senior" - that day - will be a great day.
Reasons that will lead to failure
Proudness & Fear
Product Owner is too proud to do any additional work
It may happen that you pointed out a Product Owner who is too proud to open his mind, will or heart to admit mistakes
let alone derive from own methods and facilitate change. It may also be that he or she thinks of himself as something better than his colleagues and subordinates and lets others always feel this by intention - up to a point that could be humiliating.
Failure to acknowledge or learn from mistakes
In a culture, where mistakes are overlooked and middle management is too withdrawn to admit mistakes or apologize to their staff for mistakes, chances are a process gets never further than stage one of the Capability Maturity Model (CMM).
Management is Careering instead of Contributing
Chances are high, that when you introdice Agile, the Team Manager will feel shut out, even though he does not contribute a single line of code.
In an environment where mistakes are not celebrated and learned from in order to mature processes it is very probable that senior staff will focus on careering instead of contributing to organisational change.
Leadership washes its hand clean
It may happen that the CEO level does not want to interfere in the hierachical organisation and would like to see problems "take care of themselves". In a hierachical organisation that is very unlikely to happen.
Anti-Agile Hiring Practices
It is very likely that the Scrum Team will not get involved in the hiring process. Team members leave and novices are getting hired. I have seen teams that consist to 95% of interns.
Talent leaves the company and take achieved process maturity levels with them. If no Agile was done before, code may be untested, not understood and impossible to maintain or grow.
Chances are the Scrum Master may get overwhelmed with inter-hierachical and organisational-political warfare, since he has to be an requirements engineer, a systems architect a data analyst and an active developer as well.
SCRUM often fails because leadership is not onboard and does not provide means, respect or support to the mountain of additional work a SCRUM master is facing, but often actively sabotaging her efforts.
No Information Radiator Provided
In legacy, hierachical environments it may happen that even though a Scrum Board was bought, it does not get mounted at an appropiate open space where it is accessible to all and can radiate information.
Overburdening the Scrum Master with work
It may very well happen, that the Scrum Master has to take on Product Owner responsibilities of ordering the backlog catalogue, identifiying the MVPs and informing the real Product Owner of things that go on at the Scrum Board, because a product owner may insist on his higher hierachical status and feels "too important" to take his new role seriously, let alone help to facilitate organisational change.
Failure of Middle Management to include team in project-related decisions
Management disrespecting an Agile Coach, simply "because they can", is a horrible excuse.
Important Project-related decisions are being made without the Scrum Master, without informing him or the Dev Team. Team Members are being re-assigned to different tasks during the Sprint, due to ignorance and hostility of the middle and lower management towards organisational change from within and towards Scrum, Sutherland, and yourself being somebody in a lower hierachical position than them. Management disrespecting an Agile Coach, simply "because they can", is a horrible excuse.
Failure of middle management to see value in servant leadership or co-creation.
"We are too big for that"
usualy goes hand-in hand with
"We are too small for that".
Nothing more than cheap excuses for the real underlying motivations of management to boycott change: fear about careering and ego, doubt about sharing leadership, lazyness to learn about lean and other hidden agendas like personal business projects that hinter management of real invovlemnt. exciting meetings over the usual hour-long sleeping sessions.
In the end chances are you will get your Scrum Master and other change fascillitators to leave. Please note that Process Maturity are leaving with them. The feedback your Company will receive in the developer scene is likely to be a bad one discouraging new talent to apply.
Failure of middle management to see value in TDD in order to manage technical debt
If management thinks all problems are the developers problems your project will fail. Management needs to acknowledge that the humongous task of eradicating technical debt is a management task, since their meticulously laid-out, yet useless waterfall plan will no longer work. If your management fails to introduce the management of technical debt as a streamlined process maturisation, your more complex projects will not only fail, but pre- and suceeding projects projects will stay slow, with huge amounts of ressources spend for support and troubleshooting.