The Agile Guy…

My journey on the road called 'Agile'

Archive for the category “scrum”

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 .

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.

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!

http://www.amazon.com/gp/product/0321637704/ref=as_li_qf_sp_asin_il_tl?ie=UTF8&tag=thaggu-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0321637704

Post Navigation

%d bloggers like this: