While Agile Approaches Are Frequently Used to Implement Enterprise Software Development Projects, Some of the Must-Dos Often Get Overlooked, Leading to Disastrous Outcomes
Agile has been the approach of choice for a large number of enterprise success stories. However, multitudes of Agile projects still hit the skids, enterprise ones being, unsurprisingly, the more likely candidates for failure.
As an example, the independent IT consultancy 6point6 estimates that a £ 37 billion worth of Agile IT projects flop in the UK alone annually, which says that the global figures, whatever they are, look like a cosmic-scale disaster.
Have you ever wondered how many of those projects could have wound up profitable business endeavors, had their owners been a bit savvier about what their IT employees and/or software contractors should have really been doing? Moreover, how many of those that have panned out could have lasted less, cost less or seen better prospects due to better software quality? Finally, what could be the main reasons for the startling stats, is there anything can be done, and do clients, actually, hold any sway over the implementation of their Agile projects?
Despite the empire-building effort to formalize the Agile knowledge being made both world- and industry-wide, there’s a host of momentously impactful factors in the Agile space very few IT vendors ever pay attention to. In turn, clients tend to rely on their software contractors for the organization of their Agile development process, getting trapped into false approaches or replicating these software contractors’ mistakes.
To make matters worse, there are certain things relating, mostly, to clients, of which they should be, but, from our experience, are plain never aware.
Here is our close-up on what we believe to be some of the major factors that can cause an Agile enterprise software project to go bung.
1. The Client Demotivating their IT Contractor’s Development Team
Being motivated and, most notably, self-motivated is universally held to be pivotal to the success of any Agile software development team. This trait of a development team is, downright, lionized under this approach, and, probably, rightfully so. Which makes it all the more strange that in a huge number of instances clients do their best to demotivate their Agile teams. How does that happen?
At kick-off, most Agile teams are chumping at the bit, and do all their planning with great precision. They do a great job of each and every task, included in the current sprint. But after a while, the client’s business stakeholders start “optimizing” the development process.
They start bugging the Product Owner in an attempt to find ways to get the team to do more than is being currently done. As the Product Owner, usually, wants to oblige the client, they, in turn, start putting the squeeze on the project team.
Usually, this happens in response to some deadlines or milestones, or a lot more frequently, out of the desire to find some cost advantages where there can’t, possibly, be any.
Whichever the case, sprints start being padded with 1, 2, 3 or even more tasks in addition to those, the team members feel like they are able to fulfill with good quality, on time, and, importantly, while also enjoying the results of their work as professionals.
Before long, the team is no longer able to deliver sprints with the quality that they reckon befits them as professionals. They get exasperated, start feeling put upon, and gradually lose their interest in the project.
In you are a client, do not thrust any additional tasks on your development team in addition to those, they have defined for themselves, no matter how deeply dedicated these guys seem to be.
In a pinch, if a milestone-dictated task should need to be added, prioritize all the tasks within the sprint and remove one or more tasks that have the lowest priority.
If you are a PM or Product Owner, make an effort to explain to the client that regular padding of sprints with extra tasks is very likely to result in very major disappointments for them at a later stage.
2. The Product Owner Not Keeping Close Tabs on the Work Results and/or Analyzing them on a Regular Basis
In many cases, Product Owners don’t bother to perform any subsequent analysis of their teams’ work results, if the client seems to be happy with these ones.
This attitude is trouble-fraught, and here is why.
First of all, on no account should the number of completed tasks be at odds with that in the sprint estimate. If your team members regularly deliver fewer tasks than planned, the team’s motivation will, in due course, surely be lost regardless of whether this underperformance is Okayed by the client or not.
If you are a client, never blink at any delays or fewer tasks than planned being delivered.
If you are a Product Owner, always check the points and velocity indicators jointly with other team members. Never fail to analyze the past work results and always try to find out the reason for them being at variance with the corresponding sprint estimates, if ever.
3. Adding Tasks to Sprints in an Untimely Manner
Any sprint’s worth of tasks must be finalized prior to when the sprint is underway. Nothing should be added, changed or removed halfway through the sprint. Otherwise, this may create the impression that new tasks can crop up at any minute and at any point in the development cycle, which will affect negatively your team’s sense of purpose.
As a client, avoid making your project team expand their sprints with new tasks when the sprints are already underway.
As a Product Owner, try to find out if all the likely tasks have been included in a sprint before it starts. Try to counter any attempts on the part of the client to include a task in a sprint being already underway.
4. Regarding the Product Owner As Someone Who Supervises the Development Process from Outside the Development Team
In many instances, software vendors find it more convenient to regard their Product Owners as a kind of a discrete and higher-ranked caste of employees, whose constant involvement with one project team is not so cost-effective or expedient overall.
As a result, such Product Owners wind up somewhat distanced from the team. They are not always available to answer questions, posed by the team members, and don’t always react to issues that require their attention in a timely manner. As a consequence, these questions and issues pile up, causing downtime, decreasing productivity, and giving rein to false assumptions that result in missed deadlines.
As a client, tell your software contractor that you want the Product Owner to be one of your team members and constantly available for communication with the rest of the team.
As a software vendor (PM, Engineering Manager), try to appoint a Product Owner who is a member of the development team. If this is not possible, make sure that the Product Owner you appoint is free enough to always be available for communication with the team members. Also, make sure that the Product Owner is formally fully responsible for the team’s work results.
5. Starting an Agile Enterprise Software Development Product Without a Software Architect
One of the fairly widely held misconceptions is that Agile projects, including enterprise ones, are fluid undertakings, where the constantly changing requirements eliminate the need for the role of Software Architect.
This is a fallacy that must be nipped in the bud prior to the start of a project, for it is, normally, during this stage that many critically important foundations of a project are (or are not) laid. The choice of the technology stack, development environment, scalability requirements and system consolidation are all to be handled by a well-qualified Software Architect. In fact, it would not be an exaggeration to say that the absence of a Software Architect spells doom for a vast number of enterprise software projects from day one. Moreover, it also costs many clients a pot of gold as they try to rescue their crumbling project endeavors later.
Note: The role of Software Architect is not to be mixed up with those of Business Analyst or System Analyst. Moreover, the skills and qualifications this role requires are different from those, required by the other two roles. As far as major Agile enterprise software development projects are concerned, you will, most probably, need someone with the following skill set and qualifications:
At least 7 years of experience as a Software Architect for Enterprise-Grade Software Development Projects.
- 5-7 years of experience in architecting and developing highly scalable and available software systems.
- 5-7 years of experience in architecting multi-tiered solutions using best architecture creation practices.
- 5-7 years of experience with the SOA, the ESB technology, other middleware technologies.
- 5-7 years of experience with the Required Technology Stack (for example, the Java technology stack).
Possible Project-Specific Requirements:
- Experience developing and deploying Cloud-based solutions.
- Experience in the Cloud migration of legacy applications.
- Experience with UI-related mobile technologies, such as, for example, HTML5, CSS3, Phone-Gap development framework.
- Experience with Micro Service & API technology.
Degree: PhD, MA, MS in an IT field (preferably, Software Engineering or Applied Mathematics).
As a client, never agree to a dedicated development team that does not include a Software Architect, while looking to implement enterprise software development project using Agile.
As a software vendor, never start implementing an Agile enterprise-grade project without a Software Architect.
While the above are just some of the ways an Agile enterprise software development project can be damaged or, even, driven into ground altogether, your familiarity with these hazards and perils and your timely effort to prevent them affecting your project are essential to ensure this project’s success.