Agile Transformation: Danila Vasilyev Busts 5 Typical Myths And Misconceptions

Agile has been with us for more than two decades, although the first concepts of iterative and incremental software development can be traced back to the 1950s. As with many other trendy approaches, Agile has been praised as an almost-panacea, has been blamed for all imaginable sins and even proclaimed dead. But real life goes on and the latest annual State of Agile report stated that 71% of its survey takers used Agile in their software development lifecycle.

However, as any technology or method, Agile should be used wisely. Several years ago, Jeff Sutherland of Scrum Inc. admitted that as many as 47% of Agile transformations fail.

Why do these failures happen? Today, we speak with Danila Vasilyev, Senior Project Manager at Broadridge, who has 13 years of experience in the international tech industry under his belt and is a real-life Agile implementation expert. He debunks several most common myths about Agile and talks about his extensive experience with this concept.

Agile Advocates Say It Is Very Intuitive And Natural, So Shifting To It Is Easy. Is That Really The Case?

The ideal Agile transformation is actually a mind shift, a total change of the paradigm for everyone involved: clients, developers and managers alike. Actually, it is the classic “waterfall” model that is intuitive and straightforward: we analyse, design, develop, test and launch our product.

But the journey from request to launch may take quite a while and the client only sees the first tangible result at the very end.

Agile is different: there is a team that fits the task, and a client who has a rough idea of what they need to do. We agree to work in small iterations, achieving small results step by step, but we get to see them very quickly. We do not commit to knowing everything in advance.

We build a detailed plan for every two weeks. Then we all look at the results and decide where we move next. Even if the initial plan in one’s mind was different, it may always be revised.

Well, that is how it works in theory, but real life is usually different. The reason is usually the mismatch between Agile principles and existing practices. Top management might believe Agile is needed, but the middle management is not ready and neither are the teams. This can be true both for the client and for the vendor. What happens next?

Executives get nice reports indicating that Agile is being actively implemented, they see pretty metrics and colourful graphs.

Everybody knows how to make reporting nice and pretty, right? But in reality, the effectiveness may be very questionable. Sometimes no one can really tell if it actually got better or worse. Without a true mind shift, blind application of agile mechanics to project execution can lead to hammering nails with a screwdriver and tightening bolts with a hammer. It is going to be just an imitation and that is what often happens in reality.

A Popular Stereotype Is That Everyone Needs Agile: Can It Really Help Everyone?

That is what Agile advocates usually say, but that may not necessarily be true for your company and your project. There may be different motivations for adopting Agile. For instance, when company performance doesn’t meet expectations, top managers see there is a need for a reform.

So, Agile transformation is one of the obvious options on the table. No one knows whether the reform will succeed or not, but at least, you have to try, right? That is a very typical mindset, it used to be especially popular about a decade ago,  now this trend seems to be fading, but is still strong.

On the client’s side, reasons for wanting Agile may differ. Clients do it because it is trendy and fancy sold, they want to try something new, especially when they are not sure about the final requirements and need to reserve the right to change it at any point of time at a lower cost. They might even believe Agile is faster (spoiler: no).

So why not give it a shot? Sometimes the reasons are not even rational, it’s just “we believe this ideology suits our goals better.” But where there’s demand, there’s supply.

Vendors promote this idea because it is a competitive advantage. Everyone wants to get contracts, so if the client wants Agile; fine, you’ll get paid for it. But, the reality often is that neither the client nor the vendor are actually ready for Agile. Does your client need Agile? Maybe, but not necessarily. Do you need Agile? If it is stated in the contract there is little choice.

Some Larger Companies Have Trouble With Adopting Agile. What Does Your Experience Suggest?

Agile, in its ideal form, works best for small teams. But Agile and corporations are, say, opposite things. In theory, it is possible, but in practice, no one in a typical corporation is truly ready for it. Big companies have a lot of constraints, from tools and licenses to security policies and so on.

A large corporation imposes the weight of its entire corporate structure on every team. Corporations are about unification, otherwise, there’s no control.

For example, your Agile iteration is two weeks because that’s the corporate standard. But Agile postulates that the teams should choose iteration time frames themselves. Yes, typically it’s a two week sprint, but it could be three or even four. And that is one of the core principles of Agile. It has no “bible” or strict methodology that works for everyone.

In true Agile, a team should be self-organised and self-managed. But a team within a corporate structure cannot be self-managing. It is subject to a large number of corporate frameworks, rules, and limitations that it cannot influence or change at will. Corporate rigidity usually undermines the core of Agile. As a result, a lot of effort is wasted inefficiently.

So, if you want to implement Agile in a corporate environment, you are going to spend much of your time finding the thin balance between efficiency and compliance with the rules.

Agile Is A Chance For Clients To Relax And Just Watch The Miracle Happening And The Job Getting Done. But Can Agile Really Be That Safe And Protective For Them?

Clients’ understanding of Agile is often even less mature and more naive than that of the vendors. Many clients believe that as long as they are working in Agile, they can constantly change their minds or not deliver any scopes and opinions at all, at no cost, and still get the result.

Indeed, having the project goal set, high level scope described, and the deadline stipulated in the contract, clients tend to think that with Agile they can play freely with iterations, that they are protected and that their project will magically be completed, say, within a year.

But in fact, if a client wants to be successful with Agile, they must get their teams aligned and engaged. Agile in its true form divides responsibility between the contractor and the client on an ongoing basis. It’s a collaboration: not magic, but a set of practices that demand effort.

What is often unnoticed in sales negotiation,is that the client is required to put not not less, but actually more effort. Without deep involvement, permanent availability, without constant and timely feedback there will be no real result.

Some Managers Say It Is Even Harder To Get Things Done With Agile, But Others Are Quite Happy. What Would You Say About That?

When you manage a project, it does not matter which technique or method you are using: the only bullet in your inventory is you and your team. But it is especially true with Agile, because it is here where expectations from a trendy approach may mismatch reality.

As a manager, you should, on one hand, fulfill the requirements of the contract and methodology; but on the other, you must not lose your teams and you need to get the highest possible level of efficiency from them. You should set expectations and communication in such a way that, despite all the specificities and mismatches, things still somehow get done. It is the manager’s job to explain that it is in the client’s best interest to push their team to get involved.

To make it clear that Agile is anything but chaos. Quite the opposite; it requires a high degree of organisation. The manager essentially educates the client how to use Agile effectively. Also, depending on your company’s maturity with Agile, you may need to educate your developers, leadership team and any other project stakeholders to handle this wizardry effectively.

What Should A Project Manager Do If They Have To Dive Into Agile?

As a manager, you have the power to structure all the moving parts of the project. The first thing you can and should do is to set up proper communications and transparent processes for everyone involved. Your teams need a clear framework.

It may be hard with first sprints, but if everything is clearly defined, people will become more organised. These processes can be adjusted as you go, but initial setup should be very clear for everyone. Build a system of relationships, procedures, and monitor their adaptation and compliance.

You will have to explain to everyone exactly how this framework will be implemented, and do it daily. Without this, Agile tends to slip into chaos, not because Agile is chaotic, but because people struggle to grasp the paradigm shift. These rules apply when working with your internal teams and your clients alike.

As for communications and expectation management, I have a real-life example. Once I came into a project that was supposed to be done the Agile way, but neither the contractor team nor customer team were experienced in it.

On the contractor side I had a team of seasoned pros: they knew how to do the job and were disciplined enough to adapt the contracted methodology. The main problem was on the client’s side. Their SMEs showed up at our rare meetings thinking they were not responsible for anything. Instead of focusing on critical requirements and makingscope decisions, they were in a free flight mode. Two sprints  went by with deliverables that met the sprint goals but didn’t make us any closer to the project goal.

So, I went to their leadership and made myself clear: if we continue like this, we won’t meet any scope expectations even in a year. I explained that if they wanted their project completed within the set scope and time, they needed to change the approach.

Their people should meet us three times a week instead of one. They should keep in mind the project goal and handle the backlog accordingly. And they need to do their homework and come prepared to be able to support further development discussion. I also made a high-level baseline plan for the entire project with a rough Sprint breakdown to demonstrate the pace teams should move to meet the timeline. I made everyone keep this plan in mind and continuously check whether we were on track or not.

Also, I explained that each new request should be aligned with this plan, and there are only two ways of making changes that don’t follow the high level plan: a. moving the deadlines (which was not acceptable), or b. removing something from the project scope.

Throwing in tasks that don’t fit into the high-level plan may sound very Agile, but we just won’t be able to get the contracted results. What I basically did was move the client from the role of a free artist “because we’re Agile” to someone who understands the priority of project goals, limitation of resources and importance of discipline to succeed.

That was the main win for the project: realising they won’t get everything at once, they won’t get results without involvement, and that any Agile still needs strong processes, the client had to make their choices and discipline themselves.

My last piece of advice to you in this interview is simple. No book or methodology will tell you exactly what to do in your specific situation. Remember: management is a blend of art, experience and skill.