How to Mess Up Scrum, Part 5

This is another item in my ongoing series of “How to Mess Up Scrum.” This time, I turn your attention to…

Overcomplicating the Objective

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.

How the hell does that happen?

The cliche is that projects become late one day at a time, when one little thing after another contributes to a snowballing of delays, but in this case it was more of an ongoing lack of scope discipline. As you’ll see at the end, the reason we had so little scope discipline was that nobody at all was in charge of scope.

First we had to create The Framework, which was kind of an ongoing internal project throughout the company that would purportedly give us easily-consumed services for database access, object mapping, error handling, that sort of thing. Two of our developers pitched into The Framework rather heavily. It might have taken about a month or so, because they had other responsibilities and the scope of The Framework was not so much carved in stone.

Meanwhile, the graphic designer had all the static pages done. They looked cool. He wasn’t assigned to write the copy, but he didn’t want to leave the pages blank! So he improvised something that was actually quite a bit better than nothing.

First lesson here: We may not have had anything at all to show the customer after one sprint, but after two? We had a good graphic layout that should have been integrated right through to the staging and QA systems so the internal customer could a) see that we weren’t lying about getting stuff done; and b) give feedback as early as possible. We should have brought that to the Sprint Demo, made sure that particular stakeholder would be there, and gotten feedback immediately. (The feedback did come, just much later, and it meant the designer had to rewrite a lot of the static HTML a week or two before release.)

Once The Framework was done, we needed to develop the Data Access Layer (DAL) so we could have lots of juicy data modeling built into the services side of this web application. I wrote a big chunk of that after a prior contractor started it. I got to make a massive simplification by using C# generics instead of forcing the consumer to hardcode a bunch of database column names, yay. What a great example of Don’t Repeat Yourself!

We couldn’t work on the DAL until The Framework was done because nobody ever defined the interfaces. Dependencies.

About three times after that, the two developers who had been doing most of The Framework reported into the standup meeting to say they didn’t advance any actual story cards because they were “refactoring The Framework.” Truly, The Framework’s interfaces and semantics remained the same, and they probably came up with better implementations as they went along, so it wasn’t for nothing–but it also wasn’t part of any Sprint goal.

Anyway, while that DAL was in development we had to have a Business Layer behind that MVC Controller, to do all the business logic behind a contact form. Sorry, I’m not sure how much business logic there is to stashing one thing in a database. But dogma. You must separate the business logic! Even if there isn’t any! It also had to be injectable, just in case someone needed to substitute in a different set of business rules later. Thus another dispatching layer in the call stack.

This is when I pointed out that at least the decoupling of the interface gave us a way to unit test the business logic. I made sure to include those tests; I noticed a few weeks later that someone had commented them out when they indicated a broken build.

Once The Framework and the DAL and Business Layer were done, the “client side” person got to write all the MVC Views. Now the Views were populated by DTOs: Data Transfer Objects. We couldn’t pass instances of the abstract Models back because that would “break encapsulation.” Thus the DTOs were more or less hand-copied from the Models directory and dressed up with a few custom Attributes. “We can’t change the names of the fields,” said the client side person, “because I’ve already hard-coded them into the Views.” Yay for loose coupling!

Long Story Short

I’m deliberately highlighting the excess work that went into this product. A lot of stuff went really right too, but still? Six months for really just a “contact us” page?

We can criticize the architectural overkill and “refactoring” here, but the underlying issue is that none of the above story is customer-driven. We did not have anyone from “retail” asking for mockups. We didn’t show them the output of iterations. We weren’t even super clear on what information they wanted to show their customers. Honestly, what we knew was that we were to “do a retail portal, but no product sales until version 2.”

Executive Antipatterns!

As I develop this series on “How To Mess Up Scrum,” I’m seeing a stronger pattern: the biggest Scrum failures come from lack of leadership. I’m calling these failures “Executive Antipatterns.”

This particular Executive Antipattern is closely related to not having a Product Owner. Scrum itself relies upon having a single Product Owner, a person who represents the customer’s interests and can make decisions on behalf of the customer. No Product Owner? No product.

Stay tuned for more Executive Antipatterns and more Ways To Mess Up Scrum.