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.)
Where to start?
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.
More Than a Board
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.
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.
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.
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.
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.
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.
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.
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.
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 touchpoints than Scrum but not fewer. However, 99% of the teams that I’ve worked with who are benefitting 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.
A Few Disclaimers
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.
Get Your Agile Starter Status
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!
More on Agile & Kanban Principles
Also published on Medium.