Want to Boost Your Scrum Projects’ Success Rate by 50%? Run Them Through a PMO

By J. LeRoy Ward, PMP, PgMP, PfMP, CSM, GWCPM, SCPM   |   Executive Vice President – Enterprise Solutions, IIL

Catch LeRoy’s presentation, “Agile: The One Bandwagon You May Want to Jump On!,” at the virtual Agile and Scrum conference on May 4th.

The 2015 State of Scrum Report (the most recent) released by the Scrum Alliance has several interesting, if not head-scratching, findings. Here are two that really stopped me dead in my tracks.

First, the report stated that “the overall success rate of projects delivered using Scrum is 62%.”  

This floored me. Why? Given all the hype and hoopla about Scrum and all of its intended benefits, I would have assumed that this number would be quite a bit higher. Heck, 62% isn’t much better, if it’s better at all, than projects completed with more traditional methods.  Why go through some wrenching organizational change, the change that Scrum often means for large traditional IT shops, when, in the end, the result is the same?

But it was the second finding that got my attention, and fast.

The report also disclosed, based on the respondents answers, that “Scrum projects run through a project management office (PMO) have a 93% success rate.”  

That’s a 50% improvement over Scrum projects not run through a PMO. A 50% improvement in almost any measure is simply astounding. Hey, look at it this way, if your boss called you into his office and gave you a 50% raise that would get your attention wouldn’t it? You bet.

Unfortunately, the survey offers little if any insight as to why running Scrum projects through a PMO results in such a performance boost. Apparently, they didn’t have any follow-up questions such as “Why does the PMO matter so much?” Or, what’s the ONE THING a PMO does that really makes a difference when implementing Agile?” Too bad. That’s a lost opportunity to help organizations understand what services a PMO provides that can lead to such gains. Maybe the Scrum Alliance will add those additional, clarifying questions, in their next survey. I hope so.

Let me offer a few plausible reasons why a PMO can help improve Scrum project success.

To do so, I reviewed the results of a number of “State of PMO” and “State of Agile” reports for some answers. In one report, when respondents were asked “Why is Agile difficult to implement?” the answers included:

  • Changing the culture
  • Changing from traditional methods
  • Right leadership to drive change
  • Upskilling teams
  • Understanding Agile’s value
  • Motivating teams to use Agile

Perhaps running Scrum projects through PMOs who were catalysts in changing the culture, who helped folks change from traditional waterfall to Scrum with concrete suggestions, who had the type of bold leadership required, and who made sure all the folks involved in Scrum projects were trained, and not just the Scrum masters, were reasons for greater success.

Other findings in these various surveys reveal that not many PMOs are taking the “bull by horns,” or any other sensitive place (like the tail!), to help with a transition to Agile methods. For example, when asked “How are PMOs supporting Agile?” only 4 in 10 said they were providing Agile training, and only a third claimed they were helping with a new methodology, approach or new reporting processes. Twelve percent didn’t even know how the PMO was helping. That’s not a significant level of engagement.

Hundreds, if not thousands, of organizations have bought into the promise of Agile, yet by all accounts an overwhelming majority are struggling to implement it.

The PMO has a huge role to play, and when done well, working in conjunction with a committed Senior Management team who invests in Agile training and change management practices, the results can be astounding.

A 50% improvement in project success should have every Senior Executive working with his or her PMO manager to see if they can realize those types of gains. Sitting around bellyaching about poor project performance when opportunities to improve are staring us all in the face should prompt action, and FAST.

More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.

Ready to improve your project success rates? IIL can help. Request a free consultation today.

[trx_infobox style=”regular” closeable=”no” icon=”inherit”]LeRoy Ward

About the Author

J. LeRoy Ward is a highly respected consultant and adviser to Global Fortune 500 Corporations and government agencies in the areas of project, program and portfolio management. With more than 38 years of government and private sector experience, LeRoy specializes in working with senior executives to understand their role in project and program sponsorship, governance, portfolio management and the strategic execution of projects and programs. [/trx_infobox]

Do Too Many Cooks Spoil the Broth? In Scrum They Do!

By J. LeRoy Ward, PMP, PgMP, PfMP, CSM, GWCPM, SCPM   |   Executive Vice President – Enterprise Solutions, IIL

Catch LeRoy’s presentation, “Agile: The One Bandwagon You May Want to Jump On!,” at the virtual Agile and Scrum conference on May 4th.

How many cooks do you need in a kitchen? The answer is you can have as many as you like as long as one is the boss. If you don’t have a boss, there’s chaos.

In a kitchen, there is one that is the boss, the Executive Chef (often called “Chef”), and he or she calls the shots. Everyone else (such as the Sous Chefs, Pastry Chef, Line Cooks and all the other kitchen staff) knows exactly how the system works and who’s in charge. In fact, this hierarchy works very well. Just look at any major restaurant or hotel kitchen and you’ll see exactly what I mean. (I’ve worked in restaurants large and small, independent, and as part of a large resort hotel, and I can tell you the Chef is indeed the boss!) Do you think for a second that Gordon Ramsay, Bobby Flay or Mario Batali is not the boss in their kitchens? Think again.

But in Scrum, too many “cooks,” or Scrum team members, really do spoil the “broth” (read: project). Why? Because in Scrum there is no “boss.”

The Scrum team is supposed to be a self-organizing body who figures things out on their own. There’s no Project Manager barking out orders, and the Scrum Master’s role is limited to ensuring the Scrum process is being followed and no one bothers the team.

According to The 2015 State of Scrum Report published by the Scrum Alliance, Scrum teams averaged seven members. The recommended size range is seven, plus or minus 2. Respondents in IT/software development reported an average team size of 6.6 members.

Team size evidently does have an impact of Scrum success. For example:

When there are 4-9 members on a team, Scrum is successful 77% of the time.

When there are 10 or more, Scrum success drops to 65%.

When there are 3 or fewer on a Scrum team, the success rate is only 50%.

So, not only does having more than the recommended number of members negatively impact success, so does having fewer than what’s recommended.

To be sure it’s difficult to self-organize when there are more than 10 team members. First, if everyone is ostensibly equal on a self-organizing team then everyone will have their say, resulting in a large number of opinions that have to be discussed and debated (sometimes endlessly). While the ultimate decision may be sound, oftentimes these kinds of discussions end in compromises. And while a compromise decision may soothe the egos of those involved, it may not be the best one for the project.

I also think that too many team members invoke an Animal Farm mentality, which you will recall if you read Orwell’s classic, can best be expressed and rephrased as:

“All Scrum team members are equal, but some are more equal than others.”

When the “more equal” members assert their influence, the others either fall in line, rebel, or become alienated. Hardly the end result anyone wants from a self-organizing team.

With three or fewer team members, I just don’t think there’s enough diversity of experience and ideas to reach the best decision. Three’s a crowd, as the old saying goes, and perhaps some issues arise when two members feel strongly about one course of action, and the holdout has to simply agree. If that happens enough, the third wheel, as it were, stops rendering his or her opinion.

So, we’re left with seven (plus or minus two) as the optimum team size in Scrum. But wait a minute, seven has always been touted as the optimum number of team members in project management, at least for the core team. So, what’s the big deal about Scrum and the number seven? Not much really, and that’s the point.

We can apply many of the best practices we’ve used all these years on traditional projects on our Scrum projects and, in fact, we should. After all, our only goal is to get the project done successfully. However way gets us there is the route we should take.

More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.

Ready to improve your project success rates? IIL can help. Request a free consultation today.

[trx_infobox style=”regular” closeable=”no” icon=”inherit”]LeRoy Ward

About the Author

J. LeRoy Ward is a highly respected consultant and adviser to Global Fortune 500 Corporations and government agencies in the areas of project, program and portfolio management. With more than 38 years of government and private sector experience, LeRoy specializes in working with senior executives to understand their role in project and program sponsorship, governance, portfolio management and the strategic execution of projects and programs. [/trx_infobox]

Debrief? "Ain’t Nobody Got Time for That!”

By Joel “Thor” Neeb    |    President – Afterburner

Catch Thor’s presentation, “Bridging the Gap with Agile,” at the virtual Agile and Scrum conference on May 4th.

We conducted a Debrief after every one of the more than 2500 Missions I flew as a fighter pilot and trainer pilot. We would discuss what went well, what didn’t, and more importantly, how we would improve our team execution next time.

These Debriefs were critical to developing the skills of our younger pilots and creating a high performing team that could fly in coordinated formation faster than the speed of sound.

Mustang MayhemBut Debriefs are just for fighter pilots and battlefield soldiers, right? After all, your corporate team doesn’t Debrief and they’re doing just fine.

Well, leading academic research shows that you can’t afford not to Debrief.

In their article for Human Factors: The Journal of the Human Factors and Ergonomics Society titled “Do Team and Individual Debriefs Enhance Performance?” Dr. Scott Tannenbaum and Dr. Chris Cerasoli analyzed more than 40 different independent research projects on the power of conducting Debriefs.

In their giant meta-analysis they arrived at the following conclusions:

  • Rudimentary Debriefs increased team effectiveness by up to 25% on the next project
  • Structured Debriefs increased team effectiveness by up to 38% on the next project
  • Having a third-party facilitate the Debrief increased team effectiveness by an additional 27%

So, what could Debriefs do for an organization? Let’s do the math.

There’s an eye-opening study that’s appeared in Harvard Business Review articles that states that only 33% of corporate America’s projects are completed on time, in scope, and in budget. I know, I know – that doesn’t apply to your company, you’re pulling up the average. So let’s start off by saying that you’re completing a whopping 60% of your corporate Missions. And let’s say that even though you’re not Debriefing, your teams still learn from the school of hard knocks and improve by an incredible 5% each time they tackle a project together. Here’s how their Mission effectiveness would improve over time:

Project 1
Project 2
Project 3
Probability of Mission Success

So, 5% more efficiency each time means you’ll have a 64% chance of success after three iterations of performing together as a team (note that we don’t increase effectiveness by 5% each time – we have 5% less chance of failure). Not too shabby, right? You’ve gelled together a bit as a team, new team members have gained a little experience, and you’ve increased your efficiency a bit.

But what would our team effectiveness look like if we had conducted a structured Debrief that was facilitated by a third party?

Project 1
Project 2
Project 3
Probability of Mission Success

The team that conducts structured, 3rd party-facilitated Debriefs is 25% more effective after three project iterations together and enjoys an 85% success rate on their third Mission.

Stop and look at those numbers again – what would that level of improvement mean for your team performance, your organizational culture, or your company in general?

“But,” you say, “Are those study statistics really repeatable in practice?”

They are. With our last client, a tech giant based out of Silicon Valley, our team at Afterburner supported more than 50 Missions through iterations of Plan-Brief-Execute-Debrief, and 91% of them were successful.

“But,” you say, “Debriefing takes time.” And that’s the one resource you’re running short on.

In his groundbreaking book 7 Habits of Highly Successful People, Stephen Covey relayed an oft-repeated story. In it he described two lumberjacks that were feverishly sawing away at a tree with a two-man saw. They were making little progress because their saw was dull and ineffective. When asked by a passerby why they didn’t stop to sharpen their saw, the lumberjacks replied “We can’t stop to sharpen the saw! We’re too busy sawing!”

When’s the last time your team sharpened their saw?

In the two decades that Afterburner Inc. has been in existence we’ve asked more than 3 million people at over 5,000 of our client companies to rate their own organization’s commitment to Debriefing. Unsurprisingly, the data for the past 20 years shows that corporate America rates itself about a 3 out of 10 on Debriefing. In other words, few companies Debrief, and even fewer do it well. We believe that’s because few companies know just how impactful Debriefing would be for their team or organization.

But, you don’t have the time to Debrief, right? Hopefully your competition doesn’t either!

More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.

[trx_infobox style=”regular” closeable=”no” icon=”inherit”]joel-neeb

About the Author

Joel “Thor” Neeb is the President of Afterburner, a group of fighter pilots, Navy SEALs and other SpecOps members that leverages the leadership development principles of elite military teams to help corporations achieve their Strategic Objectives. Contact Afterburner for a free consult on how to conduct a structured Debrief with one of their Debriefing experts.[/trx_infobox]

I’m a Project Management Professional (PMP)®! Why Do I Need Agile?

By Kellie Morrell   |   Agilist, PMI-ACP & PMP, CSM, CSP, AHF, AFC, ICAgile ICP and ATF
Enterprise Agile Coach and Trainer, Agile Transformation Inc.

That was my question 9 years ago.  I had earned my PMP® certification in 2002 and was proud of it.  I had been somewhat successful in managing my projects; or least the ones where the clients did not change their requirements every other day.  So why would I need to learn something new?

My reason was very simple…my Senior Management asked me to pilot Agile for the organization. My first step was to find out what ‘Agile’ meant since I didn’t have a clue.

Agile Education

I attended a “Real World Agile” course by Agile Transformation, Inc. They also provided me with an Agile Coach. I learned that Agile was just another ‘tool’ in the project management ‘tool box.’  My Trainer and Coach helped me learn the basics of Agile.

[trx_infobox style=”regular” closeable=”no” icon=”icon-ok”]Learn more about IIL’s Agile Project Management courses >>[/trx_infobox]


The Main Agile Roles

  1. Product Owner – Business Owner that sets the business vision and priorities of the work. They also accept and/or reject the work the Team does.
  2. Team Members – Developers, Analysts, Testers, Subject Matter Experts (SMEs), etc.
  3. ScrumMaster – Agile Project Manager who facilitates the Agile process and meetings. They also are focused on the Team’s health and removing any impediments or road blocks the Team may have.  This was my new role.

The Main Artifacts

  1. Product Backlog – Requirements log in highest priority.
  2. Sprint or Iteration – A time box of 2-4 weeks where the team designs, codes, and tests and the Team could potentially move to production.
  3. Sprint Backlog – Requirements log of work to be completed in the 2-4 week Sprint.
  4. Burndown Chart – Daily progress of the team burning down their hours to the end of the sprint. Show roadblocks early.

The Main Meetings/Ceremonies

  1. Sprint Planning – What work the team wants to commit to getting done in the next sprint (2-4 weeks).
  2. Daily Scrum or Stand Up Meetings – A 15 minute meeting where you stand up and answer 3 questions.
    • What work did you get done yesterday?
    • What work are you going to commit to get done today?
    • Do you have any impediments?
  3. Sprint Review/Demo – The Team shows the work they have completed to Stakeholders and get their feedback. Time to celebrate as well.
  4. Sprint Retrospective – We called these ‘Lessons Learned’ meetings in Traditional project management and took place at the end of the project. These are completed each sprint and answer these 2 questions.
    • What did we do well this sprint?
    • What could we improve upon for next sprint?
  5. Agile embraces continuous improvement. The team would select 1-2 items from the Retro list that they want to get better at next sprint.

How I Made the Transition from PMP to Agile

Agile is not all that different than Traditional project management. The big change is the focus on People and Value Delivered versus the project management process. In Traditional project management, I always had an Initiation Phase and a Planning Phase. So does Agile. At the end of my Traditional projects, I always had a Release into Production. So does Agile. The big difference is the iterative planning and the iterative development. Agile project teams have a Closing Phase for the project work, but continue on the next highest priority project. Their closing phase is really a few stories and, of course, a celebration.

The big difference in Traditional and Agile is the iterative planning and development. This took me about 3 months to really learn how to break down the large work efforts (epics) into smaller chucks so we could deliver during our 2 week sprints.  I finally learned that the smaller the chunk of work, the better we can understand it, design it, code it, test it, and deliver something valuable that we could get quick feedback on.


Hardest Lessons Learned

  1. I was surprised to learn that Agile aligns with A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fifth Edition (2013)
  2. I was also surprised on how many other PMPs were doing Agile.
  3. I learned the pros of Traditional Project Management:
    • Structured management
    • Budget and schedule predictability
    • Easy to scale
    • Skills Specialization
    • Documentation = knowledge transferability
    • Familiarity – often part of organizational culture
    • Structural support from other departments
  4. I also learned the pros of Agile:
    • Early and continuous delivery
    • More flexibility
    • More certain to deliver what the customer wants
    • Less defects in the final product
    • Higher visibility with frequent validation and transparent reporting
    • Increased estimating accuracy
    • More customer interaction
    • Improved team morale


Advice for Us “PMPers” Making the Transition to Agile

  1. “You can use all Agile some of the time and some Agile all of the time.” So try it.
  2. Allow yourself time to adjust to the new terminology, roles, process, and iterative development. It took me about 3 months before I began to feel comfortable with the framework and ceremonies.


Just like a good carpenter, you must know what tool will work the best depending on the job you need to do. Sometimes you will need a hammer; other times it will be an electric drill. The key is to know how both work, so you can select the best project management practices for your Project/Program and your Culture. In the end, what is really important is your organization’s Enterprise Business Agility. The method or framework you select will depend on the project.

Whether a PMP or Agile Certified Practitioner (PMI-ACP)®, our job is to facilitate the projects/programs, drive innovation in our organization, and keep up with the market and competition. Having both Agile and Traditional project management knowledge and experience will make you a better project manager. And you will have a few extra “tools in your PM tool box.”

More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.


PMP, PMBOK and PMI-ACP are marks of the Project Management Institute, Inc.

Agile Marketing: Expanding Agile Outside of IT

By Maria Matarelli   |   Certified Scrum Trainer (CST) – Formula Ink

Real Agile transformation includes more than just your IT department. Yet Agile continues to be strongly associated with software development.

What if your organization not only developed products faster, but reached more customers in less time? Imagine if you could truly connect with your ideal customers and develop a relationship so strong that it brought exponential increase in the number of people buying your product. What if speed to market didn’t just stop at the launch point, but flowed seamlessly throughout your organization through the end sale?

When applying Agile to departments outside of IT, dramatic results have brought new attention to what previously existed as theoretical concepts. But what exactly about this new approach to marketing makes it so Agile? Our approach to Agile Marketing extends beyond the world of theory and into real-time, practical, marketable application.

The Agile Marketing initiative began many years ago, but while we’ve seen IT teams effectively increase their speed to market, other departments have yet to catch up to this level of performance until now.

So what exactly is Agile Marketing?

Agile Marketing is:

  • An iterative process for fast results and sustainable growth
  • Focusing on customer relationships that carry the most value
  • Organizing your marketing into channels
  • Creating the systems and messaging to reach your ideal customers

All of these points direct our focus back to the main idea which is that good business is about putting people first. Whether it is the employees, the customers, or any individual involved along the way, the primary focus has to be the person, not the product. And more importantly, the customer needs should be at the forefront.

Agile Marketing provides a very unique outlook on the process of sales and marketing. It’s a fundamental shift in mindset. Instead of focusing on who you can sell to, the focus is shifted to who needs you most while leveraging rapid iterations for maximum output.

As we began applying Agile to marketing with clients, we began to see an incredible increase in revenue. By uncovering the true message to market match combined with short iterative testing cycles, we were able to identify the right customer with the right messaging and discover how the product or service could truly meet their needs, which led to incredible growth.

With clients getting more than 300% increase in revenue in just 6 months and more than 780% increase in revenue in a year, we launched a case study program to solidify the Agile best practices as applied to marketing. While pulling specific techniques from Lean, Kanban, Scrum, and Extreme Programming (XP), the benefits were clear: Agile Marketing gets results.

As many companies reach toward true organizational agility, it is important to look across departments and outside of IT. Leveraging Agile in marketing creates a common language across departments which puts the emphasis on results that are tied to revenue.

More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.

[trx_infobox style=”regular” closeable=”no” icon=”inherit”]Maria Matarelli_Formula Ink photo

About the Author

Maria Matarelli is a Certified Scrum Trainer (CST) who travels the world on one-way tickets consulting and training companies on reaching true agility. In addition to applications of Agile in IT, Maria and her team have been applying Agile to the Marketing realm with incredible results. To learn more about Agile Marketing, join our community at: http://Community.AgileMarketingAcademy.com[/trx_infobox]

Building the Lean-Agile Enterprise with the Scaled Agile Framework 4.0

By Dean Leffingwell   |   Co-founder and Chief Methodologist – Scaled Agile, Inc.

Catch Dean’s keynote, “Ten Essential Scaling Patterns We Can (Probably) All Agree On,” at the virtual Agile and Scrum conference on May 4th.

The world’s economy, and the health and welfare of society as a whole, is increasingly dependent on software and systems.

In support of this need, systems builders are creating increasingly complex software and cyber-physical systems—systems of unprecedented scope and complexity—with requirements for utility and robustness exceeding those that have come before them.

The methods that systems builders use to create these systems must keep pace with this larger mandate. However, the assumptive, one pass, stage-gated, waterfall methods of the past are not scaling to the new challenge. New development methods are needed. Agile shows the greatest promise, but was developed for small teams, and by itself, does not scale to the needs of the larger enterprises and the systems they create. What’s needed is a new way of working, one that applies the power of agile, but leverages the more extensive knowledge pools of systems thinking and lean product development. The Scaled Agile Framework (SAFe) is one such approach.

A Brief Overview of SAFe

The Scaled Agile Framework (SAFe®) is a freely-revealed knowledge base of proven, integrated patterns for enterprise-scale Lean-Agile development. It is scalable and modular, allowing each organization to apply it in a way that provides better business outcomes and happier, more engaged employees.

SAFe synchronizes alignment, collaboration, and delivery for large numbers of agile teams. It supports both software and systems development, from the modest scale of well under 100 practitioners to the largest software solutions and complex cyber-physical systems; systems that require thousands of people to create and maintain. SAFe was developed in the field, based on helping customers solve their most challenging scaling problems. SAFe leverages three primary bodies of knowledge: Agile development, Lean product development, and systems thinking.

The SAFe website provides comprehensive guidance for scaling development work across all levels of an enterprise. SAFe’s interactive “Big Picture” (Figure 1) provides a visual overview of the framework. Each icon on the website is selectable, navigating the user to an article which provides extensive guidance on the topic area, along with links to related articles and further information.

The Big Picture has two views. The default “3-level view” (below left) is well suited for solutions that require a modest number of agile teams. The “4-level view” (below right) supports those building large solutions, solutions that typically require hundreds or more practitioners to build and maintain.



Figure 1. Big Picture: 3-level and 4-level SAFe

SAFe provides three (optionally four) organization levels, as follows:

  • Team level – SAFe is based fundamentally on Agile teams. Each team is responsible for defining, building, and testing stories (small pieces of new functionality) from their backlog. Teams deliver value in a series of fixed-length iterations (also called sprints). Teams use a common iteration cadence to synchronize work with other teams; this allows the entire system to iterate simultaneously. Teams employ Scrum (primarily) or Kanban methods. Each method is augmented by quality practices: many software quality practices are derived from eXtreme Programming; hardware and system quality practices are derived from contemporary lean product development practices.
  • Program level – SAFe teams are organized into a virtual program structure called the “Agile Release Train” (ART). Each ART is a long-lived, self-organizing team of Agile teams (typically 5 to 12), along with other stakeholders, that plan, commit, execute and inspect and adapt together. ARTs are organized around the enterprise’s significant value streams. ARTs align teams to a common mission, provide architectural and user experience guidance, facilitate flow, and provide continuous objective evidence of progress.
  • Value stream level – The optional value stream level supports the development of large and complex solutions. These solutions require multiple, synchronized ARTs, as well as stronger focus on solution intent and solution context. Suppliers and additional stakeholders contribute to this level as well. Pre-and Post PI planning inform the ARTs (and vice versa) of the value stream mission and objectives.
  • Portfolio level – The portfolio level organizes and funds a set of value streams. The value streams realize a set of solutions, which help the enterprise achieve its strategic mission, as defined in part, by a set of strategic themes. It provides solution development funding via Lean-Agile budgeting, any necessary governance, and coordination of larger development initiatives that affect multiple value streams.
  • Foundation layer – The foundation layer holds various additional elements that support development. Elements include guidance for Lean-Agile Leaders, communities of practice, core values, the Lean-Agile mindset, the nine principles that guide SAFe, and an overview of implementation strategy.

Taken together, SAFE provides comprehensive guidance for enterprises implementing Lean-Agile development at the team, program, value stream, and Portfolio level.

More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.

You can learn more about SAFe by visiting the website at ScaledAgileFramework.com. SAFe is a property of Scaled Agile, Inc. There you can find courseware, supporting services, and an extensive network of over 80 partners worldwide who provide education and training, consulting and related SAFe services.

To understand more about the proven business benefits of SAFe—substantial increases in quality, time to market, productivity and employee engagement—be sure and visit the Case Studies page.

[trx_infobox style=”regular” closeable=”no” icon=”inherit”]Dean-2_Fullsize

About the Author

Widely recognized as a leading authority on software development, Dean Leffingwell is an author, serial entrepreneur, and software development methodologist. He is the creator of the Scaled Agile Framework, and author of numerous books on software development.[/trx_infobox]

The Secret to Being a Great ScrumMaster or Agile Coach: The People Chip

By Angela Johnson   |   Certified Scrum Trainer & Agile Transformation Coach

Catch Angela’s presentations “Are you a Credible Agile Leader?” and “Is your Daily Scrum Dysfunctional?” at the virtual Agile and Scrum conference on May 4th.

Why do Agile or Scrum trainers seem to walk in “off the street” and immediately pinpoint the people problems?

Clients and students repeatedly ask, “How do you know that?” “Who is giving you this information?” They are dumbfounded when the response is, “Nobody gave me this information. I picked up on the issues right away.”

How have I cultivated this “people chip?” Is it because of Certification as a Scrum Professional or Trainer? Am I psychic? Hardly!

I simply pay attention. I am not “tuned out” looking at a device or taking notes. I am actively employing the Scrum values of Focus and Respect – giving full attention to the conversation and interactions at hand in coaching or training sessions.

This means being present in the moment. The people chip becomes calibrated because Scrum is the way to do the work – not something viewed separately from the way the work has traditionally been done.

Looking directly at people in coaching conversations reveals far more from their facial expression, their body language, etc. in addition to the words that they use. Actively listening means not talking or waiting to talk – but hearing what the person is saying. Sometimes that involves what they are not saying verbally.

Coaching may result in paraphrasing what was said to ensure that I am understanding the true nature of the problem trying to be solved and not making incorrect assumptions. Asking a number of questions can also help get the person “diagnosing” their own issue and help them brainstorm a list of possible next steps to take or next conversations to have in their team or organization.

Want to begin calibrating your People Chip? Try these two tips:

  1. Stop being the Product Owner or Team’s Secretary

    Do you feel like you have to be writing or typing in order to add value? Are you updating charts, tasks, typing into some sort of tool? What are you missing because your Focus is elsewhere? You could have been asking a question to get things moving in the right direction, observed body language that let you know everyone was not in agreement on what Done looks like, or picking up on any number of things.

  1. Stop being the Authority on the Product or Technology

    As the ScrumMaster, or certainly as a Coach, you are neutral. This means that you do not assert an opinion on the Product or the Technology. If you do that you are enabling the wrong behavior. Hand someone a fish and they have food for today. Teach them to fish and they have food for a lifetime. Your job as the ScrumMaster is to cultivate and enable cooperation, collaboration, and teamwork to lead the Product Owner and Team to consensus. You do this through planting seeds, asking questions, and getting the right people together to work on the problem at hand – not by being the authority on any technology or product attribute.

More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.

[trx_infobox style=”regular” closeable=”no” icon=”inherit”]angela-hi-res

About the Author

Angela Johnson, PMP, PMI-ACP, CST is passionate about changing the world of work. She seeks to help people and organizations to break down their barriers and work together in a collaborative way. Angela facilitates the PMI Minnesota Agile Practitioner Community and serves on the Scrum Alliance Trainer Approval Committee. [/trx_infobox]

Scrum for Hardware

By Hubert Smits    |    Management Consultant, SmitsMC LLC

“The rules of the game in new product development are changing. Many companies have discovered that it takes more than the accepted basics of high quality, low cost, and differentiation to excel in today’s competitive market. It also takes speed and flexibility.”

Takeuchi and Nonaka wrote this paragraph back in 1986, and it inspired people to develop Scrum as a way to develop software faster, better and cheaper. Over the last 15 years the Scrum approach has proven to work in many different projects and it has also proven that Scrum is “simple, not easy”.

The general opinion is Hardware (i.e. cars, photo copiers, combine harvesters) cannot be developed with Scrum. The plan-do-inspect cycle of just 2 weeks is considered too short, teams cannot deliver a satisfactory next version of a product under development that quickly. However, I’m here to tell you that experience proves this assumption wrong.


Fifteen years ago I had discussions with many people who were convinced that big software projects, high risk software projects, or software package implementations wouldn’t fit in a Scrum framework. Nowadays projects with 1,500 participants have shown to be successful. Government agencies are firm believers in Scrum. Just like critics in software were proven wrong, so will critics of ‘Scrum for Hardware’!

More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.

[trx_infobox style=”regular” closeable=”no” icon=”inherit”]Hubert-Smits-picture

About the Author

Hubert Smits has been working with Scrum for over 15 years, and as a Scrum trainer for over 10 years. While training all around the world he built a broad and deep experience with Scrum in many domains. Recently he is applying it to develop hardware, like the Wikispeed car.[/trx_infobox]

Software Costs Estimation In Agile Project Management

One of the hardest things to do in software development is to determine how long and how much it will take to deliver a new software product. Should it be so hard? The answer is not straightforward.

Software costs estimation is inherently difficult, and humans are terribly bad at predicting absolute outcomes. No two projects are the same;each is unique in what it sets out to achieve, and unique in the myriad of parameters that form its existence. Often, what appears to be a simple problem on the surface is much harder or technically challenging to implement in reality. And, undoubtedly, there will be ‘unknowns’ with the project that can only be identified when they arise.

Additionally, no two people are the same, whether you’re a customer, a developer or a user. We come preloaded with our own set of knowledge, experiences, values, expectations, attitude to risk, and ability to adapt.

Writing good quality software is bread and butter for senior engineers; creating awesome software products can be a much harder endeavour, for all involved.

Delivering Awesome Software is a Balancing Act

But when it comes to software, understanding duration and cost are key in making strategic business decisions and this is true whether you’re creating a startup, realising a new business opportunity, or enabling your business to perform better. The timing, return on investment and benefit delivered can make, shake or break your business. You’ll be asking yourself: What do we get for our money? Can we predict our costs? What will it cost to create the product we want ? When can we launch? Will we get a quality product for our investment? Will it grow with our business? Will it deliver business value?

So, how do you go about estimating the size, duration and cost of a project? Let’s explore Agile project estimation and software development costs, and how we do it at Toptal.

Traditional Contract Pricing and Estimation

Traditionally, using non-Agile practices, software projects have sought to fix functionality or scope, and to let time and cost be a variable. This causes problems:

  1. How do you know that the functionality you fix at the outset of a project really is the functionality that serves your business or customers best? More often than not, functionality or scope will change, which is why we hear about ‘scope creep,’ the outcome of desired needs being identified through the lifecycle of a project and being determined as necessary or compulsory
  2. When cost becomes a variable we lose control over the return on investment (ROI) that we’re seeking to achieve. Increased cost is often a product of unidentified risks or changing requirements, which means we have to add team members to do more work in the same time frame, or keep team members longer. Neither is desirable
  3. When time is a variable, we lose control over the position in our market. Perhaps we miss an important industry date or our competitors get their product out before us, thus losing any competitive advantage our project may have had.

There are many other outcomes of variable time and cost, which are often negative and undesirable.

Of course, many customers and organisations seek to fix all three components of this ‘magic triangle’. Unfortunately, it’s nigh on impossible to realistically achieve. There are too many elements that conspire to unsettle this ideal, which ultimately end in products that don’t meet a need, take too long to benefit its customers or cost too much to realize business value.

Agile Software Costs Estimation Win Every Time

Agile Contracts for Software Projects

Cost is a product of time and people (team members). Add more time, and you add cost for employing people for longer. Add more team members, and you increase cost to deliver the same business value. The things we really want to avoid. This is why Agile principles believe in fixing time and team members and allowing scope to be the variable component.

Which sounds better and increases stakeholder confidence, fixed cost or variable cost?

Of course, it’s important that a product delivers on its promises and the needs of its customers. It’s no good spending an exact amount of time and an exact amount of money, if at the end, you have a product that nobody wants or can use effectively.

So Agile contracts focus on the following:

  • Fixed price work packages – The whole project is broken down into logical ‘mini’ releases which contribute to the full product outcome. Each release is a work package that is priced accordingly. As a work package is completed, future work packages are re-estimated based on what we have learnt from the previous one. This avoids unnecessary contingency and allows for a level of re-prioritisation and new/revised features to be defined by the customer.
  • Early termination – This allows the customer to seek to terminate the project early if enough of the product has been delivered and there is no further ROI to be achieved by retaining a project team that will only continue to deliver marginal gains. This clause is typically allowed at any time and is valid as long as the project team and customer have maintained a strong, trusting and close working collaborative relationship. The benefit for the customer is that the project will finish early, having delivered all the valuable features necessary to make the product viable. In return, the supplier is paid 20 percent of the remaining contract value and offsets the risk of retaining staff.
  • Flexible changes – Change is a theme that runs strong through the veins of Agile software delivery. We expect to not know everything we need to make a product successful from the outset. So, we promote change, based on relevant data and feedback, to ensure that the right product is delivered. At the end of an iteration, changes can be swapped out for old features no longer deemed necessary or a priority. As long as the change is of equal value, there is no further cost. If the change is of lower value, additional work can be identified or pulled forward from the remaining backlog. This clause is valid as long as the project team and customer have maintained a strong, trusting and close working collaborative relationship throughout the project.
  • Additional work – Through the life of a project, more features may be identified that would not be achievable under the existing fixed price contract. For this scenario, either additional newly priced work packages can be added to the end of the project or revert to time and materials.
  • Ranged estimates – There are two ways that estimates can be ranged in an Agile project contract: a range of duration or a range of features. A range of duration allows for an estimate to say that the project or work package will take 12 to 16 weeks for a given set of scope. However, adding duration adds cost as you keep project team members for longer, or it means they can’t be released to work on other development projects. At Toptal, we prefer to range features across a range of story points, keeping the scope as the variable but promising to deliver a minimum level of value to the customer within the fixed time frame of the work package or overall project.

It’s worth remembering that you can always add more scope later. Perhaps you’ve started to earn revenue, you’ve increased users or reduced costs. Either way, it’s much easier to ask for more money and time if you’ve already demonstrated a return or improvement and are delivering business value.

Agile Contracts

Our approach to software costs and pricing

At Toptal we work closely with our customers and engineers to employ techniques that promote stakeholder confidence in project duration and costs. We work at continually elaborating and adapting planning from an initial high level down to more granular detail when it is appropriate and necessary to avoid waste and to enable managed change.

The following steps are taken in elaborating an estimate and fixed price project:

1. Initial high level scope

At the outset of a project, we know least about it’s eventual outcome. It’s folly to imagine it’s possible to know exactly what features our customers and users need from the beginning.

So, we start with a project charter and a high level set of “epic” features that guide the direction of the project, based on a sound vision and objectives

a. Vision and Objective setting What do we need to build ? What do you need to achieve and what are your business objectives? Understanding these questions allows us to set the scale of the project. Do you need a prototype to test an initial idea, concept or technology? Have you identified a clear proposition that has been tested with your market and are you ready to build your first Minimal Viable Product (MVP)? Or, are you scaling your existing business or product to take it to the next level?

b. High level “epic” features Without going into too much detail, you’ll want to define the features that your product has to fulfil your customer’s needs. This is a structured “shopping list” that describes the bare bones of your product; often these are referred to as “User Stories” or epics

c. MoSCoW analysis MoSCoW analysis is a technique that, put simply, helps to identify what is really necessary to make the product viable and what is a nice to have. Those that are identified as a “Must” satisfy what will encourage users to engage and adopt your product. Those features identified as a “Should” will surprise and delight your customers but could be built later. The “Could” items often add no significant business value, may not increase the return and are the lowest of your priorities. The “Won’t” features could well be important one day but are out of scope for this project iteration. However, identifying these now can help to set in mind the potential scale and size of the product for the future.


2. Proposal

To make a decision on whether to proceed with a project, it’s necessary to base that decision on well informed data: cost and duration. These are the minimums you need to ask yourself: What will it take to create the product we want ? When can we launch? Does this align with our business strategy and finances?

With the details above, we’re in a position to provide a proposal. Our engineers are handpicked for the specific project requirements and work together with a project manager to derive at least one technical solution, an estimated duration that delivers the known scope and an estimated cost to complete the project.

As we mentioned before, at the outset of a project we know least about what will be delivered. We deliberately keep the features and scope vague, since to do otherwise suggests we know exactly what is required. An estimate at this stage would be the least accurate, but gives guidance on whether it’s worth proceeding with the project.

The proposal is the first tool in elaborating the duration and cost of a project. Once a proposal is accepted, we can move forward to provide a fixed priced quote.

3. Release Planning

The next level of estimate elaboration is to create a release plan that will deliver a range of features in a given timeframe. We derive this from a list of features, the size of the project, how quickly our team can develop quality software that meets a customer’s expectations and techniques for managing the risk of uncertainty.

a. Product Backlog The product backlog is simply an ordered list of “Epics” or “User Stories” that represents the features required for a product. This list starts life as the epics discussed earlier, but between the assigned project team, project manager and customer, we now break these down into more meaningful items. Each of the items represents a portion of business value to the customer. We don’t go into more detail at this stage, we don’t need to know the acceptance criteria, we don’t need to know if a button is blue or green, we just need to know there’s a button that allows some task to be performed.

b. Estimation Now that we have our list of features described as user stories, the team estimate these discrete items of features using a technique called “Planning Poker.” This is a useful technique that ensures quick, reliable results based on expert opinion and analogous sizing. Planning Poker assigns an agreed number to each item representing its size and complexity. This is called a story point. Other Agile estimationtechniques and sizes, such as ‘ideal days’, are available.

The end of this process will determine the size of the project and dependencies between features. The size is determined by adding up all the story points from the items in the product backlog. If that number equals 120, then the size of our project is 120 story points.

c. Prioritisation Now that we have a backlog and a size for the project, we’re in a position to prioritise it with the customer. This is really about identifying what is most valuable to the customer in order to achieve the desired results. The item at the top of the list is considered the most important, the second item is less important than the first, and so on through the list. No two items can be as important as another, each item’s priority is of relative importance or value to each of the other items.

This approach to prioritisation is an important milestone in planning a software project. We now know what is important to the customer and in which order to complete work, taking care of dependencies, to deliver a product that meets expectations.

d. Release Planning To date, we’ve determined what we believe the product to be and how big it is.

Now, we determine how long it will take to deliver a releasable product. The customer and team, including the designers, engineers, testers, scrum master and project manager, work together to identify what can be achieved and how quickly work can be done to create a release plan.

The release plan also gives insight into how the project will align with a customer’s strategic plans.

And finally, this plan ensures the project team has a guiding light that leads the way and defines a logical endpoint to development.

Before we start, we ensure we understand the agreed definition of “done.” This is a given set of criteria that a customer will accept as complete and also meets all of the engineering requirements to be considered releasable.

To take a basic scenario, we take the total number of story points we got from sizing our backlog and divide that by our teams anticipated velocity. (NB velocity is normally expressed as a range, but for simplicity we’ll use a single number here.) We work in two week iterations so our velocity will be reflected by how much we can complete in a two week cycle with the available capacity of the team. If our story points totalled 120 and we anticipate completing 20 points per iteration, the total development duration would be 12 weeks or 6 iterations. We add to that a sprint 0 of 2 weeks and a release preparation sprint of two weeks. In total, our project length is 16 weeks. There are techniques we can use that would help build an appropriate risk buffer into our planning, which we’ll discuss later. But in short, we use the buffer to manage the risk of uncertainty and to come to a minimum agreement of expected story points to be delivered. The outcome might be a range of 90 to 150 story points delivered, 90 being the minimum that would be acceptable to create a viable product.

Agile Planning

Alternatively, if the project must be complete by a given date, in say 10 weeks, the team would determine how much of the backlog can be completed in that time. If we anticipate 20 story points per sprint, plus Sprint 0 and a release sprint, we would be targeting 60 points completed by the end of the project. Again, we would look to manage risk by adding an appropriate buffer, which might result in a target of 45 to 75 story points completed and ready to release. The 45 story points would align with the minimum acceptable to deliver a viable and valuable product. This is one scenario where you might expect to add a team member to increase velocity, if appropriate.

Of course, all of the above is supported by good quality communication and collaboration between all parties to derive a release plan that is achievable, realistic and acceptable to the customer.

4. Fixed Price Contract

Once a release plan is agreed upon, we’re able to create a quote for a fixed price project contract. As mentioned previously, it’s advisable to keep the project duration and team fixed and the scope variable.

The quote for a fixed price contract is delivered along with a statement of work and agreed payment schedule.

As long as there is trust, communication, collaboration and a readiness to enter into the spirit of an Agile software project, all of the steps above allow us to deliver a quote with a realistic degree of confidence that a project will be delivered on time and on budget. Of course, there will be occasions where a project is delivered early or late and we deal with these variations with the utmost transparency.

Estimation Techniques

Agile planning and estimation is supported by a number of techniques that a development team can use to gain confidence in their size, effort, duration and cost. Here are some of the ones our teams use to estimate the size and cost of a software project.

Estimating Size

The size of the project is really an appreciation of its scope, complexity, dimensions, risk and magnitude. To use an analogy, it’s about understanding if we’re building the Eiffel tower or the Great Wall of China. The Eiffel tower is a tall, heavy, complex structure built in a tight urban environment. The Great Wall of China is a relatively simple, but long and sturdy structure spanning many miles of undulating terrain.

Whilst they would both be big projects to deliver, their scope, complexity, dimensions, magnitude and therefore size are different.

It’s important to manage expectations with estimates. They are never predictions, commitments or guarantees. When discussing total size, total duration and total cost, we always work within ranges, so as to mitigate risk, uncertainty and unknowns.

Stories that represent features of your product are individually sized and estimated using story points or ideal days. The total number of these units defines the total size of the project.

Story Points

Story points are a unit of measure that expresses the overall size of a user story. The size of a story, when estimated, includes all aspects of design, engineering, testing, code review, integration, etc.

Each size of a story is relative to another story. So for example, Story A may be sized as one point, Story B as two points and Story C as three points. Here, Story C is at least three times the size of Story A and at least half as big again as story B.

If the following stories in our product backlog have the associated sizes:

Story Size
A 1
B 5
C 3
D 1
E 2

The total size of the project is 12 story points.

Ideal Days

This is a measure of size expressed in days. It removes the concept of overheads such as interruptions, agile planning activities, reading emails and other non-project activities. It only concentrates on how long it would take if you were to work on something continuously without interruption, rather than the elapsed time from start to finish.

Typically, when estimating at a high level when we know least about a project, we would estimate in ideal days as this is an easier concept to correlate with past history and experience than an abstract number such as a story point. Especially when stories at a high level are more epics in nature with little detail and possibly containing additional elements when broken down at a later date.

When estimating at a more granular level, say a story in an established product backlog, either approach may be used and would be decided upon by the engineering team. There are benefits to both approaches and each team will have it’s preference.

Techniques for Estimating

Shared Estimates Estimates are not carried out in isolation. They are performed collaboratively by the whole engineering team together and include design, database, server, front end UI, QA and other cross functional experts. This avoids problems of not considering all aspects of the work involved to complete a feature, and ensures that no one person has the burden or misfortune of over or underestimating the size of a feature. The combined team will all have a view that can be discussed and agreed upon.

Analogous Estimates This is where we consider two discrete features and decide that one is relatively smaller or bigger than the other. We can look at a given story and agree that it is small in size, and if using story points we might give it a size of two. The next story might be considered as large compared to the first, and we would give it a size of five. This suggests that a large is at least twice the size of a small feature.

We would continue this exercise with all the stories. Once complete, we can then lay all the small, medium, large and extra large stories side by side and cross check our sizing to ensure there is a level of uniformity in our estimation.

Planning Poker Much has been written about Planning Poker; I also mentioned it in my previous blog. One of the best resources to understanding it is here.

In essence it combines expert opinion, analogy and team collaboration into one easy, fast and reliable process.

It brings together multiple experts who are best suited to build an estimate based on technical and domain experience, a lively dialogue and sound justification.



Velocity is a measure of a team’s capacity to get work done in a given iteration (or sprint).

It is expressed as a range, for example 23 to 32 story points per sprint, especially early on in a project’s life. Generally, this is because unless the same team has worked before on the same problem, it is hard to depict exactly what the team’s velocity will be. Notice, we refer to a team’s velocity and not an individual’s!

We use velocity to plan our releases and adapt our plans and work packages as we progress through a project, thus enabling us to adjust our forecast for completion regularly and accurately through execution.

When we start out, we are forced to define a range of velocity with very little data. We can use historical values, if the team and problem space are the same, which is often least likely. We can run an iteration to get an idea of velocity from a team actually working on the project, but this is costly and doesn’t work if decisions are still to be made on agreeing to start a project. Or, we can make a forecast.

Forecasting a velocity involves taking a sprints worth of stories and splitting them into tasks that are performed to complete the story. We would estimate the number of hours each task will take, which includes design, development, testing, and so on, and assess how much capacity the team would have in a given sprint. A capacity of 70 percent for an unencumbered team is a good baseline. So, in a simple situation, if the total hours available to the team is:

  • 4 team members * two weeks * 40hrs per week = 320 hours
  • Multiplied by our 70 percent capacity = 224 hours
  • Add up all the feature tasks and stop counting at 224
  • Take all the completed features, add up their story points and you get your velocity, say 36
  • Apply 20 percent either side to get a range of the lowest and highest, to arrive at an estimated velocity of 29 to 43 story points.

Velocity usually varies in the first two to four iterations and then stabilises within a small range of points. So, where our initial range before sprint one was 29 to 43, by sprint four, it may plateau to 34 to 38. This then gives us greater confidence in forecasting our final completion date.

Buffering Plans for Risk & Uncertainty

All software projects come laced with a level of uncertainty. That uncertainty becomes less as we progress through the project and more is known about our technology, environment, performance and the needs of the customer and users.

We mitigate this uncertainty or risk with a buffer in the schedule, which accounts for a margin of error in our estimation and the unknowns we cannot determine before development starts.

Typically, there are two buffer types: Feature and Schedule. As we’re often defining a fixed price for a fixed delivery date, it’s preferable to use the Feature buffer.

This approach gives us a credible risk mitigation strategy and gives a customer confidence in what they should expect to see as an outcome when the project is complete.

Feature Buffers

With a feature buffer, we are forecasting that we will deliver a given set of features but will ideally complete a further set of features. This should reflect at least the minimum feature set that the customer considers necessary to launch a viable product, but more may be delivered within the time frame if all the various internal and external influences allow it.

So, a customer may decide that the highest priority features from the product backlog, adding up to 100 story points, are most important. They then may consider additional features that add up to a further 30 story points. The team therefore will plan based on delivering 130 story points, with the minimum of a 100 being completed by the end of the scheduled completion date for the given fixed price contract.

Some closing thoughts

Agile can be a very difficult concept to fully grasp and adopt. This is no less true when managing sensitive topics such as price, scope and duration. Unfortunately, I know first hand that demanding clients want all things fixed up front and are eager to blame the supplier when it all starts to unravel. Equally, I’m aware of vendors that dig their heels in, become unresponsive and fail to respond to customer needs. Taking an Agile path is fundamentally built on trust, good relationships and stellar communication. These must be values held by both parties in order to maintain a healthy project for the equal benefit, satisfaction and success for all involved. Keeping an open mind and constructive attitude to collaboration and negotiation is the best way to avoid relationships going sour.

I’ve worked with clients that have found it hard to embrace the adaptive nature of Agile and to relinquish a command-and-control attitude. It’s hard to let go and put all your faith and trust in a team you don’t know. Often, clients may wish to create all the requirements up front as a specification of what will be delivered. This gives them a feeling of confidence that the scope of a project is well-defined. But ultimately, this fails to materialise as a successful approach. If we’re locked down to scope and unrealistic demands in a contract, problems arise very quickly.

We know, when taking this approach in traditional methods, that scope changes, unknowns are uncovered or what we thought the customer wanted is no longer true or way off the mark. Taking an adaptive approach to pricing, planning and scope allows customers to truly identify their product to be exactly what their market needs. It enables a vendor to be responsive, imaginative and efficient too. Harnessing collaboration between customer and vendor over contract negotiation is key.

Vendors need to be honest and customers need to be realistic about what can be achieved from the outset. A vendor that promises unrealistic targets and then increases costs may win the initial contract, but will soon lose favour from a disgruntled customer. Too often, relationships break down due to a lack of trust or confidence between parties. Trust must be built from the outset and maintained throughout the course of a project. A vendor must be flexible and cooperate with changing needs. Customers always want more; it’s a natural consequence of doing business. There must be a an equal and beneficial value exchange between both sides. For customers, they’re looking to create value for their business. For vendors, they should be looking to create value by forming long-lasting relationships with customers. Observing the Agile Manifesto’s values and guiding principles is a sound basis for forming strong, balanced and long relationships.


I hope this has given you some insight into planning, estimating and defining a price for an Agile software project. All of the approaches and techniques above are designed to build trust in a team and to build confidence in customers’ minds on how long and how much it will take to build a software product. And ultimately, to build confidence in making a decision to proceed.

Follow these guidelines and you’ll be sure to find a satisfactory route to bring your software product to life.

More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.

Agile, Scrum, and Kanban: What the Heck Do These Words Really Mean?


If you want to be the smartass of the crowd, you should use the word “agile” in every other sentence when you are talking about the work process. It has a pretty wide range, does not obligate you to know much about the subject you are talking about, and it is a really nice adjective or adverb: “thinking agile,” “agile approach,” “according to agile principles.” But what does “agile” really mean?

“Agile” refers to “agile software development,” the approach to development that follows agile principles. But what the heck are “agile principles?” Take a look at the Agile Manifesto and at the 12 principles of agile, which lay the foundations of agile development. From the Manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
Agile principles encourage continuous delivery of functioning software, close communication among teams, and high adaptability to changing needs. If you follow these values and principles in your work, you can say that you are working in an agile environment. So, agile software development is not a methodology, it is just a set of different methodologies, frameworks, and techniques that follow the same principles. It can be said that “agile” is a framework for thinking and making decisions.

Agile is a framework for thinking and making decisions.

But why is it so important to follow these principles in our work?

The Manifesto and principles are the result of searching for the best solutions that have evolved over the decades in response to the challenges of software development. Throughout the 70s, 80s, and 90s, different developers and teams all over the world had been experimenting with methods of working and approaches to problem solving, inventing different frameworks and techniques (such as scrum and Extreme Programming), and even coming to the same ideas in parallel. Finally, in February 2001, seventeen developers got together and found the common denominators for all these diverse ideas and experiences. That is how the manifesto was created.

The Agile Manifesto is the result of different experiences and practical solutions that emerged over the decades.


If you talk about “agile” methods without knowing what they mean, you may slip up and say things that will uncover you in front of the interlocutor who knows the subject: “Scrum and other agile methodologies.”

Scrum is not a methodology, though we’ve all heard it called such more often than the number of killings inGame of Thrones. Scrum won’t give an answer to every question, and it won’t provide you with the precise procedure for responding to every situation you face. And probably as a result of this incorrect interpretation, most scrum implementations are also wrong: Teams don’t get value. This results in probably the most foolish statement about scrum: “Scrum doesn’t work.”

What is scrum? The Scrum Guide defines scrum as:

“A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”
So it’s a framework, and like any other framework it can be, and regularly is, used the wrong way. Using scrum effectively requires not merely adopting the structure set out by scrum, but having a deep understanding and appreciation for agile principles across the entire team.

Scrum consists of three roles: Product Owner, Scrum Master, and Development Team; four ceremonies:Planning Meeting, Daily Scrum, Sprint Review, and Sprint Retrospective; and three artifacts: Product Backlog, Sprint Backlog, and Product Increment. It is organized into regular time frames, which we callsprints. Sprints should last between one and four weeks.

The Product Owner, or PO, is responsible for guiding the project’s direction. As new tasks and features are determined, the PO adds them to the Product Backlog. A sprint starts with a Planning Meeting where theDevelopment Team selects the tasks from the Product Backlog to work on and plans how they will be implemented. That is followed by development, during which the Dev Team uses the Sprint Backlog to track progress and meets for the Daily Scrum in order to synchronize activities and adjust the plan, if needed. The result of development should be a Product Increment, something that can be applied to the product and released immediately. At the end of the sprint, the Product Increment is presented to the Product Owner at the Sprint Review, where the product backlog is augmented if further changes are needed. Afterwards, the whole team attends the Sprint Retrospective (also known as the Pub Meeting) where they talk about the work process and how it can be improved.

The basic Scrum framework.

That’s it in a few sentences, but if you need a detailed explanation of how scrum works, check out this article written by yours truly.

It is easy to learn and understand scrum, but it’s hard to adopt. There are many reasons this framework may or may not be a good fit for a project. It often requires a lot of changes, not only in everyday development, but also culturally. Scrum fits best with development of complex products, ones that last a long time and that include different kinds of specialists.

Why is scrum so popular, and why does it have an advantage over the traditional waterfall model? Simply put, because it delivers more value to a product and customers. With “heavyweight” methods such as waterfall, horror stories abound in which nobody sees anything of the project for months. With scrum, that is not possible.

Scrum is all about the value that is delivered to end users. If you really utilize scrum, you need to deliver something of value every sprint. The value can be measured, and the team is also forced to inspect impediments and adapt, with the goal of delivering more value in the next iteration.

In most software development we are not building a skyscraper; we don’t need to have the whole plan ready before we start, and stick to that plan until the end. We are developing software, and we have the ability to adapt to different situations and to change the product requirements during development. For a long time, many developers saw this as the eighth deadly sin, but from the product perspective it is a huge benefit for optimizing predictability and controlling risk. Scrum is developed around this ability, and its implementation gives a reliable and efficient way of dealing with necessary changes.

Many techniques are used in conjunction with scrum: planning poker, pair programming, test-driven development (TDD), behavior-driven development (BDD), and others. They are not really a part of scrum, but rather compatible techniques. One method often mentioned at the same time as scrum is kanban, and there is a lot of confusion about what these two things mean in relationship to each other.


When you talk about scrum and kanban, one frequently asked question from the crowd will be, “Which is better, scrum or kanban?” And you won’t know what to answer because it’s like comparing apples and oranges, or asking, “Which is better, pancakes or beer?” Both are better.

Kanban is a simple method that aims for just-in-time delivery while not overloading the team members. It is similar to scrum in that the goal is to deliver maximum value at the end, but it is much more flexible than scrum.

Kanban was not invented by the software development community. In fact, it has its origins in manufacturing processes at Toyota, and it has wide usage in other spheres. There are no strict procedures that you should follow, and no strict way you should implement and use kanban; it is, rather, a set of principles and practices, and you can choose from these practices to suit your needs. But there is one most-often used implementation of kanban in software development that includes the usage of a kanban board, consisting of columns representing stages of work, and tasks.

Columns represent the state of a task in the development process. The simplest example consists of three columns: “To Do,” “In Progress,” and “Done.” So, tasks are added to “To Do,” moved to “In Progress” when development starts, and considered “Done” when moved to the last column. But of course, it could be more complex:

“Backlog” → “Defining Specification” → “Ready for Development” → “Development” → “Code Review” → “Testing” → “Deployed” (→ “No one really uses it” → “Completely Removed”).

Every column can have subcolumns; for example, “Development” can be divided into “Planning” and “Coding”; “Testing” can be divided into “Unit Testing” and “Integration Testing,” and so on. Columns might be dedicated to specialists, if appropriate. The team defines the columns and stages according to its needs. Per the “pull” philosophy, tasks should only enter the workflow when the demand for them is immediate.

Kanban boards help visualize the workflow.

The purpose of this board is to visualize the workflow, which is the first key practice in kanban. In fact, kanban can be done without a board at all! It could be a simple list of tasks in a Google sheet with different background colors indicating the state of the task, or it can be Gantt charts, diagrams, tables… It could even be a set of buckets in your office, where each one represents the state of the task, and where balls are used as tasks. Just visualise the workflow and provide transparency to the whole process.

Another important principle is to reduce the batch size of your efforts. Simplified, this means avoid multitasking. That can mean reducing the volume of tasks you work on at the same time. If you have three designers in a team, the team might set the maximum number of tasks in the “Designing” column to three.

Like scrum, kanban also sees the team as the most important figure in the process. But it doesn’t suggest roles as scrum does, and you may keep the existing roles to avoid making changes to your existing process. The same stands for continuous improvement: Kanban generally encourages you to learn and improve continuously, but does not prescribe a specific event just for that process, as does scrum’s Sprint Retrospective.

Which Should I Use?

Scrum and kanban are not mutually exclusive and not really comparable. In scrum, there are defined roles, while kanban says, “What the hell, keep your current roles and responsibilities.” Scrum will force you to change your way of working; kanban lets you start with your existing process. In scrum, a clear schedule for events is prescribed by the framework; in kanban you don’t have events. Yet, they have a lot of similarities: Both are value-centric, team members are respected as “bosses” of the system, and essentially, they have the same mission: To continuously eliminate waste and remove obstacles.

But the question, “What should I use in my particular project and with my particular team?” makes much more sense. Kanban doesn’t require so much of the process and cultural changes, and, in most cases, it will be easier to adopt than scrum. Scrum, on the other hand, offers significantly more structure to guide the process, which can eliminate a great deal of overhead as long as everyone is on the same page.

But the beauty of both is that neither is a strict set of rules. There is nothing stopping you from picking and choosing the best scrum elements for you, such as a daily meeting or review. And there is no reason you cannot incorporate a kanban board into scrum.

Scrum has proven to be a highly effective framework when the whole team understands it well. However, in my experience, I find it hard to work in scrum with some clients. The process and cultural changes required for proper scrum implementation can be too much (especially when dealing with someone who believes that he is making a new Google!). On the other hand, kanban is more flexible and doesn’t force people to change. Some authors also say that kanban is a good path to agility, and offers easier implementation of scrum. Others say that using scrum should lead to kanban at the end.

The truth is that every project is different, and there is no one-size-fits-all solution. As a project manager, it is up to you to determine what works best for your team.

More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.