We've been using the Scrum agile development framework (or just "scrum") at Socialize since early this year. Hats off to Jason, our VP of Engineering, for really championing it and to Sean and Isaac for implementing it with the developers. Our workflow is to use Basecamp to discuss ideas (Basecamp is like Democracy: it's not great, but it's the best thing out there -- you can read my rants & raves about Basecamp here), then Github for issues & code repository, and Pivotal Tracker to manage our dev process. We do fast iteration cycles with one-week sprints, planning meetings every Monday and daily stand-ups to reconnect.
I'll explain what all that means below, if you don't already know, but here's the point of this blog post: Scrum has worked so well on the dev side -- what if it was possible to implement scrum across an entire company, including its non-development components like user acquisition, sales, even accounting, HR & finance?
We decided to find out. I'm going to write a series of blog posts with our experience implementing Scrum throughout our company, with a focus on the non-development parts of the organization, as I haven't really seen other companies do this yet. I figure this is a good opportunity to share our knowledge and learn from yours, so please post your experiences with Scrum, agile and general, and other workflow approaches in the comments.
In this first blog, I'll talk about what scrum is (at least to me) and show you a video of Jeremia, our developer evangelist, and Christine, our wordsmithstress, discussing the pro's & con's of implementing scrum in the user acquisition department (the first non-dev team we decided to test it with).
There are individuals within our organization that know scrum way better than I do because they're using it every day -- Jason, Sean, Isaac and our incredible developers, for example, and I'll invite their comments. Our goal is to institutionalize this agile mentality throughout the company.
We've been using the Scrum agile development framework (or just "scrum") at Socialize since early this year. Hats off to Jason, our VP of Engineering, for really championing it and to Sean and Isaac for implementing it with the developers. Our workflow is to use Basecamp to discuss ideas (Basecamp is like Democracy: it's not great, but it's the best thing out there -- you can read my rants & raves about Basecamp here), then Github for issues & code repository, and Pivotal Tracker to manage our dev process. We do fast iteration cycles with one-week sprints, planning meetings every Monday and daily stand-ups to reconnect.
I'll explain what all that means below, if you don't already know, but here's the point of this blog post: Scrum has worked so well on the dev side -- what if it was possible to implement scrum across an entire company, including its non-development components like user acquisition, sales, even accounting, HR & finance?
We decided to find out. I'm going to write a series of blog posts with our experience implementing Scrum throughout our company, with a focus on the non-development parts of the organization, as I haven't really seen other companies do this yet. I figure this is a good opportunity to share our knowledge and learn from yours, so please post your experiences with Scrum, agile and general, and other workflow approaches in the comments.
In this first blog, I'll talk about what scrum is (at least to me) and show you a video of Jeremia, our developer evangelist, and Christine, our wordsmithstress, discussing the pro's & con's of implementing scrum in the user acquisition department (the first non-dev team we decided to test it with).
There are individuals within our organization that know scrum way better than I do because they're using it every day -- Jason, Sean, Isaac and our incredible developers, for example, and I'll invite their comments. Our goal is to institutionalize this agile mentality throughout the company.
So what is scrum, really?
To me it's simply a way of thinking about getting things done. There are traditional development models like waterfall development, which (like a waterfall) takes a staged, or phased approach to development. I'm going to abstract "development" into "workflow" for the purposes of this blog, since we're talking about using these models in a larger sense throughout the company's divisions.
The magic of scrum is that it takes time out of the equation. Or to put it another way, assuming you have employees that are dedicated and are working hard, things take as long as they take. You're not doing anyone any favors by setting arbitrary deadlines. "This project needs to be finished by Friday" or "This deliverable is due in 60 days" cause way more problems than they solve. When the team inevitably misses the goals, everyone is disappointed -- the goal setters blame those responsible for stepping up to an arbitrary date, and the implementers resent having a date put on them that didn't reflect reality.
The scrum attitude is that things take as long as they take, so the best thing to do is embrace that reality and instead of setting deliverable-based goals, instead focus on prioritizing everyone's time effectively so the most important and value-added items are being worked on first.
It's a very simple but monumental shift in thought. Things take as long as they take. Focus on what matters.
Here's a video of Jeremia & Christine talking about implementing scrum in the UA department. In the next blog, I'll discuss some of the difficulties we've had implementing scrum in a non-development environment.
>
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.
