This past Wednesday at the Great Lakes Area .NET User Group I had an opportunity to listen to Brian Prince (Architech Evangelist from Microsoft) speak about agile development practices. The following are just a few of the concepts that were covered on the topic.
Stand Up Meetings
Every day at a set time get together with your team and meet for anywhere from 10-15 minutes. The time limit is important to adhere to no matter how large or small your team is and keeps the meeting flowing and on topic. Take long discussions offline after the meeting so that you won’t be taking up other people’s time. Use some type of object as your speaking token and only the person with the token gets to talk. This token can be anything you want and gets passed around the entire team. It’s encouraged that **everyone is standing **during this time, which besides the fact that its called a “stand up” meeting, I would imagine that it also keeps people from getting too comfortable and extending the meeting time longer than it should be.
Usually the stand up meetings covered these three things:
- Talk about what you did yesterday.
- What you plan on doing today.
- Anything holding you up
The “Moscow” rule
Moscow, which stands for Must O Should Could O Wont, is used to give your tasks prioritization. The client plays a big role in this as they will be constantly prioritizing the tasks regularly based on their needs. Try to think of the Moscow rule as a series of containers. The rule of thumb here is to have your client put as many tasks in the “won’t” section as they want and then divide the rest of the tasks evenly into “must”, “should” and “could”. By practicing this you have a clearer picture of what types of things that people should be working on for each given iteration without allowing the client to have every feature assigned to the “must” container.
The Iron Triangle
The Iron Triangle is a way to visualize each aspect of a project and how it affects the other. By emphasizing any two areas from the triangle you will be taking away from the one remaining piece. Interestingly enough, where is the “Quality” piece of the triangle?
Not all rules of agile must be adhered to, use what works and forget what doesn’t. It can take upwards to a year or two in some cases for your team to fully embrace and acquire the benefits of practicing agile development.