At least we have one

I posted a link to this photo on Twitter this morning. One of the first responses I got was making fun of the fact that the first incarnation of our continuous integration server is on an old laptop. They used the word "quaint".

When I asked the rude person what their server ran on, they didn't even have one. This leaves me thinking that I'd rather have a caravan in the hills than a mansion in the slums.

Excuses about not having the money or permission or a restricted network is not a good enough excuse to not have a server that is building your code, running your tests and preparing automated deployments. Get out there and start building rigour in to your development practices and hopefully finding the emergent quality that accompanies it.

If you don't happen to have one or possess the will to make it happen then shut up because you just look lazy and rude. Lazy on its own is bad enough.

Tell me a story

The story wall went up at work today. We are the not just the only project running agile, we are the only project with much of a plan at all. Working in this small city has frustrated me to no end. People here talk of things they do, without doing them. They say they are aiming for this and that and then all the aiming that is done is in the talking of it.

This project is different. We are walking the walk. The team likes the idea of agile. They are willing to try it. They are willing to find the flavour that suits them and the project.

Our goals are simple. Short deadline. Fixed budget. Huge scope.


The Story Behind It


When I joined, we had done a lot of requirements gathering and there were big solid specs being written. There were documents defining process and documents defining documents. Today, I uploaded my last documentation of the project up to the Sharepoint portal and turned my head to the story wall.

Over the last few weeks, we have been breaking down tasks. I walked them through how to do that breakdown and then how to guesstimate to the best of our knowledge at the time. We recorded effort in days and the whole team agreed on complexity and volatility. We came up with numbers and costs and best of all, a shared understanding of what we were building.

The first visible way this has been communicated is to produce a story wall from our master story list. The master story list is a list of the discrete tasks that describe functions and sub-functions in the required system. Developers will undertake one task at a time, after business analysts have described it and they have both agreed on acceptance criteria. That acceptance criteria will guide our test driven approach to development and eventuate in automated tests and the QA and then user acceptance tests for each story/task/story.




Reading the Cards


Right now, the wall is made up of different coloured cards...

• White - Story cards made up of an Id, a task description, estimation of effort, complexity and volatility ratings and space for acceptance criteria and notes;
• Green - Descriptive cards that give headings for the stages that a story goes through and other important sections that a card can belong to;
• Pink - Defects which are played like stories and require Ids, estimations and all the things a story needs. They will come out of testing stages after they have been accepted for QA and moved out of In Dev, which are two of our story stages;
• Yellow - Tech cards for technical tasks that are related to stories and need to be explicitly detailed. I personally hate tech cards but for iteration 0, they are valid. If I see too many, heads will roll;
• Blue - We haven't associated them with anything yet. We are calling them Terry cards. Terry is our project manager. We didn't want him to feel left out since he's on leave and I'm sure he'll have a good suggestion for their use. Possibly things Damana is not allowed to blog about;
• Sticky notes of random colours - These denote blockers and notes relevant to a story. They are stuck on the story card.

The Life of a Card

There are columns that represent the stages a story, defect or technical card can move through. At each stage, there is an owner of that card. A card can not be in play and not have an owner. For a card to move from one stage to another, there must be a discussion between at least two members of the team and one must be the owner handing over to a new owner.

Our stages for this project are...

• Backlog - Where all stories sit until they are played in an iteration. Everything starts here. It's a little like Munchkin Land;
• In Analysis - All stories that are being played in a current iteration will start here on the first day of the iteration, after the IKO (Iteration Kick Off) meeting. At this point they belong to the business analysts and will only move once they are ready for development. This is usually a decision made by two analysts or an iteration manager and an analyst. Remember that the analysis on a story does not need to be 100% complete. A story card is an opportunity for a conversation. It is not a spec;
• Ready for Dev - Now the story is available for a developer to pick up once they have the bandwidth to start and complete it. At this point, the decision to move it to the next stage is made by a business analyst and a developer. If you live in a perfect world then hopefully a QA is around to help establish acceptance criteria with those two;
• In Dev - The acceptance criteria is set, the estimation validated loosely by the dev and the shared understanding of what is required completed enough to start the task having occurred between analysts and developers (yes, a pair). Development starts. This does not mean running away and working in solitude. Nope. There will be more questions for the analyst and the business and other members of the team. Nothing happens in isolation on this agile team. Transparency and Conversation are paramount;
• Ready for QA - As it sounds, this is when the developer(s) think that the story has been fully implemented and can be taken for system testing. In our case, this means acceptance criteria are met and there are automated tests at all levels ready and running in continuous integration. Full integration has been made with the project code base and all compliance with agreed coding and developer standards are adhered too (well, mostly). At this point, the developer and the QA are often having a chat. Anything that needs clearing up is brought to the business analyst. Beware of slippery developers who bargain at this point. Don't pay the ferryman until he gets you to the other side. I have turned around to many QAs and said "well, you agreed I met the criteria so move that to another story";
• In QA - The story is in system test and belongs to the QA. I won't tell you how to do good QA because I'm a developer and there are better people out there to tell you such important things;
• Ready for UAT - The story has met acceptance criteria and passed system testing. It is ready to show to the client;
• In UAT - Users are testing it. The team deals with defects and waits for users to accept the implemented functionality. Business analysts, QAs and iteration managers are dealing with outcomes at this stage. We wait;
• Signed-Off - The users have tested it and the business has signed off the story as complete. We celebrate. For some that is chocolate. For others champagne.

Pwn It

Every member of the team has chosen themselves an avatar that will represent them on the wall. Some chose their photos. Some chose creatures or characters that represent them. This is how they will be seen and how they will own their current task. These are about the size of a business card. Our only rule is "no nakedness".


The Outcome

Every process is different. Every wall is different. The purpose is the same. Communicate and provide visibility to the whole team and stakeholders.

Tomorrow, we will start holding our stand ups around the story wall. That is when the team will see the true value of both the visual story wall and stand ups. It will become the most important part of our project.

It will grow and change so that it gives meaning to our particular project. Come back once in a while and check how we are progressing.

Configure your embedded YouTube video

While embedding a music video on my blog, I found that YouTube now lets you configure the dimensions of the video and a few other useful options. This makes a huge difference when you have size constraints on the host site. Blogger is a great example of embedded videos exceeding template limits and just messing the whole look up.

Again, YouTube gives me another reason to use their service for easy video sharing and embedding. It is little things like this that appeal to bloggers. Thank you.