Crisp's BlogPage 23

There’s a lot that could be said about metrics. I’m quite skeptical in general in the value metrics gives you in product development or running a department/organization. At the same time I feel that metrics could help you understand the health and status of your group/organization or project, and to know the effects the changes you implement have on the performance. During the years I have used a lot of different software metrics, both targeting the product development performance and the code and design quality. Most of them have been quite complex, and they have in reality given me little value or understanding of how things really are working.

But I have also used a few ones that I feel has helped me see things during product development, metrics that says something about the performance and also direct you to possible improvement areas. Below I briefly describe a few ones that I like.

• The happiness and stress indexes tells you about the health of the team
• The code duplication and test coverage tells you about the health of the code base
• The release burn down and lead time tells you about the health of the project goal

Continue reading

I had a conversation with some of my colleagues about what makes a good daily stand-up, here are some properties: Time-boxed (15 minutes) Everyone is engaged Synchronization is taking place Attention to problems People ask for help The conversation is about stuff that matters to most people, individual issues are postponed Anyone can lead the

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?

Continue reading

The team has its Scrum board as an information radiator. It is an excellent way of getting an overview of the sprint. But what about us, the product owners, don’t we need that too? Of course we do, we too have a need for an overview of our work and to radiate information. The stakeholders pass by and ask “what’s in next sprint”, “when will we migrate”. We’d like to just answer with a light gesture towards the wall. It is all there for everyone to see.

Let me tell you how our project owner board works, as an example.Continue reading

I have just finished reading a neat little book about functional programming for Java developers by Dean Wampler. The book is only sixty pages long so it’s a really fast reading. This is a book for Java programmers and others working in the object oriented paradigm that haven’t read about or done any functional programming before. If that fits you then this book may be a good choice to read. Otherwise, I recommend that you seek more advanced and in-depth books in the subject instead. But this text will not be a review of the book. I will instead comment on the use of the functional structure and its paradigm in languages like Java that is not designed for it.

Continue reading

I like travelling. But I don’t like being away from my family. So I decided to go on a Big Family Trip! And, happily, my family decided to join 🙂 We call it the Big Family Trip because we’re a Big Family (me & Sophia and Dave 8, Jenny 6, Emma 3, Peter 1), and because

I attended the Optimera STHLM conference this spring where SSL was a recurring theme. The speakers convincingly argued for more extensive use of SSL in websites. Consider that without SSL anyone can see what you read online, what you look at and what your interests are… I was pretty confident after the conference about setting up a website with SSL, and I got the chance to test it out soon after. In the process I discovered that sometimes it’s a bit tough to find information when you have a problem with the implementation, or when you want to learn more. So here’s a how-to guide with what I learned and links to the resources I used most. Maybe it’ll help you, and hopefully you can give me some feedback 🙂

So let’s get started!
Continue reading

Estimation of the effort to implement and deliver a set of functionality is an important but not always the most fun part of product development. Estimations are done at different detail levels during the project, for example the high level story estimation and the low level task estimation. It is a few years since I did task estimation; many times it is a waste of time doing low level estimations, so in the following text I will describe a technique that I like when estimating the user stories.

Continue reading

It turns out that I’ve gotten completely side tracked…or maybe not side tracked per se, but at least not completely focused on the client side of the Application. The past couple of weeks I’ve been engulfed in Node. Trying to figure out what it is, what I can do with it and obviously how I can test drive it. I found nodeunit which seemed to be a good testing framework candidate.

Continue reading

Hi! Just back from Devcon11 where I presented on techniques to improve flow. There is plenty to say here so had to limit the material in some way. Hope to come back to this subject again in the future. Anyway, here are the slides

After several years of running our blog on Pebble we’ve made the move to WordPress, and it’s pretty exciting! But how did we get here? It turns out that migrating a blog from an unsupported platform is not very difficult, all you need is a bit of programming know-how and in a couple of hours you’ll be migrated!

Pebble stores all of its data in XML files on the server, WordPress data can be imported from WordPress eXtended RSS format. XML to XML pretty straightforward, you just need to pick a language! I figured I would try out Groovy since it seemed to offer some nice api’s for processing and producing XML.
Continue reading

As I mentioned in my previous entry, the goal of my sabbatical is to build a JavaScript Application. Notice the emphasis is on Application. That is, I don’t intend to build a JavaEE web application with plenty of JavaScript. The goal is to build an Application in the browser. It will probably (eventually), communicate with a server side component for persistent storage and synchronization but for now, that’s secondary.
Continue reading

It is important to have members with excellent technical skills in most agile projects to succeed deliver desired customer value. But even more important is that the members have great collaborative and communication skills. Without the ability to collaborate efficiently the team will have a tough time to succeed with the project. The soft part of product development includes both how the members act against each other, but also how good they all are in introspectiveness and adaptability. They need this to be able to mature as a team compared to just being a bunch of individuals acting under a common project hat.

There are many ways you can improve your ability to inspect your own behavior and adapt and change it accordingly. Working together with others and asking them to give you feedback is one great way of improving yourselves. Last year I found, a bit surprisingly, another way of improving my skills in collaboration and team work; I took on a personal sport challenge with the goal to perform a race one year ahead. This challenge has learned me a lot about myself and has also improved my collaboration skills.

Continue reading

What makes a group of good people a great team? I believe that shared values and experiences are fundamental. While there are many team-building activities available, such as paint ball and boule, I’d like to think that software development teams need more than that.

Continue reading

I’ve been thinking lately about the effects of transparency and information on decision making. After observing situations like:

• Teams flooded with report requests
• Costly measurements requests, but without explanation of why they are requested
• Holding back decisions in wait for complete information (even though just enough information seems to be present)

I’ve have wondered if more information can actually delay your decision making and what is really required to make correct decisions.

In short: More options can actually impair your decision making (more likely for inexperienced people). Experienced people are more likely to make the right decisions even in situations with incomplete information.

Continue reading

It has finally started. My sabbatical. In April I decided that I needed some time to step back and try some things my own way. I told my current client that in Q3, I would not be available. A lot of Q3 has passed but, as of this Monday, summer in Sweden is over and our two daughters are back at school and daycare which means I can actually start. 🙂

Continue reading

When I started to work as a freshly graduated computer scientist in the mid-nineties I was immediately assigned to a project programming C++. I certainly did my best to implement the functionality with the best quality I could manage to produce, but when thinking back to it, it is no surprise that the result was not very good, the code was actually quite bad. This was pre-XP and Agile time; pair-programming was not widely used and in the first couple of projects we didn’t even code review our code before delivery. Luckily I read a lot of books and articles and studied code examples written by gurus in the field, and after a while I got a good feeling of how to organize and designing the code in order to make it maintainable. What I really would have liked to have during this time was guidance from an experienced programmer helping me to improve my coding skills. 

I’m a big fan of the software craftsmanship movement; software development is a craft and you need to practice continuously in order to deliver quality software and customer value. I see myself as a journeyman who steadily is gaining new knowledge and experience in how to implement software. I read a lot to get new input and I practice my coding skills as much as possible beside my ordinary programming assignments. So in the spirit of craftsmanship I would like to give an apprentice, someone new in the profession, some guidance that I myself would have loved getting during my first year as a software developer.

Continue reading

The concept of retrospectives is well established in the agile community as the way to incrementally improve your processes and the way the team members collaborate during their work. The idea is that by regularly looking back at the past period you may find improvement that will increase the productivity and delivered value.

This concept can also be used in other contexts, for example during a project kick-off at the start of a new project and team. To get the team on track and up to speed quickly it is important that the forming process starts out nicely and that the team learns how to collaborate and get focus on their work. Iterative processes with short iteration lengths helps out here in that the team needs to get focused in order to have a successful delivery after the first iteration. But you can also help out by establishing a common goal and vision for the team immediately at the start of the project. This common goal could help the team establish better collaboration and communication patterns as well as good process and engineering practices from start that will kick-start the project. And to establish that goal you could run a retrospective from the future, a future-spective.

