And no matter how much we try to hurry the seed along, Nature will run its course. Assigning ten gardeners won’t make the seed grow faster. In fact, fussing about with the seed could put it in peril.
And:
As my father says, “A garden’s for life. And it needs you.” Given this commitment, it’s natural to want to make repetitive tasks, like weeding, as effective and efficient as possible so you have time to “grow” things.
I couldn’t have put it better myself.
Denise Jacobs on A List Apart:
Why be concerned with your inner critic? In essence, an overactive inner critic acts as a deterrent between the seedlings of great ideas and the fruits of accomplishment. Don’t think you have an inner critic? Think again. The question is not if the troll is there, but rather how big, loud, and disarmingly influential and persuasive it is.
The article is targeted at web creatives. But, I think it’s equally applicable to my last post about courage. The inner critic is what you need the courage to overcome most of the time.
Kent Beck in Extreme Programming Explained (first edition, page 31):
We will be successful when we have a style that celebrates a consistent set of values that serve both human and commercial needs: communication, simplicity, feedback, and courage.
Of all the agile values, courage is the one that doesn’t translate directly into specific practices. Communication is fostered by sitting together in an open space. Simple design pushes the simplicity meme, as does refactoring out duplication and YAGNI. And, feedback is built into the processes with things like Sprint Reviews and Retrospectives. But, courage? Which one of the practices embodies courage?
This is not a question I was asking myself. It wasn’t even on my mind until my test-obsessed friend and mentor, Elisabeth Hendrickson, offered to let me pair program with her on Entaggle this week. You see, Entaggle is written in Ruby using Rails, rSpec and Cucumber – tools I’ve never used. And, I have (as Elisabeth so delicately put it) “competence issues” – meaning that I have a fear of incompetence.
So, I was fairly aware that it was going to take some courage to overcome my fear of not knowing the tools in order to just sit next to Elisabeth in front of a keyboard. But, it wasn’t until we were sitting there and Elisabeth was muttering on about how she couldn’t believe she was showing me the code in such a sorry state – in need of multiple refactorings – that I realized that pairing with me took as much courage from Elisabeth as pairing with her took from me.
Suffice to say that the next time I sit down to pair program with someone, I’m going to be cognizant of the courage it took to bring both of us together with the code. I might even go so far as to recognize it before we begin pairing, just to get the fears out in the open so we can move past them.
I also think the next time I pair with Elisabeth, I’m going to muster the courage to write at least one test. (I can’t believe we didn’t write one!)
Elisabeth Hendrickson, in Testing is a Whole Team Activity:
Testing is an activity. Testers happen to be really good at it. We need testers on Agile teams. But, if we want real agility, we need to see that completing testing as part of the sprint is the responsibility of the whole team, not just the testers.
To which my brain immediately responded:
Programming is an activity. Programmers happen to be really good at it. We need programmers on Agile teams. But, if we want real agility, we need to see that completing programming as part of the sprint is the responsibility of the whole team, not just the programmers.
Thing is, you could put any traditional software development role (e.g. “planner”, “builder”, etc.) into that paragraph and it would work. Try it. It really works.
Release and Iteration lengths are highly dependent upon local circumstances. But, given the ability, I prefer to do Quarterly Releases and Weekly Iterations.
Quarterly Releases may seem like a long time. But, many businesses are incapable of absorbing change much faster than that. So, unless you’re at a web start-up or in a highly regulated industry, I say try to match your release schedule to an existing organizational heart beat, like quarterly financial reporting. (Though, perhaps you don’t want to try to release new code the same day, week, or month you release financials.)
As for the structure of a release, here’s what I like to see:
Alternatively, I could also support a structure that looked more like this:
A development iteration is a normal iteration. The customer pick stories for the team to build, as described above. A slack day or iteration is just like a development day or iteration except that Team decides what work to take on, from exploratory testing to refactoring items on the Technical Debt Backlog, to spiking new technologies. No new stories are implemented during slack time, though new tests may be added to shore up code coverage. And, the review, deployment and planning iteration is exactly that: review the release, deploy it, and plan the next release.
Short iterations allow for rapid customer feedback. Longer iterations allow for more work to be accomplished. In my experience, Weekly Iterations provide the best balance between getting stuff done and running off into the weeds. Plus, it has the side benefit of guaranteeing you your weekends off!
I like to see the following structure to iterations:
As I hinted in my previous post, planning is broken down into three levels:
As I am not a product planner, I will not try to discuss how that process happens. Rather, I’ll focus on the active development process through Release and Iteration Planning. First off, I like some to see symmetry between releases and iterations. The only difference is the scale at which the two types of planning occur. Specifically, I like both releases and iterations to include:
Here’s what I mean by each…
Each release and iteration should begin with a planning session designed to select some number of user stories from the parent backlog for inclusion in the current cycle of the process. For example, during Release Planning, user stories are selected from the Product Backlog for implementation in the next Release.
Each release and review should end with a review meeting wherein the Product Owner (and other stakeholders) is shown the running acceptance tests and asked to approve or reject them. If an item is approved, it becomes part of the next release. If it is rejected, it is placed into the backlog for the next iteration (or release, potentially). These meetings are also often the source of additional user stories for the backlog. For example, the Product Owner may accept a user story as it is, but desire that something about it change in the next iteration before accepting the feature in the release review.
At the end of each iteration and release, after the review meeting, the whole team should get together to discuss process improvement. Some teams do this without the Product Owner. I recommend including them, as their perspectives are valuable and it serves to reinforce the concept of the “Whole Team.”
Next up: Release and Iteration Duration and Structure
Since you’re reading my blog, I’ll assume that you’re either a relative, or you’re already somewhat knowledgable about agile software development. So, let’s jump right in... (Sorry, Aunt Gina.)
Given my drothers, I prefer to mix and match terminology and practices from Scrum and Extreme Programming. Here’s what I like to do:
A Product Owner is responsible for:
The cross-functional Development Team (or Team) is responsible for:
A Coach (or Scrum Master) is responsible for:
The Whole Team, which includes the Product Owner, Development Team and Coach, is responsible for:
Next up: Release & Iteration Duration and Structure
While I was with patterns & practices, Microsoft invested a considerable sum of money to build the team a custom space that that lent itself to agile software development. My friend Darrell Snow was largely responsible for securing the project and shepherding it through the 40 some odd cooks who want to put their fingers in the stew. Overall, it turned out amazingly well - though the team spaces could be a bit bigger, IMHO. Even so, I really miss working in that space.
Most of the photographs below were all taken shortly after the team moved into the space. For context, the first picture shows what our team room looked like before the new space and the second picture is a floor plan of the new space.
I’ve talked about agile testing before, here, here and here. But, a recent thread on the Alt.Net Seattle Google Group got me thinking about it again. Here’s the response I sent to the thread:
Testing is a huge domain. If you’re familiar with Marick’s testing quadrant, you know that there are four basic areas that testing covers:
Typically, testers focus on the business facing tests. And, people with specialized technical skills focus on the technology facing tests. (Developers on the support programming side; Performance testers on the critique product side.)
None of these tests can be run before the software is written. But, the tests in support of technology can be written before the code. And, metrics for perf/load/stress can be defined before the code is written. I recommend doing all of that (unless perf/load/stress isn’t important to you). Obviously, exploratory testing is something that has to wait for the code to be written.
If I were designing an agile team from scratch, I would propose the following approach:
During planning:
During an iteration:
After story is functionally complete:
Exploratory testing should happen outside the constraints of a single story:
Once all acceptance tests are passing:
Variations:
How do you do agile testing?
In an article published in The Washington Post on July 22, Daniel Carpenter discussed why our government always seems to be working down to the wire. He blames deadlines (both real and conjured), stating that the "eleventh-hour effect" tends to delay decision making until the last possible moment:
When deadlines are imposed, decisions and bargains that could happen more quickly — because of momentum or normal work flow — often end up getting put off until the last minute. Social scientists have referred to this as the "eleventh-hour effect," and we see it both in experiments and in real life.
Furthermore, as a Harvard researcher studying the effect of deadlines on the FDA drug approval process, Mr. Carpenter and his colleagues discovered that drugs approved close to the Congressionally imposed deadline tend to be recalled often than others:
A few years ago I joined some Harvard Medical School colleagues in examining the deadlines that, since 1992, Congress has placed upon the Food and Drug Administration's drug reviews. Our research found that medications approved right before these deadlines were considerably more likely to be pulled from the market or have significant warning labels attached later on.
In other words, deadlines cause poor decisions to be made slowly.
I must admit, as a proponent of agile software development practices such as continuous, iterative planning, I find more than a grain of truth in this statement — and not just within the bounds of our government. In fact, it has been my experience that deadlines rarely encourage people to complete their work early, as the task at hand tends to fill the time available. And, besides, experience has also taught me that deadlines often seem arbitrary, feel capricious, and demotivate teams. (Details in footnote.)
Granted, businesses need to be able to plan around software development projects. There are end-users to train, products to market, and systems to integrate. And, no matter how arbitrary it may seem to software developers, a deadline does provide a business with a stake in the ground around which to plan these other activities. In this sense, deadlines perform a valuable service to the business. However, due to the "eleventh-hour effect" and the rush to finish work on time, deadlines can also do quite a bit of harm to an organization's systems.
Therefore, my preference is to manage projects using a stack-ranked, estimated backlog of user-stories and team velocity. The backlog shows me what's complete, how much work remains, and in what order it will be completed. The team velocity tells me when I can expect a specific story to be completed.
So, if I have a specific business need to see story X completed by date Y, then I can make the appropriate adjustments to the stack-ranking of the backlog without putting undue pressure on the development team. Furthermore, because user-stories are discreet, end-to-end slices of functionality, I can deploy them as soon as there’s sufficient business value to offset the costs of deployment.
The only question I have is could this management strategy be effective in Congress?
Footnotes: