Redefining Heroics

Last Updated on Wednesday, 26 March 2014 09:36 Written by Tim Wise Tuesday, 18 March 2014 10:25

Heroics

Recently, while working with one of our customers the topic of heroics came up… okay, this comes up all the time :)

It seems hard to argue with heroics, from the time we were young we’ve heard stories of heroes in our family tree or national history. The term is attributed with acts of valor and selflessness.

Upon closer examination, frequently we find that the heroics that are being described in many enterprises could be better attributed with undisciplined, or even un-intentional delivery….

How do you define a hero in your business?
How does your business define a hero?
How do you reward the heroes?

A bunch of companies define a hero as someone who swoops into a project to save the day. They work a ton of overtime and get the job done by slaying the vicious dragon. They are capable of quickly stitching up a troubled problem just enough to get it to market.

It’s time for this paradigm to change.

When transitioning to agile there is a high value placed on one of the 12 principles of agile development, the indefinite, sustainable pace. Given the traditional “hero”, we immediately have a conflict. So let’s change the definition of the hero.

Heroics Redefined

  • What it is not:
    • working overtime
    • being the goto guy
    • taking over for others
    • saving a project at the last minute
    • the number of bugs you find
    • the total lines of code you write
  • What it is:
    • Sharing in successes and failures with the team
    • Practicing commander’s intent by helping the team generate new ideas of how to achieve a goal with an unknown path.
    • Demonstrable selflessness in self promotion
    • Creating a new team option by developing a new Generalist skill
    • Reducing team cycle time

 

This blog was co-written by Isaac Hogue.

Learn More

Building the right software…right, It’s easy…RIGHT?

Last Updated on Tuesday, 4 June 2013 04:46 Written by Isaac Hogue Tuesday, 4 June 2013 04:45

We encourage the teams we coach to keep their eye on the ball: Delivering a product that reaches a defined goal and thereby delivers value to its stakeholders in the most efficient, predictable and reliable way possible.  This process of delivery frequently includes helping teams improve their internal product elaboration and development practices through the use of Behavior Driven Development (BDD) and Test Driven Development (TDD).   And in doing so, it is my observation that there is a bit of confusion over the distinctions between how to focus teams on building the right software, and building the software right.

It seems that one of the key drivers for this confusion has to do with where Acceptance Test Driven Development (ATDD) fits into the development lifecycle.  At present, BDD and ATDD both loosely describe a clarification process for iterating or incrementing around acceptance criteria for a given business goal that results in a just-in-time scenario or example-based specification.

What if we clarified things a bit…?

Perhaps we could reduce confusion around “building the right software… right” by redefining the specific meaning and places for BDD and ATDD as follows:

- Formalize the meaning of BDD around the practice of defining the “right” product through goal-oriented behaviors or scenarios.

- Formalize the meaning of ATDD around the practice of building the “right” product  by connecting behaviors to automated acceptance tests.

How about the following as a high-level map for “building the right software… right”:

(1)

Start with BDD to clarify the goal, defining behavior-based scenarios that will become acceptance criteria for scenario-oriented user stories

(2)

Then, (this is the redefinition) use ATDD as the iteration’s goal-oriented roadmap, where the delivery team transforms each behavior into a set of executable steps, or executable acceptance tests, using technologies such as FitNesse, Cucumber, or similar

(3)

And finally use TDD’s Red-Green-Clean cycles to develop a high quality product with the functionality required to see each step of the executable acceptance tests pass

This approach clarifies the terms and provides a specific meaning and place in the development lifecycle for BDD, ATDD, and TDD.  In my experience the above map has reduced confusion around how to “Build the right software… right”.

Let me know what you think.  I’m eager to hear your thoughts and concerns around such a mapping.

Learn More

All About Agile… Guest Post

Last Updated on Friday, 16 November 2012 12:51 Written by Mike Cottmeyer Tuesday, 4 August 2009 11:48

A week or so ago Kelly Waters reached out and asked me to do a guest post for his blog All About Agile. Kelly has been writing on Agile topics for a while and was one of the first bloggers that I ever started following. Needless to say it was quite an honor and I was happy to contribute. My post is called “The One Million Dollar Question“… it’s about teamwork… and I think you’ll like it.

Hop on over and take a look… and if you are not already subscribed to Kelly’s blog… I highly recommend you take this opportunity to do so. Happy reading!
Learn More