Pages

Tuesday, September 30, 2014

Large Scale Scrum (LeSS)

Last week, I had the opportunity to speak about Large Scale Scrum (LeSS) at Agile PM meet up group  in Melbourne.  It was really an honor to speak with such an incredibly experienced, knowledgeable audience. At the end of the session, we had very engaging Q&A.

As part of the session, I shared some of the challenges of  scaling Agile and possible solutions as well. One of the solution being, applying the Large Scale Scrum(LeSS). 

Based on my experience of working on several large scale Agile projects, I have come to realize the following 4 types of challenges common across large enterprises.  They are People, Process, Tools/Technology and Org Structure/Culture. 

I have summarized the challenges into this diagram

image

Even though these challenges are common in small Agile projects but gets amplified while scaling Agile.

The popular  Scaling Frameworks are as follows:   Spotify,  XScale, SAFe, DAD (Disciplined Agile Delivery).

image

In addition to the above,  Large Scale Scrum(LeSS) by Craig Larman is popular as well.  I have personally applied this while working with Craig Larman during 2006 at Valtech India. LeSS and LeSS Huge are two variants for large scale projects.  LeSS huge can be depicted as shown in the diagram below:

image

LeSS is based on some of the proven principles around Queuing Theory,  Systems Thinking  and Empirical Process Control  as shown below.

image

If you want to learn more about  applying Large Scale Scrum on your projects, do drop me an email and happy to share the ideas.

Friday, September 19, 2014

What is Loyalty ?

No one plans to fall sick isn't it? Similarly, when I caught some flu couple of years ago, we were eager to see a doctor. Being new to our suburb, googled around to find a nearby medical center. Took an appointment with "any available GP," visited and got better.

After some time, it was my wife's turn. When she wasn't keeping well, she too called the medical center, took an appointment with "any available GP" and felt better.

Apparently she visited a different GP than mine. She recommended me to see him next. Over the course of time, we noted his name and started getting appointment specifically with him when needed. Suddenly one day we heard that he moved out of this medical center, and the receptionist wasn't eager to share his new coordinates.
We felt a bit sad as he knew us well, and we had a built a good rapport over the years and now we don’t know his whereabouts.

Later due to circumstances, we moved to a different suburb and once again started the search for "any available GP". We weren't so happy with the GPs we had seen compared to our earlier one. We used to remember our earlier GP once in a while.

One day we casually thought of searching our earlier GPs name on google, and some names came up. We called a few and one of them actually turned out to be our earlier GP. Everyone was elated, and we went and met him as well. He was not only surprised to see us but was beaming with a big smile.

I would call our selves as the loyal customers for this GP as we did everything we could do get the services only from him even when several options were available.

Loyalty is something when you chose a specific service inspite of having many options in available to you. Of course, a more formal definition from Wikipedia would be “Loyalty is faithfulness or a devotion to a person, country, group, or cause.”

On the other hand, repeat business is something where customers use existing service as they don't have an alternate option.

It is shameful to see that many companies measure "repeat business" rather than "loyalty." Loyalty is much more powerful than getting a repeat customer. Loyalty is something that will enable the company to grow during downturns and fierce competition. Repeat customer will leave you and go when they find better options.

Nowadays companies rollout the so-called "loyalty program." Big shopping malls and airlines have this loyalty program. I feel that this is a bit misnomer. People tend to go back to these companies not because they like the service, but because they get some discounts or redeemable reward points. I don't call such programs as a "loyalty programs", but as "carrot programs."

Couple of things I liked about our family GP has been his relationship building skills, his frankness, his specialty, customer service and respect for us.

Here is another personal example, while I moved to a new suburb, I was scouting for an electricity provider. I was calling each provider and gathering various details. As one could see, each one was tried their level best to sell a service by sharing their discount program, except one of them who explained their weaknesses as well. She not only suggested alternate but better options. I genuinely got connected with this company. Lesson learnt, being truthful and genuine breeds loyalty.

To conclude, It is very important for a business to evaluate if the returning customer is a loyal one or a repeat.

Even though we have tools like NPS, it won't clearly tell you the difference between loyalty and repeat. It partially helps to understand the situation though.

Always try to build a loyal customer base and work towards converting the repeat customers to loyal ones.

I have also posted this article on LinkedIn

Monday, September 15, 2014

Increase speed by incentives and sacrifice quality

Recently  I read an article in the news paper about improving the speed of passport delivery to citizens.  This is the news published in Times of India. It seems that passports are getting delayed as the police verification is taking a lot of time. In order to improve the speed, the passport office is planning to incentivize the police.  That is, if  the police completes their verification within 21 days, then would get more money else they are penalized by reducing the incentive.  I felt that this is one of the most dumbest idea ever implemented !!

Here is the quote from the news paper:

However, he said the delivery of passports has been expedited by incentivizing police. "We have reduced the time taken for delivery once the application is sent for processing. We are insisting that the police department send in police verification reports in 21 days. For each report sent before 21 days, cops are incentivized Rs 150 per report. If sent later, they get Rs 25 only. This will reduce the time taken to get the passport delivered. In some cases, the passport is delivered less than a week if verification report is sent fast,"

There are couple of issues with the above idea:

1. I don’t think any root cause analysis has been done to identify the delay in verification. There could be various reasons for the delay.

      For example, this passport verification may not be the top of police’s backlog list.  It is also possible that police force don’t have sufficient people to support this activity.

A root cause analysis could have helped to unearth the real cause of the delay and proper action could have been taken.

2. Going forward, I could see that the all police verification will complete within 21 days due to incentives. Question is, at the cost of  WHAT ?    I could see that the quality of verification will drop heavily as the possible root causes are never addressed. 

Being in the software industry, we keep hearing that external motivation causes more harm than the anything else.  The above story correlates to what we commonly see in the organizations. Employees are incentivized for ensuring on time delivery. But the companies pays for the cost of quality at a later stage, which no one really bothers or accounts for. 

Saturday, September 13, 2014

Your understanding of Kaizen is wrong

Kaizen is popularly associated with continuous learning or continuous improvement.  However, where people get wrong is who should continuously improve ? 

Most Agilists and Leanists use Kaizen in the context of team improvement. That is, an agile team should continuously improve, and thus excluding the managers/leaders, rest of the company. 

This is exactly where the understanding goes wrong.   The true Kaizen involves continuous improvement across the organization starting from the CxOs, and involving HR department, Finance, PMOs, Sales and marketing. It is also about improving everyday and everywhere. 

So to conclude, you are not really following Kaizen if the expectation for improvement is only for the team(shopfloor) and rest are excluded !!!

Watch this video to hear directly from the master Masaaki Imai, founder of Kaizen Institute

https://www.youtube.com/watch?v=jRdTFis4-3Q

image

Sunday, August 31, 2014

Secret recipe for building self organizing teams

I authored this short post for image as part of Agile chronicles.

image Some time back I noticed something odd with an agile team. Team temperature used to be 10 out of 10, and each team member expressed their happiness working on this project.  I was curious to find the secret behind an “always happy team.” A bit of interaction with the team and the ScrumMaster revealed some disturbing secrets.  Here are the key ones:

  1. The team is self-organizing, and individuals can pick the story of their choice and deliver at their discretion!!
  2. Team has neither time pressure nor delivery timelines

I thought to myself that this is not a self-organizing team, but a directionless team.

As Esther Derby points out, there are several myths and misconceptions about Self-Organizing teams.  I did cover a bit about these myths during my talk at Lean Agile Systems Thinking conference(LAST) in Melbourne, which is available on Youtube (toward the end at 1:03 minutes).

I understand it is not easy to build a self-organizing team, but there are principles enabling leaders in building such agile teams.

One of the best analogies that I have heard so far about self-organizing teams is from Joseph Pelrine.  As Joseph puts it, building self-organizing teams is like preparing soup.  I thought it would be easier for readers to understand the self-organizing concept if I map the soup preparation steps to the self-organizing steps. Yes, soup preparation involves many more steps, but the key ones below would give the clues to readers for further analysis.

Read rest of the article on  : Agile Chronicles

Photo courtesy : https://flic.kr/p/ayhjag

Saturday, August 23, 2014

Measuring Business value in Agile projects

image

Because the first principle of the Agile Manifesto talks about delivering valuable software to the customer, many agile practitioners are constantly thoughtful of the value in each step of the software-development lifecycle.

At the thirty-thousand-foot level, value creation starts with gathering requirements and continues with backlog creation, backlog grooming, writing user stories, and development, finally ending with integration, deployment, and support. Even with knowledge of all these moving parts, it is common to see organizations only measuring value during development and ignoring the rest of the steps.

What’s the fix? During backlog creation, user stories need to be compared and contrasted in order to promote maximum value delivery. The product owner might need to use different techniques, such as T-shirt sizing, in order to better prioritize the project’s stories.

An alternate approach to measuring the business value of user stories is to use a three-dimensional metric that incorporates complexity, business value, and the ROI. Creating value can often require a change in perspective from the normal project’s tasks and functions. Thinking outside the box, identifying business value before writing the user stories is much better than writing and then trying to evaluate.

Read  the complete article about measuring business value on TechWell

Picture courtesy https://flic.kr/p/8E7Dr5

Saturday, July 26, 2014

LAST (Lean Agile Systems Thinking) 2014 Conference

image Last week I had the pleasure of speaking  at the LAST 2014 (Lean Agile Systems Thinking) conference. This is my second consecutive year of having opportunity to speak at this popular Melbournian event.I  have seen this event growing year after year. First year, we had 150 attendees, the second year 350 and third year is even more successful with 450 people. The event is highly affordable and run by the Melbourne community.  Some call this conference as  “Meet up on Steroids”. 

The two passionate people who are successfully managing this event are Craig Brown  and Ed Wong.  Organizing such a large scale event managing speakers, schedule, events and sponsors is not a simple thing. The event was such a smooth one, didn’t realize that the day had already passed.

This is a classic example of power of passion and network in the community.  You don’t need many people to make a positive difference to the society, you just need one or two passionate givers.

The session was organized by  TABAR 

I spoke about  10 Irrefutable laws of Agile Coaching.  The presentation slides are available on Slideshare as well. Feel free to download/share.  

My intent for sharing these ideas was to encourage Agile coaches to think beyond  Scrum, Lean, XP, etc.   Agile coaching involves a broader systems knowledge to succeed.

More details about my session:  Agile coaching is one of sought after skills in the IT industry and many experienced coaches are doing extremely well. However some change agents are struggling to make an impact, not because, they don't know Agile but because, they don't know some ground rules dealing with the coaching teams and leaders.

Whether you are a novice or an experienced coach, there are irrefutable laws governing Agile coaches. Based on my own personal experiences coaching teams/leaders since the last several years, I have come to realize the 10 secrets. Irrespective of where you are in the journey as an Agile coach, practicing these 10 laws will help you to become a successful Agile coach. These handy rules can help you anywhere in Agile coaching journey.