by John Turner
Posted on June 13, 2011
Estimating and planning are inherently difficult and the mechanisms that Agile apply to these efforts differ significantly in approach and execution. In this book, Mike describes what makes planning so difficult and how an alternative approach can help alleviate the issues that arise with traditional approaches.
Again the quotes that Mike has scattered throughout the book capture the essence of the subject matter and so I have replicated them throughout this review.
Part I - The Problem and the Goal
The first couple of chapters establish why estimating and planning are difficult but also why they are essential. The primary goals of estimating are defined as reducing risk, reducing uncertainty, supporting decision making and establishing trust. The purpose of planning is defined as “finding the optimal answer to the overall product development question of what to build”. Interestingly, a good plan is defined as one that “is sufficiently reliable” which fits well with Agile generally and the principle that the level of planning, estimating, analysis etc. should be ‘just enough’ or ‘barely sufficient’.Read More
by John Turner
Posted on April 06, 2011
Manual code reviewing can be a painful exercise. Typically it involves a developer identifying the files they have modified as part of a feature development or bug fix and then a number of people reviewing the changes in a round table review. Following this there is normally a number of iterations until all the points raised in the review have been addressed.
So, where are the challenges in this approach?
Identifying the files modified as part of a feature development can sometimes be a challenge and because of the dependency on the developer (a human) it is often prone to error (especially if the review occurs after a period of time).
Getting the right people in a room at the same time is the second challenge and often it is this that is the main hurdle to having an effective process for code reviewing. This limits us to reviewers in a single location unless we are using review templates, email, wiki etc. which are all less than ideal.
Finally, the intrusive nature of iterating over points raised in the review results in a process that tends to be treated with mild neglect at best, and at worst complete disdain.
To learn a little more, I have downloaded an evaluation copy and installed it. Pretty straight forward stuff. The download includes a standalone package that executes a web application within an embedded server.
Next, I created a repository, pointing at our SVN repository using the built in repository client. Crucible spends a bit of time creating change sets and indexing the repository and after that I was able to view the all activity on the repository.
From each repository commit, I can create a review and assign reviewers. This helps out with the developer having to identify the change set. The reviewers and the developer can then raise points and iterate (via the web application) over the points raised. Nobody needs to be in the same room at the same time…excellent.
I’m going to spend a bit more time playing around with Crucible to see if it could be truly useful. I want to play around with resource watches and I am looking for a feature that allows me to create developer profiles that trigger reviews based on the experience level of the developer, sensitivity of the source code region or branch etc.
It’s been interesting so far. If you have experience with a similar tool, I’d be interested in hearing about it.
by John Turner
Posted on March 14, 2011
Last week, I attended Mike Cohn’s Certified ScrumMaster course and I must say it was a great opportunity to learn from someone with such a vast amount of experience with Scrum and Agile.
In addition to authoring 3 books on Scrum, Mike publishes many of his presentations on his website, Mountain Goat Software. Having read his books and much of his published material I was quite familiar with what was being presented but still gained so much from listening to Mike’s views on the issues people were raising and his experiences of consulting for a range of companies adopting Agile.
Mike’s presentation style was relaxed and he welcomed questions from the floor throughout. He answered questions with great ease and a confidence that can only come from having experienced many of the issues raised before. His enthusiasm is infectious and for anyone floundering in their Agile adoption, this in and of itself is a great asset.
The two day course includes a number of group activities that reinforce the material and encourage attendees to consider their own experiences with Scrum and Agile. It was very encouraging to hear about how others were adopting Scrum, what issues they experienced and how they addressed them. With everyone coming from different backgrounds and adopting Agile in different ways, I gained a lot from these activities.
I would highly recommend that anyone who is considering adopting Scrum or is acting as Scrum Master consider attending this course. In my opinion, the main differentiator for such courses is the experience of the trainer. In this regard, Mike’s course has to be the benchmark.
by John Turner
Posted on February 22, 2011
User stories are critical to the way in which an agile team discovers and delivers new features. They primarily act as place holders for features which form the product backlog. As the agile team begins a release or iteration, a planning exercise is performed in which user stories will be refined and estimates will be provided (with greater degrees of certainty as the process continues).
The utilisation of user stories by an agile team is significantly different to the way traditional teams utilise use cases or other types of requirement documentation. Through this book, Mike Cohn explains the what, when and how of user stories.Read More
by John Turner
Posted on February 02, 2011
Mike Cohn is a well respected author, trainer and coach. I follow his blog at Mountain Goat Software avidly and am hoping to attend his Certified Scrum Master training in the near future. In the interim, I obtained a copy of the three books he has published and I will be working my way through them as time permits.
I am not new to Agile or Scrum (but of course always learning), but more recently I have been tasked with building a Scrum team, delivering working software, and looking to further spread Scrum. Succeeding with Agile describes how to introduce and spread Scrum within an organisation, and the challengesrewards of such an endeavour. I was looking forward to seeing how my experiences would compare to the experiences relayed by Mike.Read More