scrum – Virag Consulting

Just Enough Estimating

Software developers hate to give estimates, and they’re generally bad at it. I can say this because I came up as a developer, and I understand the attitude. We’re wired to dig in and fix problems, not sit around characterizing them. This is one reason we like to code at night. If we finish early, we’ll go to bed. If not, we’ll just keep coding.

Accurate estimating is a serious challenge for managers and scrum coaches. Ironically, it was less of a problem back in the waterfall days. Longer development cycles meant more risk, so we put more effort into estimating. Also, bigger chunks of work meant that an underestimate on one task might be offset by an overestimate somewhere else.

GMAT data sufficiency questions are surprisingly sophisticated, and most students do not truly understand the game or leverage all the hints present in these complex problems.

Contract development firms would live or die by their estimates, so they developed elaborate quantitative tools. See my earlier post on agile development.

This challenge, sizing up a problem without actually solving it, is a testable cognitive skill. I am referring to the dreaded data sufficiency section of the GMAT exam, which is cleverly designed to kill you if you try to solve each problem. The skill is to work each problem only far enough to determine the data requirements. Here’s a sample:

A dealer offered a service contract at a price that would gross 40 percent over cost. Which, if any, of these facts is needed to determine the dealer’s cost: 1) After reducing his price by 10 percent, the dealer sold the contract at a profit of $403, or 2) The dealer sold the contract for $1,953.

Sometimes, “we don’t know anything until we know everything.” Every piece of the puzzle must snap together. This is true of the development phase, but not estimating. Making decisions under uncertainty is the theme of most management training.

The diagram above is the ne plus ultra of data sufficiency problems. I found it, not on a test-prep site, but on Twitter. If you’re handy with geometry, you’ll notice that you don’t have enough measurements to fully determine the shape. You can’t compute its area, for instance.

But that’s not the question! Even though the exact shape isn’t fixed, the length of its perimeter is. This is a great example where you don’t need to know everything, to know the answer.

Software Development at RumbleOn

I have some jobs open right now and I am also busily documenting our Software Development process for the auditors, so I thought this might make a good blog post.

The magic starts in our Product Management department. We treat all our software as program products with roadmaps, features, and release plans. This includes our internal operational systems as well as omnichannel retail. I have long been a proponent of this approach, even for APIs.

Our vision is to have an integrated pipeline from the survey portal all the way to deployment.

Artifacts like requirements, concurrence, priorities, and customer feedback are maintained in Aha! Roadmaps. Product Management is also design driven, but I digress. This post is supposed to be about Software Development.

Software Development includes four agile teams. Most of the staff are here in Dallas, with some work offshore in India and Eastern Europe. See my post on sprint planning with time separation. The teams manage their work with Jira.

Jira synchs in both directions with Aha! Roadmaps, and will soon synch with Circle CI for deployment. Our vision is to have a seamless pipeline from Aha’s survey portal, through feature planning, all the way to deployment. For omnichannel retail, we add feature flagging. We are not quite to the point of doing statistical testing and audience segmentation, but we’ll get there.

Agile teams manage their own deployments and feature branches, but releases are coordinated with Product Management and moves to production are regulated by the Architecture team. This is designed to be a choke point for secure change management. The Architecture team also maintains a reference library of artifacts for standardization, like federated identity.

If you’re interested in managing one of our agile teams, here is the link. Work is onsite in our Dallas location, corner of MacArthur and 114, convenient to fine dining and Sunstone Yoga. The facility is urban industrial, with terrazzo floors and exposed béton brut. No remote work, sorry. That’s so 2020. As a manager, we’ll need you onsite.

We are looking for local talent, preferably Texans of the DFW variety. This is to avoid relocation challenges. There is also a certain corporate culture that comes from selling 80,000 street bikes, dirt bikes, and ATVs each year.

RumbleOn does not discriminate on the basis of race, sex, color, religion, age, national origin, marital status, disability, veteran status, genetic information, sexual orientation, gender identity or any other reason prohibited by law in provision of employment opportunities and benefits.

Cost Accounting with Scrum

Here is another in my occasional series on the finer points of scrum. See also Sprint Planning with Time Separation. Cost accounting seems inimical to scrum, philosophically, and also infeasible. We use story points for a reason, and then we let the team discover its velocity through experience. Neither of these numbers is readily convertible into dollars, but that’s exactly what we’re going to do.

If the latest sprint delivered 70 story points, those points are worth $402 each.

Our goal is to calculate how much was spent to develop a certain feature. This can be to support a cost-benefit analysis, to track development as a capital investment, or to claim an R&D tax credit.

The team’s velocity is the number of story points it can complete in one sprint, typically two weeks. Velocity changes from one sprint to the next, but the key is – we know the velocity of the most-recent sprint, and that’s the one we need to account for.

We also know how much it costs to run a sprint. Let’s say that we have a seven-person scrum team with an aggregate base salary of $677,500. Adding an 8% burden rate and dividing by 26, we calculate that the cost per sprint is $28,142.

So, if the latest sprint delivered 70 story points, those points are worth $402 each. Now, let’s say that two capital projects absorbed 65 of the 70 points, plus a stray five-point story that fixed a bug or something. It was a regular expense. Here is the cost allocation:

It’s easy enough for the scrum master to load these figures into an accounting system at the end of each sprint, but it does require each user story to be tagged with the project it represents. If you’re using Jira, it’s best to group the stories into epics, which represent new features, and include the capital project identifier (i.e., an account number) on the epic.

Sprint Planning with Time Separation

Here is a short post on a practical problem for my readers who use agile. My client is in Dallas, and most of the developers are in Poland. That’s a seven-hour time difference. We have enough overlap that daily scrums are not a problem.

“What I’m fixing to do today,” in Texas, comes at the end of the team’s workday in Poland. This is a little weird, but not a problem. Sprint planning is a problem.

With everyone in the same time zone, I like the rhythm of closing the sprint on Friday, doing the review, and then sprint planning on Monday. If your idea of “sustainable pace” includes working weekends, the team gets that weekend off. Then, we start Monday with a fresh scrum board. This is probably everyone’s favorite rhythm, if you have the luxury of cotemporal teams.

By the way, I write “cotemporal” here instead of “collocated” because it’s the time zone that matters, not physical distance. I know of at least one F&I company based in New York with developers in South Florida (an F&I “tech cluster” thanks to AutoNation and JM&A).

Replacing the initial eight-hour session with two separate four-hour sessions conducted over consecutive days is more practical.

With widely separated time zones, the problem is that you can’t leave the scrum board empty. Unless the next sprint is planned immediately, one team or the other will have a day with no work. So, we have adopted what Mike Cohn calls the two-call method. The quote above is from his book, Succeeding with Agile.

We close the sprint on Friday, do the review, and begin sprint planning with the Dallas cohort. We have the scrum master here, the product owner, and the lead developer. So, that’s a quorum. The downside is that the Polish team misses the initial discussion of the sprint goal. Cohn lists pros and cons in the book.

Relating the big picture falls to the lead developer, who conducts a second session on Monday during the overlap period, and develops the sprint plan. This approach doesn’t allow much debate over scope, so it places a premium on good stories with good estimates. For more on agile, read my post Sales Driven Development (or buy Cohn’s book).