Managing Agile Development Practices

I have received several interesting emails, and some great feedback following my latest post about Agile Product Development lifecycles. In one email, I was asked the following:
How in a fully agile world one would reasonably manage budget, customer expectations, and dependencies across multiple projects?
Good question. My response was a lengthy one (who knew I had so much to say on the subject?) and I figured I shouldn't let my response be relegated exclusively to an email inbox somewhere. This is how I answered that question.
Controlling Budget Unless you are running a consultancy where it is prudent not to invest any resources in features or development that have not been fully agreed upon, then there is little difference in the techniques you will use in a waterfall model and an agile one. In either case the best way to control budget is with clearly defined requirements. In my presentation there is a slide that illustrates the Agile lifecycle. You will notice a "planning" phase that is interspersed throughout and preceeds a sequence of phased releases. This planning phase is critical and is where product management clearly defines and articulates the problems they need to be solved by engineering. The more concise and clear the problems the better. What you are trying to avoid is an engineer building something that is not core to solving the problem at hand, or investing in too many bells and whistles. In order to ensure this, it is important that requirements are not developed in a vacuum. It is important to involve engineering during the whole process and then to document what you discuss and the decisions that are made. Over time your requirements document evolves into a set of problem statements, and then a set of questions (and their answers) that came during the process. Also, you will want to draw clear boundaries between what is a must have and a nice-to-have. Be clear with engineers: "all I need is it to do X, Y, and Z. Ok, AJAX would be nice, but IT IS NOT NECESSARY; focus first on getting the problem solved, and then let's work together to refine what you build in subsequent releases and phases." Don't sap the fun out of the process, and don't keep the engineer from innovating, but push them to achieve a feature complete milestone first, and then start iterating and improving. Managing Customer Expectations This is where blogging comes in. Blogging is such a great mechanism and medium for communicating with customers. It is easy to do, takes very little time, and the reward can be immense. So what do you blog about? * blog about problems you are having * blog about your successes * blog about every new feature (but don't lump all your new features in a single post, spread it out, create one post per feature) * and most importantly: blog about what is coming Share everything you can afford to share, strive for transparency. And as long as you are trickling out new features on a regular and predictable basis, customers stay happy. In the end, the key is to let customers participate in the development process with you. Help them to feel like your product is not just for them, but that it belongs to them, in the way that the product belongs to you. Managing Multiple Concurrent Projects and their Interdependencies I believe in keeping features separated in their own branches. It may seem like a lot of overhead at first, but it gives you more flexibility in determining when a feature gets released. Merge only when you know for sure what you will be able to release. What is nice about this process is that the merge process itself is useful in helping you to understand and assess QA impact. If you have a lot of merge conflicts than you know to what extent you will need to regress the system. If there is no merge conflict, then features can be more easily be tested in isolation. This is the opposite of how typically releases evolve. All the features, bug fixes, and changes get checked into the same branch. Once that happens you can't easily remove a feature to reduce scope and complexity. The release begins to snowball, and you lose any "agility" you may have gained throughout the rest of the process.

No Comments

Leave a comment

what will you say?