Bringing people around to Agile
This is an email I wrote my department yesterday, talking about keeping on with Agile. The team has decided we want to keep going with the successes we’ve had with Agile but we obviously have to convince the people above us. Since I’m not a manager I have to put out my ideas and work more behind the scenes to make changes. I don’t know how useful this might be to anybody but if you’re looking at introducing Agile to your work, just think about putting your ideas out there to stew around in people’s heads.
Since the email is pretty long, click Read More to read it if you’re interested.
As you might know, I went to the international Agile conference last week and I came back with a bunch of ideas (I can already see some of you rolling your eyes but bear with me J).
One of the things I’ve been thinking about for awhile and about which I had a lot of ideas about at the conference was how we can continue to take advantage of the benefits of the Scrum methodology we used on BillingCenter. So this is my idea and I’d like to open up some discussion about how we can carry on being Agile long-term. Like I say, these are just some ideas and I hope we can all talk this stuff over. I really believe in this stuff and from what I saw at the conference, it’s helped a lot of companies. I’d hate to lose the benefits of this methodology just because we’re not doing BillingCenter any more.
The core of the plan is the idea of having a single backlog for all the work that we need to do as a team (by which I mean the programmers since this style of work fits our stuff best but of course if you guys think it would benefit the administration side there’s no reason why it couldn’t be used). This means everything goes on a single list and gets estimated for difficulty by the team and prioritized. The backlog would be based on Jiras and include new work as well. Then, we do 2-week iterations where we take things from the backlog based on the priority and difficulty estimates and work on that stuff. Anything new gets estimated and prioritized onto the backlog (not including emergency stuff, obviously). This way our customers (the rest of the company) knows what we’re working on right now and has insight into what we will be working on. Obviously everybody thinks their stuff is super important but when everybody can see how much work we think something will take, we can make rational decisions about priority and everything is out in the open. This also prevents us from jumping around on a million different tasks, which has tons of benefits. And since we’re iterating every 2 weeks, we’ll be delivering working stuff into our customers hands and getting feedback much quicker.
Since everything goes onto a single backlog, we can mix projects. One iteration maybe 3 people work on tasks related to Project X and the others work on tasks from Projects A, B, and C. Then if we need everybody on Project X for a time, the iterations are only 2 weeks so people aren’t waiting around forever for their stuff to get done. Or one person can take an iteration break from working on Project X to get something done in Project B. It’s very flexible and since we have so many different types of projects and tasks going on around here, flexibility is key.
I’m looking into a couple of tools (like Scrumworks but much, much better; believe me) that help track projects and tasks. I hope to have something to show everybody soon and see if the tools are something everybody thinks we should use.
All in all, the structure and openness provided by taking on an agile environment has a ton of benefits, not only for IT but for the company who relies on us to get their stuff done. Over and over at the conference I heard not only from programmers but project managers, the business people, and customers who all said going agile was the best thing they could have done. I’d love to talk more about this and if you have questions about it, I’m all ears.
If you’ve made it all the way down here, thanks for reading.
You should follow me on Twitter here!
|
|
