Since I’ve learned about agile practices, I’ve wanted to work in that way. Initially it was to get testing involved more up front and, heaven forbid, maybe at the same time as development. Now when I talk about agile to people it’s about the reasons below…
- Discovery / Change / Creative
- Agile projects evolve as they go. Things come up and things will change as you learn more about the product, environment, customers, and technologies. Everything has the potential for meaningful change and agile embraces that. It also allows, and should demand, innovative and creative ways to solve problems. I love sitting with designers as they sketch ideas on paper or a whiteboard and bounce ideas around. This keeps it exciting to me and with a road map or a problem to solve in mind, helps the team get there.
- I am big on individuals and how individuals contribute. They also need to be able to function as a team to get things done. A quick team solution is better than one guy saying “do it this way”. I want smart people and people who are technically skilled but also without the ego or attitude that usually comes with it. Rock Star developers who want to work by themselves and not involve or worse belittle other members of a team is bad. Those people should be removed ASAP.
- Not everything is going to work. All the different ideas, designs, technologies that there are means that something is bound to either go wrong or not work like someone planned. The fact that it failed is not a bad thing, the failure should allow you to flex into a better idea, or learn and react to that failure. Failure is not a reason to cut a project, or stop doing something, it’s simply a way to say “try again”, let’s make it better.
- What’s most important
- I hate requirement documents. Mainly because it’s an unstructured pile of crap that lists any and everything that somebody thinks they want or was told to write. They are almost always out of date and when you actually get around to build that particular thing, it’s just wrong. Also they lead to the problem of priority. Priority is needed but what I see is a list of 20 things, and 18 are high. That’s not helpful.
- Force ranking that list of 20 items is critical because that’s when you find out what’s most important. Something is always 1st, something is 2nd, and on down the line. I like working to make that hard choice because it’s a discussion about what’s the most important thing, the item with the most value for the user. That also means it’s usually cheaper to build, faster to market, and higher quality.