Are you at the mercy of your environment?
Consider the things that limit you the most when trying to do your work as a business analyst. They probably include at least one of the following:
- 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; 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.
- 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
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.
Kanban is iterative and incremental implying, among other things, that teams do not try to do too much too soon. We see here an application of the ‘minimum viable product’ approach.
The introduction of kanban can see the emergence of other desirable features such as co-operation between teams and the facilitation of culture change.
Kanban and agile business analysis
The business analyst is concerned with identifying problems and opportunities and then specifying the goals and requirements for a solution to those problems or the realisation of the opportunities. How often do we feel that we are pushed by others into identifying requirements and solutions before the problem have 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.
Kanban was born in a manufacturing environment which 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.
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.
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. I loved the sound of that.
I constantly stress the importance of context and of defining a project approach that is appropriate to that context. I also have a natural suspicion when people say to me, “If you do it exactly like this, all your problems will be resolved”. Similarly, I am suspicious when people say that if you don’t do a particular task in a particular way, you are bound to be wrong. Actually, when I try my hand at cooking, I do follow recipes to the letter and, in the context of cooking, the above statements are generally true; if I don’t follow the recipe exactly, the results are a disaster.
But the above statements are not true in situations that are novel and unpredictable. 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.
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.
Kanban principles
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 a kanban based system
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 ? Is the analyst able to 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 ?
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.
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 to gain their cooperation and acceptance in order to move progressively through the six steps. 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 to your business analyst role, give it a go.
