In his excellent book, The Workplace Within, Larry Hirschhorn provides a lengthy analysis of the Challenger disaster. Among the many events that led to the crash, the one that strikes us most is the notion within NASA's management that every successful launch of the space shuttle reduced the risk of a disaster. Many at NASA knew that the faulty O-ring seal that led to the disaster had potential to fail but management’s growing optimism with each launch increased the frustration and helplessness among engineers.
The Agile Manifesto guides us to avoid such disconnects. When choosing a topic for Agile Practitioners 2016, we wanted to identify detrimental symptoms in organisations and look at how they may contribute to drifting away from agility. We wanted to highlight the values and principles that help organisations avoid their own disasters.
This article is intended for newbies and agile sceptics who want to challenge their take on agile.
We came up with 10 ways to successfully fail your agility, implying that by replacing these practices with ones that do the opposite, you will increase agility and improve the odds of having successful launches.
1) Lack of leadership support
Management must be involved and committed.
At NASA, engineers knew about the faulty seal. Obviously, neither they nor management wanted a disaster. Going back to basics, the Agile Manifesto tells us “Business people and developers must work together daily throughout the project.” The word “must” is carefully chosen. If management ultimately represents the business, this means they should spend time working on the shop floor, feeling what it is like to be an engineer at the company. Being involved and committed means being in the trenches — holding the project’s own “O-rings” to understand what engineers are talking about.
At an independent software house, the VP of R&D called in an agile-consulting firm to transition the organisation. During initial training, the VP expressed scepticism about the concept of Scrum. Not wanting to force her own opinion on the teams, she spent time with the engineering teams to observe how they work. She saw for the first time how testers and programmers worked together to accomplish valuable increments every week. “I don’t get it,” she told us, “but everyone, including the customer, is happy-happy, so it’s not about me at the end of the day.” From that point, she began to let go of her commanding style, which was prevalent in the organisation.
2) Missing or inadequate purpose for the transition
The company must decide what it wants from agile.
Becoming agile is hard work. It requires continuous practice, breaking old habits, and adopting a new mindset, to name a few challenges. It means tweaking the culture, and that requires investing a lot of energy in the organisation.
If the problem you are trying to solve is not clear, it will take even more energy to keep your momentum. Start by defining what you want from becoming agile and keep refining those goals. And, no — because everyone is doing it is not a good enough reason to adopt agile. You must look your own problems in the eye to figure out why you want this change.
At a large enterprise, top management chose agile to increase time to market (TTM), improve quality, enhance communications, and become more adaptable to change. But management did not prioritise the goals, and TTM and quality kept conflicting and interfered with any improvement in communications. The four goals were all but forgotten after a while, owing to these incoherent purposes for the transition.
3) Organisational structure and roles that are incompatible with agile
The existing team structure must not get in the way of getting to “Done”.
Management roles must not prevent a servant-leadership/learning culture
The Agile Manifesto tells us “The best architectures, requirements, and designs emerge from self-organising teams.” Teams cannot self-organise if they depend too much on one another — for example, if a development team depends on a testing team to advance its work to “Done”, the teams likely will exhibit unhelpful behaviours towards one another such as blame culture or apathy.
By the same token, strong or coercive leadership is likely to invite dependency on the leader, leaving little room for innovation and creativity. Since our industry relies on innovation and creativity, we want teams to become fertile environments for them. Diversity in role and task within the team are key to that.
Build your organisational structure according to the value that you want to create, so people can work more independently and depend less on managers — who in turn can instead help those same people excel.
A large government organisation is implementing Scrum in their software R&D department. The software QA, BI, and DBA are in separate departments. Whenever the R&D team needs support from other departments, the R&D team lead has to approach the team lead of the other departments to ask for their time. Members of the R&D team feel that they must respect the other, non-agile, teams and feel pushed into a waterfall-ish culture.
4) Broken-build theory
Not fixing problems is an indication that it’s okay to have poor quality.
In the 1980s, the broken-window theory suggested that ignoring small crimes such as vandalism would indicate to a population that more serious crimes would also be ignored. Later, the mayor of New York City, Rudy Giuliani, adopted this approach and tackled small crime. When vandals broke a window, it was promptly fixed. Police were trained to deal with offenders and to help empower the community to address acts of petty crime rather than to overlook them. The results were staggering. Notoriously dangerous areas of New York City became some of the safest. Despite criticism of the non-scientific nature of the research, this approach has been successfully applied in other cities as well.
The analogy to software organisations is almost self-explanatory: if you ignore the broken build, that bug, or that spelling mistake, you are sending out signals that it’s also okay not to write unit tests, not to refactor, or not to develop according to the requirements. This is how you shape the standards.
The alternative? Don’t bother to look for the culprit, just fix it. Be an example of the standards you want to reach, and praise those who follow that example. Others will then do the same.
A software development team kept complaining how other teams’ work caused them to fail and miss their target: “When they improve their work, we can start looking at ours.” One day, the Scrum Master (SM) installed Jenkins and borrowed a large screen to show the build status.
On the second day, the build became red. The SM and an engineer started investigating, and within an hour they found a bug in another team’s code. Within three hours, the bug was fixed, which could have taken weeks before the new setup.
A few weeks later, the SM started experimenting with JUnit. Once that got going, he experimented with automation of RESTful APIs (solely a tester’s responsibility until then). Gradually and consistently, this team’s members keep pushing boundaries towards fixing their broken windows and growing their sense of professionalism. Their frustrations have become increasingly episodic instead of a state of mind.
5) Rigid gated process
Traditional methods can get in the way of Getting Things Done.
This one dates back to the 17th century or even earlier. “I think, therefore I am” is a source of Cartesian dualism, the belief that mind and body are separate; you either think or you do. Frederick Taylor, inventor of scientific management in the late 19th century, interpreted Descartes’s insight to mean that thinking and planning should be separated from manual labour. In software development, these approaches tell you that you can either think about designing, coding, and testing or do them — but not at the same time. You should plan how and when to do each. It’s not exactly agile.
The Agile Manifesto states “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely” — not phase by phase but all the time.
Rigid gates, such as market (MRR), requirements (BRR), testing (TRR), and so on advocate different levels of “Done” throughout the project. Agility and tradition clash here, sometimes badly.
Since changing traditions is not typically easy, tackle one gate at a time. The number-one way to fail in agile is through lack of leadership support, so an organisation’s leadership must be involved in and committed to removing unhelpful gates, one at a time.
A government organisation has used a gated system with requirements, analysis, implementation, testing, and GA gates for a long time. The software R&D teams have implemented Scrum in their process, and are delivering working software each sprint. But teams are still required to synchronise with the testing sprints and are not allowed to release to GA until the gate approval at the corporate date.
6) Insufficient training
Sometimes, a company expects one-off training will get everyone to know how to do agile.
Say you want to complete a marathon. That requires being able to run 42.2 kilometres. And let’s say that you are not a regular runner. You’re starting from nothing. Will you be ready for the marathon after a three-day training crash course? How likely are you to learn all the possible problems and scenarios in those three days?
Going from non-agile to agile practitioner is similar. The likelihood of becoming an expert in a two days course is next to nil. You must invest energy and resources in increasing your agility.
“We only have one opportunity, and only that much budget, so there’s not much we can do about it.” This statement set the scene for a meeting on initial training for multiple teams embarking on their Scrum journey. Management decided to hold one-day sessions to teach Scrum, taught by the EVP who sponsored agile and who knew Scrum. Putting aside the gaps in understanding the roles, ceremonies, and artefacts of Scrum, virtually everyone took Scrum as yet-another-project-management technique, and did not understand concepts such as self-organisation and the empirical approach to iterative work. Through hard work, only a couple of teams began to transition to an agile mindset but for most, agile was still only a new method to be micromanaged.
7) “Agile is just for Christmas” approach
Agile is not simply another project to tick off on your bucket list. Becoming agile is a journey, not a one-off project or just another practice to learn.
To many organisations, becoming agile means changing the operating system, quite literally. Yes, being agile includes adopting new operating practices but the more important change is in mindset. Many organisations operate under a Taylorist or Cartesian mindset: management is responsible for results; other employees are responsible for execution.
It requires discipline and perseverance to make agility stick. It may take years before you reach the tipping point at which your organisation can call itself agile — not that you will be able to stop that way of working at that point. You will not even consider another alternative by then. You will have tweaked your culture.
A large international enterprise has embarked on a journey to agility. A coach was available on site to help teams and managers in their day-to-day challenges and in gradually enacting Scrum according to their maturity and interest. About two months into the process, some painful issues started to surface: e.g. programmers didn’t want to test, seating arrangements impaired productive work, teams assigned blame to other teams. And then the journey exhausted the budget. The company was left with a crippled Scrum and a lot of frustration. Six months later, people started self-organising to learn agility, this time without help on site and with much greater effort to get desired results.
8) Misalignment with neighbouring departments
All involved departments must play the same game.
In physics, wave sources are coherent when their waveforms create a constant phase difference. They are not coherent when their frequency or direction or both are not aligned. In music, we know immediately whether what we hear is in harmony or not — it can just sound wrong.
The same goes for teams in an organisation.
If one part of the organisation focuses on speed of delivery and another focuses on quality, even if they are aligned in the same cadence, the outcome will not be in harmony. When interdependent teams are working towards misaligned goals, the results are misaligned, too.
Successful teams align their schedules, goals, and purposes.
That does not mean that all teams need to align all their work procedures, for example. Alignment emerges when neighbouring departments align their values, their standards, and their definitions of success. If that reminds you of leadership support, you are catching on!
Two departments working on the same product have implemented Scrum in their working processes. One department is developing measurement tools to provide KPIs for the product. They focus on the quality of the measurement. The other department is introducing new features to the product. They focus on the speed of delivering features. Both departments depend on the other: providing KPIs requires API calls into the product’s features; new features are not “Done-Done” without the KPIs. Both departments take pride in their agile implementation and how it serves their values. Only after exchanging experts for a sprint or two in experiments do the two departments start to bridge the gap and develop a “Definition of Done” that includes their counterpart’s needs.
9) Lack of adequate and adaptable measurements
Use vanity measurements in order to fail.
The Agile Manifesto’s seventh principle is “Working software is the primary measure of progress,” so whatever measurement you choose should measure how work contributes to a functional product.
Measurements such as number of defects opened or closed, velocity, velocity trend, and committed-versus-done ratio all measure contributions but do not apply to a working product.
Larry Hirschhorn in The Organisation Within calls such measures “fetishes”. They may represent the real thing, but are essentially not.
Customer satisfaction, employee happiness, or press coverage may instead be better indicators.
However, to paraphrase Mark Twain, measurements and diapers should be changed frequently, and for the same reason. Every measurement can be gamed and people behave according to how you measure them. So don’t try to look for the one measurement to rule them all. What you measure should be relevant to the product’s and teams’ maturity, and you should replace it as often as possible.
A large enterprise deployed a set of tools to assist in its agile implementation, and put a home-grown reporting tool on top. This has gradually evolved into a BI platform that could slice and dice various data: velocity, cycle-time efficiency, WIP over time (a.k.a. CFD), commitment accuracy, and many more. Consequently, a new culture evolved: towards the end of each quarter, program managers spent days to find the perfect filtering to present the best reports for their stakeholders. It didn’t matter what was really happening on the shop floor as long as the reports looked good.
10) “Scrum is agile is Scrum” approach
This is when a “technical” Scrum means “Done”.
Agile is so much more than Scrum. Scrum, the most popular framework for the development lifecycle, deals with just one facet: a team or teams taking a backlog of requirements and completing them in a short feedback loop. Scrum, in itself, does not deal with engineering excellence, overall purpose, scaling (LeSS does that quite elegantly with Scrum), or long-term planning, to name just a few aspects.
Good Scrum Masters know that and help their teams, product owners, and stakeholders to excel in a multifaceted manner.
That is to say, good Scrum Masters don’t really practice Scrum. They are agile practitioners, operating in a Scrum environment.
A mid-sized organisation wanted to implement Scrum. An organisational analysis clarified the process: start with improving engineering practices, as the first problems the organisation was likely to encounter would be related to quality of code. Following a number of meetings, leadership at the organisation insisted on going forward with Scrum despite the painful and lengthy release procedure and prevalent blame culture, among other symptoms. The journey worsened relationships in the teams until the organisation abandoned Scrum altogether.
What’s next?
It’s time for you to reverse-engineer this article.
This article isn’t about making you abandon your agile journey.
On the contrary, it is about making it stick.
If you find that you are doing one or more of the anti-patterns mentioned here, ask what you can do to change it. What can you do different to become just a tad more agile in the way you operate? Where is your own O-ring that you are overlooking, what anti-pattern contributes to it, and how can you get rid of it?
A large enterprise implemented Scrum and kanban in one of their R&D departments. Following tension between Product Owners and the teams, the organisation called in an external vendor to conduct a workshop on working agreements for the teams. A preliminary meeting revealed that while there were some challenges at the team level, there were more important ones with leadership. For example, while managers believed in agile, they were not setting an example for teamwork.
The team workshop was replaced with one on management-team formation. The result of the workshop was a backlog of changes: formalising a purpose and values for the department; clarifying roles for the management team members; defining and owning standards, in particular with external dependencies; and more. By having their own change kanban and owning their dysfunctions, management began to remove ways to successfully fail in their agility and replaced them with incremental steps that set an example for their agile teams.
About the Authors
Ilan Kirschenbaum - Since he owned a Sinclair ZX81, Ilan knew he wanted to be a programmer — which he did with great enthusiasm. One day, he realized that the small company he was working for had turned into a big, process-rich, document-hungry mammoth. Programming and software projects were not so much fun anymore. Then he found agile (rather, agile found him where he worked). The concept reminded him how much fun software development can be. Today, Ilan loves helping high-tech professionals fall in love with their workplace, so they can help their customers love the products that they make. You can read Ilan’s ramblings on agile here.
Oren Kdoshim is a senior project manager at Tel Aviv-Jaffa municipality. He has more than 15 years of experience in software-development management, system analysis, project management, and, in recent years, agile practices. Oren is happily married, the father of five, a freak of Persian cuisine, and a keen nature photographer. He will go places to shoot a rare butterfly hatch.
