Teams and Commitments
November 7, 2010 § Leave a comment
I hear this question often:
- We are working as a team but we seem to be always rushed
- We can’t seem to reap the benefits we thought we would get out of regular cadence on delivery.
Some of the questions I ask when I hear this are:
- Is the team committed and are the commitments made by the entire team?
- Are the teams small teams?
- Are these truly cross functional teams or are these just your old organizational structure which is silos in the form of teams handing off work from one team to the other?
- Is there mutual respect amongst the team members?
- When you find you are rushed have the teams realized that maybe they are overcommitting or are getting bogged down due to hand-offs?
And when the team does fail how does the organization react. Here are some of the questions to ask when the commitments are not met:
- Are tasks assigned within the team or do the members pick their own work?
- Is the expectation that the team will always have to meet commitments and if they don’t there is an attempt to find someone to blame?
- Are their partial credits given out and who gets them?
Building Trust
October 25, 2010 § Leave a comment
Building Trust as you work with a new team is crucial. To achieve a collaborative work environment, trust has to be built between all the involved parties be it team members or outside stakeholders. Trust helps teams function in a manner where they can help each other without fear.
Trust is all about letting go of human vulnerability. No one on a team wants to admit that they are wrong or they need help. You have to trust your team members and your management so that you can openly admit things you don’t know or understand. If building cross functional teams is important, having trust between team members is crucial to achieving cross functional teams. What you need to do is create a safe zone for the team members.
Reasons for lack of Trust
There are many reasons for lack of trust on a team. Below is a small list of things I have seen in the past that contribute to lack of trust:
- Individualism (Selfishness leading to hidden agendas) and Lack of mutual respect
- Belief that teams become cohesive when they have an outside enemy, ex, Management is the root of all problems.
- Politics
- Defensive Behavior leading to jumping the gun and blaming others or being aggressive.
- Managers that are more into evaluating each individuals actions in a team than understand the reasons. This leads to Fear, fear to admit failure or lack of knowledge.
- Unhealthy competitions
- Constant team member changes or not having dedicated team members.
- Specialization leading to hiding information for the ensuring job security.
- A team leadership that has a know-it-all attitude and arrogance that goes with it.
The above problems are, in no particular order, a small list of things you might notice on a team that can contribute to lack of trust. Although we understand that we have to collaborate to build software the issues list above can cause team members to retreat and thus not be part of a functioning team. One of the fundamental reasons leading to these kinds of behaviors is a lack of safety that team members perceive. I have been on teams where team members would confide to me that because of the volatile nature of things, they did not know how long they will have there jobs and so they were really careful in what they said, when they said it etc etc making them risk averse and defensive. This is an extreme case but shows what lack of safety can do. It is one thing to have incompetent team members and another when the management is constantly creating a culture of fear.
Things you can do
Below are some things that I think can help elevate issues due to lack of trust.
- Ensure that you as a coach or team member voice your concerns about lack of safety. If you have a team coach all the better because chances are that he/she will understand what you are saying and will start interfacing with Management and other leadership within the organization to change the culture of fear.
- Creating a personal link is crucial to leading people through challenging times so ensure that team members build ties that involve a better understanding of each other. Maybe do exercises like Myers Briggs etc to help everyone in the team understand each other’s nature and behavior.
- Establish a common purpose removing personal gain from the equation. Support individuals within and outside team that will help you achieve a more collaborative environment.
- If safety has been an issue set goals in collaboration with the team. You have to let them know that they their view points are important.
- When making decisions start by soliciting everyones buy-in, genuine buy-in, that is not done using brute force but by looking at facts. If you use facts team members will have a way to defend there decisions. I know this can make things slower but in the longer run it will help overall cohesiveness of the team. Also this will help individuals to build mutual respect as now they have to convince each other regarding a particular decision. If decisions are being made in a collaborative way you can be assured of this behavior “Since you also have the authority to decide, if you decide, you must at least follow your decision, and then this(decision) will not be forced upon you at all” – Taiichi Ohno
- Have sessions where you help team members understand each other’s motives and what makes them tick. Deal with relationship issues within and outside team. Your attempt should be to create a cohesive unit not just within the team but with all the stakeholders.
Trust is the key ingredient to achieving a well functioning cross functional team.
We tried that!
October 22, 2010 § Leave a comment
So, you are sitting in a team meeting where everyone is trying to come up with ideas to improve certain aspects of team performance; for example, everyone might be pondering how to improve quality of code. You see this as a great opportunity to talk about TDD. As soon as the words “test driven development” are out of your mouth, a senior team member/manager/technical lead/<insert cynical team member’s name> says, “We tried that and it didn’t work”. You look around for support from your team members, but all of them are silent. This is a result of not getting buy-in from your team members before you proposed the idea.
Your gut reaction is to have a reasoned discussion with this person. I want to warn you – the person that made the remark wants you to engage, but not for a reasoned discussion. He wants to have an argument, well maybe not an argument, but he is defensive and will not accept any reasoned arguments. Besides, you have no one in the team that is in agreement with what you said. Also, because the way this individual responded, you should know that he is used to having everyone hear what he has to say. Any disagreement from you could result in a screaming match thus diluting from what you had proposed.
What I want to propose to you is that instead of arguing or trying to have a reasoned discussion, tell the individual that you are not completely familiar with what happened in the past, but you think that TDD (your proposal) is a very good idea. You feel that since your arrival, you have seen the team grow substantially and now might be a good time to try again. Also, say that you understand the point that was made by this individual, but you feel that with new team members and the overall maturity of the team, it may work this time. At that point, tell the individual that you would like to talk to them after the meeting to hear about the issues that the team faced previously “so when we try this again we don’t make the same mistakes”. That’s it. Leave it at that. Don’t get sucked into any more discussion. Whatever remarks are said to you after that last comment, just say “let’s talk after the meeting”.
In most cases, you’d want everyone in the team to participate in this discussion, but in this particular scenario, you are facing a hostile individual with a strong personality that always gets his way. Also, you don’t have buy-in from other team members. By continuing the conversation within the meeting, you give this individual a podium to discredit any idea you’ve proposed without any team member’s coming to your defense. If other team members had agreed with you, you might have had an opportunity to have a time-boxed discussion having others supporting your idea. If you are alone, realize that you haven’t gotten the buy-in necessary to affect the change you want. Get the buy-in from your team members and then approach the matter again in the next team meeting.
There is place for battles within a team but also place for calm reasoned thinking. Choose the right occasion for the conflict.
PS: This is only useful if you have not had buy-in. If you do and still don’t have support, try having the reasoned argument, you might not win the battle but you will have tried and in the process might have changed someone’s opinion. If not then try some other time.
Value- III
October 21, 2010 § Leave a comment
http://xprogramming.com/articles/its-all-about-value/
I could not have said it better than Ron.
Presentation from my Talk
October 15, 2010 § Leave a comment
Here is a link to my presentation You Get What You Measure that I did last night at Agile Tour. And me talking:
A lot of what I talked was inspired by M Poppendieck and Ron’s blog entry http://xprogramming.com/articles/jatrtsmetric/
True Measurement
October 15, 2010 § Leave a comment
I got this story in an email from my dad and without dilution here it is.
A little boy went to a telephone booth which was at the cash counter of a store and dialed a number.
The store-owner observed and listened to the conversation:
Boy : “Lady, Can you give me the job of cutting your lawn?
Woman : (at the other end of the phone line) “I already have someone to cut my lawn.”
Boy : “Lady, I will cut your lawn for half the price than the person who cuts your lawn now.”
Woman : I’m very satisfied with the person who is presently cutting my lawn.
Boy : (with more perseverance) “Lady, I’ll even sweep the floor and the stairs of your house for free.
Woman : No, thank you.
With a smile on his face, the little boy replaced the receiver. The store-owner, who was listening to all this, walked over to the boy.
Store Owner : “Son… I like your attitude; I like that positive spirit and would like to offer you a job.”
Boy : “No thanks,
Store Owner : But you were really pleading for one.
Boy : No Sir, I was just checking my performance at the job I already have. I am the one who is working for that lady I was talking to!”
This is called “Self Appraisal”
Agile Tour – Philadelphia
October 14, 2010 § Leave a comment
Come check out our local conference today. This is the second year we are hosting this. I’ll be there as a host and a speaker: http://www.agiletour.com/en/at2010_philadelphia.html
Span of Influence
October 13, 2010 § Leave a comment
Deming said this about problems and blame
“Most of the problems we encounter (perhaps 90%) are the result of multiple influences, they generally cannot be attributed to a single cause. Assigning blame for a problem to the last person involved is worse than counterproductive, it will probably make the bad situation worse.”
Sadly though most organizations don’t get this. Most organizations use the cover of Accountability to assign Blame when things go wrong. Imagine what this does to a team when they are supposed to collaborate to solve a problem. Paralysis of mind and action occurs because no one likes to be blamed for things going wrong. And worst still it creates silos within the organization. Silos that cause departments to say: The development team is responsible for Technical Success and The product managers are responsible for business success. Organizations forget that there is no such thing as “Technical Success” (Kent Beck, 2004).
The situation is exasperated by Management types that insist on focusing on short term goals and bottom line. This inevitably leads to individuals trying to control every aspect of team and organizational workings. Instead of letting go of control, they become control freaks. The difference is in the two philosophies Span of Control and Span of Influence (Mary Poppendieck):
Span of Control
Hold people accountable for what they can control
Measure at the individual level fosters competition
VS
Span of Influence
Hold people accountable for what they can influence
Measure at the team level Fosters collaboration
You always want to see things from a point of “Span of Influence” if you ever want to achieve high performance and break down silos within your organization.
Closures- Ruby
October 10, 2010 § Leave a comment
I am learning Ruby for a project. Ruby utilizes closures extensively and the implementation within ruby for closures is elegant. So what is Closure: Well it is like an anonymous function that has a closed scope, meaning it has access to local variables. You will see closures being used everywhere in Ruby. Below is a very common example if you are doing Ruby on Rails
respond_to do |format|
format.html # show.html.erb
format.xml { render : xml => @order }
end
It is very easy to tell what the code is doing. Depending on the request the code block either execute the first closure to display html or executes the other closure to display xml. This type of closure i think takes advantage of the yield keyword. The yield keyword tells the function to execute the closure.
Below is an example where I use yield:
def closure_example
first = "This comes first"
second = "This comes second"
puts first
yield(first, second)
puts second
end
my_first = ""
my_second = ""
closure_example do |first, second|
puts "This is the middle. "
my_first = first
my_second = second
end
puts "value of first: '#{my_first}'"
puts "value of second: '#{my_second}'"
The above code will results in the output:
This comes first
This is the middle.
This comes second
value of first: 'This comes first'
value of second: 'This comes second'
Another simple example:
10.times {puts "display me."}
times is a method on 10 that executes the code in the closure(puts “display me.”) 10 times.
Final example
['ruby', 'is', 'cool'].collect {|item| item.upcase}
This line of code takes each element of an array, calls the closure on it, and then builds a collection with the results.
Milkshake moment
October 7, 2010 § Leave a comment
This story is from the book “Milkshake moment”. Well, it is my version from the book. So this guy, the author of the book(steve), goes to a hotel after a long day at a conference. He is really tired and decides that he wants to reward himself by having a vanilla milkshake. He calls downstairs to the concierge and asks if they have what he desires. The guy looks thru the automated system they use to place orders and reports back that they don’t have it. So Steve asks if they could send to his room vanilla ice cream, half a glass of milk and a long spoon, all the ingredients needed to make a shake of his own. So why didn’t the concierge at the hotel think of this? As steve points out that the hotel employee could have charged him any amount he wanted. Was the system making the hotel employee stupid or at the very least constraining his behavior? Was the system stopping him from being creative?
How many times have you heard this line: I know this process(choose yours) does not make sense, but that is the process we have at our organization? Why hasn’t that person stating this line stopped and said but this process does not make sense? And if they have stopped and asked this question how easy it is for them to change it? Are things really that rigid within an organization and if they are how can they really adapt to changing customer demands.
I wish more organizations could see that they have adults working for them and treat them with respect and dignity providing them the freedom to be creative. We build processes and systems and then leave them in place constraining creative behavior. More organizations need to realize the effects of complex and rigid systems.
There is something called standard work, but 