"This project can't be done on Scrum – the client only understands 'Use Case.' They will never give us a user story!"
"Nope -- there is no way we can have an MPP as a Scrum project!"
How often have we come across situations where people have complained about something similar to the points above? Don't freak out! Probably we just came across another Scrum Fundamentalist (aka: scrumdamentalist
If we look into the situation, is it wrong to follow pure Scrum? Of course not. In fact, if pure Scrum works for our project -- voila! Nothing could be better than this. But the fact is, in real life we come across situations and projects where pure play doesn't seem to work, and we need to "inspect and adapt."
Let's take a few situations to dive deeper:
No upfront design/architecture: Have we ever come across a decent house -- that was built without a design? How can we build anything without a plan? Yes, we do need up-front design, but let us not overdo that (that is, don't paint yourself into a corner). We don't wish to get to the debate of BDUF (Big Design Up Front) versus RDUF (Rough Design Up Front) -- but we do need design to start off.
Daily collaboration: In an onsite-offshore model, we often come across situations where teams get into the cadence of having a daily collaboration. But before setting a cadence, ask yourselves, "Do we really need this?" Sure -- if there is a need, go ahead! But let us not impose collaboration on teams.
Story points: Do we always have to have story points? Not really. If your team is in the first leg of its journey, story points may make sense to help team members understand the process better (I personally provide them an hour bucket to start with). But for an experienced team, let's cut them some slack. They might be more comfortable using t-shirt sizing to categorize their work. Some teams may even feel comfortable to doing a ROM PD estimate (though I personally prefer a combination of story points and WBS -- hourly break-down).
Risk tracking: We often get into the feeling that we don't need to explicitly track risks, as we are covering them via release plans, sprint plans, and daily stand-ups. But no harm done if we start tracking them using a simple spreadsheet or, even simpler, if we leverage the ALM that we are using. It not only helps us in tracking risks and interrelated dependencies but it may also act as a nice set of empirical data for the future.
Retrospect: We all hold retrospectives. But does it make sense to have a retrospective without taking the action items, or without driving the open items to closure? Does pure Scrum only talk about driving a retrospective and not driving the open items to resolution?
All said and done, the point is: Pure Scrum (that is another topic -- what we mean by "pure") may not always work, and we do need to make "adjustments" to make it work right in a given context. This is the need of fluid market dynamics, and this is what the Agile Manifesto guides us toward: "Responding to change over following a plan."