We're trying to switch to Scrum as our development process but we're not sure how to implement it in the best way possible.
We also don't want to pay for expensive software tools until we get scrum working and get positive results.
How can we implement scrum using a whiteboard without asking people to write down their time on the board and then also input into our own time tracking software?
What kind of methodologies do you use?
Here is a nice resource resource for you to start with: Implementing Scrum on 10 steps
There is also a really good site with many advices about how to begin with scrum: implementingscrum.com
One way you could easily do the tracking with just the whiteboard is to write your stories/tasks on post-its and also write on them the estimated cost/time. Then you can do your daily meeting near the whiteboard and when developers are talking they write down the real time they have done them.
With this information you can build both the burn up and burn down charts.
How can we implement scrum using a whiteboard without asking people to write down their time on the board and then also input into our own time tracking software?
If you think that this will make it harder to adopt Scrum, then maybe you can lean on your Scrum Master. People can write their time on the board, and the Scrum Master can enter it into the time tracking system.
We also don't want to pay for expensive software tools until we get scrum working and get positive results.
Unless you're dealing with a distributed team, there isn't much need for software tools. Even when I worked on a team that used Mingle, we maintained a physical Scrum board. I think all the other developers appreciated it.
We're trying to switch to SCRUM as our development process but we're not sure how to implement it in the best way possible.
If you have already some understanding of Scrum, then create a product backlog, get a product owner, a team, a ScrumMaster and start using Scrum. Then, inspect and adapt.
We also don't want to pay for expensive software tools until we get scrum working and get positive results.
You don't need to and, actually, I would strongly recommend to start with a whiteboard and post-it notes, especially for an adoption. You need to learn and to master the process and the last thing you want is a tool that dictates the process and gets in the way.
How can we implement scrum using a whiteboard without asking people to write down their time on the board and then also input into our own time tracking software?
There is no magical solution for that (and the intend is totally different). In the first case, people need to do it because software development is an empirical process and requires transparency to be controlled. The burndown chart (that shows an estimation of the remaining work, and not the time spent) is one of the tools Scrum uses to achieve this transparency. In the second case, you need to do it for the only purpose of reporting (which is a kind of waste) but, well, your management requires it (and this time, you report the time spent but Scrum doesn't care of that).
Scrum is about the process, not the tools. Make very sure that everyone involved (not just the development team!) understands what Scrum is about. It's not just working iteratively in 2 week sprints. It's about commitment from management about this way of working. It's about having a very good product owner that can set priorities. It's about being open to each other within the team. Etc. etc. This will take time to learn.
Read Scrum from the Trenches for an easy introduction.
Here is a video describing scrum and how we implement it at Atalasoft, as acted out by stuffed animals and toys.
We do tracking with FogBugz. We create a "release" for the backlog and another release for a sprint. Tasks are entered into the sprint from the backlog with time estimates. The total time remaining in the release is tracked daily in a burndown chart, formerly built in excel (noe in FogBugz) by the scrum master.
I have found the best way to implement Scrum, is using Scrum.
Have a backlog of tasks you need to do to move from your existing processes to Scrum, break these down into a number of 2 week sprints, and implement gradualy over a couple months. this helps people to get tp grips with each process, without bombarding them with new tools.
Initially I would introduce a basic sprint planning meeting, daily standups, and sprint reviews, and keep doing the work using the old methods. Then bring in more methodologies as the sprint continue.
In particular Scrum suggests that each user story should be a vertical slice, with all aspects of the implementation done together to deliver business vale ASAP. Design, development, testing, infrastructure, integration... This can be very difficult estimate, and even harder to achieve. You will only really get this right when you have a rock solid, mixed disciplinery team, and very strong engineering practices. Start by bringing togther dev and unit testing if you haven't already, then bring more parts of the process into each task.
With Scrum, it tells you how to do things, not what to do. Look to XP if you want lots of hard and fast rules. Much of getting a really effective team is working out what works for you. Keep an eye on velocity and see what improves it.
Regarding tools, a white board is great.
BEWARE THE POST IT. These are great for reminders and notes on your desk, but one day you walk into the office and see your beautifully organised sprint as a pile of confetti on the floor. Even the extra strong post it notes dry out and lose their stick after about 2 weeks in a room with A/C. I learnt this lesson the hard way.
Use index cards, with drawing pins and a cork board.
Excel is perfect for working out your velocity and burndown metrics.
We only use tools with distributed teams. Then we use Acunote for it's simplicity. It is really just a virtual cork board.
Track time in your time tracking software. Track story points on your tasks. These are not the same. The recent snow in London and resulting transport chaos, dropped our velocity by 35%, and hence our ability to complete tasks, even though the team was doing more hours with a couple key individuals and clients working from home.
Here's the short answer as to how we are using (and used to use) Scrum:
We currently use an electronic taskboard which is connected to our defect tracking system. The electronic taskboard was implemented by some of our own developers between Sprints. Before that we simply hung huge white posters on one wall and stuck notes with tasks on it.
I agree that the best way to find out how to do Scrum is to actually do it. You should read up on it first, mostly since however easy it sounds it does have a set of rules that I'd absolutely recommend to follow. (If you find that some of them are not working well for your teams, you can still adjust them, but you won't find out until you try them out for a couple of weeks first.)
The brilliant thing about Scrum is that in terms of tools you can pretty much use whatever you got. Whiteboards, walls, electronic tools, whatever. It's very flexible and allows you to start implementing it without having to spend money on new tools or equipment first. If you have a whiteboard, use magnets or sticky notes and you're set. Print out the burndown chart and update it daily by marker and you're done. Use Excel for the product backlog (or whatever else you like). If you feel the need to you can still use other tools later when you have a better idea of what your team needs in term of functionality. (Or you can just stick with the whiteboard and note cards.)
Scrum from the Trenches is an excellent introduction and has a lot of real life examples of how to do Scrum, so I second that recommendation.
We've been 'around the houses' a bit with Scrum tools and I've come back around to thinking that whiteboards and post-it notes are the best. All the project management tools that I've tried, Scrum-specific or otherwise, tend to make your team change their process to fit the tool. Whiteboards enforce the good working practices you are trying to adopt with Scrum without getting in the way.
Be aware though that you'll be putting more work on somebody when you want to produce reports or just track any historical data. For example, calculating velocities has to be done by hand and as well as prior to people disrupting the whiteboards planning the next Sprint. Even then, I tend to agree that this still eats less time than everyone having to wrestle with a tool.
Having the master copy of your product backlog(s) stored electronically is good practice, just keep it simple (e.g. put it in an Excel doc).