Continue reading

As developers feel the daily pressure to deliver, they tend to skip a crucial step in the process: learning and understanding the system. There’s a huge difference between just adding more lines of code to the codebase and making changes that maintain the conceptual integrity of the system.

Horizontal development is the result of not spending enough time learning and understanding the system you’re working on. By starting to churn out code too soon, you’ll inevitably be adding silos of functionality in parallel to existing functionality.

The outcome is legacy code. It doesn’t matter how well factored it is, and what test coverage it has!

Continue reading

You can embrace lean in different ways. You can make use of Lean tools, you can attend lean courses and you can embrace Lean values  (Toyota production system “TPS”  to be correct).

But how do you know you are a Lean organisation?

1. You define value from the eyes of the end customer
2. You have a value stream/process to deliver this
3. Management is continuously decreasing the Lead time across that value stream

Continue reading

I have the great pleasure to have had my session-proposal accepted to the Lean Kanban Central Europe 2011 conference! Together with Johan Nordin, a colleague coach from Sandvik IT Services, we will present the result of our Kanban coaching since november 2011. The title of our session is about scaling Kanban. The actual presentation is

Links: Game material (powerpoint) – so you can print your own copy of the game www.whereareyourkeys.org – more about the fluency game Have fun!  

I’m doing a free webinar tomorrow together with Kent Beck & Aslam Khan. The topic is Lean software development, with some real-life examples and interesting discussions. I will be sharing some experiences with scaling kanban to larger projects. Join us! Here is the registration link. Wednesday July 20 at 1pm EDT, 10am PDT, 7pm Stockholm

My experience is that most Scrum teams define "Done" as a "potentially shippable" story/feature. However, Lean has taught us that this definition actually introduces waste in the software development process.

You may remember Mats Henricson’s blog entry about what we know at Crisp. Well now we’ve put that same tag cloud (with some minor changes) on a mug! I’m sure you’ll be seeing these mugs in the hands of a Crisper near you in the coming weeks, but here’s a sneak peek: Get in touch

A couple of years ago during a visit to Japan I had the the great fortune of talking to the CEO of Fujitsu Applications, Jun Watanabe. Before we left, I asked him  "What is the most important thing in your work?" He’s response was  "At the end of the day, all that is asked, is what have I improved"

Jun is a manager who expresses his commitment to improve the capability of his organisation. And to improve it, you first need to understand it 🙂

What is capability? It is your team’s systematic performance, what it is constantly delivering. Examples could be your teams cycle time, your velocity or the number of production bugs you are getting.

How are you doing in this respect? Test yourself by answering these three questions in your mind:

The TDD Tetrahedron, or if you wish, pyramid, has reached 2.0. Like cars, the new model is bigger and comes with new technology.

By pure coincidence, I ran into somebody willing to print this. So here it is, the version 2.0 of the TDD Tetrahedron. The new version has sides of 100 mm and it is made of plastic.

What’s it for?

Well, if you didn’t use the older version, you may be wondering what’s so great about this. It is all about mental focus.

Continue reading

Having fun in London, beta-testing the concept of travelling with 4 small kids. We wanted to make it a challenge – if anything is to go wrong we’d rather it goes wrong on this short trip, than on the big trip after summer (we’re planning to do a 6 month round-the-world trip). So all the kids (except our youngest, 1 yrs old) got to pack & carry all of their own stuff all the way.

And no cabs or cars, which meant walking 1 km to the bus on gravel & dirt roads + a whole bunch of switching between buses, planes, subways, trains, escalators, elevators, stairs, etc, in both Stockholm and London.

Here is part 2, a week has past. I think as I write so it is a bit different in style and content than my other posts here.

It has been a hectic week, this first week as PO/SM. First of all, it was only four days thanks to national day. Then there were two new developers from Russia which meant twice as many developers as we had before, not counting me. Simple, you just tell people to pair program. That works out if they are well enough to come to work. Which they weren’t. So they russians were left a bit hanging. I had a lot to do just to keep the team running, at least according to my standards.

Continue reading