Synesthesia

Agile Across the Enterprise: Prioritizing Value in Support and Training
Guest post on The Agile Executive by Anne Gentle about applying agile methods to non-coding tasks, in this case the writing of documentation.
agile AnneGentle
XBRL
XBRL (eXtensible Business Reporting Language) is a data standard for electronic interchane of business data. Soon to be adopted by HMRC as the mandatory format for submission of UK Company tax returns.
XBRL UK is UK arm of XBRL International, consortium driving take-up of XBRL
xbrl companies HMRC

I am Synesthesia

Add me to your network

Lean Programme Shaping – Models

Filed under:

Programme Management

Tags: Agile, lean, leanprogrammeshaping, linkedin, Methodology, MSP, Programme Management, UML

14-12-2009

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

Kanban Board

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

UML Example - Mapping Projects to Capabilities

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

(1)

Lean Programme Shaping – Amplifying Learning

Filed under:

Programme Management

Tags: Agile, lean, leanprogrammeshaping, MSP, Programme Management

19-11-2009

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).

PDCA Cycle

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)

(2)

Lean Programme Shaping – Exploring Waste

Filed under:

Programme Management

Tags: Agile, lean, MSP, Programme Management

05-11-2009

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

Filed under:

Programme Management

Tags: Agile, lean, MSP, Programme Management

05-11-2009

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.

(2)

Lean Programme Shaping – Finding the Value Stream

Filed under:

Programme Management

Tags: Agile, lean, MSP, Programme Management

03-11-2009

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.

(3)

Agile Programme Shaping – First Thoughts

Filed under:

Programme Management

Tags: Agile, lean, MSP, Programme Management

25-10-2009

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

(4)

Links roundup for 2008-07-15

Filed under:

LinkLog

Tags: Agile, Kanban, lean, Scrum

15-07-2008

Shared bookmarks for del.icio.us user Synesthesia on 2008-07-15:

Scrum-ban
merging lean/kanban methods into a Scrum environment
scrum agile lean

How simple is “simple enough”?

Filed under:

Enterprise Architecture

Tags: Agile, EnterpriseArchitecture, TOGAF

11-07-2008

Or “Simplifying an ‘architecture framework’ for agile strategy”

How often have you faced the situation where you need to get something done, and you know there’s all sorts of advice and guidance available, but you only have a limited time to implement something?

My current challenge is to relatively rapidly put together some strategic roadmaps for the systems in a business area.

In the past I’ve spent a very small amount of time studying TOGAF, just enough to appreciate the coverage of the model and to feel overwhelmed by the amount of material and unfamiliar language.

My current feeling is that it could serve as a guide for the piece of work I need to do, but I need to find a lightweight way through it.

Apologies in advance to all the experts out there, but I think the gist of what it says is:

Agree the objectives of the piece of work
Review the business environment and understand the drivers for change
Sketch out some possible changes to the business environment (e.g. process changes)
Review the impact on the systems and data, and sketch out some possible changes.
Review the impact on the technology, and sketch out some possible changes.
Decide on some interventions on all three levels that will address the drivers for change
Do some of them
Review and repeat as necessary

Seems logical, I’ll see how it goes – and if this is something you specialise in let me know if I’m missing something!

Links roundup for 2008-02-26

Filed under:

LinkLog

Tags: , Agile, ea, Enterprise_Architecture, Linux, Writing

27-02-2008

Shared bookmarks for del.icio.us user Synesthesia on 2008-02-26:

How Writing Flow Can Happen For You Too ~ 9 Ways
writing
Introducing the “Double Iron Triangle” of Enterprise Architecture
enterprise_architecture ea
andLinux.org
Run Linux natively inside Windows
linux
XPM Project Report #1
Experiences apply ing an XP-like model to a (building) architecture project.
agile

Links roundup for 2008-02-25

Filed under:

LinkLog

Tags: , Agile, agile/metrics, Kanban, lean, no_tag

26-02-2008

Shared bookmarks for del.icio.us user Synesthesia on 2008-02-25:

If estimation is harmfulâ�¦ then, whatâ��s not?
lean agile
Estimation considered harmful Â« epistemologic
discussing
lean agile
Lean software development: An iteration-less agile process
lean agile
A Kanban System for Sustaining Engineering on Software Systems
David J Anderson and Rick Garber – experience at Corbis 
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
agile/metrics agile

Links roundup for 2008-02-22

Filed under:

LinkLog

Tags: , Agile, CFD, lean, PDF, RegEx, TOC

23-02-2008

Shared bookmarks for del.icio.us user Synesthesia on 2008-02-22:

Reflections on Agile Approaches for Delivering Business Value

Filed under:

Conferences

Tags: Agile, AgileApproachesForDeliveringBusinessValue, Conferences

13-02-2008

I’ve spent the last two days Agile Approaches for Delivering Business Value, and feel I’ve learnt a lot. Here are my initial reflections on the conference.

Firstly, there are a lot of very smart people thinking about these issues – it was thoroughly enjoyable to have to take on so many ideas in such a period of time.

The second thing that stood out was that most of the people at the conference were involved with the development / supplier side of the IT equation. Hardly surprising, but it does mean that some of what was covered was of particular relevance for the “supply side”. However pretty much every topic had things which can be of use from the customer perspective.

Thirdly, a number of people are applying thought to the problems in getting the benefits of Agile in multi-party environments, and how to support the process with appropriate contracts.

It’s in everyone’s interest that there should be consensus on how to reliably deliver software projects, and how to assess the risk of such delivery (and I don’t mean CMMI) – if we can get to that, then there is more opportunity to deploy financial engineering (e.g. Graham Oake’s idea of completion bonds) to facilitate business improvements through software.

There are clear lessons about the importance of getting a common view of risk between project participants.

DSDM/Atern doesn’t seem to have much visibility yet outside the IT world, but looks worthy of further investigation.

Last but not least, Agile is not just for software (nice to see other people have spotted this to!).

Topics for Further Research and/or reflection

Agile Contracts, and the work of Cem Kaner

DSDM/Atern

How could we use a Acceptance-Test-Driven approach from the customer side?

I need to reflect on, document and develop the work we have been doing on using agile approaches for such things as business analysis / programme shaping etc.

Finally, thanks for thought-provoking conversations to Rachel Davies, Graham Oakes and Antony Marcano.

Acceptance Test Driven Development

Filed under:

Conferences

Tags: Agile, AgileApproachesForDeliveringBusinessValue, Conferences

13-02-2008

I’m blogging the conference Agile Approaches for Delivering Business Value

Acceptance Test Driven Development

David Peterson

Summary

What happens if you put acceptance tests in the
driving seat?
Fresh ideas about the agile development process
Practical techniques to improve your project’s agility
Emphasis on process and practice (non-technical)

Notes

Whilst working at EasyNet, David modified their normal XP iteration cycle to insert a phase where, for each story, acceptance test criteria were agreed and documented. Alongside this their testing harnesses were adapted to provide autoamted testing of acceptance tests wherever possible.

A key enabler was to separate out test case definition (which depends on the business requirement) from test scripting (which is dependent on, and coupled with, the system under test).

The technique adopted was to build test fixtures which interfaced between the (HTML) test cases and the system under test. This way the test cases can stay unchanged whilst the system changes. If the system changes in a way that breaks the test fixture that shows up as broken acceptance tests.

The tool is released as Concordion. Good write up on that site.

Update: See this post from Keith Braithwaite

DSDM Atern: The next step in agile!

Filed under:

Conferences

Tags: Agile, AgileApproachesForDeliveringBusinessValue, Conferences

13-02-2008

I’m blogging the conference Agile Approaches for Delivering Business Value

DSDM Atern: The next step in agile!

Keith Richards, Keith Richards Consulting, on behalf of DSDM Consortium

Summary

DSDM Atern (login required) “The Agile Project Delivery Framework”

Latest iteration of DSDM – much more aimed at being a generic project management method rather than IT-specific.

Often used as a wrapper around Scrum and XP to scale them.

Philosophy / Principles / Process / People / Products / Practices

Presentation was a run through material that can be found on the website…

When XP Met Outsourcing

Filed under:

Conferences

Tags: Agile, AgileApproachesForDeliveringBusinessValue, Conferences

13-02-2008

I’m blogging the conference Agile Approaches for Delivering Business Value

When XP Met Outsourcing

Angela Martin, Martin IT Consulting Ltd

Outsourcing is common for software development, and is the context for many projects using agile development processes. This paper presents two case studies concentrating on the customer role in projects using outsourcing and extreme programming (XP).

The studies follow an interpretive approach based on in-depth interviews, and suggest some tensions between some contractual arrangements in outsourcing, and the XP process.

In particular, one suggests XP worked well in the context of their particular outsourcing arrangements, and the other study suggests difficulty in aligning XP with a different set of outsourcing arrangements.

Notes

(to be) Published as a paper on MartinIT website

Method – two interpretative in-depth case studies. Multiple perspectives via semi-structured interviews. Validated data and interpretation with each interviewee.

Two Case studies

Case Study 1 (T&M)

KiwiCorp (customer), DevCorp (outsourcing/software house), BureauCorp(facilities management and infrastructure). 15 months, 11 people. Seen as a success.

Customer saw benefit from the XP process. DevCorp project manager recognised that on fixed price would have had to be harder on the client.

Lots of vendor issues because of differences between DevCorp and BureauCorp.

Case study 2

Project Pinta. Custom-build, fixed price. FalconCorp (US developer), RetailCorp(UK retailer), ManageCorp (big consulting organisation who hired FalconCorp to do the job). FalconCorp to take the cusotm build and sell as a project.

Everyone thought it was doomed… 6 month deadline. In 2 weeks ramped up to 60 people over four XP labs. Weekly iterations. So within a month knew it wouldn’t fly.

FalconCorp felt that as fixed price very little room to move, so moved more to waterfall… Stopped asking questions, to make sure they could just get signoff and the cheque. Kicked the customer rep (ManageCorp) out of the lab – seen as being a “spy”.

Is this because of the process, the contract, or Winner’s Curse? (over-bid)

Got to 6 month demo – and custoemr accepted it! (the demo didn’t show the broken bits…).

FalconCorp went into bug-fix mode and laid off 2/3 the staff. Then new management came in and found that actually the product was full of holes. Treated it as a throwaway prototype, and went into a fixed-price waterfal project to re-engineer as a saleable product.

Questions (and for Duncan too)

Q: How do you sell Agile to your client?

A: Don’t – until you are sure you can deliver in an agile way

Q: What are the client drivers for fixed price?

A: Need someone to blame “not the client’s problem”

Q: Which has pects of Agile do you keep/drop when customer insists on fixed price:

A: All of them (internally) as a delivery engine.

Q: Why does the industry encourage under-bidding?

A: (Keith) We have allowed purchasers of IT to think it is a fungible commodity so competition is on price. Look for shared-risk, shared-reward…

A Square Peg in a Round Hole: Agile and fixed-price contracts

Filed under:

Conferences

Tags: Agile, AgileBusinessValueConference, Conferences

13-02-2008

I’m blogging the conference Agile Approaches for Delivering Business Value

A Square Peg in a Round Hole: Agile and fixed-price contracts

Duncan Pierce, Amarinda Consulting Ltd

Summary

Square peg: Agile processes flex scope freely and have open-ended timescales.
Round hole: Fixed-price contracts usually come with a deadline and strict limits on how much scope change can occur – often none at all.

Luckily you don’t have to hit agile particularly hard to make it fit, while being internally agile gives the fixed-price supplier some interesting options.

In this presentation we’ll explore the value of those options and what has to change for agile to work in a fixed-price world.

(more…)

Can IT Projects be Insured?

Filed under:

Conferences

Tags: Agile, AgileApproachesForDeliveringBusinessValue, Conferences

13-02-2008

I’m blogging the conference Agile Approaches for Delivering Business Value

Can IT Projects be Insured?

Graham Oakes, Graham Oakes Ltd

Summary

In the movie industry, the people financing new productions can buy “Completion Bonds” – effectively insurance policies that repay their investment if the film isn’t completed on time and in line with the original proposal. Such bonds cost perhaps 2-6% of the total production budget. Could we do the same for IT projects?

(more…)

Fit for the Future: The future of Agile Acceptance Test Tools

Filed under:

Conferences

Tags: Agile, AgileApproachesForDeliveringBusinessValue, Conferences

13-02-2008

I’m blogging the conference Agile Approaches for Delivering Business Value

Fit for the Future: The future of Agile Acceptance Test Tools

Antony Marcano, testingReflections.com

The role of acceptance test tools in agile teams
Where have they come from; what are they; what is their future?
Report on the vision created during the Agile Alliance Functional Test Tools Visioning Workshop, which included Ward Cunningham, Brian Marick, Jim Shore, Elisabeth Hendrickson and the presenter, Antony Marcano.
Delegates will be encouraged to discuss these ideas and suggest some of their own.

(more…)

Examples, Exemplars, Requirements, Tests

Filed under:

Conferences

Tags: Agile, AgileApproachesForDeliveringBusinessValue, Conferences

13-02-2008

I’m blogging the conference Agile Approaches for Delivering Business Value

Examples, Exemplars, Requirements, Tests

Keith Braithwaite, Zuhlke (but speaking on behalf of SPA)

Summary

Automated Functional Tests ensure quality and drive process change
Test failures are more often due to misunderstood requirements than sloppy coding
Treating tests as executable specifications can help with both
Tests based on examples lead to an exploration of the problem space that discovers requirements and provides a foundation for trapping defects.

(more…)

Case Study: Using Agile: the QA perspective

Filed under:

Conferences

Tags: Agile, AgileApproachesForDeliveringBusinessValue, Conferences

12-02-2008

I’m blogging the conference Agile Approaches for Delivering Business Value

Using Agile: the QA perspective

Chris Ambler – QA Director Electronic Arts

Not a developer, never have been, never will be.

Not a techie! But have worked in testing (of various sorts) for 28 years.

Focus is product, and quality.

What does quality really mean? How does it affect the business? How can we measure it?

(more…)

Keynote: Scaling Scrum

Filed under:

Conferences

Tags: Agile, AgileApproachesForDeliveringBusinessValue, Conferences

12-02-2008

I’m blogging the conference Agile Approaches for Delivering Business Value

Scaling Scrum

Rachel Davies, Agile Experience Ltd.

Summary

Scrum is the simplest possible agile method so it’s easy to get started with a small team of software developers. What happens when you try to apply Scrum to large projects? This talk shares experiences of working with large projects with multiple scrum teams and distributed scrum teams. Come to this talk to explore how to scale Scrum without losing the essence.

(more…)

Leading Agile Teams

Filed under:

Conferences

Tags: Agile, AgileApproachesForDeliveringBusinessValue, Conferences

12-02-2008

I’m blogging the conference Agile Approaches for Delivering Business Value

Leading Agile Teams

Dot Tudor, TCC

Summary

One school of thought is that good leaders make a big difference to the successful outcome of any initiative. On the other hand, some agilists want to eliminate leaders and go with situational leadership and self-organising teams. There is also a large contingent in the agile community with the view that the right approach is to change the style of leadership, not to eliminate leaders.

This interactive workshop will explore the workings of an agile team and attempt to identify the issues and approaches to leadership styles that support an agile environment. This will be fun, informative – and there may even be prizes!

Notes

Workshop format…

Will have to think about how to transcribe this!

Case Study: Agile – Why Should Your Business Care ?

Filed under:

Conferences

Tags: Agile, AgileApproachesForDeliveringBusinessValue, Conferences

12-02-2008

I’m blogging the conference Agile Approaches for Delivering Business Value

Agile – Why Should Your Business Care?

Bill Birnie, Senior Manager, IS Development Solutions, Standard Life Employee Services Limited, Ollie LaFontan, Exoftware

Summary

What does my business want from Agile ?
Creating an Agile culture and the importance of measures
Consolidating gains and driving more change.

Standard Life’s award-winning use of Agile techniques is helping it achieve remarkable levels of productivity from its application development spend, and is supporting the positioning of technology provision at the heart of its business proposition.

