Thoughts on Agile Coaching

When I tell people I am an Agile Coach, unless they are in IT, I tend to get a lot of strange looks. Most of the time they will say something like, “I get the coaching part, but what the heck is Agile?” It is at this part of the conversation that they experience immediate regret as I launch into an endless barrage of commentary on Agile development.

Lately, however, I have begun to re-examine my own assumptions about what it the Coaching aspect of an Agile Coach is, especially now that there are so many professional coaches looking for work after the end of the regular NFL season.

Continue reading “Thoughts on Agile Coaching”

Agile = Antifragile Part 2

Antifragile by Nassim Nicholas Taleb

I entered my previous post on the subject when I had just begun Taleb’s book Antifragile. As I continue my reading I have run into some very specific passages which lead me to theorize that the reason Agile development works so well is that it is a living, breathing example of what Taleb would call “Antifragile.” I am also coming to the conclusion that Taleb is a truly great contemporary thinker. As I examine my own career, I plan to take to heart many of his suggestions on creating one that is Antifragile.

While I am no in any way paid to sell this book, I encourage all Agile folks to highly consider adding this to their reading list.

Continue reading “Agile = Antifragile Part 2”

Agile = Antifragile?

I am currently reading the book Antifragile: Things that Gain From Disorder by Nassim Nicholas Taleb. I loved two of his other books, The Black Swan: The Impact of the Highly Improbable and Fooled by Randomness: The Hidden Role of Chance in Life and in the Markets so I thought that I would give this one a go.

His central thesis is that there are systems that are not only robust, able to withstand randomness and chaos, but there are those that actually thrive on such events. He calls these “antifragile” as opposed to fragile systems.

Continue reading “Agile = Antifragile?”

Are You a Scrum Master? Be a Gardener.

I have recently been reading Jurgen Appelo’s book Management 3.0: Leading Agile Developers, Developing Agile Leaders. For those wondering what management’s role in an Agile organization should be then this is a good read.

In my current consulting gig I am coaching someone to replace me as a scrum master so we spend a great deal of time talking about Agile, Scrum and what it means to be a scrum master.

One of the things I have always used as a metaphor is the concept of Scrum Master (and managers) as gardeners. Though I may have heard it somewhere and forgot it or it may have reached my subconscious somehow, I came up with the metaphor of gardener because my in-laws live with me and are retired. They spend a great deal of time gardening. It is from their work bringing forth trees, flowers and mountains of vegetables that I took my cue.

Continue reading “Are You a Scrum Master? Be a Gardener.”

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

Welcome to 2012! Getting Back to Agile.

Wow! Just noticed that I had not blogged at all since October of last year! Between starting a new gig on October 31st and the holidays I have been way too busy getting acclimated to my new surroundings, shopping for the perfect holiday gifts, feeding my face with holiday cheer, etc. to spend time writing about Agile development. Time to get back to it. My new year’s resolution is to begin contributing again on a regular basis. It is therapeutic for me and I have found out through Google analytics that there are a number of folks out there that have found some value in my musings. I hope you all had a great holiday season and I wish you the very best in the new year!