InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Discussion: "Decide as Late as Possible"

Posted by Deborah Hartmann Preuss on May 18, 2006

Sections
Process & Practices,
Architecture & Design
Topics
Leadership ,
Agile ,
Customers & Requirements
Tags
Planning ,
Management
Chapter 3 of Lean Software Development is titled "Decide as late as possible".  It's an important tenet for self-managing teams, encouraging them to avoid detailed discussions of items not currently under development or nearby on the planning horizon.  This practice keeps teams from dissipating their energy on discussions that will only be rehashed again later.  It keeps them focused on their current committments and facilitates what psychologist Mihaly Csikszentmihalyi calls "flow" - a state where work is focused and uninterrupted.
Flow is a mental state of operation in which the person is fully immersed in what he or she is doing, characterized by a feeling of energized focus, full involvement, and success in the process of the activity. --Wikipedia
But "decide at the last possible moment" does not suggest blindly plowing ahead without thought for upcoming features.  Some trainers modify this to "decide as late as responsibly possible", for clarity. It's a practice that requires a careful balancing act, which one learns over time.

This goes against the grain for many new Agille managers or team leads, who are used to mitigating risk through careful up-front planning.  Can this possibly be right?  A group of ScrumMasters recently discussed the topic, drawing on many collective years of experience.
  • This article is part of a featured topic series on Agile

Related Sponsor

In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!

Second Link by Geoffrey Wiseman Posted
Re: Second Link by Deborah Hartmann Posted
It depends by Johnny Blaze Posted
  1. Back to top

    Second Link

    by Geoffrey Wiseman

    Is that final link accurate? It's pointing to the 'lean software' book, whereas I expected it to point to a discussion.

    This is a critical point for me. I can't count the hours I've personally seen go into considering and reconsidering possible avenues before getting to the clarity that implementation-level thought brings. It does require an environment and process that supports this kind of decision making, but it's a valuable ideal if you can get to it.

  2. Back to top

    It depends

    by Johnny Blaze

    It really depends on what you're deciding. As long as you have a general idea of what's being done it's fine to hammer out the specifics later. However, what's more important is to have a good team manager. If you have someone you can keep people focused with drifiting off topic or debate problems that haven't even arisen yet then you're in good hands.

    I believe that it's always important to keep potential problems in the back of your mind at all times as you want to be able to point them out before they become irreparable. At the same time, however, you don't want to get bogged down debating the minutia.

  3. Back to top

    Re: Second Link

    by Deborah Hartmann

    Apologies! My mistake :-)
    I'll go fix that, thanks for pointing it out!
    deb

Educational Content

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.

Beauty Is in the Eye of the Beholder

Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.

Architecting Visa for Massive Scale and Continuous Innovation

John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.