Here are 9 steps on how to transition a multisite organisation to agile development

1. Identify Agile coaches for each of the deployment centres

They are going to be the torch bearers of Agile, who will train, coach & be the eyes and ears for your Agile deployment. Pick your Agile coaches who have hands-on experience on what you are developing, who understand the local dynamics of the organisation & most importantly those who can influence their peers

2. Understand the existence of Cross Cultural differences

It may be subtle or more prominent but it is something that you should take care off. Cross cultural differences could be in terms of leadership styles, where some center’s maybe used to only command & control style; if so, you will need to put in more work in allaying the leadership concerns in these sites. Further you need to look for the underlying ‘politics’, within and between the sites & handle them appropriately. A big organisational change such as this will affect status-quo

3. Communication

Agile is all about communication. Communication between people and communication between people and code. You may need to set-up two types of meetings

a. Setup a regular Scrum of Scrum meeting, where the teams discuss project related dependency status - start with weekly once or twice and then increase or reduce based on need

b. Setup a regular Agile transition meeting, where the Agile coaches sync up and discuss issues, learnings & solutions. When you start it off, you may need to meet at least once a week and keep tweaking the agreed process or find new ways to handle program level issues. As you progress across sprints, the need for this meeting becomes less frequent

4. Architecture

An architecture that supports feature level ownership cannot be emphasised more. Such an architecture or design will help you vertically slice the product, where the distance between developers & users is at the minimum. However for legacy products this may not be always possible, in such cases evaluate possibilities of complete ownership of a set of features by one centre & another set of features by another centre. You will need a mature agile team & agile practices to have features spread across locations, so when you start out new, look out for clear boundaries

5. Slicing PBIs vertically

Get the teams to understand on how to slice the Product Backlog Items vertically. Since progress is measured through working code, PBI slicing is the key to measure progress. If they aren’t sliced properly, early integration of code will not be possible

6. Identify dependency and acceptance test cases

Identify dependency between PBIs and share acceptance test cases for cross-site dependencies. The acceptance test cases will ensure that the team delivering the dependency is clearly aware of what is expected of their delivery. This will save a lot of effort & bugs for the entire program

7. Single Mainline branch

Work on a single mainline branch where everyone commits code irrespective of the location. The build should always pass on this integrated branch. If your Continuous Integration system isn’t mature enough or doesn’t have automated testing, you can temporarily have a team level scrum branch for each team, which is the mirror of the Main line during start of every sprint. Each of the scrum team develops on this branch and merges the changes on the Mainline, after testing in the latest context, at least once at the end of the Sprint. This though not an optimal approach, will initially help the team to maintain the integrity of the Mainline thus not impacting other teams

8. Joint Sprint Reviews

Have joint sprint reviews. Plan it on the last day of the Sprint & choose a convenient time considering the time difference. During the sprint review, each of the scrum teams, across the centre’s will demonstrate their Sprint output from the same Mainline build. This will ensure that the product is continuously maturing, sprint on sprint

9. Tooling

All the above is only possible through proper cross-site unified tooling - for both project, configuration & build management. There are many free tools available on the internet. Choose and deploy them globally

So you’re an Agile coach who has been hired to implement organisation wide agile. The organisation has also been hiring SMs & POs. You find that each of them bring their own baggage of agile

Sam had gone to receive the delivery of his new car. He was received enthusiastically and offered refreshments

The salesman ran through the regular drill of explaining the features, what can be done, what should not be done, what must be done, etc. After a 20 minute demo, he was asked to wait until the paper work was complete

As Sam waited munching through a cookie, a young smartly dressed lad walked across the room and greeted Sam

"Good Evening Sir, I am Prakash. I am the Quality Representative, how're you doing sir?"

"I'm doing great thank you", replied Sam

"I'm here to get feedback on how your experience has been", he added beaming

"Yeah, so far, so good"

"Sir, are there any areas of improvement that you would suggest?"

"Come to think of it, the test drive car that you brought was in pathetic condition, you guys should maintain these vehicles"

"Sure sir"

"and your delivery lead time has to be shortened" 

"check your google reviews, the ratings are only 2 star, you can pick some improvements from there" continued Sam

Being the enthusiastic person he was, Sam provided a few more feedback, highly impressed by the proactive questioning from this dealer's Q-Rep

"Sure sir, we will take your feedback and strive to improve" said Prakash, stifling a yawn with great difficulty

"The poor guy must be tired, after all its near closing time", thought Sam

Sam also noticed that none of his feedback was noted down - probably Prakash had an awesome memory

As the conversation between them was ending, the salesman joined the conversation with a 100 watt smile

"How is your discussion with our Q-Rep, sir?" questioned the salesman, putting his hand over the Q-Reps shoulder

"You will get a call from the headquarters, please do give us 10/10. sir" added the Q-Rep

Aghast, Sam could only nod. Both the Q-Rep & the salesman were in cahoots and the whole exercise was to urge the Customer to give a high feedback score! So much for the 'pro-activeness'!

After a few days, Sam received a call

"Good Morning Sir, you had recently bought a car from us, what is your overall dealer experience?"

"It was ok"

"How would you rate your experience on a scale of 1 to 10, where 1 to 8 is poor, 9 is good and 10 is excellent?"

Sam couldn't believe his ears. What kind of a non-linear rating was this!

Dumbfounded he muttered "9"

"Thank you sir, when you get a call from headquarters, please rate us 9 or 10"

"Excuse me, then who are you?" inquired Sam

"We are the dealer from whom your bought the car. Thank you very much for your time"

We have two take-away's from this

1. a 'pro-active' dealer whose pro-activeness is not in finding & fixing issues but in 'managing' feedback

2. The company 'gaming' the feedback by providing a non-linear scale of measurement in order to show they have 'highest' feedback score among the competition

So much for Quality, Customer Feedback & Process!

Is Agile the only sole saviour for software development? 

Surely no, however if you have decided to implement Agile or are implementing Agile, it is imperative you familiarise with the top reasons for Agile failures so that you can lookout for these signs in your organisation

Don't like reading? Watch the video on why Agile fails!!!

Following Agile for Novelty’s sake . This may sound weird or almost unbelievable but it is a fact. Either a Project or the Organisation may have decided to move to Agile because everyone else in the industry is using Agile & the term “agility” may give them some brownie points in contracts

Becoming Agile is not just about fancy name changes to Scrum Master or Product Owner or Sprint, etc. The investment goes beyond that and includes cultural transformation, e2e change in the s/w development flow, changes in HR practices & a lot more, Management may have committed to go Agile without being fully aware or committed to these changes

On the other extreme, is an over zealous Management which may have mandated teams to move to Agile without ensuring teams buy-in. Agile thrives in an atmosphere of trust & teams wanting to inspect & adapt to improve the product & processes. With a non-buy-in team, teams could actually work against agile!

When an organisation decides to adopt Agile from a traditional development methodology, they choose to transform rather than transition. This has a steep learning curve and they may not be ready to embrace the short-term impact

A need for successful transformation is to have a subject matter expert focussing on ensuring that everyone understands and implements the practices by spirit. The Organisation may not consider the budget to train employees or allocate a coach and expect each team to figure-out agile for themselves, while this may work for some team, for many it fails

Something not very uncommon are organisations having agile like practices & defending that it can be mapped to Agile practices. While this maybe true, however we are not doing a gap-analysis for an ISO audit or a CMMI appraisal. More likely than not, the practices can be ‘mapped’ only on paper and not on intent on how it was implemented

While Scrum doesn't explicitly talk about automation, in order to scale, it is implicit that one needs to invest in automation & Extreme Programming practices can help here. Not investing in automation of repeated activities & test cases will increase the project effort exponentially as we move from one sprint to the other; this will eventually increase validation effort and the project would start compromising on quality

Not handling technical debt is another cause for Agile failures. A project with a large base code implementing Agile without a roadmap to improve the code quality would pretty soon end-up with a deluge of bugs and blame Agile - for exposing them!

Expecting one size fits for all. This unknowingly stifle teams from ‘inspect & adapt’ of the project process by enforcing organisation level processes expecting that ‘one size fits for all’

Dependency with External non-Agile Teams can be another cause for failures. If you have large dependencies with external teams who do not follow agile, it will be an uphill task to expect intermediate good quality delivery from them for integration & test. This may eventually defeat the purpose of your Sprint releases as you may not be able to validate in the product context

These are some of the causes why agile fails. If you have come across other reasons, do leave them in the comment section

"Get Certified under Rs. 10,000"

"We will help you write your process in 2 weeks and get you certified"

These are some of the adverts which shows the true state of the Quality of implementation of the Process Improvement models.This has been so because Organizations and Quality professional strive to attain Certification instead of Improvements

Therefore a QA not only played the role of experience sharing (personal as well as across project's) but more importantly had to be a visionary and a strategic thinker to identify organizational weakness and set things right (avoid slogging of developers & testers, on-time and good Quality Delivery!)

However with time, to win contracts, service companies adopted process models such as ISO, CMMI etc and they needed someone to "get things done quickly"; there was no time for progressive improvements - deadlines were set and had to be achieved for business (not necessarily improvement) purposes. Therefore the only way to do it in a cost effective manner, was to hire untrained, less experienced people as QA professionals. It did not stop there, because the process improvement models were force fitted without true commitment (other than the push from Top Management), a constant monitoring was required to continue the certifications - therefore these QA professionals continued to exist, without realizing that their true role was much much higher than what is being done presently

A friend of mine, who was going through the same turmoil, got an interview call yesterday for a Process Quality role in Europe. He was surprised at the importance given to this position - he was expected to define the end to end product development - which would mean the success or failure of the entire company! 

His passion for his work got re-ignited after the interview. Hopefully other QA professionals would also realize what the role demands and look at the bigger picture rather than limiting themselves to daytoday activities

I like my hair short… cut really short… the liking may be deep rooted, arising from the fact of my laziness to comb… having short hair has soo many advantages such as less “maintenance” time, looks more tidy, lesser “round trip” time to the barber’s shop, etc. (meet me and I can tell you at least a 100 more reasons!)

For the past couple of month’s I have been regularizing on a barber near my place. Due to my fantasy to cut my hair short, not many barbers come forward with enthusiasm, for they are unable to try out their “fantasies/creativity”. Of the three barbers available in the nearby shop, I usually end up with the youngest… probably around 16 yrs (talk about encouraging child labor)… by my deduction, this happens due to the simple fact, that, my hair requires not much creativity!!!

As many other businesses, this shop also does not run just on the “main line” of hair stylist but has other premium services such as hair massaging, anti dandruff treatment, removing black spots, etc

Coming back to my story, for the last three months, as mentioned, I always happened to end up with the youngest barber… he is very quick at his job, should I say, a petite hair mower… the only problem with our young hero is that, he has a mind of his own, of course nothing wrong with that, but it hurts when our preferences crosses… after all its my hair, not his!

Our young hero is usually more interested in wooing me to take up his premium “services”. During my hair cut, every 5 minutes or so, he would say “Sir, I’ll do hair massage, it’ll be nice” and with my broken kannada, I say “That’s ok, some other time” and our hero proceeds to pester “Sir it’ll be very nice, soothing and relaxing” and I say “No time” and he says “It won’t take long, I’ll do it real quick” (and I think, if its that quick, then why go for a short lived happiness, eh!). After couple of cross rebuttals, he quickly completes my hair cut, unties the cloth wrapped around me and ushers the next person in line (probably in the hope that, that guy will go for his premium services).

I put on my glasses; see myself in the mirror and voice out my opinion, that, he can still trim my hair. Our young hero replies “Sir, it’s correct, else you will not have any hair to comb”. Being a gentleman I am (at least I like to think that way), I feel too rude to continue the argument, especially since the next Customer has got up and is waiting for me to embark the “priced” chair, so I silently accept defeat.

This happened to me for around three times and my dissatisfaction became stronger each time… I had mentally made a note to try out a different barber, the following month…

The following month (two weeks back), as luck would have it, I get up at 10 and am rushed for time, so I end up in the same shop.

Our young hero was busy with another Customer, so I forcibly enthroned myself on the oldest barber’s (possible the owner) chair. He listened to my simple specification (had our young hero ever listened to my specification?!) and he started his work. Towards the end, he hinted to me about the other available “premium” services and even before I could decline, he said that I could have those things done whenever I wished to (he probably noticed my body language and knew my answer).

I was quite relieved at the way he had handled the selling of “premium” services, instead of pestering me. To add the icing to the cake, after he had done with my hair, he handed me my spectacles (which is usually placed on the table during the hair cut) and asked me if I was satisfied. This was the first time a barber had the “thoughtfulness” to have handed my spectacles and then, asked if I was satisfied. Usually almost everywhere, my barbers used to ask me, somewhere towards the fag end of the hair cut, if I was satisfied and I used to think, doesn’t this guy understand that I can only give a better judgment if I wear my specs and should I go through the embarrassment of picking up and wearing my spectacles???

But here was a barber,
1. Who knew exactly how much to push his Customer and
2. Could literally put himself in his Customer’s shoes and offer me my spectacles (he doesn’t wear one, so it was his thoughtfulness)

I was more than happy with the services that he had offered and needless to say, he had listened to my “specifications” and had done just what I wanted (no unnecessary improvations!)

This reminded me of the Kano model. The young boy could not even meet up to the basic needs of meeting the Implied and Expected Needs, not to say about the Delighting Needs! The old man had met all the three… to me “no pushy sale” was the Implied Need, “hair cut to my expectation” was the Expected Need and the final show of “thoughtfulness” met the Delighting Need!

How are we, as individuals, meeting the Implied, Expected and the Delighting needs of our Customer’s? This is a worthy point for each of us to ponder over, whatever be our role...

My next line of thought was, if I ran this business, how would I assess the performance of these three barbers? Would it be by

1. Who does the most number of hair cuts?
2. Whose conversion rate of ordinary to premium customer was the highest?

If I have just these as my parameters to assess their performance, I would have been sending a wrong message to the three barbers! You can see how misleading the above two measurements by themselves would have been. They almost lost a Customer and we do not know how many others have already left! Focusing on these measurements may have brought in short term profits but would have failed in Customer Retention and Long Term Sustainability.

The question that struck me was: which would be the most appropriate way to assess their performance??? A Customer Satisfaction Survey? But how many Customer’s will have the patience to provide such a feedback? Well that’s a separate topic by itself, so I leave that as “Food for thought” for all the readers to contemplate… Bon thinking…