Last week there was the Agile Seminar here in Helsinki. During my talk I promised that I would make the content available so here we go.During the talk and through a story that I told at the start I tried to illustrate the first Agile value. I slightly changed the it's phrasing from "Individuals and interactions over processes and tools" to "People over processes and tools".But there was a reason for this change. I was trying, with that story, to demonstrate that "people" are at the heart of that value, and ultimately of all Agile values. The "people" value is present in all values in the Agile Manifesto:Individuals and interactions over processes and tools: In this value the "people" component is quite obvious. This value tries to convey the message that ultimately if people don't adapt to the processes or tools we must seek some process or some tool that adapts to people. This was what I tried to illustrate with the story that I told in the beginning of the presentation.Working software over comprehensive documentation: In this value the "people" aspect is not so obvious, but it is there. When a team starts forming, the best catalyst to have the team "Perform" (remember: Form->Norm->Storm->Perform)is to present to them a concrete challenge, and having the team deliver working software very early on helps the team focus on solving the challenges that "delivering working software" presents. One example I used in the talk is that our team (which had only 2 people at the start of the project) was able to define many details of the software development process very early on, because they had precisely one month to deliver working software (20 working days was the length of our Sprints) they were "forced" -- even if the "force" was implicit -- to make decisions. Also, because they eventually were able to deliver working software they also gained the self-confidence that allowed them to take even bolder steps in the following sprints.I'm sure someone will write something at some point on how "delivering working software" helps teams steam past the "norm" and "storm" phases, one strong reason for this is that the "shared goal", so important for teams, is there from the beginning.Customer collaboration over contract negotiation: In this value the "people" aspect is again more obvious. First, Customers are people too ;) and collaboration (not antagonistic negotiation) is the best way to establish a productive and hopefully lasting relationship. If you and your company/team follow this value there's also the added advantage that you reduce the pressure on the development team by having customer buy in through collaboration. NOTE: this does not mean that you are allowed to slack, indeed, collaboration often leads to the exact opposite effect: people commit and therefore give more of themselves to the work than they would otherwise.Responding to change over following a plan: I'm sure you are asking yourself "let's how he manages to put the "people" aspect on this value!". Well, here's my take on it, you judge if it makes sense in your context. In my company (as well as in many other companies) the changes to requirements come at the worse possible time: at the end when we finally know more about the product and can change the scope based on that knowledge. In Waterfall-type methodologies this is a moment of crisis for the team, the questions are often "why does the customer only see that requirement now?", "don't they get it that if they change the requirements we will be so much more late than we are already?". If you are lucky enough to work in an old style consulting company (I won't mention which ones I'm thinking about but I'm sure you know...) you even have a way to get out of this situation: "Dear customer, here's the requirements document you signed-off, to add that requirement it will cost you 1 000 000 more. We did our project plan based on the assumption that the requirements would not change and the resources would be fixed and there would be no surprises during the development process". Obviously this is not good for anyone. Specially not for the morale of the team that gave it's best to produce what they thought the customer wanted only to be faced with the cruel fact that requirements change.Now imagine the same situation in an Agile team: The customer comes in and says "Well, after all I need this new feature in the software and I cannot ship the product without it". The team replies: "OK, do you still want to ship the product on the same date? If you do we will have to remove some work from the backlog, if you don't we can happily add that feature and, if it is that important we can start working on that feature in 2 weeks' time (on average, taking into account the iteration length of 4 weeks).See the difference? Now imagine how both the customer and the team feel about the project in the first situation: probably stressed, frustrated, de-motivated, etc. Would that be a situation that you would like to be in?The talk also mentioned other aspects that I'll leave for another post, but the main point that I tried to get across is that "people" is the most important aspect in a software project, and we must be prepared and active when dealing with that important aspect of any software project. Posted by

Last week there was the Agile Seminar here in Helsinki. During my talk I promised that I would make the content available so here we go.

During the talk and through a story that I told at the start I tried to illustrate the first Agile value. I slightly changed the it's phrasing from "Individuals and interactions over processes and tools" to "People over processes and tools".
But there was a reason for this change. I was trying, with that story, to demonstrate that "people" are at the heart of that value, and ultimately of all Agile values. The "people" value is present in all values in the Agile Manifesto:

• Individuals and interactions over processes and tools: In this value the "people" component is quite obvious. This value tries to convey the message that ultimately if people don't adapt to the processes or tools we must seek some process or some tool that adapts to people. This was what I tried to illustrate with the story that I told in the beginning of the presentation.
• Working software over comprehensive documentation: In this value the "people" aspect is not so obvious, but it is there. When a team starts forming, the best catalyst to have the team "Perform" (remember: Form->Norm->Storm->Perform)
  is to present to them a concrete challenge, and having the team deliver working software very early on helps the team focus on solving the challenges that "delivering working software" presents. One example I used in the talk is that our team (which had only 2 people at the start of the project) was able to define many details of the software development process very early on, because they had precisely one month to deliver working software (20 working days was the length of our Sprints) they were "forced" -- even if the "force" was implicit -- to make decisions. Also, because they eventually were able to deliver working software they also gained the self-confidence that allowed them to take even bolder steps in the following sprints.
  

  I'm sure someone will write something at some point on how "delivering working software" helps teams steam past the "norm" and "storm" phases, one strong reason for this is that the "shared goal", so important for teams, is there from the beginning.

• Customer collaboration over contract negotiation: In this value the "people" aspect is again more obvious. First, Customers are people too ;) and collaboration (not antagonistic negotiation) is the best way to establish a productive and hopefully lasting relationship. If you and your company/team follow this value there's also the added advantage that you reduce the pressure on the development team by having customer buy in through collaboration. NOTE: this does not mean that you are allowed to slack, indeed, collaboration often leads to the exact opposite effect: people commit and therefore give more of themselves to the work than they would otherwise.
  
• Responding to change over following a plan: I'm sure you are asking yourself "let's how he manages to put the "people" aspect on this value!". Well, here's my take on it, you judge if it makes sense in your context. In my company (as well as in many other companies) the changes to requirements come at the worse possible time: at the end when we finally know more about the product and can change the scope based on that knowledge. In Waterfall-type methodologies this is a moment of crisis for the team, the questions are often "why does the customer only see that requirement now?", "don't they get it that if they change the requirements we will be so much more late than we are already?". If you are lucky enough to work in an old style consulting company (I won't mention which ones I'm thinking about but I'm sure you know...) you even have a way to get out of this situation: "Dear customer, here's the requirements document you signed-off, to add that requirement it will cost you 1 000 000 more. We did our project plan based on the assumption that the requirements would not change and the resources would be fixed and there would be no surprises during the development process". Obviously this is not good for anyone. Specially not for the morale of the team that gave it's best to produce what they thought the customer wanted only to be faced with the cruel fact that requirements change.

  Now imagine the same situation in an Agile team: The customer comes in and says "Well, after all I need this new feature in the software and I cannot ship the product without it". The team replies: "OK, do you still want to ship the product on the same date? If you do we will have to remove some work from the backlog, if you don't we can happily add that feature and, if it is that important we can start working on that feature in 2 weeks' time (on average, taking into account the iteration length of 4 weeks).
  

  See the difference? Now imagine how both the customer and the team feel about the project in the first situation: probably stressed, frustrated, de-motivated, etc. Would that be a situation that you would like to be in?

The talk also mentioned other aspects that I'll leave for another post, but the main point that I tried to get across is that "people" is the most important aspect in a software project, and we must be prepared and active when dealing with that important aspect of any software project.