Agile for Freshmen: 2012

Monday, December 31, 2012

Six months as a ThoughtWorker

That’s a long time with no posts here! I must say that I had been amazed during the last six months, after I joined TW.

As I wrote in my last post, I couldn’t ask for better opportunity - I was totally right! I like this feeling of “no regrets” that I have everyday when I reach the office. I’ll start talking about what happened after I wrote my last post. In that time I was working in a project in the national institute for space research. I got a scholarship for Jan. 2011 to Dec. 2012, the duration of the project I was working on. During my time there I applied to some master’s degree classes (Artificial Intelligence and Applied Computing) and I my job in that project was develop a framework in Java, using web services. I learned A LOT during the 18 months I worked there.

Although I was enjoying that, I was really looking for new challenges and opportunities to grow.

I found this opportunity at ThoughtWorks, I applied for a QA role, and I got really really happy when I received my job offer. It was on start of March. However, I was submitting a paper for a conference and I had a deadline to deliver part of the framework in the next months… for this reason, I asked for some time till get my new job. So, finally June came and the time to become a ThoughtWorker as well! Then I left the project before the end of that.

The thing is, joining ThoughtWorks was not only associated with leave my family in Sao Jose dos Campos, fly to another city (Porto Alegre) and start a new life over there… Accept the offer meant being hired in a day and fly on the next day to India for a 6-week immersion program called ThoughtWorks University (TWU)… It sounded a bit scaring in the beginning (mainly for my family – “whatta hell is this company that wants to send you for too far in your second day as an employee???”) _ but this opportunity made me wait desperately for June. I don’t have words to express how much happiness and anxiety I was feeling that time.

I joined TW on June 4^th, and started my journey to India on June 5^th… I’m writing another post about my experience at TWU.

My first day in the company was really funny – people invited the new hires to walk around the office, to meet the co-workers and know about the projects. It was weird – so many new faces observing us… They seemed to be planning something… maybe… wish us welcome, by launching hundreds of nerf darts in our heads? Yeah, exactly that! \o/ Definitely, it was the best way to welcome us, and it made me figure out how amazing is my co-workers

We had a day with a bunch of new hires orientation and we took the time to finish what was pending to our trip.

Six weeks later, I was back to Brazil. The company gave me some days off to organize my stuff to move to Porto Alegre. Actually my stuff were already organized, I took these days to stay at home recovering from jetlag and enjoying the time with my family and also to eat barbecue and my mum’s meal which I was missing so much!

So I moved, found a new place pretty (small) close to the office! I got assigned to one of the projects from the office and started my job as a QA.

During the first weeks it was a bit hard for me… I was far from my family, Porto Alegre’s winter is pretty different from the one I was used to, spend the weekends cleaning my place instead take my time to study and rest was not so cool, cook for myself, pay my bills, do the dishes, the laundries (mainly that time when I haven’t bought a laundry machine yet)… everything was new and hard! =)

But after a month I got used to everything. People are used to be excited about their new job just during the first days or weeks, after that everything becomes a routine and starts to let you bored… In my case was completely different – everyday in the office I face a new challenge, I meet new people (new hires and expats), I have the feeling that I had in my very first day! And that’s what makes me so happy and passionate about my job. The environment in the office is awesome, my understanding about Agile has improved a lot after joining the company - we really do Agile - it's not only about daily standups, work in pairs, send code to the CI server..it's about the way we work, the team is very collaborative, we're always sharing knowledge and another stuff that make us agile.

People in the office are really friendly, it’s possible to hear people laughing and some hipster songs playing during the day… people send spams by email inviting to a beer, to foosball and video games competitions. We work hard, but we can also have fun during and after work time!

Among the role we play into the project we get assigned to, we also have the opportunity to get involved with another activities, such as social impact programs (SIPs) that sustains TW’s third pillar – Social Justice.

In general these SIPs are projects that aim to help people and make the world a better place. Some recent projects from ThoughtWorks Porto Alegre were to help citizens to interact with the candidates on the last elections, and another one to help a village from Porto Alegre with their recycle program… that’s much more than deliver software – the coolest part of these projects certainly is to figure out how this software can change lives, make people grow and get new opportunities to make their lives better.

I’ve been a member of our women in IT group – that’s also part of TW’s third pillar, and that’s our space to discuss actions to make the company a better place for women and to attract more women to IT. I flew to Baltimore – USA on October, to attend on Grace Hopper Celebration for Women in Computing – the world’s largest event for women in computing. There was another opportunity TW gave me to spend a week at the event, attending to some talks, generally about women’s right, leadership and technical themes. I’ll post a post about GHC soon.

I’m also having a great time working on the project I’m currently assigned – and I hope I can finish what I’m writing about my job as a QA soon! (Yeah, I’ve splitted this post in another three that’s not ready yet! This is just the first part! Hahaha)

I’m having a great time as a ThoughtWorker, working with amazing people and having such amazing opportunities.

I’ll share my experiences here more often, write reviews for the books I’m reading and technical stuff that I’m learning.

Sunday, April 15, 2012

Quality Analysts and their roles into an Agile environment

Thanks to the software testing, many drastic changes have occurred on the software development – more and more the development team is getting value from testing, i.e., they are adopting test as a habit, always worried about create test cases in order to verify if what as desired was delivered.

Additionally, the concept of quality analysis in traditional software development is not only related to the write tests just in order to ensure the quality of the product. It’s more comprehensive than this. In Agile, the concept involves the effective software analysis also related to verify if what has already been developed is in total conformity with which has been specified, and, consequently, in according to the customer’s desire.

While I was searching for some references to write this post, I find a very interesting presentation made by Syed Rayhan from Code 71, about the role of a quality assurance in a Scrum project. During the introduction, he brought some questions about the effective role of a QA. I sent him an email asking for some comments about these questions, and I’ve included his answers throughout my post below.

· Is QA part of the development team?

· Can we fit QA in the same iteration as development?

· Who does QA?

· Does QA costs more in Agile as product seems to change from sprint to sprint?

· Do we need “test plan”?

· Who defines testcases?

· Are story acceptance tests enough?

· When do we know testing is done?

· Do we need to track bugs?

QA plays a dynamic role into an Agile environment – he must be active since the start of the project until the software release, working together with the developers and product owner(s) to define test cases and acceptance criteria. Although Agile testers are developers, they have a specialized set of skills.

Even though, developers can write tests (not only unit one), but QA could have the mindset to write some of the other required tests.

However, in order to increase the success rate of the project with Agile, developers and testers must be part of the development team and need to be fitted in the same iteration, it is good for testers have test automation as their core focus and not only manual testing.

A team organized like this way means more quality to the software, because it will be tested in small pieces, and the team can receive a faster feedback about what is going wrong. The picture below shows the difference between a traditional the software development model and how it could be in Agile.

Traditional Software Development

Agile Software Development

And NO, QA doesn’t cost more in Agile! It may seem that teams spend more time retesting, but it is a necessary evil. The earlier we can catch a bug, the better. We end up spending less time in the long run. In fact, with the right amount of test automation, we would spend less time in testing for the same level in the long run. QA will help the team to verify earlier if what's being developed is exactly what the customer needs/wants, as well as help to track bugs and other vulnerabilities on the software. It means less rework at the final of the project; less chances of exceed the budget and the time.

The QA role within an Agile environment seems to be contradictory, because of the tools and process used are their working tools, as well as all the documentation. But when we talk about documentation in Agile, we are referring to a lightweight documentation, e.g., acceptance tests would help the team to document what's supposed to be developed, and it's the way to have a living documentation. But these acceptance tests aren’t enough to the process: a QA must have his test cases and tests scripts as part of the documentation, in order to help the team or another QA to perform a test that has already been done, without spending time in rewriting that.

Furthermore, it’s also important the bug tracking. Usually teams track bugs after a feature is delivered. During the development of the feature, it depends on the team. Informal interaction between the QA and the developers might be easier.

I extracted a figure from the Syed’s presentation, showing the responsibilities of each role of the team in perform the different types of tests:

The quality assurance plays a critical role to the success of the project; however, it is not the key to ensure the quality. The quality is responsibility of each one of the team, since the requirements gathering till the success of the tests performed by another members of the team (devs, support engineers, performance engineers etc.).

QA works together with the developer, the business analyst and also together with the customer, gathering requirements and writing the acceptance tests, always aware of what’s been developed and ensuring the release of quality software generally every two weeks.

The picture below shows clearly the role of a QA in a project:

The main responsibility of a QA is to make sure that the right software works right.

Since the team is self-organized, QA is not a designated person’s responsibility – it’s a team’s responsibility, and they should collaborate together for the success of the project.

Thus, it’s important that the requirements are very well specified without noises in its writing which may cause misunderstandings. If it occurs, this noise should be mitigated as soon as possible together with all the others members of the team – BAs, developers etc. – this is the main purpose of Agile.

The testers know that the less time there is to test, the less they will be able to test. And the less testing they can accomplish, the less the organization will know about the software before it’s released. Less information means more risk.

Wednesday, March 21, 2012

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! =)

Friday, February 3, 2012

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!

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.