This session will cover the importance of linking your Agile enablement strategy to the needs of your business, and the challenges created by trying to change processes and beliefs that have been in place for many years.

(more…)

Case Study: Delivering a Public-Private Partnership using DSDM

Filed under:

Conferences

Tags: Agile, AgileApproachesForDeliveringBusinessValue, Conferences, Kubernetes, NPWD

12-02-2008

I’m blogging the conference Agile Approaches for Delivering Business Value

National Packaging Waste Database – a DSDM Case Study

Steve Watkins, Head of IT Portfolio Office, Environment Agency and Jeremy Renwick, Kubernetes Ltd

Summary

Delivering the National Packaging Waste Database (NPWD) on time and to budget
Facilitating a very diverse stakeholder community drawn from industry and the 4 regulators
Managing the culture shock of imposing agile on a waterfall community
Managing an agile project with a geographically distributed team
Learning the lessons

(more…)

(1)

Case Study: Agile Analysis: A Proposition Assessment Case Study

Filed under:

Conferences

Tags: Agile, AgileApproachesForDeliveringBusinessValue, Conferences

12-02-2008

I’m blogging the conference Agile Approaches for Delivering Business Value

Agile Analysis: A Proposition Assessment Case Study

Luke Barrett, Senior Business Analyst, Thoughtworks

Summary

While the benefits of taking an Agile approach to the heart of the software development cycle are becoming increasingly recognised, this people-centric, communication-oriented, test-driven way of working is also powerful in helping teams and organisations early in the evolution of a idea or proposition.

In this case study we look at applying an Agile way of working to the analysis of a new business idea at its inception – this includes the creation and iteration of key deliverables (financial model, project roadmap, core processes and usage scenarios) to allow a go / no-go decision.

Note

What is role of business analyst in an agile organisation?

Agile values of simplicity, openness, communication, courage…

Apply agile software approach to evaluating business propositions.

Project – a new business idea which the owner wants to get funding for…

New business idea – challenge to validate within limited time and funds. e.g. what could be done in a week?

Objective – Prepare a Pitch, based on a clearer definition of the proposition, e.g.: financial model, key processes and goals, capacity model, customer scenarios, development roadmap for the business.

Small team – two consultants plus client.

1 week – each day based on two Action-Reflection cycles – 2 hr workshop, consolidate, 2 hr workshop, consolidation.

Keep it self-documenting

Models: traditionally use lots words of words to drive out ambiguity – but words are slippery! Important to facilitate a feedback-driven iteration towards consensus of the stakeholders. Use lots of visual models.

Started with finances – costs, revenues… A very quick ballpark analysis. Over the 5 days about 1.5 days on this.
Processes, roles and goals – the core of what the business does. Imagine a “day in the life”.
Capacity model – what resources needed to deliver the service?
Service development roadmap – how does the business grow?
Customer scenarios – what will it be like for a customer to use the service? Lots of Post-Its and pictures!

Put client in position to pitch to prospective investors and customers with supporting information, and brought to life with the scenarios.

The output had a positive reception!

Co-location of the team was vital – and if you aren’t, you can’t have a virtual beer together! (relationships vital).

Importance of dedicated time, dedicated effort / resources. “the heartbeat of feedback”

The Ten Golden Rules for Successful Agile Projects

Filed under:

Conferences

Tags: Agile, AgileApproachesForDeliveringBusinessValue, Conferences

12-02-2008

I’m blogging the conference Agile Approaches for Delivering Business Value

The Ten Golden Rules for Successful Agile Projects
Keith Richards, Keith Richards Consulting

Summary

Agile approaches to projects are maturing and becoming mainstream, yet some are more successful than others
This presentation describes the ten golden rules that will increase the chances of success, and make the difference between an “OK” project and an “excellent” project.
The golden rules also highlight what NOT to do.

Speaker

Keith Richards – process/method consultant, specialising in Agile projects. Author of “Agile Project Management” (TSO). Led team for DSDM Atern.

The Golden Rules

No survey – just first hand experience…

