I may be stating the obvious—you can’t be Agile without being Lean.

I may be stating the obvious—you can’t be Agile without being Lean.

In the Agile Practice Guide published by PMI® and the Agile Alliance®, there is the Venn diagram shown above. It is a simple yet useful visual that most of us long-toothed Agile practitioners clearly understand.  Unfortunately, I am finding through my training practice that “coaches” and late-adopter organizations have  missed this step.  Let me restate this in a more compelling way:

If you don’t embrace Lean as an organization, you will constantly face challenges with your Agile implementation.

What does it mean to be “Lean”?

I am not referring to the book, “Lean Software Development,” which is valuable but is still a subset of organizational Lean. I am referring to the Lean as defined in the Toyota Production System (TPS) created by Taiichi Ohno and Eiji Toyoda.

While in school for Industrial Engineering I learned all about TPS. After graduation, when I started managing large software development projects, my education in Lean proved useful for software development. Based upon this education and training, adoption of the Lean principles became my fundamental basis for project management. This realization occurred prior to Agile Manifesto’s creation; to become more “Agile” I followed the models set by authors who were already adopting software development best practices that aligned with Lean principles.

Jeffrey Liker summarizes these Lean principles in his 2001 book The Toyota Way:

  1. Base your management decisions on a long-term philosophy, even at the expense of short-term financial goals.
  2. Create a continuous process flow to bring problems to the surface.
  3. Use “pull” systems to avoid overproduction.
  4. Level out the workload (work like the tortoise, not the hare).
  5. Build a culture of stopping to fix problems, to get quality right the first time.
  6. Standardized tasks and processes are the foundation for continuous improvement and employee engagement.
  7. Use visual controls so no problems are hidden.
  8. Use only reliable, thoroughly tested technology that serves your people and process.
  9. Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others.
  10. Develop exceptional people and teams who follow your company’s philosophy.
  11. Respect your extended network of partners and suppliers by challenging them and helping them improve.
  12. Go and see for yourself to thoroughly understand the situation.
  13. Make decisions slowly by consensus, thoroughly considering all options; implement decisions rapidly.
  14. Become a learning organization through relentless reflection and continuous improvement.

These principles are framework agnostic and can be applied to any project and any organization looking to excel. Organizations that adopt Lean have more success than those that only adopt Agile. Scott Ambler, the author of Disciplined Agile Delivery (DaD), published the following study in 2013:

While not an overwhelming difference between Agile and Lean (65% vs 70% successful) I’ve found that more recently that the gap is widening.

While not a comprehensive description, this article highlights the potential of Lean. If you are focused on an Agile framework, process, procedure or tool, and are facing challenges with your Agile implementation, there may be another option. Step back from your project and work with leadership to decide if any of the above principles are missing or lacking. Ask yourselves the following questions:

  • Is there a direct relationship between the lack of a Lean principle and your Agile implementation challenges?
  • Is the organization committed to doing what it takes to be Lean and fundamentally Agile?

Ultimately, you can self-assess by reading and reflecting on those principles. The path forward is simple if you adopt a Lean approach to your implementation: Try it! If you fail or succeed, if you focus on continuous improvement you will propel your company forward.


About the Author: Dan Tousignant

Dan has been leading software development projects for 20 years. He was first formally introduced to Agile via a Scrum Implementation in 2000 and has since adopted the Agile Manifesto values and principles when leading software development projects.

Dan holds a BS in Industrial Engineering from UMASS, Amherst and is a Professional Scrum Master, Certified Product Owner, PMI Agile Certified Practitioner and Certified Scrum Professional.

Dan Tousignant, PMP, CSP, PMI-ACP, SPC

President Cape Project Management, Inc.

How Agile are you? Free Agile Maturity Assessment

How Agile are you? Free Agile Maturity Assessment

Who Owns Quality in Agile?

The 2018 PMI-ACP® Exam Changes

What’s next on your Agile journey?

The Practical Agile Blog

Certifications, Integrity, Values: Where do you stand?

As an Agile Coach and Trainer, I try to stay current with certifications. I don’t believe that these certifications necessarily make someone more effective, but for me, they are a structured way of staying current with industry best practices.

How Agile are you? Free Agile Maturity Assessment

When you receive the score of your self-assessment, you can identify your level of Agility on the Agile maturity matrix. Contact us if you are looking for ways to improve your overall Agile Maturity.

  • 0 – 80 points: Ad-hoc Agile
  • 81-160 points: Doing Agile
  • 161-240 points: Being Agile
  • 241 – 320 points: Thinking Agile
  • > 320 points: Culturally Agile

Print a PDF of the maturity model and mark your score.

What is an Agile Maturity Model?

  • A model that is designed to enhance and improve Agile practices by assessing the current state of your organization
  • A way to determine how closely you adhere to Agile principles
  • A model which shows your organization on an Agile maturity  continuum  from an initial or ad-hoc level to a continuously improving, self-sustaining level

How did we measure your Agility?

We based the assessment primarily on the use of Scrum since it is the most widely adopted Agile method. The scoring of the assessment is weighted based upon the overall importance of the answer and by applying our experience to the MocSCoW prioritization model as defined by the DSDM consortium, e.g. giving a higher value to those questions that are Agile “must haves” versus Agile “could haves.”  No maturity model is perfect, but ours should provide insight into where you are today, reinforce where you have come from, and give you an idea where you are going.

The above maturity matrix is based upon the Maturity Index for Cultural Agility developed by Vodaphone UK and Hewlett Packard as presented in this paper to the UK’s National Audit office.  The online Agile self-assessment was adapted from an original source developed by Henrik Kniberg and is licensed under a Creative Commons: http://creativecommons.org/licenses/by-nc-nd/3.0/

What next?

What you do with this information is up to you. This tool only presents one individual’s point of view (you). If you want to have a number of people participate in this assessment and would like us to aggregate, summarize and make recommendations to help you on your Agile journey, please contact us.

About the author, Dan Tousignant, PMP, ACP, CSP

Dan is a lifelong project manager and trainer with extensive experience in managing software development projects. Based upon his experience, he has adopted both Agile as the primary method for developing and implementing software. He is passionate about the leadership emerging from self-organizing teams.

Dan has over 20 years of experience providing world class project management for strategic projects, direct P& L experience managing up to 50 million dollar software development project budgets, experience managing multi-million dollar outsourced software development efforts and strong, demonstrated, results-driven leadership skills including ability to communicate a clear vision, build strong teams, and drive necessary change within organizations.
Dan holds a Bachelor of Science majoring in Industrial Engineering from the University of Massachusetts, Amherst and is a Certified Project Management Professional, Professional Scrum Master, PMI Agile Certified Practitioner and Certified Scrum Professional and is the owner of Cape Project Management, Inc.
Cape Project Management, Inc.
Boston and Honolulu, USA
Contact: Dan@CapeProjectManagement.com

Who Owns Quality in Agile?

Who Owns Quality in Agile?

Who Owns Quality in Agile?

In Scrum, the expectation is that the entire Scrum Team owns quality, but what does that really mean? Isn’t the Product Owner only worried about value? Doesn’t the team own all the testing? Don’t they really own quality? Like many other concepts in Agile the answer to who owns quality is subtler than that, and as my first Agile mentor liked to say, “It depends.” Before we define ownership, let’s define what we mean by quality in Agile. In terms of Agile software development, Jim Highsmith in Agile Project Management: Creating Innovative Products identifies quality as two points of the Agile Triangle: Intrinsic quality and Extrinsic quality.
This suggests that the definition of quality comes from two different sources, externally from the customer and internally from the development teams. Defining Quality Joseph Kelada, author of Integrating Reengineering with Total Quality defines these two aspects of quality: Intrinsic Quality is all of the qualities that are built into the product: suitability, durability, reliability, uniformity, and maintainability. This type of quality can be measured quantitatively such as test coverage, bugs per line of code, escaped defects, cohesion, etc. Extrinsic Quality is the buyer’s perception of quality and the value to the customer. This is a more qualitative measurement based upon sales, usage and customer feedback. When most people think of quality, they think if intrinsic quality, which is why we have team members who are Quality Assurance specialists. They aren’t evaluating the customer’s perception of the product, they are performing verification and validation (V&V), e.g. Are we building the system right? Are we building the right system? The goal of V&V is to test the product against the written business and technical requirements. On Agile projects, we build products with the premise that every requirement ties back to a customer-facing vision and value proposition. If a requirement doesn’t align with that vision, then it doesn’t matter how reliable it is, for it is of no value. With each iteration and release, the goal is to provide the highest value features balanced against the cost to develop those features. This the goal of each Sprint in Scrum. Given this, I would suggest that Jim Highsmith’s Agile triangle is visually inaccurate. It gives equal weight to intrinsic and extrinsic quality. The reality is that in order for organizations to compete, extrinsic quality, in most cases, is more important. Remember, the first principle in the Agile Manifesto, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
The Role of Product Owner in Quality I recently encountered a simple yet telling example of how a Product Owner addressed intrinsic versus extrinsic quality while facilitating a Sprint planning meeting. A developer submitted a backlog item to refactor some previously written code that was causing a large increase in storage each time a report was run. This was an unexpected outcome of a customer-facing requirement. The assumption from a technical perspective was that the storage issue was egregious and the impact was large, but the effort to refactor the code was large as well. In a traditional software development environment it would be assumed that a defect like this would automatically be addressed in the next release. On this high-performing Scrum Team, the Product Owner questioned the value of addressing the defect in this release. This involved an in-depth discussion of the issue and the options, and ultimately in came down to a quantifiable measurement. The technical debt of that storage issue could be measured in dollars and could easily be compared against the business value of other requirements.  Once the issue was quantified, the Product Owner removed the requirement as a candidate for this release. The Product Owner had more “valuable” items slated for this release. Not all issues of extrinsic quality versus intrinsic quality can be that easily quantified, but in mature Agile teams, the correct dialogue will occur and the decision that is most often made will balance the short-term customer facing goals with the long-term viability of the product. Quality Ownership So, back to the original question, who owns quality? When speaking of Agile roles, it is easiest to use the Scrum roles. In the most recent annual VersionOne Agile survey, 75% of companies practicing Agile are using Scrum or at least the Scrum terminology. The roles of Product Owner, Scrum Master, and Development Team have become ubiquitous terms in our industry. In the Scrum Guide, it states, “As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.” “Scrum Teams” includes all three Scrum roles. So this would presume that the entire Scrum Team owns the intrinsic quality. However, the Guide also states that the Product Owner is responsible for “Optimizing the value of the work the Development Team performs.”  So, ultimately, the Product Owner owns extrinsic quality, and as we just discussed, this may supersede intrinsic quality. The Reality Though organizations understand this theoretically, this is seldom put fully into practice. For the Product Owner to truly own quality the following best practices would need to be in place:
  • Quality Assurance specialists would functionally report to the business
  • The Product Owner sign-off on design documents
  • Performance and non-functional requirements would be approved by the Product Owner
  • All defects would be approved by the Product Owner before being added to the backlog.
  • The scope of pre-production testing and readiness would be approved by the Product Owner
