using agile and scrum the correct way
by Shadowmaster on 16/02/10 at 4:45 pm
Agile and scrum are the new methods every company want to have on one side, but on the other not all of them know how to use it correctly. In this article I’m going to give my 2 cents regarding what can went wrong and how it should be taken into consideration if you planning to take your company the agile / scrum way.
Agile and scrum are the new buzz words each company wants to associate itself with ‚as for some reason they companies tend to take what they see and might suit them but they forget one important issue – to modify themselves to the new approach.
Agile means you have to work 40 hours per week as working more hours will influence you and won’t contribute as 8 hours is the proper time for a person to work per day.
Companies, especially start-ups don’t know the concept of 8 hours per day, so again they will want to say they are working with scrum and agile methodologies but without adjusting themselves as they should.
Another thing you should know about agile and scrum, there should be meetings before starting the actual task that the company divides all the work into small units and by that the company knows how much unit they need for each module or for each milestone.
This level allows the companies to modify things fast as each module is assemble with other models and each small change shouldn’t affect the whole concept too much.
Problem with start up is that they tend to make changes on spot, and not really have the time to hold a meeting to divide the components and new changes that is needed to those units. So starting in agile method is nice but keeps working on it, is something that can’t be done so much, another problem with start ups is that changes are made without any specification so you can’t really track changes if they occurs too often.
Brief meetings in scrum means to show progress, as I wrote in previous article what I think about company meetings I still think the same in the case of scrum meetings, those meetings are just to be there and show something is done, but besides that … it’s just waste of time.
The scrum method says a short 15 minutes meeting will be held, all the participate will stand and everyone will be given the chance to say what he has done yesterday , what he is doing today and how he can help others (in case someone else is doing something other has some experience in).
Start ups changes ideas and concept faster than speed of light, so morning scrum meeting won’t affect what you talk about as things changes, and as those meetings suppose to be fast and short it all good when there are 5–7 people attending it, but when you have 10+ people it’s much more harder.
At the end we end up having 20–25 minute meeting that won’t contribute to anything and most chances it won’t reflect what you actually planed to do at that day.
I’m not against the idea of scrum and agile as it works, but in order to make it works the company has to change the way it looks at things and change it ways, as it has to be more organized, and more oriented to changes with the ability to have the time to think about them deeply and dividing it into units.
Most important thing companies has to stop looking at their employees as slaves and let them work 8 hours a day, than and only than agile and scrum can co-exists and won’t consider as waste of time, if not, your company will invest some money and time to find out after few months that buzz word is cool and nice, but it won’t bring them to where it want to be.
Popularity: 36% [?]
Related Posts
Hackadelic
Mar 14th, 2010
Nice post, I’ve been practicing agile methods for years, and there is much truth in what you say.
A few thoughts:
I can confirm that often “agility” is taken absolutely wrong in the reality of “daily business” — by the management.
To effectively cope with changes flying in “faster than the speed of light” and with the reality that they are submitted ad-hoc, w/o formal specification, is one of the goals of agility (“embrace change”). In fact, the most prominent agile methods like XP or Scrum involve explicit practices to prevent from the chaos that would arise if all “external” changes would strike in unfiltered into the development process.
Management’s task is be to balance protecting development from the chaos of ever changing requirements and allowing for changes in a controlled, organized manner.
Scrum for example allows for changes only at a start of a sprint, i.e. once every month. Anything else must be “queued” in the product backlog. This is essential. Claiming someone is doing Scrum w/o obeying this requirement is self-deception.
In reality (at least as I often observed it), management just loves to walk into the room and drop their newest ideas onto the team, or make last minute changes themselves. I guess it’s because it is much easier, and much more comfortable, to just off-load your brain onto somebody else than to organize and prioritize your thoughts first. (That’s why it’s so great to have an assistant.)
Be that as it may, while external circumstances provide enough opportunity for chaos entering the development, it is often the own management that multiplies the chaos (sometimes because they don’t want to lose face before a customer, but often enough out of an own premature impulse).
On the other hand, while it’s fun to bash about management, there is clearly a certain share of responsibility (or lack of it) on the team to consequently demand a certain level of process stability and working conditions. They treat you like slaves? Don’t let them. Stand together, and say “No” to grievance. They threat to fire you? They can’t fire you all. They threat to fire one of you to make an example? Say that all of you will go if they do. What’s the worst that can happen? If things are so bad, every other day in that job is one more day as a slave… People have fought wars and died to end slavery. Switching employers should be much easier.