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!

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...
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.

Related Post

Is The Time Ripe For The Agile Revolution? One of my favourite books (and films) is "The Lord of the Rings". There are many situations presented in this book which make me pause, think and cont...
All About Awkward Agile Thinking People love slogans. They love slogans because they need something to hang on to. A stake in the ground, a beacon they can point their sinking ship to...
Implementing Earned Value Management in Agile Introduction The purpose of this article is to illustrate the way in which the Earned Value Measurement (EVM) approach is introduced into an Agile de...
Let’s Be Serious About the Agile Manifesto The Agile Manifesto states that: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we ha...
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.

Related Post

Is The Time Ripe For The Agile Revolution? One of my favourite books (and films) is "The Lord of the Rings". There are many situations presented in this book which make me pause, think and cont...
All About Awkward Agile Thinking People love slogans. They love slogans because they need something to hang on to. A stake in the ground, a beacon they can point their sinking ship to...
Implementing Earned Value Management in Agile Introduction The purpose of this article is to illustrate the way in which the Earned Value Measurement (EVM) approach is introduced into an Agile de...
Let’s Be Serious About the Agile Manifesto The Agile Manifesto states that: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we ha...
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!

Related Post

Is The Time Ripe For The Agile Revolution? One of my favourite books (and films) is "The Lord of the Rings". There are many situations presented in this book which make me pause, think and cont...
All About Awkward Agile Thinking People love slogans. They love slogans because they need something to hang on to. A stake in the ground, a beacon they can point their sinking ship to...
Implementing Earned Value Management in Agile Introduction The purpose of this article is to illustrate the way in which the Earned Value Measurement (EVM) approach is introduced into an Agile de...
Let’s Be Serious About the Agile Manifesto The Agile Manifesto states that: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we ha...
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!

Related Post

Is The Time Ripe For The Agile Revolution? One of my favourite books (and films) is "The Lord of the Rings". There are many situations presented in this book which make me pause, think and cont...
All About Awkward Agile Thinking People love slogans. They love slogans because they need something to hang on to. A stake in the ground, a beacon they can point their sinking ship to...
Implementing Earned Value Management in Agile Introduction The purpose of this article is to illustrate the way in which the Earned Value Measurement (EVM) approach is introduced into an Agile de...
Let’s Be Serious About the Agile Manifesto The Agile Manifesto states that: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we ha...
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!

 

 

Related Post

Is The Time Ripe For The Agile Revolution? One of my favourite books (and films) is "The Lord of the Rings". There are many situations presented in this book which make me pause, think and cont...
All About Awkward Agile Thinking People love slogans. They love slogans because they need something to hang on to. A stake in the ground, a beacon they can point their sinking ship to...
Implementing Earned Value Management in Agile Introduction The purpose of this article is to illustrate the way in which the Earned Value Measurement (EVM) approach is introduced into an Agile de...
Let’s Be Serious About the Agile Manifesto The Agile Manifesto states that: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we ha...

Introduction

The raging debate surrounding the #NoEstimates concept has left me with a sense of frustration one usually feels when coming across an unfinished business. While a number of individuals on both sides of the debate have attempted to address the key differences of opinion, the question still seems to be unresolved with each side sticking to their guns, unable to agree on a common ground or a framework of understanding in which all parties can feel vindicated. In this post I will attempt to outline the key arguments for and against #NoEstimates. When possible and if appropriate I will quote these arguments verbatim, sourcing them from a number of blogs where this topic has been discussed (sometimes indirectly) extensively. I will provide links to these quotes but do my utmost to ensure I do not take these quotes out of context.

The format I plan to adopt for this post is as follows. Each argument, in favor or against the #NoEstimates proposition, will be listed and a statement in support and against the proposition will be provided. whenever appropriate I will add further commentary where I will attempt to narrow  the gap and articulate the assumptions arising from each or both arguments.

As the end of this post I hope you will have a better appreciation of the arguments and you will gain the ability to articulate your own answer to the following questions:

  1. Are cost estimates required in order to manage software projects?
  2. Are cost estimates an effective tool for controlling costs?
  3. Do estimates stifle creativity and kill innovation?
  4. Do people need estimates? And if so, why?
  5. Is the very act of estimation results in the creation of uncertainty?
  6. Is estimation a practice still hanging over from the Waterfall era?
  7. Is No Estimation better than Bad Estimation?
  8. Is  Estimation really just a form of Guessing?
  9. Are estimates necessary for Governance? Is it reasonable to require estimates for the purpose of pacifying governance needs?
  10. Is there any point in providing estimates when it is known that many projects fail due to lack of credible estimates? And aren’t estimates a tool used to apportion blame afterwards anyway?
  11. Is costing a necessary tool for determining business value?
  12. Does the scope drive the budget or does the budget drive the cost?
  13. If estimates are required in order to support decisions, can decisions be made without estimates?

We have a lot to cover so let’s make a start!

Discussion

1. Making software development decisions based on estimates are counter intuitive

#NE – There is a tendency in software development to, counter intuitively, take a reverse approach to budgeting we would employ when we make purchasing decisions in our lives. Instead of deciding our budget based on how much we have available, or are willing to spend – as we would personally do – we decide it using an estimate from the supplier of how much they tell us the software that we want will cost. So, while we have a pretty good appreciation of how much much we have, want or willing to spend, we are unnecessarily engaged in a bidding process with the view to find the cheapest bidder in order to save money and squeeze as much as we can for our real budget. In such case, would we not gain a better outcome if we work iteratively and collaboratively with the supplier based on our budgetary and / or time constraints? (link).

#E – The claim that iterative and collaborative work can be used as a substitute for up-front estimation of cost is challenged by Mike Cottmeyer in “Should You Use Agile to Build Your Next Home?“. The gist of his argument is that most people when they are spending their own money, want to have some idea of what they are going to get when the time and money run out. They want some assurance that they’ll have enough of the product they have ordered to make the whole investment worthwhile. Suggesting an incremental delivery, while appealing in theory, is not necessarily a practical outcome as even a fully functional software, when lacking the greater context might be unusable (just like having a fully functional kitchen might not be usable unless the bedrooms and the other amenities have also been complete).

The other factor worth mentioning here is the behavioral aspect driven through our understanding of economic theories. The concepts of Scarcity, Opportunity Costs and Cost Benefit Analysis dictate that people, intuitively, would look to determine future value before they make an investment decision. This determination is done, among other methods, by comparing one perceived outcome against other alternatives, and selecting the one that maximizes the perceived value (or Return on Investment).

2. Estimates are seldom correct so why use them?

#NE – A casual search on Google will reveal that faulty or wrong estimation is seen as one of the leading reasons for projects’ failures. Proponents of  the #NoEstimates proposition raise the following arguments regarding the lack of credibility associated with the provision of estimates:

  • Estimates are often gamed, and for various reasons (link)
  • They are often based on zero to low knowledge (link)
  • They are often being plucked out of thin air (link)
  • Time and cost estimates are based on an up-front estimate of scope (i.e. a guess) and as such are guesses at best, leading to obvious dysfunctions like death-marches, low quality, etc. (link)
  • Asking teams to estimate how long their work will take has connotations that their output is being measured by an external party (management), creating an environment of fear and massaging figures to reflect what is desired rather than what i predicted (link)
  • We should’t be defining all our scope up-front, meaning we shouldn’t estimate all our scope up-front, meaning we shouldn’t be defining our delivery date based on our scope (link)
  • It seems like we keep failing at getting good at estimates, even though we are working hard at becoming better at doing so, then maybe we are expecting estimates to do something for us that just can’t be done. (link)
  • Estimates, quite often, are a result of a a wild guess, aimed at providing some numbers that seem plausible and will allow the decision makers to approve the start of a project with a clear conscience. That is, when things sour later on, they can always blame the developers for giving them inaccurate estimates. And the developers can always blame the ‘requirements people’ for giving them unclear, incorrect, or incomplete requirements. And the requirements people can always blame the stakeholders for providing bad direction about what was important. And so on. Regardless of who is part of this process, it is one big happy circle of blame that lets us all do the wrong thing and still keep our jobs… (link)
  • When estimating a date or cost you are creating uncertainty around those things, because you are guessing. You are saying “we’ll deliver somewhere between here and here”. However, if your delivery date and/or cost is set by a real constraint, as advocated by the #NoEstimates approach, you have created certainty around those things. (link)
  • And see also Jens Schauder’s ‘8 Reasons why Estimates are too low‘ and Glen Alleman’s specific response.

#E – The arguments against estimates can be classified into two categories; practical and behavioral.

Lets’ start with the practical considerations first:

‘Doing’ estimates right (though not necessarily correct) requires effort. While we are all accustomed to performing estimates in most facets of our lives (when we drive our car, rush to the station to catch the train, do our shopping at the supermarket, etc) there are instances or circumstances in which making the wrong estimate can have more severe consequences. If we try to cross the street and misjudge the distance and speed of an approaching car we could be involved in a fatal accident. If we misjudge the effort required to develop a software feature we could end up being responsible for a business loss that could affect our very livelihood.

When we make an estimate we always take a risk. When we buy one bottle of milk for our daily morning coffee we base our purchasing decision on past experience coupled with some probability assessment regarding the likelihood of past patterns breaking up in the future. While we don’t explicitly enunciate that level of uncertainty, we subconsciously are aware of it. We know, intuitively, that it is never 100% but are happy to concede that there is X% probability (perhaps 90%) that one bottle of milk would be sufficient to meet our needs for the next few days.  Had the probability been low, we would most likely buy two bottles.

While making decisions (based on estimates) come naturally to us when we cross the road, the reason why we are comfortable making these probability assessments is because we have learned to execute them based on past experience. From an early childhood our parents have taken our hand and instilled in us the need to accumulate experience and knowledge we could utilize at a later age, without giving it much thought. Statisticians and Economists would call this process Reference Class Forecasting (and see Kailash Awati’s elaboration on this topic in Improving Project Forecasts).

In the world of software development we are asked to exhibit the same assessment skills with the appreciation that our reference class might not be obvious up front – i.e we might be having a Reference Class Problem. In a nutshell, this problem “…arises when we want to assign a probability to a proposition (or sentence, or event) X, which may be classified in various ways, yet its probability can change depending on how it is classified ” (from The Reference Class Problem is Your Problem Too, in Kailash Awati’s The reference class problem and its implications for project management).

At the practical level, being dismissive of the validity of estimation could be an attempt at avoiding the need to establish a reference class. If you don’t have a reference class on which to base your estimates then (as often argued by Glen Alleman) build one, run a pilot project, execute an experimental iteration, ask others who’ve done something similar. Do something to reduce the uncertainty and increase the certainty. There should be no excuses for not trying to establish some level of reference class baseline and progressing based on that starting point.

And now to the behavioral considerations…

The notions of gaming the estimates, plucking figures out of thin air, perceiving estimates as a mean to establish a management control and associating estimates with future apportioning of blame are all symptoms of a dysfunctional organizations. The business dilemma we need to address is whether the elimination of estimates would turn the organization into a functional one or would that just be a way of dealing with the symptom while ignoring the real problem. A better proposition should be to suggest methods to change the organizational behavior such that these attitudes are transformed into more suitable ones. Implementing the practical practices established for the delivery of estimates can go someway towards ‘fixing’ the organization. If you are a strong and vocal proponent of #NoEstimates you could equally be in a position to strongly support calls for taking the necessary steps needed to change the organizational attitude such that developers would not feel under siege every time an estimate is required (and see also the discussion here re. dysfunctional organizations).

3. Estimation = Waterfall

#NE – Estimation is seemingly one of the few remaining immutable practices hanging over from the waterfall era (link). Waterfall and predictions are harmful (link).

#E – See Mike Cottmeyer in “Should You Use Agile to Build Your Next Home?“. Tying estimates with Waterfall is not a solid argument and it seems to appeal to those with emotional associations tied to the Agile vs Waterfall metaphorical divide.

4. Why do customers need estimates?

#NE – The main reason we do estimates is because people need to make decisions. This means that the key requirement is for people to be able to make decisions. It is true that estimates are often used to help us make decisions. But estimates are not the only way and for many of the decisions we need to make they are likely not the best way to go. One good way to make decisions is by adopting the “lean approach”, by learning from our mistakes and by frequently taking corrective action (link).

#E – There is no disagreement about the conjecture that estimates are required to make decisions. As highlighted earlier, whether or not we are engaged in formal and conscious estimation process – we are still estimating sub-consciously.  And we do it because this is how we intuitively engage in risk management. We are always on the look for signals of danger and for opportunities. And while we are engaged in this type of behavior in every facet of our lives, we should more inclined to exhibit such behavior when spending other people’s money. The type of decisions we need to be able to ethically make are about whether we ‘buy’ this software or ‘make’ it.  Do we invest the money in this product or in any one of a number of other opportunities.

The decision regarding the investment path to be taken cannot be solely based on the perceived business value, as while a number of development opportunities might present a value proposition, the value differentiation might not be so clear as to determining the one we ought to pick for further development. And this is where cost becomes a deciding factor. It is called cost-benefit-analysis and it is a sensible risk management strategy.

