h1

CITCON 2010 Wellington

July 9, 2010

CITCON

Last weekend I attended the Continuous Integration and Testing Conference (CITCON), which was held in Wellington for the first time. Paul Julius and Jeffrey Fredrick hosted their 13th conference and put on a great show, surprisingly by stepping back and letting the participants take over.

This was the first open space conference I’ve attended and I was astonished by how well it all worked out. I can definitely recommend participating in a CITCON and in open space conferences in general. Just be prepared: Make sure to have a think about what you would like to get out of the conference and what topics you would like to hear and talk about. The idea of open space is that the participants decide what is happening. If you improvise well you can, of course, do this on the fly. However, if you are like me, you prefer thinking about it ahead of time.

My main “take away” had surprisingly nothing to do with Continuous Integration or Testing. It was the realisation that there are different flavours of Pair Programming. It seems obvious now, but I never thought about it like this. I needed PJ to give them names to point out the obvious. The techniques he described were

  • Ping Pong: One developer writes a failing unit test, the other makes it pass and writes a failing unit test as well. The first fixes it and writes another failing unit test… and so forth. You get the drift. This practice is suitable for a pair of developers that are at about the same level of expertise, both technically as well as with knowledge of the code under development and business rules.
  • Ball & Board: One developer gets the mouse, the other one gets the keyboard. The ruler of the mouse should be the more experienced developer and steers the design and direction of the code under development as he is the only one allowed to choose what to do next. The developer at the keyboard writes the actual code.
  • Batting Practice: In this practice the ‘trainer’ throws an imaginary ball for the ‘batter’ by writing a failing unit test. The ‘batter’ hits it by writing the code to fix the test. This practice can be used when a more senior developer is introducing a junior developer to a new development concept, say test driven development.

Note that in all of the above practices the driver and the passenger roles change frequently, which in my opinion is crucial to keep the the developer in the passenger role engaged and focused.

Another idea that I found interesting, came up when we talked about how distributed version control systems like Git actually work against the concepts of continuous integration. PJ noted that he has been toying around with the idea of distributed continuous integration. A distributed CI tool would run on the developers machine, just like each developer has a clone of the repository. The local CI tool would then integrate the local changes with the trunk and let the developer know what would happen if he were to push his changes to trunk. There could be a setting to do this automatically, if there are no failures.

All in all, the conference was a great success. I thoroughly enjoyed it.

Posted in Conference | Tagged , , | Leave a Comment »

h1

Deployments should be non-events

May 15, 2010

The problem with “traditional” release management

I say “traditional” release management for the lack of a better categorisation. What I mean by that is having separate phases (and teams) for development, system test, user acceptance test (UAT) and finally production. The problem is that it just takes too long after the developer commits his code until it gets eventually deployed to production. In my experience, this is mostly due to delays in hand offs from one phase to another. And as we all know, thanks to Lean Thinking this is waste.

Why you (as a developer) should care

The deployments to these different environments are usually stressful, because they bare some amount of risk of taking down the system you are deploying to. And the closer you get to production, the higher the penalty for doing so becomes. Because of this risk, deployments usually take place when potential problems would have the least impact on the users of these environments, which in general happens to be out of business hours. And last but not least, deployments tend to be boring and tedious tasks. Or did you ever get excited about doing a release? Yeah, that’s what I thought.

Why you (as a manager) should care

Of course, you also care about the factors mentioned above, because you want your developers to be as happy as possible, right? But furthermore, you especially dislike the risks associated with deployments, because you have to factor them into all sorts of calculations. Additionally, all these delays between phases mean that your time to market for new features and bug fixes is way higher than it needs to be, which means you are loosing money. Constantly.

The obvious solution

It’s easy, right? The answer is continuous deployment. You fully automate your testing and deployment and you deploy straight to production after every commit. Sounds great. The problem is: Most organisations are not ready for full test automation or just not willing to give up manual testing. This may be for security or legal reasons, potential loss of revenue and/or reputation or something else. Bottom line is: Pure continuous deployment into production without any manual testing is not widely accepted. Period. I am not saying this goal is not worth aiming for. Trust me, I am all for it. I just don’t see it happening in the near future in most companies. In my opinion, the only way to practice continuous deployment into production is by having sophisticated real-time alerting combined with a system with built- in resilience. This would allow you to automatically detect and back out a failed deployment without an interruption of the system as a whole. Have a read of this blog post about how the guys at kaChing managed to achieve this.

A step in the right direction

Don’t worry, not all is lost. Even if continuous deployment is not achievable for you right now, that doesn’t mean you can’t improve your situation at all. You can take the first steps towards continuous deployment by decreasing the batch size of deployments and automating the deployment and hand-offs between the environments.

  • Decreasing the batch size should be easily achieved by just allowing automatic deployments into your first test environment. Only, of course, after a successful build that runs all your automated tests.
  • Automating the deployment may require some tailored scripts to suit your system. However, if you are using Hudson and your deployment artifact is a war or ear file you can use the deploy plugin, which is based on Cargo.
  • Automating the hand-offs could be achieved by using a central release management dashboard that is used by developers, testers and managers.

So far I haven’t found any Hudson plugin that would provide this. What I have in mind is something like the following:

  • Deployments can be configured to happen automatically or to require manual approval.
  • When deployment to an environment finishes, a configured set of people gets notified
  • The different environments where the application is running can be accessed directly from the dashboard
  • When approving a build, and all previous builds have been approved as well (there might be dependencies), deploy to next environment.
  • When rejecting a build
    1. A tester raises one or more issues for the build. The issue tracking system is tightly integrated in the dashboard and can be reached via a link, which pre-fills relevant fields about the current build and project. This automatically rejects the build.
    2. The developer that committed the change that triggered the rejected build gets notified.
    3. The developer fixes the issue (after creating a failing test to expose it, of course).
    4. The developer commits the fix with reference to the issue in the commit comment. This triggers a new automatic build, plus an automatic update of the issue and a notification to the tester who raised it (like the Trac SVN Policies Plugin).
    5. When the tester approves the new build the old build gets automatically approved as well, if this was the last outstanding issue for the old build.

In my mind it looks somewhat like this (click image to enlarge):

Release Management Dashboard

In order to do pure continuous deployment you could then configure the dashboard with only one environment (=production) with automatic deployment. You can, however, choose to set up as many intermediate environments as you like and also require manual approval of deployments to any of them.

Does anyone know if a Hudson plugin with this functionality exists or is in the making?

With this in place I believe deployments can be non-events, in the meaning of being effortless and stress free. This does not mean you should stop celebrating your releases, though.

Posted in Development | Tagged , , | 4 Comments »

h1

The purpose of test-driven development (TDD)

March 24, 2010

Most test-driven development (TDD) advocates claim that TDD generates well designed code. I think this thesis is in essence true, but conceals some conditions and intermediate steps. The direct outcome of test-driven development is not a design, but testable code and tests that enable refactoring.

Testable code

Testable objects usually have their dependencies injected and in general clean interfaces, which increases the likelihood of loose coupling with other objects. These are characteristics of well designed objects. So, objects that are created with testability in mind (as they are with TDD, since you just wrote a test for the object at hand) are more likely to be well designed.

Enabled refactoring

Being able to refactor your code allows you to change your mind about your design while you program and therefore to improve it as you go along. It is infinitely harder to come up with the best possible design up front than to start with something simple but imperfect and improve in small steps. This is the most powerful weapon of TDD. Your test suite provides a safety net and gives you the confidence to make the necessary changes to improve the design of your code.

No guarantees

Practicing TDD does not guarantee the above though, because

  • Doing TDD right requires skill and
  • TDD only increases the odds of good design, but certainly does not guarantee it. It still requires skill to make the right design decisions.

How do you do TDD right?

  • Test code quality: If your tests are of poor quality, you can’t expect them to improve anything and they will become a burden rather than being of use. Your tests need to be understandable, after all they are supposed to be your executable specification.
  • Testing on the right level: Your tests should test the behaviour of your objects, not their implementation. As such they need to test the communication of an object with other objects, i.e. the messages passed between them (aka method calls). In Java, for instance, you should write tests that invoke the method under test and then verify the return value and that the method called the expected methods of other (mock) objects. Don’t test how the method computed its result (= implementation detail).

What is TDD for?

Because of all this TDD (quite rightly) is considered to be a design technique rather than a programming technique, but one that happens to let you do your design, while you program. I do however believe that TDD is a design technique for the more fine-granular parts of your system (like the shape of interfaces) and that it does not make a high level design and architecture obsolete.

Posted in Development | Tagged | 1 Comment »

h1

Automatic hashcode method generation

March 11, 2010

When reading the book Implementation Patterns on the bus to work one morning I came across a section that talks about implementing the equals and hashcode methods in Java. I don’t know how often I have read this rule by now: “If you implement equals you also have to implement hashcode“. Otherwise you get into trouble when you try to use objects of your class as a key in a Map or Set. These two methods are basically Siamese twins that share vital organs. They can’t be separated.

Every time I implemented the twins I first created equals based on the business logic I wanted to achieve. Then I just used the standard implementation of hashcode from Joshua Bloch’s Effective Java book using the same instance variables as in equals. Pretty straight forward and in 99% of all cases totally sufficient. You just shouldn’t forget about it.

Reading about it again that day made me wonder though: If it’s so straight forward, why doesn’t the compiler do it for me? I also asked myself why I have never questioned this rule before, or anyone else for that matter. Or did someone? A bit of research should prove just that. There are in fact several ways to avoid writing equals or hashcode yourself ever again.

  • Let your favorite IDE generate it for you
    I can’t believe I’ve been developing in Eclipse this long and never noticed the auto-generation function for equals and hashcode.
  • Use the Apache Commons builder classes
    The usual suspect for convenience classes strikes again. The commons-lang library provides the classes EqualsBuilder and HashcodeBuilder that allow you to build standard equals and hashcode methods by appending the required fields to a builder instance. Alternatively, there is a method that uses reflection to determine the fields (all non-static, non-transient) at runtime.
  • Use Lombok annotations
    Lombok generates equals and hashcode at compile time from annotations in your source code and integrates well with Eclipse. Once you finish typing the annotation the methods even show up in the outline. Pretty neat. An additional bonus is that this boilerplate code no longer clutters your source code.

My winner clearly is Lombok. But don’t take my word for it, try it out yourself. For a more detailed comparison of the above with code examples read this review on the SpringFuse blog.

Image via Wikipedia

Posted in Development | Tagged | Leave a Comment »

h1

How transparent is Scrum?

February 24, 2010

transparencyThe Scrum Guide states that transparency is one of the three legs underpinning Scrum, with inspection and adaption being the other two. Since adaption depends on inspection and inspection depends on transparency, one could argue that transparency is the foundation of Scrum. So I came to ask myself: How transparent is Scrum?

Why is transparency so important?

Because

  • it makes inspection possible, which is needed for adaption
  • it enables visibility, to observe and understand what is happening
  • it leads to more communication
  • it establishes trust (in the process, as well as among team members)

This is why I think transparency is at the core of every good development process.

How does Scrum create transparency?

  • A visual (physical) task board is a great tool to raise the team’s visibility of the status of the current Sprint. For me the instant status report for manager type people is a mere side effect. Much more important is the constant feedback for the team – to be aware of the progress within the Sprint. Only with this knowledge can the team be truly self-organizing. This is why I am usually against all these software tools that try to replace a physical task board. Yes, there is a slight overhead to produce index cards and print out the burndown chart, but in my opinion it is minor in comparison to the raised level of transparency. Advocates of Kanban say that the typical Scrum task board with its columns for Backlog, In Progress and Done is not transparent enough. The column In Progress is a black box, hiding states like Analysis or Development. What is the right granularity for your team depends on your context, like the complexity of your development process, team size and others. My advice is to try keeping it as simple as possible without sacrificing transparency.
  • Early feedback is essential to make sure you are doing the right thing and that you are doing it right. It enables the team to discover and correct any errors and misconceptions as soon as possible. Feedback cycles can be applied at every level of development: pair programming, unit tests, acceptance tests, Daily Scrums, Sprints and releases. The time frames of these cycles range from seconds to months and the feedback is coming from different sources: your colleagues, automated tests, the Product Owner and most importantly the users of your product.
  • Future work seems to be predictable. This is achieved by the Product Backlog, which can be examined by anyone anytime. This creates a sense of predictability during the project. Even though most team members barely ever look at it, its existence creates the illusion of anticipation of where the project is heading.
  • Cross-functional teams work together on a common task. In an ideal (software development) world there is no them only an us. More often than not there is a bit of rivalry and tension when developers, testers and DBAs  are in separate teams. This is because they don’t understand each others pain points, caused by a lack of communication and transparency between teams. In big organizations they might not even sit in the same office or know each other personally. People tend to be so much more understanding and forgiving when they communicate face to face rather than via email. By putting all needed specialists within the same team, Scrum enables communication between them and makes their needs transparent to each other.

Nowhere left to hide

Even though transparency is so important and brings the above described advantages your team might be reluctant about working in a glass house process. To happily do so requires the team to be comfortable with admitting mistakes. Mistakes are inevitable and they are not necessarily a bad thing either. Making mistakes is quite possibly the best learning technique that is out there, as long as you don’t forget about the learning part.

Are you ready for the truth?

This can of course only be achieved if the people leaders of the team have the above understanding about mistakes and react appropriately on them. If your team is scared to admit mistakes, they won’t. They also won’t adopt a transparent process. So be aware that the truth might not look as nice as the filtered reports you are used to. It’s kind of a red pill – blue pill thing.

What did I miss?

  • What other reasons are there why transparency is important?
  • What other things make Scrum transparent?
  • What makes Scrum less transparent?
  • What are other processes using to create transparency?
Image by *SΛM via Flickr

Posted in Process | Tagged | Leave a Comment »

h1

A domain name system for people

February 11, 2010

Yellow PagesLast week my best friend sat the last exam for his university degree. I am currently living on the opposite side of the world, but I wanted to at least send him a text on his cell phone to wish him good luck and to let him know that I am proud of him. Only days later did I remember that he sent me his new phone number and that I haven’t updated my address book yet.

A better world

I wondered if there couldn’t be a service that would automatically update my phone’s address book whenever one of my contacts changed their phone number. This also means that in case I changed my own phone number, I wouldn’t have to notify all my contacts. Coming from an IT angle, I see this service to be similar to a domain name system (DNS) that translates web site names into IP addresses, only with names of people and phone numbers. The most important feature of a DNS is that “it translates domain names meaningful to humans into the numerical (binary) identifiers associated with networking equipment for the purpose of locating and addressing these devices worldwide.” Ideally, I would like to completely abstract away from phone numbers and only need to remember my friends’ names. After all, I want to reach a person not a phone – just like you want to see a website without caring what server it is hosted on. As with IP addresses, people could be completely oblivious to the fact that there even is a number. In this improved world if I wanted to call someone, I just need to know his name.

Don’t stop there

Phone numbers are of course not the limit. The same approach works for physical addresses, email addresses, or any other means by which you can reach a person. Whenever any of your friends changes their contact details, your phone’s address book automatically updates itself.

Back off

Does that mean anyone can find your phone number and your other details just by knowing your name? Or even worse, just randomly pick a number and get your name with it? You probably don’t want that, unless you enjoy spending your time talking to strangers about random polls and lottery tickets. There needs to be some kind of white listing, so you can choose who is allowed to see your details.

Yet another service

This means you and your contacts would have to sign up with this DNS to exchange the right to see each others details. There would probably be a website (with some IP address you don’t care about) to keep your details up-to-date and to manage your contacts. You have your doubts that you will get all, or at least most of your friends, to sign up for yet another website? Granted, but here is the good news: Chances are, you and your friends already have. Long live social networking!

Leverage what you have

With Facebook and Co. growing every day all you need is an application on your phone that logs into your favorite social network and gets the details of your friends and checks for updates from time to time. Only your friends could access your details (if you shall choose so) and you could totally forget about their numbers. After all, you want to call a person with a name, not a phone with a number.

Posted in Uncategorized | Tagged , | 1 Comment »

h1

Personas are the tests for requirements gathering

February 3, 2010

John Doe PersonaI just watched a presentation by Jeff Patton about using personas for requirements gathering. I especially liked his comparison of personas to tests in test driven development (TDD). He argues that using personas for requirements gathering is like TDD for development. Personas are the tests for your requirements.

Like tests in development your personas should be created first and your requirements built from them. This also implies that your personas need to be specific, concrete examples from the pool of users, representatives, like tests with concrete values.

Just like tests in TDD help you design your application, personas help you understand the problem space of your application. If you can’t create a concrete persona you probably haven’t understood the problem space well enough.

Tell me a story

Personas are closely related to the topic of storytelling. In his article Better User Experience with Storytelling Francisco Inchauste states:

By centering around a specific theme, or character, the uncoordinated elements of an experience all have a clear goal and purpose. With storytelling, a diverse team creating a website or application can collectively link together the tangible elements and create something that is a meaningful experience and is more than just bits and bytes. [...] Using the created personas and then creating stories about them, we are able to cast a more meaningful vision of the project.

Personas and their stories help the team understand how users will experience the built website or application and how it affects them at an emotional level.

To find out more about personas have a look at the before mentioned presentation by Jeff Patton, this presentation by Alex Horstmann and on Cooper.com.

Image by MIT

Posted in Process | Tagged , | Leave a Comment »

h1

Java Build Server

January 23, 2010

Update [15.05.2010]: I finally had a chance to try out SecureCI, which is pretty much exactly what I described in this post. The guys from Coveros did a great job, so I suggest after reading this post you head over to their website, download SecureCI and give it a go. Thanks John for pointing this out to me.

In my last Java project, I set up a build server with Continuous Integration (CI) capability. I am a big fan of Test Driven Development (TDD) and I quite enjoyed Hudson telling us right away when someone checked in code that broke the build. It just gives you so much more confidence in your code and keeps it releasable at all times. In addition, we used Sonar to measure the quality of our code. I found it quite interesting to study how the different metrics changed over the course of the project. We paid particular attention to code coverage and tried to keep it as close to 100% as possible. This should happen naturally anyway if you are practicing TDD.

Setting all this up was a good experience to learn how it all fits together – But I learned my lesson and I don’t really want to do it over and over again. So, I started looking for a Virtual Appliance that had most, if not all, of these capabilities. Setting up a build server must have been done by other developers a million times before. Surely, someone along the way stuck it all on a Virtual Machine (VM) and made it open source, right? Well, that’s what I thought, but I couldn’t find any. So, I decided to create one myself. Unfortunately, I am lacking the hardware to do so at the moment. I have even already created a project for it on https://launchpad.net/java-build-server. Although, I haven’t come around to create the VM yet, I still wanted to share my idea here to maybe animate someone else to go ahead and give it a go. So here it is: my idea of a Java build server.

I planned to start with what I think of as a good enough build server: A VM based on Ubuntu Server JeOS with pre-configured installations of Subversion (Source Control), Hudson (Continuous Integration), Sonar (Quality Metrics), MySQL (to store Quality Metrics), Maven (Build) and Nexus (Enterprise Maven Repository). Once this is all working I am going to also install Trac (Wiki and issue tracking system). You might of course have your own preferences for tools to use for the tasks listed above. Feel free to swap out whatever tool you wish. You might already have an enterprise Maven repository. Fine, just use your existing one. All I am saying is, these tools will be on my build server VM; pre-configured as much as possible with standards found in the tools’ documentation, following the convention over configuration paradigm.

Creating the VM

Here is how I am planning to create my Java build server VM. I am using VMware Studio to create the VM. VMware Studio is a Virtual Appliance itself and I deployed it in VMware Server 2.0. First I created a basic VM based on Ubuntu 8.04.1. Studio automatically installs VMware tools and embeds an in-guest management component called Virtual Appliance Management Infrastructure (VAMI), which lets you configure the network settings of your VM after it has been built. This is essential, since you want your development team to be able to connect to your copy of the build server VM. Here is a list of the essential settings I used to create the base VM:

  • ubuntu-8.04.1-dvd-i386
  • 1 CPU
  • 512 MB RAM
  • 8 GB
  • Network settings: DHCP (to automatically find an IP address)
  • Target format: zip

After the build finished, I downloaded the zipped VM and deployed it on my VMware Server instance. I started the VM and assigned it a static IP address on the boot screen. I logged in and carried out the following steps:

Using the VM

Of course there are some project and company specific configurations that cannot be set in advance. Here is what is left to do:

  • Install a VM container on a server (e.g. VMware Server)
  • Download and start the VM in your container
  • Set the network details on the boot screen
  • Add your developers as users to Subversion (in /usr/local/svn/passwd-team)
  • Create a project
  • Create Hudson jobs to monitor your project

What’s next?

To make using this Java build server even easier I am also planning to create the following:

  • a Maven archetype that only needs the IP address of the build server to be configured
  • a script to create a new project on the build server (create SVN project, create Hudson jobs, etc.)
Image by indigoprime via Flickr

Posted in Development | Tagged , , , , , , , , | 6 Comments »

h1

Is estimation waste?

January 7, 2010

Lean Thinking suggests that estimation is to be considered wasteful. Instead, the throughput time (lead time) for planned items is projected by using previous measurements. I always thought this was an interesting approach and today I came across this screencast about Naked Planning, a development process created by Arlo Belshee based on Value Based Planning. In a nutshell Naked Planning consists of the following.

  • A list of goals that describe objectives to satisfy the costumers needs.
  • A fixed length (7 ± 2) queue (Product Backlog). This is based on the idea that 7 is the number of things a person can keep in their mind at once and prioritize. It ensures that customers are making value prioritized decisions at all times.
  • The 7 slots in the queue are to be filled with Minimal Marketable Features (MMF) by the customer (Product Owner). The customer uses the list of goals to generate new MMFs once the development team has eaten away the top priority MMF.
  • The customer prioritizes the MMFs purely by value. There is no upfront estimation of MMF’s. This is based on the idea that cost is distributed linearly and therefore approximately constant, whereas value is distributed exponentially and therefore outweighs cost. Estimation itself is considered a wasteful task (see arguments below).
  • There is one (and only one) slot for urgent tasks, which the costumer can use to bypass the queue. The development team tries to keep this slot empty at all times.
  • The development team has a fixed amount of slots to pull MMFs from the queue; just like the Work in Progress (WIP) limit in Kanban. This depends on the size of your development team, but there should be about two slots.
  • A MMF is considered done when everyone included in the process thinks it’s done, including the customer. In the done state, the MMF is already part of an automatic deployment, so unless someone takes action to prevent it, it will end up in production.
  • Throughput time (time between ‘MMF gets added to the queue’ and ‘MMF is in production’) is projected by previous measurements. Since there are no estimates this is the only way to do this. These measurement-based projections are supposed to be more accurate than estimation-based predictions. Arlo puts a dotted line on the bottom of the queue with “Your approximate time to wait is x days”. This is what he calls the “Disneyland wait time”.

This is what I gathered from the above mentioned screencast, Arlo’s comment on this blog entry by Aaron Sanders explaining Naked Planning, this podcast from Agile 2008 and this short video from Agile 2007. I don’t think there is any “official” documentation about the process, just videos from conferences.

Estimates deliver negative business value

Arlo argues that when customers prioritize the MMFs purely by value without considering the cost at all, they actually make better decisions. Let’s say we’ve got a two by two matrix with cost on the horizontal axis and value on the vertical axis and MMFs scattered throughout this matrix. The common behavior is to choose the cheap MMFs on the left – first the ones on the top with high value, then the ones further down with low value. These low value / low cost MMFs are what Lister and DeMarco label with ‘Death March’ features. If you take away the cost axis, people only choose high value MMFs – some with low some with high cost. Arlo calls these short term value (high value / low cost) and long term value (high value / high cost) items. According to his studies, it turns out that this is a much better portfolio of MMFs than just low cost MMFs. Consequently, not giving your customers estimates to consider when prioritizing their MMFs actually let’s them make better decisions. Having estimates is therefore a negative business value proposition or as Arlo puts it: “It’s positive cost, it’s slightly dishonest and it delivers negative business value.“

He further explains that not doing estimates also saves a lot of time:

I never spend any time tracking estimates, improving the team’s ability to estimate, applying math to counter the effects of holidays & sick days, etc. This estimation normalization stuff takes a surprising amount of time – as I only discovered when I stopped trying to make halfway-decent estimates. Possibly most importantly, eliminating estimates eliminates conversations like “you promised that, this week, you’d do X, Y, and Z. Where’s Z?” Instead, the conversations become “What is the relative importance of X, Y, and Z? Well, X, then Y, then, eventually Z. Can we just release X+Y as soon as they’re done? Sure. We’ll give you some warning when the release is coming close.” It opens up a lot more success opportunities, and shuts out several types of bad behavior.

Points to debate over

I find the idea from a developer’s perspective very appealing, because it takes away the dreadful task of having to come up with an estimate, but there are a couple of issues with this approach that I am not quite sure about.

  • Team motivation: How do you achieve a commitment from the team and keep the motivation up, without the looming deadline of the next sprint demo and without the team trying to achieve the estimates? One possible way to keep the motivation up is to keep regular meetings in which the team demonstrates the done MMFs to customers. Naked Planning does this by keeping demos and retrospectives as a heartbeat for the team. However, I am questioning if the motivation will be as high as with the commitment to a certain number of MMFs prior to the sprint. But maybe I am wrong. There is a study mentioned in Peopleware by Lister and De Marco, that suggests that “the highest [software development] average productivity was on those projects that didn’t estimate at all.”
  • Customer buy-in: You need to find a customer that is able and willing to make business decisions independently from the cost of the wanted MMF. From my experience with Scrum, it is hard enough to convince customers that they don’t need a detailed project plan with a big design up front. How can you justify abandoning release and sprint planning (and sprints for that matter) all together? Here Arlo draws from his experience by using the Naked Planning process with his team. In his experience, the ‘Disneyland wait time’ (the time for the 7th item on the queue to go into production) is usually never longer than 90 days. This means the customer can plan with the seven most valuable MMFs within 3 months.
Image via Wikipedia

Posted in Process | Tagged , , | 5 Comments »

h1

Resigning is a bit like breaking up with your girlfriend

December 23, 2009

Broken heartI started a new job last week. This also means that I had to quit my old one. It was the first time I have left a company by resigning from an open-ended contract. The situation reminded me a bit of breaking up with ex-girlfriends. Both are difficult situations. Both are awkward. No-one likes to hurt or disappoint someone else. Especially someone you had a close relationship with.

Of course, leaving a job is much less emotional than leaving the person you loved, and that you might have lived with for an extended period of time. Don’t forget though, that most of us spend the greater part of our waking hours at work. More often than not, the amount of time we spend with our colleagues sums up to more hours than the time we spend with our spouses. So, no matter how professional you might be about it, “leaving” your old job, and therefore your colleagues and your boss, is emotional as well.

The last impression counts too

If the first impression you make on someone is the most important one, then the last impression you leave probably follows right in second place. It’s all about keeping your face. If you stay honest and you keep your (business) partner up to date about your situation and feelings, then there is not much they can hold against you. Of course, it will still be awkward, but at least you can still look the other person in the eye afterward.

We need to talk

Don’t go blabbing your decision all over the place before you have told your boss/partner. There is no excuse for them having to find out from someone else. You should still have enough respect for them (and the courage) to tell them yourself. Personally. Be prepared, direct and polite. Show some class. No matter what may have happened before, this is not the time to get personal. There will be questions, so make sure you have thought your decision through. Don’t accept counter offers. They might tempt you stay around for longer, but the key problems resulting in your decision to leave in the first place, won’t just go away.

Notice period

Ok, ok. There are differences between a resignation and a break-up. What is very appropriate in one situation (job), doesn’t necessarily work in the other (love). Please notice the key term ‘a bit’ in the title. Your employer obviously would like to have as much notice as possible to prepare for your departure. This doesn’t apply to ending relationships. In the later situation you need a clean cut and some distance – at least for a while. Anything else will just make it more complicated. Trust me, I’ve been there and I’ve seen it happening numerous times. It never works.

After handing in your resignation, don’t slack off. Continue acting professional with your employer. It is highly likely that your paths will cross again. Make sure that you’ve completed any outstanding tasks and participated in the smooth handover of any unfinished work.

Get some distance first

Switching from a close relationship to just being friends doesn’t happen over night. Allow yourself and your significant other some distance to get over the heartache and to get used to your new situation. Depending on how tight the relationship used to be this phase might last between one and six months. After it you should not be feeling bad about the break-up anymore and once you get over the initial awkwardness of meeting again, you can start seeing your ex-partner from a new perspective.

I know, it’s probably the most cliché phrase ever, but I tend to really mean it in both cases: “Let’s stay friends.”

Image by WolfS♡ul via Flickr

Posted in Job | Tagged , | 4 Comments »

Older Entries »