Going Agile - Does It Work for All?
The agile movement is making its way into the enterprise world, but does it work for all? Learn how to leverage agility to the benefit of your organisation.
1. Enterprises going agile
With each passing day, the agile movement is making its way into the enterprise world. More and more large corporations are discovering the benefits of agile approaches and want to leverage them within traditionally rigid and bureaucratic enterprise workflows. This is hardly a surprise since the agile methodology promises several advantages for businesses: (references: [1] [2] [3] [4])
● Decreased time-to-market
● Higher Quality
● Reduced Risks
● Scalability
● Increased Flexibility
● Stakeholder Involvement
● Transparency
● More Attractive to High Performers
The abstract goal of becoming an “agile organisation” has no doubt been driven by media hype fanning the flames of young startups hitting stratospheric heights with their lean methodologies. It’s only natural that large enterprises want to reap the rewards as well [5]. In fact, the more we compare startups with large enterprise organisations, the more it becomes clear why the latter are putting so much effort into increasing their own flexibility. Nowadays, most enterprises have become too slow, too sedentary and too traditional to maintain their competitive advantage over the long-term. In contrast, startups are driving new features, they are growing tremendously and they’re developing new technologies as they go.
The main difference between startups and enterprises is that the former are more agile. This means that in order to be as innovative as startups and to regain their position as technology leaders, enterprises must become agile and overcome the problem of being inflexible, slow, and stagnant.[1]
2. Nautical metaphor, revised
The problems described above are commonly explained through a nautical metaphor. The large enterprise is a huge tanker ship, while the agile startups are speed boats weaving in and out of the waves. In this case, the CEO of a large enterprise would be the captain of a tanker and she could command a change of direction so that the ship, albeit slowly, would turn and set its course on a new path [6]. However, this image is not an adequate reflection of the truth. In reality, the C-level of the enterprise are not officers on a tanker but rather admirals of a huge fleet of ships. This fleet contains not only tank ships, but also speed boats, briggs, sailboats, and even a few old canoes. On top of that, there might be also several submarines under the command of these admirals without them even being aware of it.
Moving such a big fleet is definitely harder than steering one mere tanker. This is because every ship has its own captain, who interacts according to his or her own understanding of the general plan, communicated via word of mouth and hearsay. Naturally, these captains also have their own ideas and goals, sometimes even hidden agendas and egos. These objectives are often more important to them than the command from the admiral who might be working some three nautical miles away from them. Moreover, all these ships also interact with each other and some of them might have a stronger influence than the admiral's' actual commands. Some ships group together to hunt whales side-by-side, others may connect their hulls to create a larger vessel, and a few even cut the other captains off in order to gain small advantages. It's not uncommon that cannons are fired and grappling hooks are thrown into the mix as well.
This is the real issue of the enterprise: it's not that it's a slow, sluggish ship that must become faster and more manoeuvrable. Instead, it is a chaotic conglomerate, which is heading in so many directions at the same time that it rarely moves as a single entity. Therefore, the task of the enterprises’ top management is not about replacing the engine and rudder, but getting the conglomerate to work together as one singular unit with everyone moving in the same direction.
3. Does agile work for the enterprise?
Once the differences between startups and enterprises become clear, it’s fair to ask whether an agile methodology can work for the big companies too. In fact, it’s difficult to say whether the agile methodologies work at all. On the one hand, there is a lot of proof for its success with many startups achieving hyper-growth while working in an agile fashion. On the other hand, the overwhelming majority of startups fail and, although there is little research on this, this could be caused by agile methodologies too. In general, the hype around agile is also founded on the 'survivor bias' [7] [8]. In other words, as we only see and talk about those companies who survive, we tend to overestimate the chances of success. Therefore, we should think critically about the agile methodology and not just take it as the holy grail.
The big remaining question is whether enterprises benefit from these changes? Unfortunately, there is no clear answer as it depends on the case at hand. This is so because economics are not like physics: there are no general laws that apply such as gravity. In economics, there is no equivalent that would state, for instance, that agile processes must improve the time-to-market. In reality, business is a complex game being played by seven billion people with rules that nobody really enforces [9].
In this case, the main problem is that agility does not reduce complexity. A small startup is not complex: it works on a green field and it’s free from heterogeneous stakeholders, lawyers, 30-page contracts or standards and processes it has to comply with. However, that's more due to the fact that they are a new company operating in a nascent or less mature market rather than because they use Scrum or other agile models. Simple user stories like 'I want to get information about the new product' might work for most startups, but not if the 'information' about that product is distributed across 4 systems per country with 30 countries in play, and most of the systems having been built in the 1990s which don’t even support a proper ID to identify the product.
Additionally, agile approaches far too often deteriorate into 'yet another process’. To make it worse, in these cases people would still be warning anyone from deviating from this agile process as the company ‘has to be agile!'. Take the standard phrase for user stories: 'As a … I want to … so that … '. The reason for this sentence structure is that it promotes user-centric thinking and that it explains why the actual task is important. While this is generally a good approach, it becomes less useful when the user story in the system reads 'As a developer, I want to implement the module so that it can be used.'
In my experience, far too often agile in the enterprise is implemented like this:
1. Define an agile group called 'think tank'. Sometimes it is set up within the regular company hierarchy, but establishing a separate legal entity is also quite common, such that some of the enterprise restrictions do not apply.
2. Decide on Scrum as the agile approach.
3. Define a project that shall be done in an agile fashion. Obviously, this project must be something mission critical to harvest the benefits of agility to the full extent.
4. Re-name the corresponding staff to 'Product Owner' and 'Scrum Master' and define that the personnel is now 'the team', convert all requirements into user stories.
5. Approve a training on agile methodologies for the Product Owner and Scrum Master (this step is purely optional).
6. Define a two-week sprint cycle (three at most) and create a backlog of user stories (which might be empty, because it will be set up in the course of the project).
7. Most importantly: Send out the invite on daily stand-ups as well as sprint review and sprint planning meetings.
From there your Scrum process is established, Story Points are distributed and the agile approach has manifested itself in the enterprise. Everyone starts storming, forming, norming and - hopefully - performing. However, this approach will not deliver any benefits. In fact, it would be lucky if it turns out to just be a waste of time and money and doesn’t create actual mayhem.
Added Value by Agility
How can agility be leveraged to the benefit of an enterprise? The centre point is to have a clear focus. Don't buy into the 'agility allows us to work without plan' slogans. You must clearly know what you want to achieve or you will fail.
3.1 Identify the problem first
Agile methodologies are a tool which you can use to solve a problem, but they are not a magic elixir. If you don't know what the (real) problem is, then agility most likely will make it worse before it solves anything. Therefore, identify the problem you want to solve first. Stick to one problem and don’t try to solve everything that’s wrong in your company at once. Ask yourself what the most critical issue is: speeding up development, increasing quality or improving usability.
Only when you’ve identified the right question, you will know how to use agile approaches to actually answer it. The focus in your setup must differ if you want to speed up compared to increasing quality.
Additionally, it is always a good idea to monitor whether the problem is being addressed and the approach is working out. Identify the key performance indicators you want to measure for the project and compare to other projects. If you want to increase speed, verify the delivery times. If you want to improve quality, check the issue-density and, possibly more importantly, user acceptance.
3.2 Keep it simple
Start with something small, and plan twice the budget and time you would normally assign to such a project. Of course, you might, rightfully, argue that agile should make things faster and cheaper. However, if this is your first try it simply won't happen that way. There is a learning curve for the team, the stakeholders, and the organisation involved, and these learnings merit an extra investment upfront. Build those additional costs in ahead of time, but remember you don't have to communicate them too openly. We all know the Pareto-principle [10]: The Scrum project will waste roughly 80% of the available budget. Yet, this is okay because it’s part of a learning process. Moreover, you should also set aside another slice of budget after the remaining 20% didn't deliver what was expected.
3.3 Work with a defined scope
Right from the start, ensure that the team really knows what is expected. Strong governance is important to truly achieve impressive results. This should not be confused with being contradictory to agile - not knowing what you want to do is not agile, it is clueless. Agility is knowing where you want to go and adapting if that path changes. In the startup world, you might often just have a vague idea of what your product will be. This kind of openness is rare in the enterprise world because you don't get the budget if you cannot describe your delivery to management. In turn, this description creates an expectation of the desired result. As a result, you should ensure that you are working towards that description. In an agile environment, it is easy to optimise simple things to perfection while ignoring difficult topics entirely. Counteract this by making sure you have an almost complete backlog and an understanding of the rough complexity and main dependencies of the items included. If you fail to do so, you will run out of time in the end.
3.4 Leave room for results
Once you are running an agile project, you'll soon have a lot of meetings, most notably sprint planning, daily stand-ups (officially: daily Scrum, but that doesn’t seem to be very widespread), sprint review and sprint retrospective meeting [11]. I have also often noticed the tendency to merge the sprint review and retrospective meeting into one. Maybe that stems from both asking for what went well and what did not, however, be careful not to do that. Moreover, request result presentations in the review meeting that include hard results. Additionally, also request demos and don't be passive about it. Validate against the scope to determine whether you are really moving forward at a sufficient speed towards your goal. If you are not hitting your target, identify what can be changed to bring you back on course. Remember, this is an agile project, so re-arranging things to meet the goal is part of the game.
3.5 Prerequisites
Finally, there's one critical decision you need to make before you even get started: figuring out whether you are really able to run an agile project. The biggest challenge of enterprises seems to be the following:
● Ability to Decide. The team and especially the product owner must have the ability to decide on options without lengthy approval processes.
● Co-location. The team must be able to interact directly and easily. Video Conferencing and Slack help, but they cannot replace actually sitting next to one another.
● One team. In the enterprise area, there are often many external team members included - with their own agendas and approaches. This mixed group must be forged into an entity (and that takes time).
● Experts. According to Scrum, every team member should be a generalist (it is really made for brilliant, committed people). Be sure to invest in a very high skill set.
If you cannot ensure that these prerequisites are met, try a more controlled approach, like incremental models. Scrum is not the only agile methodology out there, although the two appear to be synonymous. Prioritise results and outcomes over processes.
4. Conclusion
Agile can work for the enterprise, but it is not a guaranteed success. In fact, agility is about mindset, not toolset. Discussions focused on processes, tools, and applying the proper names are an indicator that you are heading in the wrong direction. Be sure to do it right by fostering communication, flexibility and fast delivery - avoid employing yet another process. Agile does not mean that you can skip the plan and just start to work. Do the planning properly and re-evaluate your plan over time. Focus on your goals and measure your results. Keep it simple. Ensure you have the setup you need.
If you have a look at the agile manifesto [12], it is really enlightening to see its true aims: Agile is about the results (working software, customer collaboration) and the best way to achieve them (individuals and Interaction, responding to change, etc). If you work in that direction, you may not be guaranteed success straight away, but you’ll definitely be on the right track.
References
[1] http://www.allaboutagile.com/10-good-reasons-to-do-agile-development/
[2] http://www.seguetech.com/8-benefits-of-agile-software-development/
[3] https://leankit.com/learn/kanban/benefits-of-agile-development/
[4] https://www.versionone.com/agile-101/agile-software-development-benefits/
[5] Goldmann, Lisa: "Sag mal, ... ... kannst du mir helfen?" in Fischer, Gabriele (Chief Editor): "Brand Eins", 09/2016, page 94-98.
[7] Dobelli, Rolf: "The Art of Thinking Clearly", New York 2014, page 1-3.
[8] Or more visually via http://www.smbc-comics.com/comic/path-of-a-hero
[9] Tim O'Reilly: "Why the Game of Business Needs to Change Its Rules", https://medium.com/@timoreilly/why-the-game-of-business-needs-to-change-its-rules-4332ee4917de
[10] Ankunda R Kiremine: "The Application of the Pareto Principle in Software Engineering",http://www2.latech.edu/\\~box/ase/papers2011/Ankunda\\_termpaper.PDF