Those changes and many more would need to occur, both culturally and organizationally for an organization to truly align quality ownership with the Product Owner role. At minimum, in order for the Product Owner to truly own value and quality, the Development Team needs to educate the Product Owner on the cost and effort of addressing intrinsic quality issues. The Product Owner needs to understand that well written code costs less to support and maintain. Technical debt eventually needs to be paid back and only an educated Product Owner can make the best decision as to when. This often creates conflicts within newly emerging Agile teams. In my experience, especially with large traditional organizations, this can shift the ownership of building the product away for the IT department and more to the business. This is intentional in Agile so that we ensure that delivering value to the customer is a primary goal. Personally, I have seen too many well-built, highly reliable, stable products sit on a shelf because ultimately they missed customer’s expectations or were too late to market. Often a product that was not built half as well can dominate market share. There are exceptions to this of course, but for those companies at the forefront of their industries, they are adopting a Lean and Agile approach to software development that front-end loads value. They then add stability and reliability once the product achieves traction and validates the ROI for both the initial investment and continuing investment. It is a team effort to understand how each requirement, whether technical or functional, will drive value to the customer. This type of understanding requires close collaboration between the Product Owner and the development team. It means truly embracing the “one team” concept and allowing full transparency into the decisions about which requirements make it into each release. Ultimately, it will be the Product Owner’s decision, but only in an environment that had truly embraced what it means to be Agile can this occur. References: Joseph Kelada, Integrating Reengineering with Total Quality Jim Highsmith, Agile Project Management: Creating Innovative Products 10th Annual VersionOne Survey Jeff Sutherland, Ken Schwaber 2016 Scrum Guide About the Author: Dan Tousignant Dan has been managing software development projects for 20 years. He was first introduced to Agile via a Scrum Implementation in 2000 and has since adopted Agile as the primary method for managing software development projects. Dan holds a BS in Industrial Engineering from UMASS, Amherst and is a Professional Scrum Master, Certified Product Owner, PMI Agile Certified Practitioner and Certified Scrum Professional. Dan Tousignant, PMP, CSP, PMI-ACP. President Cape Project Management, Inc. agile.us.com

The 2018 PMI-ACP® Exam Changes

The 2018 PMI-ACP® Exam Changes

The 2018 PMI-ACP® Exam Changes

The Project Management Institute (PMI®) has proceeded down the path of embracing Agile. On March 26, 2018 both the PMP® and PMI-ACP® exams with be updated to reflect PMI’s new Agile Practice Guide and the PMBOK® 6th edition. You can read about the changes here.

My Observations

PMI stated there were not any changes to the overall course outline for the PMI-ACP exam, but changes were made to “harmonize with terminology” used in the practice guide. After scouring the guide, I made a number of updates to my practice exam questions, training content and my self-study training.

Here are my takeaways after reviewing the guide in detail:

  • Ultimately their goal is to become framework neutral so there is an attempt to create some common terminology and practices.
  • There are now 3 generic Agile roles, taken primarily from Scrum:
    • Team Facilitator
    • Cross Functional Team Members
    • Product Owner
  • There was recognition that there is no PM role in Agile but the PM can play the role of Team Facilitator
  • They have stated the need for PMOs in an Agile environment
  • There are now 2 generic Agile approaches:
    • Iteration-based Agile (essentially Scrum)
    • Flow-based Agile (essentially Kanban)
  • Transparency, Inspection and Adaptation (from Scrum) are now considered to be generally Agile principles
  • Stories (for Agile requirements) now seem to be accepted terminology. I don’t think they were even referred to in the initial version of the exam
  • I like how they now have a Venn diagram for Lean and Agile and how Kanban bridges both. That will become a popular training graphic
  • Hybrid and scaling were now acknowledged, though minimally. I don’t expect to see many more questions on this area yet- too much inconsistency in the marketplace.
  • I think they have embraced the following pure Agile concepts even though they are the very opposite of traditional PM:
    • Servant leadership
    • Generalizing specialists
    • Burndown charts and Kanban boards instead of Gantt charts
  • Even though there was a lot alignment with Scrum, there were still some contradictions:
    • “The Product Owner sees the demonstration and accepts or declines the stories” – that is a big faux-pas in formal Scrum. The Product Owner should be signing off throughout the iteration and showing the final product to stakeholders at the demonstration.
    • Iterations are usually 2 weeks – that is another false reality. I trained hundreds if not thousands of people over the years and the length of a Sprint is anywhere from a week to a month. If anything, three weeks seems to be as popular as two weeks.
    • The Product Owner asks a “triad”; a developer, tester and analyst, to get together to write a story as a way to refine the backlog. Hmmm that sounds dysfunctional to so many ways…


