Like to get Scrum Product Owner Certification?

Our Principal Consultant Colm O’hEocha will be delivering his comprehensive 2 days training for Product Owners in Dublin, 24/25th October. This course will prepare attendees for the Professional Scrum Product Owner certification exam. Some of the topics we’ll cover:

  • Concepts in Agile and Lean Software Development
  • Scrum Framework, including roles, events and artefacts
  • User Stories and Story Mapping
  • Estimation and Planning

Training includes exercises, lots of sample questions and a practice exam.

Feedback from the last time Colm ran this course included ‘the trainer was very, very, very good‘!

We can also offer discounts for 2 or more attendees on the same booking. Email us today at

For further details of course content, see our website.

AgileTour17 Slidedecks available for Download

After another superb lineup of speakers at our AgileTour conference last week (5th Oct), we now have some slide decks available for you to download :

A&E Meetup 21st Aug – Barry O’Reilly at Workday

Designing for Business Evolution

To evolve businesses, leverage technology and exceed customer expectations, organizations need more than a leap of faith. They need to design for it.

In this talk, I share how I’ve been using practices and principles from design thinking, lean and agile to help organizations design for continuous evolution and become experimental by design.

Designers routinely use methods such as hypothesis testing, customer journey mapping and enquiry to uncover and resolve complex challenges. But they fail to realize how those skills and capabilities can be leveraged beyond product development alone.

Through case studies and examples from the organizations I work with I showcase the value of design and designers. These organizations understand that design isn’t just about user interfaces and pixels — it influences everything. I share concrete tools and techniques that drive culture change and business performance, and challenge teams to rethink the role they can play in creating high performance organizations.

Dublin Technology Leaders Aug29th: ‘Build Innovation In’

The next meetup for Dublin Technology Leaders Meetup is 29th Aug at 6pm – Our principle agile consultant, Colm O’hEocha, will be talking about agile in high innovation environments, while Ken Finnegan, Chief Technologist at the IDA, will talk about some of the innovations he sees in Irish organisations. For further details and to register go to the meetup page

‘Build Innovation In’ – Colm O’hEocha, AgileInnovation

Innovation can be defined as ‘the discovery, development and concrete implementation of new ideas’. Therefore it involves exploration (for discovery), learning (to develop) and delivery (to implement). Agile frameworks such as Scrum and Kanban have knowledge creation, learning and innovation at their centre.

Traditional management of software development (‘plan driven’, ‘waterfall’) assumes the discovery and learning have already occurred, and that we know before we start what are the most valuable features and how long it will take to implement them. In this case the focus is on the most efficient, productive delivery of systems that meet customer requirements in terms of functionality and quality. There is little focus on exploration or learning, leading to low support for innovation.

Some firms see innovation as a separate activity from the daily work of delivering software. For example, innovation happens during hackathons, or other ring-fenced ‘innovation time’. It is not an integral part of the daily work of delivery. Agile aims to maximise value delivered not just by delivering software as efficiently as possible, but also by supporting innovation to ensure that the features delivered are the most valuable.

Agile isn’t just about churning out code – it supports exploration and discovery with rapid learning by providing high quality feedback and a fail-safe culture. As we discover new knowledge, we can then redesign our solutions and rework our plans appropriately – that is, we can be ‘agile’. By combining exploration and discovery with concrete implementation (e.g. in Scrum you deliver production ready software every sprint), agile bakes innovation into the heart of the way we work. it ‘Builds Innovation In’ rather that treating it as a distinct activity, carried out separately from the work of software delivery.

In this short talk, I’ll elaborate on some core agile concepts that support innovation – from both human and systems viewpoints.

AgileTour Dublin – 5th October 2017 – Save the Date!

AgileTour is a not for profit, community event that we at AgileInnovation sponsor and organise every year – its where Irelands agile community go to share experiences, learn from each other, have fun and make new contacts.
This full day, not-for-profit conference (only €40 early bird) is where we share war stories, tips and tricks, what might work and what might not. This year, we’re lining up a range of workshops, expert speakers and experience reports from companies in Ireland doing agile. We hope to cover a selection of introductory and more advanced topics over three parallel sessions.
Confirmed companies who’ll be represented include Fleetmatics, Overstock, Ammeon, Hiptest and Workday. If you’d like to share your agile story or discuss a particular topic, please email me – we’d be delighted to hear from both novice and experienced agile practitioners and leaders.
Further details, and registration, on the conference website
For the last few years we’ve sold out all tickets (~300) within a few weeks so better book your ticket soon!
See you there!, Colm
AgileInnovation have been sponsoring the event with our colleagues at InspireQS since 2009. Our friend Frederic Oehl has been our voluntary co-organiser, taking care of logistics, registrations and so on.

Galway Meetup: Kanban basics – Value Streams, Flow and Pull

Kanban is a tool that packs a punch! A simple mechanism for synchronising work activities, it gives us a holistic view of the end to end process and were we can improve. It focuses our attention on the flow of work, enables a pull rather than push environment and can drive radical cultural and organisational changes to enable collaboration. Often used alongside or instead of frameworks like Scrum, it has become a valuable addition to our agile toolbox.

In this presentation I’ll start with a simple exercise to illustrate the basic concepts of flow and how they alter our approach to managing our work – I’m hoping this will drive a lot of interesting discussions on how you might apply Kanban in your environment.

Colm, AgileInnovation.

On the subject of Self-Organisation

“Organise the work, let people self-organise”
Many agile frameworks include the idea of ‘self-organising teams’ as an essential ingredient. For example, Scrum calls for long-life, stable teams where individuals have no titles and there is no hierarchy. With no hierarchy, there is no ‘boss’. When I introduce these ideas in training, most audiences react with incredulity, citing a myriad of objections such as:
  • We must have accountability* – a single individual I can rely on to ‘make it happen’
  • Junior folks couldn’t organise themselves – they need a team lead or project manager to tell them what to do and make sure they do it
  • If someone isn’t in charge, it’ll be chaos…
  • How can we make sure people aren’t ‘slacking off’ if we’ don’t have someone keeping an eye on them?
  • If people are allowed to decide what they’ll work on, you’ll have people doing work they aren’t capable of and making lots of mistakes
  • How do I tell a senior developer with 10 years hard won experience that they now have the same title as the intern?
  • We decide on pay scales based on title – we aren’t going to pay everyone the same so how else could we do it?
  • Whats a career path without titles and hierarchy? What will motivate people to work hard and do a good job?
  • Some people like to be told what to do – they aren’t comfortable making decisions for themselves
  • Isn’t no titles or hierarchy just for an ideal world – can’t we be agile without the self-organisation bit?
*See a recent blog post on accountability in agile organisations

So if you take away titles and hierarchy, it leaves a lot of open questions. Lets tackle some of these one by one.

Firstly, do we really need self-organising teams to be agile? Not all of what are considered agile** frameworks  require self-organising teams – in fact some like Kanban don’t mandate teams at all. But frameworks like Scrum and XP are based firmly around the idea of cross-functional teams. But why ‘self-organising’? The logic is that teams based on a hierarchy, with power at the top, but most of the detailed knowledge and awareness of the work at the bottom, are two slow to sense and respond to complex, fluid situations. In a traditional environment, people on the front line must articulate the changing context to those up the hierarchy, while decisions must be fed down through the ‘chain of command’ till they reach those that will implement them. To speed up this process, teams can delegate power to the front line. However, delegation implies the person delegating, i.e. temporarily passing the power to another, still has ultimate responsibility. Therefore, delegation is usually carefully qualified and bound. Heavy oversight and a fear of a loss of control can hugely restrict the intended benefits. In self-organising teams, on the other hand, the decision making power is not delegated, it is distributed. That is, there is no one individual with the power who is temporarily delegating it to others. The power is everyones, and everyone on the team is responsible for using it to the benefit of the team objective. So in summary self-organiing teams are not a mandatory requirement of agile, but their ability to be agile (sense and respond rapidly and effectively) is an important aspect of a successful agile organisation.

**What is and isn’t an agile method is highly subjective, but mostly I consider whether it shares the values of the Agile Manifesto

The next question is ‘how do we ensure everyone on the team is contributing in the most effective way’? If we don’t have a ‘boss’ telling us what to do, how do we know what to do? The answer is a shared goal, and commitment to that goal. 

‘Make the mission your boss’

The team should have agreed a shared objective that everyone on the team will pursue. In Scrum this may be the sprint goal (short term), release goal (medium term) and company or team strategy (long term). To use a rugby metaphor, the short term goal is to score a try, medium term to win the match and long term to with the championship. It is this shared goal, unattainable by any one team member or subgroup, that causes the team to ‘gell’ in a network of interdependancies and mutual accountability. This is where the transparency agile calls for is so important – so people can see where they can best help the team to reach the goal, where the problems and blockages are, who is contributing what. If everyone is working to a single goal, one that is not too far out (e.g. a day, a sprint), then alignment of activities happens ‘implicitly’ through face to face discussions, the team board, programmers and testers working on the same things at the same time, etc. And since everyone is mutually accountable to each other to do their utmost to achieve the goal, there is no place for people who will sit around waiting to be told what to do. I’ve seen this approach transform a group of shy, junior, fearful engineers into a cohesive, dynamic and super effective team within just a couple of weeks. A good agile coach/scrummaster will create an environment where the mission is the boss, where there is no fear, and where the team has everything it needs to do a good job.

In the next few posts I’ll discuss some of the other questions raised above – e.g. hiring effective team members, career paths, performance management, etc.

Who’s to blame if it all goes wrong? Accountability in agile organisations

It’s amazing what you can accomplish if you don’t care who  gets the credit, (or the blame). Harry S Truman ( in brackets added by me!)

Many agile frameworks, noticibly Scrum, propose self-organising teams to increase productivity, agility and creativity. One aspect of self organising teams is accountability.

In hierarchical teams, common in traditional organisations, it’s clear who is accountable for the outcome of the work. Most teams include some type of leadership or manager role, such as team lead or project manager. If the project doesn’t go well then there is clearly somebody to hold accountable. Of course, you can’t hold someone accountable for an outcome unless you also give them the power to control the resources and coordinate the work. This leads to that person taking control of what the team is doing, which means you no longer have a self-organising team.

So if you want a truly self-organising team, with distributed rather than centralised decision making, then you must also distribute accountability. The two go hand in hand.

(Note that I avoid the term delegated authority in the above discussion. Delegated implies the power and authority are temporarily and voluntarily moved from one person to one or more others. A similar scenario usually underlies the term empowered team. But here we mean that the power and accountability belong to everyone – they are not being given them by another person who really owns them).

You may have heard the saying ‘if everyone is accountable then no one is accountable’. This usually is meant to apply to ‘joint accountability’ where not one but a number of people are accountable for an outcome. But on a self-organising team, I find a much more powerful concept is ‘mutual accountability’. Everyone on the team is individually accountable to everyone else on the team.

So I am accountable to my peers and they are accountable to me. If you are having a problem, I am accountable for recognising that and helping, while you are accountable for letting me know the issue and seeking my help. This directly encourages, or even demands, that we stay aware of our colleagues progress and actively make sure we are helping everyone succeed.

On a practical level, this might manifest itself as a renewed interest by the team in the daily Scrum or stand-up meeting. If I need to be aware of how others are getting on so I can help out if necessary, then the scrum is certainly something I don’t want to miss!

But many of you might still be thinking ‘We still need someone to be accountable for the outcome’, or, in other words: ‘Who should take the blame if things go wrong?’.

Why do we hanker after accountability? Why do organisations strive for demarcation of accountability and role definitions? Is it so that they have somebody to blame if things go wrong? Which leads to the question: are the terms ‘accountable’ and ‘blameable’ interchangable in this context? Are we really looking for someone we can blame? And an obvious follow on question is ‘Are we  designing our organisations for failure?’ So we have someone to blame if things go badly. Or you may prefer to take a more positive spin on this: we need demarcation of roles and accountability to encourage people to work to make the outcome a success. But this is the same justification from a different angle.

What if we designed our organisations for collaboration and success, rather than failure and blameability? What would such an organisation look like?


The Super Chicken Story – as told by Margaret Heffernan

An evolutionary biologist at Purdue University named William Muir studied chickens. He was interested in productivity — I think it’s something that concerns all of us — but it’s easy to measure in chickens because you just count the eggs.He wanted to know what could make his chickens more productive, so he devised a beautiful experiment.

Chickens live in groups, so first of all, he selected just an average flock, and he let it alone for six generations.

But then he created a second group of the individually most productive chickens — you could call them superchickens — and he put them together in a superflock, and each generation, he selected only the most productive for breeding. After six generations had passed, what did he find?

Well, the first group, the average group, was doing just fine. They were all plump and fully feathered and egg production had increased dramatically.

What about the second group? Well, all but three were dead. They’d pecked the rest to death.

The individually productive chickens had only achieved their success by suppressing the productivity of the rest.

To encouarage mutual accountability, where everyone on the team is charged with everyone else’s success, the differentiation of role, job and competence is key.

In most organisations, a role is synonymous with someone’s job: if you are a project manager, your role is project management. If a tester, your job is to test. However, in a self-organising team, where everyone is responsible for team success, this construct restricts our ability to help each other be successful. An alternative is to think of individuals bringing various competencies, skills and knowledge to the team, but not being confined to only practice those skills that are defined as part of their job. Instead, each individual is tasked with helping the team be successful in any way they can – whether or not that is by applying their strongest skills. In this sense, the role, or roles, a person is playing can change day by day, depending on what the team needs at the time. Roles are defined seperatly from individuals. The team has a competency in UX, and one individual usually carries out this role, but it is not only their responsibility. And if they can help another team member by applying the competency, or sharing it, or performing a completely different task, then that’s what they do. Because they are accountable to those others on the team.

Another way of looking at this is in terms of ‘span of control’ vs. ‘span of influence’. In hierarchical organisations, accountability is usually confined to a person’s span of control – that is, what they control directly – the individuals who report into them, whom they control. But in flat, team based structures, there is no direct control. Here accountability applies to your span of influence – that is, each team member is responsible for those they can influence. Depending on the organisational structure, this might extend to your self organising team, or beyond to others in the organisation. For example, some organisations use the ‘advice system’ to support distributed decision making. Here anyone can make any decision on behalf of the organisation, but only after seeking advice on the decision from a number of others. But the decision maker doesn’t have to act on the advice they get from those others – the decision is theirs, and theirs alone. The only rule is that they seek out and listen to the advice. This allows others on the team to exercise their ‘span of influence’. And mutual accountability means each person giving advice must do their best to help you make the best decision. And the decision maker is accountable for seeking out and considering that advice to the best of their ability.

So how do you cultivate a culture that values collaboration and team success over individual performance? There are a few tactics you can employ immediately:

  • Measure and reward ‘helpfulness’. The best people to measure this might be the team members themselves, so look at peer to peer measurements. For example the old 360 degrees evaluations could be developed to this purpose.
  • Define a single, compelling team goal that provides a challenge but is still achievable. Such a goal will ideally require intensive collaboration across the whole team. It will not be achievable by any individual or subset, and so require collaboration to achieve.
  • On your teams, don’t use job titles that refer to a persons job rather than competency, don’t impose a hierarchy or seniority structure, and instead allow a natural structure to emerge. From experience, this results in those that are truly respected by others in the team, for their skills, knowledge and, more than anything, helpfulness, to naturally emerge as the leaders. These are true ‘servant leaders’, elevated to leadership positions by the team because they serve the team so well. They will therefore naturally serve as role models for collaboration, respect and mutual accountability.

The above discussion raises many questions regarding career paths and planning, performance management, hiring, alignment, and so forth. These are topics that more advanced agile organisations are addressing on their journey – and AgileInnovation is helping such companies make the deeper, cultural and structural changes to go beyond mere changes to practices and agile frameworks. If these are challenges you are also facing, get in touch at

Conferences on Agile | DevOps| Testing, Dublin, 19 May – 20% Discount

AgileInnovation can offer you 5 FREE tickets and a discount on further tickets on the UNICOM Agile Showcase Dublin on 19 May. Delegates may attend any sessions from across the three events:

Agile Showcase Dublin:

Implementing and Scaling Agile

19 May 2016, The Gresham Dublin Hotel

Co-located with:

Testing Showcase Dublin:

Testing Challenges, Opportunities and Digital Transformation

19 May 2016, The Gresham Dublin Hotel

DevOps Showcase Dublin:

Fundamentals of DevOps

19 May 2016, The Gresham Dublin Hotel


How to Apply for Complimentary Places:

If you would like to attend the conferences, please follow the steps outlined below, and a member of the UNICOM team will contact you to confirm your place.

  1. Please confirm urgently by email [] saying that you would like to take up the offer, including the following information for each delegate aiming to register:
  • Primary conference track of interest: 
  • Full name:
  • Job title:
  • Company:
  • Email address:
  • Telephone: 
  • Reference Code: AgileInnovation Offer
  1. If you accept a place and subsequently find that you are unable to attend, please either nominate a colleague to attend in your place or advise UNICOM in advance so that they can offer it to someone else.
  2. These 5 complimentary places are on a first come first served basis, we recommend applying urgently to avoid disappointment! If the offer is oversubscribed in the interest of fairness UNICOM may have to limit the number of participants from the same organisation.
  3. The offer cannot be applied retrospectively if you have already registered for the event. Refunds cannot be provided for places already booked.

If you have any questions about the conferences, please contact UNICOM directly and their team will be delighted to help you: +44 (0) 1895 256 484 |

Discount for AgileInnovation clients:

We have arranged with the organisers, UNICOM, an exclusive 20% discount on the ticket prices for any of these events. To claim the discount, when booking, simply apply the Voucher Code “AGIN20“ when booking online.

Whichever of the three events you book for, you are welcome to attend any sessions from the co-located conferences.

Contact for information:

If you have any questions about the conferences, please contact the organisers directly, their team will be delighted to help you.

UNICOM Seminars Ltd | Tel: +44 (0) 1895 256 484 | |