Sunday, September 3, 2017

Tribute to my Agile "guru"s

Guru (Sanskrit: गुरु. IAST: guru) is a Sanskrit (an Indian language) term that connotes someone who is a "teacher, guide, expert, or master" of certain knowledge or field. In pan-Indian traditions, guru is someone more than a teacher, traditionally a reverential figure to the student, with the guru serving as a "counselor, who helps mold values, shares experiential knowledge as much as literal knowledge, an exemplar in life, an inspirational source and who helps in the spiritual evolution of a student".

So why am I telling all this to you? My path in Agile transformations was filled with many challenges. It would not have been smooth if I did not get connected with such a Guru who was friend, philosopher, guide, mentor, counselor and coach to help mold agile values into me, to share his/her experiential knowledge as much as literal knowledge and to be an exemplar in life with an inspirational source.

I have came across many such Guru's and I want to pay a tribute to the most influential Guru's through this post. I want to sincerely thank each one of them for being part of my journey.


Chad Holdorf

Chad was my first guru. Chad was the one who showed me the first step towards the agile ladder. He told me the basic of agile manifesto and principles. And that's all. He never told me how to implement these principles, neither he told me how to conduct sprint planning, demo and retro. It was weird feeling in the beginning. But later I understood that it was all part of coaching Agile. Agile itself works on an empirical process control. So I learned that he wanted me to do experiments and learn, rather than doing a spoon feeding for me. This helped me understand different frameworks like scrum. Thank you, Chad!


Vibhu Srinivasan

Vibhu taught me scrum. He was my trainer in Certified Scrum Master class. He was the one who created solid foundation of scrum knowledge in my brain. He was the one who explained all the scrum rituals in a fun way. The training given by him included many table exercises which helped me to understand sprint planning, daily stand up, retro, story points, complexity, etc. I also learned from him on how to train somebody on agile-scrum. Thank you Vibhu!


Ashish Dhoke

Ashish showed me project management side of Agile. Until I met Ashish, I knew only scrum and kanban. This was the first time I learnt other siblings of Agile like DSDM, Lean, etc. He conducted 3 days of training on PMI-ACP for me and I never felt tired in the class. I also learnt the value part of agile from Ashish like ROI, IRR, etc. Getting certified by PMI would not have been possible without Ashish's guidance. Thanks Ashish!


Sachin Dhaygude

Sachin was (and is) a friend, philosopher and guide in my agile journey. He coached me on coaching skills. Sachin was the one from whom I was able to clear my thoughts around story point and relative estimation. He taught me soft skills as well which come handy while coaching anyone on Agile. His skill/art of explaining any difficult topic in a simple way amazes me always. I was able to put forward some of my ideas during his training, which I was not able to implement before, but after the training it was so easy to implement. Thanks Sachin!


Vineet Patni

Vineet is always looked at as an Agile evangelist. He coached me on ICP-ACC certification. His training was the most interactive training I had ever had. Vineet created the most brain damage during training. Vineet helped me to come out of project manager role and mold into an agile coach role. He used several real world examples to explain Agile principles and Agile mindset. I was able to relate with the human part of Agile. Thank you Vineet!


There are many more "guru"s to come. I will keep this blog post updated.

Wednesday, May 24, 2017

Scrum Master

"You will be scrum master of this from next week!" These are the words that you hear and then you find yourself in a mess. You really don't know what to do from next week? Your first reaction should be "Will I be a full time scrum master or a part time one?"

Wednesday, February 22, 2017

Definition of Done

Dear agile team, Don't let anything that's not DONE into your production.

In this practical and dirty world of software development, many roles work together on a user story and do their tasks to complete the user story. For a role, when s/he finishes his tasks, s/he might think that s/he is done. But we need some tool which will help the team and the product owner to get the confidence that a user story is really "Done" Done. With different members doing work that is "finished" at different times, how can the team and the Product Owner, know when a story has truly been completed?

Definition of Done (we will call it DOD henceforth) gives a confidence to the team and product owner that the story is done and can be released to production any time. Definition of Done is a list of things that must be finished before the work/story is accepted by the Product Owner. Merely testing the acceptance criteria can not ensure that the story is done. Acceptance Criteria is just a part of DOD. DOD also has lot of other things like -

Wednesday, August 3, 2016

Are we burning the right thing?

Is our development effort aligned with the business?
Are we getting good value out of our development team?
Is our team working on the right items?
Are we on the right track to get more value out of the team?
Are we burning the right thing?
Product Managers get a severe headache when these questions bang-bang their minds. Our development teams are usually great and great teams can deliver great software, but when the software delivered isn’t of high value the Business (i.e. the Product Managers) will still not be happy!

Tuesday, July 19, 2016

INVEST in user stories and perform SMART tasks

What is a good user story?

In scrum, we get married to user story. Have you ever thought of which story is good to get married and which is not? What are characteristics of a good user story? The acronym "INVEST" can guide you to identify the good stories:

I – Independent
N – Negotiable
V – Valuable
E – Estimable
S – Small
T – Testable


Stories are easiest to work with if they are independent. Its better for them to neither overlap with nor depend on other stories and we should be able to schedule and implement them in any order.
We can not always achieve this. Once in a blue moon, we may say things like "3 points for the first screen, then 1 point for other screens."


A good story is negotiable. It is not an explicit contract for features. The details will be co-created by the customer and development team during development. A good story captures the essence, not the details. Over time, the card may acquire notes, test ideas, and so on, but we don't need these to prioritize or schedule stories.

Monday, July 4, 2016

Definition of Ready

Dear Scrum Master, Don't let anything that's not READY into your Sprint.

Imagine, you are going to cook a meal for your spouse for your anniversary evening. Before starting to cook, you actually check, whether all the ingredients are available, you check if those are in the sufficient quantities, you buy out the missing things and then you start cooking, Right? The same is true for user stories.
User stories after their birth, have very tiny details. It is difficult for the team to commit to such stories. Team needs discussions, analysis, arguments and negotiations to groom the stories, so that the stories become matured and then team can commit to the stories.
But how does a team know, if the story is really ready to be taken into the sprint?
As user-story becomes clear and team doesn’t have any unanswered question and dependency remaining, the story is considered "READY". The list of items which help us to identify the "READY"ness is called as Definition of Ready (DOR).

Every user story must satisfy the INVEST criteria, before team commits to it. Every dependency
from the story needs to be removed, before team commits to it. All the necessary softwares and hardwares must be ready, before team commits to any story. These and many more items comprise into a list i.e. DOR.
Before committing to any story, the team can check if the story meets all the DOR criterion. If not they can reject the story, so that the stakeholders can put the missing details into it.
Agile promotes "Courage" as its core value. Courage to say "No" is important while committing for the stories. DOR gives us the sensible reasons to say "No".

Sunday, June 26, 2016

Testers role in agile

What testers do in agile?

coders + testers

In a perfect agile team, there are no people called as developers and testers. Entire team contributes to development and testing. So this article is non-existent in a perfect world. But in the real world, where developer (actually coders) and testers were in existence before agile came, this article finds a valid place. Development team does not mean coders. Software development comprises of coding and testing. So till now, we were mistakenly calling the "coder" and "developers". My view is "developers" = "coders" + "testers". So when we say development team in agile, we really mean coders and tester and any other roles which are required to achieve the say do ratio.
In non-agile environment, the role of a tester includes analysis, test case design test case writing, and test case execution. He is involved right from the project initiation stage up to when the project is closed.
However, in agile environment his role primarily is to work as part of a development team, and to ensure that quality is built into a product by working closely with the product owner. This helps the tester get more details out of the story cards. It will be difficult for the development team to meet the acceptance criteria and consider a story "done" if the tester does not engage him/herself with the product owner. The role of a software tester in an Agile environment goes beyond “just testing” and logging bugs.