The troubles of reaching Sashimi.

Posted in scrum by Kris Gray on April 5th, 2007

Sashimi, in the Scrum religion is a term used to indicate a bit of completed functionality. Yet the meaning of completed in this instance is up to some debate, according to Ken Schwaber an old veteran and founding father of Scrum…

This introduces the concept of sashimi, a slice of the whole equivalent in content to all other slices of the whole. For the Daily Scrum, the slice of sashimi is a report that something is done. “Done” implies accepted engineering practices that indicate that done means coded. Or maybe it means coded, unit tested, checked in, built, and acceptance tested. Either way, there must be a common understanding; otherwise mistakes may be made as various team members inappropriately adapt based on incorrect assumptions of what they inspected. Similarly, the increment created every iteration must be well-defined and similar every time. In Scrum, each increment is an increment of potentially shippable product functionality.

-Ken Schwaber (

So at the end of each iteration, you should have shippable product consisting of the sashimi of the last sprint. If you think about this in terms of pieces of fish and dinner, everything works great, if you think of this as programming the next version of Windows, your not going to have shippable product after a single iteration, does this mean Scrum won’t work for large projects? Or even projects that will take longer then one sprint? Not if we refine the definition of Sashimi.

  • Development Sashimi

This is the amalgamation of all the completed work from the last iteration. This may not be shippable, but you can see the value of the time spent on the iteration, so its important to keep cranking these out. If your sprint is as short as a week, you will have quite a few of these before reaching the all important product owner sashimi.

  • Product Owner Sashimi

At some point you will complete an iteration and the collection of the development sashimi iterations will be shippable. This is the milestone thats super important, up until this point your feature is in limbo and cannot be shipped. Its important to get here as soon as possible, the longer your in limbo you issues and can’t get all the full benefits of the normal scrum process. You can’t shift priorities (as all the previous work is wasted), you can’t ship your active source tree and you have the ability of feature/scope creep.

This seems to imply that you should never do a sprint that you couldn’t get PO Sashimi from, which is highly favorable but impossible for more reasons then I have time to document here. Just keep on the lookout for these stages, and scrum away.

No comments

What is SCRUM?

Posted in scrum by Kris Gray on March 30th, 2007

The Essence of Scrum in 2 small Bullet points.

  • Scrum makes sure that what your working on is what your supposed to be working on.
  • Scrum tries to make sure that everything you need to do is scheduled, and that the schedule is kept on track.

Thats it, you do this whole process, just so that you have to actually do some estimation and planning.

That is it.

No comments

More Noise?

Posted in development,scrum by Kris Gray on January 30th, 2007

Last week Mike Vizdos wrote an article at Implementing that had me scratching my head a little. In this article Mike was arguing that Silence is a symptom of poor communication, and that when team members have conversations over messenger, those that would gain collateral information from the conversation would be shut out from such juicy bits.

One of my colleagues once walked into a room with a new team. When he told me about it, he said something along the lines of, “It was so quiet you could hear the waterfall.”

Think about that last statement for a moment. I’ll stick around.

Welcome back. Good thought break? Hope so.

When *I* hear this statement, I realize a team is probably not working to its full potential.

While not the Uber scrum master Mike is, I don’t think he understands the psychologies of programmers to realize that ambient conversations are going to murder their performance and concentration. When I initiate a conversation with a person over IM that is in the same office, it gives them the ability to multi-task and not be thrown off their process completely.

I’d basicly equate this to trying to program with the TV on. Some of us can do it, some of us can’t, but nobody is as productive with it on, as with it off.

A lot of the rules of Scrum are really important, transparency between client and team, team and scrum master, team and team are super important, but were not the Borg. And there are only so many hits performance can take in the name of transparency before Scrum starts to become a hindrance.

Long live IM!


Our outsourcing is killing us

Posted in development,scrum by Kris Gray on December 28th, 2006

and our company is asking for more.

We’ve been contracting developers and testers overseas, known for the length of this article as Initech. (Wha?) So like I said, we’ve been using Initech for the majority of our support issues, and then using them to make up large portions of our development teams. The former, while a developers dream (never have to fix a bug in released code, holy cow) is eventually going to lead to shoddy quality and less attentiveness on the behalf of the in-house development team.

As a result, Test driven development and even more importantly any real refactoring attempts are ignored by management, and not voluntarily adopted by the majority of the development team. Test driven development will catch the majority of your issues at dev time, and ensuring quality in following builds through the magic of continuous integration. Since we aren’t writing our tests first our coverage is quite low based on our weak testing discipline, but a much bigger result is that we are not performing the third step of TDD, which is Refactor Ruthlessly.

What we’ve got now is a bunch of weakly tested, ugly, smelly code that we just need to mangle enough to produce the functionality we want, without having to worry to much about the long term quality issues.

I know what your thinking, excuses, excuses. Good developers should refactor, they don’t need a reason, they have the motivation to have quality code developed and part of that is refactoring. There are other factors, and since this is an outsourcing rant and not a refactoring rant, I can’t go into those fully yet.

The Initech guys really are talented, I’m impressed by what they can do, especially under the conditions we impose upon them. Yet they have serious lapse in their completeness. Such as jobs being reported as done just being skipped, functionality being skipped, holes in the design going unnoticed all killing us overall.

Our in house development staff is spending a large portion of their time reviewing, fixing, and completing Initech code. Add these extra duties, to the new demands of scrum, we are finding the amount of time we get to actually code is being severely decreased which leads back to in house developers not having the ambition to self impose TDD and Refactoring into their day to day efforts.

Less apparent is the effect this is having on employee moral. You can argue developers ambitions for their work but whatever they are, this process is ruining it. Our code isn’t something to be proud of, our day to day operations are contain less coding and we’re producing less of those glorious features everyone praises us for. Would it surprise you to find out we’ve had some key people leave in the last few days?

I may make outsourcing seem like the root of all evil, I don’t think we need to do away with them, but with our current process, structure, and personnel, we cannot handle the work load given to Initech. They are great tools for supporting our current in house development team, but history has shown that we can’t trust them on a consistent basis. I hope the message can be relayed to the top, otherwise life as an Initech babysitter will continue to suck.


No comments

Lets get a conversation going: Scrum style

Posted in scrum by Kris Gray on December 2nd, 2006

Implementing Scrum has setup a new forum at! I know its kinda empty right now, but I think it’s a really good idea to get this thing going strong, so lets all band together and post our brilliant thoughts. (Or mundane if your not quite as brilliant as I am.)

1 comment

Next Page »