|Done with Definition of Done or Definition of Done Considered Harmful (Naresh Jain)
Mon, 26 Jan 2015 12:26:49 +0000
Definition of Done (DoD) is a checklist-driven project management practice which drives compliance and contract negotiation rather than collaboration and ownership. Its very easy for teams to go down rat-holes and start to gold-plate crap in the name of DoD. It encourages a downstream, service's thinking mindset rather than a product engineering mindset (very output centric, rather than outcome/impact focused.) Also smells of lack of maturity and trust on the team. Bottom line: Its a wrong tool in the wrong people's hand.
|Melbourne: Upcoming Agile trainings and conferences (Venkatesh Krishnamurthy)
Sat, 10 Jan 2015 21:24:00 +0000
The Agile community is getting ready for a new and exciting year ahead. Several interesting and fascinating Agile trainings, conferences and workshops have been scheduled.
Here is the first list:
1 - Advanced Agile Master Class with Alistair Cockburn. 17-19 February
2 - Certified LeSS (Large Scale Scrum) Practitioner with Bas Vodde. 24-26 February.
3 - 1st Conf, 16 March 2015. For people starting out with agile. Alistair Cockburn keynote.
4 - Workshops for 1st Conf, including Introduction to Kanban, and Management 3.0 … with more coming.
NB - The code POBA will apply a discount to all of those events :)
|Scrum Australia 2014 : Build great products with Scrum + Design Thinking + Lean Startup (Venkatesh Krishnamurthy)
Thu, 01 Jan 2015 10:43:00 +0000
I had the privilege of speaking at Scrum Australia 2014 conference couple of months ago. It was a fascinating experience to stand in front of such an energetic and knowledgeable audience and share ideas. Scrum Australia team had put a lot of effort and energy in getting good speakers not only from Oceania but from abroad as well. I enjoyed every bit of this conference for 2 days.
The title of my topic was “Building products that customers love by strengthening Scrum with Design Thinking and Lean Startup methods” .
I believe that we need to combine various methods, and use their strengths to build the products. Scrum has its own strengths, and similarly Design Thinking and Lean Startup as well. However, none of these methods on their own can be used on their own to build great products.
First of all one needs to ensure that any new product idea is viable, desirable and technologically feasible.
It is very important that one has a good understanding of the problem one needs to solve. Most of the products fail mostly because of lack of understanding of the problems.
Design Thinking comes handy in articulating the problems, and Lean startup could be applied with product testing, pivoting.
I would like to thank Lynne Cazaly for beautifully depicting my session with the following “Visual Note”
I had put together this idea of bringing the 3 methods together (Scrum + Design Thinking + Lean Startup) long ago. This idea was published by Cutter as an Agile advisor. Cutter was also gracious enough to make this article public. The entire article is available here if any one is interested in getting into a detail a bit.
I have been attending Scrum Australia conference without fail since the last couple of years, and return with a load of new knowledge and experience. I am already looking forward for the 2015 conference :-)
|Correlation does not imply causation (Venkatesh Krishnamurthy)
Thu, 11 Dec 2014 05:26:00 +0000
Popular ideas being borrowed in the Agile community include the Spotify’s tribes/guilds, Google’s 20% innovation time and many more. In this advisor, I am challenging the readers to think before they act and understand the hidden secret’s of success.
Here is link to the complete article.
This advisor has been written to enable the Agile conferences attendees to look deeper about the “causation” aspect rather than the “correlation” .
|Self-Organised vs. Self-Managed vs. Self-Directed…What’s the Difference? (Naresh Jain)
Wed, 29 Oct 2014 04:17:56 +0000
Self-organised, self-managed and self-directed…do they mean the same thing or are they actually different concepts, where one might be more desirable over the other? In the context of an “agile” team, people seemed to use these terms interchangeably. However, it’s important to note that there are subtle, yet worthwhile distinction between each. Self-Managed Team A […]
|Program Committee’s Expectation from a Talk Proposal when Selecting It (Naresh Jain)
Sun, 12 Oct 2014 11:36:51 +0000
Over the recent conferences, I’ve had several people ask me the follow: I would like to better understand the expectations from the organising committee on the talk proposals. In particular, I would like your feedback on my talk submission so that I can work on improving the same. I think, this is a very valid question: […]
|How to make wall-related decisions in Distributed Agile projects (Venkatesh Krishnamurthy)
Thu, 09 Oct 2014 04:41:00 +0000
I authored the following article for Cutter which got published today. So, it is hot out of the press.
The subject that every distributed Agile team is questioning is the topic of setting up visual walls. Conflicts arise when purists argue in support of setting up visual boards across all locations, while the distributed teams consider it an inconvenience.
Many companies don't realize the importance of making the right decisions related to visual walls. Typically, wall setup is left to the ScrumMaster. These companies don't realize that this "single-handed" decision could result in loss of productivity, increased stress levels, and thousands of dollars in loss due to waste.
==== I am recommending a principle based approach for deciding if the information needs to be displayed on Physical wall or Digital wall. ===============
Wrong wall decisions or forcing wall decisions on a team could end up with stale walls and thousands of hours could be wasted in maintaining these walls. Be sure your organization considers the core principles during its exploration of walls.
Since this article is available only for Cutter Members, kindly continue reading rest of article on Cutter
|If you are start up, think beyond one user (Venkatesh Krishnamurthy)
Wed, 08 Oct 2014 06:22:00 +0000
As I am coaching and mentoring a few start ups in Melbourne and elsewhere, I have noticed common pattern of issues across the board.
Recently read a story about startup failure “Patient Communicator”. The founder built fantastic features applying iterative development method, however, it was never tested beyond his father’s medical center.
If you are in start up journey, think beyond one particular user !
|Key Principles for Reducing Continuous Integration Build Time (Naresh Jain)
Fri, 03 Oct 2014 08:23:37 +0000
Many teams suffer daily due to slow CI builds. The teams certainly realise the pain, but don’t necessarily take any corrective action. The most common excuse is we don’t have time or we don’t think it can get better than this. Following are some key principles, I’ve used when confronted with long running builds: Focus on the Bottlenecks – […]
|Large Scale Scrum (LeSS) (Venkatesh Krishnamurthy)
Tue, 30 Sep 2014 04:51:00 +0000
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
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).
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:
LeSS is based on some of the proven principles around Queuing Theory, Systems Thinking and Empirical Process Control as shown below.
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.
|What is Loyalty ? (Venkatesh Krishnamurthy)
Fri, 19 Sep 2014 05:07:00 +0000
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.
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
|Increase speed by incentives and sacrifice quality (Venkatesh Krishnamurthy)
Mon, 15 Sep 2014 03:29:00 +0000
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:
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.
|Your understanding of Kaizen is wrong (Venkatesh Krishnamurthy)
Sat, 13 Sep 2014 21:56:00 +0000
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
|Secret recipe for building self organizing teams (Venkatesh Krishnamurthy)
Sun, 31 Aug 2014 02:14:00 +0000
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:
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
|Selenium Conference 2014 Proposal Data Visualisation (Naresh Jain)
Sun, 24 Aug 2014 04:30:22 +0000
|2005-2015 Copyright © Agile Software Community of India|
|Website designed and hosted by Agile FAQs|