Does anybody here have practical experience with SCRUM?
StefanL38
Posts: 2,292
Hi,
found this video about SCRUM some time ago.
http://www.youtube.com/watch?v=XU0llRltyFM
seems to be fascinating. But - is it really practical? anybody here with practical experience with SCRUM?
best regards
Stefan
found this video about SCRUM some time ago.
http://www.youtube.com/watch?v=XU0llRltyFM
seems to be fascinating. But - is it really practical? anybody here with practical experience with SCRUM?
best regards
Stefan
Comments
I've studied it before and have participated in parts of it being applied within Parallax. Complexities aries when people have other demands on them than the project at hand, or if they keep changing the customer stories (specifications). Our Education department is effective at project management, but using different tools than OnTime and the scrum system. It would be difficult to apply this kind of management to something like the Propeller 2, but it could've made our efforts to date more successful.
We use a modified Scrum process due to the team size on our product (2 people plus 1/2 a DBA). I like the way it works for us.
We have a 2 week Sprint, followed by 1 week QA an then a week of production follow-up when we handle any issues from the release and also prepare for the next Sprint by grooming the backlog. This pretty much gives us a one month release cycle for any high priority features. Otehr products in our teams have 4 or 6 month release cycles, so we look pretty darn responsive to users.
Our biggest problem goes back to team size and our functions. We handle requirements gathering (helping write and define user stories), design, coding, testing PLUS production support. Having the production support burden can really mess up your 2 week sprint. Instead of being able to code 100% of the time, there are several times when a week or more of sprint time can be lost due to production problems. This causes for some juggling of items in the sprint, or taking some of the QA week for development or just working a few long days to catch up.
I like the user story concept and having the developer work with the user to write requirements (thsi is part of our modified Scrum process. I also like the quick turnaround in an Agile methodology - you can actually go back to the client or product owner and see if you are on target with providing what they want.
We aren't formal enough that we determine our team "velocity" and use the burndown charts. With only 2 people, you are pretty much in constant contact throughout the day and have a feel for what can get done and where you are in the 2 week sprint.
I'd like to have the opportunity to try it on a project with a larger team. It works well on our small team.
It's especially bad when upper management doesn't fully buy into it, and you end up just wasting a bunch of time/effort doing the SCRUM Smile and then not following it because upper management comes in and changes everything.
Personally, I think these sorts of things are invented by managers for managers, and to justify their existence. Luckily for me, the place I work at now doesn't have managers.
Edit:
At my former employer the team sizes were varied from half dozen to 80+ people.
This guy's video is good. He's been living the process and not selling a product like the one in the first post.
At my current employer we have teams just as large with no managers, and the results are much more success.
Like I said, we only had a team of two. We just both wore a bunch of hats so it felt like a bigger team! Outside of the dev/supt team, there was a product owner and other interested clients. We ran governance to groom the backlog and make sure things were prioritized. I think like with any methodology, if you follow the book too closely or don't adjust for your teams, you can get this or this .
Might be good idea if you have no idea what you are building before you start.
As my old boss used to say. "Why do I have to have all these people on my team when I have to rewrite all the Smile they have written on the weekends"
Yes, I have practical experience with Scrum. We use it extensively where I work. It's a good technique for projects where the requirements are volatile, or are expected to evolve during the project itself (which is true of most projects!)
The essence of Scrum (like many Agile methodologies) is that you sacrifice predictable functionality ("we're gonna work on this till we get it done!") to achieve predictable costs and deadlines ("we're gonna work on this till Tuesday, then deliver whatever we got done"). This is quite a difficult mindset for engineers to adopt, but in reality it is what most customers actually want - even when they claim otherwise.
You might think that since the customer is not sure exactly what they're going to get till the project is delivered, that Agile would lead to higher customer dissatisfaction. However, the opposite tends to be true because the customer is actively involved throughout the process, and gets the chance to "steer" the project at a very granular level, in ways that are impossible with traditional project management techniques.
The sad reality is that software is hard. Nearly all software projects are delivered late, are over budget, and fall short of the promised functionality. At least with Agile you get your project delivered on time and on budget, and if it's not exactly what you first thought you wanted, the reality is that what you first thought you wanted was probably wrong anyway.
The biggest downside of Agile is that the total cost per unit of functionality delivered can be far higher than with more traditional techniques.
Ross.
SCRUM + Lean is a potential great combination and can result in faster time to market as well as a more "solid" product. (Solid = what the customers REALLY needs, not what they thought they needed 5 years ago)
I would say that it takes maybe a year for a new team working like this to become efficient. Until then then they will probably be less efficient than without it.
XFT is not that great for our project though since it means that every person needs to know what 1800 other persons knows. And it means that you will never be an expert on anything and you will have to mentally start from square one many times a year. It may work for projects that are small enough for a single person to comprehend though.
/Johannes
This is all a lot of Taurus Droppings(No points for guessing which game I'm playing on the bus to work every morning).
A project where the requirements are 'volatile' or changing is also known as a 'failure in waiting', or if big enough, 'expensive failure in waiting'
I have seen 'projects' that has been 'delivered on time' and yeah, they usually doesn't work. The ones that do work... Are rarely any use either...
I work in a large government agency, and every time I hear one of those buzzwords in conjunction with one of the software projects going on, I KNOW it will blow up spectacularly. So far I haven't been wrong.
At the moment, we're porting one of Norway's biggest DBs from BULL mainframes and building new apps to support it.
(The old one used apps running on front-end mainframes and the users ran a Terminal emulator with lots of weird stuff patched on to add functionality. 25years of patching isn't pretty... )
Its probably half a year behind schedule by now, and only a few of the apps are even in regular use, yet, but...
THEY WORK!
(Some of those apps aren't even used internally in our organisation; they're web-based 'self-service' systems, and SMS services.)
Why do they work?
Because the group handling the project is run by some of our best server and networking specialists, together with senior users. The consulting companies delivering the programmers aren't allowed to 'run the show'.
The last time this operation was attempted, a large consulting company came in, threw buzzwords around like confetti and generally thought they knew everything..
Made for some awful headlines in national newspapers...
Today we make darn certain the specification are nailed down properly, and that 'nifty ideas' are scheduled for 'afterwards'. If it ain't in the schedule, it won't be implemented now.
And half-finished code is NOT pushed to our users.
This is my observation and not in any way a definition of SCRUM.
We have various opinions or anecdotal examples of how the different methodologies have worked or failed on a variety of projects in a variety of organizations and industries. People are splitting into factions based on their experiences and beliefs.
I bet the correct answer will be pick the tool that is right for the job at hand and if it is wielded with craftsmanship and knowledge, it will probably work. If it is the wrong tool for the job or the application fails, the project will falter due to the failure of the tool, rather than the failure of the choice, applicarion or people involved.
Welcome to "Methodology Wars", sponsored by Human Nature!!!
Also, "less efficient in the first year" may be misleading. Nobody but the team members or maybe the manager (if very competent) would be able to determine a difference on way or the other. That is, during transition, the transition project would likely be worse than the best previous effort, but better than the worst previous effort; so it would likely still fall within the teams previous bounds.
But this is the same for any new tool or methodology, what really matters is whether the implementation (of the tool of methodology) suitable for the situation at hand.
No it isn't. Agile is now used on all types of software projects, including large and complex projects in highy regulated industries. Because it gets results where classic techniques tend to end up late, over budget, incomplete, and of poor quality. If you are not aware of this then it is likely that Agile has just not reached your particular domain yet. Agile is driven primarily by a need to constrain cost and schedule, and so has made largest inroads in those domains that are very sensitive to this.
Classic. So this project is already behind schedule, is probably over budget as well, and has so far only delivered some parts of the project that apparently have little business value. I'll bet your customers hate it, and have already begun thinking about whether they would be better off just minimizing their losses and pulling the plug.
I'd also be fairly certain your engineers haven't yet tackled some of the really curly stuff yet. Of course, you'd probably never know this because they never tell their managers or their customers until its too late. This is why so many software projects get to 80% completion "on time and on budget", and then blow out massively trying to achieve the last 20%. Most never do. And if that last 20% contained too many of the requirements that really delivered business value, the whole project will be considered an utter failure, no matter how much good code was written.
As I said, some people find Agile a difficult concept to grasp.
Engineers tend to be the worst - they always believe they know more than their customers. And worst of all, they can prove it!
Trying to get specifications "nailed down" before development begins is a classic cause of software project failure - it's called "analysis paralysis". Agile simply does away with that by starting work early on anything that can be specified well enough for the customer to accept - with an understanding that this may have to be reworked later, as requirements change (as they always do).
And Agile does not "push" "half finished-code" to customers. There are two problems with this notion. Properly implemented, Agile is a formal methodology - it is not a haphazard technique that releases half finished code. The code is complete and meets its requirements as they are understood and agreed at the time. In fact, Agile code is often better tested than non-Agile code. The other problem is that the customer has already agreed that the functionality they are being delivered is valuable to them. They have been involved all the way along the line to make sure this is true.
Agile is a way of taking into account that there are always differences between what customers ask for, what they want, and what they need. Too often, these three have very little in common.
Ross,
Anyway I learned something from it. But I want to get back on the first question:
(Ask the product manager - no just kidding)
Does anybody hit the following points in summary:
- practical experience working with scrum
- still likes it
- and can tell my something what are typical hurdles at the beginning?
(or do I have to ask the product manager? ;-) )
best regards
Stefan
1) Instead of signing up for and starting work on a billion dollar contract with Agile/Scrum we sign the customer up for a million dollar contract and the software house delivers that.
2) When both the customer and software house see where they are at that time, taking into account changing requirements and experience with what they have so far, they both sign up for the next million dollars of requirements and sprinting.
3) Repeat until the money runs out or the customer is happy with what he has.
This is magical because now a billion dollar project cannot fail. Only a million dollar contract. A thousand times improvement over the traditional methods.
Hi Stefan,
I guess you will have to ask more specific questions if you want more specific answers.
I have managed several mult-million dollard projects that use Scrum. I participate in the daily standups, story development, backlog grooming, etc, etc - but I do not do any coding. But then, neither does the majority of our scrum teams - they tend to have more engineers and testers than actual coders.
I didn't appreciate Agile at first, but was willing to try it, and now I have come to understand the benefits of it.
The hurdles at the beginning are mainly what you have seen in the forum discussion here - i.e. many engineers simply don't believe it can work in their particular niche domain, and therefore don't want to try it at all. Or they deflect by adopting it in name only - i.e. they call what they do "Scrum" when it is in fact just iterative waterfall development, and when it fails they claim to have "proven" that Scrum doesn't work, or was no better than what they already did.
If you have never done Scrum before, you should get yourself an experienced Scrum Master. If you don't have that you will almost immediately fall back into non-Scrum ways, and destroy the effectiveness of the Scrum. You also need a customer who is willing to participate in your project at a much deeper level than usual. If they just want to throw you a set of half-baked specifications and then come back a year later to take delivery, you should not use Scrum (I'm not really sure what you should use in this case - probably best to just let someone else take that job, and fail).
Here is a good summary of the differences between Scrum and other methodologies: http://www.agilistapm.com/differences-between-waterfall-iterative-waterfall-scrum-and-lean-software-development-in-pictures/
Also, people adopting Scrum tend to think you can "mess" with various aspects of it, not realizing it is a fully-formed discipline with specific reasons for doing things the way it does. The two biggest mistakes we made were having the teams too large or too small (about 8-10 is ideal for us - this might vary a bit in other domains) and thinking you can have "distributed" or "virtual" teams. Both of these destroy the effectiveness of Scrum.
Most people simply don't "get" Agile until they try it, and suddenly find their customers are enthusiastic and happy instead of antagonistic and cynical. This is usually what finally changes people's minds about Agile.
Ross.
From your link:
I'm seriously curious how this all works out.
Projects tend to have interdependent features. If one does not work the whole thing is pointless.
Or am I mistaking "implementation details" for "features"?
But then sometimes it can take an awful lot of implementation details, basic structure or framework, before even one, small, useful, customer facing feature is possible.
And what happens when a year down the line a customer feature turns up that requires a totally rework of all that has gone before because the implementation so far does not scale to that or is otherwise logically incompatible.
As a, probably bad, analogy one could end up building a housing estate and it turns out the customer wanted a hotel or cruise liner. All the time those little feature requirements were being satisfied and delivered: Bedrooms, bathrooms. restaurants etc but the desired end result cannot be achieved !
Surely there must be some upfront master plan and a not insignificant effort to ensure it might be possible.
In short, how does SCRUM stop you painting yourself into a corner?
Seems to me that SCRUM projects almost by definition will succeed because they never bite off more than they can chew at any given time, but that still might not get what is required without starting over. The failure becomes the customers fault! All the risk has been moved to the customer, brilliant.
Yes, I think you may be confusing implementation details with outcomes. Engineers love the former, and have little interest in the latter. Customers love the latter, and have little interest in the former.
And who said Agile was an easy option? It isn't - it takes skill and patience to tease a complex project apart in a way that makes sense to your customer - who is of course the final arbiter on this subject. It may also take quite a few sprints before you gain enough momentum to deliver even a single item of functionality that is actually useful to them. Most Agile projects have one or more "sprint zero" cycles - to shake down the team, calibrate their efforts, build up a backlog of implementable stories, and get the appropriate tools and infrastructure set up.
Then you rework it. This is no different to any other project, where code may be reworked several times over the life of the project - except that this way, each time you rework it, you have delivered more value to the customer. No, it's not a bad analogy. But don't forget that with Agile, each iteration is a fully developed, fully tested and deliverable system that achieves some agreed business value for the customer. It may not actually get released - but it often is. If it truly does deliver value, why would the customer not want to release it as soon as possible? Of course, there may be many reasons why they choose not to - but they could.
If the customer really wanted a cruise liner, and you offered them a 2 bedroom bungalow in the first iteration, they would probably say something like "Great accommodation! Now - how many gallons of diesel do I order for a shakedown cruise to the Bahamas and back?" This would be a clue that they may have missed telling you about some basic requirements that are important to their business, and that what you delivered was therefore of little or no value to them. But at least this way, you found this out before you built 10,000 such bungalows!
On the other hand, there may be business value in first building such a bungalow on a barge, with room for a BBQ and a shuffleboard court on the deck. Who's to say a travel holiday company couldn't start out with a fleet of those and work their way up? There usually is. As I said, Agile is not simple, and does not magically eliminate the hard work required to make a project a success. It merely makes it more likely that the project will be a success.
But in fact any "master plan" will most likely itself evolve, maybe just a sprint or two in front of the functional development. Not all stories in the scrum deliver functional outcomes - there are investigative stories and infrastructure stories that may be required preparatory to implementing some elements of functionality in succeeding sprints.
In practice having such a "master plan" is not as important as having a customer who knows what they want to achieve (but is willing to be flexible about the path they take to achieve it) and a team with the technical skill to make it happen. If you don't have those, your "master plan" is just fiction anyway.
You are still thinking of "developer" vs "customer" as an antagonistic relationship. If this is the case, Agile is probably not the right choice.
If instead, the customer is with you on the journey, then you can only paint yourself into a corner if the customer is right there with you, with a paintbrush in their hand.
Then who's fault is it? More importantly, how much easier is it to get yourself out of this situation when the customer understands exactly why their requirements may in fact be more difficult than they realized, or (in some cases) are in fact contradictory and irreconcilable?
Ross.
If you start with Moe, Lary and Curly, you will end up painted into a corner (or similar) regardless of any tool, etc.
A reasonable group of people could learn how to work together in a flexible fashion. These are just frameworks to help you get to that point by following examples that have worked for others, rather than you having to evolve it youself over the course of 25 years.
They may have unfortunate buzz word names, and silver bullet types will always expect silver bullets, but these tools can be effective if used properly.
I think that all the time we spent in meetings would have been more productive if the time was spent actually developing the products.