Some thoughts on Agile Development

Last October we attended to the 4th Latin American Conference on Agile Methodologies

This event involved over more than 20 talks and workshops per day delivered by local, regional and international experts.

Here I focus on the main subjects treated and give you some tips you should not miss. Hope you find them interesting and useful!

Story Writing

Sessions in general were focused on determining a better product design figuring out the “why and who” is interested in a particular story.

Jeff Patton, who was in charge of the first keynote in the event, explained a technique used behind this concept: Story Mapping. Fortunately, and besides the amount of people who wanted to participate, we were able to attend to his workshop and gain some practical experience.

Jeff's vision about Scrum and Agile Methodologies in general is that they tend to enforce “output” during a project, i.e. deliver the biggest amount of functionality in a time-boxed period and finish stories already predicted in the backlog for that sprint. Nevertheless, he points out that's not the mean of a successful project. The goal is to satisfy the client (or the co-worker as he wants to call him/her) resolving the first needs that led him/her to actually desiring the product. The only way to accomplish this is by focusing on the project's ‘outcome’. In order to build the best product according to clients' expectations, it's necessary to work on a good release plan, understand the business and break the client role into the different stakeholders that will be taking part in the product.

Story Mapping consists in building a business flow, identify more detailed steps in the flow and establish a hierarchy between the more global steps which are going to become stories and their detailed tasks or sub-stories. Finally, the goal is to assign sub-stories to each release, mapping them with each stakeholder profile for whom the release is planned. Jeff emphasized on how important is the visual, self-organized and cooperative way of working with this technique, especially when human understanding is involved.

In my opinion, you should apply this technique in case you have the opportunity to decide on the product design. This happens in every software factory but outsourcing is not as far as you may think. If you have the chance, it's only about taking the initiative to participate and making the difference.

Regarding Zauber, it's good to confirm that we follow the right approach, getting involved together with our clients in product design and definition, acting not only as a development team, but also as product managers.

Estimation

There were some workshops introducing well known estimation techniques such as PERT applied effectively at enterprise level. Beyond the method itself, it is actually a good practice to think about 3 possible estimations for each story: the optimistic, the pessimistic and the realistic one. This is hard to incorporate but it would help a lot not only to achieve more precise estimations reducing the chance of sub and over estimation but also to identify the very true risks of the story itself.

On the other hand, there were discouraging talks about estimation. These theories are based on the new mixed methodology Scrum-ban which is the combination of both Scrum and Kanban. The new concept, following the story-points idea, is to estimate in stories' complexity or size and build a sprint according to the already known velocity team and the number of stories that can be delivered, without considering the usual hourly-men or ideal days unit. Even though this is a good approximation for reducing projects deviation and leading to a more comfortable work environment, I can't still figure out a way to apply it because clients are not yet prepared for this vision. People in general are used to work with time as their unit measure and it takes a long time to change from one paradigm to another. However, this is a nice theory to follow up and keep in mind.

Continuous Delivery

The talk exposed a truly typical problem concerning a complex and distributed architecture with frequently deploys. Features were easy to develop but integration tests and deployment consumed proportionally a lot more time leading to client’s upset and late delivery of functionality.

The team in charge decided to carry out an automatic system for test and deployment. It took them 1 month development and let them reduce their 10hs delivery time to some remarkable 20 minutes. During the talk, they explained the most important features to take into account when using continuous delivery and finally showed a demo.

The technology used for the project was: Jenkins + Plugin Promoted + Amazon. They casually mentioned they hadn't had good results with Cargo (another known plugin for Jenkins).

There was also an introduction to PAAS (Platform as a service), in particular they showed a little bit of Heroku and its main differences with Amazon.

Our advice is that, if you are about to develop or you're already maintaining a big project, you should adopt continuous delivery and choose the most suitable infrastructure between all the alternatives the market brings, taking into account your non-functional requirements.

I hope you've found this review interesting. If you want to know more about how we build software in an Agile way at Zauber, you can check Agile Software Development

.