Friday, July 22, 2011

From Months to Minutes

I found another presentation on InfoQ, this time by Dan North. In it, he puts many Agile practices through the wringer, and turns them inside out and on their head. Dan questions why we do them, what they do for us, and offers pointers on how to intelligently apply them to become a high performing team.

It's a great and very fast-paced discussion, and it got me thinking a lot about what I do and what I recommend to my teams.

My favorite parts, which are also the most important steps to effectively delivering software, is about the need for one team. In his case, he talks of developers working side by side with traders. He talks about how the developers know as much about trading as the traders do, having learned this by spending time talking with the traders while they work making trades. There is no difference between the business and the engineers. It's one team, consisting of both engineers and traders.

He also talks about minimizing boundaries and hand-offs, particularly within the team. The team does not have members who are analysts, QA's, DBA's, etc. Those roles exist, and are filled by the team members as needed. Particularly, the developers are the ones talking to the traders about features. There is no handoff from customer to analyst to designer to developer. The developers talk directly with the traders, and then implement the features. There is no loss of fidelity; the message does not have a chance to be misunderstood. This is helped by the fact that the traders and developers work together.

Thursday, July 21, 2011

Craft and Software Engineering

Glenn Vanderburg has a great presentation available on InfoQ titled Craft and Software Engineering. In it, he describes where Software Engineering came from, some of the fallacies, and a direction to make it more like other Engineering disciplines. It's a great talk and moves quite well through the content. I'd recommend it to anyone involved in software development.

One of the things he talks about is feedback, and how the different XP provide feedback at different levels of granularity, and at different timescales. He also discusses this in his 2005 paper XP Annealed. Here's what this looks like in a table:

XP Practice Feedback Timeframe
short releases solutions months
planning game priorities weeks
acceptance testing features
collective ownership architecture days
on-site customer
continuous integration design hours
system metaphor classes and interfaces minutes
unit testing statements and methods seconds
pair programming

In his paper, he goes on to describe how the nested levels of feedback are effective and efficient because the practices support each other, and cover for each other. Each practice, at each level of granularity and timeframe, covers and is covered by nearby practices.

Observation: The feedback can be broadly classified as technical at the lower levels, and business at the higher levels. Taken broadly, there are only two types of roles needed to implement the project. Technical (developers) to work out the design and testing, and business (non-technical) to provide the vision, the priorities and acceptance criteria.

Taking it one step further, putting these people together, as one collocated team, would be the most effective way to facilitate this communication. Nothing original here, but it seems to be a natural progression. It minimizes the number of hops that need to happen for any communication.

That's not to say there is no room for specialists, for things such as the environment, deployment, acceptance testing, UI design, and so on. However, they should all be part of the same collocated team.