Back in April, I agreed to be a team member on 2 projects split equally 50/50. This was an experiment I agreed to in order to experience first-hand why team members need to be dedicated to a single project.
It started out fine on planning day. Half the day was dedicated to planning for Project A and the other half for Project B. Half-way through the first sprint, it was apparent what was going to happen. My 3 hours daily allocation per project was working out to be more like 2 effective hours per project and as I was just about ready to implement something cool for Project A, I had to stop and work on Project B.
On the day when QA needed to have the last bits to test, I had incomplete stories on both projects. And of course, the next bad thing that happened was Project A wanted to be more valuable than Project B. So what did I do? Of course! I worked long hours on Project A.
In short, both sprints' goals were not met and I had very few completed stories. Each project became the other's impediment and I "thrashed" between the two of them getting very little done.
This experiment reminds me of a line from Patrick Lencioni's "The 5 Dysfunctions of a Team" where the CEO character had to tell her team they were to pick a #1 priority goal. A member asked why not 2 goals and her reply was, "If every goal is a priority, then none of them are".
In my case, this was exactly what happened. Both projects wanted to be #1 and it's just not realistic. One project needed to be killed (there were no other resources to work on it).
As Scrum practitioners, it's important to learn why certain things don't work well and why others do (such as XP practices). By all means, don't take my word for it. Experience is the best teacher and in this case, my experience was quite the eye opener. We have since moved to strictly dedicated team members. We still have shared resources but none of them own stories and they certainly don't sit at the table.
Showing posts with label Scrum. Show all posts
Showing posts with label Scrum. Show all posts
Wednesday, October 20, 2010
Tuesday, March 2, 2010
Unit Testing V. The Debugger
From a recent presentation I delivered, it finally hit me that the craft of debugging is really a form of manual unit testing. Yes, this may be a "duh!", but this was an "ah hah!" moment for me.
Think about it.
You compile your application and start it in the debugger. You then click, select, submit, type and probably click your way to the part of the code you want to make visual assertions on. You'll use watch windows and breakpoints so you can inspect the outcome. You then repeat this until the code is doing what you expect.
This is synonymous with:
1) instantiate the test subject (probably a class).
2) establish its initial state.
3) call a method on it.
4) use Assert()ions to determine if the outcome is the expected one.
5) repeat
Interestingly enough, it takes FAR longer to compile (integrate), run the debugger (instantiate and set up initial state), then make the Assert()ions (watch window, breakpoints and immediate window) then repeat the process. Also, you are human and therefore are subject to all sorts of distractions that minimize the probability of executing the same code path every time. This results in poor testing and invariably less than satisfactory code quality. Add 5 scenarios you need to test for the chance of screwing up is greatly exacerbated.
Unit tests, on the other hand, are repeatable, not subject to human distraction, do not require full integration of the application and can be shared with your team.
You'll find, if you're new to Scrum, that unit testing will save you a ton of time and give you a much better chance of burning down to zero instead of burning out.
If you're interested, let me know and I'll be happy to share my recent Unit Testing 101 slide deck with you as well as sample code (.NET) that demonstrates the basics as well as advanced concepts using a great addition to the Mocking world known as "Moq" (Mock You).
Think about it.
You compile your application and start it in the debugger. You then click, select, submit, type and probably click your way to the part of the code you want to make visual assertions on. You'll use watch windows and breakpoints so you can inspect the outcome. You then repeat this until the code is doing what you expect.
This is synonymous with:
1) instantiate the test subject (probably a class).
2) establish its initial state.
3) call a method on it.
4) use Assert()ions to determine if the outcome is the expected one.
5) repeat
Interestingly enough, it takes FAR longer to compile (integrate), run the debugger (instantiate and set up initial state), then make the Assert()ions (watch window, breakpoints and immediate window) then repeat the process. Also, you are human and therefore are subject to all sorts of distractions that minimize the probability of executing the same code path every time. This results in poor testing and invariably less than satisfactory code quality. Add 5 scenarios you need to test for the chance of screwing up is greatly exacerbated.
Unit tests, on the other hand, are repeatable, not subject to human distraction, do not require full integration of the application and can be shared with your team.
You'll find, if you're new to Scrum, that unit testing will save you a ton of time and give you a much better chance of burning down to zero instead of burning out.
If you're interested, let me know and I'll be happy to share my recent Unit Testing 101 slide deck with you as well as sample code (.NET) that demonstrates the basics as well as advanced concepts using a great addition to the Mocking world known as "Moq" (Mock You).
Learning from our elders
Over the past 5 years, I've come to the conclusion that there is something missing in the first few years of training aspiring developers embrace when they feel the pull towards software development as a career.
Scrum and XP practices have been around for quite some time now, 10 years or more to be more precise than "quite some time now".
I believe it's time for those of us who are more or less .NETters to take a break, reflect and start looking to our SUNners across the aisle (or Oraclers). Almost every tool we use in the .NET world to assess code quality got its start with a "j" in its name or at least with the absence of an "n". This tells me that there are either more mature experienced developers who are writing or have written applications in Java from which I can learn. The alternative is that we in the Microsoft camp write flawless code and therefore do not need to lean on quality tools.
I can tell you that I personally don't write flawless code. I lean heavily on quality tools to tell me when I'm an idiot. The beauty of those tools is they typically report my idiocy only to me and not to the people who assign my bonus. Of course, when I'm a real idiot and don't ask my quality tools if I'm being one, they will also quickly report to everyone that Tim had a poor thought moment.
Many of us pour libations out to Uncle Bob and Steve McConnell while others are clueless who these guys are and why we should care about what they say.
Here's an interesting factoid. From McConnell's Code Complete 2 book, he states that "a study conducted by IBM indicated that for every hour spent doing code inspections, 33 hours of additional work was saved".
These guys have been around the block a few times. We as developers should understand that their experiences can become our experiences if we only take a moment and listen (or read).
Scrum and XP practices have been around for quite some time now, 10 years or more to be more precise than "quite some time now".
I believe it's time for those of us who are more or less .NETters to take a break, reflect and start looking to our SUNners across the aisle (or Oraclers). Almost every tool we use in the .NET world to assess code quality got its start with a "j" in its name or at least with the absence of an "n". This tells me that there are either more mature experienced developers who are writing or have written applications in Java from which I can learn. The alternative is that we in the Microsoft camp write flawless code and therefore do not need to lean on quality tools.
I can tell you that I personally don't write flawless code. I lean heavily on quality tools to tell me when I'm an idiot. The beauty of those tools is they typically report my idiocy only to me and not to the people who assign my bonus. Of course, when I'm a real idiot and don't ask my quality tools if I'm being one, they will also quickly report to everyone that Tim had a poor thought moment.
Many of us pour libations out to Uncle Bob and Steve McConnell while others are clueless who these guys are and why we should care about what they say.
Here's an interesting factoid. From McConnell's Code Complete 2 book, he states that "a study conducted by IBM indicated that for every hour spent doing code inspections, 33 hours of additional work was saved".
These guys have been around the block a few times. We as developers should understand that their experiences can become our experiences if we only take a moment and listen (or read).
Subscribe to:
Posts (Atom)