Scrum apposes the hierarchical approach that many project management techniques subscribe to.
Instead, a Scrum team trusts and relies on each other to provide help and advice. A Scrum team takes collective responsibility for a project and we trust each other to do the best work possible. If a mistake happens, then the team will rally around to collectively solve the problem.
I've had lots of conversations with people about Scrum. After an hour of me trying to explain the whole framework, I usually see confused faces staring back at me. So, instead of doing that, I thought I'd explain some comparisons between Scrum and a traditional project management process (waterfall). I'm not going to go into the advantages or disadvantages of either, but hopefully you'll see a few reasons why we practice Scrum at Fudge.
The same goes for designers/developers.
At Fudge, we trust everyone to do the best they can. We also trust them to tell us how long they think something will take, and how difficult it’s going to be.
Something that we try to avoid, is putting pressure on our teams to deliver more than they think is possible. It doesn’t matter how loud you shout, if something’s going to take a long time, apart from assigning more resource to the task, there isn't much you can do about it.
We also try (unless it’s life of death), to keep our working days at a reasonable length. Forcing people to work an extra three hours a day, isn’t going to result in an extra three hours of quality work.
At Fudge, the days of the “hero programmer” ended as soon as we implemented Scrum (Google it). We don’t want people to grudge coming to work because they had stay late the night before. They won’t be motivated and they won’t be productive.
Here's a description of the type of situation we used to end up in: Hero Culture.
Instead of this, we help our teams to deliver as much as possible while keeping standards high. We do this by investing in time-saving techniques, tools and technologies. We try out methods of working to see their effect. If it works, it stays, if it doesn’t we adapt and try something new.
If you want to get more out of your team, help them to work smarter, not longer.
If you trust your team to tell you the truth and deliver to the standards you require, you’ll have a happy, productive bunch of people.
There are lots of apps out there designed to digitise the day to day activities of Scrum. Some are good, some are definitely not good.
One thing that I've noticed is that almost all of them try to replicate and replace the use of physical artefacts. Traditionally you'd see things like story cards pinned to a wall and a burndown chart (sometimes hand drawn) somewhere near your team. I'll use Nigel Baker's (AgileBear) term and collectively call these assets your "information radiator".
I think that replacing physical assets completely, in favour of storing them in some kind of application is a bad idea.
Here's why.
Removing this information from your physical space reduces the need to communicate verbally. This is definitely a bad thing. Relying on email or on communication through some other tool slows down problem solving. I guarantee a discussion will resolve a problem quicker than an email conversation.
A new team, or a team new to Scrum should be encouraged to communicate verbally. Given the opportunity to fall back into the old routine of emailing, waiting for a reply and then trying to decipher the response, slows down the process of decision making. So, is there a need for a digital alternative to physical artefacts?
Yes, in some cases.
At Fudge, we often work with product owners and team members in different countries and time zones. It isn't possible to have a single physical location for this information. What we do instead, is replicate the physical space in a digital format. We keep these two synchronised and distribute a revised digital version regularly, so that regardless of location, a team member knows what's going on.
Like I said, there are good and bad apps to help with this, but I won't mention either, other than Glu, a product we're working on at Fudge :-)
A few months ago we put together some processes and tools that we'd been using in isolation (mostly). We like what it gave us, and you might too. Ruby on Rails and Linux hosting (from Brightbox) are our tools of choice, but I'm sure the principles will translate to other technology.
What we were aiming for, is a way for the team to keep working without having to manually update issue tickets, deploy the app or tell the team that features are ready to be tested. Instead, they can just keep coding.
I doubt this is news to anyone, but setting up a staging version of your project is massively helpful. It will help you isolate progress that isn't production ready and acts like an air-lock, allowing you to check and double check a feature/change/bug-fix before it's pushed live. Your product owner/client will like it too. We use Scrum so changes are welcome and frequent. Having staging versions of our applications lets the owner test and refine before anything is shown to the world.
We like to use the master branch of our repo as the deploy point for staging. We have a production branch which is updated with production-ready changes when they're ready to be pushed live.
If you're not using a version control system, you should be. We use Git, because it's amazing. All of our project source code is hosted with Github. Again, it's amazing.
Using a combination of a Sinatra app called Pushr and Github's post-receive hooks we configure our staging version to automatically deploy, whenever a change is pushed to the master branch of our repo. This helps in a few ways:
There are lots of good issue trackers out there (Lighthouse, Sifter etc..). At Fudge, we use a tool called Glu. It's our own product that we'll be releasing at some point this year.
A few, specifically Lighthouse (and Glu) integrate with Github. When a push is made to the repo, the issue tracking app is informed (through a post-receive hook) and tickets are automatically updated.
Here's an example:
So, if your issue tracker of choice supports this, you're in good shape. Not having to manually update a ticket after it's been worked on saves a massive amount of time. Seriously.
We use a Rails plugin called CapGun. It integrates with Capistrano (used to control deployment). Whenever a deploy takes place (keep in mind we already automated staging deploys with Pushr), an email is sent to everyone on the team. This email lists all of the commits that were included in that deploy. It's incredibly helpful during testing/QA.
I'm Scrum Master on most of the teams at Fudge, so for me to be told about progress on staging like this is awesome. I don't have to keep asking where tickets are up to and asking people to deploy. I get a nice email whenever this happens.
This might all seem a bit complicated, but a few hours spent configuring this at the beginning of a build saves hours later on. The point of this is to let people build, test and refactor without having to worry about deploying, updating tickets or letting the team know about the status of the staging site.
Obviously the tools I've listed aren't the only options, but if you're using Rails they're a good start.
