The Agile Guy…

My journey on the road called 'Agile'

Archive for the category “Agile Coaching”

Water the root , Enjoy the fruit

Yellow or dry leaves of a tree have more to do with its root, rather than its color, which is just an indication of need to water the roots. For a tree to flourish, to bear green leaves, with fruits, it’s the root that needs to be watered.

This is to say, put focus and care into your core every day and then the rest of the things will simply flourish and express itself.

At times, we are too busy in discussing and analyzing things at a very high level, trying to improve the color of the yellow leaves of the trees, by applying patches, thereby ignoring watering its root.

We are so obsessed with achieving better results every time, that ,metrics, processes and numbers become the focus of discussion in the organization. We keep on doing the same thing again and again, and expect different results, every time.

Measure more, measure accurately, implement jazzy-flashy processes with new fashioned terminologies of promises of skyrocketing results, make everyone occupied, and reduce cost at any cost!

And most of the times, you get the same results, or even worse.


You cannot be better if you keep doing things that gave you the same results.

You cannot solve problems; with the same thinking you created them.

How do you think out of the box, or destroy the box itself, and never be in it.

We all know subconsciously or consciously to a certain extent, what is the real thing that is stopping us to get what we want. Yet we focus on improving the color of the leaves, applying patches, quick fixes,.

Here are some of the things,I believe, are watering the tree of Product Development that bear the fruits of success.

  • Focus on automated unit tests and refactoring the code every time you see an improvement opportunity, quality will take care of itself.
  • Focus on having open, honest and professional discussions with customers; trusted partnership will take care of itself.
  • Promote culture of failing fast and encourage making mistakes, time to market and innovation will take care of itself.
  • Implement the DNA of Value Flow into the organization, and cost will take care of itself.
  • Focus on respecting and improving skills of the people in your organization, the results will take care of itself
  • Destroy the cubicles , both physically and mentally,  and the waste will have a tough time to find a place.
  • Focus on building great teams; and great products will take care of itself.

Litmus Test for Agile

How much percent are you Agile?
How much do you wish to increase your agility over the given time period?
What percentage Are you deviating from The Agile Checklist?

Ever heard these questions?


If you are trying to have a litmus test for agile,you are kind of standardizing Agile.
You don’t get it.
You are bundling practices and putting it in a box of compliance.

Its not important to clear the litmus test of agile.
Does it matter if you call yourself agile or get certified as Agile?

What’s more important is to understand what you are getting out of what you are doing.

Was the project successful?
did you deliver what was expected?

Is the team happy?
Would they like to work in the way they succeeded last time?

These are the questions that matter.
Sustainable pace,early delivery with high quality,motivated and enthusiastic people,happy customers is what should be focussed on..

It really Doesn’t matter which path you take, which name you follow,which litmus test you pass as long as you focussed on the values you thrive as n individual,team or organization..

How to handle technical debt

How to handle Technical Debt
Source: by Ron Jeffries
Do you have your views on technical debt in something that is published?  I would love to see that as I think it’s a view that does not get enough attention in the industry.
Let me put them right here. If anyone doesn’t find them quite obvious and clear, please inquire.
Never give code to the Product Owner that is not well programmed. This means clear code, well factored, supported by sufficient tests to be sure that it works.
If we are later going to look at this code and say that it sucks, it is not clear, well factored and supported by sufficient tests right now. 
If we do not know what clear, well factored code, supported by tests looks like, find out. We are cheating our team, our Product Owner, and ourselves.
When we do give code to the Product Owner that is not clear, well factored, and supported by tests, know that we have done a bad thing. There is some reason for that. This is a top priority for our next Retrospective. Figure out why we are doing bad work and fix it. Stop doing bad work.
P.S. There is no tradeoff against this kind of quality. We cannot go faster by skimping on clear well factored code supported by tests. It will bite us in the ass. You wouldn’t be reading this answer if it wasn’t already biting you in the ass. Stop writing bad code.
OK, despite our best efforts, we turn out to be incompetent. We now have code in the system that isn’t clear, well factored, and supported by enough tests. Perhaps we just noticed. Perhaps we have learned some stuff that we wish we had known sooner. Perhaps we bent under pressure. Doesn’t matter. We do a Retrospective and figure out what caused it, and remove the cause. But the existing code is still bad. What do we do?
We do not, repeat DO NOT, put code improvement “stories” in the Product Backlog. The main reason for this is that we cannot state the value of the improvement in any terms that the Product Owner can understand, and therefore the Product Owner can never schedule the stories. P.S. We don’t know the value either.
If we do put code improvement stories in the backlog, we can’t count the work against our Product Burndown or other progress measurements.  Why not? Because we have already been paid for this work when we did it badly last time. We don’t pay the mechanic again when he re-fixes the far. We don’t pay the programmer again when he fixes what he did poorly last time. Anyway, don’t schedule this work as stories in the backlog anyway. It’s just wrong. Stop it.
Then what do we do about this bad code? I’m glad you asked.
If our Product Owner’s stories do not cause us to make changes to the bad code, we leave it alone. It is not hurting anyone, and it will not rot. It will just sit there. Cleaning it up will take time away from stories, and it will pay off, if it ever does, an unknown amount at an unknown time in the future. Bad investment. 
If stories cause us to work in the bad code, the bad code will slow us down. It will make us throw up, causing extra breaks in the rest room. We will be sad. Therefore, follow the “Boy Scount Rule”, “Always leave the campground cleaner than you found it”. Clean up the code in a reasonable fashion. Do not take ten days to rewrite it. We don’t know how and anyway it’s inefficient. Just leave it better than it was. Over time, all the code that is troubling us will get better. 
That is all:
Don’t do it. 
When we do it, figure out why and stop. 
When we do it, leave it alone if it’s not in the way. 
If it is in the way, clean up the parts we pass through.
You may be wondering “How do we get the time to keep it clean? How do we get the time to improve the campground?”
We have a story to do. That story includes a certain amount of experimenting to figure it out. It includes enough testing to leave the code properly tested. It includes the time to make the code clean and well factored, including any code we have to touch to do the story. 
That’s how much time the story takes. So, that’s how much time we take to do it. If we take less time, we have just stuck a screwdriver into one of our own bodily orifices. Stop doing that. You’ll get a rash.
So. Any followup questions?

Ron Jeffries

Source: by Adam Sroka in response to above:
I agree with what Ron says above, but let me give you a slightly different take and see if it helps:
In TDD we refactor towards a Simple Design. Simple Design was defined by Kent Beck as a design having these qualities:
1) Passes all the tests (i.e. does what the PO wants)
2) Contains no duplication
3) Clearly communicates the author’s intent
4) Has no superfluous parts
As Agile developers we value the ability to safely and rapidly make changes to a codebase in order to reflect our current understanding of the product and our customer’s evolving needs. Simple Design makes this relatively easy. We just add or modify tests and then refactor mercillessly until we are satisfied that we still have a Simple Design. 
Technical debt can mean a number of things and I find discussing it with people difficult. So, I take a slightly different tac nowadays. Instead I talk about safety. 
If we don’t refactor mercilessly to a simple design we eventually slip into maintenance mode. Maintenance mode is where good programmers go to die. More explicitly, code is hard to maintain when it exhibits any of the following properties: 
1) Untested
2) Contains duplication
3) Obfuscated
4) Has superfluous parts (often in the form of Speculative Generality) 
This code is unsafe and must be fixed. Your life will be much simpler if you learn to work in a way that addresses these issues prior to the end of each Sprint. I have seen teams be successful carrying a limited amount of this crap from Sprint to Sprint, but IMNSHO even the best XP programmers I know don’t get away with it as well as they think they do. 
Hope that helps,

How a CSM course helped me..

I see a lot of debates on the value of CSM certificates.People have various opinion on it .Some say it is just a piece of paper,a show off, just a addition on your resume, waste of money blah blah…

I have been in Agile teams since last 3 years , and have faced various  challenges in transitions..Call it the mindset challenge, teams dynamics, current  designations vs Agile Roles ,etc.. I also had a chance to mentor teams in their Agile Transition..There were always some loose ends, that needs to be tied up.Some questions to be answered.

I got an opportunity to attend a local CSM course in my city by one of the CST (Pete Deemer). It was a great 2 day experience. It included games,industry experiences shared.And after Clearing the online exam, I got my CSM.But this is a part of what i got .Its been one year I attended CSM , but the community I got engaged , is still thriving me to get better day by day.I met people from various companies who had similar aspirations from the Course.We shared our challenges,learned from each other. This made me be a part of a community of Scrum professionals in my city.I started attending various conferences on Agile , presented and learned a lot. became members of some of the great online Agile/Scrum communities.Many of my co-workers also got inspired.

Six months later I got an opportunity to attend CSPO ,again by Pete Deemer. The various challenges and questions on a product owner role got better.We discussed on various aspects of this role and this helped me a lot in helping my teams out.

I am now a CSP , and my ambition is to help the software community in helping the teams achieve more.I truly believe that an individual brilliance is not sufficient in todays world. A person should actively be a part of a community , and share and learn from it as it is a collective knowledge.Most of the issues or confusions get cleared when you share it with the community. As problems are context specific , but  the knowledge of community will definatelt give you a thought to work on.

And coming back to CSM , it was a starting point  for me to ignite the passion of Agile/Scrum .

Post Navigation

%d bloggers like this: