This article on Kanban for agile business analysis looks at things that can frustrate a business analyst. It then explains how Kanban might help to make things better.

Estimated reading time: 9 minutes

Things that frustrate business analysts

The following list includes the things that may limit and frustrate you the most when doing your job as a business analyst. 

• Being overloaded with work
• Lack of a clear idea about what you are supposed to be achieving
• Constantly needing to switch between tasks
• Being slowed down by bottlenecks in the process
• Working to estimates made by ‘someone in management’ who has no direct link to the process
• Working to frequently changing priorities imposed by the person or group with the loudest voice and the greatest clout
• Reactive (crisis) management
• Lack of cooperation among teams
• Resistance to change

You perhaps feel that you are subject to control by people whose management philosophy is based on the premise that nothing is impossible to the person who does not have to it themselves.  You may also feel that you work in an environment where the normal laws of physics are suspended so that sound travels faster than light.

Can Kanban make your life better?

In 2010, David Anderson wrote a book entitled, ‘Kanban’.

Kanban seemed to offer a solution that could help resolve the sort of issues mentioned above.

I do not intend to try to give a full description of kanban in this short article.  There are plenty of books and articles available. In considering using Kanban for agile business analysis, you might start by reading David Anderson’s.  However, for those who are not familiar with kanban, here is a list of some of its characteristic features.

Characteristics of Kanban

• Limits work in progress (WIP)
• Participants at any particular step in a process ‘signal’ when they are ready to accept more work; it’s a ‘pull’ rather than a ‘push’ model
• Emphasises visualisation and transparency
• Incremental and iterative. (evolutionary and incremental)
• Helps to produce a sustainable pace of work
• Fundamental to continuous improvement
• Starts from where you are now and seeks to improve things

Kanban is a ‘pull model’ for product development

The Kanban approach is to ‘pull’ work on request. ‘Pushing’ work from one step to the next can cause the recipients of that work to become overloaded.  Furthermore, each step in a process has defined limits for the quantity of work in progress that it can handle at any one time; the team involved in that step will not allow those limits to be exceeded and only they can say when they are ready to accept more work.  This has the effect of creating a sustainable pace of work, without exhausting the team members.

Perhaps counter intuitively, limiting the work in progress can increase the overall throughput.  Consider, for example, what is sometimes called the ‘motorway effect’ on major roads.  Traffic is snarled up and just as you are thinking that there must be dreadful accident ahead, the traffic suddenly clears for no apparent reason – there was no accident or other obstruction.  Such bottlenecks typically result from the sheer volume of traffic. The effect is defined mathematically in queuing theory.

When using Kanban for business analysis, it’s the analysts who decide when they are ready to accept more work.

Iterative and incremental

Kanban is iterative and incremental implying, among other things, that teams should not try to do too much too soon.  This is an application of the ‘minimum viable product’ approach.

Scrum is also iterative and incremental, but its a ‘push’ model. Whether you’re ready or not, work is pushed down the line to you. This can be overwhelming. It can also result in slowing progress.

The introduction of Kanban can encourage other desirable work practices, such as cooperation between teams and the facilitation of culture change in the development environment.

Kanban for agile business analysis

Business analysts identify problems and opportunities and then specify the goals and requirements for a solution.  But how often do we feel pushed by others into identifying requirements and solutions before the problem has been properly understood?

In a process based on kanban we are saying that the analysts will not request the next task until they have determined what the problem is, obtained general agreement on the business goals and priorities for a solution and then discovered the requirements for that solution.  This sounds good. Of course, the analyst must not abuse the system by causing the old problem of paralysis by analysis. Transparency and visibility of the process should prevent that undesirable situation.

To properly determine the nature of problems and obtain common agreement as to what the problems are, requires the cooperation of a number of parties.  Similarly, to get common agreement on goals for a solution requires cooperation between concerned stakeholders.  Such cooperation is a feature of kanban.  The insistence on visualisation and transparency demands that concerned parties work together.  When parties cooperate in an open manner, it is easier to highlight differences of opinion and to negotiate a common vision and approach for the way forward.  Visibility and transparency help to prevent disembodied voices in the background from adversely impacting the process.

Is Kanban really the answer?

At a thought provoking talk I attended a while ago, the speaker, a highly experienced agile consultant, said that the examples in Anderson’s book spoke about software maintenance rather than software development and were not relevant to the latter.  He also claimed that Kanban was not the thing that was going to prevent more catastrophic software failures from occurring in the future.  For the record, the Speaker also said that Scrum was not going to help in that regard either.

Characteristics of software development

Kanban was born in a manufacturing environment that is concerned with processes that have predictable steps.  Software maintenance can perhaps be similarly categorised.  But software development concerns innovation, novelty and unpredictability, all in the name of seeking business advantage.  Actually, Anderson’s examples from Microsoft did concern software development, but let’s leave that aside for the moment.

