On numerous occasions I’ve observed long-time members of the Agile community complain about misinterpretations of what Agile means, and how it performed. Frequently this is precipitated by yet another blog post about how terrible Agile is, and how it damaged the life of the blogger. Sometimes it’s triggered by a new pronouncement of THE way to practice Agile software development, often in ways that are hardly recognizable as Agile. Or THE way to practice software development is declared post-Agile as if Agile is now obsolete and ready to be tossed in the trash bin. Read More
Sometimes we intentionally make our work more visible so that we can more easily see what’s going on. We do this so that, as a group, we get a better picture of the whole of the group’s effort. At it’s best, this is more than a dashboard that displays information. Instead, it’s a tool that’s used by the people doing the work in the process of doing that work. Read More
My article, “Project Communication: Caught in the Middle” has been published on projectmanagement.com now. It talks about the communication issues for a project manager in charge of an Agile project, and ways to manage both downwards and upwards.
(Free registration required)
In my recent posting on Separate Retrospectives, I mentioned sometimes performing a Safety Exercise at the beginning of a retrospective where the situation was unknown or seemed a bit charged with emotion. I was asked about that exercise.
This week, Chris Matts tweeted, “Contemplating whether GIVEN-WHEN-THEN is back to front. The system should do <outcome> WHEN <event> PROVIDED <
stimulus context>… Hmmm.” Let’s try an example. “Given I have $500 in my account, when I withdraw $50 then I have $450 in my account” becomes “The system should show $450 in my account when I withdraw $50 provided I had $500 in my account before.” It doesn’t exactly roll off the tongue, does it? Putting the result first makes the sentence both more complex and more passive. Yet I can understand the impulse that triggered this tweet. Read More
Documentation! It’s what we do.
People approaching Agile software development for the first time often ask about what documents are required. When I ask developers what annoys them most about other peoples’ code, I frequently get the answer that it’s not documented well. And I can’t tell you how many times I’ve heard people express the opinion that Agile software development is undisciplined because you “don’t do any documentation.”
Why is documentation so important to us? Read More
There were a couple dozen people who showed up at the Fool, last night, for my presentation on A ”Lingua Franca” to Ensure You Get the Right System. I’d like to thank them all for coming and for such lively participation.
These are exciting times. The tools of acceptance testing and behavior-driven development are progressing beyond the domain of the techies. They are entering the realm where they can help the Whole Team. Read More
A few weeks back, in a conversation with a colleague, I raised some issues that were important to me. Well, I tried to raise them.
“Don’t worry about that. Besides, I’m working on these other issues that are more important.”
That response reassured me–NOT! Read More
I applied for a new credit card. I wasn’t in the market for a new credit card. I shred credit card offers almost daily. No one sent me an offer that I found too irresistible. No, the funny thing is that my current credit card bank spent money and went to a lot of trouble to convince me to open an account somewhere else.
It sounds very odd, doesn’t it?
Now I happen to know that this particular bank has worked to embrace Agile software development. I know people who have worked with them to do so. And I’m sure that, considering the size of the organization, they’ve made great strides in improving their software development practice. Yet the events that transpired today tell me that they’re missing an important feedback loop–arguably THE important feedback loop–the one that involves the customer.
Here’s what happened: Read More
A while back, I was working with a young and cocky software developer. He was a smart guy, and sure of his abilities. He had seven years of Java experience, he said, and he knew how to write code.
As he was a new member of the team, I described the strategy I’d planned for a bit of code. I showed him what I’d already written, and asked him to complete the functionality.
“But I can do it another way.” And he described a different technique. Read More