Posted on: March 2nd, 2015
As mentioned previously, this blog series will cover the basic patterns only; advanced topics may be addressed in the future.
I will cover the basics on the principles and process before discussing the team and technical practices. Lean Software Development will be covered subsequently. The following topics will be covered in the order (more or less) listed below:
Posted on: February 21st, 2015
by Bill Rinko-Gay
One of the advantages of Agile is the ability to deliver continuous improvements to your customer. If you have experience in traditional development paradigms you a release is usually a mixed bag filled with new functionality and new (and sometimes old) defects. This is frustrating for users and the development team. You seem to always be under a backlog of bugs that keeps the software from delivering all the business value you intended.
Posted on: February 19th, 2015
Pattern Name*** (with confidence level)
Aliases: if any …
Context in which we find the problem
The context is often described via a “situation” rather than stated explicitly. Sometimes, the context is described in terms of the patterns that have already been applied.
Forces or trade-offs behind the pattern
The often contradictory considerations that must be taken into account when choosing a solution to a problem. The relative importance of the forces (those that need to be optimized at the expense of others) is implied by the context.
Posted on: January 28th, 2015
by Bill Rinko-Gay
Now that your stories are chosen and the iteration has been kicked off, is there any reason not to have developers simply start in as quickly as they can on writing the code for the stories? I believe there are 3 reasons to set up a plan for delivering groups of stories to test. First, functional grouping allows for higher quality code delivered faster. Second, functional grouping makes the testing job far easier. Third, functional grouping allows the team to re-plan an incomplete iteration. Let’s look at each of these claims in detail.
Posted on: January 13th, 2015
Recently I was interviewing candidates for a couple of positions on an Agile project. As part of the recruiting process, I had to spend considerable time (aka late nights) going through dozens and dozens of resumes in order to shortlist the ones that seemed promising enough to call for a face-to-face interview.
Posted on: December 16th, 2014
Patterns organize implicit knowledge about how people successfully solve recurring problems. Patterns describe solutions that have been successfully applied on numerous occasions; they are not theoretical abstractions created in ivory towers.
Posted on: November 1st, 2014
What makes a successful Agile team member?
I’ve been asked this question numerous times by people assembling a Scrum or XP team, so I thought I would blog about it. Simply put, attitude is everything.
Posted on: September 6th, 2014
In this series of posts, I will discuss common (and not so-common) problems faced by teams and their leadership trying to adopt Agile practices.
Posted on: July 25th, 2014
Thesis: agile methods can save you money. Are you getting your share? Systematic adoption of agile methods can substantially reduce your project costs; however it can be hard to get these results right away. Most new agile teams don’t see these results until the 3rd or subsequent project. That’s where we come in.
Posted on: June 20th, 2014
The worst thing any team can do is to raise expectations through early success, but be unable to sustain the pace. This happens to many Agile teams due to some simple mistakes made in tracking Team Velocity. As a result of these painful misses, some organizations are getting a bad taste for Agile, and are once again looking to the next big idea to get the performance they want.
Let’s look at the formula for velocity: Velocity = Story Points Accepted/1 sprint
Pitfall #1: Story Points Accepted.