• A User Story Primer
  White paper from Dean Leffingwell and Pete Behrens that synthesises current thinking on the use of user stories
  agile requirements userstories system:filetype:pdf system:media:document

• Non-functional Requirements as User Stories on Agile Projects
  Mike Cohn article suggesting that using the standard “As a <type of user>, I want <some goal>, so that <some reason>” user story template is a useful way to capture non-functional requirements and system constraints.
  Good discussion in the comments about whether these should sit in the backlog or be held as ongoing cross-cutting items.
  agile requirements non-functional_requirements
• Complex Requirements On an Agile Project
  Scott Ambler on strategies for handling the complexities of large real-world systems through agile:
  - look ahead in the backlog for complex items coming soon – pre-model
  - recognise where usable lumps of functionality rely on several work items at different points in the backlog
  - recognise where usable lumps of functionality rely on several work items in the backlogs of several teams
  agile requirements
• Beyond Functional Requirements On Agile Projects
  Scott Ambler on addressing non-functional requirements / constraints on agile projects:
  – identify in requirements envisioning and formulate technical strategy in architectural envisioning (Iteration 0)
  - explore JIT during contruction
  -validate with parallel independent investigative testing
  - train developers to understand the issues
  agile non-functional_requirements requirements

In the last two posts I started to explore how we could find the value stream in the “messy” stages of early programme shaping. In this post I will turn to the concept of “waste” in our context.

In the classic Toyota Production System, seven types of waste are identified:

1. over-production
2. idle time
3. transportation
4. inventory
5. motion
6. over-processing
7. defective units

Leaning heavily on the work the Poppendiecks did to translate these concepts to software engineering, I suggest the seven types of waste for programme shaping are:

Over-production

e.g. producing documents which do not add value, and which have to be kept under configuration management

Waiting

e.g. time the team are idle waiting for decisions

Hand-offs between groups

Always an opportunity for tacit information to be lost, and the reason many organisations perceive a need for excessive organisation

Too much work-in-progress

For example creating work products long before they are needed. This “gums up the works” with documents which have to be kept under configuration management, and becomes a source of distraction

Motion to find needed information

How often have you found the situation that a critical piece of information is held by one person, and that person is in another department, or another building?

Over-refining work products

e.g. Adding levels of detail or polish which do not add to the value of the document to support decisions or execution

Defects in the work produced

e.g. Plans which do not fit strategy, products which do not stakeholder expectations, or inconsistency between documents.

I’m sure that each reader will be able to add their own examples. In later posts I’ll look at possible solutions.

Next – how do we design the programme shaping process to amplify learning?

Technorati Tags: Agile, lean, MSP, Programme Management

In the previous post I started to explore how we could find the value stream in the “messy” stages of early programme shaping. Before I go on to explore the concept of “waste” in our context, I want to say a bit more about the value stream.

The key outcome of the programme shaping process is a clear understanding of the “Why”, “What”, “How”, “When” and “Who” of the programme. Different methodologies have different names for products that address these questions, and sometimes different names for the products at different stages of their development.

For example in MSP 2007, in the pre-programme and Initiating a Programme stages, most of the key questions are addressed (in outline form) in the Programme Mandate and Programme Brief, but during Programme Definition these expand into products such as the Blueprint, Benefits Maps, Benefits Realisation Plan, Project Dossier, Programme Plan, Programme Definition and Business Case, not to mention the planning and documentation around programme governance.

Regardless of the particular nomenclature, the process is one of iterative discovery and design. What we are doing through this time is architecting the “programme as management system” – the system goals, the programme “engine” and the feedback/control mechanisms.

So the challenge to find a Lean approach to programme shaping is the challenge to find a Lean approach to designing a management system.

In the next post I will explore the concept of “waste” in our context.

Technorati Tags: Agile, lean, MSP, Programme Management

• Building a Personal Intelligence Dashboard by Howard Rheingold
  Video introduction to building dashboards with Netvibes
  pkm dashboards howardrheingold

• Leading Agile: Velocity in the Enterprise, Part 7
  Last of a series of 7 articles about scaling agile using lean approaches
  agile lean
• Conveying Agile Processes Concisely to Clients

  agile projectcharter

• Faded London
  "London is a city constantly re-inventing itself, but every now and then there's a window on to the past"
  london

• Internet Time Wiki / learnscapes
  Jay Cross – "Learning is a process, not an event. A Learnscape is where that process plays out"
  learnscape learning KM pkm
• Learnstreaming and PKM
  Harold Jarche links PKM, Dennis Callahan's learnstreaming, and Jay Cross's learnscapes
  learnstreaming KM learning pkm
• Learnstreaming
  Dennis Callahan's take on learning-based lifestreams
  learnstreaming KM learning lifestreaming

Here I am using “programme” in the widest sense – to borrow a definition from MSP2007 “a temporary, flexible, organisation created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation’s strategic objectives”.

The core of all lean approaches is to identify the value stream – what activities take place to generate value from the process. For example, in software development, what sequence of activities has to happen to create production applications which deliver benefit to the customer? So how do we map that to the early, often “messy” stages of a programme?

Standing back from the detail of a programme, we can see that it is (like any business activity) an investment of time and money to move the organisation closer to its goals. I think you can structure the problem as a series of steps from the strategic to the specific:

1. What challenges does the organisation face, and what objectives will it adopt?
2. What areas of change would make good programmes?
3. What would a specific programme address?
4. What specific benefits will the programme deliver?
5. What does the programme have to do to deliver the benefits?
6. (and then down into the projects and business change activities)

Many commentators would suggest that (1) is the province of strategy development and that (2) is the realm of Portfolio Management, but for the moment I’m going to elide them together – I’m trying to find the flow of value rather than establish discipline boundaries. Having said that, most of us who get involved in programmes can usually only monitor (1), so I think there is a fairly natural (albeit fuzzy) line between (1) and (2).

In terms of the programme shaping flow, we can start to see a series of intermediate products at increasing levels of detail, requiring increasing investments of time, money and resources, and which eventually (should) generate benefits that flow back up the tree. Before we can identify the value chain associated with all this activity, we need to determine how the organisation will assess value. It seems to me that the clue is in the definition of what a programme delivers – “outcomes and benefits” – and the key to evaluating those is benefits realisation management. It won’t surprise anyone when I say that in my opinion benefits mapping and related analysis is at the heart of an effective portfolio and programme process.

So the second clue about finding the value stream is to focus on benefits at each stage.

The third element is to decide how we recognise “good” quality at each stage – i.e. something that delivers value to the stake-holder. Sadly, we have no equivalent of the software world’s automated unit, integration and user tests for programme artifacts, so we need to turn instead to guidance such as MSP 2007 Appendix D “Programme Health Checks”, OGC Gateway reviews, or any other audit and evaluation approach used within an organisation. To optimise our value stream we have to optimise the flow of our work products through those constraints.

In the next article I’ll start to explore the concept of waste in our context.

Technorati Tags: Agile, lean, MSP, Programme Management

• Failure Demand
  "Failure demand describes the demand on the resources of an organisation caused by its own failures. "
  lean agile quality process

• Using Subversion with WordPress – Part 2: Maintaining Vendor Branches and Upgrading WP Core Files » :: TechBlog ::

  none

• Using Subversion with WordPress – Part 1: Creating Vendor Branches and Integrating your Existing Code » :: TechBlog ::

  none