Posts Tagged ‘agile’

Game – Test small, test often

September 15, 2011

This is a game to demonstrate Testing small and Testing often is more affective. Take any building blocks. I used Jenga wooden blocks.

I chose 36 Jenga blocks and numbered them from 1 – 36. I asked one person who is pretending to be a Developer to build a structure with the blocks:


  1. Build a structure that is at least 3 stories taller.
  2. Use all the blocks.
Something like:

I asked upon another person who is pretending to be tester. I gave four random numbers between 1 and 36 and told her they are problem blocks. We are going to play three rounds:

  1. Round 1: Tester is allowed to come and verify the built structure only after the whole structure is built. Tester points out problem blocks and the developer need to get rid of them and comply with the requirements.
  2. Round 2 : In this round the tester is allowed to point out the problem blocks after every 9 blocks (one fourth) are put in. So, tester gets 4 opportunities to give feed back.
  3. Round 3: Tester is allowed to work with the developer as he is building the structure and point out if he is using a problem block.

What did we learn:

Tester and developer when worked together, delivers high quality software with less rework. The first case depicts water fall where testing happens after the software is built. If the bugs found are more fundamental (like blocks in the first level), the project will be delayed more.

In the second case, feedback is faster. Developer could correct the code early and there is less risk than the option 1.

In the third case, it is the most agile way and the tester is helping developer avoiding putting the bugs in. It may not be possible to reach this in software development. Getting as close as possible to this level of agility is what an agile team should try for.


Test First Development is like driving a car with GPS

September 6, 2011

I had this funny thought that what if you have a GPS that tells you that you made a wrong turn only after you made a turn (I know no one will use one like that), what will happen?

Lets say you are driving around with this kind of GPS and reached an intersection. You made a right turn and the GPS beeped that it is a wrong turn. What do you do? If you are in India, you just reverse your car and take a different choice. If you are in US, you may have to find a “U” turn and come back to the intersection and then make another choice.

When we don’t do Test First Development this is how it feels like.  Every time a bug is found, developer needs to figure out what and where to fix. This could take a significant amount of time, depending on how well the code is designed.  Of course, GPS is pre loaded with maps and a developer needs to create his own GPS (executable tests) before starts his journey (coding).

Once a bug is found, developer has two choices:

1)   Some how quickly fix it. This is very likely, if the code is not well factored, since it could take lot of rework to fix the bug. If the developer is in a hurry, he wants to patch it up and move on. This is like in Indian scenario above where you could bump into on coming traffic or someone and create a bigger mess, that leave the code in an undesirable state.

2)   Take the right path by re-factoring the code and place the fix , which takes longer.

Test First development helps reduce number of bugs since the code is driven by executable tests and also helps fixing the bugs, if found, easy since the code is better designed.  Here the tests are the GPS for coding and helps you reach your destination faster.

Hope, this makes sense!

Try first.. then test

June 6, 2011

Testers who are new to agile software development often struggle to find a way to test the code in smaller pieces. This is mainly because they are trained to test only after everything is done. It is big change in mindset for them.

I think testers should take an approach that they are just trying to see if the code works. Though they might be really testing it, an “I am just trying to see… “ mindset will make them loosen up from the formality of entering bugs etc. Every time the developer says that something testable is checked in, tester should try it and inform developer if it doesn’t work. This notification could be as informal as telling the developer at the water cooler or send an email or add a task card to the task board.

Once tester has tried the functionality enough times and gained confidence that the functionality is mostly working, she could do more formal testing. However, at this point, testing the standard cases should be a breeze, and that allows tester to spend more time on exploratory testing.

Sure, this causes fewer bugs to be entered in the defect tracking system, and some testers seem to be concerned about that. One tester told me that her performance review is based on how many bugs she entered. I think it is a really bad thing to use that metric. In this situation, probably the tester prays for her teammate (developer) to fail, so that she can have a better performance review. All members
of a team should have common set of goals rather than conflicting ones.

