• About me

    JensI have been working as a software consultant for more than 11 years. Because of that I am an eager supporter of lean principles and agile methods.

  • Recent Posts

  • Recent Comments

    • Code Monkeyism: time. Too many developers on the other hand lead to communication overhead and get ineffective says...
    • Websites tagged "scrum" on Postsaver: - Speaking at Nordic Scrum Forum saved by speechjon2009-09-03 - Drury snaps...
    • Erik Lundh: Well “XP expert” sounds a little odd. XP was a vehicle for getting agile teams started in the...
    • The Flex Person: Well, just a single look at the restaurant you are referring to makes me want to pack by bags and...
    • Jens: Thanks Johan, I applied for the prezi beta testing like you recommended. I might post an example if I manage to...
  • Archives

  • Blogroll

  • Meta

Archive for February, 2007

Agile Scrum vs. Traditional Scrum

Posted by Jens on February 26th, 2007

I read this great article by Tobias Mayer where he describes how he has evolved Scrum into something that fits him (any many others) better than the process originally described in the first Scrum book.

Maybe we have seen the birth of agile Scrum, where evolution continues, in contrast to traditional Scrum, which was a snapshot in time.

Evolution cannot be stopped, it is eternal. Evolution was actually the reason why Scrum was invented in the first place, to replace the static traditional waterfall approach that had been around for too long, and replace it with a dynamic agile initiative, Scrum.

It’s interesting to hear that Tobias was actually fired from the Scrum Alliance because of his thoughts. Makes one wonder just how agile they are in their minds.

“When is Scrum not Scrum?” - Tobias’ article

Software Architecture and Agile Development

Posted by Jens on February 21st, 2007

Evolution started with simple life forms evolving into more and more complex structures where mother nature slightly adapted life forms to the existing and changing environment. Agile values promotes the same evolutionary approach for both software development in general as well as the architecture.

Software development is done incrementally and this implies that architecture should be kept simple in the beginning. Actually architecture should remain simple and it should always mirror the present state of the product and evolve together with the product. The architecture should not reflect a future version of the product. “Build today what you need today” or go ahead and consider future changes, but do not act until you need. This calls for frequent refactoring of the architecture when it becomes unstructured or inappropriate for solving the present problem. This is perfectly alright when done in small steps.

Architecture should also be a team effort, not a one man show. This makes all of the team understand the architecture as well as contributing to it. It also facilitates collective code ownership and refactoring. Adopting Test Driven Development further fortifies an agile architecture by facilitating regression testing.

Let’s have a quick look at Service Oriented Architecture (SOA). SOA is all about enabling agile values to the business. SOA is able to provide a method for rapidly responding to changing business demands. Sounds familiar? This implies that a SOA architecture and agile methods are very well suited for each other. Combining them enables your organisation to quickly respond to a changing environment.

Read Scott Ambler’s article about Agile Architectural Modelling.

Reducing Huge Backlogs

Posted by Jens on February 13th, 2007

How do we approach the problem with overwhelmingly large backlogs? The answer is simple. Make sure the backlog is prioritized first and then simply throw away the lower half. It sounds controversial but it’s all about limiting work to capacity. Having too large backlogs means that you are building inventory and inventory is waste that eventually degrades and becomes obsolete.

Instead adapt your backlog to your output capacity. If you are afraid of loosing important features in this process you need not worry, if they are important they will eventually reappear. Having a smaller backlog also makes you more responsive to new features and it consumes less resources.

These conclusions can be drawn by studying Lean Manufacturing Principles, which partially originates from queuing theory.

Our dialog with Jeff Sutherland resulted in the publication of a second interview, where we get to know more about his latest case study of an intercontinental Scrum project achieving a productivity of five times the industry average.

Read the interview.
Also read the previous interview (”Scrum in Larger Organizations”).

How did I end up in this business…?

Posted by Jens on February 6th, 2007

I have been a software consultant for more than 10 years, but my career as a software developer started much earlier. It must have been around Christmas in 1984, at the age of 14, that I got my first computer, a Sinclair ZX Spectrum.

I sat down for two straight weeks during my holidays reading through all manuals and learning to program in BASIC. I was completely struck by the power I had at my fingertips. I remember making a holiday greetings card with some moving blocky graphics and beeping music that I showed to my stunned family. This is actually where my career as a software developer started.

I loved my Spectrum and continued writing code for it. This is btw also where my interest in computer gaming was born. Eventually I wanted more power so I got a Commodore-128 with a floppy disc station.

However it didn’t take long before they released the Amiga500 in 1987 and I just had to have one. I got an Amiga500 and again I was stunned at the power I had at my disposal, especially the graphics where way ahead of my friend’s early PC. By this time they had also introduced computers in school and I had run into the Swedish bestsellers ABC-80 and ABC-800 and of course PC/AT computers.

Towards the end of my senior high school (sve. gymnasium) I focused on computers and telecom and had learnt to program Pascal and C and a little Prolog. This is also where it became more serious and I got my first PC with a whopping 40MB hard drive and I also start my first company together with a couple of friends.

However when school ended we split up and the company disintegrated. Two years later, 1992, I started my university studies in computer science. Another four years and a masters degree later I had started another company where I combined small assignments with my studies. But after my exams I wanted to be employed as a consultant and so I have remained for more than 10 years.

Bloggtoppen.se