A fundamental expectation for a high performing Agile team is to have clear requirements to begin building the product(s) with sprints and validating demos. The Agile approach supports the philosophy and the reality as long as the integrity of the requirements remain clear and well thought through. What happens when requirements run amok? Continue reading →

Over the years the software industry has developed many solutions to producing quality software to meet business needs. Software, however, is an ever-changing industry, and our tried methods are failing to keep up with modern development practices. Quality Engineering has made waves in the industry for a few years and is often associated with iterative or agile development processes, as a new way of ensuring quality software. How does Quality Engineering fit in to traditional Quality Assurance to get us working software?

Want a guaranteed way to reduce your spend on software development? Do less. Really. Testing too expensive? Test less! Development too expensive? Develop less! Does this sound too good to be true? The good news is that most teams can benefit tremendously from this approach. The trick is to identify what to do less of.

We have all seen the various studies of software development and the causes of failures to deliver on time and cost overruns. The original Chaos report stated that a mere 16.2% of projects finished on time and budget. There have also been numerous studies surrounding the cost of defects and how it varies depending on when in the lifecycle they are discovered. The consensus, first reported on by Barry Boehm in the 80’s, is that the later in the software process a defect is discovered, the more expensive it becomes. There is some debate as to whether or not this is a hard and fast rule, but suffice to say, defects are rarely free to fix. Agile has cropped up to try and address some of these issues. It has certainly helped. A more recent report on software project failures puts it at 50% – 70% of projects are finishing on time and budget, with the projects using more agile techniques in the upper end of the spectrum. Agile practices are successful in reducing the failure rate by, in part, making the team test the development more frequently and elicit requirements more often. This is wholly dependent on your team’s ability to gather, record, and test requirements efficiently.

Here are some simple techniques that you can slowly introduce to decrease the defect rate due to poor requirements.

It seems today that no discussion about software development is done until someone brings up ‘Agile.’ And for good reason, as Agile is all about agility – an Incremental and iterative delivery model which focuses on business value, encourages flexibility and rapid adoption to change. It’s based on collaborative efforts to achieve common goals.

The agile principles & values are very short and sweet, but in the real world, Agile is not that simple. Remember, it’s a collaborative effort that requires people – Developers, Testers, all the folks involved in the product development who are trying to perform their best in this transforming phase and get things DONE… all the while trying to get accustomed to new processes that get introduced to improve delivery, and where output is expected quickly. Though, as Albert Einstein once said, “in middle of difficulty lies opportunity.” Hence for me as a Test Engineer, this transition to Agile opened up a wide array of opportunity where I could wear many hats – as a developer, as a tester, a customer advocate, a constant learner, and much more.

Here’s how I see each of these hats fitting my head, and perhaps yours, too. Continue reading →

Increasing a team’s productivity is a ubiquitous goal. But, how do you achieve that goal?

To many, it may be tempting to use velocity as a measure of productivity, but the value of a story point can vary significantly over time. Once you get past counterproductive answers like, “let’s inflate all our story points by 50%,” you’re left with options that can actually increase your team’s productivity or, at least, facilitate collaboration between team members.

In my experience, the top two methods of truly increasing productivity involve creating a comfortable work environment, and addressing technical debt and developer concerns. Continue reading →