Is your organization using Agile for development? Are you sure? What if you're actually doing Agile in Name Only (AINO)? We discuss what this is, how to detect it, and what can be done to change direction.
Links:
Forbes article on Microsoft's adoption of Agile
US Gov article on "Detecting Agile BS"
The risk of "fake Agile" in Department of Defense
Impact of Agile adoption at Microsoft (case study)
Take a listen here - http://apexbpm.libsyn.com/004-agile-in-name-only
Transcript of the Podcast:
Blake Smith:
Accelerate Business Transformation by Apex Process Consultants. Welcome to Accelerate Business Transformation by Apex Process Consultants. I'm Blake Smith.
In a 2015 Forbes article senior writer Steve Denning described how Agile programming methodologies have transformed Microsoft. For a software company, Microsoft had long been viewed as a slow and lumbering ship that took direction from the top and was slow to change course. After the adoption of Agile, Denning described the company as being more like, “A flotilla of speedboats operating and maneuvering in an orchestrated fashion.”
As a mode of transformation, Agile is currently the gold standard for rapid accomplishment, but what happens when an organization takes up this trend in appearance only by cloaking their traditional approaches with new labels. In the 1982 movie, Poltergeist, the occupants of Cuesta Verde suffer tremendously because the housing developer-built homes on a graveyard without actually moving the graves. This seems like an apt metaphor for what we call Agile in name only. You don't want zombies of stale and rotten approaches popping up in your projects.
This is a big enough problem around adopting Agile that the US government released a 2018 document called Detecting Agile BS. I'll put a link to that, plus some other articles about this topic, in the show notes. In today's episode we're going to look at Agile in name only and talk about how you can spot it and what you can do about it.
Welcome back to Accelerate Business Transformation, by Apex Process Consultants. Today, we're going to be looking at problem of Agile being used in name only. I think, in our previous episode we did a good job of covering what Agile development methodology is, and why it exists, and why we use it, and some of the challenges around it.
But, one of the biggest ones that I've run into is people who say they're Agile, but when you really start to look at it, they are not doing Agile. Today, we've got Nick Laughton with us again.
Nick Laughton:
Hello, Blake.
Blake Smith:
Hello, Nick. So, Nick, is there some kind of test someone could use to figure out if their organization was really doing Agile or just doing Agile in name only?
Nick Laughton:
Well, I think the true test is to look at the criteria laid out in the Agile manifesto, so you have to ask yourself, is this organization really prioritizing working code above documentation? Is it prioritizing collaboration between people above tools and processes? There are a few indicators that sometimes you can see that might show you that perhaps that's not really the case.
Blake Smith:
I was talking with my sister in and her company, they have been doing Agile, and she hears Agile as a buzzword a lot, but apparently they haven't released any code in close to a year, and that sounded wrong.
Nick Laughton:
That does sound a bit suspicious, doesn't it? But it happens. Yeah. I think sometimes you go to places and they're talking about having a documentation sprint, for example, or a requirements sprint, which certainly doesn't sound like it's going to deliver working code. So, you start to question whether that's Agile.
Blake Smith:
I'm trying to imagine what that would be like. It sounds contradictory to the Agile approach. It's not against having documentation, but it's: get working code first.
Nick Laughton:
Yeah. Well, I think what it is, is it's people who are familiar with the waterfall process attempting to shoehorn, or put Agile terminology around what they've always done as waterfall process.
Blake Smith:
Right? So, literally, in name only, right?
Nick Laughton:
Yeah, so they didn't say, "Well, first thing we do is gather requirements, so we'll call that our first sprint, and then we'll start to develop the code and that'll be our next sprint." So, yeah, that is definitely Agile in name only.
Blake Smith:
Yeah. And so, sprint length. What's ideal? I guess it's going to vary by organization.
Nick Laughton:
Yeah, it can vary by organization. It can vary a bit by technology and the size of the team, but typically one to two weeks. Two weeks is probably average. When it gets going really well, you can get it down to one week. Sometimes three weeks is appropriate. Sometimes four weeks is appropriate, but if it starts to get much longer than that, then I think you, again, have to question, "Are we really doing Agile here or something else going on?"
Nick Laughton:
We often try to size a sprint by how many requirements or user stories the product owner can be familiar with in their memory, in their working psychic RAM. How much can they handle, to hold in there at the same time, and size the sprint based on that? So if you look at the number of user stories that our typical team can get through in a week or two, that amount of stuff is about as much as a product owner can think about for that period of time.
And, when you start to make the sprints much longer than that, it's hard for them to stay very familiar with everything that the team is working on throughout the duration of the sprint. So, that's an interesting angle on sizing the length of the sprints.
Blake Smith:
It is, indeed.
Nick Laughton:
Slicing, Let's talk about slicing. So, we talk about the Agile approach is using a cake slicing approach. So, when you get a slice of cake, depending on the type of cake, obviously, you might have some different layers of cake with maybe some cream, or some jam, or some chocolate, or something in between. You cut the cake vertically and each piece of cake has some of each slice in it.
And so, the ideal Agile user story delivers functionality and has a little piece of each layer of the infrastructure built into it. So, when we deliver a piece of working code at the end of an Agile sprint, it may be that there's some user interface that's been developed for that user story.
Maybe a new API has been developed for it against the backend of the system. And, maybe there's some backend logic and perhaps some data persistence, maybe some changes or additions to database tables that have been put in, all to support that one small piece of functionality which is delivered as a user story and can be tested and accepted.
Blake Smith:
And, what would be the anti-pattern?
Nick Laughton:
Well, the anti-pattern is when you start hearing people talking about having a sprint to establish a data model, or a sprint to build a database, or a sprint to build the API. So, if you think about that, they're talking about the layers in the application architecture, and when you talk about delivering a layer, you're not delivering any piece of end user functionality. You're delivering a spread out thing that is hard to test-
Blake Smith:
Yeah.
Nick Laughton:
... any meaningful user requirement.
Blake Smith:
It's how to eat an elephant. Right? There's a lot of metaphors around this. The journey of a thousand miles begins with a single step, or in my personal philosophy, is that every complicated working system necessarily evolved from a simpler working system, which is beautifully built right into Agile. You build small working parts and then eventually you have a really complicated, or possibly, complicated but functional, bigger system.
Nick Laughton:
Yeah, yeah, absolutely. I think that's even another Agile principle, right? Never let perfection get in the way of something that works.
Blake Smith:
Yeah. Well, and of course I need to give credit that I'm quoting Gall's Law. I'm actually technically misquoting it, but Gall's Law is roughly that any complex system that works invariably evolved from a simpler system that also worked. And, over the course of my career, I've gone from thinking that's a really funny, albeit cynical, take to believing that it's a fundamental reality of how things get done.
So, it went from being a joke to a philosophy.
Nick Laughton:
Yeah, Well, I think it is. And, you can take that cake slice analogy beyond the user story to the sprint planning level ad say, maybe in our first sprint we're going to deliver the functionality to take the thinnest vertical walk through core capability that this new thing is going to offer, such that we can demonstrate to ourselves and to the team that, when it's all finished, it's going to be able to achieve the primary business purpose.
Nick Laughton:
And, to do that, we're going to leave off all kinds of ancillary stuff. We're not going to have fully-specified roles, or security permissions, or a whole bunch of other things will be ignored while we prove that vertical slice from top to bottom to show that it can do what it's supposed to do.
Nick Laughton:
Yeah, once it's established, then we add on the rest of the functionality, as you say. So, you start with something that works to do something, and then, build on it.
Blake Smith:
It's interesting because the waterfall approach, in a lot of ways, it is inherently counterintuitive from an engineering perspective. I mean, it's how things got done for 20 or 30 years, but, it's as likely to be a roadmap to failure as success.
If you're building a house, you may start with a blueprint, but you don't start hanging chandeliers until you finish framing and dried in the house and put up drywall. There's lots of process, so building a house, even though you can put lots of crew on it, it still comes down to small jobs that work together to build a big job.
You can't put the roof on until the foundations are there, but you can do a lot in software that you can't do in a real world. So, those metaphors break down a little bit, but you still prioritize how you take on these tasks. So, in a perfect world, you're working with your business lead, divvying up the work so that as you develop your sprints, you're getting out the functional code that's going to become that framework. But what's the anti-pattern?
Nick Laughton:
So, one anti-pattern is trying to plan too many sprints at once. Really, the downfall of the waterfall process is that it assumes that you can fully document the requirements at the beginning and that they won't change as you go along, when the reality of the world is that, what is the quote? No plan survives first contact with reality.
Blake Smith:
Yeah.
Nick Laughton:
You've got to be able to adjust and reprioritize as you go along.
Blake Smith:
Yeah. Again, going back to the house, it's, "I've planned this kitchen out perfectly. Oh, they changed the shape and size of the refrigerators that they don't fit in our cubby. That stove no longer fits."
Nick Laughton:
An even better example is that the builder starts to put in the kitchen island and the new homeowner walks in and says, "Wow, this is way bigger than I thought it was going to be." Or, "Oh, man, it would be so nice if we just had a window over there where we didn't plan to have one."
Blake Smith:
Oh yes. Oh yes. Yeah. There's this one drawer in my house that perfectly bumps into the edge of my stove if it's not perfectly closed, it's, oh, oh, it makes me want to tear my whole house down and start over. We, literally, just don't use that drawer. But, I'd love to have that whole thing redesigned. Well, way to bring it home. Okay.
Nick Laughton:
Yeah. So, like you say, there could be external factors like the dimensions of appliances changing, or it could just be that when people see it, it's not what they thought they wanted, they said they wanted this huge kitchen, but when they walk in and they say, "Oh wow, maybe I didn't want this after all."
Blake Smith:
Yeah. It also fits into why envisioning, or envisioning strategy, is so helpful because I think that uncovers a lot of those things that would slip right past. And also, I think if you do all that planning, you miss on opportunities for process improvement. You end up codifying the way things are done and miss opportunities to make a better way. So, that could be problematic.
What about quality assurance and testing. How do those fit into this, in a perfect world versus the anti-pattern?
Nick Laughton:
Yeah, good question. Well, in a perfect world, the testing is really integrated with the Agile team. Testers are part of the team involved in the writing and review of the user stories, and involved in building testing quality assurance test cases right from day one that can tie into the business need as being expressed through the user stories.
So, yeah, if you find yourself in a situation where testers are sitting around waiting for a release to get completed before they can do any testing, that then could be an indicator that maybe you're Agile in name only.
Blake Smith:
Yeah.
Nick Laughton:
One of the things that could cause that to happen sometimes is if user stories get too large. One of the most important success factors for Agile is keeping user stories under control, in terms of how big they are and being willing and able to break them into smaller pieces as soon as they reach a certain size so that we keep the unit of work down to something between half a day or two days of development work per story.
Nick Laughton:
So, again, anybody that tells you they've got a 21 story point story on their agenda, you have to question how Agile they are really working.
Blake Smith:
Yeah.
Nick Laughton:
And then, related to user stories, I think another indicator is how prioritization is being done. I think one of the most effective and freeing approaches of Agile is the ranking approach to prioritization, where the prioritization activity is simply comparing each story to all the other stories and saying, where does it fit in the overall rank?
So, when people start sending around spreadsheets that have many different categories for nice to haves, must haves, really, really must haves, really, really, really must haves, and start talking about releases being delayed because they don't have all their must haves, then that's another indication that maybe they haven't quite fully bought into the Agile process.
Blake Smith:
Yeah. Have you had any experiences of organizations were running into this where people are doing the Agile in name only approach?
Nick Laughton:
Yeah. I think all of the things that we just discussed have come from real-world examples. When people have worked with the waterfall processes for a long time it can be hard to change.
Blake Smith:
And, some of the articles I looked at that got me onto this topic were around how Agile has been incorporated at Microsoft, which was really interesting to watch because it came in almost as a renegade project. Very small groups started to incorporate it into their development style, and Microsoft was more famous for running big, massive waterfall-type projects, and over time Microsoft has quickly switched to being almost exclusively an Agile shop.
Blake Smith:
Along those lines, two examples of government use of Agile, and it turned out that a lot of the government's implementation was, somebody told them to do Agile, they didn't know what it was, they started calling everything Agile. I'll put some links to this in the show notes.
I certainly do believe that, at least in places, across lots and lots of organizations, there are places where it's being used absolutely as intended, and places where it's being used absolutely wrongly, but being called Agile, and I'm sure a variety of mixes.
Our goal for this show is to provide people with, not just information on what is good, what is bad, that sort of thing, but also to give them some tips. So, if you find yourself, you're in an organization and it turns out that you're only doing Agile in name only, what are some steps to try to recover and get into an actual Agile mode?
Nick Laughton:
Well I think the first step is to make sure you have the right roles, is to make sure you have the product owner, the scrum master, and, as far as possible, the dedicated teams. And then, I think, really, the next step is to focus on the user stories and make sure that you have them written in a way that would be considered Agile best practice, following the form as a role type. I need to do something so that, and express the business value.
And then, have the acceptance criteria truly spelled out in a way that gives you some testable means to determine if that user story is being done or not.
And then, I think the third step really is to focus on your sprint timetable and really take a look at following the outline we described in the last show, incorporating all of the main activities in that sprint cycle, from the planning and the backlog grooming, through to the playback at the end of each sprint.
Blake Smith:
It is interesting that this has had such a big impact, as a methodology, to have come from such a small group just sharing their approach. If you go read the Agile manifesto, it doesn't spend a lot of time telling you, specifically, how to implement it, so there's a lot of differences in the way that people implement it.
If you were in an Agile in name only shop and you wanted to try to build a true Agile shop, do you think it's possible to do that as a rogue team, or what's the minimum you'd have to be able to pull that off?
Nick Laughton:
I think you can, up to a point. So, you can establish a small team that's operating under Agile principles within a larger organization that isn't. Obviously, there's some boundary constraints as to how far your Agile team can get. You can deliver your working code at the end of each sprint, but maybe the rest of your organization is moving a little slower and gathers up the output of many sprints to make a release, which is pushed further into production on a much less frequent basis.
But, I think it is possible to form these pockets of Agile, and then that, hopefully, demonstrates to other teams within the organization the value of working that way and brings other people on board.
Blake Smith:
In a perfect world, it's a top down mandate, but it's a bottom up approach for build. Do you have any suggested reading, or material that people might find helpful if they're trying to make this conversion?
Nick Laughton:
Yeah. I'm just reading, at the moment actually, a book called The Scrum Fieldbook. As you said, the Agile manifesto is not very prescriptive on actual methodologies or processes for implementing Agile, but scrum is certainly one of the most popular Agile methodologies. Yeah, the Scrum Fieldbook, but by J.J. Sutherland, and I think his dad was actually at the famous ski resort meeting where the Agile manifesto was originally written down. So, yeah, that's a pretty good resource.
Blake Smith:
So, you had a recommendation around continuous integration, continuous deployment.
Nick Laughton:
Yeah, I think it's become a bit cliché, but The Phoenix Project is a really good book on that, written in a novel form. It openly acknowledges that it was inspired by The Goal, which was a manufacturing textbook back in the 1980s, I think, that was written in the form of a novel to get some key principles across on the theory of constraints and how it applies to manufacturing productivity.
And so, The Phoenix Project is a book about continuous integration, continuous deployment, which is really taking Agile principles and applying them in IT operations such that you can build the velocity of your operations team to support the frequent and regular delivery of code from your Agile development teams.
Blake Smith:
You've spoken very highly of it. Like you say, it's a book that comes up a lot, but a lot of times clichés have a reason that they're popular.
Nick Laughton:
Yeah.
Blake Smith:
There are principles like test-driven development, or TDD, and continuous integration and continuous deployment of CIACD. Does adopting those help correct course if you are one of these name-only shops?
Nick Laughton:
I think test driven development for sure. As I said already, I think having testers deeply embedded in the Agile teams to make sure that the acceptance criteria that are being developed for user stories are truly testable criteria is very helpful in moving you towards truly Agile.
Blake Smith:
Testing being a part of the process also uncovers places where there's a problem where that that island in the kitchen is too close to the door, or whatever.
Nick Laughton:
Yeah,
Blake Smith:
Yeah. It's a lot more than, just does it function, I think, when you have that feedback loop, it helps keep things true, but also uncovers design issues and various other issues.
Nick Laughton:
Yeah. Sometimes, even when you've got a very good product owner who's very familiar with what they're trying to achieve and writing good user stories, when they spell out the acceptance criteria and somebody says, "Well, how are we going to test that?", it can generate a whole line of discussion that clarifies things more for the product owner, as well as for the team that's going to deliver that capability to the product owner.
Blake Smith:
And, tell me about CI/CD.
Nick Laughton:
Yeah, so CI/CD, I'm not sure that adopting CI/CD helps you go Agile or whether you're better off thinking about CI/CD as Agile spreading through the rest of the IT organization. I guess you could have a waterfall development team in a CI/CD organization, but it doesn't seem very likely.
Blake Smith:
Yeah.
Nick Laughton:
It seems much more likely that you would start with this pocket of Agile that we described earlier, which is delivering value in the form of working code every week or every two weeks, and that code stacks up into chunks which the IT operations team is comfortable deploying to production once they've put it through their procedures for security and performance testing, and all the other things that operations teams have to worry about.
And, as they adopt CICD, they figure out how to incrementally run all of those tests and incrementally deliver that software into production so that, ultimately, what you're hoping for is as your Agile team is pumping out value on a weekly basis, that it can be going into production on a weekly basis.
Nick Laughton:
So, I think a lot of organizations are starting to look at this. I don't know how many of them are truly at the point where they're comfortably pushing new code to production daily, or even hourly, basis. But, I think the leaders are.
Blake Smith:
if you find yourself in this situation that you're in a waterfall organization or you're an Agile in name only shop. If you wanted to approach leadership to try and get them to change, and I'm assuming here that you're not leadership, you're somewhere down the chain, but what might you do, or how would you recommend approaching leadership to try to get them to adopt something that comports more closely with the Agile manifesto?
Nick Laughton:
That can be tough. Obviously, it depends a lot on your leadership. It can certainly help if you can point to other projects or other organizations that have been able to achieve some of the benefits of Agile. It can help to maybe bring in an external consultant like Apex, for example, to talk through how it could work for your organization and how we could start some pilot projects to demonstrate that the Agile approach is worth bringing in.
Blake Smith:
No, but it requires something like a paradigm shift, doesn't it? Because it's easy enough to tell someone, intellectually, that this is better than that, but actually seeing it executed, and not that you need to necessarily have a bake off or something, but to be able to see how Agile projects approach and execute successfully versus ones that just have the label on it but are actually still waterfall.
It's a pretty clear difference and I think you would get to working code a lot faster. So, that's the kind of demonstration that, it's like an infomercial. Well, obviously I want the one that cleans my pan when I just drop it into the liquid. It's all work. Agile is work, waterfall is work. Any of these techniques require lots of labor, but knowing that you're more likely to get a successful bit of working code out the other end and faster, to me, makes it really an easy sell.
But, this is more about persuasion, and if the leadership has an entrenched passion for waterfall-style development, maybe they're old school, maybe that's how they've always done it, it may take some kind of a demonstration to prove it. I don't know.
Nick Laughton:
Yeah.
Blake Smith:
Certainly we can get you some more information if you're curious about that to help make that case.
Nick Laughton:
Yeah, definitely. Well, you say, it's all work. Again, I think one of the principles of the Agile manifesto is avoid doing as much work as possible by identifying work that doesn't really need to be done.
Blake Smith:
That's true.
Nick Laughton:
Maybe that, in itself, can be part of the sale.
Blake Smith:
So, that you too can be part of a ski lodge retreat instead of working 15 hour a day weekends trying to get to the release deadline. So, it is a different approach. All right. All right. Nick, that's fantastic. Thank you for helping me with this overview of Agile in name only. Is there anything else you want to add?
Nick Laughton:
No, I don't think so. You're very welcome.
Blake Smith:
All right.
Nick Laughton:
Always happy to talk about it.
Blake Smith:
I'm Blake Smith. Thanks for listening to Accelerate Business Transformation by Apex Process Consultants.
