I was recently asked to help a client kick-off development of a new product. This was to be their first “agile” project so the kick-off had to set the scene for the collaborative development approach that was to follow.
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:
- Review project vision and goals
- Establish key priorities and concerns
- Establish candidate releasable chunks
- Decide what to do first
Attendees included the development team, development management and business sponsors.
Read the rest of this entry »
I met with a potential client last week and found my self answering the question, “what, in a nutshell, does agile mean?”.
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?
July 28th, 2009 in
Agile |
4 Comments
SCRUM and Kanban (as applied to software development) are different. Proponents of the two drift from staunch opposition to declaring Kanban as a special case of Scrum.
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.
July 28th, 2009 in
Agile,
SCRUM | tags:
Agile,
Kanban,
SCRUM |
1 Comment
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.
July 21st, 2009 in
Agile | tags:
MMF,
Prioritisation |
No Comments
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 »
May 27th, 2009 in
Agile | tags:
coaching |
No Comments
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.
February 24th, 2009 in
Agile | tags:
Agile |
No Comments
