Home
About
Contact
Sunday, March 30, 2008

ScrumAndXpFromTheTrenches Lately I've been shifting focus back and forth between development and project management. 2 years ago I took the initiative to start Scrum where I work, and this has turned out to be such an interesting and demanding process that I'm having problems letting go (not that there is any reason to). During this process I've been reading a lot of books about Scrum, Agile, XP, planning, estimating and so on. All the books I've read has been very theoretical. Most of them were based on experience by very experienced practitioners, but still they tend to be very general in their advice and cautious of telling you how to do things.

Today I was looking at some Scrum resources over at ScrumAlliance and found a presentation by Henrik Kniberg called "The Manager's Role in Scrum" (access requires membership). In his presentation I saw a book he had written (Scrum and XP from the Trenches) and found it freely available at InfoQ. The interesting thing about this book (which I by the way have not read but just skimmed through) is that it focusing on "this is how we did it" on a very detailed level. The nice thing about these kinds of books (or even presentations) is that you might not agree with everything that they've done, but it gives you input like: "we've tried this and it worked!" or "we tried that, but it failed miserably!". And if you're lucky you also get "we think this worked for us because..." or "it did not work very well because..." and so on. You also often discover things that you haven't thought about before. "Ahhh... that's right, why haven't I thought of that?".

I've seen the same things at NNUG where we typically have two types of presentations; new technology, or someone's experience within a certain topic. New technology talks are very interesting and motivating, but often lack experience. Experience based talks are popular because everyone knows the value behind time spent and experience gained, and that this information is given to you for free, helping you do avoid common mistakes.

Hopefully I will get time to read Henriks book soon and maybe I'll post a short review as well.

Sunday, March 30, 2008 11:26:14 PM (W. Europe Daylight Time, UTC+02:00)
Monday, March 24, 2008

ScrumOverviewTinyAt Contiki we started doing Scrum in November 2006 and I wanted to post an update on how we're doing, and at the same time look back and see what we have accomplished. Quite a few things have happened since I held my presentation about how Contiki is doing Scrum in February 07 at NNUG. After skimming through my emails from the last 2 years I was able to find an interesting progress on what and when we have introduced the different aspects of Scrum:

  • Daily stand-ups/Daily Scrum (Oct 06)
  • Daily Scrum in Campfire to improve communication with our offshore team (Nov 06)
  • Started using ScrumWorks (basic) as our Scrum management tool (Dec 06)
  • Started our first test sprint (Jan 07)
  • Read Mike Cohn's book, Agile Estimating and Planning, which I've used as a guideline from that day (Jan 07)
  • Started sprinting for real including all meetings (planning meeting, review meeting and retrospective meeting) (Feb 07)
  • I got certified as Scrum Master (March 07)
  • Started using Planning Poker and www.planningpoker.com (March 07)
  • The word Scrum became a buzz word in our company (April 07)
  • Our current dev team at the time got split into 3 Scrum teams because the team had grown to big (Nov 07)
  • Started having fixed lengths on all sprints to get an accurate velocity (Nov 07)
  • Started using release planning for long term planning (Nov 07)
  • Started calculating cost based on number of sprints and team resources (Jan 08)
  • Our Product Owner got certified (March 08)

It's taken time and we're still not quite there, but I feel we have achieved a lot. Not only that, I also think (and are quite confident) that we have improved our development process enormously.

If you look at the list above we can shorten it down to:

We started with Daily Scrum, continued with Sprints and "ended" with Release Planning.

For me this have been a very logical approach to introduce Scrum to our organization. The easy part was getting the development team to adapt Scrum. You might argue that we spent a long time doing so, but the process has evolved over time (for us that is) and we've adapted the different aspects of Scrum as we felt ready for it. It also has to do with the team getting more and more mature and gaining new knowledge about the process which increases the willingness to adapt new things. I also feel that we did right in not pushing everything at once. We could for instance have started with Release Planning earlier, but we had several good reasons for not doing this. It's also about letting the whole organization getting used to Scrum and it's way of doing things. Getting used to communicating with User Stories and Story Points instead of features, use cases, days, gant charts etc. The development team hasn't changed how they do Scrum for quite some time, but the rest of the organization has needed this time to adapt. The time spent also reflect our learning curve as we have moved forward. The most important thing of all is that the Scrum initiative came from the developers themselves, and not from management, and there was a mutual agreement for us to try this out.

In addition to focusing on the development process of Scrum, we have also adapted many things from XP. As you probably know Scrum does not say much about how a developer should adapt to the agile way of working. Scrum is a management process is my eyes. XP however are very practical and fits nicely with Scrum. You might ask why we decided to do Scrum and not XP? The answer is coincidence. At the time when we started looking at a new process, Scrum had a lot of attention and it was Scrum I started to read and learn about first. Later I found that XP is not as extreme as one might think.

The hard part for us (developers) has been to be effective with TDD or Unit Testing in general. Actually not only effective, but to get "acceptance" from all the developers to spend time on writing tests instead of being "effective" with coding. We have a lot of legacy code (as defined by Michael Feathers; legacy code is code without tests), and making major changes to our application for the sake of automated testing was just not an option. The cost would be to high and our ability to deliver new functionality would have decreased to much. Sometimes I really envy the consultants out there that get to work with new products more often than not. We are however aiming for improving our existing code with tests as we touch the code fixing bugs or creating new features, but this is a long running process.

Agile | Scrum | Work
Monday, March 24, 2008 10:54:39 PM (W. Europe Standard Time, UTC+01:00)
Thursday, March 13, 2008

MouseClickServer deployment of ClickOnce? Isn't ClickOnce client deployment? Yes, it is. However, you will have to deploy the ClickOnce files to a server, right? I feel this is a poorly documented step and I thought I share some of my experience around this.

So what's the problem? The main issue is the deployment manifest file. If you've worked with ClickOnce you know about this file, if not here's a (very) short description. The deployment manifest includes information about where the ClickOnce application is located (e.g. http://myServer/myWD/myApp.application) as showed in the following snippet:



...
<
deployment install="true"
mapFileExtensions="true"
trustURLParameters="true"> <subscription> <update> <beforeApplicationStartup /> </update> </subscription> <deploymentProvider
codebase="http://myServer/myWD/myApp.application"
/> </deployment>
...

This file needs to be signed with a certificate to be valid, which means that any changes to this file makes it invalid and you'll have to resign it. This is a good thing for security, but it causes some problems regarding deployment. The url specified in this file must be changed when deployed at a server. Unless you want to get all information needed from your customer and create the deployment package before sending it to them or force them to set up a server named myServer ;-). I don't think that solution is very likely to be used in production systems. So what you need to do, is make the installation (e.g. msi) change the manifest file and resign it during installation.

Microsoft has provided us with a tool to do exactly this. However, you're not allowed to redistribute it. Another issue is that you need to have a certificate for signing and you don't want to have your corporate certificate laying around in your msi. The most common solution around this problem is to prompt the user during installation for a certificate (like suggested here). But then your app is signed by someone else's certificate, which is probably not what you want.

I will now suggest a different solution to this problem. In the System.Build.Tasks.dll you'll find much of the functionality needed to do the same thing as Microsoft's Mage.exe is doing. The nice thing about this dll is that it's a part of the default .Net Framework installation. Here's a short description of the classes needed:

DeployManifest
An object model for the manifest file. Gives you direct access to specific parts of the manifest and makes it really easy to make changes.

ManifestReader
Have a static method (ReadManifest) which let you read and return the manifest you are going to work with.

ManifestWriter
Use the static method WriteManifest to write your changes back to the manifest file.

X509Certificate2
Your certificate to sign the manifest file with.

SecurityUtiities
Has the static method called SignFile which let you sign your manifest.

By using the classes described above it should be quite easy to achieve the same as with the Microsoft utility. Here's an example:

using System;
using System.IO;
using System.Reflection;
using System.Security.Cryptography.X509Certificates;
using Microsoft.Build.Tasks.Deployment.ManifestUtilities;
...
string
manifestPath = @"C:\Temp\myApp.application"; string deploymentUrl = "http://myServer/myWD/myApp.application"; DeployManifest manifest =
(DeployManifest)ManifestReader.
ReadManifest("DeployManifest", manifestPath, false); manifest.DeploymentUrl = deploymentUrl; ManifestWriter.WriteManifest(manifest); X509Certificate2 certificate =
new
X509Certificate2(GetCertificateFile(), "password"); SecurityUtilities.SignFile(certificate, null, manifestPath);

There is one important step we need to solve. How do we protect the certificate we need to sign the manifest file. For this I suggest you incorporate this into your tool (either a command line tool or a .Net library) by using Build Action = Embedded Resource. This will make your certificate inaccessible for most people. If you want to secure it even more, you can crypt it in however way you want. I leave this up to you ;-) In my code above I've done this in the GetcertificateFile() method:

X509Certificate2 certificate = 
new
X509Certificate2(GetCertificateFile(), "password");

There is of course one other issue which you'll have to consider. What if someone uses your custom tool to sign their ClickOnce app? So you need to protect this as well with a password or some other mechanism. If you have a good suggestion to this, please let me know.

Thursday, March 13, 2008 3:03:15 PM (W. Europe Standard Time, UTC+01:00)
RSS RSS - Comments Twitter LinkedIn
         
SEARCH
 
 
         
TOP POSTS
   
         
NAVIGATION
   
         
CATEGORIES
  .Net (61) ADFS (3) Agile (31) Ajax (5) Architecture (20) Articles (1) ASP.NET (7) ASP.NET-MVC (1) Blogging (12) Books (2) BPEL (1) CleanCode (1) CloudComputing (7) Community (5) CSharp (11) DasBlog (5) Database (2) DDD (5) Deployment (17) DSL (1) Events (38) ExtremeProgramming (6) Fun (6) Gadgets (4) IIS (10) InfoQ (4) Java (2) Kanban (1) Lean (3) Linq (2) MemoryLeaks (5) Microsoft (37) MVC (1) NDC (2) NNUG (37) Other (10) Patterns (9) Performance (3) Scrum (17) Security (7) ServiceBus (1) Silverlight (4) Software (19) TeamManagement (12) TechEd (7) Testing (5) Tools (25) TvGuide (1) Vista (15) VisualStudio (16) WCF (8) Web (16) WebDeploy (2) WIF (3) Windows (10) WiX (9) Work (18) Workflow (3)  
         
ARCHIVE
   
         
BLOGROLL
   
         
ON THIS PAGE...
 
Theory is one thing...
Scrum @ Contiki - How's it going?
ClickOnce - Server Deployment