Tags

, , , , , , , ,

Hello all,

This week we had an interesting activity where we met with various colleagues from other parts of the company and discussed the many organizational aspects of Team work and software development. This gave us an opportunity to learn how others went about their day and delivered their product.

the_fox_and_the_crow_by_evanira-d5kid52

evanira.deviantart.com

As per the title of this post, what I would like to highlight from this discussion is the fact that after so many years of advancements in management and processes regardless of whether it be considered Agile/Lean we face the constant threat of human nature when we accomplish work. Like in the story of “The Fox and the Crow”, in order to get his prize, Fox make good use of Deception to the sadness of the Crow who lost her meal and a bit hurt from the whole ordeal. In my many talks with Teams or people surrounding project delivery (mostly Software products) it seems that there are no reservations when it comes to the use of Deception in order to manipulate a situation in their favour. A great example of Deceptive behaviour was Team members fabricating Sprint Burndowns because people surrounding the Team were quick to panic when the graphic would not “burn” and in turn pressuring them to have a continuous progression. This behaviour only aggravates the root behaviour we are trying to fix, which is lack of Trust. This is mainly an example to provide context into the type of Deception that I am referring to. In the context of our discussion, the topic of Estimation came up and have to say that this subject has to be the biggest piece of “Cheese” plaguing our industry today. The question was asked: “… Do you use Story Points or Man days to estimate your User Stories?” A volley of answers came quite quickly, such as “No, we use Story Points”, “We use Story Points, though they are mapped to Man days”, etc. Listening to this I had to ask “What are you using? and Why?”. Explanation came to conclude that since they had to report in Man days, therefore they just got tired of trying to figure it out and developers would simply map Points to Days. I am pretty positive that I have spoken about this before and will likely do so again, we have a simple reason why we moved away from using Man Days because it was Deceptive!!!! People took comfort and let go of the cheese simply because they heard what they wanted. Courage is required to stick to a measure which is both “good enough” and “predictable” for all to succeed in delivering a quality product. Points/Sticks/Beans are a measure that does away with the conventions of time simply because Software is more often than not too complex to simply attribute a value which stands for absolute predictability which is Man days! false expectations arise from the use of such “metrics” and Trust erodes as Teams are unable to stick to those estimates. What results is an even worse Deception as Teams start to adopt a behaviour of “Buffering” in response to lack of Trust and this leads us to our over running costs ,etc. I dare say again, learn to stay away from such “metrics” and disrupt the standard management conventions if you hope to regain a “real” sense of trust. This might actually lead to an increase in employee engagement which seems to plague our Corporate world!!

Cheers PS 🙂

Advertisements