Time for Agile principle number four, where we talk about the relationship between product owner and engineer:

Business people and developers must work together daily throughout the project.

In the post on agile principle number two, I gave the example of a Secret Santa management system, as an example of how being able to accommodate changing requirements can benefit a project. As a refresher, here's the key story points of the project:

• A user should be able to sign up
• A user should be able to log in
• A user should be able to get a recipient assigned
• A user should be able to add notes to their recipient
• There should be an "Add Amazon product" link that searches on Amazon
• There should be a "Buy on Amazon" button

I'm going to reuse this example to show the value of business people working closely with developers. You can refer to the original blog post if you like. I'm going to be counting the number of product owner-engineering interactions in the Agile scenario:

1. Meeting with the dev team to decide that sign up and login functionality are essential
2. Being notified of the sign up and login completion/deployment
3. Verifying sign up and login
4. Being notified of the recipient selection completion/deployment
5. Verifying recipient selection
6. Being notified of the notes completion/deployment
7. Verifying notes
8. Having developers stop work

That's 8 different product manager-engineer interactions, and this is a tiny hypothetical product -- we only did 4 story points! This doesn't include questions or clarifications that inevitably come up in all projects while the developers are at work. You show me a client that thinks it's okay for each of these interactions to wait for the weekly (or longer) review and I'll show you a client who is overpaying for bored developers.

So what if you're concerned that these interactions suck up time? Given that other than planning meetings (which occur in waterfall too) the interactions generally last 30 seconds for a quick question or notification, or 5-15 minutes for verification. I've never met a client who was too busy for this. Also these frequent interactions give you frequent input. That lets you guide your project -- think about driving a car that you can only steer every 30 seconds. It's worth it.

This is actually one area where Cloudspace adds it's own flavor to Agile. Pure Agile processes mean an onsite customer, working as a product manager full time. We realize that when working with startups, they don't always have the time or resources to devote a full person to being available immediately. So we give our clients flexibility. We find out why the software is valuable and what the business goals are so that we can make good decisions if we reach a point where the product manager is unavailable but we need to move forward. Of course, sometimes the good decision is to hold off on one ticket and be productive on another. Clients are always consulted on key decisions. We're also good at batching these interactions into the daily meetings -- a 15 minute meeting or email where we update the client on the day.

From the developer side of things, having easy access to answers is great. There's nothing worse than trying to guess how an entire feature should work, and then having to rewrite the whole feature due to a difference in perspectives. Remember: happy engineers are productive engineers.

Speaking of happy engineers and productive engineers, in my next post we'll be talking about the 5th principle of Agile: trusting a team of motivated engineers.

P.S. If you are one of those rocking motivated engineers, Cloudspace is hiring!