|
Wednesday, 01 July 2009 |
In December of 2007 I wrote a review for ClearContext IMS 4.0 plugin for Microsoft Outlook. Since that time, they have added some new features and fixed a lot of bugs. Like I said before, if you are reading this, just buy the tool now - it will change your email management life. Want more? read on... |
|
Read more... [ClearContext 4.6 Review]
|
|
|
Wednesday, 18 March 2009 |
After many delays, I have posted my 14 day Sprint timeline diagrams. Please see the reference tab above and look under Scrum Resources. I will update these with small requirements over the next few months as I revisit and rethink some of the words.
|
|
|
Friday, 06 March 2009 |
|
Ward and Jim get together at Agile Open Northwest in Feb 2009 to talk about CI and merge. Worth the eight minute watch.
See the video here
|
|
|
Tuesday, 10 February 2009 |
|
The daily standup meeting, or daily scrum, often does not get the respect it deserves. Done correctly, daily standup meetings keep everyone on the same page for the daily deliveries and moving as one toward the sprint goal. Productive daily standup meetings can be a challenge for some. If a team strays from the strict three question and answer format, they soon will find that they’re spending far too much time talking and not enough time doing. Common obstacles teams run into include:
- Should we do a deep dive in the meeting?
- What do we do when people show up late?
- What if one person constantly dominates the meeting?
- We can’t get our meeting done in fifteen minutes. What do we do?
Solving these all-too-common problems is essential to running a productive daily standup meeting. Let’s take a look at a story about an ineffective daily standup, discuss what went wrong and how to fix it, then find ways to ensure that your team’s daily standup becomes/stays productive. Download the PDF - please provide feedback.
|
|
|
Monday, 02 February 2009 |
|
Should each project have a sprint (or two) dedicated to fixing defects? How about a stabilization phase? After all, we need to reach the mythical code complete phase, right?
Defect management is one of the easiest things to forego on any agile project. After all, we have been conditioned to address our defects at the end of our projects. Failing to deal with these defects on an ongoing basis, though, results only in low-quality software and the need to “build quality into the system” during a defect-fixing phase or sprint. So how should a team manage its defects? There are several techniques out there, but I have found one that I have successfully applied to a large majority of my projects. Before we take a look at it, let’s start with the story that led to this pattern. Read the PDF and provide feedback!
|
|
|
Friday, 09 January 2009 |
|
In November, 2008 there was a discussion on the Scrum Development yahoo group about how Scrum benefits the individual, and why anyone would want to work on a Scrum team. Here is what was asked:
What does Scrum (or other Agile umbrella method) offer to an individual seeking improvement?I realize that TDD helps one improve one's skillset and so do some of the other Agile practices. But, specifically to Scrum, which practices are intended to address individual achievement/improvement? The reason I ask is because teams have stronger and weaker members and would like to know both what the team can do to help the weaker embers and what the weaker members can do to help themselves. While till attaining/maintaining a high velocity, of course. Preferably with o overtime. This got me thinking, what are the values and benefits? It turns out it was easier to answer than I thought. I had been saying these things for years, in workshops and on teams. Here they are: People who work on Scrum teams will have the opportunity to improve/practice/polish/learn/grow in the following areas - Technical skills (any) by working in a collaborative space, hopefully pair programming
- Interpersonal skills through daily conversation and human interaction
- Presentation skills by having to show working software every two to four weeks
- Relationship skills by having to work with people you may or may not especially like
- Leadership skills by teaching others your unique perspective on how you have solved problems in the past
- Self confidence by going out of your comfort zone, stretching yourself and growing
- Self awareness by understanding what actions, or inactions, your decisions have on others and the system you are building
- Communication skills, both verbal and non-verbal, through daily standup meetings, pair programming, customer demo meetings, sprint planning meetings
- Estimation skills by having a better understanding of the whole system through the practices of collaborative estimation and collective code ownership
- Continuous improvement by having the discipline and trust in your team to allow the items above to become a reality
I use this list when I meet with new teams that are adopting Scrum. Try it out and let me know how it goes!
|
|
|
Friday, 21 November 2008 |
|
A big thank you to everyone who attended my talks at the SQE Agile Development 2008 Conference in Orlando, Florida.
You can download the slides on the resources page or you can grab them here:
|
|
|
|
<< Start < Prev 1 2 3 4 Next > End >>
|
| Results 1 - 8 of 30 |