Going to try to lay down some quick observations about getting new teams ramped up on Agile. It's just like everything else in life, you keep getting better at doing what you've been doing, but you keep having to lead new horses to the same water.
1. Agile is hard to understand, and it's really hard to understand if you aren't intimately familiar with the challenges of modern software development. When you have to bring in business stakeholders and other non-developer team members into the mix, be prepared for a longer than desirable ramp-up time. Reading books about Agile is like reading books about skiing. You can glimpse about 5% of what there is to know this way, but until you do it a lot of times for a lot of different projects, you ain't gone skiing yet.
2. Every project is different, and your process needs to be allowed to emerge. This is something that can drive new people crazy - "But how did you do it before on other projects? Why are we using process and procedure X when we did Y before?" People naturally resist emergent approaches because to them change means that there is a problem, that something is wrong, that something wasn't well thought out. They don't know that every project and every team is going to have an unique mix of personalities, technical problems, logistical problems, etc., that will result in an unique set of solutions that are built on the shoulders of giants from previous problems.
3. Initial story quality always sucks. Don't spent too much time doing it. You have to spend time and energy every iteration - for us, every day - evaluating existing stories, throwing stale ones out, and writing new stories that cover the gaps that you didn't think of until you tried to actually do any work.
4. Try to get from mockup to building real applications/web pages ASAP. No one will really understand what the true UX challenges are going to be with your brilliant ideas until you can click on something that does something. Light-weight mockup tools like Balsamiq are incredible productivity-enhancers for this phase, but don't spend too much time on them. YOU MUST BUILD to really discover. This is probably the most important and profound learning on my agile journey - Just Do It. Stop talking, stop thinking, stop planning, just build something, inspect what's wrong with it, solve one small well-scoped problem at a time. Emerge.
5. Do not confuse visual pretty makers with interaction designers. Pixel pushers almost universilly are bad at UX. If your product doesn't make sense to users it doesn't matter what it looks like. Decorate it later. The extra work your HTML person might have to do and bitch about is sad, but it's nothing compared to the amount time you saved not decorating first and building later.
6. Small bite size pieces at all levels, from stories, to the size of your iteration, to the time to initial launch, to your release cycle. The smaller you make things the less you have to think about, the more you can focus on doing one thing perfectly right.
7. There are two kinds of reactions to Agile. "I get it, this is how it's done," and "WTF???" Don't bother trying to lecture or explain to the latter crowd. Lead them to water and spend as little time as you can trying to convince them of anything. Some people are never going to play the game as its meant to be played 100%, but as long as they don't get in the way it's ok.
No comments:
Post a Comment