The “Lean Startup” approach is based on a book by Eric Ries of the same name. The fundamental problem that the book addresses is that many companies:
Think that they know what the market and their customers want,
Make a lot of assumptions based on that thinking
Launch a long and expensive product development effort to meet what they think are those needs, and
Then find out that those assumptions were wrong
That approach is typical for a company with a traditional plan-driven approach to project management. (That is what many people loosely call “Waterfall”). The problem isn’t really unique to startups; this problem can take place with any company of any size – it may happen more frequently with startups just because there is normally a higher level of uncertainty associated with a startup.
What’s the Solution?
The solution to this problem is to use an incremental and iterative approach to product development. That approach should have lots of customer input and feedback along the way. That approach is exactly what is used in an Agile product development effort. The approach would look something like this:
It’s easy to see how this approach can significantly reduce the market risk associated with new product development. And, it is appropriate for any company (not just startups).
Instead of committing to a long and expensive development process on the basis of some limited number of assumptions that may later to be wrong;
It treats those assumptions as only a “hypothesis” and seeks to validate those assumptions (hypotheses) as the project is in progress.
How Does This Fit With Agile?
The product development approach recommended by the Lean Startup method is essentially the same as an Agile/Scrum product development approach. It is based on an incremental and iterative development process with lots of direct customer input and feedback.
The Lean Startup approach goes somewhat beyond an Agile/Scrum approach.
The approach focuses on how the business strategy behind the product is developed and validated, which an Agile/Scrum process does not directly address.
In practice, this concept can be applied at many different levels. It is not limited to a single product development effort and it is not limited to startups. There are potentially multiple levels in any enterprise-level Agile implementation as shown in the diagram below:
The implementation of this is really at a higher level than the development process. It is at a business strategy level and a product strategy level. At each level in an enterprise:
There may be different levels of uncertainty and
Each level may call for a different planning approach based on the level of uncertainty at that level
Planning in an uncertain environment can be very difficult. Here’s an article that goes into that in more detail:
The “Lean Startup” approach is a good, common-sense approach to planning that is very appropriate for an uncertain environment. It acknowledges the level of uncertainty in the environment:
Rather than glossing over the uncertainty and making assumptions about it to try to make it go away
It uses an incremental and iterative development effort to validate those assumptions as the project is in progress
This approach is not unique to startups; it can apply to a company of any size and level of maturity. It can also be applied at any organizational level and any level of planning and management in a company based on the level of uncertainty in the company at that organizational level or level of planning and management.
Why is automated regression testing important in an Agile environment? An Agile development approach can dramatically improve the quality of software, but it requires a very different approach to software testing. Here’s a previous blog post with more on why an Agile testing approach makes so much sense:
What’s the Impact of Agile on Regression Testing?
Because the testing approach is so different, regression testing; and, in particular automated regression testing becomes a lot more important:
In a traditional plan-driven project management approach (Waterfall), all testing is typically done at the very end of the project
At that point-in-time, all software development is normally complete and the software is stabilized
In an Agile environment, software testing is done concurrently with development throughout the project
As a result, software is still changing as it is being tested
The difference is shown below:
A big challenge this creates is this:
In a Waterfall-style development process, the software should be stabilized once it goes into testing
In an Agile environment, the software is continuously changing throughout the project. During each sprint, in addition to testing new functionality, it is essential to do regression testing. The purpose of regression testing is to verify that some new changes haven’t inadvertently broken something that was previously tested
In a large, complex project, the number of features requiring regression testing will grow significantly as the project is in progress. That makes it almost impossible to do manual regression testing. Attempting to do manual regression testing would slow down the progress of the project significantly if it can be done at all.
For these reasons, it is important to do regression testing to ensure the quality and integrity of the software in an Agile environment. And, for a large, complex software project, automated regression testing becomes essential.
I’ve seen a lot of questions about Unified Modeling Language (UML) that center around “Is UML still relevant today?” and “How is it used in an Agile environment?”. I will try to address these questions in this blog post.
What is UML?
UML stands for “Unified Modeling Language”. Here is a definition of UML:
” The goal of UML is to provide a standard notation that can be used by all object-oriented methods and to select and integrate the best elements of precursor notations. UML has been designed for a broad range of applications. Hence, it provides constructs for a broad range of systems and activities (e.g., distributed systems, analysis, system design and deployment). “
“In 1994, Jim Rumbaugh, the creator of OMT, stunned the software world when he left General Electric and joined Grady Booch at Rational Corp. The aim of the partnership was to merge their ideas into a single, unified method (the working title for the method was indeed the “Unified Method”). “ Visual Paradigm website
“Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models.
Provide extensibility and specialization mechanisms to extend the core concepts.
Be independent of particular programming languages and development processes.
Provide a formal basis for understanding the modeling language.
Encourage the growth of the OO tools market.
Support higher-level development concepts such as collaborations, frameworks, patterns and components.
Integrate best practices.“
UML is typically used to simplify a lot of written documentation. It provides a visual model of how a system works and how it is designed.
UML is intended to satisfy a broad variety of interests. It consists of a number of different diagram types that show the system from different perspectives. Those diagram types can be grouped into two major categories:
Structure Diagrams – “Structure diagrams show the static structure of the system and its parts on different abstraction and implementation levels and how they are related to each other.”
Behavior Diagrams – “Behavior diagrams show the dynamic behavior of the objects in a system, which can be described as a series of changes to the system over time“
How Does UML Fit Into a Software Development Process?
UML diagrams are heavily-associated with what is called “Big upfront design”. That is typically what is called a “Waterfall process where:
The requirements for the process, as well as
The design of the software to satisfy those requirements can be defined in some level of detail upfront prior to the start of the project.
In that kind of environment, UML diagrams are a way of presenting a visual, diagramatic view of what is in the requirements documents and how the design will be implemented and that can be particularly useful for large, complex projects.
UML obviously works best in a sequential Waterfall process as shown here:
In this type of process,
The requirements definition phase would typically take place first
Then, UML behavior diagrams might be used to define the most critical behavioral characteristics of the system from a user perspective
Those diagrams might then serve as input to the design process where the design of the system would be laid out to satisfy those requirements
Once the design process is complete, UML structure diagrams might be used to define the expected overall structure of the system from a design perspective
Those diagrams might then serve as input to the development process to implement the design of the system
In this type of environment, the UML diagrams provide two different kinds of value – UML:
Provides a communications mechanism to summarize the information that is in various project documents. That is useful to transition that information from one phase to the next
Can also be used for support purposes after the project has been completed. refer back to how the design of the system was created
Can potentially play a role in defining and standardizing the system architecture of the solution. That can be particularly important in large, complex, enterprise-level projects where it is important to have a clear and consistent architecture for solutions
Is UML Still Relevant Today? What Is the Role of UML in an Agile Development Process?
Many companies are moving to an Agile development process for software development which raises the question: “Is UML still useful in an Agile environment?”. In an Agile environment,
The requirements for the project and the design of the software are normally not defined in detail prior to the start of the project
Both the requirements and the design typically evolve and are further extrapolated as the project was in progress
In an Agile environment, there is also normally much less reliance on formal project documentation
The difficulty of using UML diagrams in that environment should be obvious:
There is typically insufficient information at the beginning of the project to define the requirements and the design in detail prior to the start of the project
It might require a lot of effort to continuously update UML diagrams as the project is in progress to reflect any changes
It raises questions as to who would benefit from maintaining and updating those UML diagrams and how they would benefit from it
The general rule I use for any kind of documentation is that:
We shouldn’t create documentation for the sake of creating documentation
Documentation should create some kind of value for someone and
That value should be sufficient to overcome the costs of creating and maintaining that documentation
Agile is redefining how software is developed and raises some significant questions about “Is UML still relevant today?”.
The value of UML diagrams in an Agile environment is limited and the effort required to continuously update the diagrams as the project is in progress may not be worth the effort. However, there are a couple of reasons why UML diagrams might still be useful:
Support – There might be some value in having UML diagrams as an aid for supporting the system once development has been completed
Architecture – There might also be some value in using UML to define and standardize the architecture of the solution
Both of those functions would depend heavily on the complexity of the system, the criticality of the business functionality it provides, and the overall support strategy for the system.
You can find further information on how an Agile/Scrum development process works and the advantages it provides in these links:
How many times have you heard people compare Agile versus Waterfall?
It happens a lot,
I do it myself, and
I keep hearing presentations that talk about how Agile has displaced Waterfall
But, if you really think about it, I don’t think that’s a very meaningful comparison and it’s out-of-date. The result of this confusion is people tend too see these two alternatives as binary and mutually-exclusive choices and they try to force-fit a project to one of these extremes:
There are many myths, misconceptions, and stereotypes behind the typical “Agile” versus “Waterfall” comparison. I hope this article will help people see these two alternatives in a fresh new perspective as complementary to each other rather than competitive.
What’s Wrong With The Typical Agile versus Waterfall Comparison?
“Agile” and “Waterfall” Are Not Individual Discrete Methodologies
When people talk about “Agile versus Waterfall”, it sounds like there are two individual discrete methodologies that can be directly compared:
One called “Agile” and
One called “Waterfall”
The truth is that neither “Agile” or “Waterfall” is an individual discrete and well-defined methodology. It would be more accurate to recognize that each one is a style of methodology with more than one different methodology associated with each style. For example:
What is the “Agile” Methodology?
“Agile” is not a single methodology. Agile methodologies include Scrum, Kanban, and other less commonly-used methodologies. Scrum is so widely-used, that when many people say “Agile”, they really mean “Scrum”; however, it’s not really accurate to say that “Agile = Scrum”. In addition, many people consider Scrum to be a general framework and not a specific methodology. Here’s some more detail on that:
The common denominator of these Agile methodologies is that they are flexible and adaptive. That makes them well-suited to an uncertain environment where an empirical process control approach is needed. I think the word “adaptive” is a much better and more accurate term to use to describe these methodologies because it defines a style of methodology and doesn’t convey the idea of a specific methodology at all.
What is the “Waterfall” Methodology?
“Waterfall” is also not a single methodology. When people talk about “Waterfall”, they are not necessarily referring to the pure original phase-driven approach defined by Dr. Winston Royce in the 1970’s. “Waterfall” has evolved significantly since those days and there are many variations that might still be considered to be “Waterfall”. For example, the Rational Unified Process (RUP) and its many variants probably would be considered “Waterfall”.
Again, when people use the word “Waterfall”, they are not generally talking about a specific methodology; they’re talking about a style of methodology. You will find more detail on that in this article:
The common denominator of these methodologies is that they are “plan-driven”. They emphasize trying to achieve predictability over the costs and schedule of a project plan. They do that by nailing down the requirements in detail upfront and controlling any changes once the project is in progress
It’s Not a Binary and Mutually-exclusive Choice
Another serious flaw in the typical “Agile” versus “Waterfall” comparison is that it implies that there is a binary and mutually-exclusive choice between these two extremes and that is also not the case.
These two approaches are not mutually-exclusive. If you recognize that these are really styles of methodologies and not really individual methodologies, there are many ways to blend the two styles together:
Its not a matter of blending a Scrum methodology with a true Waterfall methodology;
It’s a matter of blending a plan-driven style of methodology with a more adaptive style of methodology in the right proportions to fit a given situation.
Agile versus Waterfall – An Example of Sloppy Terminology
A lot of this is just sloppy use of terminology; but, in many cases, there’s also an implication that Agile is good and Waterfall is bad. Here is an example to illustrate what I mean by sloppy use of terminology when people talk about “Waterfall”:
From the 2011 Chaos Report: “Agile Succeeds three times more often than Waterfall” The report goes so far as to say, “The agile process is the universal remedy for software development project failure.”
What do they mean by “Waterfall”? (Are they talking about a specific methodology – like the Waterfall that was defined by Winston Royce in the 1970’s or are they talking about a broader range of plan-driven methodologies?
How did they define how “success” was measured and how do you compare success from one project to another? Are the metrics for success really the same across all projects to make that comparison?
How can anyone possibly say that “The agile process is the universal remedy for software development project failure”?
This is an example of some of the opinionated polarization that has existed for a long time. Saying that “Agile is better than Waterfall” is like saying “A car is better than a boat”. They both have advantages and disadvantages depending on the environment that you’re in.
A More Accurate and Meaningful Comparison
A more meaningful and more objective comparison is between an “adaptive” style of project management and a “plan-driven” style of project management.
“Plan-driven project management” is a style of project management where the requirements and a detailed plan for completing the project can be defined prior to implementing the project
In contrast, an “adaptive” style of project management starts the implementation of a project with a less well-defined plan of how the project will be implemented. Then, the requirements and plan for the project are expected to evolve as the project progresses
Neither of these is an absolute, rigid extreme. In reality, no project is ever totally plan-driven or totally adaptive; you won’t find many projects:
That start out with an absolutely rigid plan that is not expected to change at all, or
That have no plan whatsoever of how the project will be done
There is a broad range of alternative approaches between those two extremes as shown in the diagram below:
Fit the Methodology to the Nature of the Problem
A good rule to follow is don’t force-fit any project to any methodology that doesn’t fit the nature of the project. A methodology does not provide a “cookbook” approach for solving any problem you might have:
Rather than force-fitting a project to some particular methodology (whatever it might be) and taking a “cookbook” approach to applying that methodology mechanically.
The right approach is to go in the other direction and fit the methodology to the nature of the problem you’re trying to solve. It takes more skill to do that but it definitely can be done.
The impact of all the myths, misconceptions, and stereotypes behind the typical Agile versus Waterfall comparison is significant:
Don’t Throw Out the Baby With the Bath Water
By categorizing all plan-driven approaches as “Waterfall”, people tend to dismiss any form of plan-driven approach and regard any kind of upfront planning as inconsistent with an Agile project. That’s not the case.
Get Past the Polarization
There has been a lot of polarization between the traditional project management community and the agile community. There is a perception that project managers and project management are associated with the Waterfall approach. As a result, some people believe that project management skills are not needed at all because the Waterfall approach is an out-of-date approach for many projects.
There is actually a lot of project management going on in an Agile approach although you may not recognize it as “project management” for several reasons:
It’s not the traditional kind of “project management” that is so heavily stereotyped. It’s a different kind of project management with an emphasis on maximizing business results rather than controlling costs and schedules.
You also won’t typically find someone called a “Project Manager” at the team level in an Agile project because the functions that would normally be performed by a project manager have been distributed among other functions on the Agile team.
We need to get past many of the myths, stereotypes, and misconceptions that exist in this area. We need to see these two approaches in a fresh new perspective as complementary rather than competitive to each other.
I recently saw an online question that asked the question “Which Agile approach do you prefer – Kanban or Scrum?”. I decided that it was worth a blog post because I’ve seen this question several times. There are a couple of things wrong with this question:
It implies that Kanban and Scrum are interchangeable and
That the choice of one or the other is only a matter of personal preference
I don’t believe that either of those is correct:
Kanban and Scrum serve very different purposes
The choice of which one you choose should depend on what problem you’re trying to solve and objectively fitting the best approach to the nature of the problem. Personal preference or bias should not be a factor in that selection
How Are Kanban and Scrum Different?
Kanban and Scrum are very different kinds of processes and are intended for very different purposes.
The table below shows a comparison of how Kanban and Scrum are different:
Completed Individual Work Items
Nature of the Work To Be Done
The work may have a high level of uncertainty and require considerable interaction with the customer to resolve the uncertainty as the project is in progress
The individual work items may be relatively well-defined and may not require much interaction with the customer to clarify requirements
No Significant Planning Required
No Defined Roles
Work is organized into fixed-length sprints
Each work item is handled individually – Kanban has no concept of grouping work items into a sprint
Work to be done is planned and prioritized to support a product road map (Push Model)
Within a sprint, work is started as soon as capacity is available to work on it (Pull Model)
Continuous Flow Model (Pull Model)
Work is started as soon as capacity is available to work on it
Level of Integration
Work can be organized into a hierarchical structure to facilitate integration
Sprints and releases can be defined to support Product Road Map deliverables
Work is organized as a single stream of work to be done with no hierarchy
Each item of work is treated independently and there is no mechanism for developing an integrated solution
Process Definition and Continuous Improvement
The process is intended to evolve as the project is in progress
Strong emphasis on continuous improvement with Sprint Retrospectives
The process may be well-defined and repetitive
No formal mechanism for continuous improvement
It should be apparent that Kanban is very streamlined and designed for efficiency but it is also very limited in what it is intended for:
Kanban has practically none of the overhead (planning, meetings, roles, etc.) of Scrum
However, it is intended for producing completed individual work items that do not require an overall integrated solution
If you asked a developer which one they prefer, their choice might be obvious because developers like to write code without being burdened with too much overhead. However, that “overhead” is not unnecessary and can be essential in an environment where the goal is to produce a well-integrated solution that meets some overall business objective or solves a business problem.
Kanban and Scrum are designed and optimized for very different purposes:
Kanban is designed for a continuous flow kind of process that may be somewhat repetitive. An example would be a customer service response queue or a queue of requests for business reports, The overall goal of a Kanban process is to produce as many completed individual work items as quickly and efficiently as possible
Scrum is intended for project work where there is an overall goal of producing some kind of integrated solution
I’ve seen some people who want to abandon Scrum and move to Kanban because they don’t like some of the overhead that is built into Scrum; however, that “overhead” serves a purpose, provides value, and can be essential for projects that need to produce an integrated solution.
I frequently get questions from students and others asking “How do I maximize my value as a project manager?”. That’s a very good question because the world of project management is changing rapidly as a result of the influence of Agile. As a result, the answer to that question is not as simple as you might think. It’s important to understand the impact of these changes and plan your career accordingly.
What’s Different in Today’s World?
There have always been two primary aspects of being a good project manager, in my opinion:
The first is knowledge of project management principles and practices
The second is understanding of a particular area to apply that knowledge to
In the past,
You might have been able to get by with being a “general purpose project manager” with a solid knowledge of project management principles and practices alone
In some cases, a project manager might have been nothing more than a good, high-level planner and administrator
In today’s world, I don’t believe that is sufficient.
1. Project Managers Need to Provide Business Value
In the past,
It may have been sufficient for a project manager to be successful by delivering a set of defined requirements within a given cost and schedule budget
However, there have been many projects that have met their defined requirements but failed to deliver an acceptable level of business value
That can easily occur for two major reasons:
A. Level of Uncertainty
We live in a world today where solutions are much more complex and there may also be a much higher level of uncertainty about what the best solution is. That can make it very difficult or impossible to accurately define the requirements for a project upfront. In this environment:
Business value takes on a much broader definition – Simply meeting cost and schedule goals is only one component of business value and it may not even be the most important component of business value
A more adaptive project management approach is needed – Attempting to define firm project requirements upfront in a very uncertain environment and then controlling changes to those requirements makes it difficult to optimize the value of the solution as the project is in progress
B. Need for Creativity and Innovation
There is also a very high level of competition in today’s world. Being successful in that environment can demand leading-edge products and it can require a significant level of creativity and innovation to develop those products. An over-emphasis on planning and control can stifle creativity and innovation.
For example, can you imagine trying to develop an industry-leading product like a new iPhone with a traditional plan-driven approach to project management? There is a lot of uncertainty about how to maximize the customer value of a new iPhone and it can require a lot of creativity and innovation to be successful. Producing high-impact business results is what is important.
2. There Is Not Just One Way to Do Project Management
A major impact of this is that there is no longer just one way to do project management. You need to fit the project management approach to the nature of the project. Any project manager who only knows how to do a traditional plan-driven approach to project management and tries to force-fit a project to that approach is not likely to be successful.
It is also not a binary and mutually-exclusive choice between “Agile” and “Waterfall” as many people seem to think. A good project manager needs to see those two approaches in a fresh new perspective as complementary to each other rather than competitive and learn how to blend those two approaches in the right proportions to fit any given situation.
How Do You Adapt to This New World?
It can be a big challenge to develop and enhance your project management skills to adapt to this new world. Here are some questions I’ve seen frequently:
What Certification Should I Get?
PMI is still catching up with these changes. For a long time, PMI has treated Agile and traditional plan-driven project management as two separate and independent domains of knowledge with little or no integration between the two. Today’s PMI certifications still reflect that:
PMP is heavily associated with traditional plan-driven project management
PMI-ACP is associated with general Agile and Lean knowledge
Neither of these certifications really addresses the most important challenge I believe a project manager needs to address of learning how to blend these two areas in the right proportions to fit a given situation. In addition, the role of an Agile Project Manager is still not well-defined and PMI-ACP is only a test of general Agile and Lean knowledge and does not prepare you for a specific role. The result is that:
Both of these certifications have value as a foundation, but
They do not go far enough to address the primary challenges that a project manager might face in today’s world
What Academic Degree Should I Get for Project Management?
There have also been a number of questions from college-age people about the role of an academic degree in becoming a project manager. For example:
What academic degree should I get for a career in project management?
Is it worthwhile to get a master’s degree in project management?
Here are my thoughts on that:
There is certainly some value in academic training but project management has always had a practical, real-world focus on getting things done. As a result, an academic degree in project management without any real-world experience has limited value
Many universities that offer academic training in project management still base their curriculum heavily or exclusively on a traditional plan-driven approach to project management and have not fully-integrated an Agile approach into their curriculum
As I’ve previously mentioned, project management is more than just knowing project management skills, its important to also have some knowledge of an area to apply those skills to. An in-depth knowledge of general project management skills without much knowledge of how to apply those skills to deliver business results in a particular area of focus is not a good formula for success, in my opinion.
What Is the Role of an Agile Project Manager?
Any project manager should have a clear idea of what role they are preparing themselves for. However, the big question that is difficult to answer is “What Is the Role of an Agile Project Manager?” That role is still evolving and there is even some controversy among some people that there is a role for a project manager at all in an Agile environment. I can only give you some general recommendations on this:
The role of a project manager in leading and managing small, simple, single-team projects is rapidly disappearing
Many project managers who may have primarily focused on performing that role will need to move up to a higher level of value-added
The primary focus of any project manager should be on delivering business results and just a knowledge of project management skills is often not enough to do that
Here’s an article with more on that:
The world of project management is going through some very rapid and significant changes at this time.
Many project managers have questions about how to adapt their careers to fit this new environment
There are no simple and easy answers to that because the role of a project manager in this environment is still rapidly changing
The most important things for a project manager to realize are that:
These changes are happening and can’t be ignored. Most project managers will probably need to upgrade their skills to continue to grow and thrive in this new environment. Any project manager who is in “denial” and insists on doing project management the same way it has been done for years may have limited success
PMI is still catching up with these changes. As a result, you can’t totally rely on PMI certifications to guide you in the right direction. The existing PMI certifications are a good foundation but they don’t go far enough at this time
This is only a very brief, high-level overview of the changes going on in the project management profession. If you want to learn much more detailed information, check out my Online Agile Project Management Training Courses. The first course is free!
Quality and reliability standards today for software are higher than ever and new approaches to software testing are essential to meet those goals. An Agile development approach provides a excellent approach to meet that challenge.
How Is Traditional Software Testing Done?
In a traditional software testing approach, a separate and independent QA organization normally does the testing:
The development team typically turns over software to the QA organization for testing at the end of the project
That normally happens after all development is complete.
That method of testing is very consistent with a “Waterfall” style of development. A Waterfall project typically consists of phases that might look something like this:
That’s been the traditional way that software development and testing has been done for a long time.
How Is Agile Testing Different?
Agile takes a fundamentally different approach to the whole development process (not just testing).
First of all, Agile does not break up a project into phases as the Waterfall model does
It breaks up a project by chunks of functionality and uses a much more integrated approach to develop and test each “chunk” of functionality
There are two major differences that have a big impact on how testing is done:
Incremental Development Approach
Integral Testing Approach
We will discuss each of these in the following sections.
1. Incremental Development Approach
Instead of developing and testing the complete functionality of the project as one big effort:
The functionality is broken up into small increments called “user stories” and
The work to be done to develop those user stories is broken up into sprints. Each of those sprints are typically 2-4 weeks long
The work in each sprint includes testing as well as development
Ideally, at the end of each sprint, fully-tested software for that portion of functionality should be ready for release.
2. Integral Testing Approach
Instead of testing being done by a separate and independent QA organization:
The testing function is an integral part of the Agile team, and
As soon as software is sufficiently complete, it is tested
It is worthwhile to note that integration of testing with development does not necessarily mean that developers do their own testing. Within an Agile development team:
There is value in having people who are specialized and trained in testing
Having developers test their own code is generally not a very good idea
What Are the Advantages of the Agile Approach?
There are several significant advantages to the Agile testing approach.
1. Proactive Rather than Reactive Approach
Agile testing is a more proactive approach to eliminate defects at the source. A reactive approach to find and fix defects later can require a lot more rework.
2. Immediate Feedback to Developers
An Agile testing approach provides immediate feedback to the development team. If difficult software bugs go unresolved, they can compound themselves and that can make it much more difficult find and resolve the defects.
3. Quality is Not Someone Else’s Responsibility
Agile testing makes the quality of the product an integral part of the development process. The development team producing the product owns responsibility for the quality of the product they produce. It is not someone else’s responsibility.
In the traditional Waterfall-style development process, it is not uncommon for the development team to throw code “over the fence” to QA. They put the responsibility on QA to find any bugs.
The Roots in Total Quality Management (TQM)
In order to understand why this approach makes so much sense, it’s useful to understand the deeper roots that influenced it:
Agile is heavily based on the principles in Total Quality Management (TQM)
TQM was originally developed for manufacturing by Dr. W. Edwards Deming
The quality of the Japanese automobile industry was improved significantly as a direct result of TQM,
It is relatively easy to extend the TQM principles to software development.
TQM emphasized a major shift in thinking from
A reactive “Quality Control” approach that was heavily based on inspection to
A more proactive “Quality Assurance” approach to go upstream in the process to eliminate defects at the source
That makes sense for a number of reasons:
Resources required to perform the inspection are costly
Defects that are found after the work is already done can result in costly and unnecessary scrap and rework
Any inspection approach is based on sampling is not a thorough approach for finding defects. Some defects will likely slip through when you use sampling resulting in relatively low levels of quality
It is easy to see how these same factors apply to a software environment. Many software testing processes have been based on an old-fashioned quality control approach. which is based heavily on inspection.
There’s a lot of confusion about “What Is Agile” and “What Is Scrum?”. This article provides a very brief explanation. Loose terminology is a big source of this confusion. For example, many people use the word “Agile” when they really mean “Scrum”.
Difference Between Agile and Scrum
For that reason, it is important to clearly understand the difference between Agile and Scrum. Here’s the difference:
Here’s the official explanation for “What is Scrum” from the Scrum Alliance:
“Scrum is a process framework used to manage product development and other knowledge work.
Scrum is empirical in that it provides a means for teams to establish a hypothesis of how they think something works, try it out, reflect on the experience, and make the appropriate adjustments.
That is, when the framework is used properly.
Scrum is structured in a way that allows teams to incorporate practices from other frameworks where they make sense for the team’s context.” – Agile Alliance
What Is a Framework?
Many people will say that it is inaccurate to call Scrum a “methodology” and that it really is a “framework”. What’s the difference? Here are a two key differences:
A “framework” is not very prescriptive and is normally adapted to fit a situation
A “methodology” is more prescriptive and provides a specific and well-defined approach for arriving at a solution
Empirical versus Defined Process Models
A related factor to understand the difference between a “framework” and a “methodology” is the difference between an “empirical” process model and a “defined” process model:
Defined Process Model
A “Defined Process Model” attempts to define every piece of work in advance in order to develop a detailed plan for completing the work. There are two very important characteristics of a Defined Process Model:
Repeatable – A Defined Process Model will produce the same outputs every time for the same set of inputs
Predictable – The results of a Defined Process Model are predictable in advance
For example, the diagram below shows a figurative depiction of a defined process using a well-defined methodology that is repeatable:
A traditional plan-driven project management approach as defined in PMBOK and a Waterfall model are examples of methodologies that follow a Defined Process Model.
Empirical Process Model
An “Empirical Process Model” is a style of work that leverages the principles of inspection, adaptation, and transparency. For that reason, an Empirical Process Control Model works best where the result that is needed is uncertain and the process to produce the result may also be not well-defined.
The diagram below shows a figurative depiction of how an empirical process model works. Basically, the process is not as well-defined and uses an incremental and iterative process based on some level of experimentation to try to arrive at an optimum solution.
A key point is that in an empirical process model, you’re not really sure exactly what the solution will be and you’re also not exactly sure of what the optimum process for arriving at a solution is. Scrum is an example of an empirical process model.
The key difference between the two process models is related to the level of uncertainty in the project:
Low Level of Uncertainty
With a relatively low level of uncertainty, a defined process model might work best especially if there is a goal of being predictable because it is a predictable and repeatable model.
To achieve predictability, you would typically use a Defined Process Model because all of the work can be planned in advance
A Defined Process Model may also be more efficient because the work can be planned and organized in advance
For example, you would be very likely to use a Defined Process Model if you were building a house where it is important to have some predictability over the costs and schedule for completing the house.
Higher Level of Uncertainty
With a higher level of uncertainty, an empirical process model might work best because it provides a more adaptive approach for arriving at an optimum solution.
It may be less efficient than a Defined Process Model because it may require more trial-and-error but
It is much more likely to produce a more optimum solution, especially in an uncertain environment.
For example, if you set out to find a cure for cancer or some other disease that has no known cure, the solution is probably not well-known when you start the project and it likely requires some level of experimentation to arrive at at an optimum solution.
How Does Scrum Work?
Scrum uses an empirical process model that continuously refines both the product and the process to produce the product as the project is in progress. For that reason, Scrum works best in an uncertain environment.
Scrum Is Incremental
A Scrum process breaks up all the work into short development increments called “sprints”
Sprints are limited to a fixed-length that is normally 2-4 weeks long
The Product Owner prioritizes all work based on business value. That enables the team to deliver value as quickly as possible
Scrum Is Also Iterative
At the end of each sprint, the Product Owner and any important stakeholders review the results of the sprint and provide feedback and inputs
Providing direct feedback and inputs is essential to optimize the solution
Reviewing the results at the end of each sprint enables rapid learning for ongoing continuous improvement
Have you ever thought about “When an agile project fails, who gets blamed”? I thought it was a very interesting question.
How Does an Agile Project Fail?
It’s actually difficult for an Agile project to fail.
An Agile project typically does not have rigid cost and schedule goals that must be met and
An Agile/Scrum process has the capability to detect and correct potential failures early
Given that, an Agile/Scrum project should be self-correcting if it is done properly. For example, at the end of each sprint:
There is a Sprint Review to detect problems with the product
There is a Sprint Retrospective to detect and correct process problems
An Agile project should provide early warning of a potential failure with plenty of opportunity to correct any problems before the end of the project. At the end of each sprint, both the product and the process to produce the product are reviewed and corrected if necessary. If an Agile process fails, the process must have broken down somewhere; and rather than looking for an individual to blame, a more appropriate response would be to figure out what went wrong in the process to prevent it from happening again.
Fail Early, Fail Often
One of my favorite Agile mantras is “fail early; fail often”. People should not be afraid of failure and should see failure as an opportunity for learning. That is very important in an environment that is designed to support creativity and innovation. If senior management is looking for someone to blame, that’s not very consistent with an Agile culture.
How to Prevent Failure in an Agile Project
It’s relatively easy to prevent failure in an Agile project – its mostly a matter of:
Implementing the process effectively including Sprint Reviews and Sprint Retrospectives with an emphasis on continuously improving both the product as well as the process for producing the product as the project is in progress
Designing and implementing an enterprise-level transformation to align the Agile development approach with the company’s business and to create a culture that is supportive of an Agile approach
The important point is that their should be:
Everyone in the organization should have a spirit of shared ownership and partnership and be committed to the success of the project instead of an “arms-length” contractual relationship between the business and the project team
The business sponsors and users actively participate in the project in a spirit of partnership as the project is in progress to provide feedback and inputs as the project is in progress
A number of my students have requested some case studies that show applying Agile to non-software projects. As an example, I recently completed a home remodeling project which may seem simple and trivial; but believe me, it was not.
Using Agile for Non-Software Projects
It is possible to apply Agile to almost any project but that doesn’t necessarily mean using Scrum. And, it certainly doesn’t mean just going through the rituals of doing Scrum mechanically. Applying Agile principles and figuring out how to apply them to non-software projects can be very challenging.
I have been a project manager for a long time. I’ve managed large, complex multi-million dollar projects; but nothing compared to a recent project to do a major remodeling of the kitchen in our house. The project involved:
Knocking down a wall that separated the kitchen from the rest of the house to create a more open environment
Ripping up the concrete floor to re-route electrical and plumbing connections
Replacing all of the existing kitchen cabinets and appliances
Installation of new lighting fixtures
Moving the entrance-way to the master bedroom to be more consistent with the new floor plan
Removing a pantry and replacing it with a new pantry cabinet which required knocking down a wall and moving an intercom system
Repainting the entire area and many other cosmetic enhancements
Agile Home Remodeling – Why was this project so difficult?
My wife was the major stakeholder in the project, she is a perfectionist, and she has a habit of changing her mind frequently about what she wants. (Her response to that is “She doesn’t change her mind, she just decides as she goes along”)
Multiple outside contractors did all of the work in this project
A major challenge was to try to manage the costs and schedule of this project within reasonable levels
Agile Contractor Selection
The first task was to select a contractor (or contractors) to do the work. I had several choices:
Contractor “A”was the most widely-known contractor in this area. They advertise widely on television and have a good reputation for delivering a high-quality result. They would also take full responsibility for the overall solution. However, their approach is fairly rigid and controlled. Once you sign a contract with them, it is very difficult to make any changes.
Contractor “B” was much less widely-known but offered much more flexibility and willingness to work with on a design that was customized to meet our needs. They would also take overall responsibility for managing the overall solution.
Contractor “C” offered the most flexibility to meet our needs but was actually two different contractors. It was not really possible for either of them to take overall responsibility for the overall solution
One contractor did the demolition and prep work including electrical and plumbing to prepare the new kitchen
Another contractor provided the kitchen cabinets and counter-tops. They installed them after the initial demolition and prep work had been completed
Following the installation of the cabinets and counter-tops, the original contractor returned to do the finish work. That work included final installation of new lighting fixtures and repainting of the entire area
Choosing a Contractor
Selecting a contractor was difficult:
Contractor “A” was probably the lowest risk choice from a traditional project management perspective. It would require less management on my part but offered little flexibility to adapt the solution to meet our needs
Contractor “C” was the highest risk and involved coordinating the work of two different contractors. However, they offered the most flexibility to meet our needs
Contractor “B” was a compromise between those two extremes. They had the advantage that they were a single contractor who would take overall responsibility for the solution. However, their costs were considerably higher than Contractor “C”
Final Contractor Selection
We chose contractor “C” because flexibility and adaptivity to meet our needs was so important; even though contractor “C” had the highest risk and might be the most difficult to manage. However, these two contractors had a history of working together successfully on other similar projects. I also had a good feeling that I could trust and partner with these individuals to manage the overall solution. That was a key difference:
With contractor “A”, we would have relied on a very clear and well-defined contract to deliver the solution. However, we would have little or no flexibility to make changes (That’s what many people might call “Waterfall”)
Contractor “C” had a statement of work but it was understood to be flexible and subject to change. The relationship relied on a spirit of trust, partnership, and collaboration (This relationship was much more similar to Agile)
How Did the Project Work Out?
This was a difficult effort to manage.
The scope of the project changed numerous times
My wife decided that we couldn’t remodel the kitchen without replacing all the living room furniture and carpets. And, of course, other changes to the rest of the house became necessary as well which included:
Repainting the master bedroom,
Replacing pictures and reupholstering other furniture. and
Enhancements to other areas of the house
Nailing down the design requirements was very difficult
As I mentioned, my wife changes her mind frequently, and insists on perfection in the end-result. We looked at many different kinds of granite counter-tops and many different floor tiles before making a final selection. There were also many times when a “final selection” changed before it really became a “final selection”
This Was a Project Management Nightmare
This was not a large project but it was one of the most difficult ones that I have ever had to manage. For a traditional plan-driven project manager, this would have been a nightmare attempting to control all of these changes. It is also very challenging to be caught in the middle between a very demanding stakeholder and contractors who have to deliver the work within a given cost.
However, this is a perfect example on a small scale of what an Agile Project Manager has to do. You have to learn how to balance flexibility and adaptivity to maximize the business value of the solution with some level of planning and control,
What Were the Results?
The project turned out to be enormously successful
The whole project was completed in a little over three weeks from the time the work started
It went over the budget that that we expected to spend but the costs were still at a reasonable level
Most importantly, my wife was delighted with the way it came out and she is the most important stakeholder I needed to satisfy.
Here’s a picture of what the finished kitchen looked like:
Here’s a couple of pictures taken during the work-in-progress leading up to finishing the kitchen:
How Does This Apply to a Business Situation?
I know this is an unusual situation but I like to use unusual situations. I think it encourages “out-of-the-box” thinking rather than viewing standard, stereotypical Agile case studies. The following is a summary of how I think these lessons-learned can be applied to a business situation:
Most businesses could not survive without some kind of contractual relationships with outside contractors. In addition, many businesses have significant supply chains that are critical to the success of their business.
Typically, a firm, fixed-price contract and a competitive bidding process among multiple bidders is used to get the lowest possible price.
That is a relatively low-risk approach from a cost-management perspective but doesn’t necessarily result in the best overall solution.
When there is a lot of uncertainty in the requirements, a different approach is needed to maximize the business value of the solution. It requires a collaborative partnership with a contractor to work together to maximize the value of the solution is essential
Developing that kind of relationship with contractors requires trust. For that reason, it will not be possible to develop that kind of relationship with just any contractor. That’s why it is important for a business to have strong relationships with a selected number of contractors who can be regarded as close partners.
I took a risk by going with contractors that I thought were the highest risk from a project management perspective. However, that risk paid off in terms of the overall quality of the solution. A similar thing is true in a business environment. Many times you have to take a risk to maximize the value of the solution.
The project was completed in a very short time once the work was started. That was largely due to the fact that I empowered the contractors to get the job done the best way they knew how and I didn’t attempt to micro-manage what they were doing. Conventional project management might attempt to more directly manage the work being done.
Here are some of the important conclusions and lessons learned from this project about applying Agile to non-software projects:
Agile principles and values can be applied to some extent to almost any project. However, it requires some skill to interpret these principles and perhaps combine them with traditional project management practices.
The overall value that the project delivers is what is most important. The key stakeholder determines “value”. Cost and schedule goals have some value but are only one component of value and not necessarily the most important,
A spirit of trust and partnership is important even in a contractual situation. Over-dependence on a traditional contractual relationship can severely reduce flexibility and impact the value that the solution provides.
Risk management is important but attempting to minimize and over-control risk can also impact the value of the solution. Taking risks may be necessary to maximize the value of the solution.
For another example of applying Agile to non-software projects, check out this article: