ISerialized .Net, C#, Scrum and agile software development

10Jan/120

Troubleshooting Squeezebox network connections

Posted by Pål Eie

squeezebox duet networking problemsTroubleshooting network connection errors on your Squeezebox is hard! Once the Squeezebox Duet is fully configured it is important to remember that you actually have two devices connected to your network: The Squeezebox player/receiver and the Squeezebox Duet controller!

If you eg. change network provider, router etc. you can easily set up your controller again, but you will have a very hard time reconfiguring or connecting to your Squeezebox receiver SBR as it is still configured for you old network!

In many troubleshooting situations the easiest and fastest solution is to do a full facotry reset and reconfiguration (as the full setup only takes about 1-2 minutes). Follow the steps provided here!

19Dec/110

Scrum is like a game of Backgammon

Posted by Pål Eie

The first time I learned the rules of backgammon, I was quite surprised by the simplicity of the rules. But as I read some more about backgammon I quickly came across the saying: "Backgammon: A minute to learn a life-time to master", and as I started playing more and more I came across new rules like The Crawford Rule, doubling and a lot of strategy principles! Gradually I realized that the key principles I learned about backgammon is merely a fundament, getting good requires hours and hours of training!

A couple of years later (2005), I came across Scrum for the first time and had some of the same feeling. The principles are few, are theory is very easy to understand! But as I started using scrum, first as a team member, and later as a Scrum master I discovered a never ending series of hard to handle problems and challenges.  Today I see my self as an experienced Backgammon player and Scrum Master, but realize that both require both theoretical skills and years of experience!

Here I will present a couple of principles that can help you become a more valued scrum master!

 

18Nov/111

Five key principles to mitigate risk

Posted by Pål Eie

Releasing new software will always involve some risk of failure whether you do it small incremental releases, or you do it in large cycles with comprehensive testing.  There are however some key principles that will help you lower your risk of failure, principles which are easy enough to remember, but which we often don't follow for one reason or another......

23Aug/110

Memoization using generics – Part 2

Posted by Pål Eie

This is Part 2 of my series on Memoization. In Part 1 I described the basic principles behind memoization, and showed some examples on how to create an effective generic method to do memoization of methods with zero and one parameter. In this post I will show how to do memoization of methods with two parameters

17Jun/115

Installing updates on Ubuntu & Linux Mint

Posted by Pål Eie

Update Manager is a program that updates all installed software and their associated packages, with important software updates for security or recommended patches. The Update Manager checks for updates regularly and gives you much of the same advatadges as the loved and hated Windows Update functionality in W7.

I see however that a lot of users are troubling with the Update Manager lately! What every you try to update you always get the same error:

Could not apply changes! Fix broken packages first.

3May/112

Checklists in software development

Posted by Pål Eie

I guess a big percent of the developers reading my blog have stopped reading already, another big percentage probably still reads, but for the sole purpose to find out what's wrong with this stupid f*** who mentions the words checklists and software development in the same sentence! http://utihagen.com/?p=116

For those how have already stopped reading, there is not much I can do, other than feel sorry for their employers who hire people who wont keep an open mind and try new techniques to make us even better developers!

In most of my professional career I have worked as a consultant, with a constant focus on hours spent vs. value added to my customers. As a rookie you are normally afraid you don't have enough work to fill the day, being a senior or an architect is the opposite, I have too many obligations, too many projects to monitor, too many customers and too little time. And how do we solve this?

I see too many who end up just being the firefighter: always short of time, always on the project where hell has broken loose, always stressed and always cranky! I got tired of being a fire fighter, got tired of being cranky when I came home to my children, got tired of saving the day!

How did I solve my problems? I started using checklists!

1May/115

Features/Epics vs. user stories in Scrum

Posted by Pål Eie

As Scrum has grown in popularity, the concept of user stories has made its way from theory and dust covered UML books, to developers every-day vocabulary.  In the "old days" we tended to focus on one layer at a time, instead of one user story at a time, we focused on writing large classes supposed to solve all possible scenarios for later re-use instead of simple YAGNI focused classes pin-pointing its purpose  and we focused on large-upfront design instead of gradually adapting to the maturity obtained by the customer (and developers) through the project.

We started out with allot of user-stories and even more good intentions, but ended up with phase 2 and 3 and a bunch of long forgotten concepts and diagrams. Today we are not better at planning one year ahead; we have just realized that this is almost impossible. We started focusing on business value which closely relates to user-stories. We started working with user stories weekly and we started estimating and prioritizing user stories in our Product Backlogs.