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

measure quality

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.

Hurry and Read the rest of this post!

{ 7 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.

  1. Agile Estimation: 9 Reasons Why You Should Use Story Points
  2. Agile Estimation: 8 Steps to Successful Story Point Estimation

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.

agile estimation - collective intelligence

Hurry and Read the rest of this post!

{ 4 comments }

Story Mapping and/vs Process Maps

by Shrikant Vashishtha

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.

Hurry and Read the rest of this post!

{ 9 comments }

Demo is an integral and important part of Scrum ceremonies. Important because that’s the whole point of being Agile. You get early feedback from Product Owner and stakeholders and fine-tune the product if required. Also this is sometimes the only occasion for offshore team when sponsors and business actually get to see the real contribution of offshore team. There are valid reasons also when someone from onsite team gives the demo. They include:

  • Language problem. I worked with a French team in which stakeholders and business were more at ease to talk in French.
  • Completely opposite time-zones which may not allow a lot of collaboration.

The advantages of distributed demo far outweighs the ones of onsite demo.

Hurry and Read the rest of this post!

{ 0 comments }

Genchi-Genbutsu is the Japanese expression for a practice of finding your answers right down at the source, rather than relying on second-hand reports or charts of data to achieve true understanding. This practice emphasizes going to a place(gemba) where you watch, observe and ask “WHY” five times. I shared few posts earlier on 5 Whys.

Most of the time we are hidden in our project plans and design documents to find root causes. Traditional methods assumed that having a great plan and good documentation is the secret to project success. They alienated themselves from implementation and real world.

Agile Go See and Confirm.

Agile, on the other hand, believes in delivering some thing early on to confirm our understanding. It inherits the expression Genchi-Genbutsu.

Hurry and Read the rest of this post!

{ 4 comments }

Let’s take a scenario.

You have a product owner at distributed location but somehow he is not able to provide sufficient time to distributed team. Because of that team doesn’t get enough understanding of user-story.

Does it sound familiar?

Mostly it’s about PO getting involved in too many other things. That results in not having user-stories READY, analysed or communicated properly.

That brings another question related to suitability of people assigned for PO role. Not everybody is good in analysing and writing good user-stories.
Hurry and Read the rest of this post!

{ 1 comment }

Off-shoring in current market is a global economic and strategic need. Building Agile Offshore teams across boundaries and time zones is a different ball game. It has its fair share of challenges to work with. I shared few of those challenges and a possible approach to take in my earlier articles.

1. How to Address People and Communication Challenges
2.Distributed Agile:10 Best Practices of Successful Teams
3. Distributed Scrum: A Day In The Life Of A Distributed Team

Proxy Scrum Product Owner

 

 

 

 

 

You need to make few changes along your way to your normal routine to make it work. One challenge I often see is integration of offshore team with onshore team and to project/business vision.

Hurry and Read the rest of this post!

{ 5 comments }

Simplicity at work – I h’ve always wondered what does this mean to me, to my team and to my organization. In my quest to know more, I asked this to many Agile Coaches and enthusiasts on various groups.

In this post, I like to share what I understood and gathered from my interaction with these people: Steve Ash, Charles Bradley, Lynn Shrewsbury, Ruud Rietveld, Philip Ledgerwood, John Hebley, Jeff McKenna, George Dinwiddie, Adam Sroka, Michael James, Matt Anderson and Cass Dalton.

Agile Simplicity less-is-more

Simplicity is the ultimate sophistication. ~ Leonardo da Vinci

Decluttering is a consequence of Simplicity. Simplicity leads to:

  • Decluttering of products.
  • Decluttering of your mind. Not being manipulative – being honest, open and trustworthy.
  • Decluttering your workspace, working in open spaces.

Scrum philosophy of working in small teams, small sprints, small stories imbibe simplicity thinking – Thoughtful reduction.

The desirability of simplicity is sometimes expressed as the KISS Principle.

  • Do today only what you absolutely need to do today. No ‘future-proofing’.  No  ‘gold-plating’.
  • Achieve Just Barely Good Enough (JBGE). JBGE is actually the most effective possible.

Thanks to Scott Ambler for sharing this term JBGE. You could read more about this in my earlier post Agility is About Identifying and Achieving “Good Enough”

There is a point in time when any additional effort put into work product will increase its cost without increasing its value. If not zero, the increase in value may be insignificant compared with the increase in cost. This is the point to stop! (Achieving JBGE).

Hurry and Read the rest of this post!

{ 9 comments }

Scrum team members know that things get very busy near the end of an iteration. The coding and quality activities need to be wrapped up, demo preparation occurs, the sprint review is held, the sprint retrospective is held, and the next sprint planning meeting is held.

If the onsite team team prefers to end iterations on Friday, they might naturally assume they have all day Friday until evening for these activities.

However, look at what that would do to a remote sub-team in India – it would mean working until early hours on Saturday morning. A better practice is to split the end of sprint activities across two days, ideally during the overlap time dedicated for sub-team synchronization. This insures minimal impact to normal working hours at the end of each sprint.

Hurry and Read the rest of this post!

{ 15 comments }

In my earlier post on “How to Address People and Communication Challenges on Distributed Scrum Teams” we discussed about importance of communication in building trust. Quality and Quantity of communication needs get amplified as soon your team gets distributed.

Distributed teams I have worked with have organized their schedule and overlapping hours some thing like below.

distributed scrum team communication between offshore and onshore team

Hurry and Read the rest of this post!

{ 0 comments }

Distributed Agile: How to Address People and Communication Challenges

by Avienaash Shiralige September 26, 2012

The main challenges of Distributed Agile revolve around People, Information sharing / Communication, and Project Structure. Let’s talk about first 2 challenges and how to address them. I wrote an article couple of weeks before on “10 Best Practices of Distributed Agile“. You will find few more practices in that article to address below concerns. [...]

10 comments Hurry up and read the full article →

5 WHYs: Positive Root Cause Analysis To Find Good Practices

by Avienaash Shiralige September 11, 2012

In my earlier article I shared my opinion about using 5 WHYs to find root causes. What I really missed to point was, it is not just applied to find root cause to problems, but it can be used to find root cause to good things that are happening on the team. In sprint retrospectives [...]

3 comments Hurry up and read the full article →

Distributed Agile:10 Best Practices of Successful Teams

by Avienaash Shiralige August 29, 2012

Distributed agile teams can exist in different forms like. Product Owner is onshore, Team is offshore Team split between two or more locations A complex model like product owner not with onshore team and development team distributed across time zones I would like to share top 10 best practices that are implemented by successful distributed [...]

5 comments Hurry up and read the full article →

5 Whys: Sprint Failed – Team Did Not Deliver Committed Work

by Avienaash Shiralige August 20, 2012

Applying 5 Whys is a good way to address the problems that you are facing on your teams.  This thinking is very simple, just ask WHY multiple times till you reach to root cause. You can read more about 5 Whys here. Some benefits of using this Lean technique are: Helps identify root cause of [...]

3 comments Hurry up and read the full article →

100 Practices to Form Your Dream Scrum Team

by Avienaash Shiralige August 5, 2012

Today I would like to share few practices that I have seen working wonders to teams following scrum. Not all the practices are followed by all the scrum teams. But by and large you see highly successful teams has many of them from this list. Below is a mind map which you can download to [...]

11 comments Hurry up and read the full article →