Prioritisation with MMFs

For the majority of agile teams user stories are the preferred tool for requirements management. User stories provide numerous benefits including; a focus on the business problem being solved, a just in time approach to specification, amenability to splitting that supports working in short time-boxes.

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.

Managing WIP with Scrum

Recently I’ve mentioned, both on groups and blog posts, the fact that many limiting Work In Progress in reserved for those taking on Kanban Software Development.

In this post I’d like to share a couple of the techniques / approaches that I use in managing WIP within a Scrum framework. These tools may be useful to you in order to improve an existing Scrum team or as a step in moving towards Kanban (see also Scrumban by Corey Ladas).

Daily Management

Members of an agile team should be empowered and trusted to work on the right thing. This may be helping out a colleague or fixing a broken build as well as building new features.

In order to encourage the right behaviour I propose the following filter to new teams. When looking for the next task to work on:

• Is there anything I can do to assist a colleague in moving a high priority task to Done?
• What is the highest priority task on the board that I have the skills to take on?

This has the effect of keeping the task in progress to a minimum as well as weighting the teams effort towards the top of the board (i.e. towards higher priority stories).

Some of the teams I have coached have had a code review column that development tasks must flow through, reviewing some code would be one way of assisting in getting to Done.

The effect of this approach is to minimise the stories in progress, maximise the chances of completing the higher priority stories in the iteration, encourage swarming over tasks and stories.

Project tracking

Many Scrum teams use burn down charts. Consider using a burn up chart, this provides visibility into changes in scope as well as room for further improvements as you’ll see in a moment. By tracking two lines representing scope and done we can our progress towards some milestone. In the example below blue shows the known project scope and green is work done by the dev team.

It is common to do some early analysis work before an iteration to ensure that the acceptance criteria of a story are known before the sprint planning meeting. We want to ensure that we don’t over invest in this analysis work retaining a healthy buffer of stories ready for development.
This part of the scope that has been analysed can be shown on our burn up chart, yellow in the example below. Here we can see where analysed work is building up.

Of course if we are doing this we may also add an analysis column to the task board along with a ready for development column.

Another category of work common in Scrum teams is post iteration testing. After the demo we hand off work to a QA or UAT group that validate the requirement has been met. By recognising this work we continue to expand our view along the value stream.
Below I show in red the work that has been accepted by QA. This demonstrates a problem in the system which was not made visible by the original chart. We can see that work that is developed but not tested is building up. If we care about WIP and cycle time then this is a problem, also if we care about project success we should consider this to be a build up of risk.

A final line could be added to show the deployment of software. A delay in deployment can mean missed revenue earning opportunities as well as a missed opportunity to learn and react.

I use these type of charts (Cumulative Flow Diagrams) as an aspect of project reporting in order to expose a more complete view of the development process beyond the confines of the Scrum team.

Also, where applicable I will augment the task-board with these extra states to show more project context to the team.

My first open space

I ran my first open space the other week.

What is open space?

For those that haven’t experienced it this is an approach to running meetings or conferences that leaves the agenda open for the participants. The way I have seen this applied is for attendees to do a very short elevator pitch regarding a subject for discussion at the beginning of the day. They then place a card on a large wall plan of the day indicating time slot and location of the session. This free form approach allows for small group discussions to be held in parallel. Throughout the day attendees move from session to session selecting subjects of interest from the board. Sessions tend to be run as open rooms so attendees are free to drift between sessions if they wish.

With some trepidation I requested that time was put aside in the schedule of my companies quarterly gathering. As you would expect I had some concern that no suggestions would be forth coming and the days schedule would have holes in it. In fact, attendees came up with a wide variety of ideas for discussion and all concerned appeared to enjoy the day.

If you have considered running an open space either for a local user group or at your place of work I can recommend it highly. I believe that the key to achieving active participation in a work environment is to be clear that sessions are informal, thus minimising prep work, and enable many sessions to run in parallel, enabling small group discussions on niche subjects.

Agile coaches gathering

Last weekend was the agile coaches gathering in Bletchley, UK.

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.
Read the rest of this entry »

Task boards and kanban boards

Karl has offered this post explaining the difference between a task board and a Kanban board.

He draws attention to the common task board focus of tasks to do this iteration. No WIP limit, only tasks currently in development.

This differentiator becomes less apparent when we look at how teams develop their use of task boards. Personally one of my prime reasons for using a white board over an electronic tool is to open up the possibility of the team changing the layout.

It is common for teams to apply the mantra, don’t start something new if you can support an existing activity. In addition to, always ensure that you are working on the highest priority story to which you can contribute. While this is not a fixed WIP limit it does reduce the work in progress in terms of both tasks and stories.

It is also quite normal for a team to choose to show upcoming stories where early analysis is due in preparation for a sprint. Add to this a column for acceptance testing, again not unusual, and we begin to see similarities.

I really appreciate the contribution that the Kanban community have made to our collective body of knowledge. However, it may be beneficial for them to more openly recognise the broad overlap in values between Kanban practitioners and the rest of us agile folks.

Software cratsmanship

Last night the subject for debate at XTC was software craftsmanship. This is not a new subject but seems to be gathering momentum. In many ways I am a supporter, however, I do have certain reservations about the way it is being presented.

We have a draft of a manifesto for software craftsmanship that has been written to build upon the Agile Manifesto. Following this we have a host of proposed principles.

Personally I care about delivering quality software, I believe that software apprenticeships and effective mentoring would have a very positive impact increasing the skill of those involved in the industry. Finally, I believe that practice (i.e. doing a task followed by reflecting on the task purely for the purpose of learning) is largely ignored within our industry. If you care about what you build at work you should practice to develop your skill in your own time.

On the other hand I would prefer it if the concepts of craftsmanship and agile were kept separate. Being a craftsman is a personal choice independent from the process your team has selected. It is also a life choice since it is unlikely that you can be a craftsman 8 hours per day. By contrast agile teaches us about collaboration. I am sure that these two are compatible, even complementary but my preference would be to retain the separation.

Craftsmanship

There seems to be an increasing amount of discussion about software craftsmanship but what is it?

Thanks to Robert C. Martin for this great presentation about what it means to be a professional craftsman.

I’m sending this to everyone I can think of so I should let you know. This is recommended viewing for anyone who considers them-self a professional developer, software engineer or dare I say it craftsman.

In the presentation you will hear ‘Uncle Bob’ suggest that we have finally reached the point where we can discuss our profession. He goes on to talk of a variety of practices that have evolved to form the lynch pins of that profession. These include design principles, testing and my favourite, the following comment regarding defects:

Expecting QA to find bugs is unprofessional.

Rocks into Gold

Just read Clarke Ching’s “Rocks into Gold”.

What a fantastic little book.

The economics for agile development are so simple. Release it early and it’ll pay for it’s self sooner.

I’ll certainly be sharing this link.

Agile workflow

Karl Scotland has proposed an agile workflow to counter some of the waterfall like connotations apparent when we look at a Kanban board.

So for each feature, one by one, we end up with:

Incubate –> Illustrate –> Instantiate –> Demonstrate –> Liquidate

Does that still seem like a waterfall process?

I think that Karl’s reasoning is sound and I have used similar workflows with SCRUM teams to ensure that they keep the entire value stream in view.

However, before I go on to describe the workflow I am currently using I should stress what this workflow is.

A feature workflow is just that. The feature goes through a number of states from the lightbulb moment to deployed, in use and generating value. A workflow in kanban does not mandate hand-offs between individuals. Equally there is no demand that the team do not swarm over the feature ensuring it travels smoothly and quickly between states.

As Karl states, it is common for SCRUM teams to visualise features as being to-do, in progress and done. I tend to add a couple more states in order to visualise the product backlog; it is nice to have items at the top of the product backlog that are ready for development to pull, everything else on the backlog is simply identified.

So, I have: Identified, Ready for dev, To-do, In-progress, Done.

To tidy this up a little more I can say: Identified, Ready for dev, Committed, In progress, Dev Done.

Again Karl identifies the fact that if it’s not deployed then it’s not generating value. I also tend to work in environments where there is more to do between Dev done with it’s automated unit and acceptance tests and go-live. I’m not saying this is ideal of even that it’s an end state but I am currently looking at workflows a little like this:

Identified, Ready for dev, Committed, In progress, Dev Done, Iterative test done, QA accepted

Where iterative test is an ofset risk mitigation exercise including exploritary testing, some performance assurance and anything else that we can’t pull into the iteration but we’d like to get feedback on ASAP. QA is just that, if we’ve done everything right then there will be nothing coming back from QA.

Of course a workflow like this provides me with the opportunity to visualise work in progress using cumulative flow and to identify bottlenecks. Don’t forget, this is a SCRUM team, we batch 2 weeks work into an iteration because right now that is helping us. Maybe one day we’ll decide to go towards single peice flow but not today.

What is agile?

I recently sat in the pub with a couple of colleagues and the subject came up. It soon became apparent that, while we do things in very similar ways we do differ on the use of the word agile. We had views expressed from “stop using that word” to “it’s just good practice” and others I don’t recall.

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.