Kanban as a catalyst

When I first read Anderson’s book, the thing that intrigued me the most was not so much whether or not kanban was directly relevant to the process of developing novel software, but that it appeared to be the catalyst for many emergent features. These features might possibly be surprising or counter intuitive, but at least some of them could lead to the development of an environment that would support software development whatever process was actually used.

Home grown processes

Anderson went on to say that Kanban supported, and even encouraged, teams to develop their own processes according to the context in which the teams were working.  He predicted that kanban, properly understood and applied, could lead to the demise of one size suits all processes along with any schemes that promote them.  Sounds great.

I constantly stress the importance of context and defining a project approach appropriate to that context. Business analysts should have a natural suspicion of people who make claims like, “If you do it exactly like this, all your problems will be resolved”.

Similarly, they should be suspicious when people say that if you don’t do a particular task in a particular way, you are bound to be wrong.

Such rigid approaches do not work in situations that are novel and unpredictable, the so called, ‘VUCA’ environments. I once provided consultancy to a very large project on which I was asked to extend their methodology to cover every conceivable situation – a job for life that could never be achieved.

Experts who understand why the rules are there also know how and when to break them

The main reason I take the above mentioned approach to cooking is because I am not an expert chef; these guys make their own rules, but only after developing a profound understanding of the basics. Software experts ought to be able to the same. Professional developers, should be able to tailor approaches to specific situations and contexts. They should not do things just to comply with a particular statement in the agile manifesto, for example.

Context is affected by both hard and soft factors such as the business goals, strategic importance, culture, risks, budget, the project scope, the project team, the processes, data and business rules that impact the project, etc.  Kanban gives people permission to be non conformist. This is not done for the sake of non conformity but to match their process to their situation.  Kanban therefore encourages diversity, even between teams in the same organisation.

Principles for using Kanban in business analysis

To be able to define a process that is appropriate to any given context, it is important to have an agreed set of principles rather than a recipe.  This allows teams to develop context dependent processes whilst maintaining a core of common understanding and agreement.

The business analyst is, or should be, involved in the project from the outset. They are therefore in the right place at the right time to affect how the project should proceed. They are natural partners of project managers, product managers and product owners.  If all of these groups, plus representatives from architecture, design, development and testing share a set of commonly understood principles, they are well placed to cooperatively define context dependent processes.

Anderson describes a set of principles, or properties, that kanban uses to cause the emergence of lean behaviours in organisations :

• visualise workflow
• limit work in progress
• measure and manage flow
• make process policies explicit
• use models to recognise improvement opportunities.

Anderson goes on to define  ‘6 Steps for success’ which he unfortunately calls a recipe.

• focus on quality
• reduce work in progress
• deliver often
• balance demand against throughput
• prioritise (a responsibility of the business, not IT)
• attack sources of variability to improve predictability

Moving from top to bottom down the list, we go from things that can be done independently of other groups to things that require cooperation with other groups.

Implementing Kanban for agile business analysis

The business analyst should concentrate first and foremost on the quality of their work.  Do they have the right skills for the job and are those skills honed to perfection? 

• Is there a Business Analysis Centre of Excellence within the group? 
• Can the analyst quickly and consistently identify the business problem, place it in the context of business goals and strategies and define the optimum approach to a resolution of the problem? 
• Is the analyst capable of skilfully managing negotiations, presenting their viewpoints, and defending those viewpoints logically and rationally, whilst also taking on board the viewpoints of the whole team?

Working at a sustainable pace with Kanban in business analysis

If you, the business analyst, are trying to reduce your work in progress, it is essential to be able to calculate the amount of work you can handle at any one time in order to maintain a sustainable pace.  It is your skill as an analyst that enables you to do that work as quickly as possible, whilst maintaining quality and satisfying the demands of the business.  You are seeking to prove that limiting work in progress will result in increased throughput with higher quality and therefore higher business value.

Going viral

You are also seeking to identify bottlenecks in the process and to remove them one by one.  These effects will be reinforced by increasing collaboration and developing more effective relationships between groups.  You are seeking to achieve the viral spread of these practises across the organisation.  This may take time.  Eventually, you are also looking to see a better work life balance for you and your fellow team members.

Marketing yourself as an agile business analyst

As an agile business analyst, you should ensure that the quality of your work is recognised both within the business and within the development teams.  As your reputation as an analyst increases, you are more likely to be able to influence other stakeholders and gain their cooperation and acceptance.  Anderson has demonstrated that this is an effective approach to reducing resistance to change. As an analyst, and therefore an agent of change, this is worth taking on board. If you think there is a way of applying Kanban for business analysis give it a go.