Monday, January 22, 2007

Going Agile - tips and tricks

Are you looking to make the jump to agile release models such as Scrum and XP? Worried about whether your current tools will effectively support the new methodologies? Well, the tools you use are probably the least of your worries. If you want to ensure that your switch to Scrum (lets use Scrum for now as the example), your #1 priority should be ensuring that your Development/QA team is culturally equipped to handle the change...

Making the switch from a traditional longer/'non agile' release paradigm to something more agile like Scrum may seem simple, but it is not as simple as it looks. Here are some tips that should help your Development and QA teams navigate the transition with the least amount of hiccups as possible:

- Breaking up is hard to do. One of the biggest challenges you will face is in migrating to an agile model, is that your Dev/QA team will probably be used to longer release cycles - maybe 3 months release cycles on average, maybe longer - 6-12 months. Regardless of the duration, Scrum typically has releases in the range of 30-60 days, and this in itself presents all sorts of new challenges. The biggest challenge of which, is your team will not be used to pushing a release out every 30 days (lets use 30 days as an example, it could be 60 days etc). The Dev/QA team will now have to learn for example how to break a 3 month architecture project across 3 releases of 30 days each. And if a feature is not ready to ship in the first 30 days, they have to figure out how to manipulate their code to 'hide' features that are not ready for prime-time yet. Not to forget, you also need to make sure that your release build processes are in shape to handle the accelerated release rate. None of these are insurmountable challenges though - they are just some of those simple things that if you don't pay attention to early on, can come back and bite you in the rear. And no one likes being bitten in the rear.

- Keep it simple. Keep it flexible. Scrum has a ton of guidelines and best practices. You don't have to follow them ALL to the T though. For example, many books state you should do your daily stand-up in the morning when everyone is fresh (sorry non-morning people). However, what if you are on the east coast and some of your Dev team is on the west coast? I don't know many developers who are ready to rise and shine at 6AM :-) So keep it flexible, if the morning doesn't work - do the stand-up at the end of the day (have to give credit to our Director of Dev who came up with this one). In the end all you as a product manager need to focus on is the end goal - shipping kick-ass features at regular, controlled intervals with maximum opportunity for customer feedback. Whatever approach you take to reach that goal is up to you.

- Ease into it. Lets say your company has 14 product-lines. In the interest of maintaining sanity and risk reduction, do NOT try to move to a new release model for all product-lines at once. This is one of the biggest mistakes that people make. Culturally, the organization will probably not be able to handle it. To minimize risk, do one product-line first. You decide which line is best. Maybe choose it based on the enthusiasm of the developers in the team (enthusiastic people have a way of making challenging things happen). Maybe choose the product-line based on the fact that it is on a relatively independent code-base. And if the project then is not as successful as intended (to my next point), the impact on the other product-lines will be minimal.

- Success may take a little time. Switching to a new release model is tough on any company. Be prepared for it to potentially take a little while to succeed. Your first Scrum release may not be a success, you may even have to scrap the first release totally (don't let the team off the hook too easily though, keep the heat on :-). So be prepared for this, set expectations appropriately. If possible, choose a simple project for your first release, it will help reduce risk. Choosing a huge, mission critical, high visibility, time sensitive project is probably not the best way to go for the first try. Again, keep it as simple as possible on the first go round.

- Product Owners should not be Scrum Masters. This is something specific to Scrum. Product Owners are the sponsors of the features going into the product - they provide the direction and guidance on what features should go in the release, and how they should be delivered to the Customer. It makes sense that it is the product manager in this role. Scrum Masters on the other hand, are the release project managers. They ensure everyone is doing their thing, obstacles are moved out of the way, risks are identified and eliminated. This should NOT be the product manager. If the product manager is playing Scrum Master and Product Owner, they will never come up for air, and will likely lose track of important PM stuff like the industry and the competition - which is no good. What works best is a dedicated Scrum Master role in your organization (who has strong project management skills of course). But if budgets are tight, what you could do is have one Scrum Master first who is shared across a few projects (it is OK if this is a part time gig for the person initially), and then grow more Scrum Masters as the budget/success permits - all up to you.

That's it for now. In summary, it is all about keeping things simple, setting expectations appropriately, and not trying to 'boil the ocean' with the 1.0. I'll probably do a post soon on the benefits of agile, iterative release approaches vs some of the traditional release models.

No comments: