Per Lundholm

Per Lundholm

Continue reading: Assumption assistance with Impact Mapping

Assumption assistance with Impact Mapping

As a product owner, your job is to make assumptions, or hypotheses. (Hypothesis-driven product discovery, anyone?) You assume that your priorities will be the best outcome, the shortest time to market or something else. But how good are your assumption when it comes to reality? Did that sale increase occur and was it thanks to your great mind or just pure luck? Do people around you understand and help you with your assumptions? Impact mapping is a lightweight tool that helps you with quantifying and communicating your assumptions.

Continue reading

Continue reading: The three states of working agreements

The three states of working agreements

You may have read about this elsewhere, but a recent event led me to write this. I feel that the working agreements concept is not given the attention it deserves. Working agreements are about making your culture explicit. It is desirable to have them visualised on your Scrum board as a constant reminder. Question is, when do we remove them from the board so that they don’t cover the whole board? My answer is, when the third state is reached, “internalised”.

Continue reading

Continue reading: Elm for backend developers

Elm for backend developers

Before there was the concept of frontend and backend developers, there were just developers and I was one of them. We did everything from HTML to SQL and it was not hard. Then something happened, JavaScript became popular. After years of server side rendering and thin clients, the pendulum was swinging back to fat clients again. And I was a backend developer.

Believe me, I have tried to get on the train with JavaScript and its hose of new frameworks. I took courses in JavaScript. I wrote applications using Meteor, tried Angular and React. But what I never managed to do, is liking it. There is simply to many ways of shooting yourself in the foot. And all these frameworks that come and go points to something, perhaps we are trying to fix the wrong problem. I suspect it is the foundation itself, JavaScript.

Continue reading

Continue reading: Introducing the Agile Pill

Introducing the Agile Pill

Through the years we have at Crisp repeatedly been confronted with the question “How can I become Agile?”. We have checked with coaches outside Crisp and they give us the same picture. People want to become agile and they want it now. It has become obvious to us that there is a need for a quick fix. Hence the Agile Pill.

The agile pill box
The agile pill

Continue reading

Continue reading: 7 Misconceptions about TDD

7 Misconceptions about TDD

Here are some common misconceptions about TDD. I call them “myths” here, for short.

If this feels like talking to the dentists about your teeth, you are not alone. When I talk about tests sometimes people gets embarrassed about their habits, “I know you’re right but …”.

Continue reading

Continue reading: Programmer productivity: SP < PR < PP < MP

Programmer productivity: SP < PR < PP < MP

In my experience, when it comes to programming productivity, mob programming beats the rest. Of course the definition of productivity in this context is debatable and these are just my observations. Thus, it is not a proper scientific study but bear with me anyway.

I wish to compare one aspect of productivity, how we work together. I look at single programming, pull requests, pair programming and mob programming.

Continue reading

Continue reading: X-team Silos Game – getting in T-shape

X-team Silos Game – getting in T-shape

Cross functional teams are complete in expertise but not necessarily collaborative. Sometimes team members hold on to their expertise too much and the team does not perform to its potential. This Lego game illuminates the difference when members allow themselves to take on tasks outside their expertise, being so called T-shaped. Play the game to kick-start your change and create collaboration.

Playing the game.

Continue reading

Continue reading: Continuous Discovery and Validation

Continuous Discovery and Validation

Continuous discovery means an open backlog where everything is considered speculation and hypothesis. Continuous validation means that the user experience is validated for each release, rather than up front. This may sound like big budget to you, but let me give you a case study, about how a single team accomplished it on a tight budget.

A small team with a small budget has the advantage of not losing its head with big ideas from experts in different fields, be it architecture or user experience. The budget constraint sharpens your effort in a way that could be healthy even to a larger team.

Continue reading

Continue reading: User stories are not requirements

User stories are not requirements

532397504_53698473c4_m
Elephants

Elephants are not giraffes and user stories are not requirements. They share some traits and you may find them in the same context, but that does not make them the same. Despite that, many believe that user stories are the new requirements because there has to be requirements for a project, right? I give that a double “no”, they are not requirements and that is not anything we really need. User stories are about being able to explore options and seize opportunities. Requirements are about deciding up front and sticking with that.

Continue reading

Continue reading: Impact Mapping – the developer’s cut

Impact Mapping – the developer’s cut

