The Daily Scrum or Morning Meeting

A scrum or morning meeting is the best way to get control of a development process. Having it in the morning seems like the most natural part of the day for everyone to synchronize, obviously, before everyone has started working. Not first thing in the morning because everyone needs time to have some breakfast, review new email, read the news, and get settled in. About a half-hour should do it. The other good thing about having it in the morning is to ensure that everyone gets to work on time, which gets to the essence of how a scrum works - peer pressure. When someone is late to the meeting, it is not just clear to their manager, but to the whole team. So they are not letting their manager down, they are letting the team down.

During the meeting, each member of the team goes over what they have accomplished since the day before and what they are working on. According to strict principles, the meeting is not supposed to become a status meeting run by the project manager (technically the role is supposed to be called a scrum master, but I don't like that name). Personally I like having the project manager run the meeting. I prefer the direction that it gives. And you still end up with the peer pressure because everyone is listening.

Using Humans in Your System Design

A mistake that a lot of people make when creating software is to try to automate everything. When you are making software for a business, you are generally automating a process and there is often a desire or drive that people have to make software that automates the whole process. They get into an all-or-nothing frame of mind that, unfortunately, usually ends up with nothing getting deployed, or, even worse, software that gets deployed which tries to do it all and fails, disrupting the business and wasting a lot more money.

There are many different strategies and methodologies to deal with this situation. Agile is probably the most popular and successful. One of the main tenets of Agile is to deliver business value as soon as possible. And in most situations in order to deliver that value quickly, you obviously can't program everything. And if you can't program everything, you are going to have to learn how to design humans into your system. This is something that a lot of software people seem uncomfortable with because they view the system they are building purely as a piece of software and think that automation is the ideal. But full automation is not necessarily the goal, creating business value is. (I'll have more to say on this in a later post.)