Blog

Happy Thanksgiving

By: Agile Velocity | Nov 24, 2015 |  Agile,  Article

Happy Thanksgiving

We live in a world where companies deliver cookies fresh out of the oven and stress-relieving puppies. On the other hand, we live in a world that sadly reminds us every day that we really do have a lot to be thankful for.

Here are just a few of our reasons why we give thanks:

I am thankful for the people in my life, including my co-workers and the people I get to meet through work. The world is full of lovely, fascinating people.” -Doc List, Senior Director of Coaching and Training

“I’m thankful for my job. Also, I’m thankful for my trainer for helping me work off the Thanksgiving turkey.” -Sara Abrams, Training Coordinator

“I’m thankful that I’m alive and also for cheese. I’m thankful for cheese.” -Brett Simon, Wisconsin native and Tech & Agile Recruiter

“I too am thankful to have happy and healthy family and friends. I am also thankful to live in a vibrant and active city with lots of opportunities, optimism, resources, and friendly people.”-David Croley, Senior Developer & Technical Player-Coach

“I am thankful for the health of my family and friends. I’m thankful for a bubbly, confident little girl who corrects my Spanish pronunciation. Also, I am thankful to live in a world that allows me to communicate my ideas with the push of a computer key.”

“I am thankful for a happy and healthy family.” – Jessica Bush, Business Operations Manager

I am thankful for miracles: father beating cancer, friend’s expected full recovery from a broken neck, and the love of my family (yes, that’s a miracle).” – Mike Lepine, Director of Operations

“I am thankful for a passionate team that makes building a company fun and for a family which is supportive in my entrepreneur pursuit.” – David Hawks, CEO 

From all of us at Agile Velocity, Happy Thanksgiving! 

Blog

Agile Velocity Registers 52% Growth in Coaching & Training Revenue in First Half of 2015

By: Agile Velocity | Aug 03, 2015 |  Agile,  Article

Escalating Demand Creates Need to Expand Workforce by Adding New Key Hire

Agile Velocity - Realizing Impressing GrowthAUSTIN, TEXAS – August 3, 2015  – Agile Velocity, a Texas-based provider of Agile services, including Agile transformations, assessments, training, coaching and recruiting, announced today that it has been experiencing ongoing company growth, evidenced by rising revenue. To support the increasing demand for services, Agile Velocity has added a new key hire to their expanding team.

Based out of Austin, Texas, and historically focused on the Texas market, Agile Velocity has continued to expand their reach to deliver enterprise-wide services to organizations in multiple states including Louisiana, Georgia, Virginia, Ohio, New Jersey, Florida, and Arkansas. This market expansion, combined with increasing local business, has contributed to the reported growth in revenue. Agile Velocity has also seen a 100% increase in training participants, training over 800 Agile professionals on a variety of Agile related topics in the first two quarters of 2015.

“We are happy to announce our ongoing growth and increasing market presence,” said David Hawks, CEO of Agile Velocity. “We attribute this growth to our diverse team of Agile experts, our focus on customer service and the support and loyalty we continue to receive from our valued clients. This, combined with our commitment to a client-centric approach on every engagement, continues to result in satisfied clients as evidenced by our high net promoter scores (NPS).”

To support the ongoing growth, Agile Velocity, who for the past two years has been ranked in the Top 10 of Austin Business Journal’s Best Places to Work, is expanding its team. Recently joining the Agile Velocity team is Doc List, as Senior Director of Coaching and Training. Doc will lead the delivery of Organizational Transformation, Coaching and Training services by building the team and ensuring quality delivery. With over three decades of experience spanning software development, IT, coaching and consulting, Doc will apply a variety of Agile principles to aid client organizations in becoming more effective and profitable. Most recently, Doc has been an independent consultant, focusing on transforming organizations world-wide through coaching, consulting and training.

“The high caliber experience and expertise that Doc brings to our team will give us an even stronger competitive edge. This is essential to growing our business and supporting our expanding needs” mentioned David Hawks, CEO of Agile Velocity. “We are excited to have him join our team in a strategic role and look forward to the ongoing value he will add to our organization.”

Blog

Austin Business Journal-Best Places to Work

By: Agile Velocity | Jul 02, 2014 |  Agile,  Article

Austin Business Journal - Best Places to Work - The Agile Velocity Team

2014 Best Places to Work

The Austin Business Journal named Agile Velocity in the top ten of the best places to work in Austin for the micro companies category.  Agile Velocity was named to the list for the first time, ranking #8 out of 20 micro companies.  This award was announced at a luncheon hosted by the Austin Business Journal in Austin on June 26.

This is the first year Agile Velocity has been eligible for the Austin Business Journal award. Since its inception in 2011, Agile Velocity has grown from a single employee to over eleven with revenues increasing steadily each year.  Agile Velocity began when founder, David Hawks noticed companies ineffectively building innovative software products with a lot of waste.  With a background of building highly productive teams, David used these principles when establishing Agile Velocity.  Austin Business Journal recognizes these elements as key to creating companies that are fun and desirable places to work.

Companies are evaluated on areas that include:  benefits, job satisfaction, trust in leadership, the effectiveness of management, goal alignment, retention, and teamwork.  Kevin Tougas, the Staffing Solutions Manager at Agile Velocity says, “Collaboration, innovation, and team empowerment are the foundations to what we teach and what we live by at Agile Velocity.” Kim Phipps, the Marketing Manager at the company, said, “It is great to see Agile Velocity recognized locally.  It is a company that truly practices what it teaches and is an amazingly fun place to work.”

Agile Velocity is proud to represent micro-companies as an inspiring place to work.  It looks forward to continued growth and sharing of these principles with customers and the Austin community.

Blog

Product Camp Austin 11

By: David Hawks | Aug 12, 2013 |  Agile,  Article

The Agile Velocity Team at Product CampThe Agile Velocity team recently attended and participated in Austin Product Camp 11 on July 20th at the AT&T Conference Center. They were happy to see familiar faces and meet new ones while being a part of this fun event.

David Hawks led two popular sessions, “Delivering Product in an Agile World” and “Requirements Process from Discovery to Delivery”. His story mapping session slides can be found here.

David Hawks presenting at Product Camp

Eric Stewart also delivered “How to Keep Your Development Teams Going Fast”.  His slides can be found here.

Product Camp Austin

ProductCamp Austin is the premiere event for Product Management, Product Marketing, and Marketing professionals to teach to, learn from, and network with each other.

 

Blog

Many Companies are Drowning in a Sea of Opportunity

By: David Hawks | Jun 19, 2013 |  Agile,  Agile Transformation,  Article

picture of a rowboat on water, many companies are drowning in a sea of opportunity“Many Companies are Drowning in a Sea of Opportunity.” Ken Rubin made that statement at a conference I attended and it resonated with me. This is probably one of the top three issues many companies face — they try to do more than their capacity allows and it perpetuates the problem.

If companies would focus on a single project at a time, they can be 2-4x more effective than splitting time between multiple projects.  When working on four projects at a time of similar size, the first project may take 80% of the overall time.  However, when focusing on one project at a time, the first one could be completed in 20% of the time and the rest of them done sequentially in typically 40%-60% of the time it would have taken if done simultaneously.

graph depicting simultaneous vs single projects - companies are drowning in a sea of opportunity

 But why do we work on so many projects at once?

The top two traps organizations fall into:
  1.  Stakeholders wanting their project to be “In Progress”
  2. Management trying to maximize the efficiency of individuals
The underlying issue in everyone wanting their projects “In Progress” is a lack of trust. Customers and Stakeholders want to know their project is “In Progress” because if it is, then they feel they have a higher chance of receiving it someday. If it hasn’t started, they don’t know if they will ever get it. This is typically a problem with teams that aren’t delivering frequently and/or aren’t providing transparency.
Management teams have been trained to focus on efficiency and utilization. Too often this translates into focusing on individual optimization as opposed to system optimization. This is an ineffective way of thinking when leading knowledge workers. By optimizing individuals you will typically sub-optimize the overall system.

In contrast, the whole system should be optimized to deliver value.

For example, I often hear things like, “it is more efficient for our lead developer, Pat, to just go work in his office for 80 hours to get the feature done.” It might be more efficient for him to crank out the most code, but will it help QA understand how the system is being built? Will it ensure Pat is building the feature to meet the customer’s needs? Collaboration is inefficient at an individual level, but it’s critical when trying to maximize value delivery.
Organizations should balance demand to their throughput and limit how much Work is in Progress (WIP) at one time.  This requires leadership to make hard decisions about priorities. If not, and they maintain everything a high priority, then they are deferring the decision to the implementer–the least equipped to understand the business drivers.
Imagine Pat is given four High priorities and told they all must get done immediately. How does Pat decide which one to work on first? The easiest? Whoever is screaming the loudest? The one that looks the most fun? These are all excellent criteria to be used to run your business, right?
By limiting WIP and balancing demand to throughput, companies can realize some valuable results:
  • Increase productivity and deliver more value
  • Customers become more engaged
  • Agility to adjust when changes occur
  • Limit the costs of delay
  • Lower cycle times
Blog

Qualities of a Good Team Player

By: Agile Velocity | May 29, 2013 |  Agile,  Article,  Leadership,  Team
Blue Angels are team playersThe word “team” in Agile Team is hugely important and something we rarely give much thought to.  I recently browsed the web to discover and define what really makes a good team player.  Part of my personal journey is to improve as a member of my team.  I look to these words for inspiration.

Coming together is a beginning.
Keeping together is progress.
Working together is success.

– Henry Ford
None of us is as smart as all of us

Dependable, reliable, and consistent

You can count on a reliable team member who gets work done and does his fair share to work hard and meet commitments.

Communicates Constructively

Teams need people who speak up and express their thoughts and ideas clearly, directly, honestly, and with respect for others and for the work of the team.

Shares openly

Good team players share. They’re willing to share information, knowledge, and experience. They take the initiative to keep other team members informed.

Asks “What can I do to help the team succeed?”

Team members who function as active participants take the initiative to help make things happen, and they volunteer for assignments.

Listens

Teams need team players who can absorb, understand, and consider ideas and points of view from other people without debating and arguing every point.

Cooperates

Good team players, despite differences they may have with other team members concerning style and perspective, figure out ways to work together to solve problems and get work done. They respond to requests for assistance and take the initiative to offer help.

Flexible

A flexible team member can consider different points of views and compromise when needed.

Problem-solver

They’re problem-solvers, not problem-dwellers, problem-blamers, or problem-avoiders. They don’t simply rehash a problem the way problem-dwellers do. They don’t look for others to fault, as the blamers do. And they don’t put off dealing with issues, the way avoiders do.

Considerate

Team players treat fellow team members with courtesy and consideration — not just some of the time but consistently. They care about the team winning.

When observing the best teams, it is difficult to identify leaders.

  • The creative type who generates ideas called the Plant
  • The extrovert who has good networks (the Resource Investigator)
  • The dynamic individual who thrives on the pressure (the Shaper)
  • The person who soberly evaluates the usefulness of ideas (the Monitor-Evaluator)
  • The cooperative team player (the Team-worker)
  • The ones with specialist skills (the Specialist)
  • Those who turn ideas into solutions (the Implementer)
  • The person who get issues completed (the Completer-Finisher)
  • The person who keeps the team together effectively (the Co-ordinator).
Blog

Recap of LSSC12 Conference

By: David Hawks | May 17, 2012 |  Agile,  Article,  Kanban
Lean Software and SystemsI just returned from the Lean Software and Systems conference in Boston. There was a definite common thread around learning cultures and a focus on treating our industry as a set of scientific experiments. The heavy influence from the Lean Startup movement was prevalent. Here are some of my takeaways for those that were not able to attend.

Steven Spear

  • Greatness is achieved by increasing the pace of learning

David Anderson

  • Kanban Principles
    • Start with what you do now
    • Agree to pursue incremental evolutionary change
    • Initially respect current roles responsibilities and job titles
    • Encourage acts of leadership at all levels from individual contributor to senior management
  • Implement feedback mechanisms added
  • Steps for converting to Kanban
  • Understand sources of dissatisfaction
    • From viewpoint of internal and external
    • Source of variability that cause dissatisfaction
  • Demand and capability analysis
    • By work item type and class of service
  • Model workflow
    • Understand the knowledge discovery process by type
  • Kanban system design
  • Visualization
  • Roll out plan

Steven Denning

  • Dude’s Law – David Hussman
    • Value – Why/How
    • Focus on the Outcome
  • The only valid purpose of a firm is to create a customer
    • Not create shareholder value
  • Switch your focus from Outputs to Outcomes
  • Customer Delight = Providing a continuous stream of value to customers and delivering it sooner
  • The goal is to delight the customer. Everything else is a means to getting there
  • Less is more. Aim for the simplest thing.
  • Costs will come down because you will only focus on things that delight your customer
  • Commands kill conversation
  • Money kills inspiration

Dominica DeGrandis – Kanban for IT Operations

  • Need to get visibility to dependencies because they carry risk
  • Design your SLA’s into your board. Create timeline like tick marks across your in progress column and move items each day.
  • Problems with board where there are names for swimlanes
  1. Standups are focused on individuals
  2. Perception of poor performance
  3. Limits Collaboration
  4. Focus on utilization
  5. Pigeon hole folks
  • Bring visibility to skill levels of different skills required on team
  • Make interrupts visible
  • Institute the Goalie.
    • Handles small interrupts
    • Rotates Weekly
    • Expands Knowledge base
    • Gain flexibility in team
  • Make a policy on when the team should create a ticket for something (i.e. takes more than 4 hours)

Jeff Patton

  • Focus on Value
  • Don’t focus on maximizing the output, focus on maximizing the impact of the outcomes
  • Think beyond the edges of the Kanban board

Arne Roock and Markus Andrezak

  • “Projects” are like waterfall containers that have planning, time constraints, focus, budget and purpose
  • Replace projects with epics that align to strategic goal/ outcomes. Let the team work to achieve those outcomes

Don Reinertsen

  • Compared Software to Firefighting, “You don’t just say this is a complex adaptive problem so we can’t create a plan”

Jim Benson

  • Change happens in evolutionary leaps
  • Kaizen is a status quo monster

Misc

  • Can run simulations through board http://www.focusedobjective.com/
  • “Standard” is just the status quo written down

Some of the presentations:

Blog

Infrastructure Agility

By: Agile Velocity | |  Agile,  Agile Technical Practices,  Article

Architectural Infrastructure - infrastructure AgilityWhether your team is agile, lean, or anything else you have likely run into frustrations with your infrastructure

See if any of the following strike a chord with you in relation to Infrastructure Agility:

  • You aren’t sure how your servers are configured
  • Your servers, workstations, etc. aren’t configured the same way
  • Nobody is sure who changed a configuration file, or why, and what was the last good version of the file?
  • Who installed that rogue server process? Why was our standard version of a dependency upgraded that is now breaking our applications?
  • Why are our development servers configured differently than our QA servers? What will it take to make them the same?
  • How long will it take to upgrade or install application x on our cluster of servers?
  • Your developers/QA/UAT Testers are blocked 3 days waiting on ops to install/upgrade a server with something new needed for a story
  • It takes 3 days for new developers to get set up with all the standard dependencies (or the machine image used has old/missing versions and needs a lot of upgrading)

No matter what your particular frustration, your infrastructure, and systems take time and effort. We see it all the time, but it is especially frustrating when teams following lean/agile principles who have put effort into eliminating waste and providing quick feedback find themselves against another wall they must continually climb and are regularly slowed.

Getting Control of Infrastructure

We don’t advocate solving a problem you don’t have, so if frustrations like those mentioned above are not among the bigger problems affecting you, just file this away for later.. But for many of you the above probably resonates.

So, where do you start?

Outsource It!

First, why not just fix the glitch? Why spend time trying to address a problem you can get rid of? Look at your application, infrastructure, whatever that is causing you pain. Is it standardized enough that you can just offload the problem?

We don’t want to just move the problem to a team doing the same thing in another location. What I’m referring to is taking advantage of platforms that have taken common deployment or infrastructure scenarios and packaged the operations around them as a service. You do this when you choose to host a server on a cloud service like [Amazon] or [RackSpace]. This kind of cloud computing model which abstracts and automates the details of physical hosting of storage and computing resources is often referred to as Infrastructure as as Service, or IaaS.

You can take this to another level by using a service like Heroku or AppFog that removes the need to manage servers and instead deploy to more highly managed environments that accomodate certain solution stacks. If your application fits their managed platform or isn’t too customized you can avoid having to deploy both servers and much of your solution stack, focusing on your core application code and configuration. This level of cloud computing services is often referred to as Platform as a Service or PaaS.

Offloading what you can offer you the reduced complexity of operations for some or all of your environments. But for many teams, we have found constraints that don’t allow taking advantage of these types of services.

Control It!

Whether you have resources in the public cloud, private clouds, or on good old bare metal hardware, you have work to do to manage provisioning, configuration, deployment, and tracking of assets and infrastructure.

Agility in infrastructure is achieved through:

  • Providing good visiblity on the infrastructure you have
  • Eliminating bottlenecks to adding / changing your environments
  • Minimizing complexity
  • Being able to adapt quickly to changing business needs
  • Having a high level of communication and visibility across all those involved in delivering software to end users

Many operations teams already track assets in various places. Some keep standard configuration files and checklists they use for consistency. Others have scripted common tasks in their daily operations work. But not all do these sorts of things. And even if they do, manual work ends up being the biggest bottleneck of all. The Path to Agility® requires finding straightforward, consistent ways to communicate, control, and automate your infrastructure management.

Infrastructure as Code

While not necessarily new, there has been some disruptive change in recent years led by the growing popularity of tools like Chef and Puppet. Similar tools, such as CFEngine have been around much longer in different incarnations both inspiring the newer generation of tools and greatly evolving in their own ways. The combination of these types of tools with the rapidly expanding selection of virtualization and cloud tools.

The philosophy is simple, with the support of the right tools a team can create configuration files and scripts (code) that describe what their infrastructure should look like and how to go about creating it. This code can be executed to provision systems, configure and install dependencies, deploy applications, take inventory of what is deployed, and keep things consistent.

As Jesse Robins once described, the goal is to:

Enable the reconstruction of the business from nothing but a source code repository, an application data backup, and bare metal resources.

Such an approach to managing infrastructure isn’t limited to servers either. Some groups use it to help keep developer, tester, or other types of desktop machines up to date with the latest tools/configuration a team needs. When you have only a few machines to manage such an approach is neat. When you have hundreds or thousands it becomes essential.

Hopefully, this has piqued your interest or brought awareness to how we include infrastructure in our assessment of agility and waste. As always, don’t solve a problem you don’t have. But if infrastructure issues are affecting your team and you have identified the bottlenecks stay aware of your options.

We will follow up with additional posts in this series on Infrastructure Agility with looks at DevOps and a closer look at tools like Chef and Puppet.

Blog

A Tried and True Method for Retrospectives

By: David Hawks | May 10, 2012 |  Agile,  Article,  Scrum

Rear View Mirror - RetrospectivesI feel the Retrospective is the most important ceremony, especially for new teams. I am concerned when ScrumMasters boast they can get their Retrospective done in 30 minutes or less. I must ask, “Did your team learn anything? Are they improving? Are they pushing themselves through the Tuckman Model and getting close to becoming a High Performing Team?”

In my experience, new teams need 1.5 – 2 hours for a healthy retrospective. They need time to reflect on the Sprint and fully explore opportunities for improvement. The retrospective is a key ingredient in engaging teams to take ownership of their own process and figuring out how to improve. In this post, I will walk through my standard approach to a Retrospective.

Goal of Retrospectives

It is easy for the team to identify a laundry list of problems, but the team can’t address more than a couple at a time. The goal is to devise 1-3 actionable items the team can change during the next Sprint timeframe. If the team can make a 2% average improvement every two weeks, they would accomplish over 50% improvement on the year. In order to encourage more significant improvements, we also need to help the team have the courage to try some more radical changes.

Set the Tone

When I kick off a retrospective, I want to make sure it is a safe room for the Team. This includes the team members (Pigs), ScrumMaster and Product Owner, but does not include chickens, stakeholders or managers. We also want to defuse negativity. I usually kick things off with a statement like the following:

“We are looking for changes that we the team can change. This is not a blamestorming session (I usually point with my fingers outside the room), this is a chance for us to reflect on what we (pointing at myself) can do better as a team.”

I might also put the Norm Kerth quote up if I think there might be some attacking of individuals:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

When setting the tone, I also like to share our current metrics. Things like:

  • The Sprint Burndown
  • Sprint Results (Points planned vs. completed)
  • Release Burnup to show progress on overall goal

This helps the team review some of the facts around their performance and effectiveness.

Data Collection

The next thing to do is gather some data and insights on the Sprint. The standard way to do this is Start, Stop, Continue. I create three sections on the wall or whiteboard with those titles and have the team come up with as many items as they can in 5-10 minutes. We are looking for:

  • Things that worked well and the team should Continue
  • Things that did not work well and the team should Stop
  • Things that the team did not do and should Start

This exercise should be silent with folks writing individually. This tends to prevent a couple voices from dominating the discussion and get the introverts to participate a little bit more. We want to give the team members time to reflect to themselves on opportunities for improvement and reinforcement.

They should all be writing at the same time with provided Sharpies and Post-it notes. They should write one item per Post-it, which can be put on the wall anytime. Sometimes, the early ones will help others generate ideas, but this is all done silently. The Sharpies are important so that everyone in the room can see what is written on the Post-it. Once I see that no new ideas are being generated, I move on to the next step.

Read for Clarity

I introduce this step by saying:
“Now we want to read through the items to get an understanding of what everyone has written. On this first pass, we just want clarity so we don’t want to get into discussion or debate. If you are unclear of the meaning of what someone wrote, just ask and that person can provide a brief description of their intent and then we will move on to the next item.

Now, who can come up and read one of the columns?”

I have volunteers from the team read the items to foster ownership by the team. As the facilitator, make sure the volunteer is reading slowly enough so participants have enough time to digest. If after a couple have been read and no one has asked to clarify, I typically will ask for one to be clarified so people recognize it is ok to interrupt. Once they have finished one column, I thank them and ask for another volunteer until all three columns are read.

Group and Theme

In the next phase, we will organize what we have to determine where to focus our discussion because there is rarely time to discuss everything. I ask everyone or for large teams everyone who did not volunteer to read a column, to stand up and go to the board. At the board, we want everyone to do a silent sort (for speed). They should put like items near each other (without covering up the others). At this stage, it is ok for items to move across columns. Once they have a grouping, they should label the themes. It is ok to have a couple oddballs that don’t fit into the groups.

Prioritize

If you have 3 or less core themes, focus on those and start with the one with the most items. If you have more, then you need to prioritize. I like to use dot voting. I give each person 3 dots (Stickers) and ask them to vote on the topics they think are the most important to tackle. They can put all three on one item or spread them across multiple. They are voting for a theme not individual items. (Hint: ask them to place them on the Post-it as it is much more difficult to peel them off of the whiteboard or wall.)

Discuss

Based on the voting pick the top 3 items and set a timebox of about 15 minutes per item. Ask an open-ended question on the topic and then let the team own the discussion. (i.e. “So what do you guys see as the underlying problem here?”) As the facilitator, try and refrain from leading this discussion. We want the team to drive it and it is ok for the discussion to wander a bit. After 5-10 minutes, try and bring it to a close with something actionable the team can change. Prompt them into solutioning by asking something like, “So what can we as a team do about this?”

Take Action

Make sure the team comes up with actionable changes, i.e. SMART goals. Ensure the team discusses how they are going to make it happen. Create immediate tasks in the Sprint Planning session that should follow. Make the goals visible and part of the plan, i.e. put them on the task board.

Other Variations

  • Don’t let it get stale. Try different things. I recommend buying Esther Derby’s book (listed below) to help generate new ideas to keep your team engaged.
  • Other favorites: Speed Boat (Innovation Games), Triple Nickles (Esther), Mad/ Sad/ Glad (Esther)
  • Sometimes just have a conversation as a team
  • Occasionally just focus on a team-building exercise
  • The problems aren’t always clear and you will need to do some root cause analysis. Some great tools for that are a Fishbone and the Five Why’s.
  • It is ok for the ScrumMaster to set a focus topic of the retro. i.e. Let’s focus on self-organization or being releasable at the end of the sprint
  • For Release Retrospectives I like to do the Timeline (Esther) exercise or Remember the Future (Innovation Games)

References

  1. Agile Retrospectives: Making Good Teams Great, Esther Derby & Diana Larsen
  2. http://innovationgames.com/
Blog

Kanban vs. Scrum – How to Choose?

By: David Hawks | Feb 02, 2012 |  Agile,  Agile Tools,  Article,  Kanban,  Scrum

scale weighing two question marks - Kanban vs ScrumKanban vs. Scrum – Which is Right for my Team?

Clients frequently ask us when they should use Kanban and when they should use Scrum. To form a recommendation, these are some of the questions we ask:

What best describes the nature of your team’s work? Is it complex, risky, and/or new feature-oriented or is it well-defined, fluid, and/or more service-oriented?
If you answered yes to complex, risky, and/or new feature-oriented, score 1 for Scrum.  If you answered yes to well-defined, fluid, and/or more service-oriented, score 1 for Kanban.  The Scrum framework is designed to address complex, adaptive problems. Kanban is a Lean method applied to a team’s process in order to improve flow. 

Do your priorities change often? Do you have trouble locking scope for 1-2 weeks at a time? Do you have more than 25% scope churn during a 2 week period?
If you answered yes to these questions, score 1 for Kanban. By dropping the fixed timebox, it may allow your team to adapt more easily to the quickly changing priorities of your business.

Do your teams struggle to break features into incremental pieces of value to be delivered in less than a week?
If you answered yes, score 1 for Scrum. Both approaches work best when you break your work down into small incremental pieces. The Scrum Sprint timebox can help teams new to the practice recognize their deficiency (work not completed at the end of the sprint) and adapt (retrospective).

Can teams break work down to reasonably small, similarly sized chunks?
If yes to these, score 1 for Kanban. Kanban removes the overhead of estimation in favor of measuring cycle time for like-sized items.

Do your teams have a strong culture of continuous improvement and self-organization?
If so, score 1 for Kanban. The lightweight framework method that Kanban provides works very well in a culture of continuous improvement. They will determine the right times to hold a retrospective. For teams new to this practice, a regular cadence of a retrospective ceremony will help teams establish this practice.

Do your teams need to improve their discipline with technical practices and craftsmanship, such as TDD, Continuous Integration/Delivery, Shared Ownership, etc.?
If you answered yes, score 1 for Scrum. Both approaches excel in an environment of strong technical practices.  Scrum can help teams iterate through improving their technical practices and delivery, by focusing on production worthy increments, as well as Sprint Reviews and Retrospectives.    

Is your team’s top priority to optimize responsiveness to customer needs?
If so, score 1 for Kanban. Kanban has a strong focus on optimizing flow, while Scrum has a stronger focus on incremental delivery. Both can be tuned to provide similar outcomes, but Kanban offers the flexibility to lower batch size to reduce cycle time at the potential cost of productivity.

Is your team’s top priority to focus on predictability and productivity for larger projects?
If so, score 1 for Scrum. Again, you can achieve predictability and a high level of productivity with both approaches. For new teams, Scrum provides more guidance and resources for how to handle release planning and progress tracking.

What is the team’s appetite for process change?
If low, then score 1 for Kanban. Kanban is a method we apply to our existing process, whereas Scrum introduces a few events that may be new to the team. So, Kanban may be easier to introduce into your organization.

Does your organization / culture demand a higher degree of ceremony and artifact?
If so, score 1 for Scrum. Not that Scrum has a high level of ceremony, but it can integrate well into a culture requiring more structure and documentation. From a Lean perspective, we may question the need for these as potential waste. The reality is that sometimes we have to fit within a certain culture and incrementally work ourselves out of it.

Summary
Both Kanban and Scrum require strong discipline and rigor to be sustainably effective. Kanban doesn’t have as many rules, which is good, but it also can be ineffective with an undisciplined team. For example, undisciplined teams may constantly carry over unfinished work with Scrum or ignore WiP (work in progress) limits with Kanban. Scrum’s Sprint time box and Kanban’s WiP Limit both challenge teams to figure out how to break work down into smaller pieces to get them to a true state of ‘done’.  

Teams most commonly successful with Kanban fit into two areas:

  1. Support or Shared Services teams – These teams are focused on serving the organization to keep the production systems running or other critical business services. Their priorities can change on a daily basis. These teams need to be ultra-responsive. Kanban can enable these teams to optimize flow.
  2. Mature, disciplined, self-organizing teams. They are engaged, have well-defined processes, understand how to break down work, and are constantly swarming to solve problems and get things done.

Choosing an approach that best suits your team’s needs can be greatly enhanced by providing formal training, supported by coaching.