Recent Agile Speaking Engagements

Boy it’s been some time since I have blogged! I have been busy with all things business, personal and have had a great number of recent speaking engagements with any free time I have been able to find. I am passionate about Agile and love the opportunity that speaking brings.

My most recent gigs included a bunch of talks when my body was suffering a annoying fall head cold.

Continue reading “Recent Agile Speaking Engagements”

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

Goal, larry apke, bdd

Goal written on whiteboard

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.

Larry Apke

What is Backlog Grooming and How Much Time Should I Invest?

What is Backlog Grooming? - Larry Apke
After my experience working with dozens of scrum teams in transitioning to Agile, I am thoroughly convinced that a great deal of Agile success is wrapped up in the two things that most lower functioning teams do not do well – Release Planning and Backlog Grooming.

So what is backlog grooming?

Personally, I do not like the words “backlog grooming.” To me it is merely an extension of sprint planning so forgive me when I refer to this as extended sprint planning. I think one of the things that early Scrum made a mistake on is that it expected sprint planning to happen the very first day of the sprint in what for many are LONG planning sessions. In fact, I would not be surprised if the term backlog grooming was coined so that early Agilites could save face!

In other words, let’s call this something other than sprint planning so we don’t have to admit we were not 100% right on what sprint planning should be. (Given the religious nature of Agile and Scrum I fully expect to be excommunicated and eviscerated so please feel free to comment).

Continue reading “What is Backlog Grooming and How Much Time Should I Invest?”