Category Archives: Scrum

Extreme Programming, Scrum, Simplifying Software

Only One Retrospective Action-Item at a Time

Retrospective meetings are probably the most misunderstood and underutilized aspect of agile development.

If you know the expression, “the three most important things in real estate are location, location, location,” then you can relate when I say that the three most important things in software development are feedback, feedback, feedback. And, one particularly powerful feedback mechanism is the retrospective meeting. It’s how the developers give feedback to themselves — about their own processes.

I like to hold retrospectives early and often, at least once a week, sometimes once a day. That way, I can capture ideas while they are fresh on everyone’s minds. To make up for it, the retrospectives are kept short, 15 minutes MAX. In fact, if they go longer than 5 minutes, then something is wrong.

Why so short? Continue reading Only One Retrospective Action-Item at a Time →

Lean/Kanban, Scrum, Simplifying Software

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 →

Scrum, Simplifying Business, Simplifying Life

The Power of Self-Imposed, Extremely Tight Deadlines

Eight in Eight Band MembersNational 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 →

Scrum, Simplifying Software

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.
  1. Whole Team
  2. Open Workspace
  3. Daily Standup Meetings
  4. Big Visible Charts
  5. Retrospectives
  6. Customer Collaboration
  7. Collective Code Ownership
  8. Simple & Evolutionary Design
  9. Test Driven Development
  10. Refactoring
  11. Continuous Integration
  12. Automated Regression Tests
  13. Technical Debt
  14. Pair Programming
  15. Sustainable Pace
  16. Iterations/Sprints
  17. Iteration Planning Meetings
  18. Show & Tells
  19. Frequent Releases
  20. Release Planning Meetings
  21. 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

Continue reading Nationwide’s Tea Leaves vs. My Chart →
Lean/Kanban, Scrum, Simplifying Software

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? →

Lean/Kanban, Scrum, Simplifying Software

Some User-Story Examples

Kindle screensaver asking for feedbackI’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 →

Scrum, Simplifying Business, Simplifying Software

An Agile Dependencies Chart

I’m offering up this diagram as “the world of Agile Software Development according to Craig.” Let me know what you think.

One of the principles of Agile development is known as “Simple, Emergent Design.” And one of the ways to know if you have achieved a simple design is if the entire system can be diagrammed on a single sheet of paper — no matter how involved and feature-filled the system becomes — by applying the proper level of abstraction. (Note: It’s not unreasonable for parts of the diagram to be black boxes representing sub-systems, each of which have their own single-sheet diagram.)

A while ago, I took it as a challenge to try to describe the world of Agile development, itself, using such a single-sheet diagram. Continue reading An Agile Dependencies Chart →

Scrum, Simplifying Business, Simplifying Software

Simplifying User Requirements

It’s often said that one of the virtues (and challenges) of an organization adopting an agile methodology is that it will highlight existing dysfunctions. (The challenge being not to shoot the messenger.) One of the dysfunctions that typically, quickly surfaces is how user requirements can get overly complicated. In an environment that relies on written specifications that are “thrown over the wall” it’s the natural tendency of everyone involved to be as thorough as they can be. And who can blame them? In one respect, it’s their job to think of every contingency and bring all of their experience to bear. Working in a vacuum, it’s only natural to want to err on the side of caution.

Unfortunately, this all too often means that a requirement statement will take on a life of its own. As it evolves and gets fleshed out, the original reason or impetus for the requirement becomes clouded. It is barely retained through implication, if at all.

Allow me to illustrate… Continue reading Simplifying User Requirements →