Integral Agile Journal
Posted on: August 5th, 2015
Software Development is Not Manufacturing
… Your company likens software development to a production (manufacturing) environment and expects people and processes to reflect the same.
A number of organizations use Waterfall based processes for software development that call for all requirements to be gathered at the start of a project.
Posted on: June 30th, 2015
- How fast are we going?
- What’s our biggest obstacle to velocity?
- Does we have enough requirements defined?
- Are we building the most valuable things we can?
- Is there something we’re deferring that should be worked on now?
- Are we getting things all the way done?
- What would we have if we had to ship tomorrow?
Posted on: May 4th, 2015
- Are we tracking to the business case?
- How much time & cost remain to complete the project?
- Are we over or under budget?
- How can I give my customer even more value?
- What will I have ready to ship & when?
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.