Product Development versus Project Development

Agile has been most widely used in “product” development environments and less widely used in “project” development environments.  The difference between those two environments is not widely recognized.  Of course, this is not a totally universal, black-and-white distinction; but, in general:

  • Products are less deterministic and the business model is usually a little more open-ended.  For example, a company might say that we want to develop a product to satisfy “X” market need (where that market need may only be generally defined and might need to be validated) and we’re going to invest $X to fund a team for ongoing development to support that product development initiative.

For many products, it’s an effort that simply goes on-and-on without end to provide ongoing support and enhancements for the life of the product.  Products are generally somewhat speculative and might require a significant amount of innovation particularly if it is something that has never been done before.  For that reason, a product development effort is very well-suited to an Agile development process.

The business model behind a product development effort is typically based on a projected return on investment (ROI) that the decision to invest $X in the ongoing development effort will provide an acceptable return from the profitability that the product will generate over a period of time.

The decision process associated with a  product development effort is generally focused on prioritizing what features should be added to the product to provide the highest level of customer satisfaction and profitability.  That decision process is ideally suited to an agile development process.

  • Projects are typically more deterministic and less speculative.  Very few development teams are given a “blank check” to do some kind of project without having some expectations of what the project will accomplish, what it’s going to cost, and what the schedule will be.

The business model behind projects is also typically very different.  A company typically has a given amount of funding to invest in projects and some kind of project portfolio management approach is generally needed to determine the appropriate mix of projects that will provide the greatest overall benefit.  In order to make that decision, something must be known about the expected results, costs, and schedules of the projects in that portfolio and there is an ongoing need to monitor the performance of those projects to see if they really are going in the right direction to provide the return that was expected.

The process associated with managing a “project” is also typically different…the general nature of the features the “project” will provide would generally be much more well-defined prior to the start of the project, there would typically be some expectations about what the cost and schedule of the project would be, and it probably wouldn’t be completely open-ended to add features as a “product” might be.   These are key reasons why it is more difficult to apply an Agile development model to projects than it is to products.

Applying Agile principles and practices in a “project” development environment rather than a “product” development environment can be a bit more challenging but it definitely can be done.  Agile works best where there are no constraints on costs and schedules and the primary goal is to add features to maximize customer satisfaction (product model).  When you introduce constraints on costs and schedules (project model), this is the area where it is many times appropriate to use some kind of hybrid managed agile approach to meet the competing demands of a highly flexible and adaptive development approach and the predictability of meeting cost and schedule constraints that is often demanded in a project environment.

The Hybrid Agile Development Approach I’ve described in one of my other posts is an example of how this can be done.  It involves wrapping a “shell” around an Agile development process that can be as thick or thin as you want it to be to provide a sufficient level of planning and predictability to meet the needs of the business environment while retaining a lot of flexibility and adaptivity within the development process.

 

Emotional Intelligence and Agile

HelpGuide.org defines “emotional intelligence as follows:

“Emotional intelligence (EQ) is the ability to identify, use, understand, and manage emotions in positive ways to relieve stress, communicate effectively, empathize with others, overcome challenges, and defuse conflict. Emotional intelligence impacts many different aspects of your daily life, such as the way you behave and the way you interact with others.”

“If you have high emotional intelligence you are able to recognize your own emotional state and the emotional states of others, and engage with people in a way that draws them to you. You can use this understanding of emotions to relate better to other people, form healthier relationships, achieve greater success at work, and lead a more fulfilling life.”

Why is that so important in an Agile environment? Because Agile relies so heavily on teamwork and open, honest, and transparent communication both within the team and with other stakeholders outside of the team.

HelpGuide.org goes on to define four key attributes associated with “emotional intelligence”:

  • Self-awareness – You recognize your own emotions and how they affect your thoughts and behavior, know your strengths and weaknesses, and have self-confidence.
  • Self-management – You’re able to control impulsive feelings and behaviors, manage your emotions in healthy ways, take initiative, follow through on commitments, and adapt to changing circumstances.
  • Social awareness – You can understand the emotions, needs, and concerns of other people, pick up on emotional cues, feel comfortable socially, and recognize the power dynamics in a group or organization.
  • Relationship management – You know how to develop and maintain good relationships, communicate clearly, inspire and influence others, work well in a team, and manage conflict

Source: http://www.helpguide.org/mental/eq5_raising_emotional_intelligence.htm

The easiest way to see how this impacts the performance of Agile teams is to observe the behavior of someone who has a low level of emotional intelligence. Here is an example: on an Agile team I’ve worked with, there was one particular individual who was very bright and intelligent but had a very strong and dominating personality and what I would consider a low level of emotional intelligence:

  • He liked to be in control of everything and be seen as the “hero” who is leading the entire effort – there was a saying on the team that if it’s not XX’s idea, it sucks
  • He was opinionated and confrontational, didn’t value other people’s perspective, and attacked other people openly in emails
  • He had such a vested interest in his own ideas and proving himself “right” that he lost objectivity and wasn’t able to see different sides of a decision

How does that impact the effectiveness of an Agile team?

  • It can stifle the contribution of others on the team – it’s well known that more minds can work better than one and the performance of a team is maximized when everyone on the team is fully engaged and actively contributing to decisions and the work of the team.
  • It can lead to poor decisions because decisions may be biased in favor of one person’s point of view and may not objectively consider all aspects of the problem

Here’s some excellent additional reading on this subject:

http://www.helpguide.org/mental/eq5_raising_emotional_intelligence.htm

How do you acquire “emotional intelligence”? I believe that the first and most important step is self-awareness – you have to be somewhat introspective and be able to look at yourself openly and honestly and also learn to be comfortable being open and transparent with others. That doesn’t come naturally to all people and requires a certain amount of self-confidence to develop. Many people have a “shell” that they operate within and that “shell” can be either thick or thin. There’s a concept that I learned a long time ago called the “Johari Window” that is still valid today. The Johari Window breaks up people’s self awareness into four quadrants:

  1. Open/Free Area – Personality attributes and characteristics that are known to yourself and to others
  2. Blind Area – Personality attributes and characteristics that are known to others but not by yourself
  3. Hidden Area – Personality attributes and characteristics that are known by yourself but not by others
  4. Unknown Area – Personality attributes and characteristics that you are not fully aware of and others are also not aware of.

Source: http://en.wikipedia.org/wiki/Johari_window

Alan Chapman has created a very nice diagram that shows the relationship of these four quadrants:

Johari Window

Source: http://www.businessballs.com/johariwindowmodeldiagram.pdf

People who have a high level of self-awareness and who are also open and transparent in their behavior with others have a relatively large quadrant one (Open/Free Area) and the other quadrants are relatively small. Of course, the objective of increasing your self-awareness, openness, and transparency is to increase the size of quadrant one (Open/Free Area) relative to the size of the “Blind” and “Hidden” quadrants. Another objective is to more fully develop your true potential through self-discovery of skills, attributes, and characteristics in the “Unknown” area that neither you or others you interact with are fully aware of.

Years ago, I can remember many companies made self-awareness training a key part of their management development curriculum for new managers. The principle behind that was that you couldn’t be very effective as a manager if you had a hidden personal agenda and you weren’t open and transparent in your relationships with other people. Your employees will recognize the external veneer that you put on, see right through it, and lose respect for you.

Unfortunately, over the years, many companies have cut back on that kind of training. It was perceived as too “touchy-feely” and when times got tough, it was one of the first things that got cut because it was not seen to have a direct contribution to company profitability. The relationship to company profitability may be indirect, but I think it is just as essential today for managers and even more important for people participating in Agile teams.

There are some exercises that can be done with Agile teams to develop higher levels of self awareness. For example, here’s a Johari Window self-assessment tool:

http://kevan.org/johari

A key element for successful implementation of these exercises is creating an environment of trust where people feel comfortable with being open and honest with others in a small group. Once people have become comfortable with doing that in a small group, they can then take more risks and practice the same behavior outside of that small protected group environment.

Is Agile Like the Steam Engine?

I recently participated in a LinkedIn discussion in which the author of the discussion made a statement that “Agile is by definition a software development methodology”. I didn’t agree with that statement at all…Its unfortunate that the word “Agile” has acquired that connotation in actual usage by a number of people but that’s just sloppy use of terminology (similar to the sloppy use of the word “Waterfall” that I’ve talked about) and its also somewhat narrow thinking.

The author of that discussion defended his statement that “Agile is by definition a software development methodology” by saying that “The Agile Manifesto starts with these words ‘We are uncovering better ways of developing software'”. That statement doesn’t work either in my opinion – I’m sure that was a key motivator behind creating the Agile Manifesto but that was in 2001 which was 12-13 years ago and our concept of what Agile is has grown significantly since that time.

I was trying to think of a good analogy to illustrate this point and somehow I thought of the steam engine. The steam engine was originally invented in 1698 by Thomas Savery who was working on the problem of how to pump water out of coal mines. Thomas Newcomen improved on the design but it wasn’t until Scotsman James Watt improved on the steam engine in the second half of the 18th century that it became truly a viable piece of machinery that helped start the industrial revolution. Even though that started the industrial revolution across the whole world, very few people in the 1700’s would likely imagine that that was only the beginning and the same principles originally used to use to pump water out of coal mines would have a much broader usage in the future including powering nuclear power plants.

(Source: http://americanhistory.about.com/od/industrialrev/p/steamengine.htm)

I think Agile is very similar…

  • The roots of Agile go back a lot further than 2001 – you can very easily trace the roots of Agile to TQM and Lean Manufacturing long before 2001 and the evolution of iterative methodologies like RUP certainly also had an influence. The period prior to 2001 was probably equivalent to pumping water out of coal mines
  • Learning to apply The Agile principles to software development in the Agile Manifesto in 2001 was a real breakthrough that is probably similar to James Watt learning how to apply steam to operate industrial machinery that started the industrial revolution across the world. It had major impact, but that was only the beginning
  • Just as James Watt probably never envisioned the use of steam power in nuclear power plants, the signers of the Agile Manifesto probably never fully envisioned widespread implementation of those principles in many other areas beyond software development

In common usage, some people think that the word “Agile” only applies to software development; to other people, the definition is even narrower and you’re only truly Agile if you’re doing Scrum and doing it strictly by the book with no variation. in my opinion, this really is just sloppy use of terminology and narrow thinking in how the word “Agile” is being used. Our understanding of what “Agile” is is still at a very early stage probably very similar to when James Watt learned how to apply steam technology to operate industrial machinery and limiting our thinking about what “Agile” is may prevent us from imagining new applications and ways of using Agile principles and practices that no one has even dreamed of yet.

More on Agile versus Waterfall

I previously wrote a post on “Agile versus Waterfall” that a number of people seemed to like:

https://managedagile.wordpress.com/2013/08/02/agile-versus-waterfall/

The essence of that post was that when people use the term “Waterfall”, the use of the terminology “Waterfall” is typically somewhat sloppy. The real definition of the word “Waterfall” can be traced back to Winston Royce’s paper that was written in 1970 (a copy is available here):

Click to access waterfall.pdf

(Thanks and acknowledgement to Wayne Mack for providing this reference and inspiring me to write this post)

Here’s an example of this from an invitation to attend a presentation I received that is actually being given this week in the Boston area:

“It would be so easy if everyone at our companies just used Scrum — or at least Agile. No one would lean on the team for dates and deadlines, and everyone would know that change is a good thing. It’d be one great big happy project management family. But let’s face it — an all-Agile organization isn’t always possible. Maybe you have a Project Management Office (PMO). Maybe you work for a government contractor. Maybe you have regulatory requirements. Maybe you’re the first Scrum/Agile project at your company. Maybe your company simply *likes* it this way. Whatever the reason, Agile teams frequently report into Waterfall organizations.”

What do they mean by a “Waterfall organization”? This is a perfect example of sloppy use of terminology. In this particular case, there is an implication that a “Waterfall Organization” is one that plans and manages projects with some kind of schedule and there is also an implication that that sort of planning and management of schedule expectations should never be done in an “All Agile” organization.

When people use the word “Waterfall” like this, I’m tempted to ask, “Which aspect of ‘Waterfall’ are you referring to?”

  • Are you referring to the phase gate approach where a project is broken up into phases and there is a phase gate for approval to transition between phases? I don’t think that approach has been widely practiced for years for software development projects and, as this paper indicates, Winston Royce himself had reservations about it. Long before Agile became widely used people began using an iterative approach to projects using RUP or variations on RUP.
  • Are you referring to an over-reliance on documentation? That is a more legitimate comparison because Winston Royce did come out very strongly in support of a lot of documentation, but that shouldn’t imply that an Agile project has no documentation whatsoever.
  • Are you referring to the tendency to plan an entire project upfront before starting the project and then manage changes to the project requirements through change control? That also might be a legitimate comparison, but it also shouldn’t be meant to imply that an Agile project shouldn’t do any planning upfront.
  • Are you referring to the practice of using loosely-coupled teams from different organizations (such as engineering, test, operations, etc.) to perform a project instead of well-integrated teams? That also might be a legitimate comparison, but that is not really an attribute of the “Waterfall” methodology itself at all, it is more of a characteristic of how organizations have typically been managed.

In many cases, when people use the word “Waterfall”, its not very precise and people are using the term “Waterfall” loosely to refer to any kind of bad software development practices. This has also created the notion that there is an all-or-nothing decision between practicing Agile and practicing “Waterfall” – in other words, Agile equals Scrum (but only when it is done “by the book”) and Scrum is good; everything else is “Waterfall” or not really Agile and is bad. Don’t get me wrong, I’m very passionate about Agile and believe in it strongly, but I think this kind of simplistic thinking is what has caused so much polarization between proponents of Agile principles and practices and proponents of more traditional project management principles and practices.

This kind of simplistic comparison causes people to think that there is an “All Agile” approach at one extreme where there is no planning and no documentation whatsoever and a totally rigidly planned and controlled approach at the other extreme called “Waterfall” and nothing in between those two extremes. That is the notion that I’ve tried to dispel in my two books on this subject.