Karl Scotland – Using Agile to Deliver Value
Archive for July, 2008
Agile 2008 Sessions
Jul 17th
Agile 2008 is almost here and I’m looking forward to presenting 3 sessions this year.
Managers Introduction to Test Driven Development (with Dave Nicolette)
Wednesday 6th, 16:00 – 17:30, Civic Ballroom South, Customers & Business Value Stage
The purpose of this session is to help non-technical managers understand the business value of one of the popular agile software development techniques. It is designed to help managers understand the impact on their projects when their technical teams use the agile technique, test driven development (TDD). We begin by demonstrating the technique of TDD using a tool familiar to nearly all managers: Microsoft Excel. Clarke Ching developed a TDD exercise using Microsoft Excel that many others have used as the basis for demonstrations and presentations on the subject. We use this exercise to demonstrate the red-green-refactor TDD cycle with a tool familiar to nearly all managers so that they can see what the buzzword means and get a feel for the technique. This is followed by a presentation focusing on the effect of TDD on a project’s timeline, code quality, cost of development, cost of ownership/support, and longevity of the code in production. The core of the message is that TDD helps a team control the accumulation of technical debt in the codebase, and this in turn controls costs, reduces time to market, and results in a cleaner product that will have a longer production lifetime.
KFC Development – Finger Lickin’ Good (with Aaron Sanders)
Thursday 7th, 8:30 – 12:00, Essex Ballroom, Breaking Acts Stage
This workshop explores three important Lean concepts – Kanban, Flow and Cadence (KFC) – which can be combined to generate a more pipeline-based approach to software development, as opposed to the more common timebox-based approaches of more traditional Agile methods. We will describe our experiences implementing these ideas at Yahoo! and explain the concepts using examples, simulations and games. In addition, because this is a new and emerging way of working, there will be an opportunity for discussion between the participants about how the ideas might be applied in their own situations, in order to advance the art.
Integrating Scrum with the Process Framework at Yahoo! Europe (with Alexandre Boutin)
Friday 8th, 8:30 – 10:00, Kenora, Agile & Organisational Culture Stage
This presentation describes how Yahoo! International, and in particular, the Yahoo! Europe, has moved from having a very waterfall inspired process framework, to having one which is very lightweight and flexible, and thus compatible with Agile methodologies. This was achieved through Agile teams collaborating with the Process Group in its own iterative inspect and adapt cycle. The Process Group has evolved from being a control-oriented team, with a process-centric framework, to being a coaching-oriented team, with an organisational-centric framework. Thus, rather than telling teams how to run their projects, they help teams ensure they are meeting business needs.
The Anatomy of an MMF
Jul 7th
I’ve been involved in a number of discussions about how User Experience work fits into an Agile process. As a result a trying to articulate my position, I’ve come up with the following explanation of the anatomy of an MMF.
The following diagrams assume the following key:
Lets start by looking at a typical waterfall model:
In this case, all the UE work would happen early on, but obviously, isn’t Agile, so doesn’t allow for iteration and improvement.
A more Agile approach is:
In this case, the UE work is spread across the lifetime of the project, but for each increment, UE work happens early, relative to build etc.
That’s still not truly representative of an Agile project, which is more collaborative, so we have:
Here, everything happens together, as needed, for each Product Backlog Item (PBI, using Scrum terminology) and this is where the problem begins. In order for a PBI to be sufficiently formed to be able to be planned into a Sprint, there may need to be Analysis and UE work in advance. So typically these become PBIs of their own in preceding Sprints. The problem I have found with this approach is that the focus is on the PBI, and the over-arching feature of value is lost, resulting on long cycle times.
So this is how I prefer to think about it:
Throughout the life of a Minimal Marketable Feature, the different disciplines are involved to varying degrees. More UE earlier on, and more QA later. However, the focus is still on the over arching feature, and all are still collaborating to deliver the feature as quickly as possible. Any Sprints or PBIs are simply mechanisms to manage the flow.
Given this view of things, its a small step to allow MMFs to overlap, so that the features can smoothly flow through the system.
The Conductor as an Agile Leader
Jul 1st
One of my background areas of interest is the use of musical metaphors to describe agile software development. I’m a classically trained musician, and I’m always surprised by the number of other musicians I meet in the agile community. I can’t help thinking that the training and experience gained by musicians is applied by them in their software careers. I occasionally submit music and agile related sessions to conferences, but they generally get rejected because I’ve not really got my point across very well yet (e.g. Agile 2008). One common argument is that conductors are perceived to be command and control project managers.
On that note, I’ve just seen Benjamin Zander on music and passion (via Clarke Ching, via Frank Patrick). Apart from being very entertaining and powerful, he describes his role as a conductor with some choice quotes.
“He depends for his power on his ability to make other people powerful”
and
“To awaken possibility in other people”
And he describes success as:
“If the eyes are shining, you know you’re doing it”
so if he’s not being successful:
“Who am I being that my players eyes are not shining”
All of which can be applied to the role of leadership with an agile software development team.
