Big A or Little a Agile

This week, I have had various experiences that have prompted me to put my fingers on the keyboard about AGILE. This article is not entirely an academic piece nor an industry opinion piece, but it is an observation of confusion in the current space, which may be why information system projects continue to fail at alarming rates.

I refer first to the Agile Manifesto, which states, "We are uncovering better ways of developing software by doing it and helping others do it."

This means that Agile refers to Software Development, NOT Project Management. Further, Agile is not in and of itself a methodology either. SCRUM is an agile software development methodology. Extreme Programming is also an agile software development methodology.

PRINCE2 is a Project Management methodology. By extension, PRINCE2 for Agile is a Project Management methodology suitable for managing software development projects that use agile principles and may use, for example, SCRUM, LEAN, or eXtreme Programming. Other Project Management methodologies may include Critical Path Method, PRiSM, or Benefits Realisation Management.

I teach my students about standards, methodologies, frameworks, bodies of knowledge, tools, techniques, and artefacts. All of these must be used together to achieve an appropriate outcome. One of the first tasks for a Project Manager is to determine a project's scope and understand the type of problem they must solve. With this information, a Project Manager will choose the most appropriate methodologies, tools, and techniques that adhere to best practices, standards, and knowledge bodies, while ensuring the team provides the appropriate artefacts that help communicate to all stakeholders.

So, when I hear of organisations going Agile – I want to scream! Expensive consultants often sell an organisation the benefits of agile by claiming speed to delivery, increased customer satisfaction, and provides transparency of delivery. And yes, all these things can be achieved. However, the perils of agile are rarely spoken of.

One of the first common issues – is the Retrospective.

Here a team will gather to discuss things that went well and things that could be improved. However, what I often hear (and have personally experienced) is the inability of the team to perform as a self-managing team. All the hurdles are often management problems, and sprint after sprint, the same issues come up repeatedly. The Retrospective aims to clear these issues as soon as the next sprint. Relying on managers to enable change defeats the purpose of self-managing teams.

Another common issue – is Planning & Grooming.

Associated with planning & grooming issues is often tool selection. JIRA is a great tool. However, too often, business then thinks that JIRA is SCRUM. As such, companies often neglect the pre-planning and sprint planning stages that are so necessary because there are no apparent steps within tools like JIRA. One organisation I worked for was an exemplar of planning & grooming. We had a dedicated analyst whose job was to work with the business and groom the cards in the product backlog. Every quarter our Product owners would meet and rank and order the groomed cards (and sometimes have some heated discussions) over what needed to be prioritised for the quarter. Decisions were made based on priority and points. The sprints were 2-week sprints; therefore, each quarter included six sprints, with each sprint usually holding 50 points of capacity (this was their average velocity from prior sprints). Once the priorities were set for the quarter, each sprint was planned, and cards were placed into each sprint backlog. What an exemplar! However, what I have further observed, are poorly groomed cards, a lack of customer engagement, a lack of prioritised work, a total lack of accounting for this planning effort during the preceding sprint, confusing a product backlog and a sprint backlog, not closing a sprint because work is incomplete, and just a general attitude that "agile" means I just worry about that when I'm doing it.

One final issue – is Acceptance Criteria.

Waterfall methodologies were often critiqued for introducing testing too late in the process. The V-model method sought to address this issue, encouraging test strategy, processes, scripts, and data to be designed alongside requirement elicitation and analysis. Agile methodologies are also supposed to correct this issue. Acceptance criteria must be written simultaneously as a User Story, not when the card is placed in the quality assurance column.

Unfortunately, I could go on…. But I also want to wrap this up by saying don't let agile methodologies rule you. Agile methodologies are not the panacea that will save your organisation and projects. Often the exact reasons why other methods fail often persist when switching to agile methodologies because you are not addressing the real problem. For me, the real problem is a lack of ability to communicate a business need and place appropriate governance around the decision-making process. Little a agile or Big A Agile will not fix that.