Where do you start if you contemplating starting on an agile transformation? One of my colleagues really said ‘start with the engine room and then scale out’. Great advice but which ‘engine room do you start with?
Fortunately, Mike Cohn ** also gives some great advise about selecting the right pilot project which is probably the most critical and challenging task!
In reality not every project is equally suited to be your first and the ‘ideal project’ sits at the confluence of project size, duration, and importance and, for me, the engagement of the Product Owner.
Duration: If you select a project that is too short, sceptics will claim that agile works only on short projects. At the same time, if you select a project that is too long, you risk not being able to claim success until the project is over. Pick an average duration project for your organisation; this is typically 3 to 6 months.
Size: Select a project that can be started with one team whose members are all collocated, if at all possible. Start with one team (an engine room), even if the pilot project will grow to include more teams (scale)
Importance: It can be tempting to select a low-importance, low-risk project. If things go badly, not much will be lost. Instead, pick an important project; an unimportant project will not get the necessary attention from the rest of the organisation.
Product Owner Engagement: Having someone on the business side that has the time and inclination to work with the team is critical.
In fact an engaged Product Owner is a ‘deal breaker’ for me. Sometimes it is not easy to find the ‘perfect’ pilot project however; I would not compromise on having a strong Product Owner.
In that respect, we look for 5 key characteristics which we call DARKA
D is for Desire: Quite simply I want someone is up for the challenge, wants to be involved and is happy to try a different way of working. If not, then he/she is not the Product Owner for me; end of!
A is for Authority: The term authority is often used interchangeably with power. However, their meanings differ: while power is defined as "the ability to influence somebody to do something that he/she would not have done", authority refers to a claim of legitimacy. In our context it is the legitimacy to make decisions and enforce those decisions
R is for Responsibility: The obligation to carry forward an assigned task to a successful conclusion. With responsibility goes authority to direct and take the necessary action to ensure success – the state of being accountable
K is for Knowledgeable: This does not mean that the Product Owner has to be the font of all knowledge but it does mean that he/she must know where to find the information and in a timely manner. On a number of web projects that I have worked on, the Marketing guy has been the Product Owner but more often than not there has been a payment element to the project. The Marketing guy was not an expert on intricacies of the various payment options but he knew where to find the guy in Finance to get the answers. And rest assured the Finance guy was an active Stakeholder at Sprint Reviews!
A is for Availability: Working in small, focused iterations (timeboxes, sprints etc) then it is vital that any decisions are made in a timely manner and any questions are answered as quickly as possible. This can’t happen if you have an absent Product Owner. Does this mean that the Product Owner needs to co-located, available 24/7 – No! But it does mean that the team MUST have an agreement with the Product Owner on when and how they can make contact on a daily basis recognising that in all probability the Product Owner will have a ‘day job’ and will need his/her own time!
The role of the Product Owner is very special; it requires an individual with certain skills and traits, including availability, business savvy and communication skills. Don’t compromise on finding this special person!