Doing Agile In Non-Agile Organizations

The Clash

At a first glance we may think traditional management and Agile are misaligned. “Knowing” upfront when a project ends, the full scope and the plan to get it done are strong beliefs that anchor the waterfall solution. We, who have learned waterfall-based project management theory and used it to manage projects, are accustomed to listening and getting induced into thinking that change needs to be managed and the customer educated to stay within the scope and accept a change management that ultimately will increase the project’s revenue.

This is, in fact, a tool to lower risk, keep margins and increase revenue. Note that these are beliefs, and sometimes, if not often, they fail to meet the expectations. Margins get crushed, changes happen without customer accountability nor additional sales, deadlines slip, and, in the process, we wear out the relationship with customer. Thus, all sorts of KPIs and tools have been proliferating that try to give information and predictability in order to anticipate problems and give managers the best means and data to decide.

So, management needs to see respected some base concepts such as budget stability, revenue increase, respect for the margin, productivity control, cost control, commercial leads generation, foreseeable resource management, risk management, etc.

At this point Agile doesn’t seem to offer the same level of comfort. In fact, it radicalizes some key aspects by embracing changes and letting, if not pushing, the customer chose the outcome as the project moves forward, by integrating short cycles and leading the team to change almost anything at each cycle, by advocating the reduction of measurement and bureaucracy to the absolute minimum, to free the team so they can focus on getting the job done and by planning the least and the latest possible assuming that the plan will inevitably change, not once, not twice, but continuously until the end of the project.

 
The Link

Agile is, above all, a mindset. Agile teams set their mind to achieve the result best suited to the customer’s needs, to always improve, perhaps not always but, undoubtedly, to do, learn and adapt fast, so that when you fail to improve you can bounce right back to the improvement saddle. This way of thinking tends to clash with classical management. Is there a way that both can cohabit the same organization?

Communication is of the essence. We need information to flow. We need information to be understandable. When two people don’t speak the same language, to facilitate their communication we can find someone to translate. This translator virtue is that he knows both languages and he can listen to one and explain to the other. Note that the term used is explained, and for a fact, the gap between some languages does oblige a translator to interpret and then translate, for there are times when transliteration will not be enough to make the receiver understand. An easy example is to think of a metaphor or a saying used to characterize something indirectly (e.g. “there is no I in team”).

So, we can find someone that can translate from Agile to Classical and vice-versa, and if you are thinking that this can be the Scrum Master, well, it may or may not. It could be the product owner. I prefer having someone dedicated leaving all Agile roles as pristine as possible. The main idea is to have an observer that collects data from the team and adds requirements, creating a project image closer to the one expected by the management by, for example, keeping a plan and managing the change by reporting the base line, the change and the remainder to completion both in terms of cost and time.

If possible, the translator solution should be a temporary fix. Agile activists need to come forward and push the organization to transform. Evangelize through good examples, openly debating ideas, inviting everyone to experiment and learn.

Segregation works, and, if we find a way to fairly compare performances we can even evaluate both methodologies. Isolating the Agile projects and having the organization to accept a different way of leading these projects can give us the required conditions to adopt Agile up to some degree. This means two different chains of management, and at some level in that chain, you’ll need the translator figure to emerge, depending on the maturity of the organization in Agile adoption.

For all Agile lovers, the nirvana is to really change the organization into becoming an Agile organization. This is no small job. In fact, it should be a program, a program to transform the organization, a change management program where everyone should undergo a transformation process, preferably, top to bottom. And is also a discussion to deepen in a new article.
 
 

The stakeholders’ desires

Customers demand Agile

Customers are more and more aware that time makes things clearer. As time goes by the need for changes emerges.
Imagine a project aiming to redesign a specific site to become more ergonomic, leading customers to buy more. A study based on a pool of consumers is used and decision is to revamp all buttons and links. Sketches and specs are made, and all is defined to implement these changes. As changes are too big, the customer wisely decides to split the project into 5 phases. After phase one the customers’ feedback shows a completely different direction as best suited. The customer has now a better understanding of the best changes to make. This shows to be true for all other 4 phases and even A-B tests are introduced to improve decision making about the final design.

Thus, fixing a scope for a long-running project makes little to no sense. Customers want to reduce time span or to be able to change to better adapt to their actual needs, or to have it all, reducing time to market and being able to adapt their roadmap. Agile, along with some other techniques, gives them the continuous improvement, continuously adapting with frequent releases. 

Developers demand Agile

Having a project manager is connotated with pressure and stress, the management expects the team to deliver on time and on budget, people are asked for estimates and they suspiciously look at this as a tool for controlling and criticizing. Although that is not a management rule, when things get sour we tend to see a focus on blaming and the ones accounted are those who estimate and those who executed.

In Agile there is also pressure and stress, but it comes from within, the team commits themselves to finish what they have planned to do, and they all push the limit when necessary, at least in theory. Maybe not all people are suited for Agile development. Some tend to relax and find excuses rather than searching for ways to strive and become better. This stereotype along with others like the student syndrome, according to which, people tend to procrastinate until the last possible moment, forcing them to do overtime to accomplish the sprint goals or even leading them to fail, instils mistrust into management.
 

#Sprint16 Periscope How to be agile in a non-agile world https://t.co/ySDzoH4agD via @YouTube

— Jon Simmons (@jonsimmonssw6) 24 November 2016

 
Waterfall is also seen as carrying a large burden with endless hours of dealing with bureaucracy that serves to create data for management and it is seen as of no value to get the job done.

While in Agile the amount of bureaucracy is controlled by the team (this does a much better job to have people to accept a certain degree of paperwork). The focus on people and on performance is appealing to professionals that want to improve, grow and progress.

Non-Agile organizations adopt positional leadership while Scrum allows for leaders to emerge. Non-Agile project teams have a project manager and usually an architect or a technical leader appointed from the start. The Scrum Master is not the team leader but rather the team servant (he/she should be a servant leader, but this is not always the case) he facilitates and should create an environment in which the adequate form of leadership may emerge.
 
The market demands Agile

Adaptation and evolution are of paramount importance. A project or a product based on a good or innovative idea will only survive until someone else makes it better. This means you need to evolve fast to stay ahead, learn fast. Whilst in non-Agile methodologies, one can foresee intermediate deliveries and releases, it is still expected a full product. And once delivered, the team is expected to move to a different set of functionalities. Changing, at this point, is seen as inefficiency, and it is, it is already too late to fail or change and the cost to modify something structural at this point can be overwhelming.

This has led to focus on design and analysis, using mockups, prototypes, focus groups, analysis frameworks, etc. On the other hand, Agile methodologies propose to fail fast and learn often. Instead of a fully developed product, each release builds on top of what was built in the cycles before, adding incremental value to the product. Following this vision, a product is delivered several times while it is being developed. At each cycle, the project team has an opportunity to learn not only from the client but also from each other. The client himself has an opportunity to listen to his customers and to integrate that feedback fast. And so, at each release, the product re-aligns its roadmap, perhaps away from the initial objective, but, most importantly, towards a far more adaptable form catering to the real needs of its public.

Unlock your potential with PRINCE2 Foundation Certification and take your expertise in project management to new heights!