Category: Scrum

Definition of done, what it means and why it’s important

Understanding the definition of done.

definition of done

What is your definition of done? This is a question you often here in Agile software development. In this post I’ll take a closer look at what the question means, and why it’s so important.

Let’s backup, in Scrum the goal is to have potentially shippable product increments at the end of each sprint. “Potentially shippable” means the code is ready to deploy to production if needed. The code should provide some value to the customer or end-user.

The work within the sprint is broken down into user stories. Each story represents a feature or piece of functionality that provides value to the customer.  In order for user stories to be “done”, the following acceptance criteria should be met:

  • Code designed, built and unit tested
  • Code passed some forms of functional, integration, regression and acceptance testing

To speed up the process of “getting to done”, most software groups invest (or should) in automated deployments and automated testing.

But what if we have non development stories, how do we create a definition of done for those?

Some Scrum teams aren’t only delivering software. Here’s my take on defining done/acceptance criteria for non development user stories:

Always aim to have something tangible to show by the end of the sprint. Each story you work on should produce, or contribute to producing, a valuable output. It could be a document, spreadsheet or some other else. Whatever it is, it should be a tangible/completed item that item that provides value.

Remember, much of Agile is based on lean principles. In lean, anything you are working on that does not provide value to the customer is considered waste. The goal in lean systems is to cut waste, reduce constraints, and increase valuable throughput.

So when you are creating your definition of done, ask yourself these questions:

  • If it’s code related, what will it take to be production ready?
  • Whether its code related or not, what will it take to get it demo-ready? Is it tangible and will it provide value?
  • Does the team agree upon what it takes to be done?

What will happen if we don’t create a definition of done for our user stories?

Not having a definition of done for your user stories is a common problem. When this happens, teams usually pull more stories into the sprint than they can handle. They do this because they don’t realize what it takes to actually complete stories. The result is tons of work in progress with nothing getting completed. The more WIP you have, the less valuable output produced.

The increase of WIP is the most devastating effect of not creating a definition of done for your user stories. Nothing will slow down flow more than jamming the pipeline with user stories that don’t have clear acceptance criteria.

Next time you have a Sprint Planning meeting, review your stories to ensure the team knows the definition of done. Even if the team realizes they can only work on 1 story, if at the end of the sprint they have something completed that provides value to the customer, you’re on the right track!

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. Follow Mike on Twitter @MikeMacIsaac or subscribe to Mike’s blog.



A good Scrum Master is like high performance motor oil

Scrum master

A Scrum Masters role in a scrum team is like that of motor oil to an engine. Cross functional scrum teams consist of lots of complicated moving parts. Software development, testing, infrastructure and release management, are just a few. They all have to work together and if one of these moving parts hits a snag, the whole team can grind to a halt.

This is where the Scrum Master comes in. It’s the Scrum Masters job to remove impediments for the team. Scrum Masters should always be on the lookout for any issues that could affect the performance of the team. It’s their job to clear the way so the team can operate like a high performance engine. This lets team members focus on what they do best and not deal with road blocks outside their control.

Scrum Masters also need to ensure their team’s social and human elements run smooth. This is why you’ll see good Scrum Masters bringing in food, injecting humor, and making the team environment enjoyable. Scrum Masters like to have fun! If you’re not someone who likes to have fun, the Scrum Master role wouldn’t be a good fit. This is part of the reason some traditional command and control style project managers struggle in the Scrum Master role.

Aside from removing impediments and enjoying some fun, Scrum Masters need to be positive. If the Scrum master is positive and optimistic about what they team can deliver, the team will feel the same. The good thing about Scrum is that team members shouldn’t have to worry about long term goals. Instead, they should focus on their current tasks at hand. These are usually tackled in two week sprints. By focusing on the short term assignments, this enables the team to stay positive and feel good about what they can deliver.

The actions I mentioned are a few ways the Scrum Master can act like high performance oil for the Scrum Team. What are some ways you think the Scrum Masters can improve team performance?

For more content like this, subscribe to the MacIsaac Consulting Blog.

Mike’s Twitter @MikeMacIsaac

To contact Mike, click here.


2 huge reasons your Agile team struggles to be Agile

agile teams

In my recent post, problems with Scaled Agile, I discussed SAFe and the Agile mindset.

Aside from debating the value in SAFe, the post created good dialogue about how to foster an Agile mindset within teams. That is, how to help teams become more collaborative, open and trusting.

In my experience, teams often struggle adopting an Agile mindset for two obvious, yet overlooked reasons.

Reason 1 – The team consists of people who don’t like Agile

Think this sounds silly? I can’t tell you how many “Agile” teams I have worked with that had team members who wanted nothing to do with Agile. Not only were they not drinking the Agile Kool-Aid, they were down right opposed to it.

Management makes a big mistake when the put people who aren’t on board with Agile on Agile teams. The thinking is that team members will come around and learn to embrace Agile values. Of course, this doesn’t happen.

John Kotter, Harvard leadership professor, gives great advice on dealing with change resistors. His message is to not try to include them in the change effort. This means, go around them or get rid of them. This may sound harsh, but trying to include anti Agile people in Agile teams causes too much damage.

Managers – When you are forming Agile teams, make sure you bring on people who want to be on an Agile team. The challenge though, is vetting out the Agile imposters.

Reason 2 – People assume roles that do not align with their personality.

The classic example of this is when a traditional project manager takes on the Scrum Master role. A big misconception is that the Scrum Master and Project Manager roles are interchangeable. The truth is the two roles are different. The Scrum master role is about servant leadership. This is different from project management which is more about command and control.

Want to know if a Scrum Master is behaving more like a Project Manager? Attend the team daily scrum and you will find out. If the Scrum Master controls the meeting, they are in project management mode. The daily Scrum is a team meeting, it is not meant for each team member to provide status to the Scrum Master.

Some people who are great Project Managers make lousy Scrum Masters, and vice versa. Make sure you put people into a role that best aligns with their personality and strengths. If you don’t, good luck trying to change someones personality to fit a role.

To recap, if you want an Agile team that embraces Agile values, start by getting the right people on the team. Do not form a team with people who oppose Agile. Next, put people in roles that fit their personality. Do not expect people to change their personality to fit a role.

Like Collins says, get the right people on the bus, and in the right seats!

For more content like this, subscribe to the MacIsaac Consulting Blog.

Mike’s Twitter @MikeMacIsaac

To contact Mike, click here.





5 Reasons Why Teams Should be 100% Dedicated and Stable

Stable Product Team

If your organization is not using stable product teams, they should be. A lot of organizations are still using an outdated balanced matrix structure. As an example, a company may have different departments or groups for each area of expertise. The project managers belong to one group, the developers belong to another, QA to another, and so on.

Before the fiscal year begins, the balanced matrix business conducts a prioritization process. They define what projects will take place for the year. Once projects are determined, a scramble takes place to form teams around projects. A battle will then ensue between management to staff the best people per project.

This model results in chaos and disorganization. It also results in creating teams that have little chemistry. Even worse, you end up with people assigned to many projects, resulting in switching costs. Some studies suggest that people can lose up to 40% of their productive time by shifting between tasks.

This must stop. Management shouldn’t move people around to different projects because a spreadsheet shows the people have ‘capacity’. It’s 2018, we now know that the highest performing teams are stable teams. The people on the stable teams should be 100% dedicated. What management should be concerned with is the throughput of the team, not resource usage. Efficiency does not always improve by increasing resource utilization. In fact, the opposite will happen if resources are over used.

The biggest reason for stable teams is related to team development. In 1965 Bruce Tuckman outlined four stages of group development, the ‘forming-storming-norming-performing’ model. Aside from having a catchy name, the model still holds true. It means that it takes time for teams to start performing well. This is a big part of the reason why it’s so valuable to have cross functional stable product teams.

Below are 5 huge reasons why your company should have cross functional stable product teams:

  1. With stable product teams, you no longer need to scramble to build teams around projects. All the chaos and competition around forming teams around projects goes away. No need to assign people to projects, instead, let product backlog items flow through stable teams.
  2. With stable product teams, work gets fed right into an already high performing team. This means you don’t have to deal with the forming-storming-norming phases of Tuckman’s model.
  3. Stable product teams improve quality. Quality improves because of the focus and attention the product receives. Team members also grow their domain knowledge and expertise. When team members are 100% dedicated, they won’t have to deal with switching costs.
  4. Work gets done faster and teams get better at predicting velocity. This reduces risk to the release schedules.
  5. Finally, stable product team members tend to enjoy their work. When team members sit together for a while, they get to know each other and they have fun. All the stable teams I’ve been a part of loved to joke around, bring in food, and come up with creative ways to have fun.

The stable product team model works well, perhaps best, using Agile Scrum. If your organization is not using Agile, stable product teams can still work well.

Whatever delivery process you use, let work flow through stable teams. Take advantage of teams that already have momentum, expertise and chemistry. Companies like Best Buy, Target and Pearson have long realized the benefits that stable teams have to offer.

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an Agile Delivery Consultant and IT Project/Program Manager. Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.







Leading cause of failed Agile projects? Company culture not aligned with core Agile values

In the 2015 VersionOne state of Agile survey, the top reason for failed Agile projects (46% of respondents) was company culture being at odds with core Agile values.


I’ve experienced this myself. Companies understand they need to get better at delivering software, so they decide to assemble Agile teams and bring in training.

The Agile teams use all the Agile practices, yet leadership sees little improvement. Why is there little improvement? Usually it’s because the company has a philosophy and culture that are at odds with core Agile values.

Below are the core values outlined in the Agile 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

Organizations have to have the ability to adapt to change. The advance of technology and globalization have made this an absolute need to stay competitive.

Adopting Agile is not just about improving how a small project team delivers software. It’s bigger than that. Leadership has to get on board with Agile values and principles. Organizations of the future will be dynamic,  fluid, and need leadership at all levels. The days of a static hierarchy org structure will soon be long gone.

The question remains, what should leadership do to align the company culture with Agile core values? My advice is to not try and change the culture head on. Many have tried and failed. Instead, allow the Agile team(s) to adapt their own rules and culture. Think of them as an organization within an organization. Allow them exceptions to old buerecratic processes. Help them remove any impediments that’s slowing them down. Let them develop their own mini culture.

Once you do this and start seeing success, you can then begin to expand out the new culture. The idea is to start changing the company culture in small chunks, one area at a time.

For large organizations, changing company culture is a monumental challenge. You need leadership at the top to champion the change. You’ll need buy in and a sense of urgency.

Once Agile core values align with company culture, product delivery will go faster and changing priorities will be managed better.

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.





The powerful benefits of value stream mapping – improving your software development process


Value stream mapping is a powerful tool. It’s used to identify and remove bottlenecks in your organizations value stream.  Before going further about the mapping, let me first touch on what a value stream is. I’ll also describe the theory of constraints.

Your organizations value stream is the end to end process used to deliver a product to the customer. For example, it may begin as a request from a customer, and end once the customer has the finished product. The stream contains all the activities it takes to get the customer the finished product. Each activity contains a work time, and a wait time.

The theory of constraints says that the best way to optimize an organization is to focus on throughput. Throughput is the key to generating profitable revenue. The way to increase throughput is to look for the current bottleneck that is slowing things down and fix it. Once removed, find the next bottleneck and fix that. Keep this up and you will have a fast-moving value stream (Goldratt, E 1984).

Creating a value stream map – “Mapping your value stream is a good way to start discovering waste in your software development process. In industry after industry, the process of mapping the value stream has invariably led to deeper insights about how internal processes work or don’t work to meet customer needs” (Poppendieck, 2003).

An easy way to create a value stream map is to have a project team gather around the whiteboard. The process shouldn’t take long. You should be able to do this in an hour or less. Write out all key activities in your value stream. For each activity, write down how much work time it takes, and how much wait time there is.

For example, you may find it takes on average 2 weeks to code for a project, but it takes an extra 3 weeks to move the code to test. This extra 3 weeks is wait time that doesn’t provide any value to the customer. It is waste.

After creating the value stream, identify the biggest bottlenecks in your process. The goal is to increase flow and value added time in the system. Focus on the fixing the biggest bottleneck, then continue to fix the next bottleneck.

In software development, it is common to find that the biggest bottlenecks occur after development and testing are complete. This is why it’s so important for organizations to be moving towards a lean software development model.

Below is a picture of a value stream map from the book Lean Thinking, by James Womack and Daniel Jones.



For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.


Mary and Tom Poppendieck, Lean Software Devleopment

Eliyahu M. Goldratt, The Goal

Top 10 influencers of the Agile software development movement

As a practitioner and student of Agile software development, I am fascinated by those who have influenced the Agile movement.

For fun, I have decided to put together my personal top 10 list of those who I believe have influenced what we refer to as Agile software development. Not only have they influenced Agile, most of them have put out bodies of work that will continue to educate future generations.

For all you Agile gurus out there, don’t freak out about who’s not on my list. You may have your own list which looks completely different. I know every time the the NFL puts out a top ten players list,  I’m usually in disagreement 🙂

Here we go…

10 -Kent Beck

 Kent Beck

Currently working for Facebook, Beck is the creator of Extreme Programming. He was one of the original contributors to the Agile Manifesto in 2001. He is a leading advocate for test driven development (TDD). Beck has published over 8 books on software development.

9 – Mary and Tom Poppendieck

Mary and Tom P

Mary and Tom are a package deal. I was fortunate enough to attend one of their workshops several years ago. Minnesota locals, the two have written together several books on lean software delivery. They helped bring lean production techniques to software development. Together they have had a big influence on the Agile movement.

8 – Jeff Sutherland


One of my personal favorites, Sutherland is the co-creator of Scrum. A West Point graduate and pilot,  Jeff flew over a hundred missions in Vietnam. After his military carrer, Jeff got into software development. He was a doctor at the University of Colorodo school of medicine, and he helped write the Agile manifesto in 2001.

7 – Eliyahu Goldratt

Eliyahu Goldratt

Although his name may not be synonymous with software development, Goldratt has influenced the way we think about systems. Goldratt’s book “The Goal” is a required reading in almost every business school. He’s is known for his teachings on the theory of constraints (TOC) and the critical chain method.

6 – Ken Schwaber


The co-inventor of Scrum along with Sutherland, Schwaber is a prominent leader of the Agile movement. Ken has authored many books on Agile and Scrum. Ken founded Agile Alliance and Scrum Alliance, which created the Scrum master certification programs. Ken helped write the Agile manifesto in 2001.

5 – Jim Highsmith

Jim Highsmith

Jim has authored books on software development and Agile project management. He created the adaptive software development model. Jim is respected as a leader in the Agile software development movement. Jim won the Jolt award in 2000, and the Stevens award in 2005.

4 – Frederick Brooks

Frederick Brooks

Brooks is an American computer scientists widely known for his book “The Mythical Man-Month”. In his book he describes the lessons he learned while managing the development of IBMs System/360 family of computers. Brooks law states: “adding manpower to a late software project makes it later”.

3 – Taiichi Ohno


The father of the Toyota production system, Taiichi Ohno was the originator what we now refer to as lean. The processes and principles he put in place at Toyota had a huge influence on lean software development and Agile. Ohno claimed that he modeled the Toyota Production system after Ford, only he removed the waste.

2 – Henry Ford

Henry Ford

Ford is a fascinating American icon. He founded the ford motor company and helped create the assembly line production process. Not only did his assembly line process change the auto industry, it changed the world. Manufacturing would never be the same. What I admire the most about Ford was that he accomplished so much, and he did it all  through sheer determination.  Ford had little formal education, he didn’t graduate from High School.

1 – Edwards Deming


My favorite quality guru, W. Edwards Deming. What I like the most about Deming was that he cared for the line worker. He championed pride in workmanship. He put the responsiblity on management to focus on the system. Along with a 14 point process for quality improvement, he created the PDCA (Plan, Do, Check, Act) method. The PDCA method is exactly what takes place during Scrum sprints (iterations). His processes and statistical control methods also revolutionized the Japanese auto industry.

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

Quality and the consumer – The 3 corners of quality


Defining what quality means is difficult. On this subject, the great statistician Walter Stewart stated: “The difficulty in defining quality is to translate future needs of the user into measurable characteriscts, so that a product can be designed and turned out to give satisfaction at a price that the suer will pay” (Shewhart, 1931).

In software development, we tend to focus on a series of defined tests. If all our tests pass, we have developed a quality product ready to be shipped. If the product is shipped and the result is a high volume of production defects, the product was not of good quality.

The challenge with the old way of Waterfall software delivery, and only relying on our tests,  is that the consumer of the product is involved too late in the product development process. The consumer is perhaps the most important aspect of developing quality software.

For this reason, we need to involve the consumer all throughout the development process. This way, we build quality up front.

The below figure shows the three corners of quality model put forth by Edwards Deming.


What we have learned with the application of Agile, is the importance of learning from the customer. Deming talked about this back in the 1970s, but it wasn’t until the early 1990s that it was applied for software development.

On learning from the consumer, Deming writes: “The main use of consumer research should be to feed consumer reactions back into the design of the product, so that management can anticipate changing demands and requirements and set economical production levels. Consumer research takes the pulse of the consumer’s reactions and demands, and seeks explanations for the findings” (Deming, 1982).

What Deming describes is exactly what takes place during the Scrum sprint reviews. During the sprint review, we show production ready software to the consumer. The consumer can then give immediate feedback. This allows us to make changes to the design of the product.

The old way of delivering software looked like this:


The new way of delivering software using Agile ensures we build quality into the product up front. We build production ready software in short iterations, then review it with the customer. The new way of delivering software looks like this:


For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.






The Power of Scrum – Adapting to Change


“The Only Thing That Is Constant is Change” – Heraclitus

Unlike Scrum, in a traditional waterfall methodology all planning is done up front. For example, say the objective of your project is to get from Block A to Block B


In Waterfall, all steps will be planned out and base lined up front. Once planning is complete, the team will set off on their voyage to get from Block A to Block B.

Using Waterfall, your up front project plan might look something like this:


Here’s the problem, delivering complex software is a lot like finding your way through the dark. You have to take small steps and feel your way through. You have to adapt and make changes as you find your way.

This is why project teams run into trouble using a Waterfall methodology. They are not ready to adapt to changes when needed, and changes will be needed.

To make things more challenging, using Waterfall customers are only engaged during the start and end of the project. This means all throughout design, build and test the customer is in the dark. This leaves a risk of a system built that is completely different than what the customer actually wanted.

In Scrum, the software teams builds workable chunks of software in short iterations. The team is feeling their way through the dark and adapting to changes as needed. These iterations are called Sprints, and they usually last around 2 weeks. At the end of each sprint, the customer gets to see the built functionality. The below picture represents Scrum iterations:


By building software in short iterations and keeping the customer engaged, you can adapt to change. The final outcome of the project might look completely different than original expected.

The customer may have realized they actually need to get to Block D, not Block B. Maybe they realized Block D provides much more value than Block B.

See example below:

                                                       Original Plan



                                          Actual results using Scrum


For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.


Page 2 of 2

Powered by WordPress & Theme by Anders Norén