Some final notes

The discussion surrounding the #NoEstimates proposition is one we need to have. The issues highlighted here are not raised with the intention to keep people from exploring and challenging established assumptions but rather as a concern against applying judgement without considering the context and landscape within which these judgments ought to be made.

No doubt #NoEstimates could work in environments where such a proposition will be accepted by the stakeholders who’s money is put on the line.  While I have not yet had the opportunity to operate in such an environment does not mean that such environment does not exist. And this is exactly the point where context need to be injected into the discourse around this issue. It is about establishing known boundaries or parameters within which #NoEstimates can (and perhaps also ought to) work. Some mention areas of R&D as suitable for this and perhaps this is correct. Establish a budget you are willing to use for experimentation (based on your risk appetite) and let the team iterate until such time that you either run out of money, run out of risk appetite or hit the bull eye. Other areas could be small developments with low risk. The domain is known and the time taken to produce formal estimates is better get used on actual development. There is, however, a need to avoid broad categorizations that add little to no credibility to the argument and add a sense of religious ideology to a domain that requires no such similarities.

Think about it!

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...

Introduction

In a paper (presented as an overview to his completed doctoral thesis) titled An investigation into the prevalence of modern project management by means of an evolutionary framework”, Dr. Jon Whitty deals with the application of evolutionary principles to the domain of project management. He explains at the outset that:

Evolutionary principles can be applied to cultural matters too, in the sense that the practices, artefacts, beliefs, concepts and ideas we find around us today are there because they too have been selected (allowed or enabled to survive and reproduced) by individuals (because by using them or taking them on board benefits the individual is some way) or by organisations (because individuals acting for the organisation select them because of perceived benefits to the organisation).

This provides the foundational justification for comparing a seemingly biological process to a domain that on the surface seems completely disconnected from such discussions (and see my extended review of Jon Whitty’s paper here).

Discussion

Terry McKenna (whose earlier paper was reviewed here some time ago – see here and here) has collaborated with Jon Whitty to produce another thought provoking paper, titled: “Agile is Not the End-Game of Project Management Methodologies“.

The paper sets out to challenge the common perception, held by many (and admittedly by me as well), that the Agile movement represents a revolutionary movement, i.e a movement introduced as a counter measure to its surrounding environment and not as a by product of it (by which means it would be seen as an evolutionary movement).

Proving this point, one way or another, can only be done by exploring methods and ideas used in the past and then evaluating whether these methods and ideas have been replicated into an accepted method and ideas within the area of Agile thinking. To explore this question the paper makes use of the concepts of Memes and Memeplexes.

For those unfamiliar with Richard Dawkins‘ ‘The Selfish Gene‘, a Meme (as define in Wikipedia) is “an idea, behavior, or style that spreads from person to person within a culture. A meme acts as a unit for carrying cultural ideas, symbols, or practices that can be transmitted from one mind to another through writing, speech, gestures, rituals, or other imitable phenomena.” In the context of Project Management, concepts and methods like the Gantt Chart, CPM and the WBS could be seen as Memes that over time established themselves as acceptable ideas within the project management community, as summarized in the paper:

For our purposes, a ‘meme’ will likely equate to a specific project management method, tool or artefact which is sufficiently recognisable as representing a discrete ‘idea.

A Memeplex (again, according to Wikipedia) is a “group of Memes that are often found present in the same individual. Applying the theory of Universal Darwinism, Memeplexes group together because memes will copy themselves more successfully when they are ‘teamed up’.” In the context of project management, a project management tool like MS Project could be looked at as a Memeplex as it is a collection of Memes that copy, or replicate, more effectively together. Or, as summarized in the paper:

a ‘memeplex’ can be seen as a means to facilitate conjoining or interacting of these memes to their greater good (i.e. survival and propagation).

The paper, meticulously, demonstrates how the thread of Memes that started with the Taylorism and the Scientific Management movement, through the creation of the Gantt Chart, the establishment of the ‘4-step training process’, the creation of the Process Charts and work Simplification (and a few other processes and movements) have culminated, in the post WWII era, with the Toyota Production System (TPS) and the Lean Software Development. And on another evolutionary path, and another thread of Memes – resulting in the Iterative and Incremental Development – is a culmination of processes that started with the American Air-force in the 1950’s, through NASA’s Project Mercury, the Iterative approaches to modelling and Iterative enhancements, all leading to what is currently known as incremental development.

Based on the above analysis the paper concludes that

‘agile’ approaches are by no means ‘new’, but rather are result of a selection process

[…]

the current state is an accumulation of memes and memeplexes, chosen to suit environmental circumstances.

With that in mind the paper posits that the evolutionary nature ascribed to the formulation of the current set of agile methods suggests that this evolution is far from over and that further changes are likely to emerge in the future.

Some concluding notes

The paper provides a solid and compelling argument regarding the evolutionary rather than revolutionary nature of the Agile methods. Indeed, the methods themselves and the memes within which they are wrapped are not new. The paper mentions the fact that these various methods (and memes) have been incorporated into agile memeplexes and while it acknowledges the fact that in some contexts a memeplex can also be seen as being a meme in its own right – as the group of memes making up the memeplex become a unified idea that attract an independent evolutionary cycle – a greater importance could have perhaps been attributed to the possibility that while the memes have been around for quite some time it is the memeplex, i.e. the grouping and collection of these methods and ideas, that should be the center of this investigation and as such its creation is a less obvious or trivial occurrence and thus it does represents a somewhat more revolutionary idea.

The paper is also a timely and important reminder to the fact that a lot of what we see, hear or read around us is a result of or a spin off past actions. This is fantastically illustrated in the Everything is a Remix series and, when taken in context, is a timely reminder for placing our egos and achievements in the appropriate context of those who preceded us.

Think about it!

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...

If you are a C-level manager in an organization that has instituted some level of agility in its software development environment you should be congratulated. But don’t let this achievement get to your head as if this is as far as your drive to agility is allowing you to go you are not reaping the real benefits agile can bring to your organization.

Let me explain why.

One of the guiding principles at the core of agile thinking is the recognition that action, any action, is best prioritized based on its perceived value. In that sense then, high value propositions will receive a higher priority compared with low value propositions. In the context of software development this means that high value features will be attended to before diverting attention to low value features. When adding to the above the consideration of ‘Minimum Viable Product’ (MVP) – i.e. the recognition that a product could be released with just a sufficient level of functionality that would make it a viable product (leaving out other features not necessary to make it ‘viable’) – and the importance of value driven development is further accentuated.

There is aspect to the above scenario that makes it a winning proposition, and that is the constant iterative nature of validating and re-validating the business value of requested features.  This means that rather than determining a prioritized list upfront, and then fixing that priority list throughout the project’s life-cycle, the priority is being examined and validated on a regular basis and as often as two weekly cycles.

And here’s the catch.

There is a fair (almost high) chance that while you allow your development process to ‘run’ using the above scenario, you are reluctant (due possibly to lack of due consideration) to apply an identical process to your own decision-making process. No doubt you make investment decisions based on value, but that value is determined based on  heavily documented business cases that allow little room for cross proposal evaluations and hinder your ability to easily compare value across competing proposals. You also lack flexibility in changing direction, once investment decisions have been made, and you (most likely) spend considerable time and effort in wrestling with other executives in an attempt to secure the funds that your area requires for the next financial year.

Imagine you were adopting some agile practices to manage that process differently:

  1. Rather than spend significant time and money on the formulation of heavy weight business cases you would adopt a MVP mentality such that the business case is reduced to a level allowing you to make a go-no go decision.
  2. Use a Kanban wall to present all business cases and thus allowing the executive management team to literally compare all competing requests and collectively agree on the current priority list.
  3. Institute a recurring value review to ensure your investment decisions and investment money is still delivering most value for money.

Makes sense?

Think about it!

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...

I’ve been rewriting my LinkedIn profile.

I found  my earlier version of my profile to be overly pretentious, heavy on marketing statements that sound more like a sales pitch than reflecting the true me. I got rid of all this junk and then set out to re-write. As I was thinking about what to write it occurred to me that the best way to represent myself would be through my values. If people want to engage with me they may as well know what I am all about and what I represent.

  • I value rational thinking over dogmas and authority;
  • I value real friendship over Facebook friends;
  • I value honesty over pretentious;
  • I value people over processes;
  • I value truthfulness over falsehood

Having written up these values I spend some time looking at them to figure out where they have come from. My conclusion was that my current thoughts and attitudes have been shaped by my previous experience – from much earlier in my professional career – as an economist and from my more recent encounter, exposure and experience with Agile Thinking.

What are your core values? Do you know what they are? Do other people know what they really are?

Think about it!

 

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...
%d bloggers like this: