Your agile dev teams are not enough

Gartner’s annual agile survey released earlier this year shows some fascinating insights into the world of agile development

Of course, every development organization under the sun purports to use agile methods of development. What Gartner’s survey shows is that an astonishing number of companies’ working methods are not agile in practice, despite the presence of expensively accredited professionals, such as scrum masters, working in the organization.

Development operations, or so-called DevOps, is the new hot ticket for the IT employment agency and the latest buzzword for IT management. Perhaps though, the creation of a new substrate of management is indicative of failing processes in the enterprise, rather than being the result of a level of successful activity which needs controlling.

The Gartner survey shows that 41 percent of respondents said they were using agile methods in development while a further 41 percent continued with “old-fashioned” waterfall methods of development. The remaining 19 percent used other methods.

So, are organizations actually being agile in their development?

One of the keys to agile is that code is released into production as it is developed: minimum viable products. What is happening, however, seems to be that code is being released but is being effectively sandboxed into development or test platforms and not given to end users for real-world testing. Only when significant MVPs are gathered is the sum released.

By proxy, therefore, the overall development method could be termed waterfall despite the coders and their management overseers being convinced of their cutting-edge agile working practices.

Of course, human beings are typically resistant to change and will always try and morph back into old, comfortable working practices given half a chance. The question remains whether putting in place DevOps experts will be enough to bring round recalcitrant development management teams who, we suspect, will not be too pleased to hear that their working methods aren’t “all that”.

Perhaps the problem lies in the key agile principle which states that development teams have the authority to create and change specifications as part of the process. This particular aspect of agile is one that a State of DevOps Report, 2017, touches on.

Shifting responsibility from a management layer back to the developers themselves so “non-approved” code can be released, little and often, empowers coding teams.

The ability for teams to quickly garner feedback using techniques such as A/B testing is key: it instills an experimental approach, the direction of which is determined by constant user feedback.

Educating the client

Having a development organization fully onside with agile methods, one which is releasing compliant code for user testing, is not, of course, the end of the story.

The end-users themselves, and more importantly their testing mindset, should be on board. End-users have a pesky habit of trying to do their everyday jobs, rather than committing themselves full-time to testing new code as it flows off the production line!

There is definitely, then, sometimes a process of client re-education required; the client has to be fully prepared to expedite testing and feedback, and the feedback mechanism has to be, ultimately, user-friendly.

While the latter, especially, might sound like a glib statement, the internal communications methods used by many development operations are specifically designed for staff who produce highly complex technical materials. These are not suitable for people whose computing environment extends as far as Outlook and a web browser. “People” in this instance may (at risk of offense) include management-level IT staff – it almost definitely includes end-users.

Organizations are stating that they are agile and have the staff and the accreditations to prove it. But as is often the case with management-led initiatives, many so-called agile implementations are, in fact, waterfall development working on top of internal agile processes.

Development teams are speeding through their tasks, having scrum meetings, and working hard to produce minimum viable products. But that’s where agile ends!

Throwing DevOps practices and highly-paid bodies at the issue might not be the answer. In the phrase “management theory”, the stress should always fall on the second word.

---

---

---

---