Agile Engineering

Traditionally, we've categorized requirements as "musts", "shoulds" and "frills". In theory, the musts had to be there to ship. But in reality, many of the musts didn't make it. And unless easy or sexy to the developers, you can forget about the shoulds and frills. So who decides which musts make it? In the absence of someone working with the teams to prioritize things to a finer level, it is determined by the order of attack of development. Those not done yet when things start to look bad get thrown out.

I attend a lot of meetings. That's not a bad thing. Meetings can be very productive. They can be an opportunity to get the right people in the room and quickly make decisions or convey information. But they can also be a waste of time.

Often times in iteration planning teams task out the stories, put people's names on the tasks and have them estimate the tasks. Each person gets an understanding of what they're slotted to take on in the iteration and can then determine if it is reasonable to commit to the iteration content. While the names are often "in pencil" and subject to change based on how the iteration goes, there are good reasons not to put them on there at this point.

One common struggle when adopting agile (particularly in large organizations) is that it can be very difficult to get things done within a short iteration (typically two weeks). Often times, people on the team will push for lengthening the iteration to make it easier to fit things in. There are a few reasons why you might want to avoid this.

It has long been accepted that defects are an unavoidable consequence of developing software. Large software projects tend to keep track of these in a defect management tool with the goal being to keep defects tracked there to a reasonable level (sometimes reasonable is defined as loosely as hundreds of defects). But, is an accumulation of defects really unavoidable? And until a team determines how to avoid them, how do defects fit into an agile process?

There are a few different ways that you can define a release. First, you can specify the functionality that needs to be in the release. If you take this approach, the release is done when you complete the functionality. Alternatively, you can specify a date. When you hit that date, the release is done. Generally speaking, you're much better off taking the latter approach.

The Agile Manifesto says "Individuals and interactions over processes and tools". In other words, that people working together is a very valuable thing. Conversation is a very efficient communication mechanism. Collaboration fosters team work, unifying of goals, etc. Processes and tools, if misused, can lead you astray and keep people apart by encouraging handoffs and focusing your attention on things which don't add value. But this doesn't mean that processes and tools aren't beneficial.

It is a good idea to estimate the size for every story that you take on. Depending on your team, this might be in story points (recommended), ideal days or something else. A team's velocity for an iteration is the sum of the points for the stories completed in that iteration. You can also track how many points you attempted to complete for the iteration. Tracking both of these over time can be very illuminating.

When you have multiple teams working together, there are several ways to handle the resulting dependencies. Each has their trade offs, but I would rank them as follows:

1. Structure the teams so that a single team can solve the problem end to end
2. Do the work within the same iteration
3. Implement the service and then use it
4. Stub out the service and implement it later

Single Team

I've been attending a web-based course from Alan Shalloway on lean. Here are some of the highlights from the final session (focused on Product Coordination and Release Planning). See this link for the previous session (which contains links to the other sessions as well).