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 colossal effort to formalize the Agile knowledge being made both world- and industry-wide, there’s a host of highly 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 haywire.
Big-Time IT SOLUTIONS to BIG-League ENTERPRISE CHALLENGES
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 quality of a development team is, downright, lionized under this approach, and, probably, rightfully so. Which makes it all the more odd 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 being part of 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 one, two, three 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.
Conclusion:
-
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 cannot, possibly, be postponed and just has to be added now, 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, try to explain to the client that the regular padding of your sprints with some extra tasks is very likely to result in 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.
Conclusion:
-
If you are a client, never turn a blind eye to any delays or fewer tasks than planned being delivered.
-
If you are a Product Owner, always check the points and velocity indicators jointly with the 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 any minute and at any point in the development cycle, which will affect negatively your team’s sense of purpose.
Conclusion:
-
As a client, avoid making your project team expand their sprints with new tasks, as 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 add a task to a sprint that is 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 from the team members and don’t always react in a timely manner to issues that require their attention. As a consequence, these questions and issues pile up, causing downtime, decreasing productivity, and giving rein to false assumptions that result in missed deadlines.
Conclusion:
-
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 one of the members of your development team as the Product Owner. If this is not possible, make sure that the Product Owner you appoint has enough time to always be available for communication with the team members. Also, make sure that the Product Owner is formally 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 software projects, including enterprise ones, are fluid undertakings, and their 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 fortune later, as they try to rescue their crumbling projects.
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).
Conclusion:
-
As a client, looking to implement an enterprise software development project using Agile, never agree to a dedicated development team that does not include a Software Architect.
-
As a software vendor, never start implementing an Agile enterprise-grade project without a Software Architect.
The above are just some of the ways an Agile enterprise software development project can be damaged or, even, driven into ground altogether. However, your familiarity with these hazards and perils and your timely action to prevent them from affecting your project are essential to ensure this project’s success.