The Agile Guy…

My journey on the road called 'Agile'

Keep going!

I happen to see this image in one of the fitness websites. It’s really inspiring. The message is very profound and encourages you to go ahead and always keep trying for what you believe and want to achieve. 

Many a times during coaching Agile teams you feel that the efforts that you put to help the teams aren’t bearing fruits. You tend to get disheartened and may think that should you still continue? or quit?

Keep going. Even though the results may not be very obvious and encouraging, the change has actually started to happen inside the team. Every conversation you have with the team members, every training you do,every new technique you introduce has actually triggered thoughts for change inside their subconscious mind. The time that you see no change in teams  is the time you need to keep going. 

A little more patience, a little more effort and a little more hope and you see the first flower bloom from the seed you planted. 

Keep going!

Agile Vocabulary Syndrome

Read Somewhere : The person  who doesn’t read good books has no advantage over the person who can’t read them.

One of the biggest blockers  in Agile adoption and transformation is that  people don’t read anything.

They think they do Agile if they say they do agile as Agile is nothing but common sense and can transition to agile by absorbing the vocabulary (I call it Agile Vocabulary Syndrome ).

I believe reading without practicing is useless, but practicing without reading can be expensive.



Agile Under Stress !

Have you ever come across a situation where the velocity of the team indicate that they will not be able to deliver the scope that is expected by the business by next 2 months.Its a critical deadline.And all features is all what the business wants.

What do you do?

Cut scope ?Nah..You can’t.It’s all or nothing..and yes the business do “understand” Agile.

Extend the deadline ? What !?Extending a “deadline” seriously impacts the relationships in an organization. If you can extend a deadline  means that you didn’t really mean it. People who like to declare deadlines, it’s a good reason not to extend them.

Whats next ? Stress…
When people are stressed, they often revert to doing things that (appear to have) helped them survive in the past. in pressure and deadline.

Some questions ..

How can you help them respond more effectively to it?

Why did they accept the estimates at the beginning? Why not now?

How often does the manager choose to help the  team and get the blame for not meeting deadline and be ready for the potential punishment , or stress out teams (which he can easily do) and meet the deadlines?

Agile salesman

I recently was at one of the busiest markets of New Delhi.. I encountered  lots of salesman trying to sell things to me that I don’t need.. I was amazed to see how desperate and passionate they were to sell stuff.  I wanted to buy some of them, but the extra sales pitch made me reluctant to but from them. I felt they were forcing me to buy. Finally I bought what I wanted from the person who asked me what I really wanted and gave me options to choose from without forcing any one.

This is what happens when coaches or consulants try to sell Agile to the teams  shoving down their throat.. People hate it. Resist it. Ignore it.
Always ask teams :
what their needs are..?
What do they really want.?
What are the options available to them.?
Are they comfortable taking the first steps.?
Do they need your support in their  journey..?
And there you go.. There is  more likely hood of teams “Buying”  Agile.


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..

Are you free? Part 1

The world seems to be divided on the basis of various groups like religion, ideology, philosophy, money, politics,nations,regions,even cities and what not..
You are identified with which group you are associated with.
It has some positives attached to it.
You feel secure,the community supports you and in turn you follow the rules of the group you are associated with.
The problem starts when you try to step into other group’s shoes and find it better ,as you feel more inclined towards it.
But no, then you break the rules.You fear to step out,you fear that you will loose support of your current group,you fear loss of comfort.
You fear being FREE.

Does it sounds similar ,when you adopt a process,methodology or a framework or set of practices, and are identified with the group you belong,and follow the rules of the group.
And then you want to try something different,but fear being not practicing as per the rules of the group you are identified,fear being mocked, fear being labelled failure.
You fear being FREE.

What does it take to be free?
Logic,reason,courage,self belief,instinct?.or a cocktail of all of them-?

Mahatma Gandhi once said: I reject any doctrine that does not appeal to reason and is in conflict with morality”

I will try to get some answers soon..

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 .

Stable Velocity ?

Agile Estimation and Planning introduces the concept of Story Points and Velocity.So it is all about relative estimation,with raw values called story points.And then you have velocity that is a rough estimate on how much a team can complete in a sprint.Velocit can be a great method for teams to focus on relative size of a story or a feature, but at the same time can be misused.When you have a lot of discussions around velocity like stable velocity, incresing velocity,decreasing velocity etc…, then you are in the same mindset as that of having more hours,less hours, more hours in an hour…Velocity is just the rate of completion of a product being developed, and it is just a number for planning. After the teams have been practising Sdrum for quite some time , the Veloicty trends gives you a lot of things to ponder uponPeople might looking for a term called “stable Velocity” which I believe is not worth discussion.

Bob Marshall @flowchainsensei recently quoted:
” Stable Velocity either causes unsustainable pace or undercommitement”

Here is a beautiful article on this topic by Bob Boyd .Please have a look

Hope you enjoy this !

Post Navigation

%d bloggers like this: