Agile for Freshmen: January 2012

Saturday, January 14, 2012

The Art of Gathering Requirements

On the Waterfall model, software requirements are gathered together with the customer on the beginning of the project, and become pages and more pages of documentation. However, customer’s needs and wishes changes during the project, thus, lots of those requirements gathered, in most of situations, have already been developed, are lost.

Instead the Waterfall model, on Agile, requirements, wrote down as user stories, are gathered all over the project. In addition, Agile methodology values the face to face communication. When it doesn’t happen, the requirements were gathered ambiguously and wrongly. A good example of this is illustrated bellow.

User stories are short descriptions of functionalities that the customer wishes in its software. Generally, they are write in small index cards, in order to write just the necessary on that in a low level detailed, because the stories tend to change over the project. Some stories, called constraints, act as checkpoints/test criteria on the project.

User stories can be gathered through some ways:

User interview
Questionnaries
Observation
Story Writing Workshop

Story Writing Workshop

A story gathering workshop can be composed by the follow steps:

Get everything on the table

Identify the customer
Define the Project
Create the inception deck
Analyze the NOT list – a document, part of the inception deck, which is defined together with the customer, in order to specify what’s in and what’s out of scope on the Project, as well as those customer’s expectations that haven’t been decided yet. It’s important to keep the team focused on the real desire of the customer.

Brainstorm

Define roles and personas
Create mockup screens
Create flows and other design elements

Write the user stories
Brainstorm everything else

Create User Acceptance Tests (UAT)
Create the production support documentation

After these steps, everything should be writing down in cards and then they must be prioritized and treated as deliverables for the project. As we are talking about Agile, all these deliverables will be splitted into iterations and, working together with the best practices of Agile methodologies, will ensure the quality of the product and the client satisfaction.

Sunday, January 8, 2012

Kanban Resources

Follow bellow some resources to get start with Kanban. Enjoy!

Books:

1. Kanban: Successful Evolutionary Change for your Technology Business

2. Custom Kanban: Designing the System to Meet Needs of Your Environment

2. http://www.kanban101.com/what-is-kanban/

3. http://www.methodsandtools.com/archive/archive.php?id=104

4. http://agile.dzone.com/news/defining-kanban

Kanban - An Overview

What is not Kanban?

A project management method (like Scrum)
A process (not necessarily)
Iterative

So, what the hell is Kanban?

Kanban (kahn-bahn) is a philosophy created by David Anderson for product development that has been applied for software development for about nine years. It isn’t restricted to the approach to the Lean Concept of Toyota Production System, though it follows its directives, like the continuous flow and also the improvement, through a culture called Kaizen.

Its goal is to help the team to make an efficient delivery of value over the project, through some purposes:

makes the supply chain process visible to everybody,
limit the work in progress (WIP)
help work to flow

The practice of limit the work in progress makes the process different from the cascade model, where lots of work is done and no value is delivered. This is a good way to identify bottlenecks and improvements points, as well as to avoid the buildup of tasks in some point of the process.

The main idea of Kanban is to not think about time boxed iterations, but to have a continuous process. It values the team collaboration and support them to have focus and a sustainable pace.

The definition of Kanban in Japanese is related to billboard, wall – stuff that, through a mapping on the supply chain, makes those visible to everyone.

Some stories are selected on the backlog to be sticked on the first column of the production line shown on kanban using post-its, for example. This production line is defined by the team members, who are responsible for the many steps of the project, like development, quality assurance, infrastructure and so on. The first step located on the left of the kanban shows the stories to be built, and the first one located on the right of the kanban shows the stories that was done. During the course of the project, these stories will move over the wall, from the left to the right, and more stories to built will being sticked, but always respecting the WIP limit.

Kanban doesn’t prescribe roles, there’s no a specific role to perform a determined task. Then, it’s less prescriptive than the software development methods, like Scrum.

For an organization that is getting started with Agile, the use of Kanban should be a great way to start – it is easy to install, softer, can be used in conjunction to any software development lifecycle, like Scrum, XP and Waterfall, and is less invasive than Scrum, for example, which causes a strong impact on the organization – changes the hierarchy and the roles. For this reason, Kanban should have more chances to be accepted because it can be it can be adopted gradually, and also helps the team to see the process like a queue and not like a network.

The project that I’m working, the team prefers to use RUP with the Waterfall model. By studying Agile, I’ve tried to convince them to use this set of practices, but they were still quite resistant to use it. Then I tried to start using Kanban, and it worked! After that, we started to use some of the practices of XP, and I hope I got some other advances over the time.

Monday, January 2, 2012

Scrum - An Overview

In opposite what most people think, Scrum is not a process. It’s a framework for Agile Project Management.

Scrum splits the organization into small, self-organized and cross-functional teams, and the work into small and concrete list of deliverables organized by priority and estimated effort for each task. This framework organizes the time of the project, by sorting the work into iterations. For each iteration, the goal is to deliver a functional code to the customer, get his feedback and then update the release plan and its priorities, and consequently, make the process optimized.

There are two figures that support Agile Development Teams – The Scrum Master and the Product Owner. The Scrum Master is seemed like a coach who helps the team to reach the highest level by using the framework. The Product Owner acts like the customers/users, in order to help the team to develop the right product.

An Agile project starts with a list of features to be developed over the iterations, which are organized on the Product Backlog. Each iteration on Scrum is called Sprint, and it doesn’t have more than a month long to deliver the features (shippable features - coded and tested). Each Sprint starts with a Sprint Planning Meeting in which the Product Owner prioritizes some features of the Product Backlog for another “to-do” list for that Sprint, called Sprint Backlog.

A DailyScrum Meeting is made day by day over the sprint and requires the attendance of all the team members. And then a Sprint Review is done by the end of each Sprint to show to the customers, stakeholders and other interested people on the project what functionalities were made and also to get some feedback that will be helpful for the next Sprint.

Another Scrum’s artifact is the Burndown Chart, which provides a better overall view of the project’s progress, showing it in the form of story points completed, as well as changes to the number of story points planned for the remainder of the release. It’s a great way to show to the customer when the work is on date or late, and help the team to plan the next Sprints in case the team would not be able to build the planned features within an iteration. These charts should be big and posted in visible areas where everyone can see them. You can see below a sample of a Burndown Chart.

There are some Burndown Charts Templates to help the organization start to use this artifact.

There's another artifact widely used, called Burnup Chart - it's more complete than Burndown chart, because it shows two measures that a Burndown Chart doesn't: how much work has already accomplished on the project and how much work is remaining. Some people say that the first one is easier to understand, and should be better to use it to get start, however, the Burnup Chart is better to track velocity, find trends through the past iterations, as well as predict the completion date of the activities of an iteration.

Then, although Burnup Chart are more complicated than Burndown Chart, it shows essential information that is kept hide on the last one, and avoid the team to discover late a possible delay.

So, instead of a large group, spending a long time building a big thing, Scrum helps the organization to have a small team spending a short time building a small thing, but integrating regularly to see the whole.