What you do next matters.

  • Bad logic. Some common fallacies

    I was talking about assessing documents (and statements) to see whether they are “logical”. Critics of “logical communication” will quite rightly make the point that a document can be logical, but boring, irrelevant and completely un-compelling. This is true and I should get to talking about it soon. But before I do I wanted to…

  • Assessing the logic of a whole document

    In my last article (“Is that logical?”) I discussed a way to test the logic of a statement. But a document filled with logical statements can still be gobbledegook if the statements are not linked together logically. So how can we assess the overall logic of a document?

  • Is that logical?

    (Editors note – this is not the article I promised to write on “Arenas of Change” – I got distracted by the wondrous world of logic). I promised a class that I would write something on “The Arenas of Change”, which is a theory about how teams interpret reality.

  • Unusual risk analysis techniques

    I think risk management is really cool … and certainly more fun than the alternative. Unfortunately many people find the traditional approaches to analysing risks dry and un-innovative; which is a problem because identification and analysis of risk is actually a creative process. So here are a couple of “unusual” approaches that might work for…

  • The Hard Choices game – teaching architecture to agile teams

    I have recently been talking about elaborating stories in agile projects and the topic of architecture came up. As as result Philippe Kruchten sent me a link to the “Hard Choices” game – a game that can be run in workshops and training courses to demonstrate the difficult tradeoffs involved in architecture on projects.  http://www.sei.cmu.edu/architecture/tools/hardchoices/

  • Elaborating user stories: what about architecture?

    Some people worry that in our rush to become more agile we might be leaving good architecture behind. So I often reassure with the following statement: Don’t worry – There is no doubt that the system’s architecture will emerge from what we are doing. The only question is whether it will be the architecture we…

  • Elaborating user stories by using comparison tables

    Comparison tables involve listing stories and then comparing the components or factors relevant to each story.  Generally speaking a comparison table is created as follow: Stories are listed as either column headings or row headings; and Story components or characteristics are listed for each story.

  • Elaborating user stories by using abstract to concrete approaches

    Abstract to concrete is a term I am going to use to describe the idea of elaborating stories by: Using a structured format to interrogate the story; “Abstracting” the context and meaning behind the story rather than just listing acceptance tests or task; and Making the abstract conversation more concrete by discussing what needs to…

  • Elaborating user stories by using technical stories

    Rather than breaking the story into tasks or acceptance tests, some teams simply break stories into multiple, smaller stories until they are small enough to build from.

  • Elaborating user stories by breaking them into tasks

    In some teams, the iteration or sprint begins with the team discussing each story and breaking it down into the specific tasks that each team member will need to perform in order to complete the story. The team then track tasks on their story wall rather than complete stories.