The Agile Guy…

My journey on the road called 'Agile'

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

Cheers!!

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.

Insane.

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

FreeGreatPicture.com-1609-tree

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?

BS!

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: http://tech.groups.yahoo.com/group/scrumdevelopment/message/55626 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
http://www.XProgramming.com

Source: http://tech.groups.yahoo.com/group/scrumdevelopment/message/55630 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,
Adam

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

http://implementingagile.blogspot.com/2011/09/increasing-velocity-vs-stable-velocity.html

Hope you enjoy this !

Will the Pigs (B)eat the Chickens ?

One of the principles of Agile Manifesto is:

“Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.”

How often are we able to create such environment , where the teams are motivated and full accountability of the work they do . I think, in order to have it , the two conditions should be true:

  1. The Chickens( managers/not working Agile/Scrum Teams) should trust and give freedom to the teams .
  2. The Pigs(Members of Agile/Scrum team members) should be aware of the freedom and take full ownership of work

Case 1: Chickens gives responsibility/control to Pigs. Pigs not ready to take ownership.

Smells :

  1. Team used to command and control, and have hard time when they have to take decisions.
  2. New members, in their norming /forming/storming stage , still struggling to take collective actions.
  3. Team has Dysfunctions. (Click here for a book on team dysfunctions)
  4. Heroism .
  5. Teams misuse the freedom given to them.
What to do ?
1. Coaching by an experienced Agile Coach.
2. Focus on positives of teams dynamics and small improvements the team does.
3. Appreciate the team work over individual contribution.
4. Change in the HR system for appraising employee performance.
5. Team building games/workshops.
 
 
 

Case 2: Chickens don’t give responsibility/control to Pigs. Pigs ready to take ownership.

Smells :

1. Chickens not aware of Agile.

2.Chickens aware of Agile,but less confident of giving control to teams.

3. Fear about loss of Status-Quo.

What to do ?

1. Coaching support from an experienced Agile Coach.

2. Read an article by Pete Deemer(CST) : http://www.goodagile.com/resources/roleofthemanager10.pdf

3. Change in HR policies in role description if needed.

4.Understand their concerns , and talk , to remove any fears.

5. Teams can be proactive, by taking initiatives and delivering results by self organizing.

Case 3: Chickens don’t give responsibility/control to Pigs. Pigs not ready to take ownership.

This is a classic case where:

Managers dont know.

Managers dont care.

Developers dont fix it.

What to do ?

Jeff Sutherland has a very very good technique for solving such dysfunctions called as Shock therapy.

More info http://jeffsutherland.org/scrum/SutherlandShockTherapyAgile2009.pdf

Case 4: Chickens give responsibility/control to Pigs. Pigs ready to take ownership.

A step toward Self organization..

Chickens and Pigs both needs to support each other in the journey of self organization.

Its not about who wins the battle.

It is all about how they support each other in Becoming truly self organized team.

I am now a Certified Scrum Professional

Wow !

I got a mail that my application for CSP has been approved ,and got a link where I can pay $250 to get the CSP Certification from Scrum Allaince.Finally , last weekend , I got it updated on my Scrum Allaince Profile.I also have a CSP and CSPO.

Click here to know more on how to become a CSP.

as per the website it says :

Becoming a Certified Scrum Professional is not easy. You will need to demonstrate that you have at least one year of actual experience using Scrum on a project, that you know how to apply Scrum concepts, practices, and principles, and that you understand how and why Scrum works. Potential employers can be assured that when someone is a CSP they have taken the initiative to go beyond a foundation-level understanding to achieve a depth of knowledge and experience in the Scrum process.”

This is my certificate :

 

It really feels  good , and also makes you take next ladder of Certification like CST/CSC.

I hope one day , I get that !

 

Agile Coaching

Being an Agile Coach takes a lot of Energy and patience at the same time.
You need to be sensitive to the people and situation of an organization.
Every word you speak has a great impact on your teams.
You really need to master the skills of Agile Coaching.

Here is a book on Agile Coaching by Lyssa Adkins.
Must read for anyone into Agile Coaching!

Post Navigation

Follow

Get every new post delivered to your Inbox.

Join 511 other followers

%d bloggers like this: