Agile Buddha - Page 16 - Demystifying Agile, Getting to its Core

Agile Testing: An Approach to Achieve Quality Sooner

Often I hear from testing folks one question. How can I apply Agile for testing? Local optimisation has been the bane of software development – viewing it from his/her activity perspective and not just as a whole. Let’s see how agile principles can be seen through testing angle?

Image Source: www.testobsessed.com

Agile is Not Ad hoc

by Avienaash Shiralige Leave a Comment

Recently, I was asked to attend a leadership meeting in a company. They had representations from different business units and groups. When we hit the topic of agility within the organisation, one of the directors immediately jumped into the conversation and said his projects are very agile in nature. That made me curious and I asked him what do you mean by that. He said,

My team take change requests everyday, we don’t do any documentation, we re-plan almost everyday to tune to new requirements from the clients and on…..

[Read more…] about Agile is Not Ad hoc

Metrics to Build Great Agile Teams: Measure Influence, Not Control

by Avienaash Shiralige 17 Comments

Couple of weeks back, I noticed an incident that triggered this post. Senior Management in a company applauded people for showing individual heroics on the project.

Some of them were:

Staying late in office to address a client request?
Responding to project emails at late night..
Rewarding testers on number of bugs found and more.

And then, managers shared this privately with rest of the organisation too. Treating this as accepted, rewarding behaviour invited more such incidents and frustrated many of those who don’t do this. Below comic strip summarises it well.

“You Will Get What You Measure(or Reward)!”

I recently heard an another incident of how testing team kept an very important bug under the carpet before bringing it up just a week before release, and then getting rewards for the same. Such behaviours more likely are the candidates for root cause analysis than rewards.

Story Points and Man Hours – When To Use Them and Why?

by Avienaash Shiralige 4 Comments

The debate about why story points why not time goes on wherever I go for conducting coaching workshops. Hence I thought of sharing few more thoughts today.

Previously we had sizing techniques like Function Point Analysis, but it was tough to understand/implement by everyone and hence was restricted to experts ONLY. But estimation is an activity to be done by people who are going to work on it. Hence a simpler sizing technique was needed so that everyone(developers, testers) can understand and use it easily.

Story points is a very powerful sizing technique. It has various advantages as I mentioned in my earlier articles.

Story points estimation using planning poker which is based on Wideband Delphi method helps to arrive at consensus based estimates using collective intelligence – Wisdom of the Crowds.

Story Mapping and/vs Process Maps

by ShriKant Vashishtha 18 Comments

One of the key philosophies of Agile software development is to have information radiators visible on the wall so that the progress of the team as well as what team currently is working on gets clearly visible to anybody who visits to the team area. That includes stakeholders, project managers, team or anybody from the organisation.

However, haven’t you observed that many times, as you look at the card-wall (Scrum Board), things are not very clear to you. Card wall may look like the mesh of user-stories with statuses in To Do, In Progress or Done. However some of the bigger questions are not clearly answered by just looking at user-stories.