The king is dead! Long live the king!

The king is dead! Long live the king!

I watch every few years as someone tries to crown a new king. You know what? Agile is dead, but it is also alive and well.

Here are some personal observations on this contentious topic for those of you who are new to Agile.

The word Agile was never intended to denote prescriptive frameworks. In this context, the word just comes from the Agile Manifesto, which was a conversation between some smart people who shared what was working for them as they managed software development projects. The authors “met to talk, ski, relax, and try to find common ground.” It included a small subset of the people who were following new, non-prescriptive, highly documented approaches. It was never intended to be considered Moses coming down from the mountain—it was written on a three-day weekend!

And don’t get me started on Scrum. It was an accidental success! In 2000, I was a project manager for one of the first documented Scrum projects. It was inherently flawed, but it was still held up as a shining example. Granted, I love the simplicity of Scrum, but as Ken Schwaber is famously quoted about Scrum, “Two days to learn, a lifetime to master.” Too many people have learned Scrum, and too few have any idea what it takes to master it.

I have a confession to make: I SUCCESSFULLY DELIVERED PROJECTS USING A WATERFALL APPROACH! There, I said it. We old-timers, like those who wrote the Agile Manifesto, actually saw success before the Agile Manifesto miraculously was written. We managed mission-critical projects and ADAPTED our waterfall approach based on the changes in the marketplace. In the late ’90s and the dot-com boom, market pressure forced us to think differently. We needed to deliver new websites and functionality every week in order to keep up with our competitors. It was not about “being Agile”; it was about doing whatever we had to do to get something out this Friday. Here is what Agile sounded like back then:

“Hey, let’s meet every day and make sure we are on track,” and “Oh yeah, the development guys say that QA is slowing everything down; let’s start automating the common test cases so we can release faster,” or “Don’t bother writing specifications for three months; we will have missed our deadline by then, so let’s just sit down and design the screen together, and I will show it to you when I have it working.”

IT WAS NOT ROCKET SCIENCE—IT WAS COMMON SENSE AND MADE GOOD BUSINESS SENSE, TOO!

I used the phrase new to Agile earlier. By that I mean that if you have only experienced Agile in the last 10 years, you need to realize that any company that has adopted an Agile framework in that time period is a late, late adopter. Companies that needed to develop software quickly in order to be competitive were being Agile long before without worrying about terminology or frameworks. You don’t hear those companies saying Agile is dead. Agile is now in their DNA, and they don’t even call it Agile. It’s just how they run their businesses. In early 2000, I worked at a company using a RAD and JAD approach to software development. Those approaches pre-date Agile by at least a decade but did not have the appeal of the Scrum terminology. They were similar and better in many ways. We did not call what we were doing Agile. We just called it project management using rapid application development.

I have written this post at least a thousand times in my head as I watch this industry that I love get lost in terminology and frameworks. I am told now that I can’t call myself a consultant. I have to call myself a coach. I feel as if coaching distances me from my customer’s success or failures; as a consultant, I have chosen to be part of the journey. Just my opinion.  I NOW HAVE TO BE CERTIFIED AND LICENSED IN A FRAMEWORK IF I WANT TO TEACH SOMEONE SOFTWARE DEVELOPMENT BEST PRACTICES. My 20+ years of experience is less important than if I can memorize the Scrum guide backward and forward…and don’t even get me started on scaling.

I love what I do, which is making organizations and teams more successful. I am confident that if I had never read the Agile Manifesto or the Scrum guide, I would still be as successful as I am today.  I jumped on the Agile bandwagon because it just made good sense, and it gave me and many other people labels for things we were already doing.

I wish now that there was a new king so I could separate myself from the noise, but unfortunately, the new king would look a lot like the old one.

One last piece of advice—not for coaches but for those of you who are still optimistic that Agile is alive and well:

  • Identify the problem you are trying to solve.
  • Ask someone with a little grey in their hair what has worked before to solve their problem.
  • Try it.
  • If it works, great, if it doesn’t, try something else.

 

An Agile framework can make you feel Agile; only people can make you be Agile.

—Me

Dan is the President of Cape Project Management, Inc. He has been managing software development and other projects since the ’90s. In 2010, he founded a company whose sole focus is to make his clients successful. He is passionate, committed, and works with lots of smart people who think like him. If you are looking for ways to make your business more successful, I suggest you give him a call or drop him a note. Remember, advice is free, until it isn’t.

Agile Consulting Manifesto

Agile Consulting Manifesto

My Agile Consulting Manifesto.

While delivering successful software development projects for over 20 years and seeing the profession that I am so passionate about become damaged by misinformation, framework saturation and a complete loss of credibility, I have come to value:

Consulting over coaching
Experience over frameworks
Long-term value over short term gains
Team member empowerment over leadership status quo
Integrity and values over hourly rates

That is, while there is some value in the items on the right, I respect those who value the items on the left more.

 

I am an Agile consultant, not an Agile coach. As an Agile consultant:

  • I will share in the responsibility for product delivery.
  • I will make recommendations based upon my experience regardless of what is written in a book, framework or blog.
  • I will lose sleep thinking of ways to help my client be successful.
  • I will role model effective leadership and communication.
  • I will care passionately about each and every individual team member's development.
  • I will choose integrity and values over a paycheck EVERY SINGLE DAY.

#agile #leadership #wehavelosttheforestthroughthetrees

 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.

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.

References:

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

How Agile are you? Free Agile Maturity Assessment

NEW! Become a Certified Agile Professional

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 MoSCoW 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.

The Overlooked Agile Topic: Psychological Safety

Psychological safety is an essential aspect of Agile teams that is often overlooked, despite its significant impact on team performance and collaboration. This concept involves creating an environment where team members feel comfortable sharing their ideas, asking...

Why Companies Struggle to Embrace the Lean Startup Approach (and How to Overcome It)

You've probably heard of Eric Ries' groundbreaking book, "The Lean Startup." The methodology has revolutionized the way many entrepreneurs and businesses approach product development and innovation. But, despite its proven success, some companies still struggle to...

Why Agile Implementations Fail

Have you ever wondered why some companies fail when trying to implement agile methodologies? Well, let me tell you, there are a few reasons. First of all, if management isn't fully on board with the cultural shift that agile requires, the teams are going to struggle....

Applying the Stacey Model: When is Agile the Right Fit for your Project?

The Stacey model is a framework developed by Ralph Stacey that categorizes complex problems into four domains: simple, complicated, complex, and chaotic. The model considers the degree of certainty of the problem and the level of agreement on what needs to be done....

Waterfall is not always bad

#agilecoachingtip Waterfall is not always bad! Some projects are inherently phased-based. One recent example was a vendor selection project that I was asked to assess. It was being mismanaged using Scrum. I could list a hundred different examples like that. Can you...

2020 Scrum Guide Changes and Observations

  The following video addresses my interpretation of the 2020 Scrum Guide changes and their impact both to those currently studying for the PSM I or PSPO I exams and for those who want to understand what these changes mean to their current implementation of...

The king is dead! Long live the king!

I watch every few years as someone tries to crown a new king. You know what? Agile is dead, but it is also alive and well.

Agile Consulting Manifesto

My Agile Consulting Manifesto. While delivering successful software development projects for over 20 years and seeing the profession that I am so passionate about become damaged by misinformation, framework saturation and a complete loss of credibility, I have come to...

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...

How Agile are you? Free Agile Maturity Assessment

NEW! Become a Certified Agile ProfessionalWhen 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...
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.

www.capeprojectmanagement.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...

Summary

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.

The Overlooked Agile Topic: Psychological Safety

Psychological safety is an essential aspect of Agile teams that is often overlooked, despite its significant impact on team performance and collaboration. This concept involves creating an environment where team members feel comfortable sharing their ideas, asking...

Why Companies Struggle to Embrace the Lean Startup Approach (and How to Overcome It)

You've probably heard of Eric Ries' groundbreaking book, "The Lean Startup." The methodology has revolutionized the way many entrepreneurs and businesses approach product development and innovation. But, despite its proven success, some companies still struggle to...

Why Agile Implementations Fail

Have you ever wondered why some companies fail when trying to implement agile methodologies? Well, let me tell you, there are a few reasons. First of all, if management isn't fully on board with the cultural shift that agile requires, the teams are going to struggle....

Applying the Stacey Model: When is Agile the Right Fit for your Project?

The Stacey model is a framework developed by Ralph Stacey that categorizes complex problems into four domains: simple, complicated, complex, and chaotic. The model considers the degree of certainty of the problem and the level of agreement on what needs to be done....

Waterfall is not always bad

#agilecoachingtip Waterfall is not always bad! Some projects are inherently phased-based. One recent example was a vendor selection project that I was asked to assess. It was being mismanaged using Scrum. I could list a hundred different examples like that. Can you...

2020 Scrum Guide Changes and Observations

  The following video addresses my interpretation of the 2020 Scrum Guide changes and their impact both to those currently studying for the PSM I or PSPO I exams and for those who want to understand what these changes mean to their current implementation of...

The king is dead! Long live the king!

I watch every few years as someone tries to crown a new king. You know what? Agile is dead, but it is also alive and well.

Agile Consulting Manifesto

My Agile Consulting Manifesto. While delivering successful software development projects for over 20 years and seeing the profession that I am so passionate about become damaged by misinformation, framework saturation and a complete loss of credibility, I have come to...

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...

How Agile are you? Free Agile Maturity Assessment

NEW! Become a Certified Agile ProfessionalWhen 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...
error

Enjoy this blog? Please spread the word :)