Has anybody had a bad or very bad experience or stories with Scrum or Sprinting, that you can share with a n00b so that he doesn't make the same mistake?
If you had a problem, what were your lessons learned? What would you do differently or have done differently, to avoid the problem again?
Make sure that your sprints are of an adequate duration for your project - too short (2 weeks) can be just as bad as too long.
Its very easy to go too deep into a problem on the daily sprint meeting. You have to have a disciplined Scrum master that catch the problems, set up times to go through them in later meetings, and then stop the discussion about the problem.
If the daily sprint meetings become a loong meeting where you try to solve problems, then you waste time for all the team.
It was only bad because they called it Scrum. We did not have chairs in our meeting room to encourage the meeting to only last 5 minutes each day, except that the management thought it was progressive to also have the developers work in the same conference room all day - without chairs.
Lesson - don't put developers at a conference table to work and then deny them the ability to sit.
the principles are what is important, not the specific practices, terminology, and trappings. I have only seen agile methods fail once, and they failed precisely because the team did not understand the principles and essentially just gave up and reverted to cowboy tactics while still pretending to be following an agile method
the lesson here is: know the principles, not just the buzzwords
Make sure that daily stand-up meetings have a small number of attendees.
Remember you can split into multiple teams for each 'task type', and one person can be involved in a number of these groups if need be.
If they go on for longer than 15 minutes you have a problem.
Another big problem is to educate the customers about SCRUM and get them more involved. They use to think its perfect when they hear that it embraces changes and focus on business values (project owner get to prioritize) but then it's very hard to get the customer to keep be involved and really DO the prioritizing of all product backlog items.
Make sure that the decision makers are always there. By it's nature, there is no concept of spec-handover in Agile, but decisions still have to be made. So waiting on someone to come back with an answer can result in unneccessary hold ups.
Any time I've participated in a pre-packaged process with a label, like Scrum, Spiral, etc., things have gone way worse than when I've participated in an unnamed process that consisted of steps with rationale behind them.
When you try to implement a prefab process like Scrum, several things can go wrong:
1) You buy into the process, but you don't have time to write a thesis on it, so you follow the steps just because the process says to without fully understanding why. This is actually the path the people who push Scrum want you to take, which is why you are told to do artificial things such as not sit down in meetings rather than being told that it's important to keep the meeting short and trusting you to be able to do that. It's just like teaching 7th graders the FOIL method for distributing ordered pairs instead of making them actually understand how distribution works.
2) You buy into parts of the process, but not the whole thing. But, because you have so much confidence in Scrum (or whatever) working, you don't put as much thought into each step as you would have if you were designing your own process. It fails because you are implementing just parts of someone else's good idea without understanding the implications of leaving out the parts you decided to leave out.
3) You decide to invest enough time in understanding the process that you literally could write a thesis on it. In addition to consuming a bunch of your own time, you find yourself spending a lot of other people's time discussing the meaning behind each step. That isn't so bad. But, it can devolve into a team-wide argument over what Scrum (or whatever) really is and what it isn't, and you spend more time arguing over what fits under the label you have chosen to use and less time creating good process and documenting rationale for its existence. If this sounds unlikely, I'm only writing this because I've actually been on a team where this has happened.
My advice is to focus on doing things that make sense for you to do. Then, write down why they make sense, and do them in the future because you know they make sense. If you are going to follow a pre-fab process, I suggest you follow "1)" above, in which you may have noticed nothing bad really happened - I just find it unfulfilling to not know why I am doing something.
It the important factor here is the people. Mostly, the desire and effort of the people to make the process work.
To quote Ken Schwaber:
If you have a team of outstanding engineers that are using excellent engineering tools, have engineering practices down pat, understand the business domain and aren’t interrupted to have all the resources they need, then you can use Scrum. While it’s true that people like that can build an increment of software each iteration. That’s good.
However, Scrum works with idiots. You can take a group of idiots, that maybe didn’t even go to school, don’t understand computer science, don’t understand software engineering techniques, hate each other, don’t understand the business domains, have lousy engineering tools and uniformly, they will produce “crap” every increment. This is good!
I'm by no means saying your team are idiots. It is just that everybody has to be conscious of what takes to make the process work and make the effort.
There is no magic here.
Scrum does not create better products.
People do.
I've been reading up on Scrum, and the interesting thing to me is that there are a lot of pre-requisites for Scrum to work. The only thing is that if these pre-requisites are met, then that will give you success. Scrum might make it better, but it is not a panacea.
Think about the pre-requisites:
I don't know about u guys, but this has happened nowhere that I have worked.
I have seen projects that have tried scrum and the meetings would go on for too long. They would last sometimes between 30-60+ minutes. The moderator didn't wrangle people in when they started going on tangents or rants. I would say that the moderator must do this for scrums to work properly.
SCRUM: Big Brother is watching you.
Scrum - is the dodgiest invention of managers I've ever seen. One may hesitate if scrum is good or bad for the company owners, but it is definitely BAD for programmers!
This technique came to make you slaves!
40% of you working time you spend on planning, estimating and telling others how you are going to implement a function that is 10 line long.
In SCRUM you are always watched. Every morning a standup meeting - you tell everybody what you've done yesterday and what you are going to do today. Every evening you fill a report how many hours you spent for this thing and how many for that.
You cannot design or develop independently more than three lines of code.
You are a little screw in the big SCRUM machine that would finally grind your personality.
Programmers!!! You are creative people! You are individuals, you are not a SCRUM.
Scrum is for rugby, not for intelligent people.
In SCRUM nobody trusts you. You are always checked and double-checked.
Yes, sometimes a programmer needs to spend three hours browsing in the internet and during this his unconscious will find a solution for the problem he works on.
One who does not understand this - is a primitive manager that would never make a successful company.
Company employing slaves would never success. Programmers should have FREEDOM.
I advice to anyone of the programmers: when you came to an interview ask if the company does SCRUM and if it does - just go away and never come back.
And the worst thing: you worked two years in SCRUM – you will not be able to find a normal job after this. Killing creativity and making you slave is easy, but reverting this process can be really hard.
I think Nik should read this article (replace baseball with scrum):
http://xprogramming.com/xpmag/jatBaseball
I have been on projects with and without scrum, and I definitely prefer scrum. It empowers the team rather than enslaving it. Like anything, it can be screwed up if used incorrectly. In my experiences, it is sometimes implemented as waterfall with the name of scrum.
My advice would be to pick a very solid team of 5-9 team members. Scrum will reveal problems, but it doesn't fix them for you. You need good team members to do that. I would also recommend using a physical task board to track progress.
I've heard scrum described as "organized failure". That would match my experiences with it.
Management treated it like a substitution for actual project management. Just because all the cards are up on the board, doesn't mean that anyone is making project planning decisions to account for changing situations.
We had an over-optimistic set of requirement and too short of a deadline (one year, should have been more like 3). The project needed an overall scaling back, but scrum made matters worse because it encouraged a focus only on the short term.
A bonus problem was that with each person attached to 2 or 3 feature teams, that meant 2 or 3 10-minute meetings spaced out over every morning. The meetings stayed to their scheduled duration, but that just killed my (and many other's) productivity. Being interrupted from real work every 30-45 minutes just destroyed the entire morning.
I'm not trying to say that scrum can never work. But everyone has to be able to perceive the value drawn from each implemented part of scrum. It is not an automatic recipe for successful software development that can be followed blindly. If you finish your morning scrum meeting(s) and it felt like a waste of your time, then something needs to change!