The following blogs are available on
DrivenSoftware.com...
I've been trying to learn git and I've decided that the next way to really get famliar with it is to use it with one of the teams I am on. They are using svn, so I have used git-svn to create the the mapper between the two. I wrote up a cheat sheet for myself with git flow I want to use and the reference links I used. If anyone can recommend any improvements let me know.
I just finished reading the book User Stories Applied by Mike Cohen. Its a great introduction to writing user stories and applying them to an agile environment.
The book is broken into 4 main sections. The first section titles 'Getting started', it introduces the reader to the process of writing stories. I found this really useful. The only thing I did not like was that there was not enough detail of showing how to write a story in the BDD style of AS... I WANT TO... SO THAT, as well as writing acceptance tests/scenario's in the GIVEN... WHEN... THEN... The BDD style of writing a story makes it easy for someone new to stories to write good and useful stories very quickly. It also helps with the implementation and testing of the stories.
The book then goes on to explain 'estimating and planning with stories' and 'frequently discussed topics of stories'. Both of these sections are useful, if not common knowledge to most agilists.
The The final section is a real gem and puts everything into context, Mike goes through an example of planning a project and iterations with user stories. This nicely details the process of creating user roles and writing stories for them. It also shows the process of prioritizing stories and planning a release. This should help any inexperience reader to get started and give new ideas to any experienced agilist.
I recommend anyone who wants to improve their user story writing or wants to learn how to write stories. Its a fantastic starting point and will help you get comfortable with writing stories.
I attached my mindmap of the book. I've only mapped the points I thought were relevant for myself but hopefully they are helpful for you too.

Its taken me a couple days or maybe even a week, but here is my mind map from the certified scrum master. I didn't include everything that was spoken about just the key points I found very relevant.
To Zoom in open image in another tab...

I'm currently on the certified scrum master training course run by Peter Hundermark of Scrum Sense. It's a two day training course discussing the basic principles of scrum. It's main focus was on the roles of the key players, specifically the role of the scrum master. Day 1 was very interesting, we started out by listing questions we have about scrum and outcomes we would like to get from the course. This was an interesting section and highlighted many concerns and misconceptions around scrum. Peter is an excellent instructor and has some great teaching methods. He constantly keeps everyone involved and helps guide people to the solution rather then telling everyone the answer to any of his questions and tasks.
The topics covered for day one where: Agile principles; roles and responsibilities and meetings. What I have take from the course so far is how important it is to define the roles of the players in the team. Also how important it is to get the team to buy in on the agile principles specifically trust and communication. We also briefly touched on how incentives for individuals don't work when they are in a team. The power of self organizing can never be underestimated.
On a side note from discussions with the other participants it was a gentle reminder of how many people are trying to implement agile principles but are finding it very difficult. I really think the best way to get a team running properly using scrum or any other agile methodology is with an external coach to help them. This will definitely help them get over the initial hurdles and get the team in the correct habits and disciples. I'm looking forward to day two tomorrow. I'll blog again on what happens and give my overall thoughts on the next day.

I've finally started my first open source project. In the Agile team I am currently working with, I found I needed a simple metric tool to analyze our code and give some simple code metrics to help the team.
The team was using code coverage as our only metric. Code coverage is a very crude tool to determine the quality of our tests. I wanted some more metrics to help us analyze our code to determine the quality of the code being written. We have as a team set certain standards which must be met for each class being written. Two of these is the lines of code per method and the complexity of the method. I initially looked at Ndepend , which is a fantastic tool, to help us measure these, but Ndepend is more complex then what we required.
From these humble beginning DrivenMetrics was born. DrivenMetrics is a very simple metrics tool that can analyze an assembly to determine the number of lines in a method and the cyclomatic complexity (number of different branches) of a method.
When I set out to write this library I had some simple goals. I wanted to do TDD, I wanted to use Mono.Cecil to learn a bit about it along with ILasm and I wanted to write a console app with some decent commands like any *nix command line tool. I also wanted a good excuse to use github and get a feel for git and then hopefully eventually be cool like all the other cool kids using github :-)
The library works by using Mono.Cecil to disassemble the a .net assembly and then using Mono.Cecil.Pdb to load all the debugging symbols. The two metrics are then run to analyze the code, the results are then written to an html report. The tool is still very much in its infancy and any help from the greater community would be appreciated. To build the code use rake, I have not used albacore or rake.net as my build library but rather the simple BuildUtils.rb from Jeremy Miller's StoryTeller.
I would appreciate any feedback anyone is willing to give. I have a Todo.txt with things I would later like to add to the project. The source code is available on github at: www.github.com/garrensmith/Drivenmetric

One thing that has become more and more important to me since joining my current team is the visibility of the user stories on the board. Its really important to have nice coloured stickies and large visible writing. Sticky colours can represent different things. Our stories are yellow and our tasks are blue. The dreaded pink slip is a bug that has slipped through the unit tests and our tester has found it. This all creates a colour useful board that people want to interact with.
However a very important requirement that often gets neglected is to have big writing on the cards. This does two things. It makes the user stories visible from a distance. And keeps the stories concise.
Often teams have stories that they are working on but at stand up they cant actually see the writing on the board. This limits any discussions about whats happening in the iteration and that story. It also seems to stop any one from being held accountable for what they are working on. Once a story is visible from any where in the team room the board gets used so much more. It also allows any one that walks into the room to fully see what is happening in the iteration very quickly, without having to analyse the board front a very close distance Nothing startling here but it can get neglected.
A really nice side effect of writing a user story with a large black marker is, it forces the story to be short and concise. As Max Pool mentions in his blog. Using a black marker or a large pen along with a smallish sticky forces the story to be short and concise.Thereby helping them be aids in further communication rather then all the information required.

Wow, my first post. I think its only polite to introduce myself before I get down to business in the next posts. I've now been working for Driven Software for one month. Its been a fantastic journey so far and I've been learning so much. My current role is as a scrummaster in one of the agile teams that Driven Software is coaching and helping. It's a great team to work with - a good code base and a really interesting project with lots of potential.
This blog will be focused on my experiences learning and implementing agile principles and methodologies. My main aim will be to mention and highlight things that the textbooks leave out, the tips and tricks that come only with experience and putting Agile into practice. The team I'm working on is using Scrum with some XP methodologies. I am also really interested in Kanban and Lean. I hope to find a way to combine them in an effective way for the teams I work with.
So stay tuned, the fun is about to begin!
*picture courtesty of Deviantart