Tag Archives: performance

Fluent@agile – visualizing your way of working

Posted on by

Help your team improve by visualizing their way working with the fluent@agile game. With the game you can help a team find out where it is on its agile journey and help it find new ways of both fine tuning and make leaps in their daily agile practices.

Fluent@agile board

A teams fluent@agile board.

Me and Christian Vikström made the game together at Spotify during the spring 2014 when we were coaching and helping team to improve their agile skill sets and processes.

At Spotify the teams owns their own way of working. A team is basically only accountable to itself. We therefore needed an coaching tool that could help team take ownership of their self image and improvement strategy.

We also wanted the tool to be opinionated. It should be normative, tell what’s good and not, what kind of practices and behaviour that’s expected and not. But at the same time it should be open to new ideas, new practices and the teams local conditions.

read more »

Size matters, why and how to measure your heap

Posted on by

I have had to deal with memory problems in Java applications a few times. A lot has been written about this already, but this time I ran into a slightly different issue that surprised some of my colleagues so I decided to write about it here. Contrary to popular belief, a big JVM heap size is not always better when it comes to performance.

The problem

I came to the customer site to help them with their performance problems of a fairly large J2EE-system Web Service/Hibernate/MySQL system. They had several customers running the system, but only the largest was experiencing problems. The application suddenly froze and stopped processing transactions. All sorts of hypotheses were discussed, but no one could really for sure say what the problem was. And there was little data to work on.

read more »

Stop using differentiated salaries

Posted on by

Most companies today uses differentiated salaries for their employees. This is something that is in general considered to be the way it must be; the companies needs the system in order to attract and keep talent employees to secure future profits for the business. This was also my belief until a few years ago; I thought that companies should pay more to the ones that produce more value to the business. Even if I saw cases where I thought people got too big salary increases and others too low at the annual salary review, I believed that in the long run the salaries would reflect the true values of each employee.

But during the last few years I have started to think differently. I do not believe in differentiated salaries any more, at least not for knowledge work like product development. There is too much evidence that the system you need to have in order to enable salary reviews each year, is impeding the progress of the business and lowers its result and profit. Knowledge work is based around motivated employees that have the support and environment they need to be creative during their daily work. Appraisals system, which is needed to implement differentiated salaries, is demotivating for the employees instead, and is therefore working against the high performance of the organization. Also, differentiated salaries is created under the belief that it is external motivations that drive people to be high performers, but as Pink describes in his book, Drive, it is autonomy, mastery and purpose that motivates people, i.e. intrinsic aspects instead.

This is also like Dr. Deming says in his book Out of the Crisis:

Evaluation of performance, merit rating, or annual review… The idea of a merit rating is alluring. the sound of the words captivates the imagination: pay for what you get; get what you pay for; motivate people to do their best, for their own good. The effect is exactly the opposite of what the words promise

My own experiencealign to this as well, both as an employee and as a manager, where I personally have witnessed the negative effect the system has had on its people and the company.

read more »

Why we are better off monitor our queues

Posted on by

The other (not so obvious!) way is to look at the size of the queue in front of the process. Because if we know the work time and queue size, we can derive the rest.

Cycle time measurement

Apart from this, the queue can tell us a lot more which cycle time necessary don’t:

  • If we have a bottleneck our system
  • Disruptive flows such as bursts in arrival of work

The queues are simple easy visual ways of learning us about variance in our system. And variance eats predictability for breakfast.

The same fact is actually mathimatically demonstrated in Little’s Law:

Little's law

Number of things in process = sum of items in queue and process. So by eliminating the queues we get a faster cycle time.

Thus,

  • cycle time is a trailing indicator
  • queue utilization is a leading indicator

Unfortunately, we very seldom in monitor the latter!