This blog is moved

I am currently building a brand called http://www.poweragile.com. As part of the consolidation, I moved this blog to www.poweragile.com/power-agile-blog. Sorry for the inconvenience.

An Estimation Experiment

Estimating work (stories) probably is the hardest part in software development. Every team I have seen seemed to struggle with it. Lately, there is lot of talk about #NoEstimates. I heard this a lot when I was at global scrum gathering, Phoenix. I was kind of frustrated that the promoters of #NoEstimates didn’t offer any solutions.

The team I work with is a matured agile team that consistently delivered to production every two weeks over last 10 years. Yet, the team struggles with the estimation. Our Scrum Master conducted several experiments with estimation techniques. However, we couldn’t find benefit that we could quantify. We have been using modified fibonacci series.

I recently suggested an idea that we tried for couple of estimation sessions and seems to work better. Here it is:

We estimated using three-point scale

Small – If the story could be done in a week

Big – If the story can’t be done in a week but could be finished in the sprint (We run 2 week sprints)

Beyond – Can’t be done in a sprint and needs further refinement

Then product owner picks a number for Small and Big story (We decided to go with 2 and 4) and establishes the velocity. Our PO and Scrum Master did some digging into past history and found that the new way of estimation leads to the velocity that is pretty close to the current velocity.

Team generally felt that it is much easier to estimate this way since they don’t need to figure out if it is 0.5 or 1 or 2. If they know it is small, that’s good enough.

We only tried for 2 sessions and still don’t have lot of data to support that this is a better technique. I would like to go ahead and post this so that other teams could try (if interested) and post the results. Also, this technique may not be suitable for while estimating bigger projects with lot of unknowns.

Good luck!

Do you write your stories right?

By now, I hope most of the people who practice agile knows what a user story is.  I observed in lot of teams that either they don’t write user stories or don’t write them right. In this blog, I will try to explain the significance of writing a user story right way so that it adds value to the product.

I am going to take an example where we are going to build a website for a restaurant to improve the business. I often take this example since it is simple and every one loves food. Of all the possible features, most important features to start with are having a menu on the website, a way to order and a way to pay. Here are some requirements:

Feature #1: Need a menu on the website

Requirements:

1. A menu with all food items and their prices are present
2. Items are sortable
3. Items are selectable by category
4. Items have their ingredients specified
5. Items have their nutritional facts listed
6. And so on..

Feature #2: Place an order

Requirements:

1. A way to select items to order
2. Shopping cart
3. Provide address to deliver
4. And so on..

Feature #3: Payment Options

Requirements:

1. Credit/debit/cash card processing
2. Pre-paid store card
3. Check
4. Direct debit from the account (Net banking)
5. And so on..

When PO and team start brainstorming about the feature, various requirements popup randomly. But the question is what exactly business needs? How do we know where to stop the requirements and what requirements are even relevant to our situation.

Let us use the prescribed story template and see if that helps us scoping the story right. Here is the story template:

As a <Who> I want <What> so that <Why>

Who: Talks about who needs this story. You need to really understand your user for this feature. It’s not the restaurant which needs this feature, but it is the user who really uses the feature. Identifying the user could is two dimensional:

1. User type: Different types of users going to use the system, like employee, employer, admin etc. In our example “Customer” and “Admin” are two user types.
2. Persona: This is a representation of certain users with in the user types, like in our example, “First time customer”,  “Repeat Customer”,  “Health Conscious Customer” could be different personas of the customer. Identifying the right granularity for the customer is very important because you could focus on what that user (or persona) cares about. You could use highest granularity like “User” or “Any User” if the feature is applicable to all users equally.

In our example, the restaurant is just starting to go online and we want to get as many orders as possible. So, we care about any customer with “First time“ persona most and build the features those are relevant to them.

Why: Once you know the user, now you need to know why you want to do this story. Do you want to get most orders or you want to promote your restaurant as a healthier brand or something else? If this is a small restaurant and at this point you care most about getting lot of orders, that’s what should be your goal. Lot of times POs as well as engineers don’t know what exactly the purpose of the story. Knowing that would greatly help scoping the story as well as coming up with effective solution.

What: Now that we know who is your customer and what goal you want to achieve, we could scope what we want. We are still talking about the problem we are solving, but not the solution itself. For our example, we need a simple menu with items and prices listed that will cater to all general customers and gets the restaurant lot of orders.

So some of the stories for the menu feature are:

1. As any customer, I want a simple menu so that I can order what I want
2. As a first time customer, I want to be able to find items easily so that I can find items quickly. (We may choose not to implement this story since the menu is not that complicated and the customer will get used to it fairly easily)
3. As a Health conscious customer, I want to see nutritional facts of each food item so that I can choose healthy food. (We may do this story when we want to address that special customer base)
4. As a repeat customer, I want to have my favorite items listed so that I can choose from what I like most (We may want to build this story as we are getting repeat customers)

We could do the same steps for features for “How to Order” and “Payment Options” which I am not going to do here.

How to choose the right solution:

Let us take the story #1 and see how we decide on the implementation. This story is addressing major customer base that just care about a simple menu.  Once engineers understand the story and it’s vision, they could come up with appropriate solutions. Some of the cost effective solutions are:

1. A static picture of the menu with a number to call.
2. An html menu, driven by a data store. This could be sortable. However, this needs an “Admin” user to maintain the data store. This solution helps in adding any future enhancements like adding a feature to click on the item that gives information like ingredients of the item etc.

Now, how do we choose between above solutions? Option #1 is very cheap and achieves the goal. Option #2 is more expensive but inline with future expansion. The answer is, it depends on what situation you are in.

Let’s say option#1 takes 1 week to complete and option#2 takes 1 month. If you go with option #1, you need to throw away the feature when you want to enhance you system. If you go with option #2 you won’t be releasing the feature for 1 month and you lose orders during that period. So, you need to do the cost-benefit analysis to see which approach to take. Some possibilities are:

1. If we are just starting out, you may want to go with options #1.
2. If we are somewhat an established business and want to go with long-term vision, we should go with option#2.
3. We could build both stories at the same time and release them, as they are ready. This is viable only if the revenues you are going to generate in that 1 month are more than the cost of building option#1.

Product owners and engineers need to go through this kind of thought process for creating and implementing all user stories.  In our example, we could go with:

A static menu card image with a phone number to order and pay cash on delivery as a payment option

Or

A sophisticated menu system with a shopping car to check out and credit card processing as a payment option

Or

Some solution that is in between

 

To conclude, you need to understand WHO, WHAT & WHY of your user story at the right granularity to come up with stories that add value to the business.

Game – Test small, test often

This Blog is moved to my company (poweragile.com) website. I don’t want you to miss the interesting content I have it there. Please make a bookmark.

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:

Requirement:

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

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

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!

Make Your Tele-team Work

Here is the article I co-authored with Lisa Crispin.

http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea

Do you understand your “Velocity”?

Velocity is a metric that is used in agile projects to represent how fast a team is building the software.  Velocity is number of story points (or what ever the unit of estimation is) finished in an iteration.  I have seen some managers using this metric in ways that is not intended for. I am going to take a crack at explaining what it should be or shouldn’t be used for.

What does Velocity represent?

Before you know what velocity should be used for, you need to understand what exactly it is. I think it is lot more loaded than it appears to be. One should know deeper about velocity to use it properly.  Velocity in a single iteration doesn’t mean much, whereas an average velocity over several iterations could answer few questions. For example, if a team’s average velocity is 10, it means that the team is likely to finish rest of the development work of that release or project or chunk of work at that velocity.  The reason I said it is “likely” because there are several factors that could make this statement wrong. It is critical for the team to understand these factors so that they make right decisions.

Team’s knowledge of the domain

The team with the higher knowledge in the domain would build the software faster.  If the project is brand new and the team that is going to work on the project doesn’t have much knowledge about that domain, the velocity would be less. Velocity will improve as the team is learning more about the domain. On the other hand if the features are enhancement to the existing system, the team probably is more familiar with the system and will have higher velocity. In either way the average velocity could be established after few iterations.

Team’s technical skill level

Team’s technical expertise plays a vital role in how fast they can build the software. This is not only the knowledge about technology and tools being used, also the architecture of the system being worked on. This would have the similar effect as we discussed above.

Clarity of requirements for the stories

If the stories are well defined, the team will have less impediments and the work will be done faster. Lot of time requirements aren’t clear at the time of estimation as well as some times at the time of building also. Team needs to work through the unknowns and resolve them on a daily basis. This will slow down the process and will reduce the velocity.  It is important to solidify the requirements before the start of the iteration for the team to maintain the velocity.

Changes to team composition

This question arises very often that what happens to the velocity if we added a member to the team. Is it going to go up right away? I don’t think so. When a new member is added, it is likely that the velocity will go down first. This is because the current team members need to train the new member. It will eventually go up. It is hard to say how many points it will go up by. It depends several factors. This includes the experience level and attitude of the new member. Since agile teams are collaborative, each member would have an impact on the whole team. For example, the new member could be a leader and inspire every one in several ways. This will have a positive effect on the team. On the other hand the new member could be a whiner and cause head ache to the whole team in which case the velocity is likely to go down.

Support activities team performs.

If team is engaged with support activities like productions tickets and fixing bugs, their velocity of developing software will go down. If these supporting activities are not controlled, eventually the velocity will go down significantly.  As the team is building more code, it could increase the supporting activities also. This could be because of cutting corners while developing new features or improper implementation of the features themselves. It is critical to identify this (Technical Debt) and correct it as soon as possible. Read my blog post on Technical Debt.

Corporate culture

Corporate culture is a big factor in the team velocity. This includes the processes, policies etc. If the team has to work in a tightly controlled framework, the value added tasks would be less and hence the velocity will go down. So, the team’s velocity is the points per iteration in that corporate culture. Everything else being the same, if the same team is working in a different corporate culture could increase or decrease the velocity. The organization needs to understand this and change the culture such a way that it fosters agility across the organization.

The velocity of a team represents its productivity considering all the factors talked above.

What should you use velocity for?

In general, the team should watch and learn from the velocity.  Velocity should only be used for planning purposes. Completion of a project could be predicted if the team’s long-term average velocity is known. However , this prediction would be more accurate if the factors affecting the velocity stay relatively stable.

What shouldn’t you use velocity for?

Team member velocity shouldn’t be calculated from the team’s velocity.

In a true agile team, more than one member work on a story. A developer, tester, possibly a DBA and a SysAdmin spend their time to complete the story. It would be inaccurate to try to compute an individual member’s velocity.

Velocity shouldn’t be used for performance reviews.

If velocity is part of the performance evaluation process, that could lead to inflated estimates by the team. Team performance should be evaluated using some other means like peer review or 360 degrees review.

Don’t expect team to have the average velocity in every sprint.

Product owners need to understand that the average velocity is not guaranteed in each and every sprint. If the team’s average velocity is 10 points, they shouldn’t wait to plan mandatory 10 points in the iteration. Features should be planned well ahead of their required delivery date.

Past velocity can’t be used as basis if the context changed.

If the teams velocity can’t be used as basis if one of the factors discussed above changed. For example a team’s velocity in one project can’t be used as basis for a different project unless same team is working on the new project and they have same level of knowledge about the new project.

True Collaboration!

Last week we had an issue in production. One of the reports was hitting the servers pretty hard. Our “Production support monkey” (all developers rotate this job every sprint) mentioned the problem in the standup meeting.

“The problem is that this report could be run for any date range and taking lot of time. Mean while user is clicking on the submit button multiple time that caused several instance of the report running.”

Soon after the standup meeting was over, engineering manager sent out an email with details of his research on who requested the report and how many times it was requested etc. This email went to whole engineering department.

DBA did some performance tuning to database and sent out an email with the test results of his change.

System administrator sent an email offering a shell scripting solution to monitor multiple running instance of the report and alert if they are running for too long.

Developers already thinking of couple of simple fixes to avoid user clicking multiple times. Team has all the knowledge and working on a integrated solution.

Points to note:

1.     Every one knows about the problem. This was automatic since everyone comes to standup meeting as well as everyone gets the emails.

2.     No one assigned any task to anyone. Everyone shared the responsibility and offered a solution from their side.

That’s what I call “True Collaboration”!

Self-Organization makes ‘Agile teams’ more agile!

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?

Exercise:

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.

Observation:

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:

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.

Credibility:

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 http://blog.mountaingoatsoftware.com/the-role-of-leaders-on-a-self-organizing-team 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?

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?

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?

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 http://www.sei.cmu.edu/architecture/tools/hardchoices/ . 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.

 

How to Choose a Scrum Training Program?

With so many agile certifications, trainers and training companies around, are you confused with where to go and what to do? This article could help in deciding your path to learning, instead of wasting money, time, and energy in the wrong places. Why is this important in the first place? Lot of people I talked to seem to struggle in deciding and often make wrong choices. Here are some of the comments/questions I hear:

• “I don’t know how this certification is useful for me”
• “I have no idea who the trainer is”
• “What all other certifications I should do?”
• “I came here since my manager sent me, I just need the certification”

I recently talked to an Agile coach who was looking to hire a ScrumMaster. He told me that he rejected 130 candidates who don’t understand the basics of Scrum. They are all certified! Imagine you have a certification but no knowledge. First of all, you will flunk the interview. Even you got the job somehow, you won’t be able to perform to the expectation of the organization. So, it is important to give careful thought to how to get value for your investment!

Start with “Why?”

When people come to me and ask what all certifications they should do, I ask them “what do you want to be?” Most of the time I get a blank face. Knowing what you want to be is the first step. Do you want to be a great technologist? or a Great Leader? or you want to be a visionary for building great products? Without understanding what you want to be, you might be putting your investment in the wrong places. If you can’t reflect by yourself, ask a coach who can help you reflect.

Where to get knowledge?

You can always learn by yourself by reading books, watching videos, or online courses. However, attending an authentic training program definitely will jump-start your journey. Getting a certification is more to showcase that you have the knowledge when you are finding a job or going up in the ladder in your organization.

If you decided to get a certification in the field of choice, research the certification bodies which are authentic. As far as Scrum is concerned, ScrumAlliance.org and Scrum.org are definitely authentic. How do you choose the certification body? The value of the certification depends on the awareness of the certification in that region. You can check what most people are doing or ask a mentor.

How to find Workshops?

After deciding the certification go to the website of the certification body where usually all the courses are listed. Find the courses in your city using the search function. For example, all the Scrum Alliance courses could be found at https://www.scrumalliance.org/courses-events/search?rad=30&pg=1. When you search for the course in your city, probably you will see many sessions listed for various dates by various trainers or training companies. You may find these courses on other websites of training companies. Be cognizant that some of them may not be authentic. So, sticking with the certification body is always safe.

How to find the right trainer?

This is where I suggest you need to be careful. You should always look for who is the trainer, not just the training company. The reason is that the training companies could be marketing companies who are just aggregators. They won’t have any subject matter expertise on Scrum or Agile. These training companies work with multiple trainers and can change the trainer on the fly. So you don’t know until the last minute who is your trainer.

What is more important is the trainer profile. Research who is the trainer? What is their experience? Are they thought, leaders? Who do you feel you can connect better with? But, how do you know all this information? Read their profiles on the certification body website, look at their LinkedIn profile, check if they write blogs or articles. Read a couple of articles to see how you feel. Check what others are saying about this trainer. Even better, contact the trainer and ask questions. If you are planning on taking a long journey in the career you have chosen, look for the trainer’s ability to take you all the way. Some trainers help their students through user groups, mentoring programs, and coaching. These are all important information to consider.

Once, you chose the trainer, it is straight forward to register for your convenient date and city. Though we are all sensitive to price, that should not only be the decision-maker. Don’t lose the value for your money just for a small discount upfront. The process may seem lengthy, but it is important to go through to get the most value for your investment.”

You can find all about me on my PowerAgile website and the courses I offer!

Whose job is it anyway ?

Teams those newly started with scrum get into the role dilemma of who should do what. This is pretty common since their roles in earlier way of working probably are clearly defined. In traditional projects, the lines are drawn clearly and people won’t cross those lines. Here are few questions I got in my interactions with new scrum team members:

“A development manager asked me whether he should tell his team that they are going in the wrong direction. He knows that they are going to fail but he was told that there are no managers in scrum teams”

“A Scrum Master asked me that who should update the burndown if he is on vacation. He used be a project manager and used to running around and getting things done. He said, people always dumped all coordination work on him though they could have done it themselves.”

“A team member told me that their last sprint failed because they were waiting on some question to be answered by a different ream and the Scrum master was on unplanned time off who is supposed to follow up with that team.”

This reminds me a story I heard from one of Craig Larman’s talks. This is how it goes:

“You are an American football played and you are standing at 98 yard line with ball lying right in front of you. All you have to do is pick the ball up and carry it 2 yards to get the touchdown. You pulled your business card and looked at it. It says you are a ‘Kicker’. What would you do? You could carry the ball 2 yards and get the points or wait for someone else to do it, since your job description doesn’t include running the ball.”

This is probably why scrum kept very few roles. If you can do something that will help the team succeed, then just do it. It is all about willingness. I have seen developers regularly testing, testers occasionally fixing bugs in code and team members facilitating meetings when scrum master is on vacation.

If you can do something that will help your team succeed, you are INCLUSIVE!