Scrum Outside IT – 1

We are going to share a few key ideas, too quickly, about using Scrum outside IT (usually they really mean outside software development).

Minor point: IT (meaning information technology) is a bit of an old-fashioned concept.  Probably somewhat inaccurate when used at your business.  But, no time to discuss here.

First, Scrum can definitely be used outside software development.  It has been done many many many times already.

Next, to use Scrum in a specific situation, you must take it, add to it, and thereby adapt it to your specific situations.  Virtually always, your current situation does not allow you to use all of Scrum (usually this is NOT good at all, but just a fact).  So, in part you must change the culture over time so that all of Scrum can be used, in a professional way.

Third, every situation (including every software development situation) is different.  So, what to add to Scrum or the tactics of Scrum will vary depending on the situation.  Those thing should be added or should vary based mainly on “common sense”, but the classic expression in the Scrummer-verse is “common sense is not very common”.  This is mostly a way of saying that the culture needs to change significantly (and also in a practical, down-to-earth way too).

Fourth, we always have problems defining the “product”.  For software development, we have lots of examples and rough agreement on how to think about the product.  In other areas, we do not have the depth of experience, so that is still open for new learning.

But, you cannot do far wrong.  Define the product in some way, and then see if that works for you.  You may find that redefining the product will help you.  But by then, you will have more experience with Scrum, and your second definition of product will be much better.  Be aware that even within software development, defining the product can be a problem.

You must define “working product” within a Sprint also.  What will be the small pieces of “finished” stuff that the team and the business stakeholders can inspect and adapt on?  One could also phrase this as: “we need to work out a reasonable DOD for our product.”

So, definitely the Definition of Done will at least be phrased differently than a DOD for software development (but note that DODs in software development can vary a lot too).

Again, everyone struggles with this some. Outside IT you might struggle with it more.

Length of Sprint:  This is still a reasonably contentious discussion inside “regular” scrum. And may be bigger of you.  If you product includes hardware, you may struggle to get hardware revisions in less than 4 weeks.  If you have to have a 6 week sprint (for now), then technically you will NOT be doing Scrum.  But, you might start there, and then later figure out how, or change things to enable you, to have a 4 week (or shorter) sprint.

But, depending on your product, a 2 week sprint might be easy for you.

To me, those are the four biggest impacts.

• how to define product
• what can be delivered in the Sprint
• what’s in the DOD
• what is the Sprint length

There are other things, too.  More soon.

 

« « ScrumMaster vs Agile Coach || Blog Posts about Scaling – 1 of 3 » »