Today I visited the UXDX Conf in Amsterdam.
UXDX conf is based around the UXDX model which integrates UX into the Development loop by breaking down the barriers between development, design and research teams.
When I was a kid, I was a big Bruce Lee fan. I walked around the playground rubbing my nose with my thumb. When I had a piece of rope, I had to do my version of the nunchaku routine from Way of the Dragon and made cat-like noises. Looking back at Lee, I find it quite striking how many of the principles of his fighting style Jeet Kun Do apply to agile practices.
Check out these descriptions of the fighting style:
JKD is a reactive style that responds to changes in in situations and applies the best “tool” for getting the job done in the fastest way possible in that situation. JKD does not care about styles or forms for the sake of it.
Ofcourse this philosophy resonates highly with an agile mindset.
So just for fun, here are my Top 5 Bruce Lee Agile Coaching Tips
I am frequently asked by colleagues for advice on how to be a good Scrum Master. I will discuss some of the tips I share in a couple of blog posts.
First of all I do like to state that I believe it’s best to have a Scrum Master that is able to get his hands dirty in the activities of the team (i.e. coding, analyzing, designing, testing etc.). It will enable him/her to engage and coach at more levels than just overall process.
In my opinion one of the most important things a Scrum Master has to do is to make things transparant for the whole team.
Now this seems like very simple advice, and it is. However, when you are in the middle of a sprint and all kinds of (potential) impediments are making successfully reaching the sprint goal harder and harder, the danger of losing transparency always pops up.
Here are three practical tips: Continue reading
If you have a car, then every once in a while, you probably have your vehicle checked to see if it’s still up to safety and environmental standards.
So you take your car to the garage and have it checked. Now, the garage will do some tests and eventually you’ll get a nice paper showing what kind of maintenance they have done.
Nowadays, cars are complex, computerized machines. (The days of dad lying under the car to do some fixing with some elemental tools are all but gone.) This means that as a customer, you will have to rely on the professional capabilities and integrity of the garage. You’ll have to trust that if the garage says the car is fixed and okay, it really is fixed and okay.
Now imagine that you went to the garage, received the paper that your car is okay, go on the road, and your car breaks down. What would be your reaction? You’d probably hold the garage responsible for this, as they are the experts and you paid them to do a good job. What would your reaction be if they told you that they didn’t have time to correctly solve your cars problems and did a ‘quick fix’, without them telling you?
In software development I frequently come across similar situations. Companies hire in IT solution providers, to help them solve their IT related problems and deliver high quality solutions for their business. Now software products and projects tend to be very complex and therefore, customers will, one way or another, have to rely on the professional capabilities and integrity of the solutions provider (or the solutions provider, checking the solutions provider).
How then would we label deliberate quick ‘n dirty fixes by developers, just to get the project ‘done’, leaving the customer with piles of technical debt?
It is the responsibility of solutions providers and professional developers, to point out the consequences of quick ‘n dirt fixes. A good solutions provider therefore will, out of professional honor and integrity, have the courage to point out the severe consequences and even refuse quick ‘n dirty fixes, knowing that in the end, low quality won’t pay off.
Quality isn’t negotiable and long after the ‘quick’ has been forgotten, the ‘dirty’ will probably still be there.
Most people working in professional IT-driven companies, have heard about Agile, most people in professional companies have heard about Lean. Those who are interested in the subject, have found out that these two very popular phrases are actually closely related. So what is the relation between lean and agile? I’ll try to briefly answer this question and will start with a little history.
One of the questions that Project Managers always pop up during projects is: “how many days will it take to finish this work?”.
This is a very natural and sensible question. You want to know when a project will be finished, so people can have an expectancy of the needed budget, what functionality is in it and when it will be finished.
However, answering the question is more difficult than traditionally is assumed. Continue reading