The+Role+of+Customers+in+Agile+Teams

toc

Introduction
Customers are intrinsic to the success of projects (Kujala et al., 2005) as they commission the work, pay for the work and use the end deliverable. It would appear that the Agile approach recognises this factor as a key core value. Agile projects require that the development team and the customer interact extensively (Robarts, 2008).

Customer
The customer within an Agile environment is defined as the client paying for the work as well as the users of the system or project deliverable, the end users. In many instances, and specifically from an Agile team perspective, the end user is generally considered the customer as it is the end user who determines the fitness for purpose of a deliverable ( Koch, 2005). Highsmith (2010) defines customers as participants who create value and suggests that agile project management is dependent upon this working relationship. Customers can be internal (part of the Agile team's organisation) or external (part of an organisation outside of the Agile team's organisation).

Agile teams
Agile teams are small cross-functional teams who adhere to a number of Agile practices, values, principles and processes in order to achieve a project deliverable (Schwaber, 2007).

Within the agile environment and team, the customer role is a far more interactive role. This is identified within theory (Koch, 2005; Beck & Andres 2004; Cohn, 2009), the [|Agile Manifesto's] value "We have come to value customer collaboration over contract negotiation", and was also evidenced within the XP planning game exercise conducted within a recent Agile lectorial. Within the picture below, the impala (representing the customer) is working 'closely' with the oxpeckers (the agile development team) to process the user story 'to remove all ticks to make life more comfortable'!



Koch (2005) and Highsmith(2010) define the responsibilities/expectations and collaborative role of the customer within Agile. This role definition has been aligned with the customer role observed in the Agile lectorial XP Planning Game:
 * //Establish requirements//:The customer was responsible in providing complete information (user stories) to the developers.
 * //Project and increment planning//: supporting the developers in determining estimated times, selecting the specific requirements for the iteration build.
 * //Evaluation of interim deliverables//: confirming whether a deliverable meets customer requirements.
 * //Frequent feedback and requirement changes//: working closely with the developers to communicate any changes and any feedback required for development e.g. "We don't want the machine to look like this but like this".
 * //Evaluation and prioritisation of changes//: continual liaison required with developers to work the changes into the iterations and decide what is important e.g. "We really want to hold 200 cups but also want the machine to be compact, however, the number of cups is more important".
 * //Ensuring quality of deliverables//: early checking of the deliverables (iteration by iteration) to ensure what is delivered meets customer requirements.
 * //Responsibility of scope creep//: the customer was ultimately responsible for any final decisions on the expansion of the project scope.

Within the exercise, the customer and developer appeared to be working as a team, although some division was observed ('them and us') when decision making was required. The importance of customer involvement was evident to prevent developer assumptions and preconceptions taking over the design and final product. In reality this could have led to rejection of the deliverable.

Agile Methods and the Customer Role
<span style="font-family: Arial,Helvetica,sans-serif;">Each agile method appears to address the customer role in different ways and to different levels as summarised below (Koch, 2005).

<span style="font-family: Arial,Helvetica,sans-serif;">**Agile Method** ||

<span style="font-family: Arial,Helvetica,sans-serif;">**Customer Role** ||

<span style="font-family: Arial,Helvetica,sans-serif;">Dynamic Systems Development Method (DSDM) ||


 * <span style="font-family: Arial,Helvetica,sans-serif;">end user is critical participant involved at each step of the way
 * <span style="font-family: Arial,Helvetica,sans-serif;">users direct progression of project ||
 * <span style="font-family: Arial,Helvetica,sans-serif;"> [|Extreme Programming] (XP) || * <span style="font-family: Arial,Helvetica,sans-serif;">physically present on-site throughout the projects entirety
 * <span style="font-family: Arial,Helvetica,sans-serif;">continuously available and integrated within the team ||
 * <span style="color: #660000; font-family: Arial,Helvetica,sans-serif;">Scrum || * <span style="font-family: Arial,Helvetica,sans-serif;">ownership of the project backlog (user stories to be completed)
 * <span style="font-family: Arial,Helvetica,sans-serif;">main judge on prioritisation, selection and acceptability ||
 * <span style="font-family: Arial,Helvetica,sans-serif;"> [|Lean Software Development] (LD) || * <span style="font-family: Arial,Helvetica,sans-serif;">judgement and confirmation of integrity of deliverable(s) ||

Advantages

 * <span style="font-family: Arial,Helvetica,sans-serif;">Stober and Hansmann (2010) suggest that good relationships are the basis for success. The active and collaborative role of the customer within the agile process means the customer has more input and control of the development process leading to greater customer satisfaction (Koch, 2005).


 * <span style="font-family: Arial,Helvetica,sans-serif;">Customer availability allows the team to view change as an opportunity to improve and enables them to work collaboratively to define the deliverables and to ensure that what is delivered is of use and desired leading to a satisfied customer and Agile team.


 * <span style="font-family: Arial,Helvetica,sans-serif;">Close cooperation and collaboration with the customer enhances project success. The customer needs will change throughout the project and therefore being able to ask the customer directly what their current needs are and aligning current development with these allows the project to always add value (Cohn, 2009).

Disadvantages

 * <span style="font-family: Arial,Helvetica,sans-serif;">A challenge to customers, as identified by Koch (2005) is the level of effort expected by the customer within the agile environment. Often customers expect the supplier to input the highest level of effort however this is not the case and could pose a challenge to customers (especially in approaches such as XP which require onsite customer representation) due to associated costs of customer-availability.


 * <span style="font-family: Arial,Helvetica,sans-serif;">Cohn (2009) suggests that contract negotiation can put customer and contract team at odds from the start of the process which is counter productive to any enterprise. A cooperative win-win attitude will build better working relations and better product delivery. Highsmith (2010) suggests that a high level of customer collaboration is difficult to achieve and requires some reorganisation and Pikkarainen et al. (2008) suggests that effective communication will facilitate this.


 * <span style="font-family: Arial,Helvetica,sans-serif;">Poppendiek and Poppendiek (2006) refer to the standard practice of asking customers for their requirements at the start of the process (freezing them and requiring a long winded change process to allow edits) as a waste. The challenge to the customer is to trust the project team and work with them to develop the requirements.


 * <span style="font-family: Arial,Helvetica,sans-serif;">The <span class="wiki_link_ext">XP planning game demonstrated how requirements change during the development process which appeared largely due to the customer's individual visions of what is required differing and/or an inability to describe the vision adequately. The customer is expected to define the deliverable by using a series of <span class="wiki_link_ext">user stories e.g. 'The deliverable must have a visible 'on' switch in the top right hand corner''. This can be a challenge to inexperienced users.


 * In Agile Software Development the customer must have a particular mindset to enhance collaboration. Beck (2004) suggests that a customer with an adversarial attitude who has learned to distrust IT will stop agile techniques such as XP from working. The customer must learn how to work with the project team and the project team must assist them.

<span style="font-family: Arial,Helvetica,sans-serif; font-size: 1.3em;">References
Beck, K. and Andres, C. (2004) //Extreme Programming Explained: Embracing Change//. 2nd edition. Boston: Addison-Wesley Cohn, M. (2009) //Agile Estimating and Planning//. Stoughton: Pearson Education Inc <span style="font-family: Arial,Helvetica,sans-serif;">Highsmith, J. (2010) Agile Project management. 2nd edition. Boston: Pearson Education Inc <span style="font-family: Arial,Helvetica,sans-serif;">Kujala, S., Kauppinen, M., Lehtola, L and Kojo, T. (2005) The role of user involvement in requirements quality and project success. //Requirements Engineering.// 13th IEEE International. pp. 75-84. Koch, A.S. (2005) //Agile Software Development: Evaluating the Methods for your Organization.// Norwood: Artech House, Inc. <span style="font-family: Arial,Helvetica,sans-serif;">Poppendiek, M. and Poppendiek, T. (2006) //Implementing Lean Software Development From Concept to Cash//. Boston: Addison-Wesley Pikkarainen, M., Haikara, J., Salo, O., Abrahamsson, P. & Still, J. (2008) 'The impact of agile processes on communication in software development'. //Empirical Software Engineering//. (13). pp. 303-337. <span style="font-family: Arial,Helvetica,sans-serif;">Robarts, J. M. (2008) //Practical Considerations for Distributed Agile Projects: Thoughtworks Canada//. IEEE Computer society. pp. 327-332 Schwaber, C. (2007) The Truth About Agile Processes: Frank Answers to Frequently Asked Questions. //Forrester Research// <span style="font-family: Arial,Helvetica,sans-serif;">Stober, T. and Hannsmann, U. (2010) //Agile Software Development: Best Practices for Large Software Development Projects//. Verlag Berlin Heidelberg: Springer.