The more i think the Scrum Methodology, the less i think of it.
That's not to say that there aren't certain things that are useful, but let's get rid of some of the crap.
1. Nobody uses the "waterfall" method.
Alright, that's not literally true. In the past 20+ years of programming, i've worked on two programs that used it. They were both large, monolithic efforts that resulted in systems that needed to be both highly reliable and highly secure. They were designed according to the venerable MILSPEC-25, which detailed literally every function, action, input and output of the system. The requirements were huge (as in "stored in a warehouse" kinda huge), the QA steps took weeks and the overall development cycle took years.
No other business i've worked at does that.
Every other business works reactively. They have a general idea of what needs to be done, work towards that goal and alter as the competition and technology advance.
Sounds oddly familiar, don't it? That's because
2. Scrum is nothing more than lots of little "waterfalls".
Yep, think about it. Even large User Stories tasks are nothing more than generally specified requirements. The only difference is that the requirements aren't thought out before-hand.
You know, that always makes me laugh out loud. Other than those MILSPEC-25 projects, guess what document was always the last one delivered, if at all? Yep, the requirements.
What was important in all of these were the marching orders. Actually, that's a pretty darn accurate description of it. If you've got an army that you want to get from A to B, you'd better know from the start that you want to get to B. How you get there, how you get around obstacles you encounter, and how you deal with issues are all things you generally consider on the march. Bridge missing? Go elsewhere. Find some abandoned but working trucks? Whoo-hoo, everyone gets a ride! The important thing is that your team stays focused on reaching the goal.
The same is true with any project. If you don't have a clear understanding of what the hell you want to do, it doesn't matter what new design methodology you use, you're not going to reach it.
So, what does this say about this latest technique?
3. Scrum isn't new or innovative, it's the same thing you've been doing. Seriously, this is generally the way that engineers have been writing code for the past 20 years. Some might even say that is the strength of scrum. It should be incredibly familiar to anyone who's been in the industry for more than a year or two.
Anyone who actually pays attention during those staff meetings should recognize the pattern. They should also see the biggest problem.
4. Scrum doesn't address The Enemy.
What's the enemy? Well, there are two of them. The first is the Calendar. Commercial projects have calendars. They have hard dates. That's because commercial projects have external commitments they have to achieve. It may be that you have to meet some big expo. It may be that some partner gave you $30 Million dollars and is expecting to be live in the first quarter. It may be that some other team needs to have your product working so they can use it.
These are real, hard dates that are generally outside of your control. "So we slip features" i hear the scrum folks say. Well, no, see, that's the problem. While it's certainly possible to do that, quite often the number of real non-necessary features are pretty darn few and nearly impossible to categorize. Plus, since you're now "agile" the product folks expect you to stay up-to-date with competitors, meaning that you pretty much have to work on new, highly required features.
Yep, features. That'd be feature creep to those familiar with pre-scrum life, the other half of The Enemy. These features are absolutely required because your product has to be the leading edge, best of breed system otherwise it'll languish. Oh yeah, and we need it live in two months because otherwise we'll lose 140K a day in revenues. Kthxbi!
What's even worse is the fact that this decision making process is hard to nail down. Why?
5. Designing by committee vs. dictatorships
Yeah, see, it's easy to toss tasks into a pool, particularly when they're not being overseen. Yes, i know, there's supposed to be a scrum leader (heh, obviously these folks don't play rugby) who's job it is to oversee that, but unless that person is the project manager, they're outnumbered and outgunned.
This, again draws back to my point that a successful project needs to be run like a kingdom. One person needs to be in clear control, have the focus and drive the idea. That person with that control is what makes the product a success, the method they use is irrelevant.
This kinda touches on another aspect that scrum glosses over.
5. No ownership.
This is one thing that always kind of bugged me. i'm weird, i admit that. i do less than glamorous tasks because, frankly, nobody else will. If i see that someone needs to write a script that pushes data into a bucket, i'll step up and do it. If there's a pile of digital hay that has a needle stuck in it, i'm the one going through that. i'm the guy that deals with getting the customer content because it's almost always crap.
i'm usually not the guy that writes the amazing front end that gets the oohs and aahs, although i can and have done that. Those ooh-ahh products are a heck of a lot of fun to work on and they get you lots of attention.
A lot more attention than reworking a filter for the fortieth time because someone screwed up the spec' again.
Scrum doesn't encourage ownership. It wants to give people the freedom to pick whatever they'd like to work on. That means that whoever the sorry sod is that inherits that particular turdblossom later doesn't really get a lot of help, and woe be it if they underestimate the amount of time required to make the change.
This is not to say that Scrum isn't without it's benefits, but i'll counter that the benefits are not for the engineers.
What scrum does right (provided it works that way) is to force the decision makers to see the impact of their changes. You want to do X? It costs this much. Granted, that communication already happens. The problem is that the decision maker does what they will do in the future. They'll blow it off or pressure engineering to meet the hard date regardless.
A good engineer knows this, and is more proactive about things. They talk with their customers (that would be the product managers) very early and often to see what they're thinking. Nothing formal, just a quick weekly email or a lunch or something so that you know what they're thinking. Simple communications do wonders.
The other thing that Scrum kinda gets right is that it mandates that sort of communication… sort of. Poorly, by my standards. See, scrum requires that you give a daily status report to your fellow engineers who you are competing with. Yes, competing. If you appear to be doing less for whatever reason, your value is reduced. It may be that the reason you're doing less is because of operational issues, or things outside of your control. Doesn't matter. When Bob reels off the fact that he completed 20 tasks and you're still working on one who gets the gold star?
Now, granted Bob's 20 tasks involved changing the color of a bunch of buttons where you need to create a wireless interprocess communications layer between a Mac and a VAX 720, but that's beside the point. He's still 19 up on you! SLACKER!
i'd rather have engineers spend parts of their day talking with their customers and dependants to get a feel for what the demands and schedule issues are. And if you're not smart enough to ask for help if your stuck, you need to stop thinking so damn highly of yourself.
i'm sure Scrum will go away, just like every other methodology did. i'm sure that there will be some that praise it as the wondrous saviour of the generations. i just wish folks would be freaking honest about it and stop pushing the propaganda.
And seriously, Scrum?
Did you ever even WATCH a rugby game?
Moved to the right post –jr
This is a bizarre and mis-informed posting. The first irony that stands out is that you critique Scrum yet at the same time claim steps that should be done instead, are actually part of the scrum methodology. Second of all, there are errors in your description of scrum. For example the daily stand up meeting is not a place for conversations with your customer. That should be done during the regular course of daily development events. So have you read Ken Schwaber's book? Perhaps you are experiencing a poor quality implementation of scrum? Scrum is easy to describe, and hard to implement, because it forces a lot of transparency in the project. Some people are uncomfortable with this transparency. The other major problem with your implementation would seem to be that the team cannot maintain a sustainable pace, that it is being asked to do more than is possible in a given sprint. Its the responsibility of the team and the scrum master to push back on the customer, and force them to actually make the very hard decisions of scope that will get done.
What is the velocity of your team? Do you know? You should. A well performing team has a constant velocity. This can be used to predict how much work the team can realistically get done in a sprint. when the work is estimated at the beginning of the sprint, the team and the customer should have a good sense as to what is doable. It sounds like neither the team or the customer actually know what the team's velocity is, so they just ask for everything. Fix that.
You mentioned being competing with your peers. Scrum teams live and die, and are measured by the business value the team delivers. All those colored buttons don't matter if the back end isn't done. The team is responsible, and so the team needs to pitch in together, be it in testing, requirements, development, etc. A team of people who have a diverse skill set working in an agile team gain experience in each other's domains. The teams self organize around the work, and ownership comes when as a team you commit to the customer to deliver n features as commercial quality code, and when you take on a task and commit to getting done.
As someone working in a very large company that is implementing Scrum with XP, there has been a 75% improvement in time to market for software projects since adopting Agile methods, and Scrum in particular. Large companies DO use waterfall, have big requirements docs that continually become out of date, time slice their developers across many projects, engage in lots of reporting on artifacts and sign offs, all the while the software, the thing that delivers the business value, creeps along under the dysfunctional PM organization. The "Command and control" methoids mentioned by another poster are simply ego driven statements about a long expired management technique that has no place in complex project development.
I am sorry you have had a bad experience with Scrum. It sounds like the implementation is problematic, and in need of refocussing on the core issues. Product managers clamoring for the next greatest feature to be in the next release will never stop. They need to be taught how to manage a scarce resource, their development team's time, and to do so means keeping a sustainable pace, while delivering the maximum business value possible. It means being responsible, and understanding what really is important for the business in total.
regards,
Robin.
(First off, I moved your comment to the right topic.)
I don't see what's so bizarre about the post. I'm stating that the methods of scrum are basically the same that most programmers already do, just with a layer of bureaucracy, overt brow-beating, needless competition, and the occasional dash of religion tossed in.
So, you've got daily standup 15 minute meetings replacing the hour long weekly status meetings.
As for the "velocity" of my team, no, I don't. Mostly because "velocity" is an artificial metric. I know the ability of my team to estimate work, achieve dates and provide support. If I were to divide a large task into several hundred tiny tasks, that would undoubtedly improve my apparent task completion rate, but would still require me to accomplish that large task. In many ways, "Velocity" is about as meaningful as "Lines of Code", and has the same sort of reward associations. Customers don't care about either. They have requirements they need to meet. Feel free to replace that term with whatever new-speak you wish, but fundamentally, it's a requirement.
You'll get no argument that transparency is good. A good programmer knows when to ask for help and when to offer it regardless of whether or not it's requested. They can listen to the people they work with, talk with them during lunch and get a feel for the level of frustration.
Competition is human nature. It exists. Even the most egalitarian societies recognize it. I can't tell you how many times I read proposals about scrum that seem to gloss by that fact. Yeah, it takes many people to raise a barn, but when you're doing 40 a year, some folks are gonna be doing a lot more work than others. You'd better have a way to handle reshuffling those groups. Likewise, you'd better realize that people will also get "pigeon-holed", and sometimes, it's by choice. That effects what your team will be able to accomplish.
Scrum, like any other methodology, is a tool. One that works in certain instances, and less so in others. Scrum is not a panacea, and frankly is being sold as one far too often. I'll note that at a recent sales pitch for scrum we were shown a pie chart that stated: 83% of folks would use scrum when asked. Again, it's a meaningless statistic. When were they asked? How many other methodologies had they used? How many different companies had they worked at before this? If I asked you "Would you like to continue to receive a pay check?" you'd mostly likely say "Yes". I guess then you wouldn't like the four million dollars I was going to give you otherwise.
I'm glad that Scrum works for you and you're happy with it. I'm glad that it's allowing you the leverage to say "No" to various product demands for now. I just realize that it's also incredibly fragile and will fail at some point. How you work with folks after that is more important.
Thanks for your comment and insight.
Most of the programmers I know laugh a lot when we hear "in need of refocussing on the core issues".
Here's my 2 cents… (not enough time to take the post on point by point)…
If Scrum benefits management, then it benefits engineers. In my company, if we can't deliver effectively – then we are challenged to offshore the work. Delivery takes effectiveness across all levels.
If I were your manager, I would be very concerned about this concept of "competition". Scrum, if implemented as intended, really does foster powerful team dynamics, where the whole is greater than the sum of its parts. The professionals on my team fully value the benefit of a team member who states that they "interviewed Sponsor ABC, and XYZ yesterday" every bit as much if not more than the team member who states that they performed a high quantity of repetitive tasks. Likewise, if one person on my team is struggling, it is my full expectation that others would step up to help them out, rather than focus on their own agenda.
Unfortunately, you have done a discredit to Scrum, and simply made it harder for teams already battered by poor management to actually embrace an empowering methodology should they ever have the opportunity.
I agree that it is nothing new. Scrum is just a brand. But does foster a lot of good practices. We are having great success with it (higher morale, greater capacity, happier sponsors).
Like anything else in life, I guess you get out of it what you put into it.
Thanks Roger,
Yeah, competition is an issue, and honestly I'd hope that folks were smart enough to deal with it within the team, but in all honesty, my greater concern is my fear that outside groups may use task completion as an artificial metric for performance measurements. In that case, smaller, easier tasks will be rewarded equally as larger more difficult ones.
I also don't see Scrum really solving the problem of managerial push either. Scrum is an all or nothing methodology, and that includes those driving product decisions. The Scrum leader really needs to be a referee in that regard, which means that he'll garner less favor with both sides, since he'll have to say "No" as often as "Yes". Not a very fun position, really.
I can see managers replacing good leaders with "more flexible" ones. In order to really fix the problem the entire team needs to work as one, and that transcends methodologies.
I've watched a lot of different types of projects go sideways. For a while, watching that and then doing CSI:Hicksville on the dead project was part of my job.
The number one reason I've seen this happen, across a bunch of different businesses and industries?
The "Vatican Method" of Project Management. Do what you want to do, and pray a lot about the outcome. (Yeah, ok, so that's cleaned up a bit)
As soon as that starts, everything else in the project is about leaning on heros in the team, or coming to terms with the bitter feeling of failure.
I'm not saying proper PM will make a project go well, but its absence is notable in the projects that don't.
With good PM, actual execution methods are secondary in most cases that don't have crazy interface (scope boundary) requirements.
Except the industry where I work now – which is why I work in it. You don't want us to scrum, agile, swerve, bob, feign, or duck-walk You absolutely want us to be top-down, by-the-book, right-on-the-money, set-your-watch-by-these-guys, my-god-what-a-bunch-of-tight-asses.
And it's making consumer products in a highly competitive market.