LinkedIn | FaceBook | Twitter
I want to make a disclaimer before I dive into this topic – At Microsoft we use all kinds of development methodologies, and I’ve worked in lots of other shops using lots of methodologies. This is one of those “religious” topics like which programming language or database is best, and is bound to generate some heat. But this isn’t pointed towards one particular event or company.
But I really don’t like Agile. In particular, I really don’t like Scrum. Let me explain. Agile is a methodology for developing software that emphasizes adapting to change more so than the traditional “waterfall” method of developing software. Within Agile is a process called a “scrum” meeting. The pitch goes that in this quick, stand-up meeting the people involved in the development project (which should include the DBA, but very often doesn’t) go around the room stating what they are working on, when that will be finished and what is keeping them from getting finished (“blockers”, these are called). Sounds all very non-threatening – we’re just “enabling” the developers to work more efficiently. And that’s what we all want, isn’t it?
Except it doesn’t work. In my experience (and yours might be VERY different) this just turns into a micro-management environment, where devs have to defend their daily work. Of all the work environments I hate the most, micro-management environments are THE worst. I don’t like workign in them, and I don’t like creating them.
The other issue I have with Scrum is that it makes your whole team task-focused. Everyone wants to make sure that they are not the “long pole” in the meeting (meaning that they aren’t the one that gets all the attention) so they only focus on safe, quick tasks. And although you have all of the boxes checked, the project does not go well at all – even when it does finish.
Before you comment (and please do comment) I fully realize that Agile <> Scrum. But in my experience, it sometimes turns into that.
It does feel like micromanagement. Part of the reason is because certain types of software development are organic and experimental in nature. You know where you're headed, but not always exactly how you'll get there. It's hard enough to give an overall estimate for the deliverable, let alone a daily estimate for every single subtask of the deliverable. I suppose part of the purpose of this methodology is to improve the skill of giving estimates. But in my experience it's like daily punishment for lack of clairvoyance.
In my very very limited experience with Agile, the BAs want to run the show. Being they work from a UI perspective, it makes sense. Having programmers work that way doesn't. Indeed, i think Agile is a sign of a bad coder covering his faults.
I think Agile could be done for the Use Case documents. And Use Cases should be test cases after the code is done. But code itself is better when its waterfall. Either the basic requirements are known, or they are not. Asking me to get from point A to either Point B, Point C, or Point D (which might be decided next week before the next three changes) is going to produce bad code and a horrendous data model.
Agile could even be used with a mock-up to design the requirements via the UI. When that is completed, the coders can come in and make sense of what they really want.
pelly: nice comment.
(typo: 3rd paragraph, last sentence "workign")
In my experience the daily scrum has gone very different, and much more positive.
To me, as a scrum master, it is very important that the team is not talking to me directly and giving me a status update. The whole purpose of the daily scrum (in my opinion) is so that team is connected and aware of what's going on around them. It is important that they are talking to each other, and helping each other get around roadblocks. Honestly, the most important item I listen to is the impediments/blockers. If the team is facing a blocking issue that they cannot resolve, then it is my job to do what I can to help them resolve it by any means possible.
The daily scrum is not meant to be a traditional status meeting, and the scrum master or manager should not be using the meeting for micromanaging the team.