This is the frontpage of a project, working on creating some advice for customers.
Let's agree, that the audience for everything on this/these pages is the "customer-side" - including project sponsor, customer project manager and business expert....
Angela Martin: Ok, but will it be written for the business expert, what they need to do, how they need to be involved etc as the primary audience? I think we should try to steer away from creating agile project management advice, what do others think? From here I was wondering how the business sponsor may fit in, I think it would be "how and/or what and maybe even why the business expert needs to communicate with the business sponsor" ... Ole Jepsen: In my experience, most business project managers usually turn out to play the role of the business expert. They are often picked to participate in the project because of their business knowledge (as opposed to their leadership skills). The IT-project manager is often more experienced as a project manager than the business project manager - so no matter how the "project organization" is defined - usually the IT project manager takes over the PM-responsibilities in the project. This leaves us with a business sponsor and a business expert... Often the business sponsor is the one that understand, that "business value" can be created in many ways - and that a close and flexible collaboration amongst business and IT within the project group is most likely to give most business value. But where does that leave the business expert? In my experience the general picture is, that most business experts has more to learn from Agile than business sponsor. This is because the business expert is (and should be) more into the details. And when you know exactly what you want in details - then you tend to be more "closed", which is not a good state of mind in an Agile project...
Kouros Goodarzi: According to Scott's original statement of purpose for the groups, I believe we have to assume a customer perspective and also a process approach.
Audience
Who is the audience...? I - Ole - believe that there are only very small differences between what you can expect - and how you should act - depending on whether you are an in-house customer or an external customer. One thing, that could differ somewhat is the commercial/contract/legal issues - but even for in-house development, there's a tendency to copy from customer-vendor relationships.
Kouros Goodarzi: So let's say audience is customer project/product managers, decision making management, and staff dealing with agile vendors.
Customer situation
How to ease the pressure on the Agile Customer - or: Which challenges can you as an agile customer expect to meet - and how handle them.
Challenges on customers side - and how to handle them.
Challenges on development side - and what you can do to help handling them...
How does Agile change the daily life in a project
Mary Poppendieck: Too bad we have to work in the context of a project. To me agile development is best done in the context of a complete software lifecycle - which includes the 70% of code written after the first project is over.
Angela Martin: Good point, my initial focus is always projects as my experience is project based. What sort of things would be different for the customer if we also considered the entire lifecycle?
www.poppendieck.com
Mary Poppendieck: At the Agile Customer Workshop at OOPSLA one group developed a poster session on treating development as a project vs. a product. You can see the poster at: . Basically finding is different, success is defined differently, and the customer of a product development program is the well defined role of product manager.
Kouros Goodarzi: As mentioned earlier we have a mandate to take a process approach to this exercise. This means we have to cover the whole of the life cycle. Requirements, release, and testing would have major effects on customers in agile methodologies. We can focus on those and leave the rest of development to whatever sub-group would be responsible for standardizing agile methodology itself (from a dev point of view).
Ole Jepsen: You definitely have an advantage, when you have a team, that is mature and well integrated. Once I was working as the PM on a project, and suddenly Anne said: "I have started writing the test-cases". I had not thought of test-cases yet, but when Anne brought it up, I could see, that the timing was perfect. It fitted perfectly with what the other team-members were doing at that point. This team had been working together for 2 years at that time. I started to play with the thought, that you should keep the project teams and assign development projects to teams along the way... But: There's also a good thing about creating teams for each development project: You can mix a cocktail of the right people with the right skills (technical and collaborative) for the task. You often get a good energy, when you bring people together. It's flexible: You can create teams, when you need them. Etc...
Kouros Goodarzi: It would be nice to inform customers of the dangers of dealing with a team of novices that claim agile development as their approach to software development.
Organization
How the project should be organized to get the best possible result out of being agile and having an agile customer on board.
Level of involvement in agile projects. (Why spend more time with the development team)
How to handle the part of your organization, that is not directly involved in the project: Explain the "rules" (not all will have the right to post requirements and to participate in decisions - because it takes time. Then take control - make decisions - and keep them informed...
Spend time with the developers - and make them aware, that you are interested in what they are doing - and available for questions - and that you want to we what they build every so often...
Which kind of persons are well suited for participation in an Agile project? On the business side? On the IT side?
Kouros Goodarzi: I see too much emphasize on IT, in the comments and read even more of that between the lines. There are many embedded and telecom (my personal background) projects also being done using agile. Would we need to cover them too?
How the perception of the developers work change, when you 'live' with them
Value
What does the customers get out of Agile - as opposed to traditional - SW development projects.
Kouros Goodarzi: This specifically, and many other customer expectation issues are being dealt with in Nancy's Sub-group which I am a member of. I would act as a double agent and let you know of items discussed there.
What do you get out of co-locating with the development team
Kouros Goodarzi: Maybe we should add the following:
What communication schemes are selected to ensure direct and constant communication between development and the customer's representative
Requirements and changes
How to handle requirements and changes - from the customers perspective - in agile projects. (short iterations rather than heavy change management)
Acknowledge that no matter how hard you try - it's usually impossible to know (and describe!!!) what you want up front
What about documentation? How the 'role of the paper' changes
Putting understanding and communicating over modeling and documenting - or rather: seeing modeling and documenting mainly as a help for understanding and communicating - and not for the "who is to blame" later in the project.
I can not type tabs. Please ConvertSpacesToTabs for me * Understand that 'the developer builds what he has understood' - rather than what is in the specs?
You are not only responsible for sharing your knowledge - you are also responsible, that your peers really, REALLY understand (because in an agile project you have the chance to do so - and this is what agile is all about: to minimize misunderstanding, and thereby maximize value for money - because misunderstandings in projects are SO expensive...)
Supposing, that the contract is more "open" than traditional contracts (we will not cover the contracts as such in our group - because one of the other groups have the contracts as their main area) - how to "act" under an open contract. There is less guarantee for what is to be delivered - but there is more room for you to think, get ideas and to change the requirements towards the better. Beware of the danger of zig-zag specifications, where you change your mind often. In an agile project you are entitled to do so - but only do it when you have to, because it costs developers time, that could have been spend on creating value for you
Angela Martin: An agile customer is responsible for eliciting requirements, communicating requirements (both to the business and developers), prioritizing requirements (or obtaining/negotiating agreement on the prioritization of the requirements) and accepting the resulting software. Are these the key responsibilities of the agile customer? Does anyone else share them? If so, how? Why is this different to traditional requirements (both chaotic and plan driven ... and does this point matter)?
Ole Jepsen: At least prioritizing is different - because in a traditional project you do not prioritize - because you have to have a system, that meets all of the requirements... Actually I also think, that "communicating requirements" is new to Agile - because in traditional projects some would say, that it is enough to "specify" the requirements. Or - in other words: In an Agile project you should - as a customer - focus very much on "communicating requirements". Make sure that you are explaining yourself clearly - AND that they REALLY understand you. This is where you can make a big difference...
Kouros Goodarzi: I agree with Ole, that all three are different in Agile. Requirements are made to be understood, prioritization is ongoing, and software is accepted in multiple releases. Maybe it would be a good idea to base the whole document on these three pillars.
Iterative development
Why the development team likes iterative development - why you should like it too - and what it takes (what it means for your involvement...)
Why give the development team a 'right to deliver'?
Giving feedback and accepting iteratively
Responsibility
Does responsibility change? How? (An agile customer I know says, that he is asked to participate in decisions, that really are pure IT-matters. But the IT people want understand the consequences and share the responsibility.
Kouros Goodarzi: Many customers (or their reps) don't understand much of the technical stuff, it is therefore very helpful (specially to everyones time and schedule) to have special meetings with customers (or their rep) to discuss issues in non-technical terms and ask for their decisions. This usually happens after the dev team has discussed all the details of an issue and prepared a non-technical (even though verbal) report of the problem at hand.
Take a part of the responsibility for the project to deliver on budget and on time (if this is important) - rather than trying to squeeze as much as possible out of the supplier
Kouros Goodarzi: In the Customer Expectation sub-group, we have agreed on the terms Customer, Vendor (agile software development team), iteration (internal builds coming from dev), release (builds with specific feature sets delivered to customer). I suggest we either use them or come up with our own and then coordinate with that sub-group.
Take responsibility by participating in the prioritizing process, that is needed in every iterative project
Overview
Q&A's (as a brief overview of everything we are writing...)
Kouros Goodarzi: I suggest we draw an outline of the sections of the document. If everyone agrees we can use the existing heading structure of the wiki page.
See original on c2.com 