Not only are our sprint planning meetings not fun, they're downright dreadful.

The meetings are tedious and boring and take forever (a day, but it feels like a lot longer).

The developers complain about it, and dread upcoming plannings.

Our routine is pretty standard (user story inserted into sprint backlog by priority >> story is taken apart to tasks >> tasks are estimated in hours >> repeat), and I can't figure out what we're doing wrong.

Here are some more details, in response to requests for more information:

Why are the backlog items not inserted and prioritized before sprint kickoff?

User stories are indeed prioritized; we have no idea how long they'll take until we break them down into tasks! From the (excellent) answers here, I see that maybe we shouldn't estimate tasks at all, only the user stories. The reason we estimate tasks (and not stories) is because we've been getting story-estimates terribly wrong—but I guess that's the subject for an altogether different question.

Why are developers complaining?

Meetings are long.

Meetings are monotonous. Story after story, task after task, struggling (yes, struggling) to estimate how long it will take and what it involves.

Estimating tasks makes user-story-estimation seem pointless.

The longer the meeting, the less focus in the room. The less focused colleagues are, the longer the meeting takes. A recursive hate-spiral develops. We've considered splitting the meeting into two days in order to keep people focused, but the developers wouldn't hear of it. One day of planning is bad enough; now we'll have *two*?!

Part of our problem is that we go into very small detail (in order to get more accurate estimations). But when we estimate roughly, we go way off the mark!

To sum up the question:

What are we doing wrong?

What additional ways are there to make the meeting generally more enjoyable?

Efficiency and companionship

Why are the backlog items not inserted and prioritized before sprint kickoff? Wasting developers' time is not fun. Let your team leads work with the product owner and project manager a few days beforehand to prioritize stuff. This goes for planning who is on each sprint team too.

Why is it taking a day to break things out into tasks? If you have a reasonably sized team (2-4 developers, .5-1.5 QA people per developer, 1-2 misc) then you should have 2-4 user stories this sprint. Spend 30 minutes or so with the product owner clarifying requirements, then 30 minutes or so breaking it out to ~8 hour tasks. Don't enter the tasks during the meeting. Just agree as a team what the tasks are, who is responsible for them, and about how long they should take. Agree that "how long they should take (including testing)" fits comfortably within the sprint.

If it's not just breaking things into tasks, what else are you doing? Sure, retrospectives can take 30-60 minutes, but will be shorter as the teams get into a groove.

So in summary—quit wasting people's time and they'll dread the meetings a bit less.

Beyond that, fun and comradarie in the team isn't something you can address in meetings. Go to lunch together, joke around, mix people up to have better personality fits, have mustache growing contests... once the morale is up then people will naturally make sprint planning meetings more lighthearted.

Less planning, better planning

Based on my experience, a sprint planning meeting should take no more than 2 hours per week being planned (e.g. a 2 week sprint should take 1/2 day at most), but successful ones should be shorter than that (half of it).

In your particular case: why are you estimating tasks? You should estimate only stories during planning. Tasks can be estimated later by the specific task owners.

A way that worked for me:

Quick intro to the sprint by the PO

Estimation of the sprint capacity

Stories run down and planning poker (timeboxed at 5/10 minutes per story) until there's enough estimated stuff to cover the sprint

Meeting-style musical chairs

Planning is one area of scrum where teams have a lot of flexibility. Try something new every sprint until you hit on something that works for your team.

Some successful ideas I've either tried personally, or heard about from other teams:

Do user story creation and prioritization without the entire team. The product owner and/or scrum master can handle a lot of the busy work and just let the team tweak it.

Make your backlog significantly longer than a single sprint. It can take a while to build it up, but if your backlog is long enough, planning meetings are reduced to making small tweaks or addressing recent business developments.

Have estimation meetings separate from sprint planning. If people think the meetings are too long, there's no reason not to split them up.

Specifically plan breaks into the agenda. This is useful if you're often wasting time waiting for one or two team members to return.

Break in the middle of the meeting and assign everyone to task out one or two user stories, then meet back together to report and gain consensus.

Make sure your planning meeting is about what to do, not how to do it. Engineers fall very easily into the latter. If you need to, set up separate design meetings where you discuss the how.

Separate your stories into investigation and implementation. Planning meetings often go too long when team members know too little about what they will be working on, and try to figure it out during the meeting. For example, say you needed to integrate with an API that your team has no experience with. Rather than try to create estimates and tasks during the planning meeting about something you are clueless about, make one investigation story to learn the API, do a simple "hello world" app, and teach it to the team. Then you'll be equipped to plan the actual work.

Keep track during your meetings of specific issues. Not just "planning is boring," but a level of detail like, "we spend a lot of time talking about unclear requirements, and no one seems to know the right answer." Then discuss those specific issues in your retrospectives and brainstorm for specific solutions. Break your problem down until the pieces are easy to solve.

