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.
Sean, awesome thanks for sharing these resources. I'd love to hear from anyone that has given this a shot in non-dev environments.
Sorry, Just saw this blog now....
As we implemented Scrum we found ways to tweak the concept to get even more value and efficiency out of it.
Here are some blog posts I made at the time to explain:
To get to where we are there were three primary parts:
1. Get to a level of confidence and have running metrics on our output
2. Having confidence allows you to focus on completing tasks instead of fixing them. At this point we started making the time to develop, sync up, and deploy as short as we could. This was done by Making things as asyncrnous as we could. Avouding mid week or adhoc meeting becuase 1 person has a question
3. Making Short Cycle Scrum so that everything is borken up in tasks that are able to be produced and tested in less then a week. And with that, knowing that no "mistake" can be more than a week of "badness". This allows everyone to start making descisons fr themselves, the best they can, and then disucssing it in the beginning of next week.
With those aspects you can apply Scrum well to all parts of biz. Design, copy writing, marketing or development religiously make an effort for the following:
- Have a metric to determine what success looks like across your mission
- Make those metrics easily definable and brainless to re-apply
- An ability to break up tasks into its atomic structure
- Removing the need as much as possible, to "check-in" or "ask for guidance" in any way that holds up output
Also, here are some free docs we read as we developed our process:
"Scrum in Five Minutes" : http://cl.ly/221W3r3a0x1Y1b380R1A
Google's Scrum tuning video: http://video.google.com/videoplay?docid=879521430...
Fundimentals Library: http://scrumfoundation.com/library
(continued from above)
So what typically happens, is the developer (or group of developers) starts making guesses about the answers to these questions based on past experience and personal bias. Or if they're lucky, there will be a detailed project plan laid out that covers some of these answers and how long those things should take.
But inevitably, the project falls behind (and by "falls behind" that assumes the March 1st date was the perfect date to begin with, which is never the case -- it's typically an arbitrary date, like "I'm getting featured in a magazine on March 2nd, so this has to be done by March 1st. I.e., the project delivery date has very little to do with how long the actual project takes to get done.)
So what to do? You could try to anticipate what all the things are that you'll need to get answers to, and come up with all those answers up-front.
Or, you could use an agile approach.
Let's say this is October, and "the website" needs to be done by March 1st. You can define "sprints" or periods of time where certain chunks of value are to be delivered. Let's say you pick 2 week sprints. So now instead of October vs. March, instead you have 10 sprints between now & then. So it's no longer about delivering a certain result by an arbitrary date, but instead about prioritizing the next 10 two-week blocks of time as effectively as possible to drive maximum value.
So you start with a bunch of ideas. Those ideas are given from the stakeholder's perspective, as "stories." A story might be, for example, "as a user of 'the website,' I can register and edit my profile.' Another story might be 'as the owner of the website, I can see and edit all user profiles.'' These stories would have some level of detail to them as well, explaining them. But they're always about a quantifiable amount of value-based output (if there's no specific value to the stakeholder, then they're called "chores.")
So you start by listing all the stories that matter to you -- but you're focusing on the value-based output. By focusing on the output, you're letting the developer decide how to do the actual implementation.
We use the tool Pivotal Tracker to track and prioritize and score all the stories and chores. This also works well when someone says "hey I have an idea for 'the webiste.' Can it do..." Just have them write up a story and put in the "ice box" Then, when you're doing your planning for the next sprint, you can break out all the ideas in the Pivotal Tracker ice box and decide which to prioritize and score.
The scoring system we use is a Fibonacci sequence, meaning each story has a complexity score of 1,2,3,5 or 8. (The actual score doesn't matter, just that scoring is applied consistently across stories).
At the beginning of each sprint, you prioritize all the stories in a backlog based on what value is most important to accomplish for a project like 'the website.' Is user registration more important, or is an API more important? Etc. Each story has a score, and Pivotal Tracker does a nice job of bumping the backlog into current work to be done based on a team's "velocity" (which is the average of the number of points they were able to complete in previous sprints).
So basically, the idea is that you end up with your team always working on what's most important and most value-added next. And it may turn out that you get 'the website' done in 5 sprints or in 50 sprints. But it doesn't matter, because they're always working on the most important stuff at any given point in time. So if March 1st rolls around and you only have half of 'the website' done, you'll know that it was the most important half that got done, and that since the team worked on the most important stuff first, there's no way they could've achieved any more optimal of an outcome no matter what arbitrary date you originally set for them.
Well, at least all of the above is *my* understanding of Scrum; I'd love to get Scotty's take on it, and I'll also invite others to comment as well.
In a future post I'll get back to writing about how we're working to implement Scrum in a non-development environment; lots of learning there too.
Hey ScottyMo, didn't know you were doing Scrum, let alone a ScrumMaster. That's awesome. Now we're talkin' -- very glad to have your perspective added to the thread.
So here's my thought for Frank -- I'd really like to get your take on this:
Frank when you say "tasks without deadlines just drag on forever," that's exactly the thing that a Scrum-based approach keeps from happening. Or to put it another way, approaching a project with a Scrum-based mentality completely wipes that problem out. Here's why:
We often start working on tasks with an arbitrary deadline. For example, you might say, "I need to have this website done by March 1st." Then, a developer gets to work on delivering "this website." But what does "this website" mean? What does it do? What features does it have? What does the UI look like? How much load is the website meant to handle? How redundant does it have to be? What are the SLA uptime guarantee requirements? What back-end database and architecture should be used? Does the data going into the website need an API so it can be easily extracted and shared? How will you handle user authentication? The list literally goes on and on.
I'm definitely interested to see how it shakes out... I've been on Scrum teams for almost three years now and am a certified ScrumMaster (not sure how I feel about having a certification with "master" in the title, though... ;).
The short answer: Scrum is a project management technique. And although this blog post talks about things just taking as long as they take, don't set arbitrary deadlines, etc. it's not quite like that... it's more about having a process that encourages you to acknowledge reality and only commit to work in small, sensible chunks (Scrum iterations are usually 1 to 4 weeks long), relentlessly prioritize the backlog of things to be done such that you are always working on the highest-value stuff, measure your pace, regularly reflect on how to do things more efficiently or with higher quality, and repeat. If you need to make some commitment further in the future than your iteration length (ie "we will deliver version 2.0 on July 1") you have to do it with the knowledge that if you want the deadline to be firm, it's possible that some features may not make it into the release.
For software development, especially for new innovation with a lot of unknowns, Scrum is often an effective way to manage projects so you build the right thing (ie. what the market needs) without burning out your team (which will often happen when you try to commit to long-term, hard-and-fast deadlines... because in long-term planning situations, people almost always underestimate how long things will take to do).
I don't get if Scrum is a software or a concept?
I found that tasks without deadlines just drag on forever.
I've written before about our challenges using Basecamp as we grow. To me, Basecamp is akin to Democracy: It's not great, but it's the best thing out there. (If anyone knows of better project management solutions, please post them as comments on the other thread -- Basecamp is getting very long in the tooth and while I'm hoping for a significant overhaul, I'd switch to something else if I could find another solution that addressed our pain points, as 37 Signals hasn't given any indication that one is coming.)
In response to a comment on that post, I'm posting below the "How To Basecamp" guide we've created for our employees. This guide was created by Christine, our Wordsmithstress at Socialize, so thank you Christine for putting this together.
Note: there are some videos & screenshots in the internal document we use that are private and aren't in here. I've done my best to replace them with blurred out versions.
I've written before about our challenges using Basecamp as we grow. To me, Basecamp is akin to Democracy: It's not great, but it's the best thing out there. (If anyone knows of better project management solutions, please post them as comments on the other thread -- Basecamp is getting very long in the tooth and while I'm hoping for a significant overhaul, I'd switch to something else if I could find another solution that addressed our pain points, as 37 Signals hasn't given any indication that one is coming.) In response to a comment on that post, I'm posting below the "How To Basecamp" guide we've created for our employees. This guide was created by Christine, our Wordsmithstress at Socialize, so thank you Christine for putting this together. Note: there are some videos & screenshots in the internal document we use that are private and aren't in here. I've done my best to replace them with blurred out versions. About Basecamp: Basecamp is a project management tool created by 37signals that creates an accessible digital trail that email can't. There's a bit of a learning curve with Basecamp, but you'll soon get comfortable with the system the more you use it. Once you've made an account, to access Basecamp, you can login at http://[your_domain_here].basecamphq.com. We recommend that you bookmark your to-do page (and choose the timeframe,this week, today, in the past, etc.,that works the best for you). With that bookmark, you'll always enter Basecamp through the view that's most important to you: all the tasks you have to do! Keep in mind that Basecamp will remember your navigation. What does that mean? Well, if you were previously looking at Christine's to-do's for the week, the next time you click on "To-Dos" on the Basecamp navbar, you'll see Christine's to-do's. You can navigate out of this view by changing the parameters in the right hand corner. Keep in mind that Basecamp will also remember your navigation through projects. To switch out of a certain project, you can click on "Switch to a different project" to change project views or head back to the dashboard to shake it clean (y'know, like an Etch A Sketch). Organization: Sometimes the terminology can be a bit confusing. Here's a rundown of Basecamp's different levels of organization. Dashboard: The bird's-eye view of Basecamp. From here you can see what everyone is working on and access a list of projects you're privy to (right-hand column). Keep in mind that your activity will show up on the dashboard view, so people will be able to see your comments and such. Projects: Sometimes pertaining to a specific department, projects are a high-level view of the big columns that prop up Socialize, Inc. Since these often coincide with the organization of the company itself, they should be created sparingly,think of projects as very broad and large-scale. Milestones (now part of the 'Calendar' tab): A mid-level view of department goals. These are what we'd call "projects" outside of the Basecamp world. For example, an in-house Socialized app launch would be a milestone. Every milestone should have a due-date and an owner, even if the due-date is an arbitrary date two years out. To-Do Lists ("Buckets"): A lower level view that breaks down what needs to happen in order for us to reach our milestones. If we're launching the Socialized app, one bucket could be "Generate Buzz." To-Dos (these live inside the To-Do List buckets): The micro view, all the little steps you need to accomplish on a (usually) day-to-day basis. A to-do can only be assigned to one person as a time. Under the bucket "Generate Buzz," we might task Jeremia with demo-ing our Socialized app at a tech schmoozing event. To-Do's 101 To-do's are the building blocks of Basecamp's project management system,these are your day-to-day tasks. If you would like someone else to take on a task, you must create a to-do for them. The task creator is responsible for making sure the task is created properly. The to-do must fulfill the three following requirements: (1) it is a separate to-do (not a comment in another to-do/task), (2) it has an owner (the person responsible for accomplishing the task), and (3) it has a due date. If you task someone in a comment thread of anothe rto-do, they will not be able to find this task under their to-do list. Create a separate to-do (and even link the original conversation) so that they can easily find the task. To create a to-do, you must be within the desired project. From the dashboard, find the appropriate parent project. From this page you can either add a to-do to an existing to-do list or create a new list as the to-do's home. Sometimes, a task is ongoing and has no real due date. In this case, the task can become a to-do list or it can be labeled as ongoing (e.g. "[O]" as a type of recognizable nomenclature). Try not to use the messages functionality, as for some reason Basecamp implemented messages in a way that doesn't allow people to be added/removed in later comment threads-- very annlying. Ideally, you want to-do's to be both measurable and actionable. Meaning that it's hard to measure the success and endpoint of a to-do like "comment on blogs",a more quantitative to-do would read "comment on 5 blogs" and be dated for a week away. It's possible to hack the system a little bit. Basecamp is great for managing various deadlines and tasks, but sometimes you want a repository for suggestions or ideas. 37signals offers other tools for this purpose (like Campfire), but you can manipulate Basecamp for this purpose as well. Create and designate a to-do list for messages and ideas. As these items become actionable, they can be dragged into a different list to become real to-do's with owners and dates. Tl;dr? Here's the basic gist: 1. Task creators are responsible for assigning the to-do on Basecamp. 2. Don't task someone in a comment. 3. All to-do's need a owner and a date. 4. Don't use the messages functionality. Searching It can be hard to search on Basecamp, and there's no advanced search option/filters either. This video is an overview of searching (spoiler alert: use shortcut Cmd+F to help you find the keyword in question).We suggest searching through projects (rather than across all of Basecamp) to narrow down your scope. And, you know, you can always admit defeat and just search through your email as well since Basecamp will always email you when you've been tasked or included in a comment. Tips and Tricks If you're using Google Apps, add their Google ShortLink Labs feature so you can make short links (e.g. "go.getsocialize.com/mother" to access The Mother) to frequently used Basecamp buckets, to-dos, etc. "Tag" a bucket or to-do with unique keywords to facilitate searching. For example, tag a website-related task with "Charlotte" (get it,Charlotte's Web?) so that you can search for that keyword rather than the ubiquitous "website." When something is marked "private" in Basecamp it means that it's private to your company (i.e. ALL of Socialize, Inc. employees). It does NOT mean it is private to only the people active/included in the bucket list. Tired of checking off 5 people's names every time you make a new comment on a task? Create an email distro list for that team and grant Basecamp access to that email address. Keep in mind, though, that tasks should be assigned to individuals and never to a distro list. FAQs If a milestone has a due date, then does every task also need to have a due date? Or if a task doesn't have a due date, but is in a task list that has a related milestone, do we just assume the corresponding task is due when the milestone is due? Every task needs a due date. Why? Tasks are the little steps we take to reach a specific milestone. Sometimes, tasks need to be completed in a certain order. Because Basecamp offers several levels of organization, you may see or access the task without seeing the milestone due date. Adding that due date will ensure that you can keep yourself accountable to getting the task done on time. Do you have other tips on "How To Baescamp?" Please post them as comments below. I'm especially interested in any 3rd party services that address some of the main pain points we've been having.
This is a series of articles discussing the best pieces of Scrum. The pieces you - as a developer or Project Manager - can steal and start using independently of a wider Scrum implementation. We'll discuss which bits of Scrum you can rip-off without drinking any of the Certified Agile Consultant Kool-Aid - in short, we'll be looking at how to do Scrum for small teams and startups.
Scrum is a business process, and like any business process, it sits between you and the work you need to get done. If it doesn't help you get that work done more effectively it's a big waste of time. Good developers, like everyone else, hate having their time wasted.
Scrum is often implemented by someone who went on a Scrum Master Certification (NOW 90% MORE AGILE™) once, and is attempting to implement it as a set of cargo-cult rituals in the wild hope it'll make everything better, and more Agile or something. Sometimes this'll be a Project Manager, and sometimes this'll be someone billing their consulting time as a Scrum Expert. Planning sessions become elaborate Arts and Crafts sessions with Post-Its and Sharpies, the Product Backlog becomes time sheets by any other name, and Velocity gets used as a personal productivity measure.
In short, in the wrong hands, Scrum becomes a tool for wasting developer time, and neatly tracking, graphing, and reporting the resulting drop-off in productivity.
This is a huge shame, because done right, Scrum protects and empowers developers. It pushes commercial and business considerations back in to the hands of the business and the customers, while placing implementation decisions back with the developers where it belongs.