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.

22. July 2014 · 1 comment · Categories: Book Review

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)?


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!

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

Few weeks ago I had the pleasure of attending the Agile 2014 Conference in Melbourne. With the overall title for the conference being “embrace disruption” I was naturally excited about the opportunity to hear from various thought leaders of their take on the tools we can positively use to deal with the inevitable change we are all facing.

In what to follow I will summarize my key learning and observations from some of the sessions I have attended:

In a talk titled “Unleashing the Full Potential of Your Agile Teams”, Dipesh Pala made the observation that the conditions necessary to achieve a happy team are similar to those needed to keep individuals happy. Those, he asserted, are dependent on a sense of achievement and this does not necessary require massive, gigantic, overreaching ones as small wins are sufficient to foster this sense of achievement. But making progress, while important, is not – on its own – sufficient to guarantee this sense of achievement. This needs to be associated with progress achieved via the execution of meaningful work. It is this combination of progress and meaning that fosters the sense of achievement, and it is this sense of achievement that is the pre-requisite to the emergence of happy teams.

Happy Team

John Sullivan, a Product Delivery Manager – Business Division, MYOB, spoke about the Agile journey of the development team in MYOB. The core question he addressed was the challenge of transforming their development team to Agile just to confront a degradation in the quality of the product delivered to the market. Or more succinctly, what do you do when you follow the Agile principles but your product delivery if lacking to the point where the market is voting you out of business? The answer, a la John, is simple: Change the focus of your teams from Agile to Delivery. The purpose of adopting agile practices is just the means but not the end. If you focus on the ceremonial aspects of Agile and forget that these are just there to support your end goal – that is the delivery of quality marketable products to the customer – then you’ve missed the point.

Focus on Delivery not on AgileIn “Lean Entrepreneur in the enterprise”, Brant Cooper indicated that there are two questions that kill innovation: 1) What’s the ROI? and 2) When will we see it? Innovation, according to Brant, is a product of a long journey that start with Disruption and ends, after a few twists and turns with a Sustainable product. This Disruption is the playground of Innovation as it is innovations that create the environment resulting in changes to current practices. While the journey from Disruption to Sustainability is a treacherous one, its fundamentals are pretty well known and it all starts with an experiment. The process of innovation is about a journey of experimentation, of trials and of learnings through failures. If you are not prepared to entertain failures and are not willing experiment you are not ready for innovation.

InnovationGeoff Apps, Director of Engineering in Zappos, gave an interesting talk titled “Holacracy at Zappos – how do you manage to deliver value when ‘anything goes’?”. His talk expanded on the journey his company has gone through as it went through the adoption of Holacracy as its operating (or rather Way of Working) model. The Holacracy concept revolves around the creation of purpose driven, self-organised and self-energised teams (known in Holacracy is ‘Circles’). Circles operate in accordance with the Holacracy Constitution and employees are assigned to various circles where they might be playing different roles in each. While no notes were provided by Geoff you might want to check the following article in Forbes which generated an interesting public debate earlier this year.

Holacracy CirclesThe last session I will review here is titled “Impact Mapping – Making an Impact over Shipping Software” by Em Campbell-Pretty. Impact Mapping is a visual technique that attempts to address four key questions: 1) Why you want to do (what ever it is that you want to do) – i.e identify your Goals; 2) Who will do it – i.e. identify the actors; 3) how would that be done – i.e. what are the impacts of what we plan to do; and 4) What will be done – i.e. what are the deliverables that will be produced. The impact of these questions (and associated answers) only becomes apparent when you draw them on a canvas and turn them into a visual board through which all relevant participants are able to view, comment and generate a common and shared understanding pertaining domain under investigation.

Impact Mapping

And a few general comments:

Given the considerable time that now passed, since the publication of the Agile Manifesto, some speakers have taken the opportunity to reflect on the journey and address some of their own observations on the trends and events that transpired since. One comment was made about the apparent attempt to ‘codify’ Agile, i.e. to cement the principles and ideas into a set of ‘do this’ and ‘don’t do that’ processes and procedures. This, generally, was frowned upon with the note that being agile and implementing agility is about being adaptive, experimental and open to change. The point of ‘doing’ agile and of ‘being’ agile is to deliver value to the customer (i.e. to DELIVER) so, in that sense, it is a means to an end – a point that should not be lost on agile practitioners.

Overall an entertaining and thought provoking conference.

Think about it!



Reading some of the conversations around the need to adopt a more exploratory and adaptive approach to estimation (aka #NoEstimates) made me realize that there is something deeper going on here beyond just objecting to the delivery of estimates on ideological grounds. While the arguments against estimation are grounded in seemingly rational and logical observations, they represent, at a deeper level an ideology and a way of thinking that warrants serious contemplation.

Being a member of a team, any team, carries with it some responsibilities. If you are a member of a national soccer team and you happen to bite one of your opponents, this activity reflects on you and is consequently impacting your team. This is why when we talk about the members’ function within the team and within the organization we often refer to it as their ‘role and responsibilities’. Having a responsibility is therefore a part and parcel of your role – one cannot exist without the other. The combination of a role and its responsibilities is a sign and measure of being accountable. In this context, accountability means having a skin in the game, being directly and personally involved in the success or failure of the organization.

Providing estimates for a prescribed activity is a method by which the organization utilizes one’s knowledge, experience and expertise in order to make an investment decision. When you make a claim that the decision maker will be better off proceeding without this estimate you very much proclaim that you wish to NOT have any tangible stakes in the decision to proceed. You wish to NOT be held, even partially, accountable or responsible to whatever transpires. If all goes well you are happy to bask in the glory of the success but should things go pear shape…well, not your fault!

Think about it!

Couple of months ago I was approached by Geoff Crane, a blogger and a Professor of project management at Durham College, to assist with the following request:

I teach project management at Durham College in Ontario. My first batch of students will graduate next month and as a gift I’m looking at putting together an eBook for them…

What advice do you have for project management students fresh out of school who want to break into the discipline?

This is a burning issue for most of them–they’re really looking for advice. As someone with a vested interest in the field, I know your insights will be valuable.

The fruit of my (and other 51 contributors) labor has been collated into a fantastic eBook titled 52 Tips to Break Into Project Management (see also on Slideshare). You can also read my own response below:

Project managers are usually seen by society, and unfortunately by themselves, as being the delivery arm of the organization. As such, one might conclude, their role is not dissimilar to that played by the hand in the human body. The head is where the scope and the vision are being formulated and these sets of governing concepts and rules are then being transmitted to the hand to carry them out. The hand, in this crude analogy, has no room – nor any capacity – to play a devil’s advocate and challenge the brain for the validity of its decisions and as such is expected to blindly follow the instructions received and carry out prescribed mission.

Being a project manager requires one to deliver, to meet objectives, to produce the results, to follow the path chartered for it by its stakeholders. An aspiring project manager might think, not unexpectedly, that he or she has no role to play in validating the morality – in the widest possible sense of this term – of the actions it is asked to lead. Regardless of the domain in which you will find yourself, you will always come across (provided you keep your eyes opened to such situations) where you will need to validate your actions against your moral compass. These might be internal to your project – like, for example, the way you tread your team, the way you respond to pressure and the way and methods you use to communicate with peers and subordinates – or external – where you might turn a blind eye to the impact of the project you are managing on the environment, on people and on society as a whole.

Having been in this game for some time now I lament the fact that in my earlier days no one introduced me to the need to evaluate my actions, all my actions, against my value system. Had I been alerted to this possibility I might have, and quite likely would have reacted differently to some earlier circumstances where I was not yet fully aware of my options and assumed, incorrectly, that my job is to deliver – no matter what.

Think about it!

The Cynefin framework identifies five domains within which systems and environments can co-exist. In summary the five domains are:

  • The ‘Simple‘ Domain – characterized by clear cause-and-effect relationships, with well-defined rules of engagement that call for the use of best practice approaches.
  • The ‘Complicated’ domain – where the relationships between cause-and-effect are not straight forward but are discernible subject to some level of analysis or investigation with the application of expert knowledge.
  •  The ‘Complex‘ domain – where the relationship between cause-and-effect can only be perceived in retrospect
  • The ‘Chaos‘ domain – where uncertainty is abound and no discernible cause-and-effect relationship are known to exist.
  • Disorder‘ – when no clear realization exists regarding the state at which the situation is and where no clear action can be taken due to conflicting views and complete lack of leadership.

When tying the concept of software development estimation with the Cynefin framework one has to consider (or rather ‘sense’) in which domain the system and the environment are and, based on that assessment, tailor the estimation process to account to that situation. The situations most likely to be present at the outset of the estimation process are as follows: Cynefin combinations Some of the objections to carrying out estimates touch on the variability (or rather uncertainty) associated with the state of either the System or the Environment. The Cynefin Framework recognizes the difficulty associated with managing complex situations and suggests an approach to effectively get them managed. Tackling complexity requires resident knowledge about the system and its environment and, more importantly, requires adaptation and openness to learn about them. Experimentation management is the key to overcome the fear of tackling the unknown. Rather than adopting an attitude of ‘it cannot be done’ I would suggest that an attitude of ‘let’s put in a place a process of experimentation so we can tackle the unknown’ would better serve the needs of both those delivering the estimates and those requiring them for business decision-making. Think about it!                       aaa

%d bloggers like this: