Menu
Change Management Week
Everyday this week!
My favorite thing about a new year is the opportunity to start fresh, put some things behind you, and move forward with a renewed sense of determination. Start by taking a minute to look back on your development efforts over the past year. Ask yourself these questions. Is what you are doing today working for your organization, your customers, and/or for your individual resources? Are the leaders of your organization complaining about not meeting their IT goals last year? Are the product owners and project managers complaining that IT didn’t deliver high-value and high-quality software? Are the individual resources burned out? Is morale and/or motivation low? Is turnover and absence from the job high?
Now, the next question: can you continue to work this way for another year, doing the same things, the same way but expecting different results? That would be insanity, right?
I often talk to students and other people in software development that would say “Yes” to many of the questions above. A popular trend right now is to go from a waterfall to an agile or iterative development approach. This isn’t a bad trend to follow, but timing is everything!
Many times, I’ve seen organizations move too quickly into agile without realizing how drastic this leap can be. Teams can be easily overwhelmed and have a bad first impression, which can take months and years to reset or recover (and typically a lot of rework by expensive consulting teams). In some extreme cases, I’ve even seen teams abandon agile all together and use their experience as an excuse to never attempt another change in anything they do.
I hear it all the time – many of you facing these challenges will say that your company, department, and/or project will never be “agile”. I typically don’t disagree. As much as I’m an agile advocate and have firsthand experience that agile works in a variety of environments, I don’t think every team or organization can become Agile overnight.
Before you throw your hands in the air and say, “See, Jacqueline agrees, we can’t be agile.”, I have a suggestion. Slow down, start with some baby steps. (This will also apply to many of you who might still be in a pure waterfall environment, but looking for a way to start using some agile techniques to improve your process.)
Scrum has almost become synonymous with agile, and, because of the structure Scrum provides, many teams start their agile transformation with it. However, I have found that sometimes Scrum is not the best first step for a team. I recommend taking a more forgiving Kanban approach. In my experience, successfully using a Kanban approach has proven to be a successful precursor for a long-term agile implementation.
You didn’t misread, I did call it the Kanban approach because I’m not just referencing a Kanban board. Kanban actually has its own framework and flow. Using the Kanban approach and leveraging it to foster agile values can help teams work to balance iterative and traditional approaches and provide a benefit for an organization struggling with or looking for an introduction to agile. Let’s take a look at a few baby steps that any team can do to start moving in the agile direction using a basic Kanban approach.
As I detail the baby steps below, please note that I’ve included a relationship to the corresponding Agile Value. It is important not to lose sight of your end goal of becoming more agile. The key is to not be random in how you approach Kanban, but to make sure you are taking steps toward all four of the core agile values:
In short, while there is value in the items on the right, agile values the items on the left more.
When it comes to processes in Kanban, unlike Scrum, the work isn’t necessarily done in a timebox of 2-4 weeks. Work items (whether they are stories, work items or tasks) are selected by the team members and worked on until they are ready to be delivered. This is particularly beneficial for special software services groups, support groups, and shared services where a range of work items come in from multiple product managers and where waiting for the other item being worked on doesn’t add value and cannot always be completed in specific sprints.
Responding to change over following a plan
This approach to process very much supports change. In using Kanban to promote agile, make sure that the team communicates and decides who is working on what and daily touchpoints are in place to ensure that you all are approaching the backlog as a team. In Kanban, before a team member starts a new item, he or she confirms that no other team member needs assistance to finish other work in progress. This is an example where without this type of Kanban discipline, the flexibility will turn into every man for themselves and individual contributions instead of a Kanban-Agile Team environment.
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 in a two-week sprint, the team finds a way to split it, even if reduces the business value of the story. However, in Kanban, a story doesn’t have to be forced into a timebox because there isn’t a timebox.
Customer collaboration over contract negotiation
To align with the customer collaboration value, be sure there is total transparency and a healthy conversation between the Product/Business Owner(s) and the team. The product owners must be disciplined to respect what is feasible and understand the capacity of the team. The team can earn this level of trust with Product/Business Owners by providing accurate estimates of what something is going to take and consistently meeting those expectations. I recommend reading Ali’s 4-Task Solution for Estimating and Defending Your Analysis Plan blog post for more tips and a template to help! The discipline of “relative sizing” is central to maintaining the Kanban-Agile Collaboration.
The Board in Kanban is borrowed by Scrum and essentially serves the exact same need by allowing the team to visualize their work and workflow. However, there is a difference on the Scrum versus 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 (I call it the emergency lane). Scrum assumes that all of 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 with an Epic in Scrum.
Working software over comprehensive documentation
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).
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 groomed to be cross-functional. While we typically promote cross-functional teams, this is sometimes better for traditional waterfall environments since some of the tasks require a highly specialized skill set.
Individuals and interactions over processes and tools
In this case, the Agile manifesto value of Interaction has to be fully embraced. The team should operate with the mindset that the actions of each individual on the team impacts the whole team. It’s not just enough that the work gets done, but also that how the work is getting done doesn’t negatively impact the team. In some cases, team members will have to ‘over communicate’ so that everyone understands what others are doing and their progress.
In Kanban, estimation is flexible, but the approach must be consistent, reliable, repeatable and it must work for the team, the customer, and provide executive leadership a comfort level of progress.
Individuals and interactions over processes and tools
The key value to keep in mind is that your team is disciplined at accurately estimating, but also realizes it’s equally important to define a delivery timeframe that provides business value.
This is an area in which Kanban and Scrum have very similar ideas. Kanban Limits help manage capacity the way “velocity” does in Scrum. Setting boundaries that ensure the team isn’t over committed can help empower its members. In the case of Kanban and Work/Scope Limits, the team decides how much work in progress they can reasonably handle, based on experience. Repeated violations of Work in Progress limits, like a Scrum Team’s velocity 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.
Individuals and interactions over processes and tools
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.
Kanban Workflow allows for continuous release versus Scrum’s timeboxed releases. The thought of a 4 or even a 2-week release is unthinkable to some teams, especially those new to agile who have traditionally been waterfall. Using continuous releases can be extremely beneficial to groups that handle support and special services and with a variety of product owners. Continuous releases can much better satisfy their needs by allowing their request or need to be addressed and used as soon as it’s ready. The type of work and task should determine what type of release framework is best.
Responding to change over following a plan
The Kanban Workflow fits into this Agile Manifesto value in that you can still shift business priorities as the work progresses by moving requests or features around, adding in new ones, or even eliminating non-value-added features. We should always be looking to improve a project so that it provides the business value needed to achieve success.
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, as well as an end product. The planning and prioritizing is at least weekly and bi-weekly but impromptu meetings are also acceptable. In general, you can do more frequent touch points than Scrum but not fewer. However, 99% of the teams that I’ve worked with who are benefiting from Agile inspired Kanban utilize a structured meeting schedule, like typical Scrum ceremonies. Why resist something that seems to work? This includes daily stand ups and bi-weekly retrospectives.
Individuals and interactions over processes and tools
The Agile Manifesto value here that really embraces all the other values is geared toward more, better, and more efficient communication. Regular touch points keep the team aligned and working together.
Taking baby steps is a great start, but also know that you can’t expect the big results. The benefits are in proportion to how slow or fast you adopt the corresponding framework.
Don’t think that this implementation is some indication that Scrum is all about providing structure to Agile and 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.
I hope you see that by taking some Kanban baby 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 begin to declare a starter agile status.
We can help you with implementation of a Kanban, and eventually full-blown Agile. To help get you started, 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 feel. Contact us today!
Thank you,
Jacqueline
© Copyright 2023. Netmind. All rights reserved.
Por favor, proporciona la siguiente información para ayudarnos a personalizar la solución.
Netmind España
Barcelona +34 933 041 720
Madrid +34 914 427 703
Nos puedes encontrar de:
Lunes – Viernes, 9:00-18:00 (GMT+1)
¡Te ayudamos!
info@netmind.net
¿Dudas sobre servicios/formaciones?
comercial@netmind.es
