Are you implementing Scrum but realize you are better suited for Kanban?

Are you implementing Scrum but realize you are better suited for Kanban?

I have found that very few organizations are starting out with Kanban as their first choice for their Agile implementation. Almost every organization that I have been exposed to through training and coaching began their Agile implementation with Scrum. Unfortunately, many companies have significant organizational impediments to being a true Scrum shop.

Before I go any further, I want to say that I am a Scrum believer. If there is a way to implement “pure” Scrum, I believe you will have the most productive and happy development teams. That being said, I have found that many organizations trying to implement Scrum have significant "Scrum-buts"and their implementations would be better served by stepping back and considering a simple Kanban approach.

There are many different approaches to Kanban for software development, and some are even proprietary. Since everyone else is attempting to trademark their own Agile approach, from this day forward, I am trademarking, “Simple Kanban™.” Just kidding… Anyway, the benefit of Simple Kanban is that it assumes you already understand Scrum and User Stories and can apply what you have learned in Scrum to Kanban. When I train on Kanban, I train one day of Scrum and User Stories and one day of how to apply those practices to a Kanban approach.

I can’t say that I am an expert in Kanban for software development, but early in my career, I did have some great exposure to Kanban in manufacturing. In college, I majored in Industrial Engineering, and my first “real” job was working as a sales engineer for an environmental controls manufacturer. They used the Kanban pull system for inventory control and as part of my onboarding training  I spent three weeks on the shop floor. It was an experience that left a deep impression on me.

While I worked there, they won the Shingo Prize for world-class manufacturing and excellence in productivity and process improvement; quality enhancement; and customer satisfaction. This award is considered one of the “Triple Crown” industrial excellence awards, along with the Baldrige National Quality Award and the Deming Prize.

Kanban was originally a lean manufacturing approach, and it was developed in alignment with these 5 lean principles:
  • Specify what creates value from the customer's perspective
  • Identify all the steps along the process chain
  • Make those processes flow
  • Make only what is pulled by the customer
  • Strive for perfection by continually removing wastes
These lean principles which I saw applied to manufacturing always stayed with me as my career shifted to software development project management. I was never a thought-leader advancing my ideas beyond the needs of my immediate project, but I was able to be “agile” before I even heard the term. I was applying both lean principles and common sense to keep the development teams productive and my customers happy.
Now that I am an Agile Coach, I have formalized my common sense approach so the process is repeatable and so I can train Agile teams. Here is how I implement Simple Kanban:

Keep existing functional teams: Most organizations are struggling with eliminating roles, especially QA. One major reason that this won’t change is because separation of duties is required for many IT shops.

  • Business Analysts perform role of Product Owner and write User Stories. They prioritize these Stories in the Product Backlog for the development team which becomes the work queue for the team to pull from. Ultimately, given the lightweight nature of User Stories, there will be fewer Analysts needed.
  • Software engineers perform high-level design, and identify the development tasks. For complex systems, it may require that an architect or senior software engineer is on the team for this activity.
  • Software engineers continue to develop, write unit tests, and advance Agile engineering practices such as continuous integration. This is the same role they have been playing, but in a “pull” environment they will be much more empowered.
  • Lastly, retain quality assurance team members to perform functional testing. I still suggest that the Business Analyst and/or a true Product Owner role exist to perform ongoing acceptance testing.

Utilize User Stories: Kanban typically uses cycle time to size requirements. It may be heretical for me to propose this, but User Stories can accomplish the same thing, especially if the team members have already been trained on User Stories.

Manage WIP using functional velocity: Each functional team estimates the story points for their work on a story. As with Scrum, over time, each team will know their velocity and can commit to their work in progress (WIP) limits. They can then work towards a stable time-based velocity which can provide the same transparency as cycle time.

Team Size is managed by Story Points: The number of business analysts, software engineers and quality assurance team members is determined by the number of story points in the functional queue and ultimately the release schedule. As with Scrum, multiple small Kanban teams work better than one big one.

Self-Organizing is the same as a Kanban pull system: When a team member is done with a story, they go get more work from the queue.

Keep open spaces: This is just a good idea. Regardless of your Agile approach, one of the keys to success is having everyone in the same room.
It may sound complicated, but as with Scrum, after a few cycles the team begins to work out the kinks. I agree that over time, cycle time is a better approach for Kanban, but if you are moving from a Scrum model, it may be an easier transition to retain the use of Story Points, and I have seen teams be successful with this approach long-term.

Bottom line – keep it simple

Do you want to learn more about our approach to Kanban? We have 2 options:

About the author, Dan Tousignant, PMP, PMI-ACP, PSM I, CSP
Dan is a lifelong project manager and trainer with extensive experience in managing software development projects. Based upon his experience, he has adopted both Agile as the primary method for developing and implementing software. He is passionate about the leadership emerging from self-organizing teams.
Dan has over 20 years of experience providing world class project management for strategic projects, direct P& L experience managing up to 50 million dollar software development project budgets, experience managing multi-million dollar outsourced software development efforts and strong, demonstrated, results-driven leadership skills including ability to communicate a clear vision, build strong teams, and drive necessary change within organizations.
Dan holds a Bachelor of Science majoring in Industrial Engineering from the University of Massachusetts, Amherst and is a Certified Project Management Professional, Professional Scrum Master, PMI Agile Certified Practitioner and Certified Scrum Professional and is the owner of Cape Project Management, Inc.
Cape Project Management, Inc.

Does your organization need an Agile Coach?

Does your organization need an Agile Coach?

As we love to say when answering many questions pertaining to Agile, “It depends.” Not the answer you want to hear, but let me elaborate. Extreme Programming (XP) introduced the term coach into the Agile community. The role was intended to both be a mentor on XP practices and a hands-on developer when needed. Scrum created the role of the Scrum Master with similar expectations but without the emphasis of being a hands-on developer.
The term, Agile coach, has become ubiquitous; however, it hasn't been used as XP intended. Quite often, the term refers to an external consultant and very seldom will you see it applied to an internal position.
I have played the role of Agile coach on and off over the last decade, and I didn’t always use the term coach. I was a coach when I was a program manager of a large Agile initiative; I was a coach when I was a functional development manager; and I was an Agile coach consultant hired to serve multiple Scrum teams. What was common for each of those roles was that I was the most experienced person in the room on Agile practices and I had a passion for passing on that knowledge to the teams I was working with.
In the first two instances, though I wasn’t formally named a coach, it was clear based upon my experience and willingness to share, that people felt comfortable approaching me for advice and discussion. Recently as an Agile Coach consultant, the same dynamic was true, but my role was more formal.

Do I need to be called an Agile coach to be an Agile coach?

Anybody with a passion for learning and sharing Agile best practices can be a coach. Becoming a coach is like becoming a leader. As with leaders, coaches can emerge from within a team.

What skills do I need to be an Agile coach?

  • Active listening
  • The ability to influence without authority
  • Experience – with both success and failure
  • Patience
  • The right attitude!

If they don’t work for me, how can I tell them what to do?

Here is a real situation I faced while coaching a Scrum Master. I had just sat through a very painful Sprint Retrospective:

Coach: “How did you feel that Retrospective went?”
Scrum Master: “It went fine, but the team is bored with them so I try to get them over with as quickly as possible.”
Coach: “Are you open to working with me to prepare something more fun and engaging for the next Sprint Retrospective?”
Scrum Master: “Definitely!”

In this situation, I didn't  immediately tell her what I would do differently, I gave her an opportunity to choose whether she wanted help or not.

How can I be an Agile coach for people that work for me?

I find this situation to be the easiest in many ways. My management style is very much in line with a typical coaching style. I work with the individual on their career goals and set a specific Agile maturity path based upon their experience and role. Some of these goals are around Agile best practices and engineering principles, and most often, it is about soft skills like listening, being self-organizing, and peer influencing.

So, back to the original question, does my organization need an Agile coach?

Every organization that is in the beginning or in the midst of implementing Agile needs someone who can be an Agile Coach. The question really should be, “Who should be playing the role of Agile Coach?”
If the Scrum Master is experienced and has the soft skills necessary, then the Scrum Master is often the coach. If there is a development manager or practice lead with the necessary background and desire, then they can be the coach. A team member can emerge as the coach if he or she has the passion and emerges from within the team.
If none of these internal candidates exist, you may need to look outside the organization—at least on a temporary basis—to fill this role. The ultimate goal is for everyone on the team to have a high level knowledge of Agile principles and practices, so that they can self-organize and continue to improve; resolve impediments; be productive; and truly enjoy their jobs. Then . . . there will no longer be the need for one individual to be a coach.

About the author, Dan Tousignant
Dan is a lifelong project manager and trainer with extensive experience in managing software development projects. Based upon this experience, he has adopted both Agile as the primary method for developing and implementing software. He is passionate about the leadership emerging from self-organizing teams.
Dan has over 20 years of experience providing world class project management for strategic projects, direct P&L experience managing up to 50 million dollar software development project budgets, experience managing multi-million dollar outsourced software development efforts and strong, demonstrated, results-driven leadership skills including ability to communicate a clear vision, build strong teams, and drive necessary change within organizations.
Dan holds a Bachelor of Science majoring in Industrial Engineering from the University of Massachusetts, Amherst and is a Certified Project Management Professional, Professional Scrum Master, PMI Agile Certified Practitioner and Certified Scrum Professional and is the president of Cape Project Management, Inc.


Who makes a better Scrum Master: a developer or a project manager?

Who makes a better Scrum Master: a developer or a project manager?

Who makes a better Scrum Master: a developer or a project manager?

I am guessing that this is a contentious topic, so it is that much more fun to talk about…

The Agile Manifesto was written by software developers. There weren't any “traditional” project managers in attendance, so, it is safe to assume that Scrum Masters were expected to come from the ranks of software engineers.

I attended Scrum Master training with Ken Schwaber in 2000 and again in 2011, and on both of those occasions, it was clear that the role of a project manager was not needed or wanted on Scrum projects. I agree with the sentiment about the role of project manager, but I still believe it is acceptable and even sometimes highly successful to have a former project manager become Scrum Master.

I am a project manager by education (Industrial Engineering), by training and by certification (PMP) and ultimately by birth. I have been managing primarily software development projects since 1996, even though the last time I coded was using Fortran in college, unless you count my ability to use <bold>html</bold> in my blog. Given my technical limitations, I still consider myself an above average project manager and an even better Scrum Master, not because of my background in either discipline, but because of my real life experience and exposure to incredible leaders and people managers throughout my career. Early on, about 20 years ago, I was told by my boss and mentor, "Just because you are right, that does not mean people will listen to you or even agree with you." I was a practical project manager surrounded by academics, artists and other creative minded people. In order to successfully lead them and organize them I had to develop skills in listening, persuasion and influencing without authority. This began my path to truly understanding servant leadership.

So, the reality is that the "average" project manager or developer makes a poor Scrum Master. The “best” Scrum Masters will be found by identifying individuals that are well-trained, educated and passionate about Agile and servant leadership, regardless of their background.

It is well known why some project managers make poor Scrum Masters. They use their “command and control” attitude on the Scrum Team. What most Agilists with software development backgrounds don’t understand is that many project managers who were trained as professional project managers were never intended to use a command and control style either. I was trained early on in my career as a project manager that we could be most effective if we could motivate and lead our teams without using a carrot or a stick, but by engaging them in the vision and ultimate success of the project. PMI actually promotes the concept of influencing without authority. Throughout my career as a project manager I never had any functional authority. The developers never reported to me. I wasn't the technical expert. So, how was I successful? By being a servant leader! We were trained to remove impediments, make sure there were minimal distractions for the team, and you know what? We were trained when projects were high-risk, we should meet every day with the team to remove impediments. Sound familiar? Granted, as with Scrum Masters today, most project managers were assigned from the ranks of functional managers who were familiar with a directive style of management, and many loved the “hero” status reserved for those overachievers, but that was never the intent. Those project managers that I worked with, who were trained as I was, and those that I trained later in my career would make excellent Scrum Masters today.

It is the same story with developers. There are many developers who see being a Scrum Master as a promotion. It gives them the opportunity to play the elusive “tech lead” role and drive the technology. How can a developer with a strong opinion on how something should be built sit back and let the team self-organize around a solution that they don’t technically agree with?

To be an effective Scrum Master, you have to embrace the core values of the Agile Manifesto. I believe there is an equal chance of both failure or success when selecting a Scrum Master from the ranks of developers or project managers. Regardless of where you find your Scrum Master, it is much more important that they have the requisite skills needs to be a servant leader; including trust, passion, and enthusiasm for both Agile and for helping their teams succeed.

Dan Tousignant, PMP, PSM I, CSPO, PMI-ACP, etc., etc., etc.
Cape Project Management, Inc.

Why Scrum “Master”? What about Scrum Apprentice? Maybe we need a Scrum Jedi?

Why Scrum “Master”? What about Scrum Apprentice? Maybe we need a Scrum Jedi?

I learned the term Scrum Master back at the turn of the century (I like how that sounds). I first heard it from Ken Schwaber himself. At that point in my career, I was a true and tried project manager that had recently earned his PMP. I was a self-taught project manager, and looking back, my instincts and style were better suited for Agile, but I happened to go down the formal PM path first. After 10 years of experience, I had come to the conclusion that project management was a “craft”.  I believed it then and I believe it even more now, which is why I struggle with the term “Master.”

What does it take to be a "Master" of Scrum?

I was a carpenter before I was a project manager. I was the only honors student taking wood-working classes in high school and I worked as a carpenter’s apprentice during the summer while I was in college. I had tremendous respect and even awe for the master craftsmen I worked with. In carpentry, the term Master is reserved for the likes of Norm Abram. Also, to be a union carpenter, you have to go through a rigorous apprentice and journeyman program before you can get paid as a true master carpenter.

In history, you had to earn the term “Master” to be seen as the top of your craft. Wikipedia has a good definition:

“An aspiring master would have to pass through the career chain from apprentice to journeyman before he could be elected to become a master craftsman. He would then have to produce a sum of money and a masterpiece before he could actually join the guild. If the masterpiece was not accepted by the masters, he was not allowed to join the guild, possibly remaining a journeyman for the rest of his life.”

I think the intent with the term Scrum Master is that the title should be reserved for those that have earned the title of Master, but that is obviously not the case. There is no job requirement or career path to become a Scrum Master.  Most of us have had some type of career path as we developed our skills; e.g. in software engineering, there is a typical path of analyst, developer, designer, architect or in project management: project coordinator, project manager, senior project manager, program manager.

So, how does someone earn the designation of Scrum Master? Until recently, it was just take a 2-day class. Now, at least there are exams to test your knowledge of Scrum. It is surprising how we have come to a place where the term Master can be designated without any true effort or experience. Most of us have had to show both experience and knowledge to get the certifications we have. PMI, for example, requires the PMP and the PMI-ACP designation be based both upon experience and knowledge.
I am not sure if there is a way to backpedal to introduce qualifications for Scrum Master, so maybe we need a new term that actually requires that someone has proven themselves. How about Scrum Jedi? Just a thought… All I ask is that I get credit for the term when it goes viral…

Dan Tousignant, (long list of acronyms usually goes here, some hard earned, others...)



The Agile Success Algorithm

The Agile Success Algorithm



1. a process or set of rules to be followed in calculations or other problem-solving operations
Those of you reading this are more than familiar that Agile is all the rage. Executives like to say that their organization is going "Agile". They throw out terms like Scrum and Kanban without truly understanding what they are getting involved in.
In order for Agile to be implemented successfully, I have created the following simple algorithm. Embrace Change + Learn from Mistakes = Agile Implementation Success.

Input 1 = Embrace Change

The primary risk with implementing Agile involves the ability your organization to embrace change. You need to answer the following questions about your organization's culture and your leadership team before you can successfully implement Agile:
How does your organization respond to change?

  • When was the last time your organization underwent any major changes?
  • Have they been through major layoffs? Have they introduced new leadership?
  • How long have they been in business? Have there been major new product introductions?
  • Have they been acquired or merged?

How did these changes go? In this case, past performance often dictates future performance. If your company struggles with change, then they will have trouble introducing Agile. Agile introduces change in so many ways:

  • Changes in roles, title and responsibilities. Just look at the roles in Scrum, since it is currently the most popular Agile method being implemented. How easy is it for your organization to adopt these roles?
    • A Scrum Master?   How many managers or project managers do you know who truly understand the concept of servant leadership? How many organizations allow for management positions that do not have direct reports? To truly be successful with Scrum, a Scrum Master role has to be created from scratch, not just assigned to an existing function.
    • A Product Owner??   Organizations that have a mature product manager function can transition easily to this, but many organizations manage product related decisions by committee with a team of business analysts. The role of a truly empowered Product Owner is difficult for many companies to swallow.
    • A Scrum Team??? A self-organizing team is the foundation of Scrum and of Agile in general. How many organizations actually foster this? How many middle manager's jobs would be eliminated if an organization becomes successful with this? How many under performers would be exposed in this model? This is the most difficult, yet most critical change required.
  • Changes to process.
    • No analysis or  business requirements phase? No Gantt charts? No 12 month project plan? Traditional project management was just formalized at many organization in the last decade. Formal PMOs have been rolled out, massive enterprise tracking tools implemented and teams of project managers hired to create and maintain documentation. Can your organization tolerate getting rid of all the processes you just implemented?

Input 2 = Learn from Mistakes

Only a company or leadership team that has experienced project failures can truly appreciate and support an Agile implementation. These failures may have come in many different ways:

  • The project came in too late to meet the market opportunity.
  • The budget changes were so excessive that the project was either terminated or deemed a total failure.
  • The customer rejected the product because it was "not what they were expecting."

The list goes on and on....The Agile Manifesto was not crafted by grad students developing a thesis. It was developed by people who were clear that the way we were working wasn't working. Many people, like myself, have become Agile evangelists only after suffering through one or more of the above project failures over which we had no control. One of the major downsides with introducing Agile to the "younger" workforce is that they don't truly appreciate how much more fun and enjoyable it is to work on an Agile project. Give them one month of using project time-sheets and hourly tracking in an ERP tool and they will start to see the light.

Output = Agile Implementation Success!

The benefits of Agile are self-evident for those who have lived through traditional project failures and are willing to change. There are hundreds of successful case studies and stories of successful Agile implementation, but implementation failures are becoming more and more common. Becoming "Agile" is not just using the term "Agile", it is a transformation that will effect your entire organization.

Dan Tousignant, PMI-ACP, PMP, PSM, CSPO, CSP

Running an Effective Sprint Planning Meeting

Running an Effective Sprint Planning Meeting

To start with, for a Sprint Planning meeting to be truly Scrum, it adheres to the following guidelines outlined in the Scrum Guide. In summary, for a one month Sprint it has a time-box of 8 hours. It is typically performed on the first day of the Sprint and is intended to answer the following topic questions each in a 4 hour session.

  • Topic 1: What can we as a Team accomplish?
  • Topic 2: How can we accomplish it?

Sprint Planning Topic 1:

An effective Sprint Planning meeting assumes that the Product Owner is prepared with an objective for the Sprint. They should not have a specific goal, since this will limit the creativity of the Team, but they should have a general expectation of what they would like to see accomplished. The Product Owner should have a high-level release plan based upon the product vision.


This release plan should contain what might be accomplished from the Product Backlog each Sprint. It is the Product Owner's responsibility to maintain and order the Backlog based upon this release plan.


During the first 4 hours, the Product Owner should discuss their objective and the Development team will select those items from the Product Backlog that they believe they can accomplish in the coming Sprint. This becomes the "Sprint Backlog".  Once that is accomplished, the Product Owner, Development Team and Scrum Master agree on the Sprint Goal. If you are using the user story approach, in this session you will select the user story, prioritize the user story and then estimate its size using story points. You would be completing the front side of the user story card.



Sprint Planning Topic 2:

In the second part of the Sprint Planning Meeting, the primary objective is determine how the Development Team will achieve "Done" with the Sprint Backlog. This session sometimes also called a Design Session. Often times technical experts and SMEs are invited to this session to determine how best to deliver a certain piece of functionality from the Sprint Backlog.  If a Backlog items becomes more complex than expected, the development team will work with the Product Owner to refine the Sprint Backlog.


Under the user story approach, this session is also used to document many of the tasks associated with the user story and update the story point estimate from the the first session.

Ultimately, the Development Team will make a commitment to the Product Owner that they will self-organize and accomplish the Sprint Goal based upon the selected Sprint Backlog.


Boston Agile Training provides in-depth training on Sprint Planning and Users Stories in their Scrum Master and Product Owner trainings.


If you have any questions, please contact me at or find me on Twitter  @scrumdan.

If you would like to order pre-printed user story cards, check them out on Amazon:


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


Enjoy this blog? Please spread the word :)