It’s Software, Not a Unicorn – Why Tools Won’t Solve Organizational Dysfunction

About collabnet

  5 comments for “It’s Software, Not a Unicorn – Why Tools Won’t Solve Organizational Dysfunction

  1. ajayaram
    March 27, 2009 at 1:00 pm

    The comments are time tracking makes sense. But not sure what is the potential poison. I think the tool should support getting this data so that the team can use this data to self organize or for a team of junior engineers, Scrum Master can help organize or distribute the tasks.
    Actual hours spent vs estimated hours – The tool should support it, but its usage left to the team. A team member may use it to get better and also might be plan and organize better.
    Also please explain why this is deterimental.

  2. Michael James
    March 27, 2009 at 1:01 pm

    I responded here.

    Jim Schiel may have more to add.

    By the way, I would question the title of “ScrumMaster” for anyone who is distributing tasks, committing to work on behalf of his team, etc. The ScrumMaster is a coach serving his team, creating conditions for self organization. Not a taskmaster.

    –mj (Scrum Trainer, etc.)

  3. jschiel
    March 27, 2009 at 1:01 pm

    It’s hard to add to what Michael has already said – when task estimates become measurable (that is, they are compared against actuals), unwanted behaviors will occur that will cause team members to misrepresent tasks status or complexity or even to decline to take on certain tasks without extensive upfront analysis to ensure that their estimates are much closer to the actuals when finished.

    But let’s take this whole matter even a little further. I posted a new blog entry here to write out my thoughts on task estimates. Please take a look and come back here to let me know your thoughts.

    Good luck! And please, feel free to keep asking questions!!!

  4. Jon Torresdal
    March 27, 2009 at 1:02 pm

    Regarding sprint lengths I agree with you, but I’ve also seen and experienced situations where having one sprint shorter/longer than usual makes sense. Specifically with teams working with legacy code that needs a stabilizing sprint at the end where the normal sprint length is say three weeks and they need a two week sprint for stabilization. Some might not call this a sprint at all and don’t use any tool to monitor there progress and just start finding/fixing bugs.

    Regarding a tool like ScrumWorks supporting varying sprint lengths I think that could be ok, though bearing in mind that the user might misuse the tool as you mentioned in your post. But is it the vendors job to put a safety harness around the tool so that the users should not misuse it? Should the tool warn you if you create a sprint with different length than before, and argue why this is bad?

    Your point about time tracking I fully support. I also get a bad feeling when this comes up and I can’t really clearly explain why. In general I usually state that keeping track of time spent and keeping track of progress are two different things, and only one of them fits my view of Scrum. I therefore also recommend using two different tools, one for time tracking and one for “Scrum”.

  5. Jim Schiel
    March 27, 2009 at 1:02 pm

    As for Sprint lengths, I agree. There are times, like near the end of a project, that a shorter length can be beneficial. However, modifying more than is absolutely necessary is simply not advisable.

    As for the tool protecting itself from unexpected use — I feel very strongly here that a tool could never and should almost never act as a guardian against what it’s users want to do. Why? Because a tool can never be certain that it’s aware of all of the realistic effective alternatives. Should it warn against potentially ill-advised uses? Sure, but only if the user can turn those warnings off. Although, even there you should pick what you need to warn about. Apple has had a field day laughing about Vista’s warning. Obviously, there’s a limit. In my experience, it’s usually not the tool that causes the problems, but the lack of procedural discipline that is a root cause.

    As for that “bad feeling” you get when people want to track actuals, I used to get those too. I still do, in fact, but now I know why. It comes down to this, if we had machines performing Sprint Backlog tasks, we could eliminate almost all of the circumstantial causes that effect machine performance. In other words, other than temperature, humidity, parts maintenance, and the quality of the inputs, machines will perform the same and similar tasks within a very slim variance in elapsed time. When you replace the machine with the human factor, you introduce uncounted variables that affect the completion of the task. Skill level, task focus, how much sleep the developer got the night before, etc.

    All of these variables affect the performance of the developer and not necessarily within a very slim variance. In my personal experience, there are times when I can knock out complex code or detailed documentation in my first attempt and there are times when my first attempt makes me look like I’ve never seen a computer before.

    Therefore, comparing one task to another similar task might seem simple on the surface, but once you throw in the entirety of the human element, it’s a whole new ball game.

    I much prefer using Sprint Retrospectives to find out what is working and not working for the team. It doesn’t seem scientific, but it is effective and routine retrospectives (once after every Sprint) helps to “tune” the environment, recognizing that what works one month may not work the next because of the humans on the team.


Leave a Reply

Your email address will not be published. Required fields are marked *