My fear of robots, er... tools, pt 3

​I have a fear of managers using tools to judge their teams in the absence of interaction. 

I have seen managers request the feedback from tools to gather data to support the endeavors of the team. When pressure is applied for acceleration, increased efficiency, or more productivity, the team is punished with the data pulled from the tool without the valuable conversation that should go with it. ​

​Estimates are considered exactimates; precise commitments by the team. 

​The output of the tools are distributed around the organization without education on the new mindset of how we work.

​Trust broken...

MechaGodzilla-Monochrome.png

My fear of robots, er... tools, pt 2

Teams may change behavior to support the shortcomings of a tool.

I have observed teams in the past that would forgo good behaviors because their tools did not support them. Of course there is the chance for a team to pick up bad behaviors because a tool reinforces it. 

A tool should exist to support the endeavor of the team while allowing their good practices to flourish. ​

dalek-sml.png

So, I started Blogging...

I have started this blog. I want to avoid my continual failure in blogging, stopping. Every time that I have started a blog in the past ended in blog abandonment. I am not sure what the reason is behind me abandoning my blogs. It may be commitment issues.

I would say that I am really passionate this time, but I was passionate last time. ?

The thing that I believe is different this time is that I know more than I ever have about what I want to share.

We will see...?

good luck - small.jpg

Capacity Planning - GASP

A GASP is a generally accepted Scrum Practice.

This is another issue where it's not wrong or right. It is a difference in approaches. I feel that a more mature scrum team does not need, and will not want to, plan by hours. I have coached teams to strive towards that. Teams forecast at the story level. We always have. (Well we used to commit!) We just use the hour estimates on tasks to verify that we are not thinking crazy. Over time we will just be able to eyeball if we can get things accomplished. I like the concept of doing it from the beginning. Pushing the team to maturity earlier than later is my suggested path.

Remember to take time and think about what value new methods provide. In this case, the team commits either way. No need to waste time with hour estimates. I suggest conservative commitments when they do this. Then a gradual push to see where they can get to. When they find their limits they will know their velocity. If they pull in more than they committed to, the customer team wins! The PO also wins in that the product team will be able to deliver a Release Plan really fast because there is not a great deal of time used in finding the velocity based on hours. If the PO does not deliver the Release Plan fast, then it is my experience that the Release Plan gets delivered to the PO.

file