Tuesday, December 31, 2013

Top Agile and Project Management articles in 2013 from Cutter

I am happy to share that one of my articles   Agile Maturity Assessments: Boon or Bane? has been made it to the Top Agile articles list in 2013 on Cutter.


Here are the list of top 6 articles:

1. On Agile and Discipline

by Jens Coldewey

There is a conception in the public debate that Agile is a basically undisciplined approach. Book titles such as Balancing Agility and Disciplinefuel this perception. In a debate on Agile and CMMI we had earlier this year, Cutter Senior Consultant Hillel Glazer rightly pointed out that "it would be incongruous to ignore the plentiful examples of dreadfully undisciplined 'Agile' adoptions resulting in 'Agile in name only'" (see "'Agile vs. CMMI': The Debate Goes On").

2. A Three-Tier Model for Guiding Your Agile Implementation

by Israel Gat

The beauty of Agile software methods is that they enable us to focus with a singularity of purpose on the iteration management and project management aspects of the software delivery process. Numerous other aspects of software delivery, such as those shown in Figure 1, are, of course, of critical importance. Yet, it is the sustained and continuous focus on how we perform iteration management and project management that leads to eventual success with Agile.

3. The Five Keys to Organizational Agility: From Agile to Agility

by Rob Thomsett

This Executive Report outlines a major Australian bank's four-year journey from using Agile models for some software development projects to an enterprise-wide agility model in responding to and delivering change, all in an effort to completely commit to agility transformation across the organization. The report presents five key lessons relevant to all organizations and to which all businesspeople interested in leveraging and broadening the true power of the Agile revolution must pay attention. The report also examines various practical approaches to the issues each of these key lessons raise. These approaches have worked successfully at the bank, despite a major reorganization during the past year.

4. Agile Maturity Assessments: Boon or Bane?

by Venkatesh Krishnamurthy

In the last two decades, organizations have moved from applying waterfall toward embracing Agile methods. However, one thing that has not changed much during that time is measuring the maturity levels. ThisAdvisor offers some tips and techniques for improving the Agile maturity assessment process.

5. Agile and Outsourcing: A Disciplined Approach

by Scott Ambler

Your initial instincts for how to run an outsourced project are likely to hurt you more than help you. Outsourcing introduces a collection of risks that can be uniquely addressed with a disciplined agile strategy. Luckily, the Disciplined Agile Delivery (DAD) process decision framework provides a foundation from which you can tailor a viable strategy for disciplined agile outsourcing. In this recorded webinar, Senior Consultant Scott Ambler explores strategies for effectively initiating and governing an outsourced IT delivery project in an Agile manner.

6. Introducing the API Economy: A Dialogue

by Jim Plamondon

This Executive Report introduces the API Economy to CxO-level executives of industries outside IT. It follows a novel dialogue format, as if it were a transcription of an introductory consulting session with the CEO and CIO of a fictional company in the oil and gas industry. The report defines API and the API Economy, discusses some of the many API business models, argues that this economy extends a proven software architecture onto the Internet, presents that architecture as a tool for thinking about business models, and discusses the role of developer relations in making APIs successful. The report then applies these ideas to the task of solving one of the fictional company's billion-dollar business problems using an API-based approach.

Tuesday, December 24, 2013

3 key things to know about performance testing

image How much does 1 second delay cost? I know the response could vary depending on the context. If it is a space walk or an emergency operation, it is life and death. However, in the context of a typical business, one second page loading delay could cost nearly $2.5 Million lost sales a year.

It is very critical to understand that people abandon websites and move on if it takes more than 3 seconds to load. Inspite of having all these data, IT departments are still struggling to get some grips on application performance testing (PT).

In this article, I would share the 3 critical factors for building a successful PT strategy. In a typical waterfall project, the performance testing was done at the end of code freeze. However, Agile methods recommend performance testing during every sprint.  My experience has been that every conceivable problem in a software project starts at the beginning, mostly because of ignorance. This includes PT, as well.

Photo courtesy flickr

For a successful execution of PT, enough time and energy needs to be spent during Sprint 0. This energy should build a strong foundation of skills, automation and strategy as shown in the picture below.


Let us look at contribution of the above 3 areas during PT.

  1. Availability of good automation tools decides the fate of the PT.  Even though there are several commercial tools available in the market, open source ones are still closer to heart for Java/.Net programmers. It is a shame that not many free tools are available for legacy systems. Even though automation is highly recommended by everyone, one should take a cognizant, evidence driven, scientific approach and calculate the ROI.

continue reading the article here onimage

Monday, December 16, 2013

5 tips to become a better Agile coach

image In the past two months, I lost nearly eight kilos (roughly seventeen pounds) after I joined a fitness program assisted by a personal trainer (PT). This is a success story for me. And when I traced the steps back, I noticed a number of things that resonate with coaching teams.

Below are some of the steps my personal trainer took when he consulted with me, followed by my comments to bring the idea of coaching teams into perspective. You’ll find that there is a strong correlation between what I learned during my training endeavors and what constitutes good team coaching.

1. Understand requirements: The first question the trainer asked me upon signing up for the fitness program was about requirements. Do I need to lose or increase weight or build muscle?

Coaching lesson: It is important to understand the customers’ requirements before starting any coaching assignment. It is not safe to assume that everyone needs cheaper, better software. Ask as many questions as possible before delving into the next step.

2. Inquire about health: Once the trainer was happy with the requirements, he inquired about my current health. He did a quick blood check and a blood-pressure test, in addition to taking my height and weight measurements.

Coaching lesson: Don’t jump into coaching without understanding the current health of the system. Understand team morale, culture, leadership style, and relationships. Have one-on-one meetings with key players to understand their feelings, ideas, and thoughts.

3. Recommend the right equipment: Based on the above information, the PT recommended four pieces of equipments I should use, and demonstrated their use. This moderate regime recommendation was tracked through a daily register.

Read rest of the article on Techwell here..

Tuesday, December 10, 2013

PMFlashblog eBook - Final version available for download


Couple of months ago, more than 70 bloggers came together and shared their opinion about “What Project Management meant to them”.  It was a highly successful event with a seamless virtual collaboration.  As an outcome of the event, a fantastic book “PMFlashBlog” has been compiled and published.

I am happy to share this book here on my site and feel free to download it from here.   Don’t forget to read my contribution on Page 67 of the ebook :-)

Many thanks to Allen Ruddock for compiling the book and Shim Marom for conceiving the idea.

Sunday, November 17, 2013

How to be an efficient product owner ?

image Last week, I had the opportunity to attend the two-day Passionate Product Owner workshop with Jeff Patton. As the name states, this workshop is all about equipping product owners (POs) with tools and techniques to do their jobs efficiently. I made tons of notes during those two days and came away with a lot of new ideas to experiment with. Here are some of the key takeaways.

According to Jeff, the role of a product owner is similar to that of the product manager. The product owner is responsible for building a valuable, usable, and feasible product. It is a shame that most product owners in Scrum projects are treated as domain experts, tasked with handling and prioritizing requirements. Forget about usability; many POs in companies don’t even have the visibility about the budget allocated for the project.

Many companies have dedicated production support or “maintenance” teams, whose duty is to focus on quickly fixing the defects from the production systems. Many companies run like this—like a factory. The green field teams keep churning code, deploy it to production, and then hand it over to the support team for further maintenance.

This separation of the coding and maintenance teams is a highly dysfunctional way to work. The above system absolves the PO from ownership, thus orphaning the product. The real ownership is generated when the team developing the code maintains it as well.

Backlog grooming was discussed in the workshop as well. These grooming sessions are popularly used by product owners and the Scrum team to plan the next sprint.

Read the rest of the article here

Saturday, November 02, 2013

What makes a healthy self organizing team ?

image Any conversation about self-organizing teams will always generate a crowd response, as this LinkedIn discussion shows with more than 330 comments. If you Google the phrase “building self-organizing teams,” you will see nearly 45 million results. Some of the results show articles with captivating headlines like “How to Build Super Star Self Organizing Teams” to articles addressing the typical myths and misconceptions of self-organizing (SO) teams.

It seems there are several ingredients that everyone seems to agree on for building SO teams.

A good leader is an essential ingredient in SO teams. Mike Cohn shares some vivid examples of how leaders should monitor the behavior and fix team issues. Giving a free hand to the team members or allowing them to do whatever they want won’t result in an effective SO team.

The leader should have servant-leadership qualities, as well. As Jim Highsmith says, implementing a light-touch-leadership style is essential, and decision making should be delegated to the lowest level possible.

Read the rest of the article here

Tuesday, October 29, 2013

Story of Agile and the Band-Aid

I have stepped into my 12th year of  practicing Agile methods. Started with XP before embracing Scrum, Lean, Kanban.  I nearly thought we found some solution, but looks like we still have some more things to do.  Even now, organizations are looking at Agile as a silver bullet without fixing the root causes.



Here is the issue, the  issue is Agile was born mostly to banish the problems coming out of the Waterfall model. If you don’t believe me, have a look at the manifesto (screen shot on the left),  everything on the right side is all about the waterfall way of working.  Whether it is the overreliance on Tools, Processes or documentation.   Everything on the left hand side is supposed to be the Agile way of working.  There is nothing wrong with it,  but it is applying the band aid on the issues coming from the right hand side.  It looks like there was too much focus on solving the problems coming out of waterfall rather than the focusing on software delivery. I see that Agile ended up becoming just a band aid.


Why Agile is just a band  Aid ?

Couple of years ago, when every one was overwhelmed with the project failures applying the waterfall model, people wanted to get rid of this problem. Instead of fixing the problem, people started applying the band aids against the bruises, and the problem stayed back.   In the above analogy, the waterfall was more like a bruise, and it was not the real problem. 

As we know, the band aid would reduce the bleeding and provide some short term relief.  However band aid won’t stop the accidents from happening again. 

What is the real problem ?

I see that the issues that was bothering the business and development community couple of years ago was much bigger than just the waterfall.  The issues were org structure, leadership styles, complexity of the problems, etc. Waterfall was just a tip of the iceberg.  Even now, half of the Agile projects are going through a lot of struggles, and it has been proven repeatedly that  Organizational culture and communication issues are the key reasons for failed Agile projects. (See other issues in the screen shot below)


Once again, we need to remember that Agile is not going to fix the company philosophy, Agile is not going to improve the communications.  Agile, Lean and Kanban are all the band aids. The cultural issues and organizational philosophy issues, communication issues are like the accidents that keep happening and causing scratches again and again.
Unless we fix those issues, no matter what methodology we follow, the projects end up with failures and teams continue to stress out.  

You can keep applying the band aid but how long ?

It is important for delivery experts to focus more on fixing the accidents rather than keep applying the band aids.

Tuesday, October 22, 2013

Agile and Happiness

All of us are doing what we are doing to achieve one thing, that is the happiness.  I read this inspiring article a while ago “Searching for happiness: What makes life meaningful” ?

We dream of  living in a villa with swimming pool and  Jacuzzi. We want to live next to a river surrounded by picturesque mountains. Why do we need these things ?  Its because, imagining having these amenities gives us a sense of happiness.  We think that one day by acquiring them we would be in a “permanent” state called “happiness”.    Is this really possible ?

Personally, I feel that happiness is a journey and a state of mind. There is no permanent state called “happiness”, and a person gets happiness by conquering challenges. No challenge and no happiness.  So, happiness is an ongoing exercise of chasing challenges, conquering and experiencing it. I get happiness when I spend time with loved ones or some one writes some good words about an article. I get happiness when I clear the challenging  “driving test” or complete a presentation in front of “challenging” audience. 

Now, let us look at how Agile and Happiness are related…  

I see a lot of organizations craving for Agility, and it reminds me of human beings craving for happiness.  The organizations invest a lot of  money to become “Agile". This is akin to the the waterfall era where organizations used to crave for CMM certifications. During the waterfall era, the companies thought having CMM 5 certification would enable them to reach kind of “Nirvana” or a “final state” of excellence.  Anyways, now it is history that it was proven wrong.

With the popularity of Agile, the companies are now craving for the Nirvana called “Agile”.  When 4 Agilists from 4 different companies get together, they would always discuss if their company is “Agile” or not.  They talk about Flickr doing 10 deployments a day, compare it to their own and beat themselves up .  There is a perception that if a company is able to do “10” deployments per day or do a Continuous  Integration then they are an “Agile” company.  This is very similar to human beings assuming that they would be in a state of “permanent” happiness when they acquire house and Jacuzzi, living next to the river. Is this really true that there is a final state called “Agile” ?    

I personally think that,  being “agile” is truly what makes a company as “Agile”.  Just like how happiness is a journey and there is no “permanent” state called happiness, being “agile” is a journey and there is no final/permanent state called “Agile”.

As long as the company is going through a journey of continuous improvement and moving in the right direction, they are “Agile”.

Friday, October 18, 2013

Customer experience is as important as Quality

image Toyota has become a synonym for quality, profitability and discipline.  You ask anyone for advice about purchasing car, they say go with Toyota. Because of its good reputation, it seems to have a good resale value, as well. However, today I heard an interesting story from a friend about a very bad experience dealing with Toyota salesman. He vowed he won’t go back to Toyota again.

Here is the story, one of my friends interested in buying the Toyota car called one of the Toyota dealers. The sales-person promised him a host of things, and after a great deal of negotiations for 3 hours the salesperson turns around and says, sorry he cannot give anything he promised. The reason he quotes it seems that he wants to help, but his manager does not want. The promises salesperson has made would cause a loss to the dealership  !!!  Very interesting reply isn’t it ?

My friend obviously thinks the Toyota sales guy wasted 3 hours of his time, and salesperson could have checked with his manager before promising anything.

Probably, this is a rare instance with a Toyota salesperson, but it has created a bad experience about the Toyota product. 

While I patiently listened to his story, one thing I realized was “A company could build a fascinating product applying a lean process or Agile method with a precision quality. However, In the end, if the end customer is not treated properly with respect and ethically, no matter how great the product is it won’t succeed.”

I visited Toyota website to see their promise to customers. You won’t believe this, their promise has everything except a customer satisfaction (see the screen shot below). 


I can build a innovative, quality and a safety product but if I treat my customers unethically or leave them dissatisfied will they come back ?

I can now see why Steve Jobs insisted on owning and running the Apple retail stores instead of giving a free hand to anybody and every body.  Probably, he knew that  building a customer loving product is not sufficient but leaving the end customer with a fascinating experience is important, as well.

For smaller items like Phones or clothes, the dealers and salesperson could impact consumer experience. However, if we are ordering a large goods like a TV or Refrigerator the shipping company or the courier service could influence the consumer behavior, as well.

If the courier boys do any damage during shipping and installing the items, “or”  they behave impolitely with the end customers, the impact will be more on the “actual brand” of the product rather than the shipping company.   

I have noticed that, while we share our experiences with our friends and families we always remember the product rather than the shipping company name. For example, we always say, while I ordered “XYZ” model TV, I had a terrible experience !!

After the above mentioned experience with the Toyota salesperson my friend is now saying, I had a terrible experience with Toyota !!

Do you have any such experiences where the salesperson left you with a bad feeling, and what was your response in terms of purchasing decision ?

Tuesday, October 15, 2013

Social Contract is not a place to resolve conflicts

image I am sure all of us have participated in creation of team social contracts at one time or the other.  After reviewing so many Agile projects since the last several years, I have seen a unique correlation between what goes in the social contracts with the team dynamics.

Social contracts as we know are created by the team and they manage it.  The items that enter the social contracts should help the team to create a positive and happy environment to work.  Social contacts shouldn’t be used to resolve the conflicts in the team. 

If the social contracts have items like “Don’t yell at your colleagues”  or  “Don’t throw rubbish on the floor”,   I feel that there is some sense of urgency to see what’s happening in the team !!

Let us take the simple example of  “Don’t throw rubbish on the floor”.  Most of us will try to keep the working area clean. Even by any chance, we spill something immediately we  make it point to clean it.   Most of these issues related to cleaning and Hygiene  are resolved or “should” be resolved through one on one discussions.   If the team is unable to resolve it collaboratively and are relying on social contract to fix them, then there is a bigger issue to worry about.

Let me conclude this by asking: How does your social contract look ?  Why did each of those items land in there ?  What was going on in your team’s mind ?

Design Testing : Improve software testing quality through this innovative way

image Design Testing,  is one of the concepts that I have come up with to improve the quality of software testing.  Since the inspiration behind this thought was Design Thinking, I have kept the name Design Testing.

Design Testing,  was created due to the frustration in the way testing is currently handled in the software industry. Test cases and discussions with product owners are the source of testing for testers.  However, most of the test cases are created based on hypothetical test scenarios and documents.  I believe that testing quality can be improved if the testers get to see the real world customers and their use of product. 

If you want to learn more about this technique, read the rest of the article here           image Photo courtesy:

Thursday, October 10, 2013

Design Thinking + Scrum + Lean Start up = Make customer happy

image Do you want to build repeatedly build products that customers love ?   Do you want to know some of the Scrum’s weakness and find ways to strengthen it before it is too late ?

Recently I have proposed new ideas around building innovative products that customers love by suitably using the right mix of tools from Scrum, Design Thinking and Lean Startup concept.

If you are interested in learning this secret recipe, check out the recently published Cutter article here



Wednesday, October 02, 2013

Is Agile good enough for innovation?

Recently I shared my views about  Agile and its role in Innovation.  There is a myth that just by embracing Agile or Lean, one could build innovative products.  Based on my personal experience working in several research projects and being part of innovation team, I have found that we need much more than Agile.  We need  a good support from Leadership, Conscious effort to have diverse thinking team and right tools.

I covered this topic today with lovely Melbournians at The Apartment.   The slides are available here.  

Some of the screen shots of the slides below:

image image image

2 monkeys paid unequally – Impact of unequal pay

See the reaction of the monkeys when they are paid unequally ?  

Watch this video by clicking    this link


From a TED talk by Frans de Waal, a primatologist, ethologist, and professor of primate behavior at Emory University.

Tuesday, September 24, 2013

#PM Flash Blog – What does project management mean to me ?

As part of #PMFlashblog, I am excited to share a pragmatic view of state of Project Management in the IT industry. This article is about “What does project management mean to me ?”

The tasks related to Project Management (PM) haven’t changed much since the last two decades. I have been in the industry since the last 17 years and seen both Agile and Waterfall era. I see that at a broader level most of the PMs effort is spent towards staffing projects, invoicing and reporting. However, a key observation has been that PMs are no more the center of attraction in Agile projects!

I am sure you would have heard about the Iron Triangle. Most of the projects I have across have some constraints of Scope, Resource or Schedule. Most of the time the Scope keeps increasing but the cost, budget and Schedule remain the same. During these situations, we agilists keep saying this is the wrong way of doing things and we need freedom, flexibility and sustainability. Guess what, this is when stakeholders and business people introduce Project Managers to “get things done”


For me, the Project Management is all about delivering what the customer wants in challenging environments. I have consciously tried avoiding the typical Agile terms like “Business value” or the “Customer value”. The reason being many a times the stakeholders or the business people themselves have tremendous constraints and demands from the investors that they ignore the real “value”. During these constraining situations, they want someone to “Get things done” rather than talk about “Values and Principles”.

Project management is all about “Getting things done” in complex and constrained environment, and whoever has the ability ends up becoming a project or a program manager. Since the PM work involves handling difficult stakeholders leading to a lot of stress,and this role is not for faint hearted. As the PMs need to be strong willed, and their focus is on “Get things done”, they end up becoming the bad cops all the time.

During the waterfall era, Project Managers were the final authority in deciding the fate of the project. Whether estimating projects, staffing or handling budgets. They always used to steal the thunder. With the popularity of Scrum, the center of gravity around projects has moved out of PMs. In Scrum projects, theoretically the PM tasks are split between the team and the Scrum Master, but the ground reality is, most of it is still managed by the Scrum Masters.

During early days of Agile, there were debates challenging the role of a PM in Agile projects, however, now it has become a reality that PMs are needed to handle the “admin” tasks. The prime reason being, they know how to “get things done” in any situation. Large companies implementing complex Agile projects still have dedicated project managers, but they don’t interfere much with day to day running of projects.

Here are the common things I have observed with all the project managers. I am sure if you visit this list and compare with your PMs, you might find most of them.

1. Experienced: They typically have a lot more industry experience as compared to rest of the team members

2. Delegators: They are very good at delegating the tasks to the team

3. C2 Style leadership: Command and control leadership style. It is very rare to see a PM who is like a servant leader.

4. They like meetings. At the drop of a hat, they schedule meetings and they have this uncanny ability to keep eyes open during post lunch meetings.

5. They are good at reporting. They can create very good power point templates, and spreadsheet reports. You just hand over them the data, and they know how to massage it before sharing it with their leaders.

6. Process neutral: Even though all the PMs still have a lot of affinity towards Waterfall brethren, they can adjust to any new process without losing waterfall thinking.

7. Crystal ball: All of them have some sort of crystal balls using which they get to hear all the gossips and rumors before you do.

Irrespective of whether PMs are the center of attraction or not, they know how to “get things done”.

Monday, September 23, 2013

#PMFlashBlog coming soon….

For the first time,  more than 70 bloggers across the globe are coming together to share their experiences around Project management.  The title of the blog is going to be “What does project management mean to me

All the bloggers will publish their blogs on 25th Sept at 0100 Hrs GMT.  I am proud to be one of the bloggers as well.

As one could see from the following infographics, courtesy HennyPortman,  we have bloggers from Australia, Canada, Colombia, Denmark, France, Italy, Mexico, Poland, Portugal, Singapore, South Africa, Spain, UK and the USA 


Sunday, September 15, 2013

Change the mindset of these 4 Practices

 image Over a period of time,  Agile practices is taking its own shape unfortunately not for the better but for the worse.  Practices are given embraced forgetting the principles behind them. Especially over the key practices like  Retros, Daily stand up, Iteration planning meeting and estimation.  
What are those myths, misconceptions and what mistakes people are doing ?   These are covered in detail in the recently published  Techwell article.  The transcript of the article is shared below….
There are two popular mindsets team members have about retrospectives that I want to address: retrospectives are done only at the end of a sprint or a project and they are done to identify “what didn’t go so well.”
In reality, I have found that retrospectives support an “inspect-and-adapt” approach and are needed for continuous improvement. Agile teams are able to get together at any time and reflect on what’s going on in the project and how to work better. Having a “do-only-at-the-end” mindset dilutes the real intention behind retrospectives.
Read rest of this article here

Some of the recent stories on Techwell

Feel free to check out rest of my TECHWELL articles here

Thursday, September 12, 2013

It works on my system !

image I am sure many of us are familiar with this message “It works on my system”.   I recently got the same answer not from a developer but from the customer service team of the popular loyalty card.   As a card member, I couldn’t login to my account and reached out the customer care team through their Twitter help service.

There you go, I got the most popular answer  “we've been unable to replicate your problem here“.  

How do you deal with that response as a customer ?   What does that response reflect on their IT competitiveness ?   You report a defect to one of your developers and you hear this response back, how do you feel ?

A quiz on Self Organizing team

image You come across a team which has the following characteristics

1. All the resources necessary (budget, time, people, tools, etc) to do their job. They can estimate and set the deadlines for their own delivery
2. No conflict at all in the team
3. Team feels very happy and relaxed all the time
4. They have no delivery commitments as they set their own delivery dates
5. Each team member assigns their own task

I know this is like a dream team. Do you think they are a self organizing team ?  If not, why not ?    Is there a test to check if a team is self organizing or not ? 

Photo courtesy:Mike Baird 

Wednesday, September 11, 2013

Net Promoter Scores - Do they work ?


Net Promoter Score (NPS) is as popular as engagement surveys.   There are several people who vouch for the benefits of  NPS. This is such a simple system that when I heard about NPS for the first time, I felt, this cannot be so simple !  There might be something I am missing.  The reality was, it is a simple system.   

The Ultimate Question 2.0 covers a great deal about the subject with tons of benefit. 

Interestingly we have few naysayers doubting the benefits of NPS as well.  Check this presentation out, where the authors seem to have data to prove the benefits of NPS wrong.

Another research paper here  has finding which says  “Contrary to Reichheld’s assertions, the results indicate that recommend intention alone will not suffice as a single predictor of customers’ future loyalty behavior. Use of a multiple indicator instead of a single predictor model performs better in predicting customer recommendations and retention.”

I hear that most successful companies like Apple, LEGO, Facebook, eBay, etc are using NPS.  I am sure there would be arguments – counter arguments on both sides for NPS. 

I am more inclined to believe the naysayers. We live in a complex world, and there could be multiple things impacting the loyalty, customer behavior, satisfaction etc.  It is not correct  to see a liner “Cause and effect” between the NPS score and the revenue generation(other benefits). This is like the Peltzman effect where “wearing a seatbelt induces people to drive less safely”  causing accidents, which goes totally against the linear “cause and effect” thinking.

Wednesday, September 04, 2013

Why do good people become bad bosses ?

I am sure all of us have come across  bad bosses at some point of time or the other.  But in reality, they are not really bad people at heart. The pressure and the stress pushes them to snap at people and ending up with “bad boss” title.   Here is a must watch video by the famous author  Annie McKee about this subject.

    A few take aways from this video
    1.  Bad bosses are good people under pressure

    2. People really like to change, unlike the popular assumption that people resist change

    3. People will change provided they are properly supported

    4. Don’t allow bad bosses to hurt your self esteem, dignity and confidence. Put your foot down to protect yourself

    5. Mindfulness is the key to success

Scattered meeting day syndrome

image I have observed that the most un-productive day would be to have scattered meetings all throughout the day.  

For example:

  • 9- 9.30 AM   First meeting
    10 – 12  Second meeting
    <Lunch break>
    2 – 2.30 another meeting
    3 – 4  last meeting of the day

After the first meeting, one would rush to get a cafe to prepare for the second one. By the time you grasp the second one, bell rings for lunch break. The day continues with meetings with a break of every half an hour, and end up with a pile of “real work” by 4 PM, causing too much stress. This leads to too many meeting syndrome

This is exactly what the Agilists dislike.In fact I have heard people calling Scrum has too many meetings !!   As per various researches, the task switching could cost nearly 40% productivity loss.


Personally I found that blocking a chunk of a day provides me the well deserved and dedicated focus.  Not sure if others have seen this happening ?   Have you experienced this ?  How do you deal with this scattered meeting syndrome  ?

Image courtesy :

Tuesday, September 03, 2013

Can a process fix the broken trust ?

image The last weekend, I approached concierge of our apartment complex to get permission to use the functional hall. The concierge pulled out a print out and asked me to sign it.  I have used the functional hall many times before and haven’t seen this new process of signing a form. 

The new form had things like  “The furniture if broken has to be replaced by the tenant”, “ Ensure to throw the trash in the bin”, “No smoking allowed in the functional hall”  and stuff like that. These rules makes sense but was curious why now ?   

I asked the concierge about the rationale of this process, and it seems the previous week some users of the functional hall created a bit of raucous. To avoid those issues in the future, they have brought this new process into place.

I had an aha moment when I heard this.  Is this not the same way our organizations and countries work by creating new rules and processes reacting to a problem ?    In the case of our apartment, Initially the body corporate  trusted the tenants and gave the freedom to use the functional hall but some where in between the trust was broken.  I am wondering now,  does this new process build the broken trust in any way ?   Does this process stop any such problems from happening again ?   Is this the right way to handle such issues or is there a better way ?

Saturday, August 24, 2013

Is Your organization ready to embrace Design Thinking ?

image With the popularity of "design thinking," companies are encouraging their designers to be in the field interacting with end users. Like any other new methodology or process adoption, design thinking requires a fair bit of change in the mindset of designers along with some new skills.

One cannot change the process without changing the mindset of people nor giving them the appropriate tools to succeed.

One needs to analyze the skills and training needed to succeed with the new process.

Do you want to learn what these skills are and the necessary tools, read rest of the article  here 



Photo Courtesy:

Friday, August 23, 2013

Lean and Agile Project Management using Scrum – Upcoming Course in Melbourne


image There is an upcoming Lean and Agile Project Management Using Scrum Course in Melbourne CBD  on 30th Aug.  I highly recommend this course both for novice and advanced practitioners.

Get further details here.

Quick overview of the course below:

Scrum and Agile have been around for years, but organisations are still struggling to realise the potential benefits of using them. Much of this stems from the myriad of tools, frameworks, practices, methodologies and processes in the market that all claim to make your teams more efficient which, in turn, will lead to an Agile organisation.

The truth is that none of these things will achieve that. The only thing that will create a more effective, adaptive, proactive, productive, happy organisation is a genuine desire from the people of influence in that organisation to want better. A desire to remove tired old processes and procedures that do not exist because they are effective but because they have always existed. To optimise the whole, not the individual parts. To care.

Managers and executives need to jump on the continuous improvement train and start to create a more effective world of work for their employees.

Thursday, August 22, 2013

Psychological impact of public criticism – AOL Story


A lot of people have heard of AOL, but until last week they may not have known much about Tim Armstrong, the company’s CEO. Recently during an internal team meeting of nearly 1,000 employees, Armstrong fired one his employees, Abel Lenz. This incident sent ripples all over the business world.

Some people believe that Abel was fired for taking pictures; others believe it is his association with the failing Patch project. Irrespective of the cause, this incident raises several questions: Is firing an employee in public the right thing to do? What are the repercussions of doing so in regards to the rest of the employees? What is the CEO’s role in the failure of a product?

This kind of firing,  impacts not only the psychological safety net of employees but impacts the employees morale, company’s bottom-line as well.

Read the complete the article on Techwell here…  I have shared many psychological research to show the impacts. In this article I have also covered different leadership styles impacting the employees.


Access all my articles on Techwell here

Sunday, August 18, 2013

LAST Conference slides available on SlideShare

image I have uploaded the Lean Agile And Systems Thinking conference slide “Does Agile help Innovation”  to Slideshare.  

Agile does help to an extent in building innovative products but overreliance would cause more damage than usefulness.   Based on my experience working in research labs building innovative products  and through well proven research data, I have shared many stories about raise and fall of  innovation  at  popular companies like 3M, Google, Amazon, CraigsLists, McDonald and LEGO

  • It was good to see, so many people turned up during this presentation, which is a reflection of interest in Innovation.
  • A meet up to discuss about  Innovation for social cause has been arranged in Melbourne next week, and looking forward to attend the same.
  • The conference was very successful with more than 350 people turning up at SwinBurne University campus with tickets being sold out.

Saturday, August 17, 2013

Look at reality and don’t get distracted with metrics

image With the advancement of technology that improves user experience, all manufacturers are spicing up the user interfaces and dashboards of their products. Recently, I read this article from The New York Times about the increased distractions due to extreme dashboard makeovers in cars. This is not surprising at all.

On our Agile projects as well, the stakeholders get carried away with Vanity metrics like Velocity, Engagement scores, Agile Maturity assessments, etc.

Even though these metrics are important, they shouldn’t distract the stakeholders from the reality…

Read the complete article on Techwell here…. 


Read all my Articles on Techwell by clicking here image


Design Thinking - Chat ?

image Any one interested in a catch up about  Design Thinking ?     If you are in Melbourne, drop me an email and we could catch up in person and, if you are oversees we could discuss over Skype or google hang out. 

My next article “What it takes to be successful in embracing Design Thinking”  would be available on Cutter shortly.

Design Thinking could help in building innovative and usable products.  Bringing a lean perspective, it helps in building useful features and avoiding wastes.

Sunday, August 11, 2013

What am I reading ? Brick by Brick


As I am learning, experimenting and playing around  Lean Startups, Design thinking and Innovation, this book Brick by Brick, How LEGO rewrote the rules of innovation and conquered the toy industry provided additional evidence to support my thinking around innovation and creativity.

I have just finished couple of chapters in this book, and I could feel the energy LEGO stakeholders have invested to make this a great company. LEGO started as a small and family owned business in a remote European town. They were happy with a set number of toys they were selling in Europe and were leading a happy go lucky life. However, one day they realized that their survival is at stake as the world is changing fast.  Sometime during 2003-4, a highly successful company was on the verge of going bankrupt. The leaders were determined to rescue it and seriously looked at enabling innovation for survival.

They religiously followed all the key principles of innovation, and one thing which made a positive difference is about the diversity.  LEGO used to be a purely European owned and confined to Europe. To enable diversity, they opened branches in several other countries in the world, and hired people from diverse backgrounds.


 Diversity key for innovation

I can’t stress enough, diversity in thinking is critical for innovation. Most companies ignore diversity, and look at purely  technical skills while hiring employees into organization. Here is how the requirement for any project looks like:

    C++ and Java expertise – minimum 5 years experience (in depth knowledge)
    Windows development expertise
    Unix (Solaris/Linux) development expertise
    Scripting languages such as Python, Perl or Shell scripts
    TCP/IP client-server development experience
    SQL commands and database knowledge
    Ability to work independently and multi task in demanding, time-critical environment
    Excellent communication skills

I have read somewhere that many innovative companies, including Google hire people with background from Mathematics, Biology, etc.  Diversity in thinking is highly essential for innovation.

Let me ask you before I end this post,  Do you have diverse thinking people in your team ?

Thursday, August 08, 2013

Difference between a Great leader Vs a Good leader

image Recently came across an article which had excerpt from Steve Jobs interview.  Here is what Jobs says
At Pixar when we were making Toy Story, there came a time when we were forced to admit that the story wasn't great. It just wasn't great. We stopped production for five months.... We paid them all to twiddle their thumbs while the team perfected the story into what became Toy Story. And if they hadn't had the courage to stop, there would have never been a Toy Story the way it is, and there probably would have never been a Pixar. "We called that the 'story crisis,' and we never expected to have another one. But you know what? There's been one on every film.

There are some beautiful messages hidden in the above statement.
  • I could see the Courage to halt things when things are not going in the right direction
  • Taking a stand to make a product  perfect
  • Willingness to take risks
  • Admitting and accepting the failure
  • Embrace the financial loss
The above mentioned great qualities I guess made Steve Jobs a great leader and inspite of his temper tantrums.
How many leaders do we see around in our organizations and projects who can courageously call off projects, provide a thinking time to redesign/rework and proceed later ?  

Most of the time, the companies are so focused on delivering the product on time within budget thus sacrificing the quality and customer satisfaction.
What's your view on this ?  
Have you worked with any leader with jobs qualities ?

Sunday, July 28, 2013

Speaking at Lean, Agile and Systems Thinking conference, Melbourne


Lean, Agile and Systems Thinking (a.k.a LAST) conference is a popular conference for Agilists in Melbourne.  The conference is on 2nd Aug at SwinBurne University.

I will be speaking about my favorite topic : Does Agile help in building Innovative products ?.  Check out more details about this conference here
If you are in Melbourne, don’t miss the opportunity to attend this event.

photo credit: Bill Selak via photopin cc

Complexity theory at 30,000 Ft

Here is the complexity theory article published on  Techwell.   This is at 30,000 Ft Level.

Most of our view about the world is based on cause and effect, which in turn is a linear way of thinking. However, the world works in a non-linear fashion with multiple agents acting in parallel. System thinking addresses this non-linearity by considering different parts of the system, their relationships with one another, and the entire system itself to solve a problem or create a future state. Some of the tenets include holism and reductionism.

The complexity theory, based on the premise of non-linearity, is the study of complex systems. Complex science embraces life as unpredictable, adaptable, and evolving. The key difference to systems thinking is that the complexity theory tends to solve a problem or build the future state with the assumption of uncertainty. Patterns and abstractions are used to understand complex systems.

Another key concept discussed focused on innovation. Chaos and randomness are the foundations for all innovations. It is proven that a detailed plan with a highly structured process won’t help in building a radical, innovative product.

Constraints emerge from the system to manage chaos and randomness, and the right level of constraint leads to self-organization. However, an over- or under-constrained system is not good for agility. There seems to be myth for agile teams regarding self-organization. Many professionals believe that just allowing the team to function on its own will lead to self-organization. In reality this is partially true; the leaders need to guide and ensure that there is the appropriate level of constraint emerging from the system.

and remaining part of this article is available here

Monday, July 22, 2013

360 Degrees feedback

The maturity of the company depends on trust and courage of employees. If the company is still using anonymous surveys to collect 360 degrees feedback, isn’t it a reflection of lack of trust and courage ?

Do you know any organization who gathers 360 degrees feedback in person ?

Evaluating testers – Past and Present

Here is one of  my guest post on Zephyr : Evaluating  Testers: Past and Present 

Just a gist of the article is below,

image Software testing has come a long way since 1960’s from debugging to defects prevention oriented approaches.  However, one thing that hasn’t changed much is the way the testers are evaluated. Let us look at the history and patterns of different evaluation techniques.

Let us being with the waterfall era. It was very clear that testers job was to catch all the defects introduced during the development stage. Testers had pretty much no options other than keep showing different metrics to prove their existence.

…………….and the complete article is available here

Image courtesy of ddpavumba /

Tuesday, July 16, 2013


imageI recently came across the the Oath of Non-Allegiance.  Now we have different parties pulling the software industry in different directions.  Some of them include, Scrum, Kanban, Lean, ScrumBan, etc.

Each party is willing to bet that their practices will help in Nirvana forgetting the real customer. Even though Oath of Non-allegiance is around from some time, I came across this recently.  This non-allegiance accurately reflects some of my thoughts. We shouldn’t get carried away with the methods but do what is beneficial for the customer.   At the end of the day, the customer and the business doesn’t care the tool we have used, they care about their experience, bottom lines, quality and the value.


Here is the oath of non-allegiance

I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation. (See

I added this to my blog as well.

Saturday, June 29, 2013

Agile Maturity assessments – Boon or Bane ?

Recently I authored an article for Cutter about the Agile Maturity assessments.  This advisory article covers the following topics

1. How Agile Maturity assessments are conducted in the organizations ?

2. What are the pattern of questions ?

3. What are the maturity levels being used in the industry ?

4. Typical organizations issues impacting the assessments ?

5. How does a good Agile maturity assessment look ?

Read the entire article  here

Sunday, June 23, 2013

Importance of radical innovation

Here is the recent article about radical innovation that got published on Techwell.   I am reproducing the same article below:

large__4601580531 Have you ever imagined having a private cloud hosted from your home? If so, you should check out this article that details how to set up your own private cloud in less than ten minutes with OwnCloud. There is currently a mixed reaction to OwnCloud, but we may not be that far away from building private Facebooks and Twitters on our own terms. Revolutionary ideas and technologies like OwnCloud could potentially impact the commercial cloud storage providers.

I think radical innovation is essential for survival in this century. But no one has been able to come up with a formula or a process to build innovative products like the iPhone or Google Glass. Why is this? Because innovation is a creative endeavor and is people dependent. Steve Jobs is a classic example of a radical innovator. He had the unique ability and creativity to sense the end customers’ requirements.

In addition, Steve Jobs is one of the best product owners (PO) in the world. How many Scrum projects have POs with the ability to come up with innovative product designs like Steve? Most of the POs I have come across are glorified requirement analysts. Even the Version One Survey 2012 has confirmed that POs are the least knowledgeable about agile. With such a poor track record of product owners, sometimes I ask myself whether it is possible to build innovative products in such agile environments?

Collaboration and innovation go hand-in-hand. Agile environments are supposed to be collaborative. However, the common understanding of collaboration in a software delivery context is to help each other without causing friction. If someone in the team is challenging ideas, he immediately is branded as non-collaborative, which is wrong. To be innovative, the team must understand the concept of collaboration and especially these three types.

The job market is another area that is impacted by innovation. Recently, I heard about this innovative 3D-house-construction printer. As I read this, I was wondering what potential impact this printer might have on the construction industry. Can this printer build the entire house on its own with little help? What will happen to the construction workers’ jobs? I realize that it is critical for employees and workers from all industries to build T-Shaped skills for sustainability.

I’ll leave you with this: Can an innovative product be built by applying Scrum or XP in your current project? What is hindering innovation in agile projects?

photo credit: Håkan Dahlström via photopin cc

Saturday, May 25, 2013

How waste impacts software delivery

Techwell, the popular Agile Magazine published my curated article.It is accessible from here as well.

square_2917573955 I was shocked to read the news in Australia that constant delays at the Brisbane Airport cost airlines $75 million last year. It looks like the closure of one of the runways resulted in a bottleneck, which in turn led to scheduling issues at the busy airport.

Consider the fact that in lean terminology anything that is not adding value is considered waste, also known as Muda in Japanese. Now ask yourself the following questions: Is there a possibility that the $75 million cost to the airlines will result in higher airfare for passengers? Is it fair for passengers to pay more for a ticket when they are not getting any value? This hefty cost is not adding any value to the airlines or to the passengers.

As a software delivery coach, I see a lot of examples of waste in every step of software development. If you are unfamiliar with the concept of development waste, Craig Larman and Bas Vodde have written an article, titled “Lean Primer,” which is a good place to start. Additionally, the following YouTube video provides an overview of different kinds of wastes.

Many lean practitioners use a concept known as “value stream mapping” as the first step in identifying wastes. Over at the website System Agility, the authors detail some creative games for teams to play in order to both identify and deal with the software garbage.

However, there are some unavoidable wastes that we can never remove. To counter this, many companies are using the concept of “Lean Six Sigma” to deliver a high-quality product. This video provides a nice introduction to Lean Six Sigma.

Due to Lean Six Sigma’s potential to increase cost savings, there is currently a huge demand for lean consultants worldwide. Unfortunately, getting lean consultants and setting a goal for them may not be sufficient.

Several companies have burnt their fingers while trying the above approach. The following article shows several examples that highlight the attention needed during a company’s lean implementation; some professionals believe that Six Sigma killed innovation at the 3M Company.

To conclude, let me ask you this: What wastes have you seen in your company and what did you do to avoid wastes?

photo credit: mugley via photopin cc

Wednesday, April 24, 2013

Why software services organization can never be Agile ?

The key members from the technology group are waiting to hear about the new project that the director is going to announce. The meeting is about to begin, and the room is filled with silence. They know that the project has something to do with Java, Oracle, and the cloud. The director starts explaining the importance of this strategic project and delivering it on time to the customer.

Read the complete article on  Cutter

Helpful guide to Daily stand up

This article was published on  Techwell, the place to go for what is happening now in software development.

image The daily standup meeting is a critical element of scrum teams. Its simplicity and benefits have even attracted the attention of practitioners of waterfall development.
The term “daily standup” originated from Extreme Programming (XP) while the term “daily scrum meeting” goes back to Scrum, of course. One should note that both XP and Scrum derived the concepts of daily meetings from software pioneer Jim Coplien and his paper on the Quattro Pro spreadsheet program.

In the simplest sense, a daily standup meeting is accomplished by having team members stand around in a circle with each person answering a few questions. But wait, life is not as simple as it sounds, and there are certain rules to be followed during these meetings. The rules cover the team’s time commitments, location of the meeting, and the meeting’s overall rigor, all of which make up the secret sauce for success.

Holding a standup meeting in a collocated environment is simple compared to holding a meeting with distributed teams, in which you need to be cognizant of time zone differences and language barriers. The use of tools—teleconferencing technology, webcams, and instant message software—can help you deal with remote teams. For more help on that front, you can read the Practical Guide to Distributed Scrum, which provides an overview of different tools and their associated pros and cons.

Most people recommend holding the meetings in the morning, keeping in mind what time the last team member arrives for the event. For some, noon seems to work as well.

As agile coach Rachel Davies explains, scrum meetings are not only about sharing yesterday’s work, but they are designed to help team members plan for the day and look to the future. If you’re working in a distributed environment, you might find help in this guide by Rally, which discusses fine tuning your meetings.

Keep in mind that there are several ways that daily scrum meetings can result in trouble for your project. For example, team members might stop attending the meetings or they could even complain that the meetings do not add any value or are a waste of time. The worst is when people make this a status update meeting.

There are several ways to fix these troublesome issues, including reinforcing the values and principles behind the meetings. Also, remember that command-and-control management issues might lead to many people-related problems, and you’ll need to address those issues if they apply to you.
Finally, if you still are having issues with standup meetings, Jason Yip, a principal consultant at ThoughtWorks, recommends a few good tips, like rotating the facilitators, breaking too much eye contact, and using improvement boards.

Tuesday, April 09, 2013

Building quality in – Do we need testers ?

Following article got published on  Zephyr recently.

image During the waterfall era, at the end of development, the completed code was thrown at testers who in turn would identify defects. These defects would get registered onto a tracking tool. In response to these defects, the developers would swarm around them and fix all of them for the next  one week. This process used to continue until the QA team signs of on all the defects.   

Now with the popularity of the Agile, Lean and Continuous Deployment, the developers are required to be more vigilant while coding. They are recommended to follow practices like TDD, ATDD to improve the code quality, reduce defects among other benefits. Since these practices are supposed to reduce the burden on testers, a lot of people are questioning the need for dedicated testers in the software development.  

In this article, I will address questions around the need for testers, the value they bring in, and their role in the context of Lean and Agile.

Why do we need to build the quality in?
Let me begin with the Lean Principle #2, Building Quality In. Before jumping to solution mode, let us understand the ways the quality issues crop up and the cost associated with it.  Quality issues originate at the beginning of the project and the top 3 reasons could be grouped into:

  1. Customer giving a wrong requirement and realizing it at a later stage
  2. The developer writing wrong code due to misunderstanding of requirement
  3. Developer understood requirement but coded a wrong logic

Irrespective of whether the mistake is by the customer or the developer, there is an effort involved in testing and rewriting the code. As per the 1:10:100 rule, the failure to identify the defect upfront could cost a fortune to the company.

Solving the quality issues:
First issue mentioned above could be solved by the development teams building the prototype and showcasing to the customer even before touching the code. Second and third issues could be solved by practices like TDD and ATDD.

If developers and customers work closely, ensure to fill the gaps and write quality code, can we still delivery a quality product without testers ?

In recent days, some of the lean startup companies have tried customer testing and crowdsourcing the testing without involving the testers. However, it is still not proven if this is the right model. A lot of people also agree that even the most experienced developers make mistake. The developers come with a specialized technical background and they won’t have the same eye as a tester. They are good at unit level testing, and they cannot effectively do the integration/system level testing. This is not something which could be improved by automating the tests.

Role of tester in Agile, Lean environment:
Many teams have tried building products just with developer testing and have got bitten badly as well. As one could see from this discussion, people have reverted back to include testers.

There is no doubt now that dedicated testers are needed in all projects. We still need testers to provide a neutral eye and their specialized skills to improve the quality. In fact, testers have now more empowering role to play than before.

To conclude:

  • Testers look at preventing defects and not just identifying them in the end
  • They get involved in the beginning of the project working closely with the product owners(PO) and developers.  They ask right questions about requirements and in turn making every get clarity on the requirements
  • They write acceptance tests, they do smoke tests and exploratory testing
  • They work as a support structure for the development team in ensuring smooth delivery of the project.
  • They think beyond just testing and embrace tasks that help the team in smooth deployment to production

Image courtesy of ponsulak /