Ah, but what’s wanted is a tower of brick and mortar. But users said, we don’t know what that’s going to look like and we don’t want to commit to bricks and mortar until we have some sense of what it will be like. Can’t we just build it out of something more palatable and less rigid and then solidify the thing when it’s built and we’re living in it? And IT said, sure, why not?.. It’s your house. How much can you afford for time and material?
A few years ago I was at That Place that implemented every management (either for Technology or Operations or whatever) fad they could try. Seemed every few months our CEO would read a new book and that became the new thing we were going to do - because very few of them really worked.
Agile is like Six Sigma is like The Toyota Way is like Lean (etc, etc). These all have some “cultish” feeling about them (Six Sigma the most for me), people who go around and evangelize how awesome X is and how it’ll be the perfect solution for your company! But know what? It may not be.
Are you at like an ad agency with lots of small projects that can be measured in days to a few weeks of development time? Agile really isn’t going to work for that - there’s generally too much overhead for the rapid development cycle (but maybe it’ll work in some cases).
Are you at - like noted above (it was Pharma for me) - a place that is very highly regulated by the government? Agile may work, but it’s going to be really tough.
Are you in a place that develops a piece of software that you’re planning on maintaining for years and upgrading regularly? Agile may work well! But chances are it is a big philosophy and process change all the way from product management and gathering requirements through testing and release.
Bottom line - it can work, but it has to be done right.
The rah-rah aspects of switching to Agile are a turn-off for the typical coder. It has that whiff of buzz-word management-speak bullshit. But it does serve a purpose: if you don’t fundamentally get your mind around the fact that things are changing, it’s very easy to fall into bad “scrummerfall” practices where you pretend you’re being agile but are still waterfall (two-week iterations of waterfall methodology is very common).
Done right, you can motivate people to change their mindset and do things differently without coming across like a clueless cheerleader. Done wrong, and it’s every bad stereotype of managers and consultants.
My workplace switched to Agile last year. Management is extremely rah-rah about it. Why? The reason is obvious - it’s a boon to them, and a burden on the worker bees.
No one dares speak out against it when management is so high on it, it would be like criticizing the teacher’s pet. So we who care about keeping our jobs buy in to the whole thing, and life goes on.
I’ve noticed it as well. I chalk it up to how the process du jour is implemented.
A lot of software engineering and programming (and, I’m sure, other professions) is rather cultish. Test-Driven Development is another one. I used to hate it because it wasn’t applicable to a lot of my problems. I still don’t really use it, but after hearing the people who actually invented it talk about it rather than their internet cheerleaders I gave it a lot more credit. Why? Because the creators think that, while it’s a good production cycle, it absolutely sucks when you try to club every problem over the head with it and give no wiggle room to the flow.
But this goes on a lot. Programming paradigms is another one. People will talk your ear off about how all your problems will be solved forever with Haskell. And, of course, the infamous arguments about the best place to put your fucking curly braces in C.
In game development, I’ve seen it with people extolling the virtues of entity component systems or functional reactive programming as well. I don’t deny that these techniques are great, and are techniques that I’d love to try out (I’ve tried ECS, not so much FRP). They have some benefits. But any design issue in a real program is often analyzed by the big proponents of the paradigm as not adhering to it strongly enough.
… or sprang from our fathers’ foreheads, as the case may be.
I’ve been on a number of nominally agile projects that never brought in a coach. These varied from being actually agile, and working quite well, to being really just s**t storms. I’d actually like the idea of having a coach, but that’s just never been an option.
Some PMs I’ve worked with have called their process agile, but said there wasn’t time to write unit tests. Ironically, they forced us to sit in daily hour-long meetings, and sprints were changeable in time and scope, but mostly scope. In other words, agile for them meant everything is ad hoc, we’ll plan everything at the last minute, and until then code to rumor.
I think that Agile gets more hype than it really deserves. The true believers seem to think that Agile is the One Software Development methodology, and that it applies to any and all software. It’s never a good sign that if you bring up an example of a failed Agile implementation, that the answer is inevitably that the project didn’t follow a true Agile methodology. It’s even more worrisome that when they elaborate, the cause is either that the project didn’t apply Agile methods strictly enough, or that the Agile implementation wasn’t flexible enough.
I can certainly see that it has great advantages for developing certain kinds of software – and probably the most common kind of software written today. However, I’m of the opinion that there’s a certain set of assumptions about software embedded in the methodology:
-
Testing the software is so cheap the cost is negligible. The extreme version of this is all bugs can be caught through unit tests (the people who espouse this version clearly only deal with single threaded code). When you start having to do significant amounts of system-level testing like soak testing, performance testing and manual testing, spinning more frequently means that you are paying the costs for this testing more frequently, and that can undermine your efficiency gains.
-
You can force your customer(s) to upgrade frequently and give feedback. This is a big one. My employer sells hardware and software to large businesses. They have absolutely no interest in spending their own resources to make my development more efficient. A coworker was once advocating for Agile and said “I can deliver a new version of the frobinator every two weeks.” That’s all well and good, but meanwhile our employer would be absolutely thrilled if our customers upgraded their software one a year. Not because they would have to pay us for the upgrade (they don’t), but because we’ve been steadily increasing our quality and our own costs for customer support would be much lower if we could get customers off of our old software.
-
Spinning is free. Ok, for software that has been true ever since we stopped having to meter CPU time. However, my VP tells me that you can absolutely blow an Agile advocate’s mind by attempting to explain to them that doing a new hardware spin can cost six figures and requires 6-8 weeks of lead time. Apparently they will still insist that hardware projects should be Agile. He has actually had this happen to him at conferences.
Now, it’s not all bad. You can credit the widespread use of unit testing today to the Agile movement, and unit testing is an absolutely fabulous tool that has made a tremendous difference in software quality. When the conditions are met (and like I said, they very frequently are), the methodology makes sense. It’s just not universally optimal, but I feel like many of its advocates believe that it is.
Listen to the inventors and they say that is the point. Agile mindset is an attitude, not really a method. The idea is everyone gets into a group hug-I mean meeting- once a week with a fixed agenda and rearranges the schedule. The customer, who should be part of the meeting, sets the due date and the programmers decide how fast the pieces are getting done and make sure they all come together in time. But it is an attitude of constant adjustment and revision that makes this work.
This, and applied with extra energy, zeal and zing to any tool (system, standard, regulation, methodology…) that the person applying doesn’t understand.
Aside: I’m feeling seriously tempted to put rainbow colors on “zing”.
Because All True Scotsmen use Agile, of course.
It’s how the Turbo-Encabulator got built.
Wait–it has a manifesto? Knowing nothing about Agile I’m comfortable assuming it’s cultish.
I’ve heard lots of horror stories about Agile - especially the aforementioned 2-week waterfall sprints - but I have to say, it’s worked well for us. It’s not perfect, but it’s a hell of a lot better than waterfall or any other methodology I’ve tried.
The bits I like:
-
The team. Our team, at least, has really come together. Even working remotely, I feel like I know all these people and can count on any one of them. (I also think this is a bit why Agile can be seen as cultish. We definitely have our little in-jokes and such.)
-
The clarity of the work. We all see what’s coming for the next sprint during sprint planning, we all have to give each item a size estimate. That leads to every single one of us having to know at least enough about <story X> to be able to confidently rank it on a relative scale. When it comes time to do the work, we know what to do. Mostly.
-
The chance to show off what we’ve done every two weeks. Our company demos to top management; others might demo to clients. It’s cool to see what our team has done as well as what all the others are doing (everyone in R&D can watch the demos via live video feed if we want).
-
How fast things get done. It’s motivating to see the stories move through their phases on the board.
-
The team as a whole decides how much to take on and in what order. We can push back if management wants us to do more than we think we can reasonably take on. Our schedule is ours to define as long as we’re moving forward and making reasonable progress.
What I don’t like:
-
It does get intense at times. There’s no hiding; if you’re struggling with something, the team knows and talks about it. Depending on your personality and ego, this can be difficult.
-
I miss the days of grabbing a big project and just running with it for a while. Our stories tend to be 3-4 days at the longest if we estimated them right, and many are much smaller. I sometimes have trouble getting into a rhythm.
-
If you don’t like a particular coworker, it’s very difficult to avoid him/her. Daily standup meetings and all.
-
The aforementioned tendency to be cultish.
Definitions, so that the above stuff makes sense:
“Team” - a group of people from various disciplines who work together to get the work done. I’m in software development; my team consists of software developers, quality-assurance folks, product managers or “owners”, and a team lead.
“Story” - what we used to call “features.” Basically a unit of work, small enough that it at most takes a few days to complete.
“Sprint” - a defined time period during which the team works together to complete a group of stories.
“Demo” - at the end of every sprint, you demo what you’ve done. Things don’t have to be 100% complete or anything; the idea is to give people outside the Agile team an idea of what’s been accomplished.
Some projects are waterfall. You can’t build a bridge and say “what should we do in the next Sprint? Lets add some steel beams!” You need a really good idea of what the bridge will look like the day you bring in the earth movers. The supplies and people need to be scheduled months in advance. You don’t get to decide “two lanes really isn’t working, lets add another lane” in the middle of the project. You can’t move “concrete supplier has gone bankrupt” to the backlog - you have to deal with it when it becomes an issue.
I do infrastructure project management, and its always been sort of Agileish in nature. Infrastructure teams often use operations people instead of dedicated project resources - so “what are you going to get done in the next few weeks” and “what do we need to respond to in the environment and change quickly” is how it works.
(Spinning servers should be Agile - you should have a dev environment and chef recipes to push buttons and get it going - and the dev environment needs the capacity to do so. Yes, the few hundred thousand needs to be spent up front to be able to say “spin me up 20 RHEL servers” - but once the infrastructure is there, that’s 15 minutes - half a day if you need to rewrite the recipe for a speciality configuration).
My husband has been in various IT development management and architecture roles for ecommerce - and was an early Agile adopter. And for that, its ideal. You can add a lane pretty easily. You can change the look and feel as you go. There is a need to be responsive to competitive changes quickly. You want many small releases and not big bang “open the bridge” versioning once you have the initial site up and going.
I think you do want an Agile consultant - or perhaps to seed the organization on a contract basis with people who have done Agile. Or you get bits a pieces.
Eeewww, lilacs stink!
[sub]What, was there another point hidden somewhere in that story?[/sub]
Exactly. Most of the work I do (enterprise software) falls in this category.
I’ve always just taken a common sense approach, some things you can predict, so do it and map it out, some things you know from experience you can’t predict, so get a base foundation built that provides value and learn/change after that.
My most recent experience like that took 6 months of design coordinated between many departments and multiple systems. Multiple short iterations would have caused the project to take 10 times as long as you completely scrap and rebuilt as you learn those important dependencies between all of the groups and systems.
Man, that seems to me to be the thing that Agile does better than waterfall. Agile doesn’t mean no design or that you don’t map out the predictable bits. It does provide a mechanism that you identify those and can get people working on the meat of those while the less-predictable stuff is being hashed out.
There is a way to deal with that and adapt it into Agile so over a period of time you move from being Waterfall to being Agile. What you are talking about is technical debt. And you either pay it in EVERY RELEASE or you get rid of those goddamn dependencies and hooks, which are often remnants of bad systems design.
But making that move is HARD and PAINFUL and its much easier to deal with the technical debt with every release because you understand it than to pay it off.
Really big enterprise software is done using Agile. That isn’t a good example of a project that needs to be waterfall. Its a good example of a project that is waterfall because people don’t want to change and don’t understand any other way to deal with their dependencies.
The unpredictable bits we leave as future work once the system is up and the users are using it, the predictable bits are mapped out in detail so we end up with a good design.
For example, a recent one was the automation of an order fulfillment center including these pieces that needed to be tied together so they all work:
1 - Conveyor hardware systems design and complete processing flow (must be complete so you can order the proper hardware so they can start building it to order)
2 - PLC programming to support the complete flow
3 - Conveyor controls software modifications
4 - Voice control system interfaces
5 - Host system interfaces
6 - Host system changes to support the complete flow
All of these pieces needed an overall coherent design and are talking to each to provide any value. Performing this overall design iteratively by different groups and frequently reworking would not have improved this project (not that it needed improving, it all worked very well and still does).
See, I do enterprise software implementations (config, master data, bespoke code…) and my own experience is that while you definitely have to have a road map before you begin, those organizations which refuse to change the Master Plan when defects arise or new information is found are screwed; those where different project stages do not build on previous ones are as screwed. As in so many things, the optimum is actually in the middle - which is actually what you’re saying. In the end it’s not about what you label the methodology, it’s about being able to find that sweet area.