How to deal with clients and iterations in Agile team? [closed]

Question

This thread is a follow up to my previous one. It's in fact 2 questions, so I hope no one minds, as they are dependent on each other.

We are starting a new project at work and we consider it as a great opportunity to try Agile techniques in action. We had a brainstorming about ideas we read in several books and articles, and came up with concept that would suit us the best: 2 weeks iteration, followed by call with clients who would choose what stuff they want to have in next iteration. I just have few more questions, which we couldn't figure out ourselves.

What to do in the first iteration?

What to, generally, do in the first few iterations if we start from the scratch? Just give it a month of development to code core of the application or start with simple wire-frames with limited pre-coded functionality? What usually clients want to see? Shiny stuff that doesn't work or ugly stuff that does work?

How to communicate with clients?

Our initial thought it to set the process to something like this:

alt text http://img690.imageshack.us/img690/2553/communication.png

Is it a good idea to have a Focal Point on client side or is it better to communicate straight with all the clients to prevent miscommunication?

---

Any thoughts are welcome! Thanks in advance.

Answer 1

In my opinion, a key success factor for agile development is to focus on delivering value for the customer in each iteration. I would definitely pick "ugly stuff that does work" over "shiny stuff that doesn't work". Doing shiny UIs and trying to get the client to understand hat business logic takes a lot of time to implement is always risky which Joel Spolsky has written a good article about.

If the client wants enhancements to the UI, they can always put that as a requirement for the next iteration.

Regarding communication with clients I think that your scetch should be slightly adjusted. Talking in scrum terms your "focal point" is called "product owner". Having one person coordinating with the clients is good, as it can take quite a lot of time to get the different stakeholders agree on the needs. However the product owner (or focal point) should be in direct contact with the developer, without going through the project manager. In fact, the product owner and the project manager has quite distinct roles that gain a lot by being split on two people.

The product owner is the stakeholders' voice to the development team. The project manager on the other hand is responsible for the wellbeing of the project team and often keeps track of budget etc. These roles sometimes has opposing agendas, and having them split on two people gives a healthy opportunity for negotiation between conflicting interests. If one person has both roles, that person often tend to favour one of them, automatically reducing the other one. You don't want to work on a team where the project manager always puts the client before the team's needs. On the other hand no customer wants a product owner that always puts the team's needs first, neglegting the customer. Splitting the responsibilities on two people helps to remedy that situation.

Answer 2

I'd agree with Anders answer. My one extra observation is that many clients find it impossible to ignoire the Ugly. They get concerned about presentation rather than function. Hence you may need to bite the bullet and do at least one "Nice" screen to show that you will pay attention to presentation details.

Answer 3

What to, generally, do in the first few iterations if we start from the scratch?

Many teams use an Iteration Zero to:

• setup the development infrastructure (source control, development machines, the automated build, a continuous integration process, a testing environment, etc),
• educated the customer and agree with him on the methodology,
• create an initial list of features, identify the most important and do an initial estimation,
• define time of meetings (planning meeting, demo, retrospective), choose the the iteration length.

Iteration Zero is very special because it doesn't deliver any functionality to the customer but focus on what is necessary to run the next iterations in an agile way. But subsequent iterations should start to deliver value to the customer.

Just give it a month of development to code core of the application or start with simple wire-frames with limited pre-coded functionality?

No, don't develop the core of your application during one month. Instead, start delivering vertical slice of the application (from the UI to the database) immediately, not horizontal slices. This doesn't mean that a screen has to be complete (e.g. implement only one search field in a search screen) but it should ideally be representative of the final look & feel (unless you agreed with the customer on an intermediate step). The important part is to build things that provide immediate value to the customer incrementally.

What usually clients want to see? Shiny stuff that doesn't work or ugly stuff that does work?

To my experience, they want to see demonstrable progresses and you want to get feedback as soon as possible.

Is it a good idea to have a Focal Point on client side or is it better to communicate straight with all the clients to prevent miscommunication?

You need one person to represent the clients (who is called the Product Owner in Scrum):

• he provides a single authoritative voice
• he has a perfect knowledge of the business (i.e. he can answer questions)
• he knows how to maximize the ROI (i.e. how to prioritize functionalities)

Answer 4

Agile generally wants to provide the client something valuable, quickly.

So I certainly would not spend "month of development to code core of the application". To me, that smells of the "big up front design" anti-pattern. Also, see YAGNI.

Get as much information from the clients about what they need soonest, and implement that in your first iteration. "Valuable" is in the eye of the client. Thet will know if they want to see slick UI (maybe they want to give a slide show about the product at a trade show, so functionality can be fake) or simple working features (maybe you're developing something that they need to start using ASAP). Business Value is what they say will help them do their job.

I'd make my iterations as short as I can (your 2 weeks could work, I suggest considering 1 week) If you absolutely can't have your dev team and your clients co-located, instead of having a call with the clients, I suggest a meeting. Demo what you've done over the previous iteration and solicit feedback about what should stay, what should change, and what should be added.

As others have said, your "Focal point" sounds like a Product Owner. What worries me about your drawing is if it is meant to imply that devs don't interact with the PO or the clients. One thing that makes Agile work is when there is lots of communication. Having communication to/from the dev team always filtered through the Project Manager is almost certainly bound to result in miscommunication, unnecessary work, and missed details.

Answer 5

I agree with the two answers given but I would just add one thing from personal experience. Are your customers bought in to the change towards quick iterations? As well as providing feedback after each iteration which is going to require the customer performing usability tests on each feature.

Now I don't know what your groups relationship is with your customer but its not unusual for customers to take a "Put request in - get working system out" attitude in that they are enthusiastic when giving requirements but not so forthoming with time when it comes to testing the feature.

Now this may be totally inappropriate to your situation but its always worth considering how your customer workflow will have to change as well as your groups.

Cheers