Extreme Programming: Short Cycles

cyclesIn our world of digital technologies, things move fast and so do the needs of our customers. Thus, as professional software developers, we have to adapt our way of working on a project, being responsive to change is key.

For this kind of development environment, some project management models are no longer up to the task, like the Waterfall of the V-Model for example. To follow the Agile Software Development Manifesto, Extreme Programming (X.P.) is based on short development cycles.

By doing so, the development teams are able to produce new features for their products at a regular interval. The short cycles of X.P. are all about feedbacks, with them you can focus on the tasks/improvements that will provide the most value for your customers and for your company.

X.P. defines two “high-level” cycles for the development process, the iteration plan and the release plan.

The Iteration plan

An iteration is a period of time (1 to 3 weeks) during which the development team work on a set of user stories defined during an iteration planning.

The features to work on during an iteration are picked by the business analysts depending on the budget the team has. In this case the budget represent the amount of work the team can achieve for the given period.

When the next iteration is defined, the feature to produce should not change nor the priority of them. This way the developers can cut the user stories into different tasks and focus on them.

The Release plan

The user stories completed by the development teams have to be released in order to improve the products and to add value. This is defined during a release plan.

A release contains the work of several iterations, the user stories are chosen during the release planning and as the iteration planning the amount of work to achieve should not exceed the budget the teams have. The order of implementation of the user stories is defined for the release at this moment.

Once a release plan is defined the first iteration of it can be planned as well. The content of a release can change, some user stories might be cancelled, others might be introduced or the priority for some might change. Yet this should not have impact on the current iteration.

Extreme Programming like others “agile” methodologies is focused on delivering value at regular interval. To do so it requires short development cycles to allow feedbacks to happen regularly by releasing new features quickly. This is achieved by defining a release plan and several iteration plans in it.

See you next time!

Extreme Programming: User Stories

user-storyAs professional developers, our role is to write high quality code within our applications. Yet this is worthless if it does not provide any value to our customers.

There are not much companies that will hire you to let you work on whatever you want. These businesses have customers that need new features and improvements in the software they buy and use.

It most cases you will work in an industry you know nothing, or almost nothing about. But don’t worry, you will work with people who know it, the business analysts. They know how to provide value for their customers and they need talents to implement it: YOU! You form a whole team.

In order to ease the specification and especially the prioritization of development in an “agile” environment, you can rely on user stories.

User Story

A user story describes a single requirement for the system. It is expressed by the business team and it generally written as a sentence matching the following format:

As a <role>, I want <goal/desire> so that <benefit>

The details are not defined within the sentence because they are likely to change with time even if the main goal will not. Details are discussed during conversations between the business analysts and the development team.

The use of user stories allow the developers to be able to provide a low risk estimate and by extension a budget for the feature. It is focused on the user needs, specific technology details should be excluded (data base schema, algorithm, …).

The role

In the sentence describing a user story a role is defined. By doing so you are able to detect the user of the system. It is likely the person who will know all the details you need to complete the task.

If the user story needs a new User Interface (U.I.) and this person is the final user of it, you should ask him how he wants to use it. Because I think that a UI providing the goal of the user story but with a really bad User Experience (U.X.) is not as valuable as it should be.

The goal

In a user story the goal is the new feature that needs to be created. It defines what the final customer/user wants and needs. This is the part of the system that needs to be well crafted, from a code perspective and from a user experience perspective (see previous section).

The benefit

The last part of the user story describes the benefit. This way you can understand the value it provides to the customers/clients. It can also describes the final result and if you know it, you can test it!

If the benefit of a user story is hard to write down maybe it means that it is not as valuable as you think it is. And therefore there might be others user stories to prioritize first.

In an agile environment such as Extreme Programming (X.P.) the use of user stories allow the business analysts to express their needs for the customers without writing an entire documentation containing every details. They are focused on the user, the goal and the benefit. This way the development team should be able to properly estimate it and they gather the details using a good communication in the whole team.

See you next time!

Image credits:


Extreme Programming: Whole Team

whole-teamExtreme Programming (XP) is one of the agile software development methodologies. Therefore it focuses on short development cycles and to do so it has defined several practices to follow when working with it. In this blog post I will introduce the first one: Whole Team.

As a professional developer I firmly believe in collaboration among a software development team. I believe that is by working together that we are able to create more valuable products.

The developers, the testers, the project manager and the business analysts (sometimes called “product owners”) have a common goal: product value for their customers. This is why they have to work closely with each others and they should be able to speak with each others easily, a good communication is mandatory.

Every role is important in the organization and everyone as a part to play in the project. The business analysts know what has to be done, they represent the customers needs. The developers know how it has to be done, the testers ensure that the quality standards are met and the project manager makes sure that everything runs smoothly.

I know that all of this makes sense, yet sometimes I feel like the common vision is lost in a software development team. Maybe you have experienced the well-known “programmers vs the business” work environment, or maybe the “developers vs testers”.

I know that I have experienced similar situations and I was part responsible for it. Because I only had consideration for my world, where coding is king and everything else is secondary. Now I keep in mind the “big picture”: creating value for the clients. It still requires writing well-crafted code, it is my role in the team. I have to make my teammates understand my point of view and I also have to understand their.

When working in an agile environment, in Extreme Programming for instance, you have to keep in mind that you are part of a whole team. Everyone as a role toward the creation of value.

See you next time!

Image credits: