Scrumban - framework overview and comparison to Scrum and Kanban

Scrumban is an agile software development framework which is getting significant traction lately.
This post is to provide concise definition for a Scrumban and a comparison to its parent frameworks - Kanban and Scrum.

All of Scrum, Kanban and Scrumban are agile frameworks and share the next key principles:

• Delivery organization is split into small, cross-functional, self-organizing teams.
• Overall scope being delivered is split into a list of small, concrete deliverables, which are sorted by priority - this list is called product backlog. 

Key Scrum characteristics are:

• Delivery time is split into short fixed-length iterations (usually 1 – 4 weeks), these iterations are called sprints.
• Sprint iteration scope (called sprint backlog) is defined at the start of sprint iteration during planning meeting, where the tasks for the sprint are identified, estimated and planned for implementation - with the goal to deliver potentially shippable code at the end of each sprint iteration.
• Key differentiating principle of Scrum is time-boxed development: during a sprint, no one is allowed to change the spring backlog, i.e. requirements are frozen for that sprint.
• Key metric of Scrum is iteration scope. It is tracked via tools like iteration burn-down charts and the ultimate process goal is to maximize scope released as a result of each iteration.

Key Kanban characteristics are:

• Delivery workflow is visualized with the help of Kanban card wall - where workflow states are represented with columns on a card wall and each specific work item is represented by a card (this card is called "kanban card" or just "kanban") and put on the wall into a specific column - in accordance with the state the work item belongs to. Kanban cards are moved between columns as the work item progresses through the delivery workflow.
• Key differentiating principle of Kanban is limit on WIP (work in progress): explicit limits are set for each workflow state on how many items may be in progress at each state.
• New work item (represented by a kanban card) is pulled out of product backlog when and only when amount of work items in the first workflow state (this may be called ToDo state) drops below WIP limit for this state. Finished work item is pulled into production as soon as it reaches the final state in a delivery workflow.
• Key metric of Kanban is lead cycle time -average time to complete one work item. The ultimate process goal is to make lead time as small and predictable as possible.

Key Scrumban characteristics are:

• 3 key principles of Kanban described above: visualization of a delivery workflow, limiting WIP for each workflow state and pulling work items from previous state are key to Scrumban as well
• The Scrum-style notion of iteration is used by Scrumban, but planning and release periods are decoupled. Convenient interval is defined to run planning sessions, another convenient interval is defined to package features to release. 
• In fact, Scrumban iteration scope may be defined by packaging work items after they have reached final development state - i.e. Scrumban iteration scope is defined at the finish of iteration 
• Key metric of Scrumban is the same as in Kanban - lead time, average time to complete one work item.

So, above is, in my point of view, concise definition of three methods and a description of differences between them.
To make things even more concise, here's extra-brief summary of three methods comparison:

• Scrum - work is devided into time-boxed iterations whith no possiblity to change scope within iteration.
• Kanban - the workflow is continuous with work items released as soon as they are complete and new work undertaken as soon as there's someone available to do the work.
• Scrumban - workflow is continuous with planning sessions and feature releases happening iteratively and independently of each other - next work items are defined periodically during planning sessions and features are packaged and then released together periodically as well.

Continuous Communication - extending communication windows for different time zones

As I've introduced Continuous Communication framework in my previous post, one of the aspects I've talked about was importance to maximally mobilize communication channels. This means extending personal communication availability window beyond one's work place - so that quick chat/voice/video session may occur when one or several of team members are out of their typical office hours.
This helps to implement flexible working hours strategy and also to address a challenge of a restricted communication window for teams in different time zones.

Now, here's two practical ways to implement this advice:

1. Invest into conference calling system and make it standard tool for cross-geography voice meetings.
As people are engaging into communication beyond their office hours, making VoIP calls is not always a good option - for some parts of your geographically distributed team high bandwidth connection may be not available or not reliable, which means utilizing "standard" VoIP tools like Skype of Google Hangout for multi-participant conferencing leads to unreliable and low-quality communication. Conference calling systems like OnConference help hugely in this situation - as they allow every participant to have really high-quality voice conference experience through simply dialing some local number (specified for each country) and then providing 7-digit participant code. In most of cases such dial-in calls are toll-free for participant's private mobile accounts, which removes yet another friction point to use the service. 

2. Utilize commute time for voice conferencing with your team members.
I've learned that regardless of location, for many people home-office commute oftentimes may take 30-120 min per day. It is indeed an excellent opportunity to extend one's voice communication window. If good 4G/LTE coverage is available during commute time, VoIP conferencing may be used. But, especially for conferencing with many participants, conference calling system is an ideal option at this point - one has to simply call their local number and enjoy high-quality multi-participant meeting. Also, having free-hands voice meeting during commute does not lead to driver distraction issues and is legal in most countries.

So, two simple rules: usage of conference calling system and utilization of one's commute time for voice meetings - may give up to two hours of extended communication window every day - a huge opportunity to improve communications in a project!

Introduction into Continuous Communication

As I've stated in my previous post on key challenges of a distributed development, building effective communication is certainly the biggest challenge. I think the best way to address it is via a well-defined and neatly-followed system approach which I would call a Continuous Communication.

Here are main constituents of a Continuous Communication.

1. Technical communication infrastructure. High quality. Available to everyone.
This is really foundational aspect. At Cogniance, we've learned through thousands of man-hours of distributed development that it does make sense to invest into really high-quality communications infrastructure - and make this infrastructure available to all team members without exceptions.
Specifically and typically, technical communication infrastructure includes:

• email
• shared calendars
• knowledge management system (usually wiki style)
• instant messaging tools
• voice conferencing tools
• video conferencing tools
• distributed collaboration system  (notes, screen, document, dashboard sharing etc)

2. Open personal communication profiles. Defined by everyone. Available to everyone.
The idea is that every team member should make themselves available for one-to-one or many-to-many communication session with any other member of the team. They provide this continuous availability via publication of their communication profile, which typically includes:

• email address
• personal calendar link (including information on personal communication availability window)
• instant messaging ids
• voice conferencing ids (personal mobile numbers)

Personal communication profiles should be available to every member in a team, so that key principle of agile development can effectively be implemented for a distributed team - everyone should have a reliable way to communicate to everyone on-demand, i.e. right when there is a need for a discussion.
In addition to sharing communication profiles, it is important to maximally mobilize communication channels and extend them beyond work place so that quick chat and/or voice/video call may occur when one or several of team members are out of their work place or out of their typical office hours.
This helps to implement flexible working hours strategy and this also helps to address a strong challenge of a restricted communication window for teams in different time zones.

3. Iteration-based, heartbeat-like meetings schedule. Carefully planned. Responsibly executed.
While ad-hoc, on-demand one-to-one and many-to-many communication which is explained in the above principle is indispensable for a true agile process, more "disciplined" planned meetings schedule is a foundational aspect too.
If the team uses scrum-like framework, their typical meetings schedule include:

• Sprint planning session
• Daily Scrum meeting
• Mid-Sprint meeting
• Sprint Review (Demo)
• Sprint Retrospective
• Backlog Grooming

Daily Scrum meeting is definitely the most important communication instrument here though other are also key and quite indispensable meetings too.

4. Enrich communication. Whenever possible.
There is a well-known communication richness scale, which I would present in this way:

The communication quality improves dramatically when communication gets from asynchronous into synchronous mode, it also further improves qualitatively with each "upgrade" - from chat to voice, from voice to video and then finally from video to face-to-face mode.

The idea is that every time a communication session is going to take place, those tools should be utilized which provide richest possible way of communication.
For example, typically all of scheduled meetings described in section above should be at least voice conferences, with the default option of video conference + document/screen/dashboard sharing session. Another example is ad hoc one-to-one meeting. If video conferencing is available, it should definitely be used instead of voice or chat.
As a separate comment, documenting all key decisions/findings of synchronously run meetings in emailed/"wiki-tized" meeting notes remains of course a valid and vital rule.

5. Face-2-face communication. At pivotal points and wherever possible.
This aspect has been discussed already in a previous post: no matter how effective is your distributed team setup, getting people to meet each other in person brings huge positive impact into the way team collaborates.
We've learned through our experience that out of all possible project pivotal points the most important as regarding face-2-face engagement is start of the project itself and elaboration of a new development phase - personal interaction at these points provides team with the huge positive impulse for the rest of the project/development phase.

Foundations of a distributed development success

At Cogniance, we are typically running 35+ distributed agile project teams simultaneously. While these teams have been involved in very different types of projects, their success is built on some common patterns which most of the teams use to organize their work.
We carefully study and generalize these patterns - I would call them foundations of a distributed development here in this post.
I believe these foundations span through 3 dimensions: project infrastructure, development process and participation culture.
Let us look into details of each one.

Project infrastructure
First foundation is to build unified project infrastructure to be used across all of distributed components of a project team. Wherever the team member is located, she should have access to the same project systems as the rest of the team.
As a minimal set, project infrastructure is based on the next systems:

