Project Methodology in 2020 (Part II): Speaking Of Agile
As we discussed in Part I of this series, Agile is the new religion when it comes to Project Methodologies. Many experienced project managers would argue that Agile only really applies to a select type of technology project, but even that assumption is now being challenged.
Like most popular management principles that we’ve all seen, there has been a tendency to make Agile into a fad. As mentioned in Part I of this series:
Agile methodologies seem to be the wondrous hammer that makes everything seem like a nail. It is just, unfortunately, not all that simple, and saying the words “Agile. Agile. We are Agile,” does not magically transform what we are actually doing.
Of course, any fad generates its own energetic commentary that takes us away from the core of whatever that fad is based upon. So I think it is helpful to go back to the initial, core principles of Agile.
The Agile Manifesto
As Claire Drumond of Atlassian notes in her description of Agile’s “origin story”:
In early 2001, against the backdrop of the Wasatch Mountains, in Snowbird, Utah, 17 people met to discuss the future of software development. The group’s members shared a frustration about the current state of affairs, even if they disagreed about how to remedy the situation.
The problem, they agreed, was that companies were so focused on excessively planning and documenting their software development cycles that they lost sight of what really mattered — pleasing their customers.
Companies may have touted corporate values like “excellence” and “integrity,” but these values did little to guide people — especially software developers — toward a better way. That needed to change. Many of the Snowbird 17 already had ideas about how to usher in software development’s new era. The trip to the mountains was their chance to hash it out.
The Agile Manifesto emerged from this extended weekend at just 68 words, and the short and sweet document went on to change software development forever. In the nearly two decades since its creation, these words (and the 12 principles that follow) have been embraced (in varying degrees) by countless individuals, teams, and companies.
The “twelve principles” of the Agile Manifesto are:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity — the art of maximizing the amount of work not done — is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
These simple principles started the idea of Agile before there was any thought of a more formal Agile “methodology.” So the question is, now that we have Agile Methodologies and Frameworks such as Scrum, Kanban, Extreme Programming, and several others, are we staying consistent with these principles?
The Enabling of Cowboy Programmers
One thing we do know — and many of of us project management types have experienced this directly — is that soon after its introduction, Agile quickly become an excuse for sloppy, just do it behavior. Agile Coach Mike Carey writes about this problem. As Carey puts it: “Agile developers do not shoot from the hip.” Or maybe, he just meant that they shouldn’t shoot from the hip, and that this behavior has nothing to do with Agile.
Still, many programmers I’ve met, since Agile started to become more widely used, seem to think that Agile is the perfect license they need to carry out some of the worst software engineering practices known to humanity. Carey lists them out into categories:
- “…making changes directly to Production (code) without due diligence”
- Arguing that documentation is a waste of time, by quoting the Agile Manifesto out of context: “‘Working software is the primary measure of progress’; anything else is just a waste of time!”
- Arguing that another Agile Manifesto element (“The best architectures, requirements, and designs emerge from self-organizing teams”) implies that the best thing to do is to “just make it up as you go.”
I distinctly remember one particular cowboy programmer experience when our firm worked with an internet based advertising and search client to roll-out one of the first significant installations of Atlassian’s Jira back in 2005. The fact that the client’s information technology management was sanctioning Agile as a management philosophy seemed to worsen the client’s already poor software development practices. When I interviewed one of the lead developers about his team’s software development practices, he was just concerned that everyone “wanted to control them.” His take on software development — to the extent that he was able to articulate one — was something along the lines of what a skilled artisan, who just wanted to be left alone, would express, and yet he was the team lead of the most critical technology area in the client organization.
Agile: Picking up Speed
Published on May 28, 2020, The 14th Annual State of Agile Report, according to digital.ai (the authors of the report), is “based on the experiences of 1,100 IT and business professionals from around the globe.” The underlying survey results indicate that “95% of respondents report their organizations practice Agile development methods. In March of 2018, in a slightly different survey reported by Harvard Business Review of “almost 1300 IT and business leaders,” “Around three-quarters (75%) of executives in the survey” said that Agile “can play a crucial role in delivering the right products and services, accelerating decision-making and speed to market, while also improving the customer experience and staying ahead of the competition.”
It is quite possible that the Annual State of Agile Report surveyed more technology-oriented executives, who were already convinced that Agile was the way of the future than the Harvard Business Review (HBR) reported survey. Whether that is the case or not, the trend line is clear here: Agile has reached extremely broad use in the vast majority of information technology departments in organizations throughout the world. One caveat around this trend is that in the 2018 survey cited by HBR, this does not imply that every company has fully deployed Agile: “Most companies report that while there is some use of agile practices throughout the organization, implementation is not broad or deep.”
Siss. Boom. Ba….Everything is Agile?
Is all of this hoopla around Agile merited? For many of us project management types, Agile has been a story of great successes and great failures, since meeting specific project objectives is not always easy to do on Agile projects, as companies attempt to implement Agile; but according to the The State Of Agile report, these companies are embracing Agile methodologies or frameworks for a lot of the right reasons. The report indicates that 71% of recipients adopted Agile to “Accelerate Software Delivery,” 63% to “Enhance Ability to Manage Changing Priorities,” 51% to “Increase Productivity,” and 47% to “To Improve Business/IT Alignment.”
More worryingly, though, for project managers, the report also notes that Agile was only adopted 42% of the time by firms who sought to “Enhance Software Quality” and 37% of the time by firms who sought to “Reduce Project Risk.”
For me, the biggest challenge with Agile is trying to get my clients to embrace it where it makes sense and reject it where it does not. The whole situation reminds me a bit of when everyone who had any kind of corporate job (and all of the consultants supporting them) was reading Reengineering the Corporation, which was first published in 1993. Back then, no one wanted to just “cement the cowpaths” with simple process improvement. We all wanted to blow everything up and completely rethink things. How many failed initiatives were embarked upon due to this business improvement fad? This was followed closely by “disruptive innovation,” as introduced to us by Clayton M. Christensen in The Innovator’s Dilemma, 1997, which, as Jill Lepore writes in The New Yorker, is a “theory of history founded on a profound anxiety about financial collapse, an apocalyptic fear of global devastation, and shaky evidence.”
It is not that reengineering business processes, approaching business strategies with a “disruptive” mindset, or embracing Agile to pursue technology endeavors are the wrong things to do. In fact, all of these approaches can be quite helpful, and we should be glad that they are part of our business problem-solving toolbox. It is this tendency among the various tribes of our species to find a new useful tool in the toolbox that might look like a hammer, and then the whole tribe begins to see everything as a nail, that is the troubling part.
Along these lines, one key question to ask: is Agile making our Projects generally more successful than other project methodologies? According to Anthony Mersino, who is the founder of VitalityChicago, and also happens to be an Agile Trainer and Coach, Agile Projects are successful 42% of the time compared to “Waterfall” projects that are successful 26% of the time. This is based on Standish Group’s 2018 study. Apparently, Standish uses a “research database of 50,000 projects,” to complete their “CHAOS Reports,” but this is the only research I am able to find on this topic (I cannot corroborate these studies with any similar study). The challenge here is that you’ll find Agile Trainers, Coaches, and others who make money from the Agile Industrial Complex, blindly quoting this study when three key things are not elaborated on:
- What kind of projects are being executed (since not all projects are meant for Agile or “Waterfall”)
- What is meant by “Waterfall” projects, and were Agile projects compared to other types of project methodologies?
- What do we mean by success? We already know from the latest State of Agile Report that success seems to be measured in different ways on Agile projects. For example: “Business Value Delivered” is the highest success criteria mentioned in the report (noted by 46% of respondents). “Budget Vs. Actual Cost,” “Planned Vs. Actual Release Dates,” and “Defects into Production” are only considered to be project success measures by 31%, 28%, and 26%, respectively, of all survey respondents.
More to come on Agile and Project Methodology in 2020 in the final installment of our series Project Methodology in 2020 (Part III): Disciplined Agile and Hybrid Methodologies.
Get new GlobeBlog Posts delivered directly to your email box. Sign-up for the BlueNotes Newsletter.
