Update 2024-02-18: Unlike the rest of the articles I reloaded from the archive, I didn’t check the links in this one. There is quite a bit here that is dated (like it’s super easy to set up CI with Azure nowadays, instead of what was mentioned) but the core premise of the post still stands.
I don’t often write opinion pieces and in fact, I’ll try and keep the opinion in this post to a minimum. I don’t intend to link bait, I think this is my way of rubber duck debugging, of gathering my thoughts, getting my observances out and hopefully hearing from the community at large to voice your opinions.
I need to start by saying I’ve never worked in an Agile shop. I’ve never seen it in practice, never seen how truly effective it can be (if it can be). To me Agile feels like how MVVM did before I started working with it. Though I had understood the principles of MVVM, it felt bloated and impractical, too much process in the practice. Eventually, though, as you start trudging through your first application the blinds get pulled back a little bit and you start to see some of the benefits, everything starts to wire up so easily. Adding new features, fixing bugs is easier, unit tests hook in easier, solid n-tiered architecture.
In the end you end up with virtually all your code being watched over by unit tests because they just work on your view models, and you don’t care about code behind causing problems. But I don’t think until I had put MVVM into practice did I really understand the benefit. It’s easy to dismiss, easy to point out that there is a significant overhead initially in developing an MVVM based application (which is why MVVM should not be used for simple projects). You have to have management that understands the long-term benefits in the maintenance tail and this doesn’t always happen. But Agile isn’t an architecture for software development, it’s a set of development practices.
Iterative Waterfall
I’ve always used iterative waterfall (aka iterfall) as the basis for my development. Start with as much of a thorough understanding of requirements as possible, make sure they’re all written down and agreed upon. Move on to design. Do your ERDs and XSDs and class diagrams and wire frames. Take those designs to the client. The wire frames are especially important for the client. Once they understand what the application is going to look like and how it’s intended to work there will be requirements changes. No biggie, go back to requirements, fix the problems, modify the design documents and then get approval again. Once design is done start implementing the application. You may run into a problem with the design, so go back to design, if it’s going to be a problem there then go back to requirements. Does it need to be a requirement? If yes, then move back down and, though it may be painful, fix it in design and then get approval from the customer. Then fix it in implementation.
The key to iterative waterfall is to never being afraid to move back a step. Unlike a traditional waterfall, never feel like you’re locked into a step. Just because you’ve got sign-off on requirements doesn’t mean they won’t change. And that’s okay. The other thing I like about iterative waterfall is that as you’re sitting down to do your project plan and laying out how the application is going to happen, each task becomes it’s own iterative waterfall. Then when you get into the maintenance tail the iterative waterfall starts all over again.
This is still, however, a “Big Design Up Front” approach and is distinctive from the iterative and incremental development practices of some Agile process because rather then working each cycle completely, in iterative waterfall you move within a path forwards or backwards. So is this bad?
Agile Practices
There are some aspects of the Agile process I have seen as beneficial and attempted to incorporate it within my process when I worked as a project lead. One of the best, with a major caveat, is pair programming. That caveat is that when attempting to do pair programming you have to be very selective in terms of who you pair up together and it’s not for everyone. Where it made sense I attempted to incorporate pair programming, working with another software engineer side-by-side. We would discuss our thoughts on what we were implementing, potential issues and conflicts with other aspects of the application. It would be a quality collaboration that produced better code.
But I couldn’t work with some engineers like this. One engineer would just shut down. He would mindlessly type at the keyboard whatever I was saying. When I was at the keyboard it was like trying to pull teeth to get him to contribute. It worked better to step away from the computer and have more of a casual conversation regarding what he was working on and then to let him go forward. Then there are those engineers who fit the stereotype for software engineers. They tend to be introverted. They don’t talk a lot. It’s incredibly hard to get them to contribute at meetings. But let them sit alone in front of a computer with an idea of what you need from them and you’ll get 12 hours worth of work in 2. All I’d often get from software engineers like this is uncomfortable squirming. They don’t want you there, they don’t want you on their computer, they don’t want to be on your computer. They just want to be left alone to work. They have things set up just right for their environment and that’s how they like it. So pair programming works, just in a limited scope with limited participants. This doesn’t make it bad, it just needs to be applied within the scope of the engineers assigned to a project.
Now I do have to say I’m not a fan of the “Daily Scrum” idea. What I found most effective is for me to meet with each of the engineers (or if I was in a larger project I imagine with each team lead) and see where they were at. I had a time, 9 AM, because by then everybody would be in, where I would walk around to each engineers, ask them what they were working on, how things were going and any problems whey were having. Now the largest team I’ve ever lead had only 4 engineers other then myself. So maybe it’s just that where simple projects don’t benefit from MVVM, maybe I’ve never worked on a project large enough that it would have benefited from Agile.
Continuous integration is another aspect of Agile I think is necessary to any development methodology. With so many tools out there it should be just the norm. We use CrouseControl at work but Scott Hanselman just did a great article on AppVeyor for continuous integration.
Use case and user stories are fundamental to the design of an application. They’re listed as an “Agile practice” oddly enough but I always thought they were crucial to the design phase of a waterfall.
I like the idea of Sprints post-implementation. When the user’s start using the application and you start getting bug reports and feature requests in it makes sense to go with a more rapid release cycle until things settle down and then move out to a quarterly release cycle (except for high priority bugs). But does this make sense during initial application development. Maybe it’s my own ignorance. Maybe I don’t understand what a Sprint is. So here is the definition from the creators:
The Sprint The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints best have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.
The Scrum Guide™ The Definitive Guide to Scrum: The Rules of the Game, Ken Schwaber and Jeff Sutherland
If you read the above reference you get a bigger understanding of the picture. It just means within the timeframe of the sprint you have to have your code ready for production. It doesn’t mean that the application as a whole needs to be ready but that the code you are responsible is ready for production. And there is a lot more to Scrum. (But isn’t this really just milestones?)
Agile Methodologies
But is Scrum Agile? Well, I mean, it’s a part of Agile, right? Ken Schwaber and Jeff Sutherland were two people who signed the Agile Manifesto. The Agile Manifesto reads, in its entirety, as follows:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:Individuals and interactions over Processes and tools Working software over Comprehensive documentation Customer collaboration over Contract negotiation Responding to change over Following a plan That is, while there is value in the items on the right, we value the items on the left more.
© 2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice.
Kent Beck James Grenning Robert C. Martin Mike Beedle Jim Highsmith Steve Mellor Arie van Bennekum Andrew Hunt Ken Schwaber Alistair Cockburn Ron Jeffries Jeff Sutherland Ward Cunningham Jon Kern Dave Thomas Martin Fowler Brian Marick
These sound like noble goals. These are all things we want. (And hey, Uncle Bob’s in there! 🙂 So what is Agile? Well, it seems to be a bunch of software development methodologies and practices that people wanted to lump together and call Agile. The best I can get out of all the websites and blogs and wiki pages on Agile, the only thing that seems to tie them together is that their not “classic” waterfall. One of the points that seem to be made about the differences is the Agile moves testing to a different place then classic waterfall. In classic waterfall you don’t test anything until you are all done. Test Driven Development (TDD) moves testing to the very front of development. As a part of iterative development, having continuous cycles means that at each cycle you are testing. But this doesn’t apply when looking at the iterative waterfall. As I discussed above, each task during the implementation of the iterative waterfall is itself an iterative waterfall. This makes it sound a lot like iterative development but the process itself is fundamentally different. You have to ask yourself, do I have the requirements to implement this? Are the designs done? Do I need to modify them? How do I implement this? Now lets test my code (i.e. write a unit test). And now we’re in the maintenance phase of this task. Iterative waterfall is an incredibly recursive process.
So if I utilize the Agile practices without utilizing the Agile methodologies am I doing Agile development? A lot of the Agile practices are really just good development practices that happen to be parallel to the purpose of Agile. Why does that make them Agile practices? So with the 10 or so listed Agile methodologies, which ones produce the best output? The Agile methodologies themselves seem so different. I mean, if I were to spin up a new project would I use Extreme Programming or Scrum? Are there aspects of each of them that can be co-mingled? Why would I choose one over the other? And then there’s method tailoring which seems to be about adapting the methodology and practices to suit your needs. But there is no guidance in terms of what situations work better for what methodologies.
But Agile is so Damn Profitable
There are a lot of books about how each of the Agile methodologies is better than classic waterfall but there doesn’t seem to be anything on how and where one methodology would be better than another. I see a lot of “Buy this Agile book” and “Hire me as your Agile consultant” and “Pay a bunch of money to become a Professional Scrum Master™” (scrum.org and by extension EBMgt are really good at this). Believe it or not I’m actually okay with this. If there is truly value to be gained then it makes sense to pay for it. Agile (writers, teachers, consultants) seems to have truly grasped the concept of capitalism and run with it. But more to my point, I have yet to have someone from the Agile community provode some sort of guide on where and how the Agile methodologies are better or worse. I’ve read a lot of blogs and web sites touting Agile from people much smarter than me.
Wonderful, I’m sold. So should I go with Adaptive Software Development or Agile Modeling or Agile Unified Process or Crystal Methods (Crystal Clear) or Disciplined Agile Delivery or Dynamic Systems Development Method or Extreme Programming or Feature Driven Development or Lean software development or Kanban or Scrum or Scrum-ban.
And what if I’m not sold? The Editor in Chief of drdobbs.com, Andrew Binstock, had a great article titled The Corruption of Agile. It seems to me that one of the key issues with Agile is understanding in what scenarios to apply the right methodologies and practices and then integrate method tailoring to your specific needs. To paraphrase I read the article as, “People have so integrated Agile practices into their culture that they no longer apply method tailoring.” That’s just my interpretation. This all concludes in Andrews response to the responses title, Addressing the Corruption of Agile, which links to responses from Rob Myers of the Agile Institute and Uncle Bob.
So there are a lot of people that love Agile. And a lot of people that hate it. It seems absurd to me that this should be such a polarizing issue. And I sit right in the middle. Is Agile that good or that bad? It troubles me that, other than hating on a classic waterfall (which makes sense to me), the various methodologies that make up Agile don’t defend why and when they are better than the other Agile methodologies. Every method has it’s good points and bad points and shouldn’t be universally applied. Even the iterative waterfall I mentioned above. It fails on really large applications when resources are immediately available. When we’re still defining requirements but we have engineers available to begin development, well, there’s iterative waterfall’s downfall. You end up with idle resources. The easy way around that is to start with a smaller team and do frequent iterations between requirements and design.
Anyways this was just my place to get out some of my thoughts on Agile. I freely admit that I’m ignorant in Agile. I’m just not sure how to move forward so I won’t be. I want that forward movement to be meaningful.
Thanks for reading,
Brian
