“The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man.” ~ George Bernard Shaw
Brainstorming for One
I just went digging through some old blog posts of mine, and a found a few worth reposting. Here’s an excerpt of one from early 2004…
A colleague of mine gave a presentation yesterday about brainstorming techniques. For example, he talked about how an initial pool of ideas can be built up in the generation phase by pushing the boundaries, piggy-backing on the previous ideas, and inverting or negating the previous ideas.
I will never forget the first time I tried it. Continue reading Brainstorming for One
Scrumban = Scrum + Kanban
I’ve been a follower of Scrum ever since I first heard Ken Schwaber present the subject at an XP user group meeting in Pasadena in ’04. Scrum has come a long way since then, boasting over 50,000 Certified ScrumMasters worldwide. Scrum is well beyond the innovator and early-adopter stages and firmly entrenched in the early-majority stage. People are no longer asking, “Will Scrum work?” but rather “How will Scrum work for me?”
Unfortunately, along with popularity comes dilution and permutation. Surrounding a core of solid, serious adopters lies a realm of half-serious adopters sometimes jokingly, but affectionately, referred to as “Scrum-buts.” You hear them say things like “We’re doing Scrum, but we’re not doing daily standup meetings,” or “We’re doing Scrum, but we can’t track velocity because the iteration work keeps getting interrupted with support calls.” Scrum purists would say that these people are missing the point of Scrum. That the full measure of benefit from Scrum cannot be realized by adopting it piecemeal.
I used to be that kind of a purist, but I’ve changed. Continue reading Scrumban = Scrum + Kanban
Not Taking Collected Thoughts for Granted (GTD)
A common stumbling point on the road to adopting David Allen’s Getting-Things-Done methodology is that we get too wrapped up in the mechanics of the system and fail to think about what we are doing. We stay bogged down in the trenches (at the airport runway level, as Allen puts it) for far too long, and don’t spend enough time at higher elevations looking down at the big picture of what we are up to and where we are headed.
One particular sticking point is when it comes to processing the thoughts that are captured with our “collection tool.” Continue reading Not Taking Collected Thoughts for Granted (GTD)
Kanban Slides Posted
Here (finally) are the slides (as a PDF file) for the Intro to (Personal) Kanban speech that I gave at the OCDUG meeting on July 26th. Actually, the set of slides I posted just now has been embellished quite a bit from what I actually used during the presentation (which is why it took me a while to post them). If those embellishments spark any questions, feel free to post a comment here, or contact me directly.
If you enjoyed this speech, then you might also be interested in materials from other speeches that I’ve given in the past. You can find them on the Downloads page.
The Power of Self-Imposed, Extremely Tight Deadlines
National Public Radio runs a show called “The Story.” Tonight’s story (listen here) was about a group of three well-known musicians (Amanda Palmer, Ben Folds of TV’s Sing-Off, and Damian Kulash of OK-Go), a famous writer/lyricist (Neil Gaiman) and a producer (Sean Slade) who decided to try an experiment this past April. They wanted to see if it was possible to produce a music album of eight original songs in eight hours, completely from scratch. They called the project, “Eight in Eight” and the album they produced is called “Nighty Night.”
The group didn’t quite meet their ambitious goal. After 12 hours, they stopped with only six songs under their belts — an impressive feat, nonetheless. Continue reading The Power of Self-Imposed, Extremely Tight Deadlines
Nationwide’s Tea Leaves vs. My Chart
The thousands of developers at the Nationwide family of insurance companies are exemplary practitioners of agile software development. They are led by Tom Paider, who uses a list that he calls the “21 Agile Tea Leaves” to measure how well any one team is doing.
- Whole Team
- Open Workspace
- Daily Standup Meetings
- Big Visible Charts
- Retrospectives
- Customer Collaboration
- Collective Code Ownership
- Simple & Evolutionary Design
- Test Driven Development
- Refactoring
- Continuous Integration
- Automated Regression Tests
- Technical Debt
- Pair Programming
- Sustainable Pace
- Iterations/Sprints
- Iteration Planning Meetings
- Show & Tells
- Frequent Releases
- Release Planning Meetings
- Story Cards w/Acceptance Criteria
Previously, I posted what I called an Agile Dependencies Chart. These two documents are remarkably similar in content. Other than the obvious fact that
TDD Slides Posted
Here are the slides (as a PDF file) for the Intro to Test-Driven Development speech that I gave at the SCQAA meeting last night. I haven’t seen the speaker feedback forms yet, but based on the comments from people walking up to me afterwards, it was an effective speech. In particular, everyone loved my grand experiment to demonstrate TDD — without requiring any programming knowledge — by having the audience break up into teams and write limericks test-driven.
If enjoyed this speech, then you might also be interested in materials from other speeches that I’ve given in the past. You can find them on the Downloads page.
User-Story Sizing: How Small is Small Enough?
The S in the INVEST mnemonic is a reminder to make your user-stories small. The trick is in knowing how small is small enough. The rule here is to make the story as small as possible, yet that it retains some measurable amount of intrinsic value — something that, when demonstrated to the end users, they’ll agree is an improvement to the system. Conversely, Continue reading User-Story Sizing: How Small is Small Enough?
Some User-Story Examples
I’m often asked if I have any good user-story examples to share. Until recently, I always had to answer, “No,” because I didn’t have permission from my clients to share their work product. Then, the other day, it occurred to me that I could kill two birds with one stone. As an avid user of Amazon’s Kindle e-reader, I had some feedback to share with Amazon — feedback that I hope might improve the already excellent product. I decided to write up my feedback in the form of user-stories, complete with acceptance criteria. Below, therefore, you will find four new-feature stories and one bug-report story, each with three or four acceptance-test scenarios.
I did this partially just as a mental exercise, but I also reasoned that Continue reading Some User-Story Examples