We hold our sprint planning and retrospective at the same time, and are almost always done in 90 minutes, but we are one of the faster teams. We do a big company-wide, longer-term planning meeting every 5 sprints that takes 4-6 hours. Every team is different, of course, but if you're spending an entire day every sprint, there's a lot of room for improvement.

43 Reader Comments

I have a genuine question about this as well. Here I read again the planning session should be about what is going to be done, rather than how it's going to be done. At our company though, a large part of the meetings is spent as well on the how question.

Frankly, I fail to see how you can determine what to do and estimate how long it's going to take without also discussing the how part. I think this is something the original poster struggled with too, because how can you give accurate estimates without knowing how you are going to implement it to begin with? In fact, in my experience stories are usually grossly underestimated because of unforeseen tasks unless you dig rather deep into the how aspect first. I guess you can debate whether the meeting is the proper place to do this digging, though it is often also good to not do this alone because co-workers can often provide useful insights at this phase.

Frankly, I fail to see how you can determine what to do and estimate how long it's going to take without also discussing the how part. I think this is something the original poster struggled with too, because how can you give accurate estimates without knowing how you are going to implement it to begin with? In fact, in my experience stories are usually grossly underestimated because of unforeseen tasks unless you dig rather deep into the how aspect first. I guess you can debate whether the meeting is the proper place to do this digging, though it is often also good to not do this alone because co-workers can often provide useful insights at this phase.If someone has some insight into this I would really like to hear it!

I think you're right, the how part is critical. The product owner needs the team's estimate of the stories to prioritise the product backlog effectively. Do not do this estimate in man hours. Use planning poker and relative estimating (T-shirt sizes or Fibonacci sequence).If a team really doesn't know how to implement a story, then it shouldn't be accepted into the sprint backlog (perhaps it's a spike that needs to be investigated further).

Accurate task estimates are less important than empirical measures of team progress: knowing it takes exactly 5hrs to do a test is less important than knowing a team can do about 30 story points from the product backlog a week. I think people (and managers especially) expect estimates to be way more accurate that is actually worthwhile.I would prefer not to estimate the tasks in hours either, but in % of the sprint backlog ... because some people will want to keep adding tasks in the belief that this keeps the team utilised and efficient. This is not the point of Agile.

How to deal with long planning sessions: schedule them for an hour. When the hour is up, the meeting is over. Period. And the coming sprint will be total chaos. Which consistently makes developers really miserable. And makes them speed up a WHOLE lot during the next planning session. Seriously. Really. It sounds insane. But it really does work. I've seen several new scrum teams go through exactly this process, successfully. The problem with letting the planning sessions run for a day is that you're ALLOWING bad behavior to happen. So don't. It's the scrum master's job to do this, by the way: the scrum master is responsible for making sure the process is being followed; and if the planning meetings are taking more than an hour, it's the scrum master's job to end the meeting, there and then. People will catch on very quickly to what's required to finish a planning session in an hour. You probably want to use one week sprints if you're expecting this to happen.

On a team that's running well, the actual answer is that you don't need to know EXACTLY what needs to be done. Just enough about what needs to be done in broad strokes so that you can make a guess.. The precise details of what needs to be done can be refined outside of the planning meeting by the person who takes the card, in hallway meetings, if that's necessary. It may be helpful for the scrum master to shut down discussions of unnecessary implementation details in the planning sessions, if the team isn't getting it.

Frankly, I fail to see how you can determine what to do and estimate how long it's going to take without also discussing the how part.

And the answer is: you don't! That's the price you pay for running on low overhead: inaccurate scheduling. Under the old system, you spent 1/3 of your development time developing accurate estimates. In scrum, you're spending 2 to 3% of your time developing estimates. Of course they're not going to be accurate! What makes the whole thing work, is that remarkably, those hasty estimates made on the spur of the moment tend to be CONSISTENTLY inaccurate. What makes the whole process work is the burndown multiple, which gets re-calibrated at the end of each sprint, based on running experience.

If you try to hold developers to their task estimates, without a multiple, all your going to do is end up with unhappy developers, which is enormously counterproductive. Happy developers are productive developers. It's not reasonable to hold them to accurate estimates, given that you're not making accurate estimates. Just adjust the multiple at the end of each sprint, and don't worry the fact that it's not 1.0. Oddly, on every team that I've seen do scrum well, the burndown multiple seems to settle at 0.5 very consistently. Not out of any particular desire to make it settle there. It just seems like confirmation a well known maxim of software development: that no matter how long you take to generate accurate estimates, it always takes twice as long as predicted. Spooky. The burndown multiple gets adjusted up or down, by team consensus at the sprint retrospective.

What matters is predictability. And if you're getting it by multiplying by a magic number, just do it, and don't ask questions. (My personal theory: the "twice as long" factor covers the things you forgot to plan for, but I try not to ask questions).

I found Sims, The Elements of Scrum really helpful when starting our Scrum process; for me, it seemed to convey the right balance in terms of what to place emphasis on when ramping up the process. Even though it sounds like your scrum is reasonably established you might find it helpful to introduce new ideas, or perhaps change emphasis in your sprint process. It's a short read so I highly recommend it.

As others have mentioned, it sounds like planning poker could be helpful to you. The importance of the fibonacci story points rating combined with planning poker is that you are not trying to estimate the duration of a task in absolute terms, just a relative gauge whether "this" task is longer than "that" one. Over time as the team becomes used to the scoring process the idea is that they will score more consistently, and analysis (retrospective) will show that the team is not able to complete more than a certain score per sprint. For example, my team of 5 developers has settled on about 120 points per sprint; if the point score of our items is much more than that then we now know that we are at serious risk of not being able to deliver everything in the time available.

In our two week sprint we spend 1-1.5 hrs at sprint kick-off (developers + stakeholders), 1-1.5hr in backlog grooming (developers + stakeholders), 0.5hr in sprint review (with stakeholders) and 1hr in sprint retrospective (development team). Sims gives percentages to help scale with sprint length, but I think our durations are roughly in line with his percentages.

Isn't the point of this sort of development to break tasks into small enough components.

Sure, any estimate for "How long will it take to write an HTTP/1.1 compliant multithreaded web server" is going to be way, way off.

But isn't "how big of a task can you polish off in about eight hours?" a question that most programmers who've programmed for more than eight hours can answer within a useful margin of error?

Sure sometimes you will be way off because of hidden land mines that only show up when you dig into something, but if you're consistently way off on how much work you can do in one day, that implies some sort of deeper problem.

The problem is obvious - your meetings are taking too damn long. They should be no longer than an hour, tops.

I've done the 3-4 hour meetings, and I can say for the most part, I could've slept for 90% of the time because I wasn't needed - it just wasted everyone's time.

The problem is not the development methodology, it's the meeting methodology. There's obviously way too many people in the meeting (everyone might be involved or impacted, but do they really need to be there?).

If you're having all-hands meetings one day a week, that's 20% productivity gone down the drain. Everything should be compartmentalized - the developers report to the lead developers who report up the chain so at the big sprint planning sessions, it's only the top managers.

Next time, take a look at your meeting. See who's participating and who's really required. If it's all the managers discussing, then get rid of the developers - they're just nodding off anyways. Developers input should've been solicited before the meeting to plan priorities so the managers can discuss what their team felt as important and then broken down into tasks. If one is missed, then it's brought back down to the devs and re-estimated.

There is nothing to be gained by getting all your developers into a room - it's not that much quicker and it brings in dread. If your developers are smart, they'd bring in laptops and be web surfing the entire time because they aren't getting any work done anyways.

For most Agile development, the team meeting should be no longer than 15 minutes a day. The manager's job is to handle all the little planning details so the developers can work - seeking top to bottom comments in a one big ass meeting just doesn't work and you'll accomplish in 8 hours what you could've in a couple of hours because the bigger the meeting, the more sidetracked you become and you'll waste hours in pointless debates between developers.

There was a brief time in my career when I wasn't subjected to Scrum's trappings and it was glorious. No daily meetings, no weekly planning meetings, no retrospectives, etc.

Planning and prioritization was so simple. The product manager used a bug tracker. Our bug tracker tracked both new features and bugs. Developers worked on whatever was highest priority whether it was a feature or a bug. We demoed things when milestones were reached, not every two weeks on an arbitrary schedule like Scrum mandates.

We could sometimes go weeks without meetings of any kind and things hummed along smoothly. Many people worked from home for weeks at a time. It was great.

Not anymore.

Now Silicon Valley is once again obsessed with the latest management fads and Scrum is trendy. Working from home is passé; almost taboo. It's definitely frowned upon. Teams are supposed to sit with each other all day, every day. The office is noisy and distracting. It's like a regressive 1950s stereotype.

We're once again fully immersed in Scrum's trappings. We're drowning in daily meetings. Every two weeks we have a demo, even if there's nothing to demo because the "user stories" we're working on are too complex to finish in a single "sprint." Retrospectives are nothing but long debates about the semantics of Scrum and whether we're doing it "right." Daily standups last an hour. Planning meeting go into useless amounts of detail in an attempt to accurately predict how long something will take to implement. And yet those estimates are rarely accurate even with so much emphasis placed on the effort.

Things were so much better when we weren't being micromanaged by Scrum. Things were so much better when we were just trusted to fix our bugs and implement our features without having to constantly estimate how long it will take and report back daily on progress. Scrum is such a draining and expensive process that I think we're actually working slower now. We're certainly not as happy as we were when the work environment was more low key.

Now Silicon Valley is once again obsessed with the latest management fads and Scrum is trendy.

THIS.

Is it that developers now need to be treated like unruly children or is it possible management is desperately grasping to justify their existence?

I've been programming professionally since the early 1980's and have seen every management fad. I even worked for one guy who used kidnapping as a management tool--he invited us to his house on a Friday night and locked us in a room and wouldn't let us leave until we finished our project.

I can honestly say I've done more and better programming without a boss than I ever did with one. My current project is my best yet and I am the entire software department. Guess how many meetings our department has, and yet I've hit every milestone so far.

Now Silicon Valley is once again obsessed with the latest management fads and Scrum is trendy.

THIS.

Is it that developers now need to be treated like unruly children or is it possible management is desperately grasping to justify their existence?

Management (as in your supervisor) isn't part of a true scrum team, though. While scrum-styled agile development is definitely highly structured and not the willy-nilly kind of development that for some reason is often associated with agile, the scrum process is supposed to be self-organized by the scrum team itself. The only real management involved is the scrum master, who manages the overall scrum process to make sure it's going smoothly. Upper management should not be meddling with the scrum team at all. I'd bet that many people who think this is a terrible way to do development have either had upper management try to control it or have had a scrum master or product owner who wasn't doing their jobs correctly.

Frankly, I fail to see how you can determine what to do and estimate how long it's going to take without also discussing the how part.

See edrowland's post first. Once you have a few sprints with quick estimates under your belt things should improve. However, sometimes even then you truly don't have any idea of what to estimate. In that case assign a small, defined, and time boxed "spike".

The spike will be a fixed amount of time that you can estimate. What you do during that time is investigate what it will take to do the user story, some high level design, and how it can be broken down. Then in the next sprint you take you newfound knowledge of exactly what you are going to do and you estimate the full user story/task and schedule it then. That way you don't use up meeting time, which is expensive due to the number of people in the room. If you really need to speak with or meet with others to figure this out, schedule a much smaller side meeting as part of your spike time so the people that can actually be helpful are the only ones there.

FYI, the reason that you hate Scrum is because you're not actually doing Scrum. You're doing some sort of management bastardized version that thinks that having hour long daily stand ups and trying to accurately predict the number of seconds it's going to take to complete a task is a worthwhile expenditure of your time.

That's not Scrum.

I've worked in shops like that before. They usually call it Scrum, and have no clue that the people they've hired might actually know what Scrum is, and as a result, are shocked when someone tells them they've cocked it up. That's pretty common. But it's not Scrum.

* avoid having more than two people in any meeting - this way everyone (all two of them) is fully engaged in the discussion * avoid discussing more than one item in any meeting - this way you can focus on just the one thing and finish when it's done * try to keep them short, 5 minutes or so should be enough most of the time

If more than two people need to be involved, we'll have a two person meeting and then post the results in writing for everyone else to see. They can raise issues (in writing) and any point that needs further discussion can be done in another two person meeting (perhaps different people than the previous meeting). When meeting with the client, rather than company employees, often the client will bring two or even three people in (business partners usually) but we try to avoid that and they always only meet with one person at our company.

We try not to discuss more than one item, this is a hard rule to follow but also an important one. We compensate by having meetings more often (sometimes multiple per day), but they are very short (less than one minute sometimes!).When things get busy a few things will queue up and you have to discuss more than one item in a meeting, this is inevitable but it can be avoided usually.

Short meetings aren't always possible either... but at least if there are only two people and if the entire meeting is only covering a single topic (even if it is 6 hours long), then likely it will have been a very productive meeting - though it will fry your brain for the rest of the day/night. Productive meetings usually leave everyone involved satisfied at the end.

Now Silicon Valley is once again obsessed with the latest management fads and Scrum is trendy.

THIS.

Is it that developers now need to be treated like unruly children or is it possible management is desperately grasping to justify their existence?

Management (as in your supervisor) isn't part of a true scrum team, though. While scrum-styled agile development is definitely highly structured and not the willy-nilly kind of development that for some reason is often associated with agile, the scrum process is supposed to be self-organized by the scrum team itself. The only real management involved is the scrum master, who manages the overall scrum process to make sure it's going smoothly. Upper management should not be meddling with the scrum team at all. I'd bet that many people who think this is a terrible way to do development have either had upper management try to control it or have had a scrum master or product owner who wasn't doing their jobs correctly.

In my experience as both a developer and a project manager, I can say that you're correct, but not for the reasons you may think. Development patterns such as scrum/sprints are usually implemented (or work best in) peer based scenarios. That is, no single person in the process has managerial duties (in regards to software development), delegation authority, or sole responsibilty. Any leadership (such as a scrum master), is either rotated regularly (either such that everyone gets a turn, or such that the person with the most experience on the given task set at the time leads), or is a first amongst equals sort of thing.

The sprint process is designed around everyone being on the same footing, both development staff and users, and internally in the development team. The idea is to develop a peer-based highly structured development cycle in the absence of (competent) management. Because unstructured peer-based development among (essentially) random individuals can often go wrong, and relying on this for business-critical software is a recipe for disaster. On the other hand, heavy handed management of development by an individual who has either little or no development experience, has development experience but no management skills, or is just plain incompetent, is often worse than having developers wander around blindly.

Sprint/scrum development makes senses under certain circumstances. However, project management by someone who understands development, software architecture, the business domain processes, the system at hand, and knows their team well, is often far superior to organic processes developed out of necessity. If the project leader knows what needs to be done (or can themselves determine this from users), can break this up into reasonable tasks, prioritize the tasks, assigns the tasks based on the team's strengths and weaknesses, all while listening to the team's experiences and adapting based on the word from the trenches, so to speak, development is not only rapid, but of higher quality.

This is because a central point of authority for development allows the team to be proactive instead of just reactive, anticipating user needs before they have them, architecting systems with an overarching plan instead of a haphazard slapdash of disparate pieces. I've seen that a lack of an overall plan often ends up causing a lot of additional work later on. A little planning up front amortizes very well. Decouple your software systems and you can replace sections piecemeal, rather than throwing the entire system out every 5 years.

I'd recommend anyone interested in development management read the book Peopleware. It's a bit old, but the concepts age well.

On another note, I've noticed that companies I consult for often have a single team that handles both bug fixing / software support for existing systems, and development of new features for existing systems, or even entirely new systems. Based on comments here, the practice seems widespread. In some cases, the budget or team size is so low that this is unavoidable, but in others, it's simply a matter of "this is how the previous manager did things", even in cases when the team has significantly grown since then. Handling both bug fixing / support and new development simultaneously ends up pulling people in different directions, causing stress, lost productivity, and eventually employee churn. Spinning off development into its own department can do wonders for productivity (not to mention that bug fixers are cheaper to hire than developers).

Keep in mind that anything I've suggested here can be and has been implemented poorly, causing significant problems. There are a lot of pitfalls that need to be avoided, which is why things like scrums exist. It's hard to screw up scrums to a huge extent (the worst I've heard of are things like the original question, scrums are tedious, but things still get done reasonably well), which is why they are so often recommended to people. When you get project management right, though, it's amazing how stark the improvements are.

I've worked at a few places where Scrum has been implemented. I've talked to many colleagues who've had the same experience, and what I've notice is a pattern in the way the methodology gets corrupted or degenerates into the chaotic and exhausting environment described by some here, and by the original topic poster.

Below are a few observations on Agile methodologies I've made over the years.

1. It falls for the No True Scotsman fallacy: if it is not working, you must have done it wrong; but then again, it seems to be done consistently wrong across the industry.

2. There's too much touchy-feely required interaction that seem to be forced attempts at manufacturing team spirit.

3. It is probably the product of the "there are no winners or losers," "you're all special snowflakes," and "everybody gets a ribbon" children-upbringing methods of the past couple of decades.

4. It ignores history and lessons from the industry's past--it abhors anything that is older than a decade or so. If it was done in the "old days," it must be wrong, therefore we must change it. Or at least call it something else, perhaps after a sports analogy.

5. Attacks the rigid structure and strict processes of older methodologies, while creating it's own set of "ceremonies" that are just as strict and ruled, albeit with a new name (see #4).

6. It is the new silver-bullet, the Single Hammer For All Things Nail. It is suggested as applicable to every single type of project, from the user-facing web site, to the low-level back-end systems development.

7. Everything can be broken down into tasks of 8 hours or less.

8. Every system can be evolved iteratively without fully capturing the problem domain.

9. Every application can have a deliverable in 2 weeks.

10. Project or people management, systems architecture, and business analysis are all roles that any developer can take, on the fly, interchangeably. The exception of course is QA testing, which is a dedicated role--perhaps because developers find it too boring or tedious (see #3).

And lastly...

11. I'm convinced that Scrum was invented by the Post-It subdivision of 3M. Really!

FYI, the reason that you hate Scrum is because you're not actually doing Scrum.

Yes, yes, we've heard it a thousand times, if Scrum isn't working, it must not have been truly Scrum. Probably isn't a true Scotsman, either.

I'm not saying that Scrum is infallible or that it can't be used to poor effect, but that what you personally were describing is not Scrum. Hour long meetings and user stories that can't be completed in two weeks isn't Scrum, it's simply something that shares the name.

The name is not the important part, the practices are. When you bastardize the practices and complain about the name, you've got it backward. One of the central tenets of Scrum is that developers can change the system to suit their needs. If you're unhappy, if your team is unhappy, and you can't change it, you're not doing Scrum. So don't complain about the name.

It would probably help to find out the real reasons why the estimates are so far off, as this may well reveal what is actually going wrong in the process.

I say 'real reasons' because naive or formal post-mortems tend to turn in to pass-the-buck blame games driven by self-serving rationalizations and non-sequiturs, as displayed in the house hearing on healthcare.gov.

Other than that, I second everyone who says that meetings must be limited to those people with a direct and consequential involvement in everything that is being discussed.

We plan over Skype or in a Hangout, share a screen and discuss the story. Then we use http://size.antix.co.uk (something i wrote) to estimate on a Fibonacci scale.Discuss any differences of option until we agree, note the result and move on.Its fun and productive.

Other than that, I second everyone who says that meetings must be limited to those people with a direct and consequential involvement in everything that is being discussed.

Which actually raises an interesting possibility....

In our planning meetings, decomposition of stories is done in parallel. Story cards are dropped on the table, and developers in the room decompose those stories into task cards in parallel. There is a room full of people, but everyone's working at the same time.

If you're doing the estimates serially, with everyone in the room being forced to watch what's going on whether they're in a position to contribute or not, that would certainly turn what should be a one hour meeting into an all-day meeting.

In passing, I've always done the physical index card version of scrum. I can't help wondering how that estimating-in-parallel process works on an electronic scrum board.

I am a veteran developer (starting with Fortran and SPSS on punched cards in 1973) whose career has included stints as a DBA, app architect director and now PM (making me certifiably useless). I work for a large (30b) multinational. We have always had a strong commitment to custom in-house development, although today it is more focused on providing the business with differentiating capabilities over an ERP backbone.

When my responsibilities included R&D we started our first Agile projects in 2008 using OpenUP, shifting to a modified Scrum in 2010. This was done at the same time we were shifting from a mainframe 4GL supplemented with .Net to Java EE. Our move to Agile was difficult but the early promise was sufficiently enticing that we persevered and I believe we are now a reasonably mature and effective Agile development shop. The business is also supportive, finding it empowering and generating high quality products. And contrary to some views expressed here, I believe it is the appropriate methodology for us for all but the most repeatable of projects.

So to what do I attribute this success?

- Drop the capital A in Agile. Stop listening to the purists and take what works about agile and incorporate it into your methodology in a way that works for your organization's needs and culture. Adapt the methodology to the specific needs of each project. Never become complacent about your processes, but always look for continuous improvement. - Ensure that all work is done within a context of a well defined business architecture. This is very hard, but architectural maturity is worth striving for and removes much of the uncertainty from agile projects. - When necessary, and in most corporate environments is usually is, engage in formal requirements gathering. We almost always start with a well defined requirements backlog built through tradition business analysis, goal decomposition and story mapping. The business is deeply involved in this work, in defining minimum viable products and establishing the release plans. Even at this point we do high level estimating in order to provide the business with at least a rough schedule. - Do not underestimate the importance of the BAs and Product Owners. The success of agile is primarily in their hands. And make sure every developer can tackle the BA role. The tradition skills of a Systems Analyst, the ability to translate business requirements into technical design, remains essential.

As for the specific concerns about the agile planning process, here is what works for us.

- We hold a separate iteration (sprint) review where the product is demoed (usually by the PO) and the business signs off on whether the iteration objectives have been met. All project stakeholders are invited to this meeting which usually takes 15 - 30 minutes. - The retro follows, and can take up to an hour depending on how things are going. The art of running a retro is a whole other topic. One thing of note for us is that only the core team can be involved - i.e. I don't get to go. - Backlog grooming for the next iteration happens all along between the BA and PO. When they are ready the appropriate developers will hold technical grooming sessions with the BA and PO to elaborate and estimate the upcoming stories. All potential stories must be 'ready' before they can be brought into the iteration plan, and our definition of ready is very strict. The actual iteration planning session lasts 10 minutes with the BA and PO present, followed by a 1/2 hour task breakdown session. The team then confirms if the iteration goals can be met and reports back to the PO. - Iterations are three weeks long. This seemed the best compromise between agility and reduction of overhead. - Standups never last more than 10 minutes. They should be informative and fun, and always done with the burn down and kanban front and center.

In summary, there are two maxims that I believe encapsulate the difference between waterfall and agile, and why I believe agile is successful for us. They are a bit counter intuitive so can meet resistance from senior management:

Yes, yes, we've heard it a thousand times, if Scrum isn't working, it must not have been truly Scrum. Probably isn't a true Scotsman, either.

There seems to be a remarkable bright line drawn between those who hate scrum intensely, and those who love it passionately. I fall firmly into the latter category. Whether a development shop uses scrum or waterfall would be a serious criteria for me in a job search. I could never go back. And that's something I've heard time and time again from people who've worked on scrum teams that are work well.

I've worked on multiple scrum teams. And I've seen it fail spectacularly only once. In that case, the process was pretty much sabotaged by the product manager. He refused to use burndown multiples. People were held to account on hitting estimates. The board failed to clear on sprint after sprint after sprint. When people ended up holding cards that ran over the initial estimate, they were expected to work overtime to make the card clear before end of sprint. I have never seen a more poisonous work environment in my entire career.

Anecdotally, the consistent theme in teams where scrum fails spectacularly is that there always seems to be a manager or senior developer driving the process, instead of a collaborative approach to solving problems, and a sense of collective responsibility for the success or failure of a project..

I've worn both hats: a chicken hat (manager), and a pig hat (developer).

From a developer point of view, the benefits of scrum are the dramatic reduction in process overhead, and pretty much a guarantee that death marches never happen.

From a management point of view, the benefits of scrum are that the entire process is marvelously predictable when you have team that's calibrated and working well. That story point burndown chart (not the sprint burndown that developers live and die by, but the long-term chart showing progress on story points completed) ticks down relentlessly, and consistently, allowing to you know where you can expect to be, well ahead of time, in way that I have never seen in a waterfall approach.

2. There's too much touchy-feely required interaction that seem to be forced attempts at manufacturing team spirit.

Predicates that there's a chicken (manager) who's manufacturing team spirit. Pigs (developers) rarely do that kind of thing.

Quote:

3. It is probably the product of the "there are no winners or losers," "you're all special snowflakes," and "everybody gets a ribbon" children-upbringing methods of the past couple of decades.

Historically speaking, empowering employees is a management technique that first showed up in the early twentieth century. Comes from early recognition that empowered employees are far more productive than assembly-line employees in many business domains. And also a far older recognition that if you beat your slaves, they end up subverting the business process covertly. It's hardly an approach that's unique to the last couple of decades.

Quote:

4. It ignores history and lessons from the industry's past--it abhors anything that is older than a decade or so. If it was done in the "old days," it must be wrong, therefore we must change it. Or at least call it something else, perhaps after a sports analogy.

It respects the historical lesson that increasingly top-heavy development processes weren't improving predictability and seemed to be having dire consequences on reliability.

Quote:

5. Attacks the rigid structure and strict processes of older methodologies, while creating it's own set of "ceremonies" that are just as strict and ruled, albeit with a new name (see #4).

That's not scrum. Scrum is an inherently self-modifying process.

Quote:

7. Everything can be broken down into tasks of 8 hours or less.

That's a guideline, not a rule. Almost everything can be broken down into tasks of 8 hours or less.

Quote:

8. Every system can be evolved iteratively without fully capturing the problem domain.

That process takes place before stories are placed into the story queue. There are extensions to scrum that can be used to formalize the capture of problem domains, and inject concrete business requirements into stories, if you need to do that. Scrum isn't a solution to everything.

Quote:

10. Project or people management, systems architecture, and business analysis are all roles that any developer can take, on the fly, interchangeably. The exception of course is QA testing, which is a dedicated role--perhaps because developers find it too boring or tedious (see #3).

Project/people managers and business analysts do have explicit places in the scrum process (manager and product owner, respectively). They're just not developers. It doesn't seem impossible to me to incorporate a systems architect role into a scrum process, if that's what you need.

There seems to various approaches to incorporating QA into scrum. The "pure" approach, I suppose is to have developers do QA activities; but teams that I have worked on have used one QA/Tester per team, with an understanding that developers have to do QA/Testing if that's what's required to clear the board. That's a dramatic shift of emphasis from teams that I worked with at the height of the waterfall madness, when there were two QA for every developer. That shift is accounted for, largely, by a heavy shift toward automated testing. But that's not actually a scrum innovation strictly speaking; that idea has been in the air for most of the history of software development, and was being used in large-scale waterfall development processes before there was scrum. (The Mozilla development process would be a good example of the use of massive automated testing and instrumentation on a non-agile development process).

My take on Scrum is quite simple: every place I've seen it used was an environment I wanted to leave. It is a great way to get mediocre work out of incompetent developers. It is a great way to get a breath of accomplishments without a depth of accomplishments. It is a way to demonstrate Brownian motion on a large scale. It is an excellent reflection on the times we live in, and it is completely understandable why it is currently a popular fad.

This is exactly the kind of nonsense statement that has people seeing the True Scotsman fallacy. Scrum: the process that is apparently so modifiable that it is almost always not Scrum. As a computer *scientist*, I demand a little more rigor than that.

Since we started using Scrum, not a single day goes by where I don't think of changing my job. It is just a useless peace of brain washing.

My company switched from waterfall to scrum.These are big projects. 10+ developers per project in a yearly release cycle.

Previously, it was managerial nightmare. There were project that broke milestones by half a year but at the end they were somewhat usable by our customers.

Now, our product feels like a high school student project.Since there is no long term planning out projects looks like Frankenstein monster put together from different parts that don't really fit together. For example, you can copy/paste from context menu and keyboard shortcut on one window, but on another window copy/paste works only using keyboard shortcut. There are three completely different looking grid controls used in one application.Everything feels like a cheap prototype.

My take on Scrum is quite simple: every place I've seen it used was an environment I wanted to leave. It is a great way to get mediocre work out of incompetent developers. It is a great way to get a breath of accomplishments without a depth of accomplishments. It is a way to demonstrate Brownian motion on a large scale. It is an excellent reflection on the times we live in, and it is completely understandable why it is currently a popular fad.

I absolutely hate it.

Standard Scrum mantra:"You are all a team. There is no one individual that is responsible for success. Entire team is to blame for sprint failure. Can you do this bunch of things and I will check on you in 2 weeks to see if you managed to screw it up, because I don't really trust you."

It is really painful watching once great developers become mediocre developers since the introduction of Scrum, because they loose all the motivation. Why bother being good in these conditions? You just end up doing most of the teams work.

What I find interesting is that the worst developers are the ones that scream the loudest if team is not following Scrum guide to the letter. They probably feel safe under protection of the "team" concept.

I just LOVE when a guy who didn't finish his two backlog items and in the course of the sprint also managed to screw up one of your backlog items that were finished in previous sprint says: "Ok. Now we as a team need to agree what we plan to tell to our product owner about those two unfinished items."

You cannot make sprint planning fun. It's a necessary evil to get the suits to leave you alone for the rest of the week/fortnight/month so you can get real things done. Suck it up and if it bothers you so much, come up with something better. Scrum is not great, but it's arguably the best we have so far for companies with more than half a dozen developers. I look forward to the post-scrum world.

Suck it up and if it bothers you so much, come up with something better.

We had something better before Scrum. It was called a bug tracker. Before Scrum, managers simply filed bugs (whether they be actual bugs or feature requests) and prioritized them. Developers simply worked on whatever the highest priority items were. No daily status meetings, no weekly planning meetings. Just a simple, efficient tool. Meetings were held on an as-needed basis rather than on a rigid, arbitrary schedule.

This is exactly the kind of nonsense statement that has people seeing the True Scotsman fallacy. Scrum: the process that is apparently so modifiable that it is almost always not Scrum. As a computer *scientist*, I demand a little more rigor than that.

Agreed, and it is an example of a form of dogmatic thinking that has plagued software development since well before the appearance of agile methods.

The dogma itself is what I call the 'proceduralist fallacy', the idea that if you follow the one true methodology's mandates with sufficient fidelity, success is assured. If things aren't working out, there is no shortage of acolytes who will quote scripture to show which rule you failed to observe with the necessary rigor. There is always one, trust me. It is in the nature of these things.

If you ask them to be more specific, you will find that, regrettably, you haven't given enough information about your specific situation. If you try to correct your failing, you will find that you have embarked on a Sisyphean task, because the rules for your particular error have a peculiar fractal nature, whereby rules split into subordinate clauses and special cases without limit as you look closer. Or it becomes apparent to the expert that your real problem is with some other rule. It is an iterative process.

A naïve believer may let slip the idea that - of course - your staff needs competent people to follow these rules. He is blind to the inherent contradiction between infallible rules and the need for skilled interpretation because, if he knows one thing, it is that the methodology is the one true way. Either that, or he is one of those who can only hold one idea in his head at a time. The latter can be identified by their ability to effortlessly alternate between viewpoints that imply infallibility and viewpoints that depend on interpretation.

If you sneakily ask what are the rules that tell you what persons of good judgment would choose to do in your particular case, you will find yourself in the same twisty maze as mentioned a couple of paragraphs ago.

The true zealot is prepared invoke time travel, pointing out all the things you should or should not have done on the basis of what came to pass. He has no trouble doing this because, if there's one thing he knows, etc. etc.

I said that this predates the rise of agile methods, and traditional software engineering took the same path. It reached its apotheosis with the CMM, which judges an organization's capability in developing software, not by measuring its results, but by evaluating its adherence to a set of rules.

The thing that all this dogmatic thinking overlooks is that software development is a design-like activity, rather than a form of manufacturing, and all attempts to apply Winslow Taylor's principles will fail because they overlook the critical importance of knowledge, rational analysis, and good judgment to success.

Great article. But "mustache growing contests?" Come on. Let's please be a little more courteous and conscious of our environment and come up with some better examples that don't exclude female engineers, or any other group for that matter.