I thought of that while riding my bike

Three Simple Truths

2012-02-27T09:27:00.000Z

I was reading a recent blog from the Agile Warrior about 10 ways to better lead your agile team; I've read the Agile Samurai and it has some really useful ideas. For example, we use the Inception Deck format for our project brief for ideas that move through our product development process from inception to starting development.

One of the points in his blog really struck a chord with me. We're lucky at On the Beach in that our "customers" at OTB - mainly the CEO and Chief Marketing Officer - "get" Agile and work closely with us during product development and iterations. They make the time to attend User Story workshops, take a full part in mini-demos and Sprint Reviews and come up with some great new ideas and enhancements. The trouble is in the past we tried to meet all their changes as we could see the clear business value, but we just didn't have the time as we needed to move on to start delivering the next feature. We've countered this by continuing to gather the changes in new User Stories and getting the Product Owner to prioritise these; sometimes we run another Sprint (if the CEO agrees to extend the roadmap), sometimes they're handed over to a small support team to pick off over time as minor enhancements.

So when I read about the The Three Simple Truths in Agile Warrior's blog it really struck a chord:

Many thanks Agile Warrior - keep the great articles coming.

Agile Development Teams - Workspace Resonance

2012-02-21T09:06:00.001Z

Almost 10 months ago I wrote about how at On the Beach Holidays we were re-arranging the development team workspace to improve collaboration and make it a better place to be. Some of the benefits were immediately obvious: better pairing, more ad-hoc discussions. But over time the team have outgrown the available real estate. Also, as tends to happen, we have a number of glory holes and untidy corners, full of stuff that nobody needs but hasn't been disposed of. Some areas are cramped and noisy and this is affecting our people, so we need to do something about it.

We recognised that a good working environment will only help improve team morale, retention and productivity, so the Senior Developers set in train some research and team discussions during our fortnightly "Google time" to look at how we could rework our working space for the better. No ideas were off the agenda and even the most radical suggestions have been taken. We now have an idea of what we need and our CTO, in his usual style, successfully argued for a substantial budget to allow these improvements to be made.

Now we reach the interesting point of delivering on the promises made to the team; it's their space and they should decide what's needed. Over the next few days we'll pull together all ideas, identify constraints and risks and put together a plan; no doubt we'll drop another project into Agile Zen and manage it the same way we manage all of our projects. This is an exciting time in OTB as we'll also be growing our development team and offering an exciting, innovative and modern working environment will be a key selling point to attract the best Ruby developers in the North West to join our merry band.

I'll update over the next few weeks as our crowded and traditional workspace morphs into something much more suitable to agile development teams working in a fast-moving, ever-changing online travel agents.

Agile Cambridge 2011

2011-10-03T14:53:00.000+01:00

I attended the Agile Cambridge conference last week; although it was held over 2 days I only went to the first day, as the majority of speakers who I personally felt could add value to my learning were on Day One. Firstly, it's worth saying that the conference was very well organised, with a slick programme and no over-run, not easy to achieve.

The Key Speaker was David Anderson, one of the leading Kanban experts and author of an excellent introductory book about Kanban . The programme then broke out into a series of concurrent sessions. I had already chosen those I wanted to attend:

The first was Why Continuous Improvement Programs Fail – Can Kaizen and WIP Help? by Michael Depaoli, an Agile Coach with Version One. What could have been a Version One hard sell actually turned out to be an extremely informative session on how some process improvement interventions fail and how Kaizen and WIP can help address this. From all the sessions, this one gave me the most food for thought and many ideas for continuous improvement at OTB. Michael's take on the impact of small change on teams and stakeholders (and indeed anyone wanting to make changes in their life) was inspiring; he recommended a book: One Small Step Can Change Your Life: The Kaizen Way - definitely on my reading list.

The first session after lunch was The role of an Agile Coach, led by Rachel Davies. This was an interactive workshop and, following on from reading her book on Agile Coaching, the main learning point for me was that the Agile Coach's role very much depends on the agile maturity of the organisation and the teams; in the early days the Coach is more like a teacher and this gradually changes to a mentor as the organisation learns and grows. I look forward to hearing Rachel speak at Magrails 2011 next week.

My final session was an Introduction to Value Stream Mapping by Marc Evers and Willem Van Den Ende. I was looking forward to this as I plan to run our processes at OTB through VSM in order to identify and reduce waste. Unfortunately, time constraints meant this session was a bit rushed but I plan to learn more about this in the near future.

Overall, I enjoyed Agile Cambridge; it was good to meet others with similar interests. The location at Churchill College was excellent and I would certainly attend again.

What's in a Nickname?

2011-09-25T09:28:00.003+01:00

We all work in environments where job roles have names or nicknames that reflect what they do. I currently work in the world of Devs, DBAs, BA, Creatives and so on. This set me thinking about the history of some of the nicknames that I've held in the past.

I spent nearly 28 years of my working life in the Royal Navy, a career that I loved and made me what I am today. I originally joined as a Writer, responsible for pay, cash, service records and career management. The nickname for a Writer is Scribes (or Scribbler). The term Scribe originally referred to a person who wrote books or documents by hand as a profession and helped the town or city keep track of its records. In the early days of the Royal Navy everything was recorded by hand and, in fact, the Service Certificate, which recorded in ink a Sailor's career, drafts (postings), promotions and awards on an Irish Linen parchment, was only discontinued a few years ago as the inevitable computerisation replaced it.

All Scribes are eligible to join the The Royal Naval Writers’ Association. This is officially the oldest military association in the world, having been founded on 5 December 1887 as a Club and Benevolent Association for members of the profession. As with the profession itself, eligibility for membership is highly restrictive and the Association is only open to serving and ex-serving members of the Writer Branch within the Royal Navy, and as such it is also one of the most exclusive organisations in the world.

When I was commissioned I then became a Supply Officer (now known as a Logistics Officer). This brings a whole new list of nicknames - my next one was Scratch or The Scratcher. This is naval slang for the Secretary - normally Captain's but occasionally the Admiral's - and is derived from the sound of the Secretary's quill scratching the parchment as he wrote. As Secretary to the Captain Fifth Destroyer Squadron in HMS CARDIFF, the Captain always referred to me as Scratch and would occasionally shout it from his cabin desk when he wanted to attract my attention (my cabin was next to his!). The most famous (and probably the first) Scratch was Samuel Pepys. He was a naval administrator and MP who is now famous for the diaries he kept. Pepys rose through hard work and his talent for administration to be the Chief Secretary to the Admiralty, under both King Charles II and subsequently King James II.

I'm also honoured to be a member of "The Scratch Club", which is only open to currently serving and ex-Logistics Officers who have held the appointment of Captain's or Admiral's Secretary.

My next nickname was Pusser (some Captains might also refer to me as The Grocer). Pusser is the inevitable corruption of Purser or Paymaster and the nickname Pusser is generally used when a Logistics Officer is in "supply charge" of a warship. The Pusser has a multiple role, covering the disciplines of payroll, finance, personnel, supply chain management, warehousing and hotel & catering services. Now the Pusser is also responsible for medical services (the administration of, not the delivery!). The Pusser is also the Command Legal Adviser, covering both International Law of the Sea and maritime criminal law in a role similar to the Crown Prosecutor (for dealing with miscreant sailors!). The pinnacle of my naval career was to be Pusser of a Type 23 Frigate, an appointment I was very proud to hold.

The Pusser also heads up the "White Mafia" - originally the Supply & Secretariat Branch - now referred to as the Logistics Branch. The White Mafia are the fixers, movers and shakers of the RN - if you needed anything then see someone in the White Mafia. They could make life difficult for you if you annoyed them (as they controlled your pay, leave records, food, stores, clothing etc) hence the term "Don't upset the White Mafia".

I'm certainly proud to have held these nicknames with such rich history behind them and will retain my links with organisations such as the RN Writers' Association and the Scratch Club.

Kanban Classes of Service - Limited WIP Society Manchester Meet Up

2011-09-22T10:30:00.000+01:00

Last night I attended my first Manchester Limited WIP Society Meetup. It was good to meet similar minded people and put some faces to names - I look forward to attending more events.

The guest speaker was Mike Burrows who gave a talk on "Classes of Services Made Easy". Mike has led development teams and larger IT functions for much of his career, working in aerospace, software tools, finance and energy, recently as Executive Director at UBS Investment Bank and then IT Director at the energy risk management consultancy Encore International where he led one of the first Kanban implementations in Central Europe. He clearly knows his stuff and the presentation was thought provoking and led to some interesting discussions and sharing of war stories. It would be unprofessional to cover the detail of the presentation here, as Mike intends to use it in future training sessions, but it was on similar lines to a blog he wrote on Kanban prioritisation and scheduling classes of service.

Overall, I enjoyed the evening and look forward to learning much more about Kanban and Lean in the future.

Agile Software Development Management using an Electronic Tool

2011-08-19T14:56:00.003+01:00

As the Agile Coach at On the Beach Holidays, I'm always looking for ways to improve our working practices. Sometimes external factors force the issue and recent events meant a re-think on how we visualise and track our projects.

Progress visibility, information radiation and team cooperation is very important. The ideal option is to have a visible Board in whatever form - this allows everyone to see what's being worked on and how we're progressing. When we first implemented Scrum at OTB some 18 months ago we started with physical boards using index cards. Our Live Support team used a Kanban board for managing their tickets. This worked well in our early days as we experimented with our agile implementation. During Stand Ups team members would move tickets and update effort remaining and progress was visible to all.

Over the next few months our teams grew quickly but our real estate didn't expand as fast - wall space was at a premium. Then the dividing glass wall you can see in the image above was removed (which held 4 Boards) and so I had to find an alternative (I blogged about the wall coming down). We also had a few guys working the occasional day from home (part of OTB's flexible working ethos) so they also needed remote visibility.

So I started to evaluate electronic solutions and finally settled on Agile Zen (there are lots out there and I'm not on commission, but Agile Zen met our particular needs). Whichever one we chose it was important that we still had a physical focal point, a campfire around which we gathered each day for our Stand Up. To achieve this we use a large flat screen monitor - this is used by all teams for their Stand Ups. This works well for us and reinforces the daily get together so the team can update each other on progress.

With the loss of wall space we also needed to increase whiteboard space. We already have a couple of fixed boards and one large mobile board but I want to buy a small mobile whiteboard for each team.

Agile Zen allows us to create bespoke Scrum and Kanban Boards depending on the team's requirements. We create a separate "project" for each feature or stream and then invite users; Agile Zen allows us to create unique user roles with differing permissions. User Stories are captured in Agile Zen which provides visibility to all and then "dragged and dropped" in to priority order. We continue to estimate each of the Stories - Epics & Themes are t-shirt sized (Small, Medium, Large) and Stories estimated in Story Points (we prefer ideal Developer Days).   The team break each one down into separate Stories if required, or use the Task Management feature in the Story to add list of tasks. We don't use the Priority field in Agile Zen Stories, but I'd like to use this to hold a Business Value score from the Product Owner; this will allow me to measure the delivery of Business Value over time (burn-up). It'll also help us to prioritise Stories based on delivering the highest Business Value first.

We make full use of the comments and attachments features for a Story so that all information is in one place and available to all. We also use the "Ready to Pull" status which provides a visual indicator to those downstream that a Story is ready to be pulled into the next column (eg developed and ready for internal testing) - this status is important for providing accurate metrics. One feature I really like with Agile Zen is the tagging and ability to filter the Board and Metrics to provide clearer performance MI. The team are collectively responsible for picking up and progressing a Story through the Board and it's very clear who owns each ticket by the gravatar icon displayed on each Story.

As our agile implementation moved from Scrum towards continuous delivery using Kanban, metrics and progress monitoring also needed to change; I provide input to our CTO's monthly brief at the Executive Board and we've been focusing on building more meaningful and smart KPIs. These KPIs also provide the information I need to spot areas for improvement at a tactical level. Previously we measured Team Velocity as a percentage of Stories committed to versus delivered during Sprints, but as we've moved away from fixed iterations to a more continuous delivery flow, these old metrics have become less meaningful. Agile Zen provides some pretty good metrics which are starting to provide the evidence I need to target bottlenecks and other problem areas for improvement. These include:

Throughput (how many Stories have been deployed to Production) - whilst this doesn't automatically measure team velocity (or Business Value) this can easily be derived if these are held on the Story.

    •    Lead Time (the average time a Story took from joining the Product Backlog to Production)

    •    Cycle Time (the average time a Story took from In Progress to Production)

    •    Work Time (the average time a Story was on the board and not either Ready to Pull or Blocked)

    •    Wait Time (the average time a Story was marked as Ready to Pull) - this is waste and should be reduced

    •    Blocked Time (the average time a Story was blocked and therefore unable to be worked on) - again wasted time to reduce

    •    Efficiency (the average time a Story was being worked on and not idle, shown as a percentage) - we aim to drive this upward

    •    The Cumulative Flow Diagram helps me identify and remove bottlenecks

I'm also looking at using average Lead & Cycle Time to develop SLAs for the Live Support team when dealing with different Classes of ticket. The nice thing about the Agile Zen metrics is that I can slice and dice them to fit my needs, including date ranging and filtering.

Whilst my preference would be to have physical Boards with index cards (and I would definitely recommend that teams new to agile should use a physical board), Agile Zen is pretty close to replicating this. Office space constraints meant I had to find a way to continue to visualise and radiate information but the positive fall-out from this includes:

    •    Better metrics and progress monitoring

    •    Use of colour and filtering to provide visual indicators

    •    Scalability - I can add infinite projects and team members without the need for additional wall space

    •    Remote access to those off-site.

It's early days and we continue to learn how best to manage our work, but Agile Zen is one tool that's helping and we now have 11 workstreams in progress, ranging from our high-level Product Development Roadmap, down to individual bug tracking. I still have some ideas for improvements, these include:

    •    Still using physical wall space for radiating issues, impediments and post- Retrospective improvements.

    •    Researching Agile Zen's API to find a neater way of exporting all this data into a form that can easily inform our Executive Board Dashboard report.

    •    Keep looking for those little nudges on the tiller to improve how we work.

    •    Getting a Costa Coffee machine for the Dev team (hoping the CTO is reading this……)

Anyone else have experience of using electronic agile management tools? And Agile Zen - if you're reading this - an iPhone app that syncs with our Boards would definitely be top of my Christmas present list!

Delivering Business Value Incrementally

2011-05-06T09:32:00.000+01:00

My team has recently delivered some key feature enhancements to our website. These have been on the Product Backlog for over 3 years but recently bubbled to the surface due to customer feedback and the plan to increase conversion. At first the Product Owner wanted everything done but we discussed delivering each feature incrementally. It was good this was agreed as, within 12 hours of deploying the first feature to the live site, conversion had dropped and so a commercial decision was made to switch if off.

Because we had developed and shipped incrementally this was easy to do and caused little pain. However, had we waited until all the features were built before shipping, then the lessons learned would have taken longer and been harder to back out. As it is, some minor changes to the feature to increase business value have now been made and this will be switched back on next week.

Delivering business value in small increments is certainly adding value. The impact of change is reduced, it's easy to back out and easy to re-ship after making changes. It means the business (and our teams) can learn the lessons from this early delivery and apply these to further feature development. It also means that the development team's morale isn't hit by spending months building features, only to see them pulled within a day of going live because they don't deliver the value the business expected to when they first thought of the idea.

Since introducing Scrum just over a year ago to manage a large roadmap of monolithic projects, we're now (finally!) moving towards feature driven continuous development based on Kanban - the good thing is that the business have seen the value of this through some stealth projects we ran, so we're pushing at an open door. The next few months should be exciting as we move to a more lean method of continuous delivery.

Team cohesion brings success

2011-04-21T14:05:00.000+01:00

I've been working with a team over the past few weeks who've been responsible for implementing a number of key features on our website. I've observed them come together and seen their throughput and quality increase at every iteration. They've shipped a number of features that are making a real difference to conversion and margin. It's been fun and we need to bottle their secret and share its essence.

So what's been different:

They've worked closely with the Product Owner to capture and understand all the requirements.
They've made the most of pair programming, utilising pomodoro.
The tester has worked upstream to ensure his scenarios and scripts are covered in the Developers' unit tests.
They've held daily demos with the Product Owner, not just at the end of each Sprint.
They've adjusted the Task Board to suit their way of working.
They've taken team ownership of all issues and bugs and swarmed to clear them.
They've conducted orchestrated UAT through a workshop and pairing with the Product Owner.
They've shipped quality features, on time, that deliver high business value.

This team cohesion has been very successful and we now need to share the lessons through the Retrospective.

Good Workspace Vibrations

2011-04-11T15:12:00.000+01:00

I was recently reading Rachel Davies' blog and came across an article about building an Agile Environment. I also took at look at her photos from Agile Cambridge which covered a similar theme. This revolved around her favourite Agile Manifesto principle: "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." These struck a chord with the workspace we inherited at On the Beach as the Development team grew. From Rachel's photos the following lists describe Workspace Hell & Heaven:

Workspace Hell:
Separation from rest of team/company
Temperature
Uncontrolled demand
Disconnected management
Noise - silent or too loud
No coffee!
Walls between people
Old hardware
Dead plants
Loud meetings/people
Hot desks - not enough
View of wall/carpark
Moving goalposts
Lack of communication
Smelly feet (you know who you are!)

Workspace Heaven:
Separate meeting rooms
Live plants
Decent coffee - free
Nice view
Team board/Burndown
Open & free communication
Space
Opportunity
Pleasant environment
Fixed goalposts
Supported by customers
Re-configurable space
Chill-out area - social space
Climate control
Own space
Artwork
Modern technology & tools
Collaborative workspace/furniture
Cafeteria
Quiet areas
Management communicate
Balance to workload
Windows
Whiteboards
Team identity
Success metrics
Shared areas with other teams
Unique space

Here at On the Beach, over the past year the Development team have grown from four living in a broom cupboard to a team of about 30, taking up a large section of the ground floor. With 5 teams, the logistics of sitting everyone together in a decent working environment, whilst keeping noise levels to a sensible level have been challenging. We're extremely lucky in that we already sit alongside our customers and there are very few communications barriers. However, we inherited a workspace which included a corner of the building separated off from the rest of the world by a glass wall. This created an artificial barrier to communications, collaboration and knowledge sharing.

So we decided to remove the wall last weekend and see what happens. We arrived in work this morning to find:

It's early days but I've already noticed the following:

Pros:
Cooler, particularly in the area that was walled in.
Team members are spending more time walking over to desks to chat about work stuff.
The workspace is much more open and brighter.
Teams are already excited about the desk layout change that will see them all sitting much closer together.
We naturally overhear conversations and learn more about what's going on.

Cons:
Noise levels have increased (but many of the Devs are plugged in to headphones to help them "zone in").
We've lost the majority of our wall space that held our Scrum & Kanban boards; we're looking at other ways of building these information radiators including mobile whiteboards.

Overall, I think losing the wall is a good thing and is already breaking down barriers between the "Insiders" (those inside the wall) and "Outsiders". Once we move the desks around to sit the teams closer together I'm convinced we'll see a much improved working environment.

One significant concern, however, is our CTO is now seeing his empire grow and is starting to think like a James Bond villain, including where he can place his throne to oversee his domain:

Adapting the Scrum Board

2011-03-11T15:49:00.000Z

Over the past few Sprints I've been letting the team play around with the Scrum Board. Following a Retrospective we headed back to the team space and reviewed the wall. They decided to try a couple of new ideas:

Rather then breaking a Story down into individual Tasks during Sprint Planning they decided to only do this once a Story was ready to be started during the Sprint. At this point the whole team would stop and huddle at the Board to spend a few minutes breaking the Story down into Tasks and estimating each one. They wanted to try this as they found that doing this later meant they knew more about the feature and therefore their breakdown and estimating was more accurate. This has worked well so far, so long as they remember to stop and breakdown the Story, but we soon catch anyone out at the Daily Stand Up (the Board never lies!).

They also decided that any Stories not started should still be on the Board but stuck at the bottom of the Board, still in priority order running left to right. This meant that only those Stories in progress appeared in the main Board area. They found this helped reduce clutter on the Board and helped them focus on only those Stories and Tasks they were currently working on. Again this seems to be working well as the Board is far less cluttered, particularly in the early days of the Sprint.

We had Sprint Planning this morning and the Stories are now up on the Board - this is how it looks at the start of the Sprint. We're short of space so every wall area is now in use for the various Scrum teams. I'm pleased that the Team came up with these ideas and took the time to self-organise, discuss the issues and come up with workable solution. We'll run this for another couple of Sprints then look to share this with the rest of the teams.

Murder at the Scrum Board

2011-02-07T09:43:00.000Z

We've recently found our Scrum Board becoming a bit stale so on Friday the team had a chat about how we can liven it up. During a visit by Kevin Rutherford, he talked about the Murder Board, where the UI wireframes are the main hub (the victim!) and all other information branches off this - such as Story cards, burndown chart, impediments and other notes.

So we're going to try this for a while and see what happens.

2010 Personal Retrospective

2010-12-29T16:32:00.000Z

It's been a really busy and life-changing year. It's now nearly 4 years since I left the (relative) safety of the Royal Navy. I was told by others that had made the leap that most ex-Service personnel only stay in their first job outside for a few months, as it takes a while to understand what you really want to do - how true. With a background in traditional waterfall, PRINCE2 project & programme management, I initially took another role in the public sector. However, with more time at home (ie not at sea!) to research, learn and reflect, the growing interest in Agile and Scrum in particular started to steer my new path. I quickly moved to a new job and after a fantastic couple of years with Portfolio Software & Epsilica Consulting (thanks to Mike & Mitul for taking me in), a family reunion triggered a number of changes which I could never have predicted twelve months ago.

Over the past year we:

Decided to move from the south coast of Hampshire to the North West of England.
Put our house on the market and sold it the same day.
Moved to Cheshire (within 8 weeks of bullet one).
Both picked up new jobs within a couple of weeks of moving north.
Bought another house and started to renovate it.
Bought 2 cars and wrote off one.

So it's been a busy 12 months and 2011 will see no let up:

We need to complete the house renovation (funds permitting).
We need to restart our weekly yoga classes (how we've missed Ann our last teacher!)
I need to get out on the road bike more (and the Cheshire Cat in March is a clear training target)
I need to do more fishing.
We both need to take more time to "smell the roses" (the garden renovation will help with that!).

I'm not one for New Year resolutions, but I think it's good to have some idea of what needs to be achieved both professionally and personally.

That's it for this year - Happy New Year and a peaceful, safe and successful 2011 to all my readers.

2010 Work Retrospective

2010-12-29T16:13:00.001Z

It's that time of the year when we look back, think about what we've achieved and what we need to do in the New Year. I'll maybe blog separately on my personal year, but in terms of work:

What's been achieved:

We implemented Scrum & Kanban - early days and still learning.
We built the team from a small group of Developers to four Scrum teams and one Support team using Kanban to manage live issues.
We worked with some great Product Owners to deliver some great customer-facing features.
We started to see the benefits of working in an agile fashion.

What we still need to do:

Improve our automated testing (we're getting there).
Improve our "just in time" User Story & Design work.
Move from project/product based planning to a more feature-based plan - this will allow us to react faster to a changing market & business priorities.
Reduce our technical debt.
Reduce the number of live issues.

We have an exciting and innovative roadmap of new features to add to our website over the coming months and so we'll need to improve our agility, speed of delivery and quality to keep up with the Board's strategic direction of travel - so it's going to be a challenging but very interesting 2011.

Demo. demo, then demo again

2010-12-14T09:35:00.001Z

During our Sprint Retrospectives the subject of customer interaction is always raised in some form. We're very lucky - our Product Owners have bought into our agile processes and are always available to answer our questions or review our work. We run a formal demo on the last day of the Sprint, but we've found that's just not enough. We were finding that, as well as driving out new requirements, the demo was also showing that some of our design & technical assumptions were incorrect. As a result rework and technical debt was increasing. So this Sprint we're pulling in the Product Owner several times a day, albeit in 5 - 10 minute periods, to review our work and provide fast feedback. This constant nudge on the tiller is not only helping to keep us on track, it's already improving quality and also increasing productivity. Furthermore, it's forcing us to really focus on our Definition of Done.

It takes real commitment from the Product Owner and the team to keep this momentum going, but we're already reaping the rewards.

Agile Samurai - worth a read.

2010-12-08T09:38:00.001Z

I've just finished reading Agile Samurai by Jonathan Rasmusson - wearing my Head of Product Development hat, I'm always looking for ways to continuously improve our ways of working. The Agile Samurai is an ideal read for non-technical Agile PMs (me!) and provides some excellent ideas to increase both quality and productivity. We have an excellent relationship with our customers and some really pro-active Product Owners, but we can improve on this, so I really enjoyed the Chapters on the Inception Deck (How to get everyone on the bus) and why we're completing the project (Seeing the Big Picture). I'm certainly going to take on the following immediately:

Include an Elevator Pitch within the Customers' Project Brief and as a lead in to our list of User Stories - this will really help our Agile Developers understand why they are building the feature and keep them focused on delivering business value.

Meet Your Neighbours - we have constant interaction with our Product Owner, but I want the Dev Team to go and socialise with the end users (mainly marketing or call centre staff) to really understand their needs and how this new feature will improve their lives (we'll provide the doughnuts!).

I'll certainly be using some of the Agile Samurai ideas to drive improvement and strongly recommend all Agile PMs, Teams and Product Owners to read this book, which is ideally suited in particular to those with a non-technical background.

Agile Software Development – Applying Rhythm to the Battle

2010-07-03T22:09:00.002+01:00

I spent many years in the military and, as well as my involvement in business change, software development and project management, I also specialised as a Logistician. Within the military, and particularly in Operational Logistics, there's a term called "Battle Rhythm". In military terms, it's used to describe a mechanism for both managing and maintaining synchronized activity. Battle Rhythm management is used by the military because of its capacity to cope with rapidly changing and/or highly distributed operations; in essence it provides a mechanism to focus staff on providing the commander with the right information in the right format at the right time, so aiding his decision-making.

I think Agile methods have some similarity with the military's use of Battle Rhythm. For example, one definition of a military Joint Battle Rhythm is: "The timing and scheduled presentation of situation reports, briefings, formal collaborative sessions, and other required actions during planning and execution." That's sounds a whole lot like the empirical management processes used in Scrum, such as the Sprint Planning meeting.

Let's take this down one level; again using a military definition, the Tactical Battle Rhythm could be defined as being: "The process where the commander and his staff synchronize the daily operating tempo with the planning, decision, execution and assessment cycle to allow the commander to make timely decisions." Sounds pretty much like the Daily Scrum meeting doesn't it - a synchronised meeting that allows daily updates in order to continually re-plan and make decisions affecting the next 24 hours.

So why's a Battle Rhythm so important when using an Agile method such as Scrum? Well, it provides consistency and some order in what is usually a pretty (let's be honest!) chaotic period during the Sprint; the team know when the Daily Scrum will take place, how long for and who will attend; they know the Scrum Master will take ownership of any impediments and aim to resolve them as quickly as possible. Also, by introducing a "Battle Rhythm", the daily process of situation reports and re-planning allows the best use to be made of available resource, reducing the possibility of periods of stretch and slack. Furthermore, a "Battle Rhythm" process also works extremely well if you have a distributed team, as we do. It's an ideal way of introducing discipline in your management, planning and reporting processes when you can't meet with your team face-to-face.

Ryan Martens of Rally Software talks about Flexibility and Rhythm as one of the Top 10 Characteristics of an Agile Organisation - worth watching.

I thought of that while riding my bike

2009-05-29T22:07:00.001+01:00

"I thought of that while riding my bike" - so said Albert Einstein when asked about the theory of relativity. How many of us have "thought of that while riding my bike"?
All too often - in these days of crunchy deadlines and in a world that never sleeps, where someone on the other side of the world wants an instant answer, even though it's 3am where you are - we don't get the time to "think of something while riding our bike". Sometimes we need to crack a problem or issue, or come up with a new idea or product and the creative juices just don't flow. We lock ourselves away in a room with no windows, with artificial light, a blank piece of paper and a bright whiteboard and we try to come up with the solutions and ideas. It doesn't work, does it? Rather than the lightbulb above our head glowing, our brains switch to neutral and the ideas grind to a halt - or at least that's how it is for me.

Maybe we should do something different to spark the creativity - go for a walk, swim in the sea, watch the clouds, go ride our bike..... I'm a keen road cyclist and on a long spin, once I'm into my cadence rhythm, I find my mind becomes clearer; I'm able to think things through, come up with a plan, assess the strengths and weaknesses, threats and opportunities. The solitude helps me think. I'd struggle to do this in a plain room, with a plain whiteboard. And Albert Einstein and myself are not the only ones to share this common love of cycling to clear our heads:

"When you ride a bike and you get your heart rate up and you're out, after 30-40 minutes your mind tends to expand, it tends to relax" - President George W Bush - May 2004

"[Cycling is] an absolutely essential part of my day. It's mind-clearing, invigorating. I get to go out and pedal through the countryside in the early morning hours, and see life come back and rejuvenate every day as the sun is coming out" - James L Jones, former US Supreme Allied Commander Europe and now Barack Obama's National Security Advisor

"One of the things that I wound up loving about being involved with a bike racer was learning how to bike and how that really creates solitary time for you to reflect on things and nobody can get hold of you" - Sheryl Crow, talking about her time with Lance Armstrong - cyclingnews.com, 13 July 2005

And, finally, to bring this back to the beginning: "Life is like riding a bicycle - in order to keep your balance, you must keep moving" - Albert Einstein

Cycle ride anyone?

Meetings – Stand Up and be Counted

2009-05-17T22:06:00.001+01:00

What's your take on meetings? Absolutely necessary, OK so long as you don't have to contribute (!) or a complete waste of time?

Some organisations revolve around meetings - meetings all day, every day. Lots of attendees sat around the table, sharpening their pencils, drinking the Fairtrade coffee, eating the biscuits and avoiding the eye of the chair-person just in case they have to say anything or (horror) win an action. Other organisations have no meetings - not allowed, forbidden.

I sit closer to the latter field, but sort of on the fence, with a foot draped over into the former field. We sometimes need meetings to make decisions and resolve problems but, unless some decisions are made, or actions defined, the meeting is a pointless waste of time. I once worked in an organisation that ran on meetings - everyone spent the majority of their day sitting in 3 hour meetings. I went to one of them once as I'd been invited so assumed I had a part to play. Wrong - like many others sat there, I was invited "just in case". I sat and sharpened my pencils to sawdust, drank one coffee, counted the number of windows in the office building opposite (sad, I know, but I like numbers) and listened to the noise of nothing being achieved. No decisions, no actions, no point. And these types of meetings went on all day, every day. I tried to arrange to have a chat (not a meeting!) with someone in the organisation once. I checked their Outlook Calendar and she was fully booked-out in meetings for 3 months in advance. I tried to call her to arrange the chat but her voicemail told me she was in meetings, so I emailed. I had a response a week later ("sorry for the delay - I've been in meetings") asking me to book a meeting with her in Outlook - I left the job before the first available slot came up!

Then I worked in another organisation that was much leaner, where individuals were empowered to make decisions, where money was spent on supporting the front-line, not buying Freetrade coffee and biscuits. I knew the Boss well; I had worked for him twice before already. He hated meetings; I remember him telling me once that when he arrived in a new job he was invited to many meetings. He didn't attend any - he figured that if he was missed someone would call him up to find out why he wasn't there or at least send him an Action List afterwards - very few did. His idea of a meeting was a weekly "catch up", with a coffee (not Freetrade - you had to take your own). Only those who had something to say needed to attend and we all stood up - no chairs, no tables, no pencil sharpeners. We each had 2 minutes to provide our update and get our points across; so you had to be brief but really think about what were the most important messages to get across. Finally the Boss would say his piece and round up. This took 15 minutes, no problem solving allowed; all this took place after the meeting, in fact it normally happened straight after the meeting as we socialised.

My Boss was a very experienced Director who cut his teeth on traditional Project Management methods. But his management style was anything but traditional; although I would bet he knew little about Agile methods, he instinctively embraced the sort of Stand Up meeting that Scrum encourages. We wasted little time in meetings but we knew that if we were there, our input was important and we therefore expected to play a part and say our piece. In our company, we use a variety of Project Management methods but when it comes to meetings, Agile wins over traditional. Meetings are important and necessary, but they're informal, we stand up and walk around and we scribble on the whiteboard. We make decisions or throw Actions at each other and follow them up. They are short, sharp and to the point. I accept that, in a Micro ISV, this is easy to implement but why not in bigger organisations? Why not dispense with the huge "round table" meetings and hold smaller, shorter Scrum-like Stand Up meetings. Think how much more effective working time you would have; if each employee could spend even 10 minutes less in meetings every day and use that time on higher value business tasks, think how you could achieve more, quicker?

So next time you're sat in a meeting and you're not sure why you're there, perhaps you should just get up and leave and make better use of the time. PS - Anyone need a redundant pencil sharpener?

The Sprint Burndown Chart – Every Picture Tells a Story

2008-12-12T22:04:00.001Z

Those who are regular readers of my blog will know that we use Agile software developments methods and that I'm a complete Scrum convert. You'll also know that our development team are based off-shore, several hours ahead of us, and our client is a few hundred miles north of where I'm typing this.

I've written before about the challenges of making Agile work with a distributed team but that it can be done (and can be fun also!). So today, I thought I would share with you one of our real-time Scrum burndown charts. Why? Well, because I think we can learn a great deal from the burndown chart and every one has it's own story to tell.

So, pull up a chair, warm your hands by the fire, and let me tell you a story. Once upon a time, Scrum team met (virtually of course) to plan the next iteration. They knew which user stories the product owner wanted in this Sprint and so they sat down, listed the tasks needed to build the user stories and estimated in hours how long each one would take. This initial estimate came out at 90 hours. Having already been through a few Sprints, they had a good idea of the team's velocity and reported that this was too much to complete within the normal 2 week iteration. Given the importance of this functionality to the customer, and to maintain momentum leading up to the Christmas period, it was exceptionally agreed to run this sprint for longer than normal.   So applying the team's velocity, it was estimated that they would be done between 15 - 19 December.

All started well and good progress was made, in fact they were ahead of schedule, as you can see from the first few days in the burndown. Then, a few days in, one of the team realised that a further task was needed to complete one of the user stories - so this was documented, estimated and added to the Spring Backlog - Task 06. This increased the estimated hours remaining by a further 16 hours and so the burndown chart tracked north.

Within a couple of days, another unexpected incident occurred. The British Government announced a decrease in the VAT rate - as the system we have built for our client is a sales order processing system, which includes pricing & invoicing calculations, we knew that this statutory change would need to be tackled as a matter of priority. Now, we're a small team (what Agile team isn't) and we quickly realised that all current development work would need to be suspended. So we parked this Sprint and worked through the week and the weekend to successfully deliver the VAT change ready for the implementation date on 1 December. As a result, our burndown chart flat-lined for a week. We therefore realised that this would impact on our estimated delivery date and so started to look at a revised completion window for this Sprint.

However, before we could complete this, the next hurdle appeared in front of us. The developer who had picked up Task 02 realised that it was more complex than we had originally estimated; as a result the effort remaining increased by a further 36 hours, leading to another upward spike on our chart and, of course, further delay in delivering this Sprint. So, again, based on the team's velocity, we re-estimated and come out with a revised completion window of between 29 - 31 December. And that's were we are today, with an estimate of 50 hours of effort remaining.

I can already hear some of you Scrum experts out there shouting at me. Surely we should have time-boxed the iteration and not extended it? When we dropped in new Task 06 we should have possibly looked to the product owner to remove something in compensation in order to deliver within the Sprint? And all this is true - in an ideal Scrum world that's what we would do. But, we know our client well, we have an excellent relationship with them, and we knew how important it was to them to get this functionality in before the New Year. So I bent the Scrum rules to accommodate their needs. Now, before I'm drummed out of the Scrum gang, we shouldn't lose sight of the Scrum values (source: Agile Software Development with Scrum (Ken Schwaber & Mike Beedle):
•    Be willing to commit to a goal.
•    Do your job. Focus all of your efforts and skills on doing the work that you've committed to doing. Don't worry about anything else.
•    Scrum keeps everything about a project visible to everyone.
•    Have the courage to commit, to act, to be open, and to expect respect.

I'll accept that we bent the Iteration rules a little, but it was for good reasons. We faced some unexpected change during the Sprint (which is still ongoing by the way so we're not there yet). But we were open and honest with the client and we were able to use the Sprint Burndown Chart to quickly show the product owner the impact of change and gain their approval to proceed.
More importantly, we stayed in control and retained order in what could have been chaos.

Build what you Must Have, not what you Should Have

2008-11-21T22:02:00.001Z

Working face to face with clients can be fun, but also frustrating at the same time. In particular, how many times have you heard " I need all of these features delivered now". The client is usually unhappy if we tell them that we cannot deliver everything in the first increment, so they need to prioritise. But, unless you control the prioritisation process, you'll just end up with a list of 85% Must Haves, 10% Could & Should Haves and only 5% Won't Haves - this makes it extremely difficult for you to deliver what they need and even harder to manage their expectations.

Most clients know enough about their business to understand which features will provide the highest value, so they have the knowledge and data to allow you to lead them through the prioritisation game.

We take a lead with the initial prioritisation process and, as we move through the development lifecycle, regularly return to the client to reconfirm their priorities. Prioritising these features does take some time and effort but this is always outweighed by the benefits of doing this early.

In The Six Ninjas, we use a tried and tested process to prioritise features. We've based this on Karl Weigers' relative weighting approach, but adapted to meet our needs. If you're still reading this blog, well done - have a gold star. If you're starting to waiver, don't worry, there's not much more. So here's a precis of the steps we take:
•    First we get the client to list all of their features at a reasonably high level. We like User Stories so, if they're happy with this, we'll use this format. The features are first of all listed in the Product Backlog.
•    Now we run through the first pass. Across all the features we'll use MoSCoW, taken from DSDM to identify the "Must Have", "Should Have", "Could Have" and "Won't Have" features. The "Won't Haves" are still listed in the Product Backlog but that's it for now - RIP.
•    Clearly the "Must Have" features will have to be delivered, but there might be quite a few of them, so we'll work with the client to score them 1 to 5 based on business value, with Priority 1's going into the first iterations and Priority 5's following up the rear.
•    Next we'll look at the "Should Haves". We'll work with the client (and involving our development team) to score each feature in terms of benefit, penalty, cost and risk. With some fairly simple formulae we can quickly understand the feature priorities and sort these in order of business value in the Product Backlog.
•    For the "Could Haves" we'll us the same scoring exercise, but at this stage we're looking well over the project lifecycle horizon, so we usually repeat this when we're close to implementing the last of the "Should Haves".

From this process we can help the client document and visualise which features will provide the best business value and therefore derive the order in which they should be implemented.   We then work with them to build the Release Plan and Iteration Plan, allowing them to see a predicted roadmap.

Importantly, this exercise helps the client understand what is the art of the possible. It also gives them control over what's to be implemented and when; for example, by the time we've implemented the majority of the "Should Have" features, they may decide that the remaining features aren't needed, saving them unnecessary costs.

Scrum Sprint Retrospective Retrospective

2008-11-10T22:00:00.001Z

That title makes no sense I hear you say - you're probably right but I was thinking about a recent Sprint retrospective that we held and, so, I suppose this is a retrospective of the retrospective.

We're currently working in Sprints of 2 weeks - that's about 7 days' real development time, as there will always be some distractions, so I like to be realistic about the team's "hands-on keyboard" time. We run at 2 weeks because our client has bought into the potentially shippable product mantra - they like to see new functionality delivered to them every fortnight. This allows them to build a meaningful Release Plan and launch new functionality for their customers on a regular cycle.

So, back to the Retrospective. As you will know if you've visited my Blog before, we use Agile software development methods with an off-shore team. I've already covered the communications issues and our solutions, so you'll know that we use a number of collaborative tools to talk. Anyway (he says crawling backwards out of the rabbit-hole), after a recent, particularly busy Sprint, we held our Retrospective; I facilitated as the Scrum Master and all the team took part. So, what did we learn and what have we done about it?

We already have in place a pretty good Release Management process which adds the necessary formality to release software from the development environment, across into the staging area, and finally into the client's testing and live environment. But one thing we noticed was that we were not always enforcing closed-loop management. In other words, we successfully released the software but were not always aware at what stage it was at after leaving us and reaching the client. The successful uploading to the client's live server is the final part of the process and triggers the release of the next build, so this was important. We therefore tightened this up, including a report in the Daily Scrum to state what was the latest release we had issued, and which release version we understood to be loaded on the client's Live server - if the two were out of sync we could quickly clarify this with the client and prepare the next build to maintain momentum.

We use Sharepoint to record and track bugs and issues. We noticed that, where lots of information (such as scenarios, screen grabs and sample reports) was provided by the bug author, the development team were able to quickly understand the issue and provide a watertight fix (remember our teams are distributed and 5 1/2 hours apart in time). However, where the information was scant, it took longer to understand the problem and provide a solution. So we reminded everyone to include as much detail as possible when recording bugs & issues.

Finally, in relation to testing bug fixes, the development team sometimes found it difficult to replicate the problem. In order to provide a more meaningful test environment, we asked the client to provide a scenario around the issue and also to provide a (non-commercially sensitive) snapshot of their database - this improved our bug-fixing turnaround and is helping us move towards a more robust test environment.

The message here is that open and honest appraisal of the Sprint may offer up areas of continuous improvement. I hold the view that it's better to improve 100 processes by 1% than one process by 100%.

Distributed Agile Teams – Communication, Communication, Communication

2008-10-26T20:54:00.001Z

I recently blogged about managing communications in distributed teams and said I'd provide an example by describing a typical day.

Much has been written about the difficulty of using Agile software development methods in distributed teams. Some thoughts are that the obstacles are so great that Agile can never work; others believe that, whilst communicating is challenging, the other benefits of Agile outweigh these difficulties.

We use Agile methods to manage software development and, personally, I prefer Scrum to many others as a management tool to track progress. With all Agile methods, communication is key and this becomes harder the more geographically distributed the client, team and other stakeholders are, but there are ways around it.
In my case, here’s a prime example. One of our clients is based in the East Midlands of England, their tech lead is based in London (as is my Tech Director), me - the Scrum Master - I’m on the south coast of England and our development team (who also provide support to the live application) are in India - couldn’t get much more distributed if we tried! Those in the “all too difficult” camp would never have taken this project on, which is a shame as they would have learned a great deal about managing distributed teams.

Let me take you through a typical day:

First let me set the scene. Our development and support team are based in India, 5½ hours ahead of GMT. This provides the first of the challenges – the time zone difference. Given that the client is UK-based and that we need to support the live application, the team in India have adapted their working day. They arrive later in the their morning and work on into their evening to more closely align to our working day. This still means they start work a few hours before us but, apart from the support team (who provide 0900 – 1700 cover), wrap up before us; this works for us and we adapt our hours on the occasions when we need to work on a particular problem or issue. One of the advantages of this is that it extends our development day – the team can be working on a problem overnight and present a solution for when the client starts work.

At the start of my working day, I’ll firstly check emails to see if the development team has sent me anything overnight which needs urgent action. At the same time I’ll log into Skype, which we use as our primary real-time communications media (international landline and mobile calls are too expensive and, besides, the link is normally clearer with skype). I can see who is online and use Skype IM to contact them quickly if we need to discuss any overnight issues; conversely they can see I’m at my desk and contact me. Generally the first IM of the day is a general chit-chat about the weather (theirs is generally better than ours!) and how everyone is. By this time the client’s team is normally logging in and, again, we’ll catch up on any key events or issues, generally using Skype IM or conference calling.

Our Product Backlog and Bug Tracker is managed in Sharepoint and this provides us all with good visibility. I’ll run through this and look through anything new, discussing any key points with my Tech Lead in India. We make full use of the attachments & screenshots functionality within Sharepoint to provide the best possible audit trail.
We have a well defined Release Management process and this starts with the pre-Sprint Planning meeting. As Scrum Master I’ll facilitate this and we use Skype conference calling. We IM on Skype first to make sure everyone is ready, then dial in for a conference call. This usually involves me, the development team and the client’s team. We all have Sharepoint open so we can quickly run through the items to go into the next Sprint. Conference calling brings it own challenges when you can’t see those involved and at first it took a while to develop a conference rhythm, but we know each other quite well now and so have picked up the nuances of each of the callers. I’ll lead and, as we run through the call, I’ll constantly confirm the understanding of all involved. This normally takes an hour or so and, once done, I’ll follow this up with a very quick actions list email. Once we’ve finished the conference call the offshore Tech Lead will discuss the items with his team and then produce the Sprint Backlog, which he will share with us all.

Our Daily Scrum is a virtual meeting and is normally held at 2.30pm our time. Again, we’ll use Skype and every team member in turn has their opportunity to update us. This meeting is ring-fenced at 15 minutes and actually I’ve found that it’s easier to keep to this timing in a virtual meeting rather than face to face, when it can sometimes be difficult to stop people talking. We have deviated here slightly from the normal Scrum rules and, if getting everyone on Skype proves a problem, I’ll get the offshore Tech Lead to produce a (very simple) Daily Scrum report in MS Word - but I still insist on every team member completing a section for their area of work, which must remain unedited by the management team. Not strictly within the spirit of a daily stand-up meeting, but it works for us with a distributed team.

Daily progress is managed via the Sprint Backlog & Burndown Chart, with each team member updating the effort remaining for each of the tasks they’re working on. We’re still looking at how best to share this information with a distributed client & development team and I’m also looking at other ways of those involved providing estimate updates, perhaps using Twitter.

When it comes to developing and reviewing the UI, this is made more difficult by our geographical locations. We use Yuuguu as it’s simple (no download software for those joining in) and free. This allows the UI designer to share his desktop with all those involved with the review and we’re able to easily walk through the design; it also allows reviewers to take control and mark up certain areas of the UI in real time to show what they are looking at. Again, we use Skype conference calling during the review and we constantly confirm the understanding of all involved.

Before the offshore Tech Lead leaves for the day we’ll catch up on Skype and discuss any issues that the team need to work on overnight. And before I close down I’ll make sure that any traffic from the client is marked up and passed on to the offshore team.

Over time we have refined and improved our distributed communications. We have a client who has a very good working relationship with our development team; they trust each other and work well together to resolve any issues. We all appreciate the constraints of working in a distributed environment but, rather than use this as an excuse for poor communications, we all work hard to improve our ways of working.
Using Agile methods with a distributed team isn’t easy, but it is possible.

Entrepreneurship – Risky, Chaotic or Agile?

2008-09-11T21:50:00.000+01:00

Choosing between safety and risk “Life is an ongoing process of choosing between safety (out of fear and need for defence) and risk (for the sake of progress and growth): Make the growth choice a dozen times a day.”  Abraham Maslow on 8 Ways to Self-Actualize

Despite the economic downturn, The Six Ninjas have seen an increase in start-ups and entrepreneurs approaching us - which is good! Some want advice on how to achieve 2nd level funding; the majority are interested in us building them a fast and functional Beta prototype to prove their concept or for demonstration purposes.
This tells me a couple of things: they're still willing to take some risk, even in the current economic climate, and the they want to drive the change in these chaotic times.

So this got me thinking about risk, chaos and agility....
In a change driven economy the entrepreneur should want to create change, even chaos for their competitors. They need to be able to respond quickly to competitors' initiatives, new technology and clients' requirements. So the question every entrepreneur should ask themselves is "Am I going to set the pace of change, or are my competitors going to set it?". The answer will depend on their risk appetite and hunger for success.

Entrepreneurs need to balance change against risk:
•    Change generates either risk or the opportunity to gain.
•    Risk Management helps mitigate risk, but Risk Entrepreneurship helps turn opportunity into competitive gain.
•    Failure to change causes.........well, failure.

So what is Risk Entrepreneurship? I see this as the management of a portfolio of ideas and initiatives with varying degrees of uncertainty:
•    Business uncertainty:
•       Is there a market?
•       Is our timing right?
•       Can we make a profit on the product?
•    Product uncertainty:
•       Do we have the right product?
•    Technical uncertainty:
•       Are we using the right technology for our product?

Not thinking about these can lead to uncontrolled high uncertainty - this could lead to a high probability of failure.....but equally greater potential for reward.

I've mentioned Agile in the title - we use Agile software development methods here in the Six Ninjas but how does this relate to entrepreneurs? In this context I see this as the agility to both create and respond to change in order to profit in a turbulent business environment. But creating change requires innovation (the entrepreneur's bread & butter) and the need to respond quickly and effectively to both anticipated and unanticipated change in the business environment.

So what is Agile Entrepreneurship?   It's dynamic, context-specific, aggressively change-embracing and growth-orientated. It's not about improving efficiency, cutting costs or riding-out the economic or competitive storm. It's about succeeding and winning; about succeeding in emerging competitive areas and about winning profits, market share and customers in the very centre of the chaotic competitive storm.

Given all of this, all you entrepreneurs out there may want to think about the following over the coming difficult months:
•    Have the ability (and agility) to change quickly.
Build a framework of growth with just enough process to hand-off chaos but, whatever you do, don't sacrifice creativity and innovation for formality and documentation.

Distributed Scrum Teams – Managing Communications

2008-09-09T21:49:00.001+01:00

In Six Ninjas we use Agile methods to manage software development and, personally, I prefer Scrum to many others as a management tool to track progress. With all Agile methods, communication is key and this becomes harder the more geographically distributed the client, team and other stakeholders are.
For example, one of our clients is based in the East Midlands of England, their tech lead is based in London (as is my Tech Director), me - the Scrum Master - I'm on the south coast of England and our development team are in India - couldn't get much more distributed if we tried!

This means we need to make use of a number of methods to communcate effectively. For us, that means making maximum use of Skype, yuuguu and other on-line tools to conference call, hold our Daily Scrums and review UIs.

In a future post I'll take you through a typical day working with my distributed team. But for now, the message from me is that, whilst working in an Agile fashion with a distributed team isn't easy, it's not impossible.

Kite or Brick?

2008-09-03T21:46:00.001+01:00

I've been road cycling for a couple of years now and mostly ride out with my cycling buddy, Ray (a very youthful 61 year old dude who is also into wind-surfing, surfing, in fact anything that involves speed and a hint of danger!). We don't get out as much as we would like (we blame the weather but mostly it's because we don't always take the opportunities to get out on the road), but most weekends we'll try to go out for a spin of around 30 - 50 miles.

So back to the original question - why Kite? Well, Kite is a cycling term for someone who is a good climber (cycling up hills) and a bad descender (rushing uncontrollably down hills). For those that know me, you might think this is laughable, given I'm not the skinniest guy on the road (and most climbers are stick thin), but I really enjoy getting out of the saddle and pushing up a hill - it hurts but it's good pain! In contrast, Ray is a "Brick" - he is not so keen on the climbing but is a fearless descender - regularly hitting 40mph plus and leaning hard into the corners - makes my blood run cold!

So next time you're driving around south Hampshire and see a small, fat guy "dancing on the pedals" up a hill followed by a tall, old guy hanging on to his back wheel, or a tall, old guy flying downhill, slowly followed by a small, fat guy hanging on for dear life with fear in his eyes - give them plenty of room - or this may be my last blog.

The Accidental Scrum

2008-09-02T21:39:00.001+01:00

Scrum (and agile for that matter) is a common sense approach to project management that we have all probably used, maybe without calling it Scrum, to manage a project at some point in our careers.

Case in point: a few years ago I joined a Royal Navy Warship as the Logistics Officer. I had been a software development project manager for a few years, but this was an operational posting, which is inherently different. I joined the ship in Portsmouth after she had returned from a lengthy deployment. We were scheduled to spend several weeks in recovery and maintenance before returning to sea. It should have been a quiet time to take over the department. It turned out to be quite the opposite.

Four days after joining the ship, the commanding officer called his senior management team to a meeting. He informed us that we had been tasked to protect the merchant fleet sailing to support Gulf War 2. Our mission: to protect the fleet as they transited the Straits of Gibraltar. Over 100 ships were expected to pass through the Straits over eight weeks. We also had a confirmed terrorist threat, so we had a real job on our hands. The CO told us we had five days to prepare the ship to deploy. As you might imagine, the Logistics Department had a massive role to play in readying the ship for deployment. We needed enough provisions to feed the ship’s company for ninety days, the right spares onboard, and sufficient sterling and foreign currency to see us through.

At this point in my career, I knew nothing about Scrum. I did, however, have a good idea of what it would take to ensure that we would be ready to deploy. In my short time onboard I had already identified the “movers and shakers” within my management team. I called them to my cabin and briefed them on our new assignment. I told them to develop their deployment requirements and work out their daily priorities for the five days remaining until deployment. I gave them our goal and sent them off to prepare their teams. They were to report back to me at a daily meeting, which we would hold every day at 0830 in the stores office.

At that meeting, each manager would have two minutes to update us on progress and issues. At the end of the meeting, I would summarise with a redefined goal for the next twenty-four hours. After our initial meeting, we met each day at 0830. As planned, each manager briefed on what they had done since we last met, what would be achieved in the next twenty-four hours, and what impediments stood in their way. I undertook to move their obstacles and briefed the CO on progress at our daily Command Briefings. We sailed five days later, fully prepared and ready to meet our mission.

Without knowing Scrum at all, I had set a sprint goal (“We have to be shippable, quite literally, in five days.”), developed the product & sprint backlogs (our deployment requirements and daily priorities), and established a daily scrum. I knew intuitively at the time that we had to come together at least daily to monitor progress and that any issues affecting the sprint goal had to be resolved by me, so that the team could be left to deliver. Now I understand that what I was doing was setting up daily scrums and acting as Scrum Master for the team.

What seemed like common sense to me when I employed it on the ship turned out to be a methodology that is being put to work in more and more software development organizations each year. Whatever you call it, Scrum delivers.