In addition to those terminology changes I mentioned, the guide provided a little more detail into some of the definitions of terms that were already in the exam outline. Though it is by no means perfect, it is a big step in developing a common terminology and set of practices called “Agile.”  The exam is difficult to study for and difficult to train because there was, and still is, so many contradictory terms in the Agile community. Even within PMI’s recommended reading list the authors contradict each other. The best part is that the Agile Practice Guide is a little more than 100 pages, as opposed to the nearly 1000 pages in the latest PMBOK. Let’s hope it stays that way!

Remember, if you are studying for the exam I have the most popular FREE PMI-ACP study guide and other great resources for studying for the exam.

Who Owns Quality in Agile?

The 2018 PMI-ACP® Exam Changes

What’s next on your Agile journey?

The Practical Agile Blog

Certifications, Integrity, Values: Where do you stand?

As an Agile Coach and Trainer, I try to stay current with certifications. I don’t believe that these certifications necessarily make someone more effective, but for me, they are a structured way of staying current with industry best practices.

An Agile software development approach could have prevented this – just saying.

An Agile software development approach could have prevented this – just saying.

UPDATE: January 30, 2018 The Washington Post published an article with more details: https://www.washingtonpost.com/news/the-switch/wp/2018/01/30/heres-what-went-wrong-with-that-hawaii-missile-alert-the-fcc-says/?utm_term=.84e766af06c6 It is interesting that one of the suggestions I mentioned to prevent this was actually in place, “They then must click ‘yes’ when the system asks ‘Are you sure that you want to send this Alert?'” the article also stated that the application uses “the same language irrespective of whether the message [is] a test or actual alert.” Hmmm.

I live most of the year in Hawaii on the island of Oahu and was woken by this alert last week. Needless to say it was a distressing event that should not have happened. I don’t claim to have any inside information other than what I have read in the paper, but I have managed enough software development projects to know the root cause of this kind of error. I have been contemplating writing about this for the last week, and first of all I want to say, “Do not fire the person that sent this out!” This was user error but based upon a poorly designed system that is all too common in software development projects. For those of you who aren’t in the industry, let me walk you through how this happens:

“Traditional” Approach to Project Management:

Step 1 Business Requirements: A business person or customer decides what they want an application to do and they create a high-level requirement. e,g. “Create an application to allow a user to send out an alert to the phone and television emergency systems. This application should have a dual purpose for both testing the system and for sending actual alerts.”

Step 2 Analysis and Design: Analysts then create a set of system requirements based the business requirement. A designer designs screens to support the application. An architect designs how each piece will work together. They write everything down and get sign-off from their business stakeholder. They then hand it to a software developer to build. Sounds good so far?

Step 3 Development: (This is where it really break down) The developer builds it exactly the way it was written down!

Step 4 Testing: (Final failure point.) The developer hands-off the application to the tester, who tests it to make sure it meets the original business requirement and technical specifications. Once it passes the tests, it is ready to go live.

Again, for those of you who are not in this industry, the above steps probably seem completely reasonable, and many projects are still run this way. The problem is, this approach is why 50% of projects fail. I worked under this model for about 10 years until I experienced a couple of major project failures. Those project failures probably cost more than the above mentioned failure because they were expensive commercial software development projects that built a product “exactly the way it was written down.”

After those experiences, I became an Agile evangelist. For the last 10+ years I have focused on managing, consulting and training on Agile practices. We still have failures but there are far fewer, and if we fail, we fail fast. Also, Agile software development is a true collaboration between the users and the developers. So, for those of you who do not know much about Agile, let me tell you how we (the Agile community) would manage this project:

Agile Approach to Project Management: 

Step 1 Business Requirements: This step is pretty much the same – a business person creates a high-level requirement. e,g. “Create an application to allow the user to send out an alert to the phone and television emergency systems. This application should have a dual purpose both for testing the system and for actual alerts.” We call this big requirement an Epic.

Step 2 Analysis and Design – Agile Discovery: (This is where everything changes) There is no analyst or middle-man between the developer and the business. Here is what we do:

  • The business person is part of the project and joins the development team.
  • At the start of the project we then have a workshop to break that big requirement into smaller requirements called user stories.
  • Included in the workshop are the people who will be developing and testing the software, business people, potential users and any interested stakeholders.
  • There is a facilitated session where we review the high level requirements and ask the following questions*:

What will the user likely do next?

What mistakes could they make?

What could confuse them?

What additional information might they need?

*Let me be clear, I did not come up with these questions in response that alert failure. It may look like I am using hindsight to fix the problem since asking those questions and addressing them would have obviously prevented the alert from being sent out. The reality is, I took those questions directly from an Agile training I have been delivering for years. I learned that technique from a leading Agile author, Mike Cohn, in his book User Stories Applied: For Agile Software DevelopmentThis is a common technique in Agile to ensure an application is well thought through.

  • The final difference in this step is that in that requirements meeting the developers are listening, asking questions, and writing notes that make up the specification. There is no second hand information, they design and build the application based upon their conversation with their customer.

Step 3 Agile Development: A key difference in Agile is that requirements are presented as a problem to solve not a specification to be built. It is the developers’ job to come up with a solution. The developers understand the business need since they reviewed the requirements with their customer. They are empowered to ask questions and clarify the design while they build it. They have a business owner or customer representative on the team who is available daily to answer questions. They are asking questions in real time, such as, “It seems like the requirement to test the system and execute a real alert are very different activities and should have a very different workflow and authentication model? Technically, there are many ways we can prevent errors from happening. Can I show you a couple of options?” Again, I am not using hindsight. I worked with systems that had a single critical field that if filled in incorrectly required a lot of work to fix. In those cases developers know the technical, and often simple, best practices to ensure quality of data entry. You may have seen these before even on a regular webpage:

  • Please enter your password again (replace the word password with “authorization for an alert”)
  • Please type YES if you want to close this screen without saving (replace the words without saving to “send the alert”)
  • A more advanced technique I have used in the past is called Double Key Data Entry.This a common technique for ensuring quality of high-risk data entry. Two different people have to enter the same information before the workflow can progress. I used it on a project for entering SSNs since an incorrectly typed SSN caused a new customer to be created instead of updating an existing customer. This prevented a lot of rework. Seems like this would be a great approach for this situation.

Step 4 Agile Testing: Testing is done very differently as well. We test as soon as we build a single functioning piece of software. We don’t wait until we build the entire application. That prevents the high cost of fixing errors. Also, another difference, and probably more critical in this situation, is we write all of our test cases, called acceptance criteria, before we develop anything. That ensures that the developer knows how the product is going to be tested and then used in the real world.

Again, don’t blame the end-user. This happens all the time our industry it’s just that the failures aren’t so public. This is why implementing Agile has become mission critical for many organizations. Implementing Agile to prevent these problems rather than assigning blame is the real lesson learned from this experience.

About the Author, Dan Tousignant

Dan is the president of Cape Project Management, Inc. and is a lifelong project manager. He has embraced Agile as the most effective way to manage software development projects. He has been managing mission critical projects and developing training for over twenty-years and is passionate about improving project team performance.



The Practical Agile Blog

The Practical Agile Blog

The Practical Agile Blog

Finding ways to be Agile in an un-Agile world.
Can You be Agile in Your Acquisitions?

Can You be Agile in Your Acquisitions?

This is one of the most common issues facing organization choosing to switch to Agile. Can you acquire goods and services in an Agile fashion? Can you contract with vendors to deliver in an Agile fashion?

read more