I am happy to announce that as of August 28 I am now a Managing Consultant with Neudesic. I believe that this new position will allow me to continue my passion for Agile development and allow me to help more teams and more organizations become more Agile.
What Agile Processes and Diets Have in Common
I have spent a great deal of time lately reading blogs predicting the end of Agile. There are a lot of good people making a lot of good points but I think that there are some major problems the arguments predicting the end of Agile.
There is a very real tendency for people to confuse Agile (the philosophy) with Scrum (a process created to achieve the principles of Agile). Agile is only 16 statements – 4 values and 12 principles – nothing more. Of those 16 statements I am sure that there are some who would argue against them, but these would be a fringe element. Don’t believe me? Follow the links above and see which, if any, a rational software developer or business person would disagree with. You can disagree with them, but principles, in and of themselves, cannot fail.
Continue reading “What Agile Processes and Diets Have in Common”
The Fourth Agile Principle
“Business people and developers must work together daily throughout the project.”
I was in a backlog grooming meeting this morning when I was given reason to reflect on this, the fourth, Agile principle. The reason was that the team I was working with was struggling/arguing about the proper wording of a story. To a few on the team the absolutely precise wording of the story was of paramount importance. While I am a big fan of precision, the vehemence of the need to be precise was a bad smell. It took me some time to realize where the stridency came from.
The Reason Your Agile Implementation will Fail
I have had the good fortune of managing Agile (scrum) implementations at a number of different companies over the years. I have had some great success and some implementations that were not so great. While not unique, my experience is such that I have enough data points to start seeing patterns, especially patterns of failure. That is, while I cannot confidently tell you what will most certainly work in your particular situation, I am eminently qualified to tell you what will not work.
Continue reading “The Reason Your Agile Implementation will Fail”
10 Reasons Why BDD Changes Everything
Recently I have been working with my two scrum teams to implement a BDD approach to our development. I’d have to say that the early results are astounding! While I have always known and believed in BDD in theory, I continue to be amazed by its simple power in practice. For anyone reading who is considering BDD adoption, below are 10 good reasons to move off of the sidelines and embrace BDD:
1. Communication between business and development is extremely focused as a result of common language.
A recent scrum team I lead was struggling during groomiing sessions to come up with valid acceptance criteria. After much excruciating pain we introduced ubiquitous language of BDD. What was taking days was accomplished in just a few hours with better quality forged from increased understanding of expected behavior.
2. Business needs tie directly to the code that is written.
The scenarios can be written by the business, testers and/or developers. Since the scenarios can be written by business and the scenarios create the tests, the code that satisfies the tests satisfies the business requirements. Simple.
3. Developers know what test cases they should write to accommodate TDD.
Most developers will see the wisdom in Test Driven Development, but they find it very hard to decide what tests to create. BDD eliminates this by having tests created directly from scenarios, making the process of deciding which tests to write a moot point.
4. All the underlying benefits of TDD become more easily realized.
These include: safer refactoring, fewer regression defects, greater ability of QA to concentrate on important tests, defects are found and fixed sooner.
5. Code is easier to maintain.
Studies have shown that about 90% of investment in software involves the maintenance of code after the initial “project” is complete. BDD means that all features have tests and these tests show how the code is used and make the code easier to understand and maintain.
6. Code is self documenting.
Similar to the point above. Your test cases and scenarios become your documentation. Using BDD will allow you to have updated documentation that is not separate from code, but integral to code. Documentation can be easily extracted and that documentation is understandable by anyone.
7. Stories are easier to “groom” – breakdown, task and plan.
I can better estimate a story that I have acceptance criteria for and the BDD scenarios become that acceptance criteria. Armed with the scenarios ahead of planning allows a team to better understand the work needed and estimate how long it will take to complete.
8. Teams can be more agile.
Like the point above – when your requirements are better understood, your acceptance criteria better known and estimates more accurate you can be more agile.
9. Developers can be trained / on-boarded easier.
Since the code is self-documenting and test cases show how the code should work, new developers have access to a wealth of information that is usually not available when they are brought on-board a project. This point alone should be a driving reason to adopt BDD as new developer training is usually steep.
10. There is more visibility into team progress and status.
One of the main benefits to Agile is to have visibility into team progress. The tasks for completing a story are broken into well-known pieces that burn down cleanly. For example, each scenario can be added to story as a task and tracked to completion to see how well the story is progressing.
I hope that you find my reasons compelling and that you too try BDD and see if it provides the benefits I outline.
Measuring Agility
On February 7, 2012 I spoke at the Phoenix Scrum Users Group about measuring agility. For those who might be interested, I have posted my presentation on measuring agility.