Bookmarks I’ve shared on 2010-06-13:
- Kanban for Service Desks
- Scum v Kanban
Different methods, different change drivers
scrum kanban agile change lean
I am Synesthesia
Synesthesia
Notes on stuff
Tagged Posts: lean
Links for 2010-06-13
Links for 2010-05-01
Bookmarks I’ve shared on 2010-05-01:
- Agile Architectural Epic Kanban System: Part 3 – State Machine View
epic kanban agile architecture ea productowner product_development portfolio
- Estimating Features
features estimating agile product_development product productowner portfolio
- Prioritizing Features
agile productowner product_development portfolio backlog ROI cost-of-delay
- Awasu API
- Virtual Team Member Dolly
- You’re Just Going to Fail, So Don’t Bother – 6 Hard Truths about Scrum
- Testing Small Stories
- New to agile? Keep it very simple
- Effectiveness of a real product stream
- Inserting Awasu Data Into Microsoft Word
- Patterns and Practices of Lean Software Development
Excellent post by Corey Ladas that pulls together a large range of concepts relating to the workflow of software development
patterns software lean workflow - CONWIP systems
Constant Work In Progress – simplest form of Kanban
systems lean conwip kanban workflow - louisgray.com: Google Checkout Web Element Simplifies E-Commerce
I am Synesthesia
Links for 2010-03-16
Bookmarks I’ve shared on 2010-03-16:
- Transformation using Lean Six Sigma measures for service processes
lean six-sigma process system:filetype:pdf system:media:document
- 5 ways to add value to information – Trends in the Living Networks
I am Synesthesia
Links for 2010-03-15
Bookmarks I’ve shared on 2010-03-15:
- Ten Suggested Practices for Applying Agile/Lean Software Management Principles to Other Knowledge Work « Scaling Software Agility
- Between Agile and ITIL « The Agile Executive
Improving IT operations to keep up with agile sfotware delivery
agile itil - Efficiency – A Must Have Agile Metric As Important As Velocity
- 7 Mistakes in Dashboard Implementations
I am Synesthesia
Links for for 2010-02-11 through 2010-02-12
Bookmarks I’ve shared for 2010-02-11 to 2010-02-12:
- The Process of Database Refactoring: Strategies for Improving Database Quality
- The Enterprise Architecture Discipline: Scaling Agile Software Development
- Encapsulating Database Access: An Agile "Best" Practice
- Agile/Lean Data Governance Best Practices
- The Skillset of an Agile DBA
- Agile Master Data Management (MDM)
- Work Design Issues for HR in the Enterprise 2.0 Context
- Top 3 Business Benefits of (internal) Enterprise 2.0
I am Synesthesia
Links for 2010-02-01
Bookmarks I’ve shared on 2010-02-01:
- VersionOne Community:Guide – Kanban
Configuring VersionOne for Kanban teams
kanban versionone agile lean
I am Synesthesia
Links for 2009-12-15
Bookmarks I’ve shared on 2009-12-15:
- BBC News – Information goes out to play
Article by David McCandless on Information Visualisation
information_visualisation via:StrangelyAttractive - Portals and KM: Implementing Enterprise 2.0 at Océ
Index post by Bill Ives to a set of posts he has made about interviews with key individuals at Oce about their internal information architecture and use of Enterprise 2.0
via:billives Oce informationarchitecture enterprise2.0 - An Agile Illusion: How That Nice Backlog is Actually Decreasing Your Team’s Agility
Why Littles Law says keep the backlog small.
lean LittlesLaw agile
I am Synesthesia
Lean Programme Shaping – Models
How can visual models improve the flow of work during programme shaping?
This is the sixth post in a series about applying the lessons of lean (especially lean software development) to the shaping phase of programme management.
In previous posts I have talked about amplifying learning, the application of the ideas of flow and a value stream to programme shaping, and touched on sources of “waste” in the typical programme environment.
In this post I want to talk a bit about (visual) models.
I’ve found two sorts of model useful when pulling together a programme – models of the shaping process itself, and models of the programme design.
Modelling the Programme Shaping Process
In previous posts I’ve talked about looking for flow in the programme shaping process. Every organisation, and to some extent every programme, will have a different flow for the shaping process.
For most this will involve some number of iterations of capturing and designing information, creating programme artifacts, and seeking approval from various stakeholders. I have talked about keeping work-in-progress to a minimum, and the classic tool for managing that is a kanban board.
Modelling the Programme Design
The other area where models are vital is in describing how the programme will work and what it will deliver – in other words, the design of the programme itself. Programme documentation has always been a way of sharing a model of how things will work and what will be achieved, but I think there are lessons we can learn from other disciplines to make the documentation more useful.
Many traditional programme documents are heavy on words and light on diagrams. Words are vital for providing detail, but they are not the best choice for communicating the relationships between concepts, nor for illustrating causal chains (for example from enabling projects to capabilities to benefits to outcomes).
I’m suggesting that as programme managers we can usefully make more use of visual models to augment our programme documentation, and to model the relationships between different parts of the documentation.
There are specialist tools (e.g. ChangeDirector) which make extensive use of graphical techniques, however not every organisation will have access to these. I have had some success in using general purpose UML modelling tools to support programme shaping work, and it’s an area I am actively exploring further. One background project that I hope to blog more on later is the creation of a UML Profile for Programme Management
I’d like to hear from other programme managers about their experience with visual modelling.
Picture credit: David Larabee
Links for 2009-12-07
Bookmarks I’ve shared on 2009-12-07:
- OpenProj
OpenProj is a free, open source project management solution. Opens MS Project or Primavera files
project_management_tools opensource - Eight Wastes of Lean in a Services Context
Debashis Sarkar translates "Muda" into a services context
lean muda - Appirio: Cloud Computing Ecosystem Map
Clickable map, with stack layers plotted against public/hosted/private
via @rickmans
cloud-computing via:rickmans appirio - Horizontally Sequenced Display Order for WordPress Posts in Two Columns
- Multiple Loops and Multiple Columns with WordPress
- ‘Communities’ and ‘Networks’: A Conceptual and Linguistic 2.0 Mess
Useful distinction between the two terms, often used interchangeably especially in marketing material!
enterprise2.0
I am Synesthesia
Lean Programme Shaping – Amplifying Learning
This is the fifth post in a series of thought experiments on applying Lean/Agile principles to the early shaping stages of a programme.
In previous posts I have talked about the application of the ideas of flow and a value stream to programme shaping, and touched on sources of “waste” in the typical programme environment.
Again borrowing heavily from the Poppendiecks for my conceptual structure, I want to think about learning in our context, and how we can make it work better.
Programme Shaping as a Learning Process
What are we learning about during programme shaping? A few thoughts:
- Stakeholder expectations and perceptions;
- The shape of the perceived problem, the nature of the programme objectives, the expected benefits and how they relate to each other;
- The enablers and business changes that will support the benefits;
- Increasing amounts of detail and quantification around benefits, costs, risks;
- Alternative solution approaches and trade-offs;
- The quality criteria that will be imposed at decision gates, and/or that we may determine for ourselves;
As we learn more about these areas we progressively build and refine our product – the design of the programme as a system.
This sort of learning process can be likened to the Deming Plan-Do-Check-Act cycle (PDCA).
So our question becomes “how do we iterate the learning cycle faster during programme shaping?”. Drawing on the agile software approach, I suggest the following themes:
Iterating Faster
If we are going to learn faster about what shape of programme is most likely to be acceptable and successful, we need to increase the speed with which we plan, develop and review our growing programme design. Translating good practice from the agile and lean engineering movements we get the following points:
- Break the programme design work down into small deliverables;
- Clarify the stakeholder requirements for each deliverable – “what will good look like?”;
- Build quality in explicitly;
- Actively constrain the number of deliverables started at any one time;
- Frequent feedback from stakeholders. Look at physical proximity (e.g. where the team sits), access to diaries, collaboration technology.
Build Shared Understanding
A central challenge to effective consensus building comes from the intangible nature of the concepts under discussion and the relationships between those concepts. Approaches that offer visual modelling to support rapid understanding of conceptual relationships, supported by the right blend of numerical and textual “backing information” to support deeper understanding and analysis are helpful here.
In my experience a visual meta-model of the programme shaping artifacts is also a useful tool to clarify the dependencies between different outputs.
Simplify Programme Documentation
Published methodologies such as MSP are often (or are often interpreted as) document heavy. The work to synchronise work products expands exponentially with the number of separate but inter-dependent documents. Following the lead of others (sorry no references to hand) I find it helpful to think of different programme documents as merely different views into the programme model.
In the ideal case this will be literally true, with the model held in a central computerised repository that can create the necessary views. However many programmes will not have that luxury, and are faced with maintaining a set of separate documents. In that situation I have found the following ideas useful:
- Actively simplify the document set, don’t just produce every document that is listed in your favourite (or mandated) methodology). For each document ask yourself what question that document answers, or what decision it supports. If you can’t answer, then you may well not need it. Adopting this approach successfully may require active engagement with, and influencing of, the”quality police” – PMO, Internal Audit etc.
- Model the documentation set to clarify dependencies between documents. The systems design principles of high coherence within a document and low coupling between documents are a good guide. If all you have is Visio, then that’s better than nothing, but I’ve found that a UML modelling tool can be very useful in this regard.
- If possible, automate production of documents from a common source. For example, with the right modelling tool it may be possible to auto-generate some documents, moving a step towards the nirvana of an all-encompassing data repository.
- Use a version control system to track document history and tag consistent sets of documents. My personal preference is Subversion, as it is free, available on several platforms, well-known, and supported by a number of tools.
Synchronise Work Frequently
In the initial stages of programme shaping there may only be one or two people involved, so keeping the work in sync is often “just” the problem of keeping the document set consistent. Once more than a couple of people are working on the idea then it becomes increasingly possible for the work to diverge, increasing the risk of re-work being needed. Until someone invents automated integration tests for programme documents 
we are faced with using the design of our shaping process to keep the work on track.
- Faster iterations, changing relatively small parts of the concept at each pass, are the first step;
- Keeping documentation as simple as possible, with well-designed and understood inter-dependencies between documents;
- Taking a set-based approach to solution design. For example if you had a team working on high-level technology decisions for the enabling projects working alongside another team looking at organisational decisions, encourage each to maintain a set of options in their design. As the programme shape firms up, each team can narrow their options.
I’d be interested in dialogue to sharpen these ideas, do please comment below!
(Image credit: Karn G. Bulsuk)
Lean Programme Shaping – Exploring Waste
This is the fourth post in a series of thought experiments on applying Lean/Agile principles to the early shaping stages of a programme.
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:
- over-production
- idle time
- transportation
- inventory
- motion
- over-processing
- 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?
Lean Programme Shaping – More on Flow
This is the third post in a series of thought experiments on applying Lean/Agile principles to the early shaping stages of a programme.
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.
Lean Programme Shaping – Finding the Value Stream
This is the second post in a series of thought experiments on applying Lean/Agile principles to the early shaping stages of a programme.
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:
- What challenges does the organisation face, and what objectives will it adopt?
- What areas of change would make good programmes?
- What would a specific programme address?
- What specific benefits will the programme deliver?
- What does the programme have to do to deliver the benefits?
- (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.
Agile Programme Shaping – First Thoughts
This is the first of a number of exploratory posts to express and refine my thinking on the subject. I want to pull together a selection of experiences with programme shaping by looking at them through the filter of lean/agile theory.
Traditionally programme management, especially in public sector, is heavily influenced by stage gates. Having said that, the authors of more recent methodologies (e.g. MSP 2007) recognise the need for iteration and conceived a “transformational flow” of work that delivers benefits over time.
The area that I am particularly interested in exploring is the shaping stage of a programme – the early part of the process when the stakeholders come together to agree the benefits to be achieved, the shape of the organisation after the change, the set of initiatives that will be needed, and the business case.
I see strong parallels between programme shaping and the world of software development – both are dealing with the development of concepts, and the progressive discovery of knowledge about the area of concern. So I freely acknowledge that my thinking is heavily influenced by pioneers in the field of software development such as the Poppendiecks and David J. Anderson. Of course the challenge in drawing lessons from a different field is not just to find the translation, but to recognise where the concepts differ, so I would expect that my views will move around as I develop the thoughts.
The areas that I think need to be explored are:
- Understanding the value chain of programmes, especially the programme shaping stage
- Identifying the flow and where the “pull” comes from
- Applying lean principles
- Exploring what it looks like in practice – people, techniques and tools
Links roundup for 2008-07-15
Shared bookmarks for del.icio.us user Synesthesia on 2008-07-15:
Links roundup for 2008-03-07
Shared bookmarks for del.icio.us user Synesthesia on 2008-03-07:
- The Modernisation Agenda: Public Services in a Dark Age
Applying Lean thinking to service delivery…
lean services
Links roundup for 2008-02-25
Shared bookmarks for del.icio.us user Synesthesia on 2008-02-25:
- If estimation is harmful⦠then, whatâs not?
- Estimation considered harmful « epistemologic
discussing
lean agile - Lean software development: An iteration-less agile process
- A Kanban System for Sustaining Engineering on Software Systems
David J Anderson and Rick Garber – experience at Corbis<br>
agile kanban - What engineering has in common with manufacturing and why it matters – AC
Alistair Cockburn on the rationale for aplpying ideas and approaches from Lean Production to (software )engineering.
no_tag - Lean-based Metrics for Agile CM Environments
Links roundup for 2008-02-22
Shared bookmarks for del.icio.us user Synesthesia on 2008-02-22:
Links roundup for 2008-02-11
Shared bookmarks for del.icio.us user Synesthesia on 2008-02-11:
- ExRx (Exercise Prescription) on the Net
- NetMotion Wireless – Mobility XE
Mobile VPN for Wireless Security, Remote Access, Continuous Connectivity and Application Access
vpn remote-access wireless products - Planning Poker – Online Tool
- Hoshin Kanri–a Suprise
Joe Ely links to useful slides on the Lean Strategy approach
lean Hoshin-Kanri - Division of Labor in Lean Software Development Workflows
Corey Ladas prods the assumption about all members of a team needing to be generalists…
agile lean development
Links Roundup for 2007-09-06
Shared bookmarks for del.icio.us user Synesthesia on 2007-09-06
- The Importance of “So What?” in A3 Kaizen:
Great summary post on the “A3 Kaizen” approach, and the importance of drilling down to root causes.
Keywords: lean, kaizen - Personal Unit Tests:
Keywords: personalproductivity, personaldevelopment
- Visualizing Agile Projects using Kanban Boards:
Links Roundup for 2007-03-28
Shared bookmarks for del.icio.us user Synesthesia on 2007-03-28
- Kanban in Action:
David J Anderson describes the application of Kanban “pull” techniques to scheduling work through a software sustaining team.
Keywords: Agile, Software, Agile/Methods, KanBan, Lean - Kayuda:
Kayuda is a web-based visual wiki, a mind-mapping tool, and a non-linear writing tool that allows you to track ideas and the relationships between them.
Keywords: Wiki, Mindmapping, Collaboration - Comparison of web-based mind mapping applications:
Chuck Frey surveys the field for web-based mind-mapping. Conclusion: Mindomo top on features, Mindmeister top on input/output and other workflow aspects, Bubbl.us and Thinkature lagging badly…
Keywords: Mindmapping
Follow Me
Subscribe by Email
Conversations Elsewhere
Meta
Copyright
- Unless otherwise expressly stated, all original material of whatever nature created by Julian Elve and included in this weblog and any related pages is licensed under a Creative Commons License.
-
