I’ve just ended a project where I was working in an Agile/Scrum based environment, with sprints, stories, and deadlines. I kinda liked it, because you collaborate closely with your colleagues, and you pick your own tasks. Things can move potentially very fast, but there are some very glaring downsides. I’ll list them below:
The burndown.
The holy and sacred burndown. People care way too much about getting a Sprint completely burned down. It sometimes makes Agile feel more like a panic room, than a flexible way of working. Especially when you have to wait for third parties. Other squads can really shit in your cereal by letting you wait days for a request to be fulfilled and things get blocked.
Yes, you should make your best effort to finish your burndown, but it really isn’t the end of the world if you don’t make it.
Refinements and retrospectives
Basically meetings without an agenda.
I thought I would have fewer meetings with an Agile workflow, but you get interrupted by refinements and retrospectives. It’s understandable that people want as many eyeballs as possible to refine something, but for crying out loud, let people work uninterrupted!
Many a time I sat a refinement, wondering what the hell I was doing there except for filling up a chair. Where I worked, the entire squad would be expected to sit in, while just a couple of people that are working in the problem domain would have sufficed.
And then there are the Agile coaches. They sit in on some of the standups, refinements and the retrospectives, but I wonder if that’s absolutely useful. Yes, they give some input on agile workflow and sometimes play moderator. But they don’t really contribute to the product. I don’t have anything against Agile coaches personally, but I would consider them overhead, akin to project managers.
Standups
I specifically left out the standup in the former part, because, well, that’s the only ‘meeting’ that I personally need. Basically just outline the stories you are working on, what is blocking you and what you will pick up next. That’s it. Also, frequently standups take too long because some people treat it like a full-blown goddamn meeting. Yeah, I get standing up is healthy, but the whole point of standing up is to add a physical constraint to ensure meetings don’t take too long.
Next Agile project I work at I will just introduce a damn egg timer. You get three minutes. That’s it.
Access, or the lack thereof.
Granted, this is not really related to Agile workflow, but it is a source of impediments. Yes, I get security is important. Yes, there must be due diligence and least access, but ideally, it shouldn’t get in the way of your work and be as transparent as possible.
The last project I worked at, they had a monstrosity of an Excel spreadsheet to outline all the rights and access a user or application has. It was a nightmare. Typical old-world holdover. Such information you should pull from the systems or from an automatically updated single point of truth (SPOT) that reflects reality in real time. It saves a lot of time and hassle. You can just look up what someone/something can do and limit/grant accordingly.
The other way around is also possible (and I’ve been in such an environment). Just give everyone full access, even on production. Let people own their mistakes and security incidents (you break it, you figure out how to fix it and who can help you, no blame shifting), implement strict code review (e.g. Gerrit), and pentest the crap out of everything. Funnily enough, it worked fine. People were careful, but mistakes weren’t punished. The environment was fluid enough to just redeploy a known working state and to sequester broken things for post mortem.
Conclusion
Agile is an interesting way of working, but it becomes awful when there are too many rigid processes attached (think of ITSM/ITIL or Prince2) and if people are too set in their ways. The whole point of Agile is to try lots of new things in rapid succession and to fail/learn a lot so you have a fast turnaround. You don’t want many extra things attached. Sure, include parts of ITIL that make sense (Incident/Problem tickets, continuous improvement, the Deming cycle), but don’t try to bolt on Agile onto something rigid. It won’t work well.
The whole point of Agile is to try lots of new things in rapid succession and to fail/learn a lot so you have a fast turnaround. You don’t want many extra things attached. Sure, include parts of ITIL that make sense (Incident/Problem tickets, continuous improvement, the Deming cycle), but don’t introduce Agile into your company as an afterthought. It won’t work well.
If you want to do Agile well, reorganize everything to facilitate it, don’t try to fit Agile in afterward. It’s like trying forcing a square peg into a round hole. It can be done through force, but it won’t be pretty, or useful.