Define the project objective in less than 10 words
Build a team with those who say “can”
Go slow early to go fast later
Look backwards to go forwards
Change is great!
To be understood, seek first to understand
Collect actuals – “oxygen” for your project
Use fat communication channels
Work hard at controlling what you can’t control
One more day? NO! We’ll catch up NO!

If you can’t understand the rationale for doing a project you shouldn’t be doing it! Expect to spend half a day writing the <10 words.

Good people above good process – in fact good people more important than that they have the skills. Test: ask “Can I ask a favour?”

How much design up front (DUF) is enough? Answer: Enough! But try and avoid grabbing early at solutions. Test: “Is it safe to move on?”

ALWAYS have project reviews! Kaizen is vital.

Embrace change… How do you feel when the customer changes their mind? Should be happy! Change to get a closer fit to the business need (depth change) is good – change in breadth might be a problem… (signals possible issue with project objective)

Facilitation and influencing skills are core competencies for Agile projects – especially for the project manager. Try the 10 second silence when getting a progress update!

Measuring actuals – start now, start simple, start using to calibrate your estimates…

Communication – go visual, use workshops, never write when you can talk…

Continuously manage external risks – be “a bit of a worrier” – actively manage your risk log!

Time focus is your greatest weapon. Force the issue – timeboxes, not milestones. If you are going to fail, fail early. Never extend deadlines.

Conference: Agile Approaches for Delivering Business Value

Filed under:

Conferences

Tags: Agile, AgileApproachesForDeliveringBusinessValue, Conferences

12-02-2008

I’m blogging the conference Agile Approaches for Delivering Business Value

The stated goals are to provide:

a forum for the exchange of information regarding all agile development technologies;
an opportunity to hear case studies from a variety of sectors
[an opportunity] to find out new viewpoints and developments and learn from the experiences of others

Sessions:

Day 1

Day 2

Update – my initial learning reflections on the conference.

Links roundup for 2008-02-11

Filed under:

LinkLog

Tags: , Agile, Development, Fitness, Hoshin-Kanri, lean, products, remote-access, vpn, wireless

12-02-2008

Shared bookmarks for del.icio.us user Synesthesia on 2008-02-11:

ExRx (Exercise Prescription) on the Net
fitness
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
agile
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 2008-02-10

Filed under:

LinkLog

Tags: , Agile, Scrum

11-02-2008

Shared bookmarks for del.icio.us user Synesthesia on 2008-02-10:

The Scrum Papers: Nuts, Bolts and Origins of an Agile Process
agile scrum

Links roundup for 2008-02-09

Filed under:

LinkLog

Tags: , Agile

10-02-2008

Shared bookmarks for del.icio.us user Synesthesia on 2008-02-09:

Welcome to the Mainstream – How To Fail with Agile
Mary Poppendieck on how not to do it 
agile

Looking forward to Agile Approaches for Delivering Business Value

Filed under:

Conferences

Tags: Agile, AgileApproachesForDeliveringBusinessValue, Conferences

08-02-2008

I’m planning to attend Agile Approaches for Delivering Business Value next week.

It looks like an interesting set of sessions, and although I doubt I’ll be liveblogging, I aim to post some notes here as soon afterwards as I can.

I’m particularly interested in two of the talks on the second day:

“A Square Peg in a Round Hole: Agile and fixed-price contracts” by Duncan Pierce;

“When XP Met Outsourcing” by Angela Martin.

In my current environment almost all our systems development is carried out by suppliers in various contractual models, and I’ve hit some frustrations in getting acceptance of Agile methods. I’m keen to learn how others may have constructed a “win-win” in this sort of situation.

Links roundup for 2008-02-05

Filed under:

LinkLog

Tags: , Agile, Kanban, littles_law, PDF, poppendieck, queueing_theory, TOC, via:kevinrutherford

06-02-2008

Shared bookmarks for del.icio.us user Synesthesia on 2008-02-05:

Principle: Little’s Law
littles_law queueing_theory
Poppendieck: Managing The Pipeline
poppendieck agile kanban toc
No More Iterations
Wayne Allen documents the start of an experiment to move an agile development team onto a kanban-based, non-iterative workflow.
agile kanban via:kevinrutherford
How You Slice It
Jeff Patton article on slicing up top-level requirements into spans and releases… 
pdf agile

Links roundup for 2008-02-04

Filed under:

LinkLog

Tags: , Agile, dbms, PDF, social+software, tco, userstories, versioncontrol

05-02-2008

Shared bookmarks for del.icio.us user Synesthesia on 2008-02-04:

Standardise your desktop hardware to reduce TCO
HP whitepaper tutorial on desktop TCO 
tco
Versioning Databases â�� Branching and Merging
Article 5/5 from K. Scott Allen on maintaining your app’s db schema in version control
versioncontrol dbms
Views, Stored Procedures, and the Like
Article 4/5 from K. Scott Allen on maintaining your app’s db schema in version control
versioncontrol dbms
Versioning Databases â�� Change Scripts
Article 3/5 from K. Scott Allen on maintaining your app’s db schemea in version control
versioncontrol dbms
Versioning Databases â�� The Baseline
Article 2/5 from K. Scott Allen on maintaining your app’s db schema in version control
versioncontrol dbms
Three Rules for Database Work
Article 1/5 from K. Scott Allen on maintaining your app’s db schema in version control
versioncontrol dbms
Finding the Forest In the Trees
Jeff Patton article on how Agile methods can best decide WHICH software to build in the first place. 
pdf agile userstories
Don’t know what I want, but I know how to get it
Why knowing what you want in agile development may be an impediment to getting it – and the difference between incremental and iterative…
agile
The mystery of the shrinking story
The decreasing size of a user story and Agile development’s drift into big-up-front-design
agile
The Elements in the Social Software Stack
Thomas Vander Wal on the elements that need to be present in successful social software
socialsoftware

Links Roundup for 2007-09-06

Filed under:

LinkLog

Tags: Agile, kaizen, Kanban, lean, personal-development, Productivity

06-09-2007

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:
Keywords: agile, kanban, lean

Links Roundup for 2007-04-19

Filed under:

LinkLog

Tags: Agile, DanBricklin, GNU, iTunes, PKM, podcast, research, Tools, WardCunnnigham, wget, wiki, workflow, XML, XSL

19-04-2007

Shared bookmarks for del.icio.us user Synesthesia on 2007-04-19

Cleaning up iTunes plist XML:
Two-pass approach – changing the iTunes plist format to a clean XML hieratrchy and then processing that
Keywords: XML, XSL, iTunes
GNU Wget – GNU Project – Free Software Foundation (FSF):
Homepage for the GNU Wget project
Keywords: tools/wget, GNU
Windows Wget files:
Windows builds of the popular wget tool
Keywords: tools/wget
Wget local copies of your online research (del.icio.us, digg or Google Notebook) – Lifehacker:
More applications of wget
Keywords: research, workflow, pkm, tools/wget
Geek to Live: Mastering Wget – Lifehacker:
Good review of practical uses for wget…
Keywords: tools/wget, workflow, pkm
Dan Bricklin / Ward Cunnigham Interview Podcast:
Dan Bricklin interviews the creator of wiki
Keywords: Wiki, DanBricklin, WardCunningham, podcast
The Elements of Agile Style:Keywords: agile/methods

Links Roundup for 2007-03-28

Filed under:

LinkLog

Tags: Agile, Kanban, kayuda, lean, mindmapping

28-03-2007

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

Links Roundup for 2007-01-03

Filed under:

LinkLog

Tags: Agile, iTunes, Knowledge_Management

04-01-2007

Shared bookmarks for del.icio.us user Synesthesia on 2007-01-03

How To Add iTunes Artwork To MP3 ID3 Tags Using iTunes:
Keywords: MP3, iTunes
SourceForge.net: OpenKM: Open Document Management System:
OpenKM is a Document Management System (DMS). Useful for small and large enterprises intended to organize and share your (or your company) documents.
Keywords: CMS, Java, KM
Set-Based Concurrent Engineering:
Keywords: Agile, Lean, ConcurrentEngineering
A Practical Guide to The Hero with a Thousand Faces:
Keywords: Mythology, JosephCampbell
MySQL Optimization Hints:
Keywords: MySQL
Royal College of Psychiatry CPD Podcasts:
Keywords: Podcast, Psychiatry

Links Roundup for 2006-10-16

Filed under:

LinkLog

Tags: Agile, MSP, Programme Management, Systems-Engineering

16-10-2006

Shared bookmarks for del.icio.us user Synesthesia on 2006-10-16

Scaling Agility: Agile Systems Engineering:
Great collection of links from Brad Appleton on scaling Agile methods to enterprise systems engineering
Keywords: Systems/Engineering, Agile, SystemsEngineering
Scaling Agility: Agile Program Management:
Brad Appleton has assembled a great collection of links to resources about scaling-up agile methods to the programme management arena.
Keywords: Programme_Management, Agile, MSP

Agile Programme Management

Filed under:

Tags: Agile, Programme Management

16-10-2006

Via Brad Appleton‘s excellent post of links to Agile Programme Management resources, a paper on Combining Agile Methods with Stage-Gate Project Management.

Based on studies in three engineering companies, the conclusion is that are benefits from both the management and engineering perspective.

Good things:

Agile method add microplanning and day-to-day control to the stage-gate methods
Engineering teams felt more in control of their work
Stage-gate approach improves ability of agile methods to interact with other engineering teams, other functions (such as marketing) and senior management.

Things to watch out for:

Need to manage expectations
Challenge on large projects of finding a “customer representative” as required by Agile methods

Links Roundup for 2006-09-22

Filed under:

LinkLog

Tags: Agile, Project_Management, Scrum

22-09-2006

Shared bookmarks for del.icio.us user Synesthesia on 2006-09-22

Using DSDM with PRINCE2:
Article from Agile Alliance showing complementary nature of the two approaches
Keywords: Project_Management/Methodology
Software Project Management : Methodologies & Techniques:
Overview of development methodologies and project management techniques commonly used.
Keywords: Project_Management/Methodology
Business Rules:
Managing Released Software and IT Problem Resolutions Using Scrum and Agile
Keywords: Agile/Support, Scrum,, ITIL,, Support

Links Roundup for 2006-02-06

Filed under:

LinkLog

Tags: Agile, Databases, Emotional-Intelligence, Enterprise-IT, IPR, Knowledge_Management, OpenOffice, presentations, Productivity, Project_Management, Scrum, Syndication-Formats, Training, wiki

07-02-2006

Shared bookmarks for del.icio.us user Synesthesia on 2006-02-06

RSS and Copyright:
John Palfrey – Berkman Center, Harvard Law School – on the issues raised by sites which republish syndicated feeds
Keywords: IPR, RSS, Syndication
Scrum for Docs:
Notes from Microsoft’s Rob Caron on using the Scrum process for managing document production in a technical writing team.
Keywords: Project_Management/Scrum, Scrum
The ACID Model:
A reminder of the four goals of any dataase system: Atomicity, Consistency, Isolation and Durability.
Keywords: Databases
Crash course in learning theory:
Great notes from Kathy Sierra on the insights from learning theory that can make your presentation or training course that little bit more effective.
Keywords: Cognitive_Science, Emotional_Intelligence, Presentations, Training

kmwiki:

Keywords: KM/Wikis, Wiki
More on Chunking as an Alternative to Multitasking:
Lisa Haneberg offers advice and a planning sheet to help with chunking your to-do list…
Keywords: Personal_Productivity
Agile links:
Blog post full of links on Agile from Clarke Ching
Keywords: Agile
Free Online Graph Paper / Grid Paper PDFs:
Generate and download unusual graph paper as PDF. I’ve found the "Cornell Note Taking System PLUS Graph Paper" one to be really good for mind-mapping meetings with space for action lists etc down the side…
Keywords: Personal_Productivity
Bristol City Council Open Source Academy:
Home page for various papers from Bristol City Council based on their experience of moving to OpenOffice.
Keywords: OpenOffice/Migration
Visual cognitive styles:
Two sorts of visualisation – people who construct images of objects, and people who construct images of spatial relationships amongst objects.
Keywords: Cognitive_Science

Tagged Posts: Agile

Follow Me

Subscribe by Email

Meta

Copyright