Is Agile still applicable?
I just read this interview article with Bob Martin and I have a few thoughts about it.
Uncle Bob is extremely code-focused and always has been in his career. This isn’t a criticism, far from it, but one must take that into account when reading his opinions on such matters. He is heavily involved in the Software Craftsmanship movement, which he sees as a follow-on to the Agile Manifesto itself.
Like any business practice, Agile has evolved and matured in directions the original 17 signatories never imagined . Others people beyond the original signatories have done a lot to further the principles into techniques like Scrum, Kanban, DevOps, etc. This is to be expected, imo, as something matures. Even Lean has evolved far beyond Demming’s orginal models.
Though the work of others in the field, we’ve learned that the original 4 values and 12 principles are applicable outside the context of software development. The primary direction it has evolved is toward frequent delivery with applied empiricism to use data in guiding decisions. We are beginning to do this quite well as an industry, imo. At GoDaddy, we are even using Agile practices to manage the work of our training team and that has been quite successful.
I would offer that his views are, of course, quite opinionated and one would likely hear different opinions from the other 16 original signatories. I would even call his views on Agile slightly dated.
In summary, Agile principles can indeed be applied to business practices within the right contexts and we’ve seen through evidence at other organizations (like Intuit, GE Medical, and others) that Agile practices can indeed scale. It’s not easy to do, of course, because scaling ANYTHING is difficult and more error prone than small scale efforts.
I respect and appreciate Bob Martin’s opinions, but in reading this particular interview I think they should be tempered with the evidence we have that shows Agile’s success beyond its original intent.
I think the view of Uncle “Bob” Martin is more focused on the original idea, to help software developers. Hence the name “Manifesto for Agile Software Development” and not Agile Manifesto. I totally agree with his assessments.
I have listened to Uncle Bob Martin on many occasions and have never heard him refer to the Software Craftsmanship movement as a follow-on to the Agile Manifesto itself. It would be interesting, to me, finding out what the context of this statement was. As far as calling Uncle Bob’s views on Agile “slightly dated” all I can say is: not in my book.
Thanks for sharing your up-to-date views on the Agile movement. And I don’t say this as a criticism of your views, but as an acknowledgement to the fact that the Agile movement has gone far beyond it’s original intent.
What I read in Uncle Bob’s article wasn’t that it’s bad that business is embracing Agile, but that the division between business and tech is increasing.
I think that agile and scaling are othogonal problem spaces. We are able to scale from a line of source code up to the impressive automatism of continuous delivery and devops. Why do you think there is a boundry to scale from technique up to business?
I am convinced that the barrier is in your mind only. In maybe thirty years you might look back and this scaling is as easy as continuous delivery today.
Maybe it is because many people have a fixed mental model in their heads what agile really is.
I found a good definition in health care and sports that I personally like: “The ability to move and change the direction and position quickly and effectively while in control”. an ant is able to do that and an elephant as well.
So, I am convinced if we develop many different aspects of professional behaviour like technique, craftsmanship, business models, communication, social behavior there is a way to scale agility or lean or however you like to name it then. The result: Probably even business elephants like General Motors, IBM do have the ability “to move and change their direction and position quickly and effectively while in control”.
Would you go underwater in a submarine built by SCRUM/KanBan/Agile?
would you follow a general relying on Waterfall into a war?
I would only want to follow a General who had well thought out plans. Of course in warfare well thought out plans will include a network of plans. Such that when it’s executed that given the reality that the next step is an array of plans. As major steps are taken new sets of plans are created.
However this is largely unrelated to how nearly any business operates. It wouldn’t be out of the question to plan in a similar fashion. The only example i could come up with is you’re attempting to acquire several new clients and you do not have the capacity to service all of them. Such that you plan for the implications of the permutations of client acquisitions. I’ve never seen a business plan on permutations of the future. I don’t see it starting unless network graph theory and dynamic systems become a common learning topic across workers as a whole. (I wouldn’t hold my breath)
Agile is just a meme, so most people will go along with it, as they think it is something they have to go along with, in order to be up to date.
Where I used to work ( Health service in the UK), they are just starting to adopt it (after 15 years).
No doubt, some people are making a lot of money out of this.
In the real world, we don’t consume products or services which adhere to agile principals. Although systems are always improving and evolving, you always get a “complete” system. Take, for example, my “old” Windows 7 computer. I use it for music production (Cubase Pro, many VST plug-ins, lots of out-board hardware), although I’m a Linux user. Let’s restrict the conversation to the Windows side … it came as a complete operating system, not drips and drabs. There was no value in getting a work-in-progress; I needed a fully functional system. The same applied to automobiles, for example. The entire thing needs to work, period.
The war analogy does not apply. War is not a “build” paradigm (quite the contrary).
Agile does have some use in the business world, but it cannot be applied to everything. SOME Agile principals are indispensable regardless of Agile/Waterfall. Things like “acceptance criteria” and “definition of ready” should be universal.
Agile means do what ever you please as long as it prevents coding.
I didn’t get the impression from that interview that Agile moving into other, non-software related areas was a problem. Rather, to me, it is the usurping of Agile by rigid and process heavy rulesets and consultants coupled with the reduced focus on craftsmanship that is the issue.
Some Agile-spawned methodologies might not initially seem too heavily laden with rules. What rules they do have, however, are almost always unbreakable in nearly all implementations. When an organization pays a consultancy to “implement Agile,” the bounded training materials the consultants bring, and the colorful process posters they put up, become scripture.
Like many, I’ve experienced this first hand. I’ve also experienced this on both sides of the spectrum, from small to huge enterprises. I especially loath the scaled agile movement (with Scrum often as a core component), which reeks of high consultancy fees, detailed rules that are deceptively sold as “just a framework” when in reality they become practically unyielding, numerous meetings (some that are days long), and a tremendous emphasis on project management-style milestones and roles. From my experience, when Agile gets implemented across a large enterprise, there is almost zero ability for a single individual or small team to improve things. And it begins to look a lot like waterfall in disguise (heck, Scrum is mini-waterfall). In this format, the codified process has become anti-agile.
I think Uncle Bob Martin is exactly spot-on when he says, “It may be that the only way is to adopt agile is at small scale, and even in a large organization you wind up with a bunch of very small agile teams.” I would add that these small teams need autonomy to adapt their processes as most befits each team.
I believe Uncle Bob is referring to the adoption of the ‘process’ oriented agile techniques but forgetting the ‘technical’ oriented ones, leading to failing agile teams. This is the imbalance that needs correcting – no point managing a team efficiently if the team is a low skill level and not given a chance to increase in skill. I think this applies to all disciplines.
Thank you for sharing the nice article. The content you had posted is much interesting and really nice. It is much informative i got lot of information here. So please keep update like this information here.
Hadoop Training
Hi David! I’ve just started my new job is Zaven http://zaven.co/. It is a software development agency and Agile methodology fits perfectly in this industry. But before I started working here I had read lots of articles about Agile and mostly people were very satisfied with implementing Agile to different industries. So I think it is still applicable. Great article! Cheers!