View my profileScrum 101
07/06/09 In: Agile coaching
Presentation: Stories for Grown-Ups
28/04/09 In: Agile user stories
Last night at the APN (Agile Professional Network) was the first time I co-presented in front of 80 people - a thoroughly pleasurable experience largely due to the extensive interaction with the audience and the great questions they asked.
During the session Douglas Talbot and I tried to explain what user stories are, where they come from, when they’re used and what makes a good user story.
During the session Douglas Talbot and I tried to explain what user stories are, where they come from, when they’re used and what makes a good user story.
User Stories: Stories for Grown-Ups
View more presentations from Sandy Mamoli.
When the red bus hits ... (Agile during a recession)
05/02/09 In: Agile teams | Agile organisations
There’s a saying in software development “If someone gets hit by the red bus ... “ which roughly translates to that if you lose a project team member or two you still want to be able to get the work done and finish the project.
Normally, red busses are rare: The realistic worst case scenario is one or two team members out with the flu or someone quitting their job. A good team can normally recover from such disruptions.
But red busses can be bigger and more damaging and wipe out large parts of a team: This usually happens if a new CEO, new management or a new government revokes funding, recession hits or an organisation just plain runs out of money.
In this case one of two things normally happen:
- The project goes on with fewer team members
- The project gets canned or put on hold
Waterfall
This is bad news for everyone but has a devastating effect if your project runs any flavour of the waterfall methodology:
Fewer team members:
Going on with fewer team members will not just result in major delays but will risk the success of the entire project.
Job roles in waterfall projects and organisations are highly siloed, i.e. testers test, developers code and a business analysts deal with requirements. A team losing several members will not just work at a lower capacity but some work simply cannot be done: If a project for example loses its testers testing will not be performed and the project comes to a grinding halt.
Canning the project:
Stopping the project has even more devastating effects and most likely the entire investment in the project is lost.
Waterfall methodologies use a phased approach: Requirements gathering, Design, Build, Testing and Deployment. Depending on which phase the project gets stuck in an organisation might end up having paid millions for a functional specification, technical design or developed but not yet tested software. All work on a product that cannot be rolled-out and used and that might never see the light of day.
If a waterfall project is stopped before the final phase the product cannot be used and the return on the (often considerable) investment is zero.
Agile
For an Agile project loss or reduction of funding can be bad news too but the risk when using an Agile methodology such as Scrum or XP, if implemented properly, is contained and the investment will not have gone entirely down the drain:
Fewer team members:
Going on with fewer team members will reduce a team’s capacity but as the responsibility and accountabililty for delivery lies within the entire team rather than individual job roles an Agile team can usually keep on delivering.
Agile teams organise around generalising specialists where people have both a primary and several secondary job roles and if one or more specialists have to leave the team other team members will take on their work. If an Agile team for example loses its testers the team’s business analysts, developers, scrum masters/project managers etc will share the workload and ensure that the software is tested and working properly.
Even at a slower pace the team will produce software that can be rolled out to end users.
Canning the project:
If the project is stopped or put on hold the damage is limited. Agile teams develop software incrementally and the primary measure of success is working software. Every 2-4 weeks (dependent on iteration length) the team delivers fully functional software, i.e. software that is fully designed, built and tested.
The basic rule to implement high priority features first ensures that, if the project is stopped, the most important pieces of functionality have been fully developed.
Unlike in a waterfall project project sponsors will never be left with just a functional specification, pieces of documentation or untested software. You might not get everything you initially wanted or set out to build but everything that has been worked on is fully functional and ready to provide value to the business and/or end users.
Real Life
Loss of funding and team members is what has happened after a change of government at my (now former :-) workplace, a New Zealand government entity.
My Agile (Scrum) project has already produced working and usable software in an incremental fashion. Even if it should get stopped we have delivered business value and a good return on investment.
In this case the organisation’s choice of running Agile has put them ahead of their peers.
The waterfall projects? I wish them the best of luck - they’ll need it.
Presentation: Scrum in a Suit - Coach Reveals All
27/01/09 In: Agile coaching
Yesterday, I gave a presentation about Scrum Coaching at the APN (Agile Professional Network) in Wellington.
“Scrum in a Suit - Coach Reveals All” was my 45 minute attempt to explain what a Scrum Coach is and why it is a good idea to have one.
If I am lucky my parents will read this and finally understand what I do for a living.
Tools - the new kid on the block
26/10/08 In: Agile tools
Mingle has received a fair bit of attention lately and the latest version, 2.1, has just been released.
I’m quite happy with Rallydev but as Mingle is made by Thoughtworks themselves and the guys at Silverstripe keep raving about it I thought I’d better check it out. Also, as much as I like Rallydev and VersionOne - they’re both a bit weak on the usability side.
Below a list of what I like and dislike about Mingle:
Things I like:
1. Installation & Support
- Free web/phone conference with a Mingle representative to guide you through configuring the system after you have received a free hosted trial. Very helpful!
- A breeze to install the downloadable version
- Runs on all operating systems (incl. Max OSX, Linux and Open Solaris) and most database systems incl. Postgres
- It just looks nice and appealing
- Tasks can be completed with relatively few mouse clicks
- If you choose the scrum template the card hierarchy of sprints - stories - tasks is very intuitive and standard scrum
- You can create epics for your product backlog
- Given you’re willing to spend enough time playing with configuration settings and are inclined to learn Mingle’s proprietary SQL-like language you can configure the tool to fit exactly your needs. Hell, you could probably even extend their JRuby ;-)
- Mingle contains a fully fledged wiki - great for sharing project information!
- All reports are configurable on the wiki
- As expected, very easily done from Excel (For switchers it’d be great to have an automated import/export to/from Rallydev and VersionOne)
- Great that it lets you preview your import before starting the actual import.
Things I don’t like:
1. Concept of cards for everything
- Representing everything as cards is confusing: It does make sense for user stories, which in the physical world are written on story cards but using cards for releases, sprints and tasks seems forced and non-intuitive
- I don’t want to fit my mental models around a tool - it should be the other way around! Scrum concepts such as sprints and releases are a bad fit for Mingle’s generic object model of cards
- I miss the nice overview I have in Rallydev where I can see all my release and sprint dates
- Card trees fill quite a big part of the screen and it’s hard to get an overview at a glance (There’s another, smaller view but it doesn’t show the relations very well)
- Sprints and releases don’t have fields for start and end dates (I can add them myself by configuring cards but not adding them by default seems odd)
- There seems to be no standard way of getting started with a project quickly. There is no step by step process to quickly set up your releases, sprints, product backlog and user stories. Unlike Rallydev which guides you through with a pre-defined process and video documentation Mingle makes you figure it out for yourself.
- Mingle expects you to invest a considerable amount of time learning how to configure the system and how to make it work for you.
- There is no free SAAS version available (By comparison Rally Community edition is free for up to 10 users and Version One’s team edition provides similar functionality for free)
- Hosting Mingle on your own server is free for up to 5 users but I don’t want to wast my time installing tools and maintaining a server.
- The hosted trial for one project is great but only being allowed to keep the instance for 2-3 week is not enough for me to try Mingle on a real project and to make a decision to move all my projects from Rally or VersionOne
Overall, this is a promising tool with an attractive user interface.
It is nice that the tool is extensively configurable but it is way too time intensive to set up. The point is that even though I can configure everything I don’t want to: I just want to get going quickly with 80% of what I need and focus on getting my projects done. Spending time on configuring a tool seems like a waste of time.
As Mingle still seems a bit rough around the edges and does not provide a killer feature that would justify the hassle, learning curve and additional licensing cost I won’t switch from Rallydev this time.
I’ll definitely keep an eye on future releases though!
Agile requirements
08/10/08 In: Agile user stories
When not to run Agile
05/10/08 In: Agile organisations | Agile teams
People keep asking me whether I’d run all projects using an agile framework such as Scrum.
When I answer “of course not” they often not only expect but gently try to steer me towards an answer that excludes certain type of projects: “You certainly wouldn’t use it for a mission critical system, would you? Or a compliance project? Or an infrastructure project? “
Actually, yes! I have used Scrum for business critical systems at a major mobile phone manufacturer, have implemented mission critical systems for a publicly owned European Rail Cargo company, a friend of mine has successfully delivered a compliance project and another one has even developed fighter jet control systems for a European Air Force using scrum.
It’s not about the type of project. It’s not even about the size of your project. It’s about whether you’re willing and able to create a setup that allows agile projects to succeed. To me the rather vague terms of organisational and cultural readiness can be narrowed down to a list of primary show stoppers:
I’d NOT run agile if ...
There are of course numerous other things that are important for agile teams to succeed but usually there are work-arounds for non-ideal situations.
If I don’t meet any of the above obstacles I’ll go for Scrum any time!
What’s your list of show stoppers or essential requirements for running an agile project?
When I answer “of course not” they often not only expect but gently try to steer me towards an answer that excludes certain type of projects: “You certainly wouldn’t use it for a mission critical system, would you? Or a compliance project? Or an infrastructure project? “
Actually, yes! I have used Scrum for business critical systems at a major mobile phone manufacturer, have implemented mission critical systems for a publicly owned European Rail Cargo company, a friend of mine has successfully delivered a compliance project and another one has even developed fighter jet control systems for a European Air Force using scrum.
It’s not about the type of project. It’s not even about the size of your project. It’s about whether you’re willing and able to create a setup that allows agile projects to succeed. To me the rather vague terms of organisational and cultural readiness can be narrowed down to a list of primary show stoppers:
I’d NOT run agile if ...
- People on the team are not fully allocated and committed to the project
- You can’t stack a great team and only get the people that everybody else wants to get rid of (Give me some of the company “stars” even if it’s just to show commitment and get me agile personalities!)
- You don’t have the courage to let the team make decisions, to allow them to learn by making mistakes and to trust them to get the job done - you’re stuck in command control
- You don’t have a business person who has the time, courage and authority to work with the team and to make quick decisions
- You expect instant success and need a silver bullet (Sorry to be the one to bring it to you but if your project is impossible or if you don’t have good people no methodology or framework is going to help you ;-)
There are of course numerous other things that are important for agile teams to succeed but usually there are work-arounds for non-ideal situations.
If I don’t meet any of the above obstacles I’ll go for Scrum any time!
What’s your list of show stoppers or essential requirements for running an agile project?
How to pick a Scrum team
28/09/08 In: Agile teams
I was recently asked by a friend how to pick a Scrum team.
My friend is a project manager within a New Zealand government department and to deliver an important project he was given complete freedom of choice with regards to project methodology and people.
He chose Scrum as a delivery framework and needed 8 people to form his dream team. The big question was which people to pick and which skills to focus on.
I've never been fortunate enough to pick my own scrum team. Normally, I get a certain degree of choice and then a combination of who happens to be available and people who I really, really fight for. And sometimes I fight to avoid getting someone on the team.
Having complete freedom I think I'd focus on:
Sure, people should be qualified and good at what they do but it is much easier to teach people skills than to perform personality transplants.
My friend is a project manager within a New Zealand government department and to deliver an important project he was given complete freedom of choice with regards to project methodology and people.
He chose Scrum as a delivery framework and needed 8 people to form his dream team. The big question was which people to pick and which skills to focus on.
I've never been fortunate enough to pick my own scrum team. Normally, I get a certain degree of choice and then a combination of who happens to be available and people who I really, really fight for. And sometimes I fight to avoid getting someone on the team.
Having complete freedom I think I'd focus on:
- Personality and work attitude - people who are solution oriented, like to deliver, like to succeed, are easy to work with, can communicate and just get the job done
- People who like each other or have a chance of getting along, i.e. have respect for each other and can have fun together
- Absolutely no primadonnas: We can all be flexible and accommodate a lot but the lone genius who lives by his own rules just does not work (I usually remove them and I have never regretted it)
- People who are confident enough to handle the visibility and transparency that come with Scrum
Sure, people should be qualified and good at what they do but it is much easier to teach people skills than to perform personality transplants.
Design Chunking with Scrum
27/09/08 In: Agile user experience
When I started with agile (Scrum) software development five years ago one of the main challenges I faced was combining an agile development approach with user-experience driven website design.
Especially, as we were working on a global, consumer-oriented web site with a strong focus on product branding we needed to make sure that we could benefit from the agile development approach without losing focus on a consistent user experience (UX) and information architecture (IA) across the site.
Agile frameworks such as SCRUM and XP say absolutely nothing about the IA and user interaction design processes, which meant that we had to learn mainly by trial and error.
Most of the problems we faced originated from a clash of two fundamentally different world views:
Our experiments:
Attempt 1: Fully agile - “out of the book” Scrum resulted in “piece meal” design and user interaction. We lost track of the big picture and lacked overall IA/design consistency across site. Also, our product owners found it difficult to keep an overview of the project.
Attempt 2: Upfront IA and graphic design caused problems with unused and out-of-date designs and feature specifications. Sometimes we finished an iteration or release with partially implemented features - very non-agile! We also found it difficult to adapt to feedback after the IA/design phase was completed.
Attempt 3: Post skinning (applying design after functionality has been developed) caused our implementation to drift from the design and user interaction intent and we often faced excessive and unnecessary re-coding and re-factoring work. The product owners and end users found it difficult to give feedback as non-shippable increments were demonstrated.
After three failed attempts we still wanted to utilize the advantages of an agile approach that would allow for continuous inspection and adaption and could help us to keep the focus on the most important parts of the site. Basically, we wanted to keep the agile advantages without sacrificing the overall user experience.
Attempt 4: Design-chunking - success!
(This term was originally coined by Lynn Miller)
With this approach we defined initial concepts upfront and subsequently broke the IA and user experience design apart into smaller pieces that could be delivered incrementally.
Design-chunking process:
The most important break-through came from two changes:
Decoupling of IA/design and development:
This approach worked very well for us, we delivered nine releases to a happy client and in terms of process we felt we got the best of both worlds.
I would be very interested to hear your thoughts on this approach and particularly any experiences you may have had with similar issues in your projects - especially large and/or global web-based projects.
Also, an absolutely excellent description of this approach was done by Lynn Miller in her paper on Adapting Usability Investigations for Agile User-Centered Design. Much of my article is based on and inspired by her work. I only wish I had know about it before we started our extensive period of trial and error.
Especially, as we were working on a global, consumer-oriented web site with a strong focus on product branding we needed to make sure that we could benefit from the agile development approach without losing focus on a consistent user experience (UX) and information architecture (IA) across the site.
Agile frameworks such as SCRUM and XP say absolutely nothing about the IA and user interaction design processes, which meant that we had to learn mainly by trial and error.
Most of the problems we faced originated from a clash of two fundamentally different world views:
- UX people are driven by a holistic approach (big picture)
- Dev teams focus on iterative and incremental development
Our experiments:
- Attempt 1: Fully agile - out of the book Scrum
- Attempt 2: Upfront IA and graphic design
- Attempt 3: Post skinning
Attempt 1: Fully agile - “out of the book” Scrum resulted in “piece meal” design and user interaction. We lost track of the big picture and lacked overall IA/design consistency across site. Also, our product owners found it difficult to keep an overview of the project.
Attempt 2: Upfront IA and graphic design caused problems with unused and out-of-date designs and feature specifications. Sometimes we finished an iteration or release with partially implemented features - very non-agile! We also found it difficult to adapt to feedback after the IA/design phase was completed.
Attempt 3: Post skinning (applying design after functionality has been developed) caused our implementation to drift from the design and user interaction intent and we often faced excessive and unnecessary re-coding and re-factoring work. The product owners and end users found it difficult to give feedback as non-shippable increments were demonstrated.
After three failed attempts we still wanted to utilize the advantages of an agile approach that would allow for continuous inspection and adaption and could help us to keep the focus on the most important parts of the site. Basically, we wanted to keep the agile advantages without sacrificing the overall user experience.
Attempt 4: Design-chunking - success!
(This term was originally coined by Lynn Miller)
With this approach we defined initial concepts upfront and subsequently broke the IA and user experience design apart into smaller pieces that could be delivered incrementally.
Design-chunking process:
The most important break-through came from two changes:
- We introduced an iteration (sprint) 0
- We de-coupled IA/user experience/graphic design from development
- done before development begins
- short (2-3 week) IA/user experience/graphic design only iteration to lay the groundwork
- defines “big picture” on which subsequent designs and not yet fully defined areas of the site will be based
- outcome 1: overall strategy for IA (site-wide elements such as page grid, navigation, rough placement of modules)
- outcome 2: overall design concept including site-wide design guidelines
- exact content balance between IA and design will be based on whether an IA or design led approach is used
- signed off by client (partial IA and design sign-off) and discussed with developer to assess technical complexity
- iteration 0 only covers fundamentals and potentially the details of the most important page. Details for other pages and areas of the site are still to be refined incrementally
Decoupling of IA/design and development:
- after iteration 0 decoupling IA/design and software development into two independent tracks
- tracks iterate separately but simultaneously and provide frequent feedback to each other
- the IA/design track feeds a refined design of the most important features/page(s) to the development track at the end of each design iteration
- the output from the IA/design track at the end of an iteration is used as input to the subsequent development iteration
- for the IA/design track to feed the development track the IA/design track needs to be ahead in time - ideally this would be one iteration ahead with minor refinements still possible during the development iteration (e.g. change an image)
- focus on potentially shippable increments of functionality to provide feedback opportunities for the client/users
This approach worked very well for us, we delivered nine releases to a happy client and in terms of process we felt we got the best of both worlds.
I would be very interested to hear your thoughts on this approach and particularly any experiences you may have had with similar issues in your projects - especially large and/or global web-based projects.
Also, an absolutely excellent description of this approach was done by Lynn Miller in her paper on Adapting Usability Investigations for Agile User-Centered Design. Much of my article is based on and inspired by her work. I only wish I had know about it before we started our extensive period of trial and error.