Tuesday, September 23, 2008
I could not have expressed this better than Dean Wampler, check his blog post out.
Hug a developer today.
The reason for fixing bugs immediately is not only the cost of content switching later on when you have to come back, but it is even more the cumulative cost of fixing all the code you have built on top of the bug you introduced.
Think about it this way. Bug = Bad code. If you have a bug and continue development you are developing working code (good code) on top of that bug (bad code).
When you later on go back to fix the bad code, you will then have to fix all of the good code that is now broken because of the bug fix you introduced.
Software is build in stacks, the lower level affects directly the upper levels (many of them), if you have a bug lower in the stack and then fix it you will have to change all of the upper levels! And that is where the real cost is.
So, if you find a bug, fix it now. If you did not find a bug, think of ways you could find it faster -- before you build good code on top of bad code.
Monday, September 22, 2008
Many people have mentioned the need to include testers in Scrum or agile, and planning your processes with a testing step somewhere (normally close to the end).
All of these ideas are OK. There's nothing wrong with testing, the problem is that testing is done too late. Would you buy a car which engine was "fixed" after it came out of the line and didn't start? -- I certainly wouldn't not!
In software, like in cars, problems should be found early, very early. In fact problems should be found so early that they never reach the (needed) testing phase at the end (of the day preferably). This is why we need to stop thinking about testing as something separate from development or even coding. Testing must be part of every step of the process.
I don't agree with the proposal in this article. The tester should not be the one developing the test cases in isolation, and certainly not after the team has planned! The reason is that the tester will find faulty assumptions and possible design problems while thinking about the test cases. That information is crucial for the team to avoid building problems into the software.
Testers should be involved from the start. In fact, for each story that the team is planning in the sprint planning meeting, they should at the same time plan the test cases, review the initial assumptions and only after that should they actually plan the tasks to accomplish that story.
The best way to develop quality software is not to test the bugs out, it is to develop quality in -- this is why testers should be involved in every step of the process (Scrum in this example).
As Deming said:
Build quality in, don't inspect quality in.
Oh and by the way, if the test cases are (really) written why would the coder wait for the tester to verify that his code change works? -- Just run the tests immediately! It seems to be that the coder not running the tests herself is just a way to avoid feedback, which is key to Agile!
Saturday, September 20, 2008
Read it if you haven't yet.
Here are the pearls that made me post this:
“If you don’t have meaningful feedback then you’re not agile. You’re just in a new form of chaos.”
“Agile practices build a technical and organizational infrastructure to facilitate getting and acting on feedback. If you aren’t going to adapt to feedback, then this infrastructure is waste that will only slow you down.”
This is very much in line (or even the same) with one of the tenants of the TPS (Toyota/Thinking Production System), the PDCA cycle. In order to improve you need to learn, feedback is the fuel for the process of learning. No feedback no learning.
If you are not learning, you are not Agile. No matter what you are doing!
Tuesday, September 16, 2008
You’re not ready for agile if you:
* behave territorially. You mark your territory like an aggressive dog, refusing to share power or information, and let everyone know if you weren’t included in the decision. When something new comes up, avoid it or kill it.
* are inflexible. You’ve got a policy for everything. If it’s not in the book, it doesn’t exist. This is the way we’ve always done it.
* grow uncomfortable with uncertainty. In an agile project, you will not know the project end date or even what features will be delivered in the next iteration. You cannot stand this, and will insist on fixed dates and costs right up front.
* treat developers as a commodity; a uniform, fungible resource. They are all alike. You can’t trust them to think for themselves, you’ve got to make the important decisions for them.
* believe development is a linear process. You ignore unpleasant feedback. Rather than acting on it, you always stick to the plan, just like a politician in an ill-advised military quagmire.
Read the whole post here.
As Andy says: Agility is a mindset. Call me back when you are willing to change your mind.