Categories
Uncategorized

What I do

The type of work I currently do

WordPress Backend / PHP

Some of the things I’ve done in the past

HTML / CSS / JavaScript
jQuery / AngularJS

PHP / mySQL
WordPress

C#.NET / ASP.NET / SQL Server
EPi Server

Categories
Thoughts

“We have a problem with …”

Often times I hear people say “We have a problem with _ in our organisation”.
Which is perfectly normal. No organisation is without fault. Circumstances change and the world evolves. New perspectives are introduced.
How people approach this seems to differ a lot.
Several great thinkers about this seemed (and seem) very determined that it is crucial to understand that the results, problems and behaviours your organisation currently produces is a direct consequence of the way your organisation is currently set up.

Your organisation is perfectly set up to produce the results you are getting.

If you have a lot of bugs in the things you make. Well, sorry, your organisation is currently perfect set up to produce bugs.

This of course is influenced by the context. No organisation lives in isolation. What happens outside influences the inside. However the pontential to handle all this in a better manner is there. It’s shown in the variation of how similar type of organisations handle the same type of events differently, and get different results.
Using external factors as a scapegoat for your inability to achieve something is very comforting.
Like l’ve heard people say: “It’s hard to recruit in this city/field”. It might be, absolutely. Do you stop at that? Or do you look at what others are doing? How they are doing it? Perhaps you’re just making boring stuff that doesn’t spark joy and that’s why few are attracted to your organisation?

Categories
Thoughts

SCRUM and problems with team performance

A while back I had an interesting discussion with a friend of mine. He works as a software developer, team lead actually. His team was using Scrum and most of the team members had been using Scrum for several years.

Him: “Guess what happened at work! My team didn’t finish a single item”.
Me: “What do you mean? For an entire sprint?”
Him: “Yep, two weeks and at the end we had to move every single item over to the next sprint”.
Me: “Wow! That doesn’t sound like fun”
Him: “You bet, the product owner was just sitting in his chair. My team morale is way down. Never fun to disappoint other people, and frankly I think some of my team members felt worthless because of this”.
Me: “So what did you do?”
Him: “We increased the next sprint from two weeks to three weeks thinking that would mean less overhead and give us more time to finish stuff.”

This is obviously not a fun place to be in, not delivering anything after two weeks work.
No value delivered.
The business people were slightly disappointed.
Team morale was way down.
It is also extreme. This is the only case I’ve encountered where a team of several people hadn’t accomplished anything of what they had set out to do two weeks prior. I’ve seen teams not finish part of sprint backlog, but never like this. It’s not like they were slacking of either. Every member had put in long hours and were pulling their hair out.

Seeing symptoms and from that finding the root cause is complex and not an easy task. Most often there are several factors involved and some are out of your control. For now I’m going to focus on how one would approach a problem like this. My friend’s team was thinking that less overhead of sprint planning, preparing demo, doing a demo and retrospective would give the team more time and energy to focus on the actual items. That sounds logical and can sometimes be the case. However to me that way of thinking is more in line with “traditional” management than an agile approach. My take is that, the more you are struggling the more you should reflect on why you are struggling.
The whole construction that Scrum is based on is to regularly make the entire team think about how they do things. Reflecting on how things are done, is the key to progress and improvement.

Reflecting on how things are done, is the key to progress and improvement.

The retrospective in Scrum (and the like) is there to give the team time to connect the dots from struggle to the problems and going deep enough to finding the root cause. In a team that is struggling as much as my friends I’m arguing there needs to be more of this reflection and especially more often. Shorter sprints would naturally make them do that more often by having a retrospective more often. With a shorter sprint they would also be forced to focus on fewer items and then reflect on how that went. That is the true spirit of Kaizen.
I don’t know about you but if I’m both thinking about what to make for dinner and how I should tackle that leaking roof. I’ll most likely end up ordering pizza and fixing the roof with elaborate use of duct tape and anything else I could find laying around.

This was a very narrow scenario and question. The perfect system doesn’t exist, and likewise is Scrum a process with it’s own drawbacks. However when you use a method or process there is a lot to be gained from understanding the principles it was built on and how the different parts interplay.