Did Beatles use Kanban? Rikard Edgren
I have become allergic to models that are brought from other industries, and put on software testing as a best practice, or something really good.
Software testing is unique, and you might violate important aspects when applying a template that doesn’t match.
It is a big difference between producing 100,000 cars a year, and one piece of new software.
As I believe that software testing is one of the most creative professions, maybe there are other places to look for really good management methodologies?
The Beatles wrote great pop songs, and a lot of them, where they using Kanban?
Did Just-in-Time play a role for the productivity of Thomas Alva Edison?
Was Leonardo da Vinci an early adopter of Kaizen?
Were the New Wave in French Film under Lean management?
Could the String Theory emerge without Six Sigma?
You might argue that these examples are very different from software testing, and that is true.
Therefore we should manage and improve our work in ways that are suitable to what we do, and who we are.
There are no frameworks for passion.
Let’s have a look at an example:
A key element in Lean is “reduce waste”, which seems like a natural and good thing to do.
But this is very problematic in testing, because you don’t know (in advance) what is waste. And what was waste in one situation might be very important in another. It might be reasonable to identify waste in activities that are predictable, but it’s not recommendable in situations with a lot of serendipity.
Of course it can be a good match as well, but I’d prefer saying “I read some about car manufacturing, and realized that parts of our test report aren’t useful to anyone, so we will skip those parts” to “let’s adopt Lean Management to our testing process!”
It’s a good idea to be inspired from other fields, but please don’t take a whole package, and please think carefully if there are things about testing that are necessary to consider, e.g. doctors can not make mistakes, testers should make mistakes.
I’m thinking movie production might be the closest to “normal” software testing projects: it involves a lot of people, a lot of different types of creativity, is complex, and spans over quite some time. What management models are helpful in the film industry?
Does it help if movie requirements involve things like “There must be exactly 3,5 minutes of action scenes including tricycles”?
Kanban is a method that can be used in any practice where you want to visualize your team’s work in a smooth way. It has nothing to do with testing.
Kanban is about managing workflow; it is a tool for any team producing something or working on anything.
If you see someone put Kanban on software testing as a best practice, they don’t know what they are talking about…
The inspiring thing about some of the new process tools that has arisen in software production is that they are people-centric; small; and solves a specific problem. People that are used to gigantic process tools tend to think that all process tools are the same: a single solution.
That said, I do agree that we shouldn’t bring in process tools from industries just because they have been successful – in a completely different context. The thing about the Agile methods though, is that those of them that origins in the car industry, are almost the opposite of traditional processes in the car industry.
On the other hand…
I totally agree with you.
As you know, there is always a need for selling new methodologies; and there is a need for people to have a label (with description) for something in order to get some credibility to their chanting.
As much as these methods can help, they can as easily fail. And especially when it comes to methods that we bring in from industries that don’t even resemble ours.
The only true way to methodology success is when everybody involved believes in it.
On the third hand…
E.g., Lean has proven to be successful in a variety of areas. In Sweden it has recently been a small revolution by using Lean in all areas of Psychiatric Care.
The important thing is to find out what matters for each context.
Good comments.
Kanban apparently is advocated, here are two blog posts I like:
http://chrismcmahonsblog.blogspot.com/2009/07/against-kanban.html
http://xndev.blogspot.com/2009/09/have-you-heard-of-kanban.html
—“there is always a need for selling new methodologies”
This could be a key. It is extremely difficult to come up with a management model aimed specifically at software testing. It is much easier to create a version of a “successful” method from another industry; and awful lot easier to sell it.
I have more faith in models developed for the intended usage, Agile and Scrum being two examples. But for these two we must remember that they were created for software development, not software testing. Developers solve problems, testers create them. Developers have an easier time focusing on a few tasks, testers often need to keep many things active at the same time. What are the other important differences?
— “small revolution by using Lean in all areas of Psychiatric Care”
Sounds interesting. I don’t know enough about Lean and the other capital letter names I have mentioned, they might be portable and good, at least in some areas.
But for an area like psychiatric care, I think I’d want to wait for side-effects in 10 or 20 years before being sure it is good.
—“The only true way to methodology success is when everybody involved believes in it.”
Very true!
Regarding Psychiatric Care it is much about shortening the waiting time between first visit, second visit, evaluation, treatment, etc. which is enabling faster treatment and less administration; which is a benefit for the patients whose lives are dependent on getting treatment fast. (*)
I.e., it has little or nothing to do with the actual process or actions (the brain-stuff) that takes place during the visits. So hopefully the side-effects are positive…
It is similar to how you would implement Lean (or Kanban) in software development: it is a workflow framework; not development method nor testing method.
—
But for people who work with refining these methods into super-duper software development methods, it is hard not to try to include more and more in order to describe the method thoroughly and solve as many cases as possible; and it might even be the same people who have described and refined other (heavy-weight) methods before!?.
This is why I agree with you on these issues, but I also believe that if you can see through the fluff you will find methods that could be appropriate in your context.
—
Regarding ”there is always a need for selling new methodologies” I guess that many times someone sees something and then thinks “Ah, this could be applied to software testing as well. If we only change this into that we are all set!”. Then you might have a milk-cow for years to come…
—
Here are two articles that I found interesting during discussions I had last year:
http://blog.robbowley.net/2008/11/15/lean-scrum/
http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html
The main point being that if you are not committed and realizing the shortcomings you will fail regardless of which capitalized method you are using. And it would be applicable to any home-grown method as well.
—
We people tend to lean (sic!) towards methods as if they were Swiss Army knives; we need something to support us in case we fall; we need something that tells us about “the right way”; and we need someone who tells us what to do so that we can then point back to that and say “Look, I just did what they told was right”. Compare this with the different baby caring methods out there: screaming-method, nanny-method, and what have we…
But in this lies the danger. Methods cannot be universal and will not support us if we bump into a case that there is no support for. And with that many contexts that can exist it is impossible to cover all cases. This is one major reason to why there cannot be any “best practices”. Only good practices that has been promising at least once, in one context.
But I don’t want to attack the methods per se, it is the people that describe them and the people that use them that should be under attack.
—
—
(*) The waiting times in psychiatric care today is a mess; one reason being that in order to meet the political decision about minimal waiting time until first visit, they hired a lot of receptionists that registered the patients fast, then you can wait up to a year before meeting any psychiatrist or psychologist because of lacking personnel. I.e., the money is spent on registering patients, not treating them.
Do we see the opposite of those project models as no steering at all? I think all the examples you mention Rikard have had some kind of project modelling perhaps the first waterfall or something scrum-like?
I agree with you on that no method should force itself onto the way you work, instead you should fit what method fits you best at that specific situation.
I think Kanban is really interesting as a method for flexible testing teams where you work on many projects, have many different stakeholders and where your assignments change very often.
Personally I think you can work incrementally for any kind of test project, where waterfall is the nemesis of testing and test planning.
I am also fond of trying out new ways of working to see what I can pluck out of each new method.
I’d like to have a management model where the focus is on trusting the people doing the work.
Where it isn’t important that everything done is written down and fully visible, or estimated in advance, because you know they will do good things all the time (and communicate, and collaborate.)
A model that encourages having multiple tasks running simultaneously, where many of them are ongoing, long-term commitments where there is no clear start and end.
A model that allows different “task setups” for different people with different needs.
A model that aims for a better whole, not optimizing of small units.
A model where the results are more important than being able to report status, or control the flow.
Any suggestions of a suitable approach?
I think you just made one up!
—
The thing is that you should make one up that suits your context, if that is what it takes.
Sometimes it is good enough with a model/method from the books; sometimes you need a combination of a few; sometimes you need to make one up for yourself.
Or it could just as well be a combination of Kanban and Scrum?
But that depends on if you believe that it is a combination of those two capitalized methods; if you also think that it will aid you in your work, then you could settle with that or tweak those two into a combination that meet your needs.
If you doesn’t think that those two methods/models fit your need, then you could create one from scratch.
Movie production no longer feels like a good comparison.
Since it is very expensive to shoot film (people and tools) a lot of detailed planning is needed to make everyone do what they need to do at the same time.
Software testing doesn’t have the same need of synchronization, hence the need for scripts isn’t as necessary.
I’m thinking painting, creating music, teaching to some degree, is more similar.
But the best is to invent what we need for us.