Category Archives: Simplifying Software

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 →
Events, Extreme Programming, Simplifying Software

TDD Slides Posted

2 Comments

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.

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 →

Book Reviews, Simplifying Business, Simplifying Software

Now Reading: “Continuous Delivery” by Humble and Farley

My local study group has selected our next book: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble and David Farley. This one picks up where a previous book in the series, Continuous Integration: Improving Software Quality and Reducing Risk, leaves off by venturing outside the developer’s realm and tying together other parts of the organization.

I’m expecting this book to become a well-worn, dog-eared resident of my “Software Bibles” bookshelf. (Can you still say “well-worn” and “dog-eared” in the Kindle age?)

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 →

Events, Simplifying Business, Simplifying Software

Fullerton Code Camp Next Weekend (1/29 & 1/30)

The schedule for the SoCal Code Camp next weekend (1/29 & 1/30) has been posted: http://www.socalcodecamp.com/schedule.aspx. My talk, Simplicity Appreciation 101, is during the first session on Saturday, so be sure to get there early. It starts at 8:45 in room H 123, which appears to be the designated room for the, “agile & project management track” (quotes are mine).  Building H is the Humanities/Social Sciences Hall, which is to the right as you walk in from the parking lot (lot F).

After me, Llewellyn and Woody give their Agile Introduction talk. Then, Woody keeps going with “10.5 Easy Code Excellence Techniques”, and that’s followed by various talks about project management survival. Note: the schedule is subject to changes up until Thursday (1/27).

This promises to be the best Code Camp yet. I’m looking forward to the fact that I get to give my speech early, so I can then kick back and enjoy the rest of the conference.