Collaboration
Contrary to traditional management methods, an Agile approach considers the team to be a single cooperative unit. Individuals are not scored on the amount of work completed, but the team is monitored as a whole. This serves to improve team cohesiveness and ensure that anyone working on a project is dedicated to the success of a project through collaboration. You are all in this together.
Product Owner
The product owner is the individual responsible for establishing a common vision. This person is often the sponsor or customer of the project. The owner must be the lead in identifying features (Stories) and prioritising the workload such that the highest value is being delivered.
Developer
A developer is any technical person working on the project, this includes analysts, testers, designers, programmers, database engineers etc. There is no wall separating roles here, programmers do not simply throw their work to testers and move on. This is a team effort.
Scrum Master
This is the third role in a Scrum project. The Scrum Master is Project Manager of sorts, but embodies a facilitatory role instead of the more directive and traditional approach. It is the Scrum Master’s job, as with a PM, to aid the team and bridge the gap between owner and developer. They are responsible for ensuring that the project remains on track, that the correct artefacts are maintained at sprint or highlight boundaries, reporting progress, running what few meetings Scrum calls for and crucially, removing impediments to work for the developers.
Work in Short Iterations
Statistically, over 60% of features go unused on a software project and the average project overruns by 100%. Agile aims to reduce this by improving the feedback loop and reducing uncertainty incrementally. It is impossible to know all of the project details up front, so don’t try. Work in iterations of between 2 and 4 weeks and go through a full cycle of analysis, estimation, design, development, testing and acceptance in each. Keep the owner involved in each iteration to ensure that the work being committed to represents the highest business value at all times. Each iteration should deliver a fully functional and accepted piece of the project functionality. This functionality is not specified as a technical task, but as a feature that will deliver the highest value to the product.
Inspect and Adapt
At the start of each iteration, incorporate new knowledge from all roles and aid the the owner in updating the plan. Priorities will always change, so be prepared to update them as quickly as possible. Following an iteration, be sure to review the process together in order to capture any new knowledge or improvements that could be made to the process itself. Feed this data back into the planning stages.
Agile Planning
It is almost impossible to know exactly what to build at the start of a project. Instead of setting out with a concrete goal to deliver something completely specified, work with the assumption that both the features to deliver and time until completion can change at any time. You are working until the customer is happy, they may decide that the product is actually good enough early on, or that with some more features and a slightly extended time frame the product could be even more desirable. Be flexible. This does not mean that you should not plan, customers will need an idea of the costs associated with the project and features before starting development. Just be aware that these initial figures are just that, initial. More on estimating is covered here.
Planning Levels
In an Agile project, you will be planning at multiple levels: the release, iteration and day. Defer detailed estimation and decision making until the last appropriate point to ensure that there is a lower chance of change. Do not specify technical activities in the release plan as by the time that features comes around, it may have changed. This means you have wasted time planning for something. It is also very difficult to give an accurate estimate of something not encountered or deeply analysed yet. Delay specification until the appropriate moment.