It’s been a year of fresh starts for us here at B2T. We’ve had the opportunity to assess how we do things and figure out what’s working and what could be improved. This has allowed us to move ahead with some concrete goals and a clear direction.
Well-run IT organizations also reflect on their results. They ask questions like:
- Is our leadership complaining about missing IT goals?
- Are our customers complaining about the value or quality of the software we delivered?
- Are our individual resources burned out
- Is morale and/or motivation low?
- Is turnover and absence from the job high?
In short, is what we’re doing working for the organization, our customers, and our resources?
And very importantly, should we continue to work this way for another year, doing the same things the same way, but expecting different results?
That would be crazy, right? We often talk to students and others in software development who would answer “Yes” to many of the questions above – yet they keep working in the same way.
Organizations frequently respond to these issues by switching to an agile development approach. Becoming more agile is an admirable goal. Unfortunately, organizations can try to move too quickly into a new way of working without realizing how drastic the changes will be.
Teams can be easily overwhelmed and have a bad first impression, which may take months or even years to overcome. In some extreme cases, teams abandon agile all together and use their initial failure as an excuse to avoid any change in the future. They say that their company, department, and/or project will never be “agile”.
It’s impossible to become “agile” overnight. But that doesn’t mean you should throw your hands up in the air and say, “See? We can’t be agile. It’s just not going to work here.” We have a suggestion. Slow down and start with some small steps. Remember – agile development is iterative and incremental. A successful transition to agile should follow that same philosophy.
By the way, these steps also work for those of you who follow a waterfall or hybrid approach. It’s a good way to start using some agile techniques to improve your outcomes.
Getting Started
Scrum has almost become synonymous with agile, and, because of the structure Scrum provides, many teams start their agile transformation with it. However, we have found that sometimes Scrum is not the best first step for a team. Many teams benefit from taking a more forgiving Kanban approach as their first step into agility. In our experience, successfully using a Kanban approach has proven to be a beneficial precursor for a long-term agile implementation.
More Than a Board
You didn’t misread. We did call it the Kanban approach because we’re not just referencing a Kanban board. Kanban actually has its own framework and flow. The Kanban approach can benefit organizations by fostering agile values regardless of the development approach that’s being used.
Let’s take a look at a few small steps that any team can do to start moving in the agile direction using a basic Kanban approach.
- Agile Manifesto Alignment
As we detail the steps below, please note that we’ve highlighted a relationship to the corresponding Agile Manifesto Value. It’s important to focus on your end goal of becoming more agile. The key is to make sure you’re taking steps toward all four of the core Agile Manifesto Values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
In short, while there is value in the items on the right, agile values the items on the left more.
Process
Unlike Scrum, work in Kanban isn’t necessarily done in a timebox of 2 – 4 weeks. Work items (whether they are stories, backlog items or tasks) are selected by the team and worked on until they are ready for delivery.
This is particularly beneficial for special software services groups, support groups, and shared services where a range of work items come in from multiple sources. Work for these teams often involves wait time and cannot always be completed in specific sprints.
- Agile Manifesto Alignment
The Kanban approach to managing work very much supports responding to change. In using Kanban to promote agile, be certain to implement daily touchpoints. During those touchpoints the team can not only communicate about the work that is already in progress, but also decide what work to begin next, and who will work on what. This allows the team the flexibility to respond quickly to a changing backlog of work.
The discipline of the Kanban approach ensures that the backlog of work is approached as a team. Before a team member starts a new work item they confirm that no other team member needs assistance finishing other work that is already in progress. This helps prevent “siloed” work efforts where people focus on individual contributions and it’s “every person for themselves.”
Tasks
In Scrum, stories are sliced or split to make sure they fit into the timebox of your sprint. If a story is too large to fit into a sprint, the team finds a way to split it, even if reduces the business value of the story. However, in Kanban, work doesn’t have to be forced into a timebox because there isn’t a timebox.
- Agile Manifesto Alignment
Kanban helps teams develop a steady and predictable flow of work. Over time teams learn to accurately estimate the effort involved in a work item and provide a realistic delivery date. This consistent performance helps earn the trust of their customers (Product or Business Owners), who begin to respect the capacity of the team. This allows the team to work collaboratively and productively with their customers, in accordance with the agile philosophy of valuing customer collaboration.
Board
The board in Kanban is borrowed by Scrum and essentially serves the exact same role by allowing the team to visualize their work and workflow. However, there is a difference between a Scrum board and a typical Kanban board. The Scrum team board shows the work scheduled for a two-week period and its progress flows across the screen left to right, leading to the delivery date. A Kanban board often highlights and emphasizes things that are on hold and includes an area for urgent fixes (we call this the emergency lane).
Scrum assumes that all the work scheduled for the timeboxed sprint will be done, and typically, due to slicing and splitting stories, this is accurate. Kanban allows for work that is unpredictable by tracking leading and lag time, elapsed time, and time on hold because the work items/tasks within a Kanban team are not nearly as predictable as those in Scrum.
- Agile Manifesto Alignment
Rather than producing lengthy documents, Kanban teams use their board and other “information radiators” to share information about work items and progress.
This statement doesn’t imply that you should have no documentation, but rather that the documentation produced should provide value for the project, but not slow the team down.
Roles
When it comes to Kanban Roles, there isn’t a designated Scrum Master. Also, members of a Kanban team who maintain their individual specialties may not be trained to be cross-functional. While we typically promote cross-functional teams, this approach may not be practical for traditional waterfall environments since some of the tasks require a highly specialized skill set.
- Agile Manifesto Alignment
Kanban promotes the concept of an inter-dependent team. It encourages teams to look beyond titles & roles. The team should operate with the mindset that the actions of each individual impacts the whole team. It’s not enough just to get work done. Getting work done shouldn’t negatively impact the team as a whole. In some cases, team members will have to “over-communicate” so that everyone understands what others are doing and their progress. This strongly promotes the agile value of individuals and interactions.
Estimation
In Kanban, estimation is flexible, but the approach must be consistent, reliable, and repeatable. It must work for the team and the customer, and it must provide executive leadership a level of comfort regarding the team’s progress.
- Agile Manifesto Alignment
The key here is balancing the disciplined process of accurate estimation with defining a delivery timeframe that provides business value and clearly communicating that timeframe to affected customers.
Limits
This is an area in which Kanban and Scrum have very similar ideas. Kanban “WIP limits” help manage workload the way “capacity” does in Scrum. Setting boundaries that prevent the team from being over-committed can help empower its members.
In the case of Kanban and work/scope limits, the team decides how much work in progress (WIP) they can reasonably handle, based on experience. Repeated violations of WIP limits, like a Scrum Team’s capacity violations, are usually a result of mistrust. This can also be an indicator of the team’s inability to self-manage and often leads to a micro-management or command and control management style. Neither of these management approaches belong in Kanban or Scrum environments.
- Agile Manifesto Alignment
If the processes or tools we use on a team are slowing us down, it may be difficult to stick to the commitment the team has made. The team should embrace the tools and processes that help it work more efficiently and either change or discard tools that impede good progress.
Workflow
Moving from a waterfall approach to one where work is broken into very small pieces that must be delivered in a 2- to 4-week timeframe is a huge change. Kanban allows for continuous release of work versus Scrum’s timeboxed releases and can be an easier transition into agile ways of working.
Continuous releases are also very beneficial for groups that handle support and special services, or those that must support multiple product owners. Kanban allows new requests to be addressed more quickly and delivered as soon as the work is done. The type of work and task should determine what type of release framework is best.
- Agile Manifesto Alignment
The Kanban workflow supports this Agile Manifesto Value by allowing the team to shift business priorities as the work progresses. Requests and features can be reprioritized at any time. New requests can be added whenever the team has capacity. Existing work is constantly re-evaluated; non-value-add work can be eliminated, allowing the team to focus on delivering business value.
Meetings
Kanban meetings are held when the team needs them. Because Kanban delivery is not timeboxed, demos are based on when there is progress to show. The planning and prioritizing is done at least weekly. Regular meetings to review and improve performance are held at a cadence that works for the team; impromptu meetings are encouraged when a need arises.
In general, it’s OK to have more touch points than in Scrum but not fewer. However, 99% of the teams that we’ve worked with who are benefiting from Kanban utilize a structured meeting schedule that is very similar to traditional Scrum ceremonies. Why resist something that seems to work? This includes daily stand ups and bi-weekly retrospectives.
- Agile Manifesto Alignment
Individuals and interactions over processes and tools
Agile teams should be geared toward more frequent, more effective, and more efficient communication. Regular touch points keep the team aligned and working together.
A Few Disclaimers
Taking small steps is a great start, but it may not deliver big results. The benefits are in proportion to the effort your team makes to really embody the principles of the Agile Manifesto. Also, don’t think that Scrum is all about providing structure to agile while Kanban is its lawless counterpoint. There is more leeway in Kanban, but often having someone with Scrum coaching experience will provide the opportunity to establish a consistent, repeatable approach.
Get Started
We hope you see that by taking some small Kanban steps, you can find a better, faster way of developing and delivering software. And since Kanban is considered a part of the agile umbrella, you can even claim to be an agile practitioner 😊
Hoping to implement Kanban or another agile approach? We offer services to evaluate and assess your team’s as-is state, facilitate discussions on process improvement, and educate your teams to show them how successful agile and Kanban can be. Contact us today! Thank you.
– Kathy
Kanban vs Scrum Infographic Download
It’s important to understand similarities and differences when it comes to Kanban vs Scrum. This infographic displays the key concepts of each approach with a reference to the related agile value to help you determine which is right for you.
Editor’s Note: This blog post was has been previously published by B2T on our previous website. Due to its popularity, Kathy has updated its content to be more comprehensive and accurate for the state of today’s environment.
Kathy Claycomb
Managing Partner, Lead Expert
Kathy Claycomb brings over 35 years of experience to the classroom. She has participated in all phases of solution development using everything from agile to waterfall methodologies (and quite a few in between). Before joining B2T, her career spanned roles from application developer to Senior Director of Services at various organizations. Kathy has broad industry background including transportation, manufacturing, insurance, energy, healthcare, and banking.
Kathy’s first love is teaching, and throughout her career she has always managed to spend a portion of her time instructing. She has an engaging, highly interactive teaching style that ensures students leave the course with a thorough grasp of the material. Her students consistently praise her teaching abilities and her talent for drawing on her personal experience to enhance their learning.
Kathy served as the Technical Editor for Business Analysis for Dummies, 2nd Edition.