1. Version-control system - to manage project code-base
2. Knowledge-management system - to manage project requirements, team profiles, process description and the rest of project documentation
3. Planning, task, resource and issue management system
4. Communication tools, including email, video, voice, chat and conference call systems
5. Continuous Integration and Continuous Delivery system

On a separate note, Continuous Delivery system has especially important place in enabling project success as it provides technical foundation for implementation of all of key project practices in engineering, quality assurance, configuration and infrastructure management, release and deployment domains.

Development process
Having a holistic and unified software development process for the whole project team is second foundation of a distributed team success.
This process needs to be agile and, as our experience shows, it should implement agile principles via the next key characteristics:

1. Utilize either Scrum or Kanban as a project management framework. We at Cogniance have studied carefully applications of both Scrum and Kanban approaches and we believe that either of them may be equally effective depending on project team preferences and product owner needs
2. Utilize Continuous Delivery approach as an enabler for all of project practices - as mentioned above.
3. Build a culture of Continuous Communication - which includes (but is not limited to) daily scrum team meetings,  iteration-based heartbeat sessions, different 1-to-1 and 1-to-many communication channels organized with the goal to make information flow within the project team maximally effective.

Also critically important is initial process deployment phase, based on all-hands project kick-off session - which sets project goals, introduces project team, reports on infrastructure deployment, describes development process and discusses other critical items.

Participation culture
This third key foundation of a distributed team success is, of course, about having the right people in the project.
But "right people" is a way too broad term and I believe the key soft skill ingredient for success is specifically ability of each team player to participate effectively in project activities across different time zones, geographies and cultures.
I would decompose this complex skill into the next aspects:

1. Command of English - English knowledge evidently is indispensable for any multi-national distributed team
2. Pro-activeness - this, in its broader sense, also includes accountability, ability to make decisions and implement actions self-dependently, high self-organization and self-discipline
3. Cultural awareness  - cultural differences may become a significant stumbling block on a road to project success and the best way to overcome this difficulty is to raise cultural awareness within the team, which helps mutual understanding and collaboration.

Other aspects which are in my opinion critically important in development of a "soft structure" of a distributed team are:
grow the culture, do not build it from scratch - you cannot build a culture from scratch, you can only grow culture, so getting onboard people with the right participation skills from the very start is really important
get people to meet each other in person - no matter how effective is your distributed team setup, getting people to meet each other in person brings huge positive impact into the way team collaborates. The simple rule is to meet as often as possible, more specifically, team should try to meet in person at project pivotal points like elaboration of a new development phase, product road-map discussion or yearly all-hands meeting.

Key challenges of a distributed software development

Our business at Cogniance is all about software development with distributed teams and our clients oftentimes ask us how we overcome related challenges. Before we discuss answers though, it is important to clearly understand what exactly these challenges are.

My take on the subject is that major challenges of a distributed development fall into
communication/time-zone/culture/process/infrastructure paradigm.

More in detail:

1. Communication issues
In fact, communication may be regarded as the most important and the root challenge of distributed development teams - all the rest of issues ultimately influence communication and hence collaboration quality.
Even people in different rooms typically communicate less effectively, communication between teams in different office locations gets even more challenging.

2. Time-zone differences
Time-zone differences further worsen the communication issue by narrowing down or completely eliminating time window for direct communication.

3. Cultural differences and language barriers
The world is really getting flat and people, especially in IT industry, more and more embrace some unified behavioral and cultural standards.
Still cultural differences remain a serious obstacle to building effective distributed team - as people communicate, lead, work differently in different cultures. Same story with the communication language - while English is universally accepted, level of it's adoption varies broadly and is oftentimes much less than a fluent level.

4. Process misalignments

Different development processes which are practiced by teams in different locations or conflicting interpretations of the same process create further interference with the quality of delivery.

5. Project infrastructure mess
Different version-control, knowledge-management and other project systems create the need to build work-around interfaces between these multiple systems and also add to the problems with effectiveness of distributed teams.

Distributed agile software development - continuously unleashed :)

This blog grows out of the discussion panel on distributed software development which Travis Bochenek, my colleague from Cogniance, and me led at Y2013 MassTLC conference in Boston.

The panel turned out to be really successful with lots of people joining and exchanging ideas. Given that all of the professional activities I'm involved with deal with software development through distributed agile teams the idea to share our experience and thoughts, ideas and questions via a dedicated blog seems to be really interesting.
So here it goes: distributed agile software development - continuously unleashed :).