Another concern I’ve heard is that if you don’t enter bugs, you can’t control the quality. That doesn’t make any sense, because at the end of a sprint, if you don’t have any bugs to enter, the code is of highest quality.

Happy Testing!

Self-Organization makes ‘Agile teams’ more agile!

April 5, 2011

We talk about self-organization is one of the most important aspect of agile teams. But what is self-organization and how does that happen? Is it easy or hard to self-organize? I get lot of questions like this from teams.

What is self-organization?

A self-organizing system reorganizes itself based on the external stimulation. There could be several possible arrangements when they reorganize. Number of possibilities is limited by the constraints added to the system.  Some of the characteristics of a self-organizing team are:

  1. Team is conveyed what needs to be done. Team understands the vision for the work that needs to be done as a whole, not just the work associated with one member.
  2. Team is empowered to make decisions on how to best perform the task. However, the “Power comes with responsibility”. Team members understand the rules of the team and stick with it.
  3. Team quickly reacts to any unexpected events. This could be change in requirements or change in the team itself, like some one in the team leaving the company.
  4. Leader of the team adds or removes constraints to the team to stimulate it arrange in an optimal way.

Probably, a lot of people are wondering how to transform their team, which has been operating in a command-and-control mode, into a self-organizing team?


I did an exercise in one the local agile meet ups with around 25 people. I made everyone to stand in rows and columns at an arms length. This is the initial setup. I asked every one to chose two people from the group. They are not necessarily their neighbors.

When I say start, they have to move to a position, which is equidistant from the two people they chose. They have to keep moving since the two people they chose also keep moving. So, every one keeps moving until every one reach a position that satisfies the requirement of standing at the same distance from the two they chose. This depicts a self-organizing team, which reacted to a given requirement.


The result was not so perfect, but they got the idea. Every one who participated tried to adjust them to meet the requirement. I noticed couple of issues here. People got too close to each other and started step on each other’s toes and some people made sudden and big moves, which caused the whole group to reorganize again.

This tells me that we can’t just have a group of people together and expect them to self organize. The team members need to be mature enough to self-organize. They need to understand the whole team well.

What would happen if I assigned a manager to the group and ask him to give command to each and every person where to stand. That would take forever for the manager to finish the work. Also, the out come would depend on how good the manager is rather than how good the people in the team are. If we added more requirements, the complexity probably increases exponentially for the manager to finish the task.

Have a good leader:

Before you have a self-organizing team, you need to have a good leader to groom one. Managers need to develop good leadership skills and understand the dynamics of performing teams. Managers need to let the control go and spend the time in more value-added tasks. They need to trust the team members on what ever they are hired for.

Groom a team:

A leader needs to take the team through the classic team building phases of “Forming-Norming-Storming-Performing”.  As the team is in forming phase, the leader needs to encourage the team members on team dynamics like:


Communication between the members of a team is the most important aspect of self-organizing team. The leader of the team should encourage the practices that encourage communication. Some of the agile practices like planning poker for estimation, all planning activities, pair programming, daily stand up meetings help increase the communication among the team members.


Every member of the team needs to establish their credibility so that the rest of the team would have confidence in them. For example, if I know that my architect is credible with his designs, I won’t think twice to go ahead and implement them.

Understand and respect individual’s values:

Every member of the team would have some values. Team needs to identify those values and respect them. If my highest value is punctuality, I wouldn’t expect any one question if I am working 8 hours or not. One thing I did was that I asked every one on my team to identify their top two values. Then I published those to whole company. Now that every one known team members’ values, team members try to stick to it as well as others will think twice before they question the team members on those values.

What’s next? We got a self-organizing team. Do we need the managers anymore? I get this question all the time that if we have a self-organizing team, should we fire all our managers? It is a big misconception. Yes, we need leaders not only to groom a self-organizing team, also to sustain. Read Mike Cohn’s blog to know why a self-organizing teams need managers.

The team I work with is a highly matured and self-organizing team and requires very little supervision.  The team continued to perform normally when the manager was on vacation for a week as well as only DBA on the team left the company. In the later case, one of the members who had the most knowledge about the databases took over the charge. Things got slowed down little bit, but the team responded well for the situation. When one of the two testers was gone on vacation for half of the iteration, developers helped with testing.

What should you do in “Technical Debt” sprint anyway?

March 28, 2011

Now that you convinced your product owner to allow you to have technical debt sprint, what should you do in those anyways?  Let us get into product owner’s shoes and think what to expect from and after the technical debt sprint. Product owner wants the team to build stories with a higher velocity or at least sustain the velocity. So, what kind of activities the team should do in the technical debt sprints to achieve this goal.

Some of the areas I see as candidates for this sprint. Are:

Code cleanup:

You might have left some unused code in the system or an unused database column is still lying around or you really want to re-factor some code that is bothering you. I am sure you could come up with a long list of these pain points, which would come in your way any time you are working in that area.

Same rules apply to testing debt also. This could include reorganizing the tests, remove unused tests and any test changes associated with code changes. The goal is that the most of these pain points are gone and the code looks cleaner and maintainable at the end of the technical debt sprint.

My team is in a technical debt sprint currently and some of the items they chose to work on are:

  1. Re-factor enums to have consistent lookup() method. In some enums it spelled as lookUp().
  2. Delete unused legacy code. We weren’t sure before if that is being used some where due to lack of automated tests.
  3. Remove the last piece of legacy code from a module. This required some coding in the new code base, however allowed us to removes 1000 lines of code.
  4. Re-factor certain areas of acceptance and web tests.
  5. Remove a database column from the table.
  6. Rename a database column in several tables for consistency.

Software upgrades:

These sprints are very well suitable for upgrading your third party software. This will allow you to start using the latest and greatest features of that software. On the other hand if you don’t upgrade the software for too long, the version you are using may not be supported any more. You need to make sure that all the dependent software is upgraded together which could require significant time.

Build features those reduce supporting activities.

The time spent in supporting activities basically not used for any features development. This supporting activity could be anything that requires your time, depending on your current situation. If you build a little features that will reduce the support time, that would be a great thing to work on in these sprints. This will allow you to spend more time on new development and will improve the velocity. Some of the tasks my team is looking at in the current technical debt sprint are:

  1. There is a long running process that doesn’t send any “Completed Notification” to users. Every time user needs to ask the engineers about the status of the process. Engineers are adding a feature to send an email to users at the completion of the process.
  2. Recently some reports were taking way longer to show up and causing production support tickets. Engineers picked up those reports to tune.

You need to be careful in picking up these tasks, since some of them could be very big and could take up the whole sprint. Team needs to look at the ROI on each task they are going to work on.

Do you have enough time?

Now you know what are the various things to work on. But your time is limited and how do you make sure that you will get maximum ROI?  There will be few mandatory tasks those you have to address in this sprint.  This could be upgrading a third party software which you delayed enough that you can’t delay it any more etc.

For the rest of the tasks, consider the following aspects:

Utility or Value : How valuable is fixing some thing would be? The fix could affect only one area of the system. This could be useful but the value is limited since that will help the future development/maintenance in that part of the system only. On the other hand, if the fix is going to be in a framework which is used through out the system, the benefit would be lot more.

Effort : Another aspect is how easy or hard to perform the task. Some tasks might take few hours while others might take the whole sprint. You need to be smart in choosing what you want to work on. My general guideline is to work in the following sequence, which is the combination of the two aspects mentioned.

  1. Easy and High Value.
  2. Hard and High Value.
  3. Easy and Low Value.
  4. Hard and Low value.

What could we learn from Cricket?

March 26, 2011

I mean, Cricket – the game that is played in most of the major countries of the world.

We had our “Agile Hyderabad” group meeting yesterday. We spent most of the time discussing about testing challenges. Most of the companies those follow agile software development has the problem of developers and testers keep “We and They” attitude.

While I was watching cricket, as we are fully into the World cup fever, it struck me that there are few things we could learn from the cricket teams. A cricket team has “Batsmen” and “Bowlers”. However, if it is required, a bowler (supposedly “none to less” experienced in batting) is expected to make few runs. Same way if the regular bowlers are not making an impact, the captain decides to use any bowling skills of the batsmen. The goal is to win the match and every member of the team strives for it.

The goal of an agile team is to deliver the quality software at the end of the iteration. The team has to figure out who does what, but the goal is to deliver the stories. Some team members would have the specialized skills like programming or testing, but they should be willing to do other activities outside their specialization also. This could be a developer performing some testing or tester fixing bugs or architect writing documentation or what ever. Agile teams need to redefine their roles and develop “We are all in this” attitude.

Moving on to a different topic, when I talk about agile way of developing software, it is big change to lot of people from how they have been building software.  People say  – “ We have been doing it for ages. Why do we do it in different way now?” Do we have to follow something just because we have been following it forever?

Long time ago when I was small, a cricket match always started with a pace bowler starting the bowling session with a new ball. It has been well established for decades that a pace bowler could make a new ball to swing and get some early wickets. To my surprise, a spin bowler started bowling session when India played against Australia in the world cup 2011. The reason why the captain took that strategy is because they don’t have enough good pace bowlers and they have very good spinners. Besides, Australia is not very good at playing spin bowling. Indian team ditched the conventional practices and implemented the practice what goes with the current situation. As a whole the team did a great job and India won the match against the odds.

In the current market conditions, the stakeholders of a software project expect that the time-to-market should be reduced to beat the competition. Organizations want to be adaptive to the market requirements. To achieve today’s market needs, an organization needs to implement the practices those work for the current conditions. Change is hard, but it is inevitable.

Why agile teams need “Technical Debt” sprints?

March 25, 2011

Lot of people asked me why do they need “Technical Debt” sprints. In my experience lot of product owners don’t see value in these sprints. I would like to make an attempt to answer that question.

Technical debt is the unfinished work due to the short cuts taken by the team to deliver a story faster. This could be due to an impending deadline or under estimated effort or what ever. It is necessary for the team to periodically clean up that code before it gets unmanageable. Some one asked me that if the team is doing a ruthless re-factoring as one of their practices, why do they need technical debt sprints? Though the team is disciplined, it is not possible all the time to re-factor, for several reasons. For example, if there is lot of legacy code with no tests around it, it would be hard to change that code.

Besides all the reasons said above, in my opinion it is a strategy how the team wants to work. The work done in a quarter or six months is going to be same whether 1) the team doesn’t leave any debt, in which case they work slowly or 2) leave some technical debt and take care of it at the end (of quarter or six months). IMO, the later choice would lead to a better outcome since the team would have a better understanding of the debt. So, I always recommend a periodic technical debt sprint in addition to continuous re-factoring.

I recently came across a game that explains technical debt and results of not paying it back. This game is designed by Software Engineering institute (SEI) and called “Hard Choices”. Read about the original game at . Basically the game has the aspects of taking shortcuts (creating debt) and paying it back (losing a turn). If you don’t pay it back, it will slow you down.

I actually played it differently. I have three players and they move with the same roll of dice. However, there are rules for each player:

Player 1: Always takes the shortcut, but never pays back.

Player 2: Always takes the shortcut, buts pays back right away (by losing the turn).

Player 3: Never takes short cut.

At the end, player 2 won as I expected. Player 1 and 3 reached the end almost at the same time.

I looked at the board carefully and figured out that if I change the positions of the bridges, I could make it event clear on how player 1 is going to suffer at the end. In this case, even player 3 is likely to reach the end ahead of player 1.

In summary, technical debt sprints are very much required to keep the backyard clean. This will at least allow the team to maintain the velocity, if not there is a big improvement.