DZone
Agile Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Agile Zone > Getting Things Done

Getting Things Done

George Dinwiddie user avatar by
George Dinwiddie
·
May. 07, 14 · Agile Zone · Interview
Like (1)
Save
Tweet
5.80K Views

Join the DZone community and get the full member experience.

Join For Free

No, not the book and personal productivity method by David Allen, though somewhat related in intent. I’m talking about getting things done in software development.

Traditional phased software development processes tend to have a long delay between starting to work on something, and having something working that people can use. During this time, there may be a lot of work expended on partial products and artifacts to support the process, but little or nothing that could be used for its intended purpose.

Both timebox-oriented [e.g. Scrum] and flow-oriented [e.g. Kanban] methods try to emphasize getting things done so that they can be used earlier and provide value. Even if you decide not to use them earlier, at least they can be evaluated for suitability of the intended use, and progress toward a larger collection of functionality that will be deployed for use together can be more reliably tracked.

The strategies for getting things done vary.

The use of timeboxes provides impetus to slice the work into small slices so that multiple of these slices will fit within a fixed time period. This allows tracking progress within the timebox, as well as across timeboxes.

If all of the slices of work become usable at the very end of the timebox, then the visibility of progress within the timebox will be nil. The risk that they won’t be done goes up. We have to take it on faith that they are progressing. We may end up with all of them partly done. Or, better, we can limit the number of slices we work on at one time. If multiple people collaborate on one slice, we can get it done and usable before starting the next. Then our risk is reduced. We risk having some of the slices not done, but not all of them.

It’s possible, but not advisable, to break the work up such that accomplishing an explicit piece of it does not result in usable functionality. I’ve seen people create analysis, programming, and testing “user stories” that defeat the purpose of routinely getting functionality done.

When we work in a flow-based model, we explicitly limit the work in progress (WIP) at each station in the flow. This does not necessarily get working slices done and ready to use more quickly, but it does make bottlenecks and buffers more visible. Dealing effectively with the bottlenecks and buffers should help improve the lead time for the work item. If you find yourself blocked by an output buffer full to its WIP limit, or starved by an empty input buffer, you can collaborate with the bottleneck to alleviate the situation. You can also arrange the work flow so that there is not a correspondence between people and activities, so that collaboration is normal even without flow blockages.

It’s possible, but not advisable, to have enough work steps and large enough WIP limits that you don’t improve the cycle time of producing working slices. Often people select a measuring cadence to check that functionality is routinely getting to done and guard against long cycle times.

Whether you emphasize the cadence, and make WIP limits secondary, or emphasize the WIP limits, and make the cadence secondary, success at Getting Things Done usually depends on paying attention to both.

 

Published at DZone with permission of George Dinwiddie, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Simulators vs. Emulators: What's the Difference
  • Image Classification Using SingleStore DB, Keras, and Tensorflow
  • The Right Way to Hybridize Your Product Development Technique
  • Data Analysis Using Google Cloud Data Studio

Comments

Agile Partner Resources

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo