hide

Read Next

Leading a Scrummy lifestyle: What's often overlooked

In my series about using agile processes not just for software development but in everyday life,  Socialize VP of Engineering Jason Polites has offered up a guest post about what often gets overlooked in software development:Nice post.  I think there are some very basic tenets relating to SCRUM, or agile in general, that tend to get overlooked though.  Actually.. throw out the word SCRUM for a second and just consider what the concept of agile development is saying.

Imagine a situation where Person A has to complete Task X.  It doesn't matter what you do or say before they start, Person A will ALWAYS take the same amount of time to complete Task X.  Whether you are operating a waterfall model, an agile model or some other crazy methodology.. Person A will take the same amount of time to complete Task X.  But what does this mean?

If we have an approach that says "we need X tasks completed by Y date", then we are effectively saying we can predict how long it will take to complete those tasks.  If there is one thing we know with certainty, is that we can guarantee that things will change, and that we can't predict the future.  So, amazingly,  this approach fails every time (amazing not because it fails, but because it's still being used and people still expect it to work).

The reality is that you can't have tasks AND time.. you can only have one.  The tasks will take as long as they take.  We might "think" we can affect this, or we can fool ourselves into believing that we CAN predict the future, but restating the previous, "Person A will always take the same amount of time".

So.. if we accept that we can only have one or the other, how to we effectively schedule anything?  Well fixed dates DO exist (they're on the Calendar ;) ) so we can easily fix a date, but we CAN'T decide on a fixed set of tasks to be completed by this date.  Where does that leave us?  Well logically if we can only have a certain sub-set of tasks completed by a fixed date, then we want to make sure the most important ones are completed by that date.

In my series about using agile processes not just for software development but in everyday life,  Socialize VP of Engineering Jason Polites has offered up a guest post about what often gets overlooked in software development:Nice post.  I think there are some very basic tenets relating to SCRUM, or agile in general, that tend to get overlooked though.  Actually.. throw out the word SCRUM for a second and just consider what the concept of agile development is saying. Imagine a situation where Person A has to complete Task X.  It doesn't matter what you do or say before they start, Person A will ALWAYS take the same amount of time to complete Task X.  Whether you are operating a waterfall model, an agile model or some other crazy methodology.. Person A will take the same amount of time to complete Task X.  But what does this mean? If we have an approach that says "we need X tasks completed by Y date", then we are effectively saying we can predict how long it will take to complete those tasks.  If there is one thing we know with certainty, is that we can guarantee that things will change, and that we can't predict the future.  So, amazingly,  this approach fails every time (amazing not because it fails, but because it's still being used and people still expect it to work). The reality is that you can't have tasks AND time.. you can only have one.  The tasks will take as long as they take.  We might "think" we can affect this, or we can fool ourselves into believing that we CAN predict the future, but restating the previous, "Person A will always take the same amount of time". So.. if we accept that we can only have one or the other, how to we effectively schedule anything?  Well fixed dates DO exist (they're on the Calendar ;) ) so we can easily fix a date, but we CAN'T decide on a fixed set of tasks to be completed by this date.  Where does that leave us?  Well logically if we can only have a certain sub-set of tasks completed by a fixed date, then we want to make sure the most important ones are completed by that date. Enter SCRUM stage left. SCRUM advocates that you have a prioritized list of "tasks" (stories) such that completion order matters, but completion time does not.  SCRUM also advocates that at every definable stage (sprint) there is a viable product.  It may be featureless, but it "works".  There are a few assumptions here: We assume that people on the project and responsible adults, and that "Person A" (from the first example) will work diligently and efficiently We assume that the MVP (minimum value product) may need to more than one sprint to get going.  This is a bit of a deviation from the rules, but is a reasonable one. Now although it's easier to see how this applies to software development vs. anything else, but actually in principle it applies everywhere.  It's just a way of looking at things and accepting that we can't predict the future. You won't know what will be completed by a certain date, but you'll know that whatever is completed is the most important.

Why People Don't Develop Process

On SEBASTIAN MARSHALL

Developing processes to replace routine actions takes considerably longer than just doing the action any individual time.

The first crack at developing processes will generally be unclear, run poorly, and be missing serious amounts of stuff you take for granted, but which are non-obvious for someone other than yourself.

(Heck, it'd probably be difficult for you to run your own first version of the process verbatim without improvising.)

At some point, you have to develop processes to move forwards. If you keep doing the same repeatable work once you've stopped improving at it, you can't move your time up the ladder of value towards higher productivity, higher creativity, and more impactful actions.

But most people don't factor that; they look at raw short-term efficiency, and making processes is almost never a smart short-term efficiency. Long-term? Absolutely. Mid-term? Possibly. Short-term? Probably not.

Rendering New Theme...