Do you, a developer, have a feeling that the user stories your product owner is but a list of ideas prioritized on gut feeling only? That the relationship between them and their purpose are vague? Impact Mapping is an agile conversational tool by Gojko Adzic that may be primarily for product owners but hey, a developer needs a purpose too!

Continue reading

Continue reading: The Sword and the Shield

The Sword and the Shield

When refactoring legacy code, two problems seems to repeatedly occur. One is that the code is all tangled up with interdependencies and the other is that there is no specification of what the system is supposed to do.

Still we are asked to add features or fix problems without breaking anything. Everything in there should stay there.

Continue reading

Continue reading: Mocka med inhoppare – del 6 i TDD på svenska

Mocka med inhoppare – del 6 i TDD på svenska

TDD är en vana man behöver etablera. Första hindret är ofta när man återvänder efter kurs att omsätta teori i praktik. I detta avsnitt berätta jag om hur man isolerar en enhet så att man kan testa den. Del 6 är i serien “TDD på svenska” handlar alltså om detta och har precis nu publicerats

Continue reading
Continue reading: Omöjligt att kombinera agilt arbetssätt med pm3

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.

Continue reading

Continue reading: Too small for a user story – bugs, fixes and support

Too small for a user story – bugs, fixes and support

Some things are too small for the overhead of a user story, still they must be handled during the sprint effectively. I suggest a small taxonomy to classify them and also what to do with them.

Continue reading

Continue reading: 7 Rules on Code Readability

7 Rules on Code Readability

What makes good code? Many things but whatever the qualities are, readability is a cornerstone.  If you can’t read the code, you can’t fix it. So how do you write readable code? I’ll give you my view but it’s like books, what I find enjoyable may be different from you.

Continue reading

Continue reading: Snabbare programmering – del 5 i TDD på svenska

Snabbare programmering – del 5 i TDD på svenska

Borde du inte programmera snabbare? Varför tar det så lång tid att mata in kraven i datan? Har du hört den frågan förut? Del 5 är i serien “TDD på svenska” handlar alltså om detta och har precis nu publicerats på vår YouTube-kanal “Crisp Agile Academy”. Du hittar som vanligt de tidigare delarna i serien

Continue reading
Continue reading: Slides and code for one day Wicket introduction with Ajax

Slides and code for one day Wicket introduction with Ajax

At my current assignment, I needed to get my fellow developers up to speed with Wicket. So I put together a one day course that taught them enough to join in on the work of a current application. Everything is publicly available on GitHub here:  https://github.com/perty/wicket-kurs.

You get a starting plate for a complete web application with database backend accessed through Spring Data JPA. Also, there is a Power Point presentation that guides you through the exercises. Very little is spent on Wicket philosophy and concepts to the benefit of hands on coding.

Continue reading

Continue reading: Time vs Story Points Estimation

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.

Continue reading

Continue reading: “Lagom testtäckning” – Del 4 i TDD på svenska

“Lagom testtäckning” – Del 4 i TDD på svenska

Hur mycket testtäckning ska man ha? Vad är skillnaden på line coverage och branch coverage? Vad är komplex kod? Hur undviker man att få fejkade mätvärden (gaming)? Vad är “förtroende” i det här sammanhanget? Hur kan man kombinera flera mätvärden?

Det och lite till försöker jag svara på i den här videon.

Continue reading

Continue reading: Personlig träning i TDD – Del 3 i TDD på svenska

Personlig träning i TDD – Del 3 i TDD på svenska

Testdriven utveckling, TDD, är en vana och för att skaffa sig en vana, behöver man träna. I den här videon gör jag en rolig övning i att bryta ner ett tal i primtal. Jag vill också trycka på att du ska träna dig att använda utvecklingsmiljön genom att skriva koden “baklänges”, använd en variabel och

Continue reading
Continue reading: Red, Green, Refactor – Del 2 i TDD på svenska

Red, Green, Refactor – Del 2 i TDD på svenska

Den andra delen handlar om TDD-processen. Se alla våra video på YouTube-kanalen Crisp Agile Academy.

Continue reading
Continue reading: Varför TDD? Del 1 i TDD på svenska

Varför TDD? Del 1 i TDD på svenska

Den första delen om TDD på svenska på Crisp Agile Academy är en motivering om varför det lönar sig med TDD. Jag funderar över vad som händer om man inte skriver tester alls, skriver dem efteråt eller skriver dem innan. Den här serien är tänkt att bestå av korta avsnitt där något inom TDD gås

Continue reading
Continue reading: Another builder pattern for Java

Another builder pattern for Java

Whenever you have a domain object, data transfer object, parameter object or any other object that can’t be instantiated with constructor parameters only, you need to create a builder for its class.

The great thing about Java is that it is statically typed so a builder can give you compiler errors if you forget to set the compulsory parameters. If you use the builder in this pattern, you also get a very fluent interface that imposes order on the parameters. When using the builder, your IDE will suggest the next parameter to set.

Continue reading

Continue reading: Schema migration, an important part of continuous delivery

Schema migration, an important part of continuous delivery

Most of you have a relational database involved in your persistence. As soon as your first version has been set in use, you can’t change the database schema as easy anymore or you might lose valuable production data.

At the same time, continuous delivery demands that there should be as few manual steps as possible. See here for motivation on continuous delivery.

You no longer have a few database instance, there are numerous for different levels of testing and every developer nowadays run a personal database. To keep track of all database instances and keep them updated becomes a steep task.

To tackle this, we started using Flyway as a tool to manage our database scripts. Our applications migrates the database automatically on startup so we get a hands-free solution that will guarantee that the code and database schema is in sync.

Here is a technical recipe for accomplishing this when using Flyway in combination with Spring.
Continue reading

Continue reading: Bragging: 100% coverage, specification by example and pair programming

Bragging: 100% coverage, specification by example and pair programming

Yesterday we ended our second two-week sprint and on the demo, besides showing the system, we could do some bragging about test coverage using our Sonar dashboard.  We also could show Fitnesse tests at system level that implements the specification by example technique, or like some say, executable requirements.

Continue reading

Continue reading: The proper use of @Ignore in unit testing

The proper use of @Ignore in unit testing

What is the purpose of the @Ignore annotation in unit testing?

Either a test will be green and everything is fine or it is red so you fix it before commit. So if there is an ignored test, it is the same thing as dead code and we know what to do with that: delete it! Keep the code clean!Continue reading

Continue reading: Retrospective using Jimmy Cards

Retrospective using Jimmy Cards

I had taken on to facilitate a retrospective for my colleagues’ team. They wanted a different retrospective than the usual. So we borrowed Crisp’s office and used Jimmy Cards!

The group was around 15 persons from two teams. They all knew each other well which I believe is crucial as the questions on the cards can be challenging.

In this post I’ll give you the recipe which Jimmy and I came up with for this particular retrospective.

Continue reading

Continue reading: Why do we never get the time to work on system architecture?

Why do we never get the time to work on system architecture?

Have not all of us been in a spot where we feel an urgent need to fix some quality such as performance or availability, which takes a change in the architecture for effect? And yet we are pushed to work on new features instead?

There is a chasm between the tech side and business side that has to be bridged before a sound dialogue about system architecture can take place.

Continue reading

Continue reading: Canned Wicket Examples Updated to Wicket 6

Canned Wicket Examples Updated to Wicket 6

Today I decided to update my canned wicket test examples to the latest version of Wicket.

I still think Wicket is a really nice web framework for the following reasons, primarly.

  1. Hot deploy from the Maven archetype. The quick start setup offered from the Wicket site gives you “change-and-reload” out of the box.
  2. Unit testing framework built in. You test the logic of the web application without resorting to click simulation.
  3. HTML separation. Allows you to work in a tight loop with an interaction designer that can use any HTML editor.
  4. No need for JavaScript. Well, for the basic stuff at least. The examples here all use AJAX.
Continue reading: Using CloudBees for teaching XP practices

Using CloudBees for teaching XP practices

We are doing a course called “Certified Scrum Developer”.  We are of course proud of being one of the few eligible by the Scrum Alliance to hold such a course. But what matters most to us is teaching some modern development practices. The certificate bit is more of a bonus.

Crisp had recently its fifth installment of a code camp, the “Crisp Hack Summit”. It is an occasion for everyone at Crisp to go bananas on some project of their liking. We took the chance to work on the technical platform for the CSD course.  We know from experience that you can loose a lot of valuable lecture time if  the technical environment decides to hassle. Murphy, will you be there?

Continue reading