Agile software development, the principles. Principle 5: Build projects around motivated individuals.

Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

This is the fifth of 12 posts about the principles of agile software development. Purpose is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering. Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage.
The question is: is this going to work in practice or is this only based on a nice marketing and sales story.
Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Motivation is such an obvious item in agile development that this is often overseen. Motivation has to be both in the field of the expertise of the developer and the developer must be motivated in applying agile methods.
Both these points require additional skills of the project manager. Traditional pm’s tend to focus on costs, schedule and quality. Now the project manager must be able to apply skills for motivation, teamwork, collaboration, individual goals and work satisfaction of the team members. This calls for a different type of project manager who is involved in his team and monitors the motivation of his team almost constantly.

The best personal example of this point is with my first major project. I was responsible for a team of 8 developers. At the start of the project I took the time to sit down with each individual developer and talked about their individual interests, challenges and goals. This gave me a huge insight in the composition of my team. I got commitment from my team members and they got motivated working for a project manager that really listened to them. I did not make the mistake to ignore their input and lose their confidence. When assigning tasks and making decisions that involved the team I took into account the individual motivation and interests of the team members. This made the whole team successful in delivering the end-product.

Going back to the basics of motivation I must point to the Herzberg’s two factor theory. Hertzberg talks about the Hygiene factors and motivation factors.  This is important to understand.

* The hygiene factors must be present, when they are not they just work as a de-motivator. Examples of these factors are: pleasant working environment, availability of good working equipment (hardware, software and network), the possibility for taking vacation, possibility for training, stable organisation, job security and salary. When these factors are not present (e.g. due to tight scheduling without time for vacation or training, massive reorganisation and possible outsourcing the IT department to India) you can imagine what this will do to the motivation. Of course the PM has no influence on all of these factors.

* Motivators. Examples of these are challenging work, getting recognition and responsibility. Your team members must be challenged in the work they are doing, give them responsibility for the way they want to do it and give them the recognition for doing it.

Motivators are the factors you steer on. Hygiene factors must be present, when not the motivation decreases. Adding more hygiene factors will not improve motivation. Adding more motivators will increase motivation.

Challenging work
Believe me. Not all development work is challenging for all developers. Lots of work is not that complex but demands a lot of concentration to prevent missing a simple setting or validation. Small part of the work can be classified as very complex. It is the task of the project manager to set up the team from as well senior and junior developer so they match the amount en complexity of the work to be done.
Secondly you must assign short and small tasks. This way there is a clear end to the tasks and they are able to get frequent rewards for completing their tasks. After completing this task they have a foresight of starting another different (and challenging) task. Working now and then on a non-challenging task is no problem as long as there is a foresight of a challenging task and you show them what the added value of this task for the whole project is.

Responsibility
Give your team members the responsibility for completing their tasks. Trust them to take the right decisions and steer upon delivery of end-results. This has a learning curve for teams (and project managers) new to this kind of work. Team members must be aware that they are responsible for completing the task within the given time and project managers must learn to steer on the end-results. The team will work together in a more mature manner. The realisation of the work is delegated by the project manager tot the team members. The project manager must ensure and facilitate the cooperation between the team members and ensure the approach to the solution is aligned with the chosen architecture.

Recognition
Give the team members recognition for their work, when completing tasks. Reward team member for their extra effort, completing complex task or issue and resolving complex problems. Let the environment of the project (your organisation or the organisation of the customer) know what your team has accomplished.
Give them a good working environment
Ensure the working environment of your team will not become the factor for reducing the motivation. Make sure the environment is pleasant to work in. Supports the needs of the team and facilitates team activities. Examples of these:

* Reduce noisy environment by setting up the team in a separate team room (instead of the “office garden”).
* Set up a separate agile modelling room with enough whiteboard space, enough whiteboard markers in several colours and post-it cards.
* Digital camera’s (to snapshot modelling artefacts on whiteboards ).
* Good development environment, network access and easy access to development environments.
* Projector demonstration purposes.
* Good tools for issue management and work planning (simple tools like post it memo’s work fine).

Make room for vacation and downtime
The agile development process can be intensive and exhausting for the team members. The project manager must ensure his planning with enough room for downtime and vacation of his team members. Working log days in a row without a break reduces the motivation of all team members. Giving your team the knowledge that the project schedule includes room for vacation and downtime will make motivation higher. After a nice vacation I’m also more motivated to start my work again :.
 

Conclusion:
Motivation is a significant factor for a successful agile project. The project manager must make sure the hygiene factors and motivators are in place to give the team members the environment to get the work done.

Other posts about the AGILE Principles (soon to come):

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Google