Can PDCA Help Us Improve Our Test-First Development Efforts?

I was thinking about target conditions and the Plan-Do-Check-Act (PDCA) cycle earlier today when a code related issue that I was having popped into head and decided to meld with the current string of thoughts. The resulting thought was leading me toward wondering if a PDCA approach to test-first development (TDD/BDD/etc) would be of significant benefit.

The basic idea behind PDCA is to work in small steps toward a defined goal – not an specific implementation as a goal, but a process as a goal. We would need to find a goal that defines a process and find small steps that can provide feedback quickly, allowing us to adjust our approach to the goal as needed.

It seems that user stories and acceptance criteria are already a fit for this type of goal and the PDCA cycle. A user story and it’s acceptance criteria does not describe an implementation, but a process that the software should provide.

  • Plan: discuss the story and criteria detail
  • Do: implement a criteria or two
  • Check: get feedback from customer rep on the increment of functionality
  • Act: adjust as needed based on feedback, and start the PDCA cycle again

I’m also wondering if the test-first process itself could benefit from a PDCA cycle… this is my first attempt and fleshing out the idea, so it’s probably a bit off, still.

  • Plan: write a failing test to begin the implementation of an acceptance criteria (Red)
  • Do: make the test pass (Green)
  • Check: validate the full business needs technical standards against the implementation
  • Act: adjust the implementation as needed (Refactor)

Is there any value in this? is it just a bunch of uber-geekery babble or nonsense? Is it painfully obvious and doesn’t need to be restated as PDCA? I’m interested in honest feedback on the idea and whether or not you think there could be any value in taking a PDCA based approach to test-first development.


Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs SignalLeaf.com - the amazingly awesome podcast audio hosting service that everyone should be using, and WatchMeCode.net where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in Agile, Community, Kaizen, Lean Systems, Philosophy of Software, Standardized Work. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.lostechies.com/members/derick.bailey/default.aspx derick.bailey

    looks like i’ll be able to get some of my questions and thoughts answered / validated / expanded on at the LSSC conference:

    http://atlanta2010.leanssc.org/2010/01/liz-keogh-behaviour-driven-development-a-lean-toolkit/

  • Nolan Egly

    PDCA is one formulation for what is pretty much the universal approach to reaching goals or a desired state.

    1) Figure out what you want
    2) Figure out how to get there
    3) Start doing it
    4) Measure where you are in relation to where you want to be
    5) Adjust, or possiby start at step 1 again

    In my opinion TDD already lines up with this, and doesn’t need to wrapped up inside PDCA.

    1) Figure out what you want the code to look like
    2) Write a failing test to illustrate what you want
    3) Make it pass
    4) Run all tests and refactor, if necessary
    5) What’s the next test?

    This…
    >not an specific implementation as a goal, but a process as a
    >goal.

    and this…
    > A user story and it’s acceptance criteria does not describe
    >an implementation, but a process that the software should
    >provide.

    make me wonder if the real issue is being unhappy with your user stories. Perhaps they focus too much on the system mechanics and don’t provide the context for why the feature is being added?

    For example, “Implement drug order screen” is a very functionally specific story. A more user oriented story would simply be “Place a drug order”, and this could be one of many stories under a goal “Treat patient”.

  • http://www.lostechies.com/members/derick.bailey/default.aspx derick.bailey

    @nolan,

    you’re reading way too much into this, man… i was saying nothing about whether i like my team’s user stories or not. i picked user stories out because it was already a natural fit for PDCA, and wanted to use that as a lead in to PDCA of TDD, since they are related concepts.

    otherwise – yeah, i tend to agree that TDD already lines up with it. that’s why i’m posing the question of whether we can improve our TDD efforts by making it an explicit part of TDD rather than an assumed / unintentional part.

    any time we can make an implicit part of our process explicit, we open up that part of the process for improvement by allowing the identification of the principles in that process and why they exist / what their goals are for that process.

  • http://www.lostechies.com/members/derick.bailey/default.aspx derick.bailey

    oh, and the issue i alluded to was “code related” as stated – not process or story related. it was more of a “how do I TDD this part of our codebase?” issue…