ISA TechBrew – 17 January 2013 – Agile product Management

Two of my client companies are speaking at this informal, fun evening event!

Thursday, 17 January 2013 at 19:00 (GMT)

Dublin, Ireland

Run by the Irish Software Association (ISA), ISA TechBrew is an informal gathering of software company management and technology leaders, getting together to chat over a bite and a beer.

Theme of the evening: Agile Product Management

 Hear from experienced agile and product management professionals in Irish software companies debate the challenges and opportunities of Agile Product Management with Rich Mironov, Silicon Valley veteran, Product Camp founder, and “product guy” at six tech start-ups.

Speakers this month:

Rich Mironov, a Silicon Valley product management veteranwill open thesession with some insights from his agile product management experience: Is there such a thing, and where have the early agilists wandered away from the realities of the software marketplace?

Rich is a visiting faculty member of the DIT Product Management programme sponsored by ISA Skillnet.

Rich will be joined ‘on the tables’ by agile and product management professionals from leading Irish technology companies.

Rich Mironov is a serial entrepreneur and agile “product guy” including stints as founder/CEO, VP Product Management/Marketing and go-to-market strategist.  He is a veteran of six tech start-ups and dozens of consulting engagements to large and small tech companies worldwide.  He founded the first Product Camp and writes the Product Bytes blog on software, start-ups, and the inner life of product managers. Rich is author of the popular book ‘The Art of Product Management’.


Siobhan Maughan, Vice President, Product Management at Openet

 Siobhan Maughan has over 20 years experience in the software industry, most recently as Vice President of Product Management at Openet. Having joined Openet 5 years ago as a Product Manager for the Openet Policy Manager product she is now responsible for a portfolio of products that enable the world’s largest and most complex service providers to monetize their services and to operate more efficiently. Prior to her time in Openet she held a number of roles across engineering and marketing for telecommunications companies including Silicon and Software Systems and Eicon Technologies.


John McQuillan – OpenJaw President, Head of Product Development

John is one of the co-founders, along with Seán Mac Roibeáird and John Lambe, of OpenJaw Technologies. As President, John has guided the Company through continual growth to being a leading online technology partner of the world’s biggest travel brands.

For over 25 years, John has been a senior executive at the forefront of travel technology working for companies such as Datalex and Westinghouse Canada. During his career, he has worked with many of the world’s leading travel companies, including Airlines, Online Travel Agencies, Hotel Groups and Loyalty Programmes, gaining considerable insight into their specific industry requirements and providing expert insight on successful eCommerce strategies.


Agile Tour 2012 – FREE Agile afternoon Event Dublin Nov 1st

The annual AgileTour returns to Dublins’ Grand Canal Hotel this November 1st from 1pm. The schedule is still being finalised but expect a selection of seasoned agile and lean presenters and several experience reports from companies that have recently adopted these methods. A great chance to network with others interested in agile and lean software development.

Event sponsored by AgileInnovation and InspireQS.

FREE Seminar: Innovative and Profitable Software Development with Lean/Kanban

This coming October 4th AgileInnovation present a free seminar on Software Development using Agile and Lean Methods. This is targeted at companies looking to adopt lean and agile methods, and to those who have already adopted and are looking to deepen their implementation and increase their effectiveness. The content will be particularly relevant senior executives, functional and project managers, and senior technical product and software development professionals.

Presenters: Colm O’hEocha & Fran O’Hara

Oct 4th 4pm (sharp) – 6pm, IBEC, Confederation House (Registration starts 3:30)
84-86 Lower Baggot Street
Dublin 2
For further details and registration please email Karen at

Seminar Outline:
The science and practice of managing product development and other creative knowledge work is being revolutionized. Following the introduction of Lean Manufacturing in Japan, ‘Agile’ software development introduced many of the same principles to more complex development work.
However, unlike manufacturing, creative development requires variability to add value and therefore must thrive in the presence of uncertainty and risk, otherwise it cannot produce innovative solutions.
Traditional project management approaches typically aim for efficiencies through standardization and conformance, and in so doing eliminate innovation. They aim to maximize utilization of resources, thereby prolonging time to market. They divide and demarcate roles and responsibilities without understanding how that destroys collaboration and information flow. And they invest in extensive up-front planning, and then resist emerging reality when it doesn’t conform to the plan.
Managing creative development teams and projects requires that we focus on maximizing the economic outcome throughout the project or product lifecycle. But most development teams have little understanding of project economics – how much does a months delay cost? – what is the value of fast, rich feedback? – what is the cost of hand-overs?
In this introductory session, we explain the concept of Flow – the foundation for radical improvements in quality, predictability, agility, visibility and efficiency. Flow depends on
· managing queues and work in progress
· implementing fast feedback loops
· breaking our work into small, independent units
We briefly introduce some of the science behind these ideas and provide an overview of how they are applied in lean and agile methods such as Kanban and Scrum . We discuss practical next steps you can take to move towards Leaner, more profitable software development.

Doesn’t Agile mean ‘No Documentation?

One of the most common questions I get from folks looking at agile for the first time is ‘Does agile mean I don’t have to do documentation?’. I think this ‘myth’ stems from the agile manifesto value of ‘Working Software’ over ‘Comprehensive Documentation’. But the manifesto doesn’t say documentation is bad, just that working software is better.
I use two ideas to explain where documentation fits in with agile teams:
1) differentiate between ‘process’ or ‘project’ documentation and ‘product’ documentation. The first is used within the project, and once the project is over, is generally discarded or at least of little value. Requirements docs, technical specs, etc fit in here – they are expensive to develop and they need to be updated regularly to reflect emerging realities. ‘Product’ documents, on the other hand, are a deliverable from the product – they describe the product that was actually built, they have a long and useful life as part of the product, and they can be less comprehensive as they merely augment the working software.
2) differentiate between documents that ‘replace’ conversations and collaboration and documents which ‘record’ conversations. Using documents to communicate between project members is intensely expensive, laborious and ineffective (the written word is exceedingly bad at communicating complex, tacit or nuanced knowledge). People talking at a whiteboard is a much more efficient and effective form of communication. However, documents can be useful to record decisions made in such conversations – the valid characters in a field validation, the calculations to be performed to generate a report column, etc. But these are specific, explicit bits of knowledge, relatively stable, and given context by the conversation that led to them.

So in summary, I recommend confining documentation to product rather than project oriented purposes, and to write it after the fact as a record of conversations, rather than a replacement for them.

Moving from Authority to Responsibility

Lean Thinking, which underlies Agile methods like Scrum and XP, has as one of its central pillars “respect for people”. Agile reflects this in terms of ‘whole team’ accountability, collaboration and self-organisation. All these factors lead to agile seeing team members from a more ‘humanistic’ point of view – they are more than just resources that can be swapped in and out of projects – the sort of ‘bean-counting’  mindset giving rise to the ‘mythical man-month’.  Agile takes teams and individuals much more seriously, calling for long-life, cross-functional teams that are allowed the time, latitude and autonomy to gel into a high-performing whole. This change is well summed up by the phrase ‘Move from Authority to Responsibility’. Where organisational structure is based on individual authority rather than joint responsibility, it leads to fragmentation, isolation of roles, hand-offs, friction and ultimately poor organisational performance.

Its great to have really simple and memorable phrases to guide our day to day decisions and I think this is one of those: Build Responsibility, not Authority.

How agile are you?

One of the big culprits in failed agile teams is the tendency to cherry pick those practices that seem to ‘fit with the way you work’, ‘with the way we do things around here’. Agile explicitly calls for methods to be customised depending on context. But often this can be misconstrued as selecting those bits that are compatible with how you work now – thereby leading to no fundamental change in the way you work. Examples are iterations as long as the release cycle, calling the project manager a ScrumMaster without a change in role and considering a feature or story ‘done’  when it has been coded and passed to QA. This leads to a Cargo Cult adoption where the team adopts the language and some ceremonies of agile, without understanding the fundamentals of how it works. No wonder the benefits are elusive…

When assessing how well teams have adopted agile methods like scrum, the approach is usually compliance based – an evaluation of how closely the team follows the defined method – whether customised or not. There are two fundamental difficulties with this:

1) The way in which agile practices are implemented in a team has a great bearing on how they support or constrain agility – for example, a daily stand-up meeting that spends 45 mins getting status updates from everyone is really not going to help a self-organising team co-ordinate their actions for the day. Even a stand-up of 10mins where the three standard questions are posed can be ineffective if the team doesn’t engage and feel ownership of it. Therefore, assessment by compliance evaluates, well…, compliance – not agility which is probably what you want to know.

2) Since each project & team implements their development method differently (a scientific fact from extensive research), and since that implementation evolves over time, using compliance as the basis for assessment hinders inter-team comparisons – akin to comparing apples and oranges. A lot of the value in assessing a team is so you can benchmark and compare to other teams as a way to identify possible paths to improvement. Without the ability to effectively compare, the assessment just isn’t all that valuable.

3) Most methods already used by teams have some really good aspects. Moving to agile should preserve these (unless replacing them with something even better). If attempts to be compliant with some textbook method causes these to be lost, then we’re really ‘throwing out the baby with the bathwater’.

To overcome these, my colleagues and I have been developing an assessment that looks at agility from first principles – regardless of what method is being used by the team. Of course agility is a complex concept with many facets such as creativity, responsiveness, simplicity and quality. By focusing on how any given method contributes to these facets, we can assess how it contributes or detracts from agility as a whole. We can also compare very different methods, like scrum, XP or indeed waterfall. And we can make recommendations which preserve whats valuable in what you do today while tackling those areas promising improvement.

In another post I’ll discuss an alternate assessment technique I use – rather than assessing agility, this one identifies barriers to adoption and helps map out an adoption strategy tailored to a team, project and organisation.