I used a variety of tools and techniques to bring the project to life. As is usually the case, some worked better than others so I thought I’d review the approach and describe some of the issues and possible reasons.

The agenda for the day was:

1. Review project vision and goals
2. Establish key priorities and concerns
3. Establish candidate releasable chunks
4. Decide what to do first

Attendees included the development team, development management and business sponsors.

Project Vision

After some general discussion about the product we set about defining the Vision. The group were split into smaller groups each mixing development and business folk. Each team was asked to come up with an elevator pitch for the project of the form:

For __Customer__ who __has some need__
the __product name__ is a __product type__
that __will provide some benefit__
unlike __competing products__
out product will __key differentiator__.

In reviewing each groups proposed vision statement we settled on a single elevator pitch that embodied the purpose of the project and began to focus the team on what might be important.

Project goals

To further cement the way in which the product could be judged a success we went on to identify candidate goals. These included some consideration of how we might measure success.

These two exercises were received with some enthusiasm as the sub teams collaborated over achieving an accurate representation of the product. The need to measure outcomes causes business sponsors to work with those who were more technically minded in order to achieve measures that were specific, measurable and representative of the desired outcome.

Goals in this example included areas such as customer and sales force satisfaction as well as specific operational cost reduction goals.

Sliders

This is a technique that I picked up from Rob Thomsett’s Radical Project Management. I have used it to great effect in the past where trade-off was a critical demand of the project.

The sliders technique works by selecting a set of traits that could be considered to be in tension. These are represented as sliders that can be fully on, fully off or anywhere in-between. The stakeholders and team can discuss the implications of various slider positions. For example when considering cost and budget to be fixed we may choose to allow for some flexibility in scope in order to ensure quality.

Thomsett uses these seven measures of success; satisfied stakeholders, meet requirements, meet agreed budget, deliver on time, meet quality requirements, satisfy the team. I have used the same technique with other measures such as maintainability, time to market etc.

This technique was less well received than the previous two. While the discussion that was provoked was valuable some members of the group were unhappy with the somewhat arbitrary nature of the measures. One sponsor suggested that he felt that he was having to trade off his goals before even the project has started.

I believe that this early trade-off is a valid concern and it came up more than a couple of times throughout the project. When we apply agile principles to product development we look for small meaningful increments. This can be uncomfortable where a sponsor has internalised a grand vision.

Establishing releasable chunks

This exercise starts with the suggestion that it is good for the project to reach a releasable state early. We begin by identifying a set of capabilities of the system. These are grouped based on cohesion. I use the notion of Minimal Marketable Features to focus on achieving small releasable increments. We begin to prioritise these and work to make the first chunk as small as is reasonable in order to achieve marketability.

This was the most valuable and effective part of the day. The notion of MMF was used extensively through the project with the business sponsor often stating that a feature was “important but not necessary for this MMF”. Further, the focus on marketability places some focus on needs that can often be deferred such as security testing, performance testing and help facilities.

The following day would include beginning to identify the User Stories that would be necessary in order to achieve MMF 1.

Lessons learnt

In reflecting on this exercise there are things I would do the same and things I would consider doing differently. The initial Vision and Goals exercise was well worth while. While I know that the success sliders approach can be useful I may not have used that technique in this particular context.

A technique that I chose not to use, on reflection, would have been a good choice. As a part of the identification of releasable chunks we should have begun to identify those personas that we could address and how they related to different feature sets. I believe that this would have increased our focus on specific features and aspects of features.

We live and learn

Thanks for taking part in my mini retrospective on this workshop, I hope it can be of use to others. Please do feel free to ask questions of make comments below.

Technorati Tags: Project kick off

To date I’ve never had a canned answer to this and can come from various directions perhaps talking about the history and how it’s an umbrella term for a whole bunch of things or maybe talk about what it’s like working on an agile team. On this occasion I was quite pleased with the answer that fell out:

Agile is about delivering business value!
Businesses tend to exist in a state of constant change so if we want to deliver something valuable to them then we need to be willing and able to embrace that change and deliver quickly.
In order to deliver quickly and deal with change we have found that quality is a necessary. This is particularly true if we want to continue to deliver over a sustained period.
At the bottom of this stack, underpinning all the elements mentioned so far is the need to treat workers with respect and empower them to do the right thing. Without this you wont achieve the quality or speed that you need.

So:
Value <- Embrace Change <- Quality <- Respect & Empowerment.

Is there any more to it?

I have been practising and coaching Scrum for a number of years and I delight in the effect it has on project teams. While I practice Scrum I find that Lean Thinking can both help me communicate Scrum and help teams to become more effective in applying Scrum. This way of thinking led to me becoming interested in Kanban a year or so ago since when I’ve being most concerned with where I ought to recommend Scrum and where Kanban.

Recently I have spent time with maintenance groups for whom Scrum would be a poor fit. Kanban offered me an alternative when the client was leaning towards a ScrumBut implementation.

There are some fundamental differences between early project / product development work and the later stages and I don’t see this as a problem. Toyota themselves hold two separate approaches. The Toyota Production System (TPS) is the most widely known Lean Manufacturing implementation. This is the world of work cells, standardised work, Kanban boards and Andon lights. However, when Toyota want to create something new they use the Toyota Product Development System. This approach focuses on a chief engineer holding a vision and rallying a team around him. High bandwidth communication, discovery and experimentation are the order of the day.

So back in a software development context Scrum was designed to manage uncertainty and complexity, to foster high band width communication and seems a valuable fit for early development.

Corey Ladas in his ScrumBan Book declares the following Axiom for applying his application of Lean to software development

Axiom 2: It is possible to develop any value adding increment in a continuous flow from requirement to deployment

Corey makes it clear as he progresses that this well defined workflow is critical to his desired approach. In a new development that workflow is often not known and usually not linear. Rather the team swarm over the requirement often returning to the customer for feedback before offering a completed deployable feature.

My suggestion is this, Scrum is a powerful approach to managing uncertainty as well as being a supportive environment for building a team. I believe that one goal of product development should be to reduce the uncertainty and evolve the workflow. As adding features becomes more straightforward we may find that we are in a state akin to production and can take advantage of a Kanban approach to further optimise for reduced cycle time, increased throughput and just in time scheduling.

The problem with user stories in practice is that the desire to work in short cycles drives teams to split stories to a degree that they can loose sight of the value element from the perspective of a customer or product owner. This is often alleviated through themes or story hierarchies but maybe there is a better way.

The minimum marketable feature (MMF) provides a connection between the high level vision of the project and the detailed user story.

According to Software by Numbers a Minimal Marketable Feature is:

… a chunk of functionality that delivers a subset of the customers requirements and that is capable of returning value to the customer when released as an independent entity.

I have found that this construct offers a powerful approach to assessing, understanding and prioritising feature sets. I believe that the benefits of considering MMFs applies to both software projects and product development activities. Due to the focus that is placed on the need rather than the solution this technique continues to apply where we consider projects with little bespoke software.

In essence given some form of need we must pursue it’s decomposition repeating the challenge; “is the described feature or feature set really so minimal as to be un-deployable should any aspect be missing”. We gain further benefit by asking; “is there any aspect of this specification that is over specified”.

I guess at this stage an example is called for. Imagine for a moment that I am a traditional retailer considering gaining a web presence. I have a vision to develop an online presence in order to increase revenue by attracting a wider customer base.

I can begin assessing my need and decomposing features while ensuring that the resultant chunk remains marketable.

MMF 0
Help prospective customers find out about the business through basic online presence.

MMF 1
Enable online purchasing of restricted set of products
Offer a single form of payment

MMF 2
Broaden product range

MMF 3
Increase payment options

MMF 4
Make special time limited offers

MMF 5
Provide vouchers to encourage repeat custom

I am still experimenting with this approach, however, it seems that as a product increases in maturity MMFs can reduce in size (probably to the point where stories would be adequate). It is early in the process where we can get the most value.

In my experience release planning is an area of weakness for many organisations. Releases are large for a variety of reasons including funding, deployment effort and fear of not getting what you really want. I believe that an aspect of this is that once assigned a project it’s team want it to live on independent of the rest of the organisations portfolio. Applying an MMF approach should ease the job of portfolio management since MMFs have a very tangible value proposition.

This was a small gathering of practising agile coaches. The event was run as open space with the subject matter focussing more on coaching than on agile.

The image below is the open space schedule, while details are sparse this may give you an insight into the variety of subjects being discussed.

I’ll try to offer some of my take away thoughts following the day below.

Effective coaching styles

In psychotherapy the term “stance” is used to refer to your approach to a specific situation. In this session we discussed the different roles a coach will play including trainer, consultant, mentor and coach (in the traditional sense).

A further conversation identified the strategy of using near and far coaches collaborating to achieve the benefits of an on-site coach while avoiding the drawbacks of a coach that becomes a part of the system under change.

Taking a user centred approach to coaching teams – Mike Sutton

This discussion focused on the personal aspect of coaching. That invisible line between work and life. Should an agile coach shy away from real stuff?

Our discussion revolved around the necessity to respect team members, be available to listen to personal stuff in order to ensure that individual goals are considered along with team and project ones.

Appreciative Enquiry – David Harvey

David had planned to discuss how AI was being applied but, by popular demand began by introducing where it had come from before inviting attendees to consider where they had applied these principles (deliberately or not).

The model presented was:

• Discovery
• Dream – how could it be?
• Design – how will we get their?
• Destiny – execution.

The obvious (by the name) focus on the positive can expose resources that are hidden and inaccessible with a more problem oriented approach.

Well formed outcomes – Mike Sutton

I arrived half way through this session as the group were reviewing the example they had walked through. The proposal here is that a proposed outcome can be reviewed against the following :

• Positive
• Own
• Specific
• Evidence
• Resources
• Size
• Ecology

This closed with a short conversation about the NLP technique of chunking in order to establish a true goal. The proposed question used to test an outcome was

What will that get you?

Leading self organising teams – Deborah Hartmann Preuss

In this session Deb walked us through some of the tools she has been using in her coaching:
Use of silence, how long are you willing to wait after asking; does anyone have anything else to say?
Active listening
Powerful questions

Dysfunctional promise making – Deborah Hartmann Preuss

Deb focussed here on the transaction that occurs between customer and team.

The risk here is that teams can forget that they have a choice of responses including but not limited to; decline, defer, clarify priorities etc.

The key to responding appropriately is to understand what it is the customer really cares about.

And finally, where new information presents it’s self, the team have a responsibility to re-negotiate.

Closing

Finally, in closing you would expect a retrospective and there were even a handful of pomodoro timers for those willing to fight for them

So, it’s sad talking about this stuff in the pub but it has prompted me to dig a little deeper into my own perspective.

So, what does it mean? In a training course I run I refer to it as an umbrella term for a whole bunch of approaches many of which pre-date the use of the word (think SCRUM, XP, TDD, FDD …). In the same course I offer the definition

“To be able to deliver business value quickly and respond to change”

But still this doesn’t provide us with an ability to recognise “agile” when we see it.

At XP day in November I recall two conversations. The first was with a manager who proudly told me his team were running text book XP very effectively and had been doing for some time. I questioned him on the output of his last retrospective. I recall someone saying about XP; “If you’re still doing it by the book after a month then you’re not doing it”. I believe that while XP, SCRUM etc. are helpful we should be constantly looking for a better way. On the same day I spoke to a developer from much more traditional background who’s team were making small steps to improve the process. So which team was the agile one?

I see constant striving for a better way as a fundamental. Compare this with the Toyota attitude to perfection.

The word “better” is the crux of this. Where better for this team is in line with the agile manifesto they will evaluate practices according to the teams ability to collaborate, their ability to deliver value (i.e. the right balance of software, documentation and other artefacts), their ability to collaborate with the customer obtaining feedback and their ability to respond to change.

So, given this definition, the team is, for me, agile independent of their current state.

So what about all of the practices we see, don’t they contribute? My perspective on an effective agile team is that they should keep sight of how practices evolve and select new practices in line with their current constraint or pain.

Given my definition above, it makes no sense to state that I have an agile team. Rather I have a team that is delivering effectively and is constantly striving for improvements. Agility offers a continuum and the manifesto proposes the direction of travel.