agility over being Agile!

2008-06-30T10:06:00.003+01:00

Shock horror... I'm actually writing an entry in my blog. I can't believe it's over a year since I last wrote here; so much has gone on.

Rather than bore everyone with what I've been doing, I'' list some of the topic areas that I'm currently involved with:

Working effectively with aggressive growth of a small technical team to a very large one
Transforming legacy code
Agile/lean product management
Finding the right balance between Strategy (long term) and Tactical (short term) and how that manifests as the choice between (technical and product) investment and debt
Creating a Society of small, single-focused, high performance teams without undesirable characteristics such as knowledge silos, and sub-optimal global performance
Continued professional development and life long learning journeys appropriate for developers
Bridging the communication gap between those who need, those that want, and those that can create

Not much then!

Extreme Programming Club in Leeds!

2007-01-20T18:26:00.000+00:00

It's great to see Yorkshire seems to have finally woken up to agile development and with it an interest in sharing indiciduals experiences. An Extreme Programming Club is being formed that will meet monthly in Leeds; the first meeting is scheduled for the 7th February.

Where did 2006 go?

2007-01-20T18:20:00.000+00:00

Well I can't believe it's 2007, and worse we are already over halfway through January. This is my first blog post in quite a while and apologies for the long gap. Basically a combination of an increase in my workload plus falling ill for a rather long time and of course Christmas and new Year meant that something had to give and I'm afraid it was my blog. But I'm finally well again and I'm gradually getting my work life back into some sort of order so (hopefully) time for my blog will again be available.

The 7 day weekend

2006-11-27T17:20:00.000+00:00

Following on from the APLN Leadership Summit and the Agile Business Conference in London (see my previous post) with their sessions on agile leadership and more specifically an open work environment, I've started to read Ricardo Semler's The Seven-day Weekend: A Better Way to Work in the 21st Century (Paperback) which describes the approach he has taken to managing his company, Semco.

It's a fascinating read, if at times a bit rambling, and it's early days yet but I'm finding it helpful in provoking alternative ways of seeing and hopefully fostering a more collaborative work environment.

I'll keep you posted!

Agile Yorkshire

2006-11-17T11:26:00.000+00:00

I'm excited: it seems that an interest in agile has finally reached Yorkshire.

I tried to start an AgileYorkshire group a year or so ago, but at the time there seemed to be relatively few people in the area with a similar interest (this, I think, might be partially explained by the size of Yorkshire and the difficulty to identify a sensible location to meet).

Given that Kevin Rutherford had established an active group just across the pennines I let the idea of Agile Yorkshire fade away and instead made the occasional commute to Warrington.

However, with many thanks to Keith Stirling who has kick started things again, I'm pleased to report that an Agile Yorkshire group is looking much more likely. So if you are based in Yorkshire and would like to help establish or simply participate in a local agile group please join the yahoo group.

Agility for me

2006-11-11T10:53:00.000+00:00

I though it was timely to state (my first draft of) what, for me, is being 'agile':

Agile =

the constant application of a set of values and principles
to a specific situation
to guide the choice and use of appropriate practices
that enable people
to deliver sustained business value

The set of values and principles you choose should conform to the spirit of the Manifesto for Agile Software Development, but I do not believe this must be followed exactly.

I've said this is my first draft because I don't feel it yet sufficiently captures the constant review and adaption that I believe agility values (and needs), nor the two way interaction with the environment (both to respond to change and to create change for useful advantage). One thought is to change the last line so it reads

to deliver sustained business advantage

Which works better for me in a business context, but seems to break down if applied to non-business contexts.

Perhaps another way to state this might be to consider the value / advantage provided to beneficiaries further up the value chain and use the assumption that if our customers gain something we must gain something. So we might change the last line to:

to deliver sustained customer advantage

But I'd be interested in hearing your thoughts.

Agile Business Conference take aways

2006-11-11T08:50:00.000+00:00

I've spent the last few days attending the APLN Leadership Summit and the Agile Business Conference in London. I enjoyed both events immensely and as ever discovered many new ideas to take away and try.

Having attended the ABC since its inception a few years ago together with a number of other agile related conferences in both the UK and elsewhere over many years, it was interesting to see how the emphasis of year's conference had changed. 'Agile' is clearly entering the mainstream and this brings both great opportunity as well as carrying a huge risk of becoming another over-hyped, mis-sold and poorly understood 'next greatest thing'.

Sean Hanly's keynote probably articulated this the most powerfully but it was a theme running through many sessions (including my own) and a subject of the many conversations I had with other attendees. This level of attention given by so many practitioners was great to see and hear, and I hope that this can be sustained long into the future.

So what else did I take away from the conference? Here's a rough list (not in any order):

The idea of an open environment (see http://www.collaborative-leadership.com/)
Describe a system in no more than 5 boxes
Select team members on: (first) Integrity, authenticity, attitide, intelligence, talent (last)
Reverse pricing contracts
During start of transisition to agile: coach must apply values on behalf of team (ie guide selection of practices). Over time coach must ensure team adopts the values so that they can select / adapt / innovate appropriate practices themselves.
The idea of Strategic Intent, Strategy, and Purpose to guide prioritisation
Scott Ambler's health warning slide
Talk in terms of "Intents"rather than "Requirements"
Use seasons as a metaphor for the UP phases (largely the same activities throughout the year but we tackle each activity differently in, for example, summer vs winter)
Role is not equal to Position (many people able to play in a role, and constant movement in and out of roles)
Change is not the biggest challenge; it is choice
Know what you are: Passionate about; Best at; and Value. Do these match your organisation, team, job?
Appreciative inquiry vs problem solving
The lifecycle of a 'silver bullet'
Understanding the spirit of the values and principles
The collaborative focused contract used by BAA for the Heathrow T5 project

Books mentioned at the conferences that I want to take a further look at:

The Seven-day Weekend: A Better Way to Work in the 21st Centuryby Ricardo Semler
Organizing Genius: The Secrets of Creative Collaboration by Warren G Bennis
Leadership Is an Art by Max DePree
Good to Great by Jim Collins
Agility and Discipline Made Easy: Practices from Openup and RUP by Bruce MacIsaac
The Naked Leader Experience by David Taylor

Where to start?

2006-11-01T10:46:00.000+00:00

I started a new engagement this week. I can't go into too many details but to set some context I can say the team is fairly small consisting of 7 developers, nearly half of which have been with the company for less than 3 months; they are part of a company that has grown rapidly in the last few years; and they are under a lot of pressure to perform.

I know very little about the team and the pressures they face so I've decided to start this engagement by simply sitting in their development room and absorbing the day-to-day flow of work, the team's dynamics and their relationship with others in the company. I'm hoping that as well as getting to know them a little better as individuals I'll also get a sense of how it feels to be a developer here and this should help guide me in the most appropriate way to proceed.

I think this is the 'best' way for this team, and the approach seems to properly value individuals and interactions over processes and tools, but I'd be interested to hear how others decide where and how they start their new engagements.

Learning

2006-10-31T08:43:00.000+00:00

Richard Banks has written a useful stock take on the progress his organisation has made to introduce scrum. It's always useful to be able to point those just begining their agile journey to such success stories.

This one is particularly useful though since it's a follow up to an earlier story by Richard which described his reflections on how NOT to implement scrum!

So failures are only failures if you don't learn from them; and learning is something that Richard has clearly done

Pair Working

2006-10-30T17:18:00.000+00:00

Myself and a colleague are presenting at the Agile Business Conference in London next week and today we've been fleshing out the detail of our session i.e. writing it!

Although I'm not part of the development team, pairing has become so embedded in our development culture we found ourselves writing our session session this way too. We spent a hour or so before hand sketching ideas on a whiteboard, exploring ideas and creating a high level 'picture' of what message we wanted to get across. It certainly wasn't a detailed design, but it was just enough for us to move on to writing some first few slides.

As we wrote the presentation we constantly swapped who had the keyboard and mouse; as one of us started to struggle, the other invariably was able to step in. We occasionally referred back to our whiteboard sketch to check we were heading broadly in the right direction. But we let the presentations design emerge. It was interesting that as we progressed many of the earlier slides either were deleted are were changed; we needed them to get us started, but then refactored them as the overall presentation was built.

At the end we arrived at (what we believe to be) a good presentation and crucially both of us have established a solid shared understanding of the message we are trying to convey. Neither of us believe we could have achieved the same result so effectively if we had worked separately.

Of course the real test will be the audience's reaction... if only we could have had access to our 'customers' as we developed the session.

On Site Customer?

2006-10-29T15:16:00.000+00:00

Customer collaboration is a core value of the Manifesto for Agile Software Development, and two of the Principles behind the Agile Manifesto further support this:

Business people and developers must work together daily throughout the project, and

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Possibly as a result of Kent Beck's book Extreme Programming Explained (1st Edition) most conversations I hear about customer involvement in projects appear to centre around how to get an "onsite customer"; and on-site is always described as where the development team works.

But what about other options, perhaps striving for an onsite development team instead; i.e. moving the development team to where the customer works - which in many circumstances would probably be a lot more successful.

So the morale of this story: don't slavishly follow a practice without understanding why you should be doing it, and what would make the most sense in your specific context.

Simplicity

2006-10-29T10:52:00.000+00:00

This is my first blog post and I'm rather excited by the idea. I hope to use my blog to share my thoughts and experiences of helping others become more effective by becoming more 'agile' in their work.

I hope to draw on experiences of the teams I'm working with, but I won't generally reveal details about specific projects or individuals.

I called the title of this first post Simplicity because it's a principle that lies at the heart of many agile practices and one which I think is critically important. Simplicity is cited in the 'Principles behind the Agile Manifesto' which states:

"Simplicity - the art of maximising the amount of work not done - is essential"

Which sounds good, but what does it really mean?

You often hear this principle translated into a couple of catch phrases (which have their roots in eXtreme programming): "You Ain't Gonna Need It" (or YAGNI), and "Do the simplest thing that could possible work".

YAGNI is designed to keep the system you are developing focused on fulfilling the current business need and no more. As discussed on Ward Cunningham's wiki, when a feature or User Story is being implemented, the aim is to:

"Always implement things when you actually need them, never when you just foresee that you need them." Even if you're totally, totally, totally sure that you'll need a feature later on, don't implement it now. Usually, it'll turn out either a) you don't need it after all, or b) what you actually need is quite different from what you foresaw needing earlier.

This doesn't mean you should avoid building flexibility into your code. It means you shouldn't overengineer something based on what you think you might need later on.

"Do the simplest thing that could possible work", is a useful mantra when faced with apparent complexity and a myriad of options. Always select the simplest one first, implement it and get feedback quickly to decide whether you need to stop, extend or adapt. Recognise that what's important is: to deliver something, and to learn from what you deliver.

Try using these two catches phrases in everything you do, and see agility in action!