Wednesday, April 28, 2010
Thursday, April 22, 2010
Wednesday, April 21, 2010
Yabbitting is when people go through a sequence of resistance statements, where each statement begins with the words, “Yeah, but…”.
Like this: “Yabbit, our shop does shrinkwrap, so what works for some web app isn’t gonna work here.” or “Yabbit, we all work 80 hours a week, so we don’t need slack.” or “Yabbit, if you write tests + code, that’s more code than if you just write code”.
Let’s try again: Ever get the yabbits when introducing a new idea?
Yes, I thought so.
Tuesday, April 20, 2010
Monday, April 19, 2010
James Shore consults and writes about high performance software development for teams who are willing to be great.
Sunday, April 18, 2010
Friday, April 16, 2010
We still got flamed in the forums, but they went from "you're obviously stupid," to "I'm not convinced." By Internet forum standards, that's high praise.
Sunday, April 4, 2010
But at the high end, which looks like excellence incarnate, additional tuning may be required, because if a team truly hits 100 percent of stories on every iteration, then it is likely taking on too little work or deferring technical risk-laden stories until a later time. Effective agile teams typically run between 60 to 90 percent story acceptance, and even that percentage will vary significantly from iteration to iteration.
I have never read this before. I always thought you were supposed to get all of your stories done. He makes a good point that we are probably deferring technical debt to a later time. I thought you were supposed to do this though. I will keep looking around and see if other people agree with his statement.
Saturday, April 3, 2010
It took me additional years to learn the art of coaching, by which, in a nutshell, I mean communicating a vision and then getting people to see their own behavior, harness their own frustrations, and own their own problems.
How I Learned to Let My Workers Lead - Mark Needham - CodeBetter.Com - Stuff you need to Code Better!
Every system is perfectly designed to get the results it gets.
Friday, April 2, 2010
Thursday, April 1, 2010
I wasn't really being asked "Does Agile scale?" (By now, though, we know the answer: yes.) What I was really being asked was, "Does Agile work in large, dysfunctional organizations? Can I keep doing all of the ineffective things I'm required to do and still say I'm Agile? I can't have a co-located team--it's out of my control. I can't have active, involved product managers--they're too busy. I can't create cross-functional teams--it would disrupt our reporting hierarchy. How does Agile scale to my situation?"
It doesn't... at least, not well. Welcome to Mediocrity.
There is another subtle benefit at work in the philosophy of agility. When developers are forced to think through how the code will be tested, or better, when developers realize that they themselves will have primary responsibility to assure that it passes the test, a new psychology emerges: developers write the code differently than they otherwise would have. In other words, the developers build systems that are inherently testable by building in the interfaces and methods they need to see inside their components to assure they work as prescribed. This is one of the key benefits of agile methods, and these inherently testable systems exhibit higher overall quality.
Lately I have been feeling like every time we write tests before we write the code we end up writing higher quality code. I have no real way to prove that through logic though. It just seems like having to write the test forces you to decouple your code and simplify your interfaces. This process of decoupling and simplifying gets your mind working and you end up writing better code.
Maybe we should start calling it DTT (Design Through Tests) instead of TDD. People might be more willing to give it a shot if they thought they were focusing on design instead of focusing on tests.
As we start to move our domain model from an anemic existence towards one with richer behavior, we start to see the aggregate root boundary become very well defined. Instead of throwing a bunch of data at an entity, we start interacting with it, issuing commands through closed, well-defined operations. The surface of our domain model becomes shaped by the actual operations available in our application, instead of exposing a dumb data object that lets anyone do anything, and consistency and validity are a pipe dream.