About my latest achievements

Well, after a long time with my blog out-of-date, I have some good news: I'm joining ThoughtWorks Brazil!

I passed for a long but enjoyable and challenging hiring process, with many interviews that evaluated not only my technical skills, but also my personal profile, such as my personality, aptitude, attitude and integrity. It was the first time I felt really assessed during a process to join a company (although I haven't have many experiences with hiring process – TW will be my first job!).

For those who don’t know, ThoughtWorks is a global IT consultancy that is really well known in the software development community. It’s being one of global leaders in enterprise Agile development services and seems to work really hard to attract and keep just the brightest, passionate and talented people working there! They take pride on their hiring process and now I understand why. ThoughtWorks inspires companies and professionals around the world by delivering high quality projects and contributing to open source projects.

 I have recently accepted their offer and I’m going to start with the company in June, with an awesome opportunity of going to India to be a trainer in an “immersion” process called ThoughtWorks University. It’ll be six weeks learning, facing challenges, and meeting awesome people from different nationalities and culture! I’m really excited to be joining a company with an amazing culture and working with so many brilliant minds!

I had a great time here at INPE, where I had the chance to learning a lot during this year of experience, but now it’s time to give a step ahead and face this opportunity to move from Sao Paulo to Porto Alegre to gain maturity and have the responsibility of live alone, and the most important: to start my professional career in a company like ThoughtWorks - I could not ask for a better learning experience!

I intend to post here my experiences while I’m in Bangalore and when I have a time for it!

So, that’s it! Wish me luck! =)

Business Analysts and their roles into an Agile environment

The business analyst plays a defining role in creating a single vision for the product out of a diverse set of needs and wishes from multiple stakeholders, by enabling a diverse group of customers to speak with a single voice.

They must constantly ensure that the project is able to deliver the maximum value for customers and adapting to the business needs, and the features requested by the users align with the product’s business goals, especially as the business goals change during the time.

The business analyst has a central role in ensuring that the product screenplay clearly defines the product’s strategic alignment to the business need. The analyst holds shared responsibility in defining the strategic criteria for completion of the project.

The techniques of business analysis don’t change dramatically in the agile environment, but the timing and how they are used do. Artifacts as personas and data models, for example, continue to be employed, but are kept as lightweight as possible. Low fidelity artifacts, such as diagrams, maps, and lists, provide more value to an agile project than long, textual requirement specifications. Low fidelity artifacts are used to build the software for a specific iteration and only need to be understandable to the team during the iteration. On the other hand, Long-lived artifacts should be used beyond the scope of the development. They should be used to communicate what the software does and why it does it.

Agile offers the opportunity for business analysis to benefit from the frequent feedback provided by the business, by reviewing the results of successive iterations with the business stakeholders, having the opportunity to refine the product’s specifications and ensure they are aligned with the business, and identify and reduce risk he project as soon as possible.

In waterfall projects, requirements are developed in their entirely prior to the development phase. As risk elements are uncovered and business needs evolve, certain requirements may change or be eliminated, which results in a waste of work. By providing just-in-time requirements, there is less rework of requirements because only the requirements required for the current release are define in detail and developed.

There are a variety of ways a business analyst can be engaged on an Agile project:

• In some projects a dedicated business analyst role is unnecessary. This is not to say that business analyst is not conducted during the course of the project, only that any member, or members, of the overall development team, may do it.
• In more complex environments the analyst might be the facilitator, bringing divergent business stakeholders together and helping them speak with a single voice so the project team are not confused by contradictory and conflicting perspectives.
• The analyst might act as the product owner/customer representative where they are empowered by the business to make decisions on product features and priority.
• The analyst could act as a surrogate product owner, in situations where the business product owner not available.
• The analyst might act as the second in command to a business product owner with limited availability.
• An analyst could take the role of business coach in an environment where the business product owner in competent and committed, but has limited IT project experience and the rest of the development team are lacking in domain knowledge.

One of the key elements for a business analyst working in an agile environment is the ability to use feedback to drive change. The BA must constantly review requirements with the business stakeholders and ensure that any shifts in business needs are accurately reflected in future iterations of the product. In an agile environment, the success of the business analyst depends on his interpersonal skills as communication, facilitation, coaching and negotiation.

Acting like the “bridge” between the development team and the customer, the business analysts should constantly think as a customer, primarily on the time of:

• Acceptance and evaluation criteria definition
• Business rule analysis
• Functional decomposition
• Interface analysis
• Non-functional requirements analysis
• Problem tracking
• Prototyping
• Requirements workshops
• Scenarios and use cases
• Scope modeling
• Survey/questionnaire
• SWOT analysis
• User stories 

Agile business analysis is related to increase the delivering of business value to the customers of the project/product to be developed. To be productive on an agile team, business analysts are active participants, if not the actual facilitators of planning, analyzing, testing, and demonstrating activities.

Business analysts play a key role in facilitating a shared understanding of the business need for the project with all the stakeholders. It is the role of the business analyst to ensure there is a share, agreed vision of the product across the entire team. This requires the analyst an extremely high level of skill in communication, facilitation, and negotiation. In addition, they should have the ability to listen and understand feedback from all stakeholders and use this feedback to drive the changes required to the requirements and priorities of the project. In the agile environment, understanding and synthesizing perspectives alongside the ability to hold successful conversations replace the need for formal, detailed, long-term artifacts such as requirements documents.

In a brief, Agile Business Analysis is about ensuring the right information is available to the development team in the right level of detail at the right time so they can build the right product.

To read more about Business Analysis, I recommend the BABOK® Guide as a great source! Enjoy!

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.

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

Related sites:

      1. http://en.wikipedia.org/wiki/Kanban_(development)

      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.  

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.