Mikael Brodd

Mikael Brodd

Actually developing software

Bimodal IT is not the goal

In 2014 Gartner introduced bimodal IT. Since then quite a lot has been written and said about it. And just recently it popped up at two different clients almost simultaneously. After reading articles, watching webinars and listening to what people say about it, I’m a bit worried that organizations think Bimodal IT is the goal. I don’t think so, and I’ll explain why.
read more »

Scaling Agile (but not in the way you think…)

For more than a year now, I’ve been working with clients that have agile scaling problems. But not the kind of scaling problem everybody is talking about – one product and lots of teams. No, I’ve been busy trying to sort out what to do when you have one team supporting a multitude of products with different architectures, stakeholders, technology stacks and whatnot. This is what I’ve learnt, so far.

read more »

Slides från session Agila Arbetsmetoder @ SAST Q20


Otroligt kul att se hur många som fick plats i ett konceptrum i Aula Magna under våra presentationer under SAST Q20! Vi pratade först om kontinuerlig förbättring och sedan om working agreements. Slides hittar du nedan.

På Crisp har vi en hel del gratis material och guider, bland annat en Toyota Kata mall, som Martin nämnde under sin presentation.

Vi pratade också om Mobprogrammering, och den främsta källan till information finns på mobprogramming.com.

Tack till er alla som kom och lyssnade och vi ber om ursäkt för att alla inte fick plats.

/Martin & Mikael


Omöjligt att kombinera agilt arbetssätt med pm3

Låt oss säga det direkt: att kombinera pm³ och någon agil metod, som t ex Scrum, är en dålig idé. Varför?

Därför att du kommer inte kunna dra nytta av det agila arbetssättet. pm³ är baserat på en helt annan världsbild. pm³ bygger på årsplaner och att verksamheten beställer från en leverantör, typiskt den egna IT-avdelningen.  Agilt har som en grundläggande värdering att reagera på förändringar i stället för att följa en plan. Det agila arbetssättet drivs proaktivt genom utforskande i motsats till att vara en mottagare av beställningar.

Vi har sett flera försök att implementera pm³ och de har ofta misslyckats på grund av att pm³ bygger på tankar om att verkligheten kan förutsägas 18 månader i förväg, att användarna vet vad de vill ha och att det är viktigt att ha en skarp linje mellan verksamhet och IT. Vi hävdar (och flera med oss törs vi lova) att inget av detta är varken sant eller bra.

read more »

Agile Maintenance

Traditionally IT-systems and products are developed in a project. Once developed, it is deployed and handed off to the maintenance organisation. But the new companies that start out with an agile way of working does not have these maintenance organisations. How do they do it? Is there no Maintenance in Agile?

read more »

Time vs Story Points Estimation

One of the most common questions we get is whether to estimate in time or points. It seems like points are used only “to avoid thinking about time” and they are essentially the same. Wrong.

Let us give you the travel metaphor to give you an idea about how we are thinking.

read more »

Det är inte bara din ScrumMaster som behöver förstå vad “agile” är!

Återigen har ni diskussionen om “working software over comprehensive documentation” verkligen betyder att man inte behöver dokumentera någonting alls. Eller diskussionen om det är ok att förlänga sprinten med några dagar för att hinna klart den sista fixen på den där storyn. Eller diskussionen om vad det egentligen innebär att vara “lean”. Känner du igen dig? Kan det vara så att alla har nytta av att ha samma grundförståelse av centrala begrepp i och runt “agile”? Läs vidare för ett enkelt sätt att skaffa den kunskapen! read more »

Slacker? No, hacker!

Last friday, I had the day off. Again.


Yes, there were some code!

This was just one of several days that I have had off, not counting weekends and vacations. So am I just a slacker that don’t work 5 five days a week? No, on the contrary! This makes me a better programmer. How? Read on.

read more »

Still not automating tests? Here’s why you should (again)!

The other day I read a blog by Uncle Bob. It more or less stated that no matter what situation you are in, writing automated tests will make you go faster. Ok, this is old news I thought, until I checked Uncle Bob’s tweets. A fair amount of people argued against this statement, and that surprised me!


Join me at the campfire!

So I started thinking about why there still are fellow software developers that doesn’t believe in automated testing? Have they not seen them in action and understood what they are for? Please, gather around the campfire, and I will tell you one, just one, of my war stories, and then I will tell you why also you should write automated tests!

read more »

Is your software architecture explicit?

You know, every system has a software architecture and a software design. Whether you think about your system’s architecture or not, it will have one.

Here is an example of two methods in a class I recently saw. It is not architecture, it is good old OOD, but it exemplifies what can happen if you do not think before you code.

protected String getSystemArg(final String key) {
  return parameters.get(ARG_PREFIX + key);

public Map<String, String> getSystemArgs() {
  final Map<String, String> map = new HashMap<String, String>();
  for (final Map.Entry<String, String> e : getParameterMap().entrySet()) {
    if (e.getKey().startsWith(ARG_PREFIX)) {
      final String newKey = e.getKey().substring(ARG_PREFIX.length());
      map.put(newKey, e.getValue());
  return map;

Both methods in the class handles the same parameter map. The first method returns a “SystemArg” for a specific key from the parameter map. The same parameter map that the second method in some obscure way gives you in total (but with keys without the ARG_PREFIX).
The first method is protected. The second is public. Which one would you have used if you have a key for which you want a “SystemArg”? Which one would you like to use?
This is an example of what you get if you do not think about your design. A public interface of a class that blatantly shows the inner workings, and a protected interface that is what should have been the public one in the first place.

To me, an explicit architecture is visible. All team members knows about it, i.e. it is well communicated. To make such an architecture you need to be aware of the decisions you make and why. This means that the team(s) need to have discussions, perhaps draw some interaction diagrams on a white board, maybe make a domain model and whatnot. Just do something. Anything is better than nothing.

White board area next to Sprint Backlog

White board area next to Sprint Backlog

Example of explicit architecture

Example of explicit architecture.

Agile does not prohibit you from doing design or architecture. It certainly does not prohibit you from using your brain. It only states that you shouldn’t do it all upfront, but rather evolve it over time, just as your requirements evolve. So please, think about your architecture and make it explicit. Because if you get an implicit architecture, you will be knee-deep in technical debt and then you will call me to come and fix it…

(My) top 3 RUP anti-patterns

I am first and foremost an agile guy. I try to be as agile as possible at my assignments, and I coach and teach agile ways. But I know that there still are several companies that use RUP, and this is written for them.
As I argued in my previous blog post, you can do RUP and be agile. In this blog post, I will give you my top 3 RUP anti-patterns that I have experienced at various projects, and often enough the solution to them is to work in a more iterative way as the creators of RUP intended (more agile if you like). If you want to know what you can do about them, read on. If you can top them, please share your experiences with me 🙂

RUP, a hideous beast, or…?

Having mentioned the acronym “RUP” at Crisp a couple of times, I am starting to get a better understanding of how Harry Potter felt when he mentioned the name “Voldemort” (if you don’t know who Harry Potter is, just borrow the book from the nearest 13-year old and read it). What is it about RUP that has made agilistas scream in terror whenever mentioned? Is RUP a hideous beast that no one can work with, or is it actually a trainable pet that can be useful when treated right?

read more »

The story of the little boy and the Big Plan

This is actually a true story that I am about to tell you. I heard it from a friend talking about his childhood a couple of weeks ago. When I listened to him, I could immediately compare it to many of the software projects I have seen.

read more »