In my last article on Incubating Innovation, we explored the culture and mindset of accountable experimentation. This article focuses on actionable tools and approaches.

Within agile frameworks, the team retrospective is the primary workshop for planning and evaluating experiments. Yet most team retrospectives I see are broken.

Teams spend too much time recording viewpoints and information—but not enough time reviewing or planning experiments. It is common to see the majority of the time spent gathering what went well, what did not go well, and appreciations. Yet where’s the focus on experiments, the learning process and trials for the next iteration?

If success goes to those who can innovate the fastest, how do we nurture innovation? The basics are simple to understand—but difficult to implement and stick with in the face of adversity. We need to create an environment that encourages experimentation while also tolerating, investigating and learning from the inevitable failures.

It may sound easy, but executives and shareholders demand results, not “learning opportunities.” We need an approach that fosters experimentation and learning in a defendable way, with a bias for results. To innovate faster than our competitors, we need to maximize our learning potential. This means that by design, 50% of our experiments should fail since we are seeking knowledge expansion, not validation of things we already know. The trick is keeping people engaged and motivated when half of their experiment time is spent failing.

My first opportunity to create and run a large agile team did not start well. Having had good successes with small to medium sized agile teams I was keen to unleash the benefits on a bigger scale. I was working for IBM at the time and was able to persuade my account manager to pitch the approach on one of our government projects. A clean-sheet development opportunity with a smart team and engaged business group – what could go wrong? As it turns out, plenty due to my ill-advised approach.

It was the early 90’s and we were trialling techniques that would later become the agile approach DSDM (Dynamic Systems Development Method). Taking ideas like James Martin’s RAD (Rapid Application Development) and active user involvement from Enid Mumford’s Participative Design Approach, we had already dramatically reduced development time and improved acceptance rates on several projects. I was convinced collocated teams with short iterations of build/feedback cycles were the future. We were all set for a big client success and who better than the British Government for good publicity! My enthusiasm was about to be tested.

I was given a full rein of the project, or as I would later realize, just enough rope to hang myself with. Having struggled to get dedicated business input on previous projects I commandeered a large boardroom to collocate the development team and business subject matter experts (SMEs). It was awesome, everyone was together in one room and we had direct access to the business representatives for requirements elicitation, clarification, and demo feedback. We were working hard and getting lots of features built but the business representatives hated it.

At first, I thought they hated me. I think that is a common mistake, we internalize changes in behaviour as attacks or criticisms of ourselves. What have I done? What did I say to upset them? - all of them! I recall wanting to write on my internal project status report to the IBM PMO that “the business is revolting”. However, that is what occurred, starting as cordial and helpful, the business SMEs became less helpful, then uncooperative, and finally hostile. I had a revolt on my hands that I did not understand.

This was my first introduction to organizational change. Luckily for me, I had access to many people in IBM smarter and more experienced than I was. I was given a book called “How to Manage Change Effectively: Approaches, Methods, and Case Examples” by Donald Kirkpatrick that changed my career. In it Kirkpatrick outlines circumstances where people will resist change. These include:

1. When people sense loss in: security, pride and satisfaction, freedom, responsibility, authority, good working conditions, and/or status
2. It creates more problems than it is worth
3. Extra efforts are not being rewarded
4. Lack of respect for those initiating the change
5. The change initiative and its implications are misunderstood
6. Belief that the change does not make sense for the organization
7. Change is misdirected, current state or alternatives are better
8. A low tolerance for change in our lives
9. When change violates a principle or commitment that the organization must stand by
10. Exclusion from the change initiative
11. Changes viewed as criticism of how things were done in the past
12. The change effort occurs at a bad time, other issues or problems are also being handled

Something I was not aware of at the time is how the career development process works within the government. The most junior new hires work in open-plan cubical offices. Then as you get a promotion you get moved to bigger cubicles with higher walls that are more like mini-offices. Next, you get promoted to a real office, then an office with a window, and eventually a corner office. In short, your workspace defines your status, responsibility and authority.

By bringing these business representatives into a shared boardroom to work on the project I had unwittingly generated change resistance scenarios 1-3 and probably triggered many others also. Making them sit and work together like the most junior recruits had caused a loss of good working conditions, status, freedom, pride, satisfaction, and perceived authority. A bad idea when hoping to develop a productive working relationship with someone.

Luckily for me the Kirkpatrick book also lists circumstances when people do accept change, which unsurprisingly are the opposite conditions and include:

1. When change is seen as a personal gain: in security, money, authority, status or prestige, responsibility, working conditions, or achievement
2. Provides a new challenge and reduces boredom
3. Opportunities to influence the change initiative
4. Timing: the time is right for organizational change
5. Source of the change initiative is liked and respected
6. The approach of the change and how it is implemented appeals to us

So, equipped with these ideas we changed our approach. Instead of the business SMEs being collocated with us they returned to their fancy corner offices, long lunch breaks, and afternoons spent reading the newspaper - none of which they could do when they all sat together. Instead, we reserved their mornings for questions, review sessions, and demonstrations. This was better received because their morning calendars were blocked with important project meetings, but we rarely called on all of them at once unless it was for a business demo.

Now they had their offices back, a little more free time, and were engaged in a more respectful way. The team were sceptical at first. However, it really is much better to have one hour of someone who is cheerful, engaged, and helpful than eight hours of someone who is bitter, obstinate and causing issues. The project went much smoother after these changes and it taught me an important lesson in never trying to introduce a process or practice without considering the people elements first.

We completed the project early, largely due to the input and hard work during acceptance testing of the business SMEs, and IBM got their successful case study. I learned to temper my enthusiasm and consider other stakeholders who will undoubtedly have a different view of the project than myself. Individuals and interaction are indeed more important than processes and tools, even if they are your own pet agile processes and tools.

[I first wrote this article for the Government themed November issue of ProjectManagement.com, available to subscribers Here]

The suggestions, observations and ideas we capture at retrospectives are not Lessons Learned. That would imply we have already learned from them and will not make that mistake again. Instead, they are Lessons-to-be-Learned which is subtly different but stresses the most important part, which is we now need to learn something.

Learning involves several steps. David Kolb, an educational theorist, describes a 4-step learning process:

1. Concrete Experiences (What we already know)
2. Observation and Reflection (What our retrospectives help us identify)
3. Abstract Conceptualization (Thinking about the problems and designing potential solutions)
4. Active Experimentation (Trying something new)

These stages act as part of an experimental learning cycle. The last step, Active Experimentation, creates new concrete experiences and builds on what we already know.

It is easy to confuse the retrospective actions of Observation and Reflection (Stage 2) as gathering lessons learned. However, this is not the case, instead it is just one step in the process. We then need to determine a solution (Stage 3) and run experiments to learn from them (Stage 4). Only then might we actually learn something.

To remind us that simply gathering ideas and suggestions for improvements is not the same as learning, I suggest we stop using the term “Lessons Learned” and instead use “Lessons to be learned”.

I am pleased to announce the availability of my new PMI-ACP Workbook. This new workbook focusses on a smaller subset of 50 key topics.   My original PMI-ACP Exam Prep book distilled all the relevant content from the 11 books on the PMI-ACP recommended reading list in a common voice. The workbook is also different by providing lots of exercises and many situational questions like you will find in the exam.

So, while my PMI-ACP Exam Prep book covers all the background and theory – ideal for a comprehensive coverage of everything in the exam, the new PMI-ACP Workbook is a practical, hands-on study tool that focusses on the core topics needed to pass the exam. If you already have your CSM credential or 3+ years of agile experience you likely know the agile mindset, values and principles material already. However, you may not have the lean, kanban, and team development knowledge needed to pass the PMI-ACP exam so the workbook can fill those gaps.

To help determine which book is best for you I created the following flowchart:

Hands-on learners and people who do not want to read all about how the approaches fit together will find the 50 key topics of the new workbook a simpler way to navigate the material. Also, since the content is arranged by topic alphabetically you can easily jump around and create your own study plan based on just the topics you need.

While the workbook coverage of topics is less than the prep-book, the emphasis on exercises and situational questions is much higher and accounts for the slightly higher page count (457 pages). There is white space for writing notes and the whole thing is spiral bound so it lays flat when you are working in it. The content changes are summarized by these rough page count graphs:

I think it fills an important need. A workbook for hands-on learners looking to build their own study plan and gain access to high-quality situational questions. It also provides access to a free online quiz. Readers can order and get an early-bird discount from RMC here.