Introducing Practices for Software Development

by Team Userlane

6 years ago ・ 4 min.

The early days of Agile Adoption are behind us, as the Agile approach to software development has become the norm instead of an exception. One does not have to look beyond the Project Management Institute’s annual Pulse of the Profession® global survey of project management practitioners to see this.

According to their 2017 survey, more than 70% of organizations reported using the Agile approach to their projects sometimes, often or always. Keep in mind, these are not necessarily software development projects where this percentage is even higher.

While the adoption of the Agile approach is widespread, it is not without its challenges, especially after the initial pilot phase is over and the various factors start contributing to organizational “cooling off”.

In order to prevent this disenchantment from happening and the large corporations (more or less) gradually rejecting Agile and its benefits, it is essential to understand these challenges in advance, which is the goal of this article.

Agile Basics

Before we get to the challenges themselves, it would probably be a good idea to say a few things about Agile software development, for those readers who may not be that familiar with the concept.

The majority of the ideas and concepts behind Agile software development existed years (and even decades) before the then-leading theorists and practitioners of various Agile approaches got together to give structure to and formalize their approach through The Manifesto for Agile Software Development.

The Manifesto, the accompanying Agile Principles and further work focused on a number of core ideas with the ultimate goal of developing better software for customers and end users:

• Adaptive planning
• Evolutionary development
• Early delivery
• Continual improvement
• Superior adaptability to change
• Self-organization of teams
• Closer collaboration with internal and external stakeholders
• Better alignment with business goals

Over the years, various frameworks and methodologies emerged, with the Scrum framework seeing the highest adoption rates for a number of reasons.

Lackluster Executive Commitment

Despite the fact that the modern executive or a member of the C-suite will probably be familiar with the concept of Agile and its many potential benefits, one of the major challenges to introducing Agile for software development in large corporations is the less-than-perfect commitment on behalf of those people.

The lack of complete executive buy-in (and the accompanying sponsorship) can happen for any number of reasons:

• Unrealistic initial expectations
• The role’s inherent over-reliance on delegation
• Unclear declaration of sponsorship
• Perceived lack of beneficial results (as traditionally defined)
• Friction with other corporate groups
• Gradual cooling off/Shift of focus

Considering that Agile projects that enjoy active executive support are more than twice as likely to succeed as those that do not, this is a challenge that needs to be addressed early and decidedly.

Existing Corporate Hierarchy

All large corporations develop a hierarchy, both a formal and an informal one. While there are (usually) good intentions and reasons behind this, the fact is that such intransigent hierarchies are not best suited for Agile software development which emphasizes self-organized and mostly self-reliant teams.

For example, Agile teams are not supposed to be pushed work and incessantly managed, as is common practice in large organizations.  

Agile software development practices do not only clash with existing processes and ways of doing things that come with the established hierarchy. They also clash with individual people within the corporation and their roles.

Perhaps the most commonly cited example is the traditional project manager whose role becomes obsolete by the orthodox “reading” of the majority of Agile approaches. In Scrum, for instance, the responsibilities of the traditional project manager are taken over by two newly created roles (the whole Scrum Master vs Product Owner thing).

While some teams and organizations will find a way to incorporate the project manager into the new way of doing things (and benefit from it), the mere notion that someone’s role is no longer necessary is enough to rub some people the wrong way.

Siloed Software Development Phases (and Teams)

When we are talking software development companies and teams that used to work according to the waterfall method and which are transforming to Agile, one of the biggest challenges are the existing “silos”, both in terms of software development phases and in terms of teams.

In waterfall, the product goes through strictly defined phases where one phase starts only when the previous one is completed:

• Conception
• Initiation
• Analysis
• Design
• Construction
• Testing
• Deployment

In other words, the construction (coding) team, cannot begin to work on the product before the design team is finished and the testing team only starts to work once the complete product is developed.

In Agile, these phases are not as separate and they overlap to a greater or lesser extent. In addition to this, Agile teams are cross-functional and often include not just developers, but designers, UX/UI  people, QA people and even system administrators in the most advanced Agile teams.

It goes without saying that transforming existing waterfall teams into Agile ones is a massive challenge, especially when you add “hybrid” phases into all this where design, development and testing all happen at the same time or at least overlap to a certain extent.

Organizational Interdependence

A small company of under ten people and working on a single independent product will find it much easier to introduce Agile than a huge company or a team within such a company. The main reason for this higher level of difficulty is the interdependence which exists in every large company.

Let’s imagine a large car manufacturer with dozens of plants around the world, entire regulatory, healthcare and HR compliance teams and a massive software ecosystem supporting everything.

In such a massive system, releasing the even most minuscule update to an existing piece of software (let alone a new application of some kind) needs to be planned, overseen and coordinated across the entire organization. We also need to factor in the many decision-makers that are an inseparable part of such an ecosystem, further adding to the complexity.

This simply does not bode well for teams that are looking to release early and incrementally which is one of the main tenets of Agile software development.

Documentation and Reporting

One of the few lines in the Agile Manifesto states the following:

Working software over comprehensive documentation

Many people believe that this means Agile does away with documentation completely, but this is simply not true. Having no documentation is irresponsible and short-sighted, making it a bad practice by anyone’s standards. That being said, Agile software development aims to reduce documentation to only that which is necessary for current and future practices surrounding the product.

To a software developer who has ever worked in a large corporation, this probably sounds like heaven.

Business case documents, business solutions requirements, high-level solution design, solution delivery plans, project management plans, functional and technical specifications and dozen other pieces of documentation are just a part of the software development process in an average large corporation.

A reality in which teams have to create and/or wait for half a dozen documents every step of the way is not exactly the most Agile one. In short, Agile teams will truly struggle to do their thing in such an environment.

In addition to huge amounts of documentation, advanced levels of bureaucracy within large corporations will also result in rampant reporting across the board. Evaluations and status reports come in from all sides and all levels, resulting in job satisfaction rates dropping and a huge amount of time being wasted.

Agile software development does not fit in with the established reporting methods in most large corporations, putting further strain on Agile teams and sponsors. Moreover, their incompatibility with the more established metrics and reporting techniques have been known to precipitate organizational rejection of Agile as a concept.

Closing Word

Introducing Agile practices for software development in large corporations is something everyone wants to do, but not that many are ready to really commit to. The challenges are many and large corporations need to tackle this strategically, with the support on all levels and a willingness to actually change things.

If this does not happen, the challenges we talked about today are enough to put a halt to any Agile practices within a company.

Guest Author: