People are always resistant to change, and moving to scrum is a pretty big one. Motivation and direction are key.
My group has recently grown in size with the addition of several teams from different projects. We work using an Agile programming methodology: 2 week sprints, deliverable every sprint, 2-3 pushes to production every sprint for each team. A challenge we face is to "convert" the newly added teams to this methodology and way of thinking with as little trauma and resistance from the members of these teams.
The first step is to get people motivated to give scrum a chance. Start with people who you feel will be receptive to the change whether they are developers or managers, so you can build some momentum. Getting managers on your side going to be a necessity at some point, but how you handle that depends on your environment.
After that, everyone needs to be trained, whether it means reading a book or having a lecture series. Unless people know how scrum works, you cannot start trying to implement the process. They won't "get it" right away. That doesn't matter -- explanations don't really help as much as simply doing it. Get them started with daily standups today. Immediately. No waiting around. No "conversion". Just start.
Agree to just one sprint to get started with a reasonable scope of work. They'll completely mess it up, but that's okay.
The best way to learn Agile methods is to just start doing Agile methods.
Here are 6 practical tips that may help you out
- First get management backing. If you don't nothing else will make up for this one.. If the upper level is all 'The deadline is yesterday..', 'Working weekends for the next 3 months', 'Why are you writing tests when you should be coding?.. we can test later.' The dodo simply won't fly.
- See if the culture of your organization is suitable for agile. This was something I missed.. To borrow a line from the book.. The process will be easier-faster if the culture supports and nurtures new ideas, allows time for people to learn and do new things, is patient enough to support innovations with long term benefits and does not consider failure to be a death sentence
- The People: Identify the innovators : early adopters : early majority : late majority : laggards ratio. The first 3 are your target audience initially.. should be around 30-40%.. that gives you the critical mass to get rolling. The trouble is Agile turns the spotlight on the elephants in the room.. deficiencies and issues become easily visible.. if you live in a place which has had a "Bozo Explosion" (to quote Guy Kawasaki's term), the change would be really slow and painful.. if at all. We have a tendency to assume that if an idea is good, it'll be accepted. Not true. Lots of sociological reasons raise their heads.
- Next don't try too many things at once. Take it slow.. take it easy. The trick is to use a refactoring-legacy-code-like approach. Find little wounds here and there and patch them with an agile bandage. Make sure that the people understand the practice and benefits and they should adopt them over time. Not everything will stick but soon it becomes better on the whole. How soon depends on a number of variables some of which are out of your control.
- Its a huge personal investment to make this happen. Re-examine if you are willing to make this committment and go through the ups-and-downs it brings. Also you may have to hand over the baton to someone else or a higher up.. Be prepared to relinquish change ownership for the greater good. Don't fall into the 'Its my baby' syndrome.
- Agile is different for each team, each organization. Not everything you read/propose will work.. let acceptance guide you towards the things that will work for your scenario. Find other ways that compensate for the practices that didn't take root.
You can't heal what you can't feel
Building trust with you team members and keeping them motivated is of utmost importance. Once people are motivated and have an idea of what they need to do, you need to have your first planning meeting and set up the necessary parts of scrum (scrummaster, daily meetings, etc.).
I would expect that the first planning meeting will not go smoothly, and will be a learning experience for everyone. Also the first few sprints will be very rocky, and probably behind schedule. The key part now is discipline and persistence. Do not let daily meetings run too long, keep the planning meetings on task, and make sure everyone is doing their roles correctly. With past successes and having the trust of both your team and your manager, they will look to you when it comes time to make decisions.
Lastly I'd just say be very empathetic. I made the mistake of dismissing most ideas before I'd really though them through because I didn't read about it in "XYZ agile book." Listening to your team & trying to implement some of their suggestions will go a long way.
Agile for small teams of 2-3 people
If you are a very small team of 2-3 people, you sure can use certain agile principles in your projects, you don't have to use scrum, use whatever will work best for you. You can definitely benefit from some of XP methods and some scrum practices. But probably not "by book", 1-2 person team is just too small even for that little overhead scrum brings, start with what book says and then drop whatever you'll feel irrelevant after some time. Just don't drop retrospectives, it sure is worth the time spent discussing the problems you have, and finding solutions for them.
Agile techniques are suited to smaller teams as with larger teams it becomes more difficult to manage communication. With 1 or 2 people developing a project (and a customer) you should be able to work in an agile manner very easily. i suggest you read the agile manifesto as a good start to agile. For scrum, I'd suggest you look at Scrum from the trenches. Kanban seems to be in fashion now and there is a personal Kanban too!
Agile for the Solo Developer
Here are some tips to implement Agile processes for the solo developer:
- By doing test-driven development
- By developing in small sprints, maintaining a sprint burndown and a product burndown - A sprint burndown starts with a list of all tasks you've decided to complete in this sprint (a subset of your product backlog to be completed over a set period of time - e.g. 2 weeks) along with the estimate of the work required. As you mark things off, you mark them as done; thereby reducing (or burning down) the remaining work for that sprint.
- Similarly, a product burndown tracks the remaining work for the whole product backlog
- By having a lot of contact with the customer
- Keeping a product backlog - A product backlog is basically a list of all items you intend to complete at some stage for this product.
- Adopting the concepts of relative estimation and velocity - Relative estimation is an estimation technique that uses the other tasks (or stories) as a guide. For example, if you know task A is easier than task B and about as twice as complex as task C, you'd make sure the "points" for task A were correct relative to those expectations. The emphasis is not on correctly guessing the amount of work required, but keeping estimates consistent with each other. Velocity is a measure of how many "points" you get done in a sprint. If your relative estimation is ensuring consistency, this velocity can be used to estimate which tasks you're likely to get done in the upcoming sprints. Note though that velocity should be constantly revised.
I found this conference talk which should help you out: Personal Kanban: Optimizing the Individual Coder
Personally, I have seen more abuses in the name of agile than I care to write on. Many times "we're doing agile" means "we're throwing away all semblance of process and doing what we want, Yeehaw!" (for the obvious cowboy reference). An agile environment definitely helps, but you have to allow for developers to talk to each other and hammer things out--without scrum dictator approval.
Agile is about incremental development in a field of changing requirements, not about dictating people how they individually go about doing their work.
References: Practices of an Agile Developer, Collaboration Explained, Agile Retrospectives: Making Good Teams Great, Stackexchange, Agilescout
