We were stuck.
There we were, a few iterations into new product development, and there was still no deliverable.
There we were, a few iterations into new product development, and there was still no deliverable.
The biggest Scrum failures come from lack of leadership. For one thing, no leadership means no scope discipline.
This is another item in my ongoing series of “How to Mess Up Scrum.” This time, I turn your attention to…
Let me give you an example. A few years ago, I was on a Scrum team that was assigned to develop a “retail portal” for the services this company already sold at old-fashioned store locations. In “phase one” the goal was to put up half a dozen or so static pages, plus one “contact” page to capture basic information so our sales rep can call you soon. That’s all.
It took three developers six months.
Why do you have hardening sprints? EVERY SPRINT is supposed to be hardening.
Some Scrum teams–whether formally or informally–have a recurring “hardening” sprint after every few regular sprints, in which they fix outstanding defects and make the system actually ready for delivery. This is a bad idea. Here’s why.
If you care about why you are “doing Agile,” you should care about the principles of Agile development, which include “early and continuous delivery
of valuable software.” Delivery. If you’re not continuously delivering software, you’re not Agile.
If you have legacy defects, which are any defects not tied to a current story, then those defects need to be made stories in their own right. If your current stories are implemented with defects, they are not done and you have no business considering them completed. If you haven’t integrated a pipeline from development to deployment, that is infrastructure! It’s not part of a sprint!
Make every sprint a “hardening sprint.” That way you always have a product to deliver. That way you are never wrong.
Fake reporting is endemic in dysfunctional Scrum shops. Here are some examples:
When you don’t prioritize the Product Backlog, you’re forcing everyone to think about all the backlog items at once rather than allowing them the blessed luxury of thinking about only the most important items right now.
In prior installments, I described a couple of ways to mess up Scrum: Adding work during a sprint and scheduling work for future sprints. This time, I direct your attention to another closely related way to mess up Scrum:
You know what? Humans aren’t that smart. We can think a lot about a given thing, but we’re not good at thinking about everything at once. Agile development recognizes that by letting us do just one, or perhaps two, things at a time and put aside the things that aren’t immediate. “Do today’s work today!” we say. “Do the simplest thing that could possibly work!” we say.
Those aren’t just cute slogans. They are reminders of how limited we are in our brilliance.
Continue reading “How to Mess Up Scrum, Part 3”
Someone who fears reprisal will withhold information.
I saw this and just wanted to share it. What a great summary of how Agile development so often goes wrong!
I love this part in particular:
There needs to be an absolute lack of fear around punishment or reprisal for negative information.
Someone who fears reprisal will withhold information. This is especially significant on under-performing or troubled teams.
Look at teams that are behind schedule (and not by a small amount), and you’ll tend to find that people usually know what the problem is. Yet if they’re not able to communicate that, well, things go south quick.
Scrum is not designed to provide certainty about the future. People who use Scrum are making a decision that they value other things. If you want to know with any degree of precision what will get done a month from now, or six months from now, that is fine but then Scrum is not for you.
Last time I explained how adding work in the middle of the sprint wrecks the rhythm of the team and undermines the concept of setting priorities.
Long story short, if you’re management and your highest-priority requirements repeatedly become visible to you in a shorter time frame than the length of a sprint, your sprints are too long! Finally, if you can’t make your sprints short enough to accommodate changes that are truly of the highest priority… then Scrum is not for you.
But let me talk about another great way to mess up Scrum, if that’s what you insist on doing.
If you have to add stories during a sprint, the problem isn’t Scrum or its rules. The problem is that your management can’t think a week ahead. FIX THAT.
I was just reading that 83% of software developers responding to a survey are practicing some form of Agile. Probably, most of those are trying to practice Scrum.
First thing, that’s probably wrong. Dividing all your work into “sprints” and having a daily standup meeting isn’t what Scrum is about, but that’s exactly what I see in the actual industry over and over again.
But rolling with that for a minute, let me talk about one specific thing that you should never do in Scrum…
Continue reading “How to mess up Scrum, Part 1”
One narrative of a successful Scrum sprint. This really demonstrates how most big organizations are getting value out of Agile methodologies.
So there I was, slogging away on some .NET code at a largish enterprise that was “really into Agile, we’ve been doing Scrum for like three years now!” We were a week into the current three-week sprint.
At that morning’s standup, we’d gone around the table as usual. Jon said he was taking the refactoring story on the WCF middle tier. Ellen, who I think was Scrum Master of some other team, assigned me the task of resolving an exception that was being thrown by client-side code. Jeff said he couldn’t package the database changes because there simply wasn’t anywhere to check them into TFS (version control). I had code checked out, modified, and working to implement a feature in an upcoming release; but I was holding off on checking it back in because, per the team lead’s policy, we can’t have more than one branch “because people keep doing it wrong.”
Phase I, he said, was running late and he wanted to know why. And furthermore, when was Phase II of the project going to get done?
Ellen said she had all our burn-downs and they checked out, as everyone had burned down approximately forty hours. She had also added up all the estimates for the stories that were going into Phase II, and they came out to 990 hours, and since we had six team members Phase II should be done in four weeks. In fact, she said, we could put all of Phase II into the next sprint, which would give us just one week of carry-over.
Okay, that’s good, said the boss–but when can we start testing the current release, the Phase I release?
That’s when the team lead told everyone we don’t really have a deploy script for the test server, and there’s not really a production server at all. It can take IT a while to provision the new production server, he went on, but in the meantime we can host the production system on a spare Windows 2003 server. Jeff pointed out that Windows 2003 won’t run .NET 4.5 applications, so we’d have to retool the application to .NET 4.0. He agreed, though, that it wasn’t worth doing until after QA finished testing the current code.
The boss thought my priorities in particular were off. “Look,” he said, “you can’t possibly need to have the API to FedEx done before the Data Access Layer.” I tried to tell him I wanted to hit the FedEx API first because it was a higher risk and thus would benefit from the greatest possible lead time, but the team lead cut me off, saying it was a low priority and wasn’t going to be in the current release anyway. (I later quietly asked, “Why was it in this sprint if it’s a low priority?” The answer: “We had to allocate all your hours and that was the only thing that would fit.”)
The boss whipped out his “to-do list” for the Phase I release. The FedEx thing wasn’t on it.
I was excused from finishing the API to FedEx, because another team needed that Data Access Layer done as early as possible in the sprint. It wasn’t on the to-do list either.
A couple weeks later, my feature in the upcoming release was still not checked in, but since my code was more or less done we figured it had to count. That WCF middle tier compiled and seemed to run okay, but the refactoring broke several unit tests that hadn’t been fixed yet. We added “Fix or comment out failing unit tests in WCF” to the sprint after the next one so we could get Phase II in first. The exception I’d gotten from Ellen took a couple of days to fix, because it had something to do with the Razor version we were using and I don’t know that much about Razor. Finally, Jeff’s database changes were handed over to a special meeting of the SQL Developers team, which was eventually going to build a schema repository.
As for rolling out Phase I, well, we had to add a story that simply read “Backfill to .NET 4.0.” The boss said that should only take a day so we assigned it three points. (Each developer was expected to do about twenty points per week, so that seemed about right.) Our scrum master said he’d take care of the test deploy script so it wasn’t necessary to add to the actual sprint. And we added a story (which just said “test”) for the QA department to do. We assigned it one to eight points, depending. And we’re not sure when that backup Windows 2003 server is coming through, but we created a story (“migrate to 2003 server”) for me to do. I don’t have production access but I can probably get an IT person to work with me on it.
The great thing about working in a Scrum shop is that everyone’s super flexible and does the best they can without relying on management to tell them what to do all the time. It’s so empowering!