The Agile Team Approach

First of All

If you don’t know the four Agile Value Statements, I invite you to take a look at Agile’s origins and values post before continuing, if you already did or already know these values, now you can focus your attention on how the agile team approach actually is in the field. Together, the Agile Value Statements add up to a highly iterative and incremental process and deliver tested code at the end of each iteration. The next points, in general, include the overall way I which an agile team carries the project:

Works as one
Works in short iterations
Release something every iteration
Focuses on business priorities
Inspects and adapts

The Agile team works as one

Unfortunately, is usual to see some business and systems analysts throw processes or requirements to designers and programmers like a ball over the wall and just continuing with their lives, also there are designers and architects who elaborate their appealing designs without the slightest consultation to their programmer coworkers, or talented programmer who finish their assigned part of the system and then shake their hands and disappear; and we can go on with sad stories. A successful agile team must have a “we’re in this together” mindset.

I really like using video games analogies, because are a great way to illustrate what happens in real life. A lot of online games are team games, where each member of the team has a role. In this teams, there are roles such as the healer who heals his teammates, the tank who receives hits becoming in a shield for the rest of team who can attack more efficiently, the DPS who do damage to the enemy and the special class who does some kind of damage. When a player doesn’t perform their role properly, puts the rest of the team at a considerable disadvantage, sometimes this breaks the whole team completely. Everybody must work as one!

Just like happens in this games, the agile teams also have roles, and it’s worth identifying them in a general way:

Product Owner

The main responsibilities of the product owner include making sure that the whole team shares the same vision about the project, establishing priorities in a way that the functionalities that contribute the most value to the business are always in which the team is working on. Take decisions that take the best return on investment of the project is the highest priority.

Customer

The customer is the person who made the decision to finance the project, usually represents a group or division. In these cases, it is common for this role to be combined with the product owner. In other projects, the customer can be a user.

Developer

In the context of agile teams, a developer title is used in a wide way, this is a developer can be a programmer, a graphic designer, a database engineer, user experience experts, architects, etc.

Project manager

We have to take this carefully because an agile project manager focuses more on leadership than traditional management. In some projects and agile frameworks, this figure doesn’t even exist or if it does, the person in charge of this role shares the traditional project management responsibilities with other roles such as product owner. Also can be an advisor on the adoption and understanding of the agile approach. In very small projects can even have a role as a developer, but this practice is not recommended.

The Agile team works in short iterations

Already mentioned this in previous posts, in agile projects, there is not a phase delineation too marked. There are not an exhaustive establishment of requirements at the beginning of the project followed by an analysis, there is not architectural design phase for the entire project. Once the project really starts, all the work (analysis, coding design, testing, etc.) occurs together within an iteration.

The iterations are done within a previously delimited time-space (timeboxed). This means that each iteration is completed is the agreed time without excuses, even if the planned functionalities are not finished. The iterations are often very short. Most agile teams use iterations between one week and four weeks.

The Agile team release something every iteration

Something crucial in each iteration is that within its space of time one or more requirements are transformed into codified, tested and potentially packageable software. In reality, this does not mean that something is delivered to the end users, but it must be possible to do so. The iterations one by one add up the construction of only some functionalities, in this way an incremental development is obtained by going from one iteration to the next.

Because a single iteration usually does not provide enough time to develop all the functionalities that the customer wants, the concept of release was created. A release comprises one or more (almost always more) iterations. Releases can occur in a variety of intervals, but it’s common for releases to last between 2 and 6 months. At the end of a release, this can be followed by another release and this one can be followed by another, and so on until the project is finished.

The Agile team focuses on business priorities

Agile teams demonstrate a commitment to business priorities in two ways. First, they deliver functionalities in the order specified by the product owner, which is expected to prioritize and combine features in a release that optimizes the return on investment for the project organization. To achieve this, a plan is created for the release based on the capabilities of the team and a prioritized list of the new desired functionalities. For the product owner to have greater flexibility in prioritization, the features must be written down minimizing the technical dependencies between them.

Secondly, agile teams focus on completing and delivering functionalities valued by the user instead of completing isolated tasks.

The Agile team inspects and adapts

It is always good to create a plan, but the plan created at the beginning does not guarantee what will happen in the future. In fact, a plan is just a guess at a point in time. If you live persecuted by Murphy’s Law like me 😀, there will be many things that will conspire against the plan. Project staff can come or go, technologies will work better or worse than expected, users will change their minds, competitors can force us to respond differently or faster, and so on. Agile teams see that each change represents both, an opportunity and the need to update the plan to improve and reflect the reality of the current situation.

At the beginning of each new iteration, an agile team incorporates all the new knowledge obtained in the previous iteration and adapts accordingly. If a team learned something that is likely to affect the accuracy or value of the plan, the plan must be updated. That is, perhaps the team discovered that they have overestimated or underestimated their ability to progress (capacity) and that a certain type of work consumes more time than previously thought.

In the same way, the plan can be affected by the knowledge that the product owner has gained from the users. Perhaps because of the feedback obtained from a previous iteration the product owner has learned that users want to see more of some kind of functionality and no longer value so much that they had considered. This type of situation can alter the plan, so you have to adapt it to improve its value.

Sorry about my English I’m not a natural speaker (don’t be grumpy, help me to improve).

This is all for now folks, I hope this can be useful for you.