In case you’re in Melbourne early September and happen to attend the Australian PMI Conference don’t forget to look me up. I will be presenting a session on “Transform yourself from traditional to Agile project manager”.

Here’s my submitted abstract:

For many ‘traditional’ project managers the encounter with agile and agility is a confrontational one. While many project managers have been trained in the art of project management based on a set of governance principles grounded in command-and-control related management techniques; managing projects in the 21st Century is developing in an environment in which agility, collaboration, exploration and adaptation are the key. This session will highlight the key issues facing project managers wishing to engage in this transition, explore the key dimensions – behavioural, conceptual and psychological – associated with this transformational change and provide a road map and a range of helpful tips for a successful incorporation of agile principles into any mode of project management, irrespective of the environment in which it will be executed.

I am hoping that by the end of the session the participants will:
1. Understand the conceptual differences between traditional project management methodologies and agile management principles
2. Be equipped with a set of tips for the incorporation of Lean and Agile principles, values and techniques in your project management activities – irrespective of the type of project management methodology you use for your projects.
3. Have a better understanding of Agile project management terminology.

Let me know if you’re going to attend and please come and introduce yourself.

I come across many people that call themselves ‘coaches’.

I come across ‘coaches’ that certainly ‘talk the talk’ but have no real experience to back that up.

And here’s my dilemma:

Should I take such coaches seriously?

Can one become a coach by knowing the domain (as opposed to ‘doing’ in the domain)?

Am I just too damn closed minded?

Think about it!

29. July 2014 · 9 comments · Categories: Agile

Retrospections

Like many things in life, Retrospective – as a concept – can have many layers of abstraction.

At the superficial level it can be used to identify symptoms and find ways dealing with them.

At a deeper level it can be used to highlight symptoms and attempt a rudimentary root-cause-analysis and possible experiments to address them.

At a fundamental level it can be used to highlight symptoms, explore their causes and explore the attitudes and motivations that need changing in order to better address such occurrences in the future.

If I understand this correctly, deeper retrospection and reflection require the investment of higher levels of cognitive effort. This investment, though, is likely to result in longer term benefits (compared with lower levels of retrospections).

While I can ‘see’ the benefits individuals can gain from exercising higher levels of retrospection, as they can gain better insights into themselves, their attitudes and their behaviours; I am not clear on the benefits to the organization. Are there clear, tangible, measurable benefits that would make the extra investment – in coaching and guiding teams to achieve this level – justifiable? I am still looking for the evidence.

Think about it.

25. July 2014 · Write a comment · Categories: Agile

The four weeks or so that have now passes since the Agile 2014 Conference in Melbourne have given me the opportunity to reflect on the conference and consider some of the presentations and messages I have been exposed to.

While the theme of the conference was Embracing Disruption, and while a number of the key note presentations were about Business Disruption, there was little in terms of providing hands-on, practical, implementable clues or ideas for ‘how to elicit disruption’. It is widely accepted that Agile is a vehicle for disruption. While this was certainly true in the earlier days, when Agile had to make its case and increase its market penetration, this is no longer (at least not so explicitly) the case. The level of disruption ascribed to Agile in the earlier days is no longer sufficient to refer to Agile as a disruptive force. We now need new ideas as what used to be disruptive yesterday is today’s norm.

There were two presentations, out of the one’s I’ve attended, that I believe fit the bill. One was the talk titled “Holacracy at Zappos – how do you manage to deliver value when ‘anything goes’?” by Geoff Apps, Director of Engineering at Zappos; and the other titled “Making sense of complexity by designing dynamic environments: The Lens” by Daryl Chan and Martin Kearns.

The idea behind Holacracy is ground breaking. Whether one takes this concept as a positive or negative approach to organizational structure (and associated roles and responsibilities), most will agree that this is a disruptive idea. It takes the idea of ‘self-managed teams’ one step forward and turns if from a small scale, agile development team approach to an enterprise wide adoption.

The Lens concept is about taking the adaptive nature of Agile and turning it into an enterprise level tool. It takes the Kanban Wall concept one (giant) step forward by incorporating into a visual wall the data and information where all employees (at ALL levels) can obtain and share insights regarding the overall scope of the organization’s operations.

To keep Agile relevant, to keep Agile vibrant, we need to focus on this level of discourse where Agile practitioners are encouraged to remain disruptive well beyond the known boundaries originally created for this disruption.

Think about it.

Just finished reading David and Goliath: Underdogs, Misfits, and the Art of Battling Giants (note: affiliated link) by Malcolm Gladwell.

The key premise of the book is that things are not what they seem to be. More specifically, using a number of real life examples, it demonstrates how situations they seem to be advantageous are really (in some circumstances) an indication of disadvantage and similarly, situations where the odds seem to be stacked against the main character result in a favorite outcome.

The book also questions the notion that bigger challenges require a stronger response (such as the natural tendency to apply more and stronger policing in situations where there is an apparent increase in crime) and introduces the notion of the U Curve, suggesting that doing more of something results in positive results, but only up to a point. Doing more of that thing after that point could result in negative consequences. The concept is easy to understand and to apply. For example, communicating with project stakeholders can result in tangible benefits as stakeholders are comfortable that the project is adequately managed. More communication could also be beneficial, but up to a point. If you swamp them with too much or too frequent information you will likely lose their good will and their attention. Just an example.

Think about it!

 

18. July 2014 · 4 comments · Categories: Agile

The Agile story, at some levels is a rosy one. A Manifesto that stipulates a set of values, a collection of principles that underpins these values and teams of people of different skills working together in collaboration and harmony to deliver value in the most efficient and lean way.

Behind the scenes however, organizational politics, power games and internal manoeuvring have the motive and the opportunity to use some of these values and principles in a manner not intended for originally.

Take for example the following principle:

We welcome changing requirements, even late in the development. Agile processes harness change for the customer’s competitive advantage.

On the surface, and taking this statement at face value, this is a deceleration aimed at celebrating the flexibility and adaptability of agile teams to the ever-present changing requirements. Being able to change direction and support the business in a changing landscape is one of the areas where Agile and Lean provide better value for money. This, however, assumes that people are playing it fair and this, I suspect, is a big assumption to make. If there is anything we’ve learned from behavioural economics is the fact that what you see is not necessarily what you get. Put differently, people’s behaviour is seldom rational and even when it is, one person’s rationale will not be the same as the next person, even when they shout the same slogans.

The agile principle of adapting to changing requirements can therefore be used as a pretext for pretentious commitment to a certain scope with a hidden agenda to water down that scope citing ‘being agile’ (i.e. being adaptive to changing circumstances) as the reason for that subsequent (and pre-meditated) change. This is a level of gaming the system that is often hidden from the team members and is played by competing sponsors and stakeholders. Not wanting to be seen to be lacking in support to a certain idea they provide a lip service with no intention to seeing this going through to a completion.

So what does it really mean:

At the practical level it doesn’t mean much. Sponsors and stakeholders have always had the capacity to disturb (or enhance – depending on your view point) project direction. Agile, nevertheless, provide such behaviours with a ‘get out of jail’ card. It provides a level of legitimacy that now turns such attitude into a perceived win, a perceived ‘good behaviour’. Lack of commitment could be seen by the wider community as a sign of intense agility and adaptability – clearly not in the spirit of the agile intent.

Think about it!

If there is anything we can and have learned from the Global Financial Crisis is that what we were taught at university in the 80s was blatantly wrong. The over reliance on mathematically elegant Macro Economic models at the expense of the necessary immersion in what makes the REAL world work. I can recall with some sense of apprehension the aesthetically beautiful graphical models showing how market forces will emerge to push markets into an efficient equilibrium. No one considered, let alone elaborated, on the impact of behavior, attitudes and – most importantly – the very lessons we can learn from observing and interpreting past events.

Reflecting on our very own domain – project management – we can, and indeed should – ponder the possibility that perhaps the way we train and educate aspiring project managers is partially or totally flawed.

Unlike some other professions (and ignoring for a moment the potential discussion around whether or not project management is a profession), one can become a project manager having taken a number of alternative paths. I, for instance, have started my professional life as an economist, have then become a software programmer, a systems analyst, a business analyst and then a project manager. My project management knowledge and experience evolved through observation, on-the-job and formal training and, at some point in time, through the codification of that journey using the PMBOK / PMP accreditation process.

What troubles me in the path I have taken is the fact that it is superficially tilted towards the application of processes and the reliance on ‘best practices’. The PMBOK, for instance, is rampant with linear processes coupled with supporting tools and techniques. It does not force you to use them all or follow them dogmatically but it certainly suggests that in the application or execution of an average project many of these processes, tools and techniques would be a useful thing to consider.

And here’s what is wrong with this approach:

It lacks explicit and direct attention to the body of evidence and case studies researching the reasons for failed projects. It makes no explicit attempt (except for the superficial incorporation of ‘Organizational Process Assets’) to formalise a body of knowledge for practitioners to explore, evaluate and learn from other people’s successes and failures. It totally lacks any retrospection and constant self-evaluation.

Furthermore it lacks context or any appreciation of situational circumstances. Think Cynefin, for example, and you will immediately see that the execution of projects in any one of the four Cynefin quadrants would be completely different and require different skills, different approaches and different tools and techniques. If you approach project management as a linear process you will fail before you even started your journey.

So the next questions we need to look at are:

What steps do professional organizations (like the PMI, and others) take to make sure that certification is indeed relevant and takes into account the proper parameters necessary to be an effective and well-informed project manager (incorporating such knowledge areas as ethics, history of project management, behavioral economics, etc)?

and…

What role do universities and other educational institutions play in ensuring the correct knowledge is taught?

Only a collaborative approach between education providers and accreditation institutions can close this gap.Universities and other institutions need to make sure that project management is being taught not as an engineering course but as the new economics ought to be taught, taking into account the various disciplines necessary to produce a ‘ready to go’ project manager. Accreditation organizations need to reciprocate and adapt by insisting on having these parameters reflected in their accreditation curriculum.

Not implementing the above approach will not be disastrous it will just mean that as a collective we will continue to be mediocre.

Think about it!

07. July 2014 · 5 comments · Categories: Agile

The founding fathers of the modern Agile movement (don’t think there were any ‘mothers’ there), through the release of their Agile Manifesto, have put in motion a process of change in the Software Development world (notwithstanding Terry McKenna‘s paper titled “Agile is Not the End-Game of Project Management Methodologies“). A closer examination of the changes that transpired since makes it obvious (I hope) that the success of Agile was due not just due to the incorporation and injection of Agile concepts into software development processes, attitudes and rituals but also due to the corresponding adaptation of Lean principles, without which the Agile benefits would be (most likely) far less impressive.

It is the Lean thinking that allows the adaptation of Agile practices into non-software projects. The focus on value, the concentration on managing an efficient flow of work, fast delivery and (even) faster failure; these are all principles that can (and should) be used in the running of any project, software or not. Agile ceremonial are adequately useful to the running of non software projects. Daily (or otherwise periodical) stand ups, Retrospectives (aimed at fast learning and immediate corrective action) and value driven delivery focus are all practices that can be applied, successfully, and easily into non-software projects.

One last comment. While I make this claim, that agile and lean practices can be applies to non-software projects, I have to qualify it with the following domain related comment: My main experience in running agile projects is in technology domain. I have, however, have experienced the adaptation of these principles and methods into projects where the deliverables were business processes, operational instructions and business strategies. And just in case you wonder, not sure how that would be implemented in construction projects.

Think about it!

%d bloggers like this: