BDD - A team oriented activity

Probably one of the harder elements of Agile that teams struggle with is the art of collaboration. Our experiences over the years have taught us to treat functional groups such as BA's, Devs and QA as separate entities each with their own perspective and each distrustful of the others abilities to deliver.  How many times in QA do we hear the phrase 'Just toss it over to QA and let them deal with it'. 

We forget so easily that what we deliver for a customer is the sum total of our efforts, not just of individuals.  The Chicago Bulls were a good team with just Michael Jordan, but only when they were able to blend ALL of the skills of the team were they able to win championships.  Scrum is about team.

Getting your Scrum team to actually work as a team is one of the key efforts that everyone needs to make and BDD is a way that can help teams  work collaboratively to  build what I call contextually rich user stories.

You can't rely on just one or two people to write user stories and acceptance criteria as there is a limit to the context of what any one person can know.  With ever growing complexity in business and technology the more people who can collaborate the more context that is captured in the story.

Does it sound like heavy overhead?  It shouldn't.  I'm sure you have all spent hours pouring over Business or Product Development documents trying to glean enough information to build a design that will work for the next 6 months (which we know doesn't happen on any planet in this solar system).  We've always spent time trying to understand what is being asked for but in Agile we spend smaller increments of time on writing details that matter.

The most successful teams I've worked with have adopted this type of approach for building out BDD acceptance criteria:

• Start of Sprint -

1. During the first two days of the Sprint the QA lead and Product Owner work together to develop (and or complete) BDD acceptance criteria for the next upcoming sprint.
2. By day three the development team should start delivering stories to QA for testing.  Additionally QA can begin their automation efforts via BDD examples with tools such as Cucumber, Fitnesse, Capybara....
3. The engineering team needs to plan to complete all of the story development so that the last two days are open for them to  review the acceptance criteria and make changes/suggestions to the PO.  The team is also completing their designs for the upcoming sprint during the last two days and fixing any bugs that are discovered in testing.

The key to this process is that before the team commits to the sprint they must all review and agree to the scope of the BDD acceptance test examples.  Without this discipline, the scope of the story and sprint will not be as precise.

As I've told my teams in the past, moving to writing BDD acceptance criteria is a mind shift in how you view both requirements and testing.  Both Development and QA can consume them for their individual efforts, but in the end, if they work against what is defined in the BDD they will both be on the same page functionally.

BDD takes the guess work out of what is being developed and that's a good thing.  For Sprints to go quickly and with high quality,  teams have to understand exactly what they are doing.  To steal from one of my favorite phrases from Bull Durham 'Don't think, it only hurts the ball club'.

BDD provides clarity for the entire team and makes demos go smoothly.

Ensuring that the team provides input, review and commitment to BDD acceptance criteria keeps everyone focused on doing just what is needed.

Behavior Driven Development is more than Automation

Recently while working with an organization going through a large Agile adoption I had the opportunity to work with a team that was open to adopting BDD acceptance criteria story development.  One of the key differences for this team was that this was the first time that they had experienced a collaborative story development effort.  Prior to this most teams in the organization looked to the Product Owner to write all of the stories, which led to stories that were not contextually rich, had little to no acceptance criteria and were difficult to demo at the end of the sprint.

As I discussed the success of the teams use of BDD I was surprised to hear feedback that indicated the organization wasn't ready for the heavy lift of using BDD and that I hadn't moved the team into BDD because their final work wasn't automated.

If that is your position then I think you are missing the point of BDD.  Yes BDD is great in that when you right acceptance criteria in the Given/When/Then format and build your example tables correctly you can obtain automation fairly easily with tools such as Cucumber, Fitnesse and a whole host of tools that have been developed to support this very successful way to build out what I call 'contextually rich' user stories.

However even if you don't automate your BDD acceptance criteria, the value you get from understanding the behavior of the features you are going to build is invaluable.

BDD came about because Dan North realized that TDD and really great code meant nothing if it didn't deliver the value or functionality that the stakeholder needed.  This concept was clearly illustrated for me at one organization I worked for when the Development Manager was lamenting about a Product his team was enhancing was pulled from the market because they didn't deliver on time in order for the organization to stay competitive in the market.  He said 'If only they could see all of the cool code that we've written'....To which I said 'Business doesn't care about code they care about delivery" no matter how great your product is from a code perspective it matters not at all if you don't deliver it when your customer needs it.

For those of you who are exploring the use of BDD with your Scrum teams understand that there are essentially two separate efforts that effective teams are working on:

1. Team collaboration - Successful teams using BDD understand that they all need to be involved when building out user story context with Given/When/Then.  In fact I would argue that this is the most important element that drives a clear understanding of what we are building and guidance to when a user story is done.

2. Automation - One of key components of successful Agile teams is the development and maintenance of an effective automation suite.  Utilizing BDD provides an effective way for teams to obtain high levels of automation and do so within the Sprint that they are working in.  A common mistake of newer Agile teams is to develop in one sprint and test in the next and sometimes automate in the third.  Using BDD automation tools such as Cucumber with well written acceptance criteria (I'll provide examples of well written BDD in my next blog post)

A third benefit of BDD is that a Scrum Team builds a clear understanding of the scope of the story.  Since everyone participates in the development of the acceptance criteria, if a scenario is missed, it's a shared miss - No finger pointing, just manage the new scope with a new story and prioritize it in the backlog.

I've helped a number of organizations implement BDD effectively,  one of which did not have any automation at all.  The use of BDD acceptance criteria writing almost immediately improved the understanding of the features being developed and helped my QA team write significantly more test cases than they had been doing.  This effort led to a measurable improvement in Quality even before we added the automation suite later.

Having come from a waterfall world many years ago I can tell you that when you 'get' BDD,  it changes the way that you look at requirements and provides you with a mental framework that you can quickly use to model what is going to be built.

After a few months of using this format at Disney the Product Owners were uniform in their agreement that there simply was no other way that they would want to work with their teams.

Automation IS our goal, but it is not what defines BDD.

Being Agile - Say it, Do it, Prove it

I was working with a team recently and as we talked about all of the planning that Agile entails, I broke it down into very simple terms - Say it , Do it , Prove it. That is really what Agile is about.  Anything else outside of these three concepts is noise to your ability to deliver product and services to internal and external customers.  As Product Owners in an Agile organization, you need to understand all of the effort and dynamics involved in getting your teams to Say it, Do it, Prove it.

Delivering what you say you are going to deliver is the best way to build credibility with your stakeholders.

For Agile teams, this translates into being effective at decomposing your stories into small enough increments so that you are confident in your understanding of the user story and estimates that the team believes in.

1. Say it = Release Planning and Backlog Grooming -
   1. Starting at a high level, the Product Owner is responsible for saying what is important to the organization from a value standpoint and beginning the process of developing a user story backlog that supports this vision.
   2. User story decomposition is so important to effective Agile teams and the Product Owner must start with a set of well-formed stories that provide context to the team.
   3. What is 'context'?   Context is anything that provides definition.  It is basically what the product should do from a functional standpoint.  One of the biggest mistakes many teams make is writing declarative stories that start with the 'How'.  This,\ in turn,  puts the technical team on the defensive as they may have many different ways to implement the feature.  As a Product Owner, be sure to steer clear of writing stories that define how you think the feature story should be implemented.  I know that as we all become well versed in technology there is a strong desire to show off our technical chops, however, as a PO you need to provide context from a business standpoint that your tech teams can consume. I've heard time and again from engineers that they would really like to understand how what they are developing delivers business value or solves a particular pain point for the customer.  The team works much more effectively when they are completely grounded in the business context of what they are building.
2. Do it = Sprint execution 
   1. An important element for teams to address once they are ready to take stories into a sprint, is that the goal during the Release Planning and Backlog Grooming activities was to begin to build out the context of 'How' the story will be implemented.  It is so important for teams to understand that there is essentially a handoff from the PO to the Scrum Team and that each of them is responsible for building what I call contextually rich user stories.  Gojko Adzic calls this Specifications by Example.  Effective teams who deliver fast and with high quality work closely as a team.
   2.  I believe that the combination of User driven stories and context driven specifications (examples) forms an extremely strong definition of both Ready and Done. which is why I coach my teams to utilize BDD as the basis for developing their User Story acceptance criteria.  The team works together to complete BDD acceptance criteria forming a clear understanding of the boundaries of the feature.  This provides the PO with a concise view of what to expect during the Demo.
   3. Another key benefit of writing BDD as part of your user story writing is that the test automation engineers can easily consume this as part of their code development for the automation.  PO's should push to get to this level of context as it also means that your test engineers can start developing their test automation code once the story is ready for development.  They can essentially perform TDD in that they can write their automation before the feature is actually developed.  Once developed the automation should run cleanly and both speed and quality are attained.
   4. The goal of teams should be to deliver user stories that do not require much further elaboration once the sprint begins.  You want your teams focused on delivery ,not on discovery.
3. Prove it = Retrospective
   1. You have done all of the work to clearly define your user stories with high levels of context.  With all of this effort, the Retrospective should be an easy affair to show the work that was defined in the stories.  The PO should not have any surprises.  In fact, if the team misses any test scenarios after the story has been started, the PO should consider that more of a missed requirement over anything else.  Since the entire team developed the stories,  there can be no finger-pointing at anyone.  It was a shared miss and everyone must accept it.

It sounds really simple when broken down into these 3 basics phrases.  The truth is that 'Being Agile' is much more involved than simply 'Doing Agile'.

"Being Agile" means exposing all of the inefficiencies in your product development processes.  It requires that the organization be completely honest in assessing what is not working and committing to letting the teams that do the work fix these processes.  You cannot top down drive the type of organizational change that is required for Agile continuous improvement.  Real organizational change is fostered at the top but truly owned by the Scrum teams that form in support of any Agile adoption.

Building great products

A long time ago I left college with the notion that I wanted to ultimately run my own business, my job experiences were purposefully diverse, giving me experience in Sales, Banking, Management and ultimately IT and luckily I've been able to do that several times. While I wasn't always engaged in the world of technology during some of its growth, I've always been involved in building and delivering great product.

What I learned during this time is that building great products is much like writing a symphony, you have many instruments that you can choose from for your piece, but if you don't bring them together in the right way, if you don't understand the limitations of those instruments you don't end up with a masterpiece, but rather something that might sound like noise.

I have often used the concept of a symphony as an example for the way that we manage software project delivery.  You have an individual, Conductor, who is responsible for ensuring that everyone in the symphony is playing their parts correctly, are watching the conductor for queues on changes that might be made in the middle of the concert.  When everything comes together correctly you get beautiful music, when it doesn't.....not so nice.  Building software in an Agile world is much like this, the Conductor is the Product Owner and the delivery teams are the musicians who watch the conductor for their queues when small changes are made in the delivery.

Understanding your craft, be it song writing, engineering, sales, etc....is an important element of you becoming great at what you do.  The craft of building great products is being able to master how to manage all of these different crafts in order to bring about something great.  My wife, who is an Arts Manager, has often likened software development as just as much as artists realm as an engineering one.  I have another post I'm writing that explores this in more depth.

For those of us who build a product with software we define our vision, much like a composer will do.  Once the vision is identified then we determine what components (or instruments) we will need to accomplish our vision.

What are the types of instruments that we use build product with software?

1. Product Owners/Managers
2. Product Developers
3. Product Testers
4. Software - Java, .Net, etc...
5. Hardware - Servers, Databases, etc..

What is our endgame with these ingredients?  Build product with software that delivers functionality that customers want and are willing to pay for.  If our instruments aren't aligned with this primary goal, we'll waste time and money and deliver quality that isn't what the customer expected.

When we talk about quality in the software world, we talk about defects, code quality, etc..., however from a holistic standpoint none of this matters if you haven't delivered a product that people want.  Your first goal as a Product Development team is to understand and align yourself to this completely.  If you focus more on delivering technical quality then you aren't delivering the quality that the customer is expecting. Using the example of a restaurant, I can cook and deliver the absolutely best Pasta Primavera to you, but if in fact you wanted a Steak, then I have missed your quality expectations.  It doesn't matter how good the food was, how well it was delivered, it failed to meet your expectations so the entire element of how you perceive the quality of my business is affected.

I think we are moving towards understanding this with concepts such as Personas, however I'll be honest I've been in only one place  where we paid attention to these personas as we built our product,  I think many of our high-tech companies that have evolved over the past 10 years are much more focused on the technical aspects of the product over what the customer wants.  Example?  Facebook, Google.  They release new features and then gauge response and then remove or modify the product features based upon feedback.   I think long-term this is not the paradigm that will bring success to most organizations, eventually you need to be driving your company based upon what your customers want, not what seems cool and technically challenging.

Building great product has absolutely nothing to do with technology.  Technology is merely the enabler of a product that customers want and are willing to pay for.   If we could find a different way to deliver the product without technology (or at least the technology we have in place today) we would do that in a heartbeat.

If we are to re-align our instruments as a technology team delivering quality what would they look like?

1. A clear understanding of what the customer wants, ensuring that whatever we work on is aligned to that need.
2. A clear set of requirements that support that need.  Agile provides a process for capturing user needs with User Stories, however the key miss I see with most user stories is that they aren't written to align to the customer need.
3. A set of software specifications that support the User driven stories.
   1.  What do we mean specifications? Using tools and processes such as TDD and BDD to define the user story at the technical level.  Again another big miss I see with teams who write user stories is their acceptance criteria stays too high level to understand the technical elements we need to delivery as part of our technical quality.
   2. Though Agile is about conversations over documentation, we really can't deliver high quality software unless we build a shared understanding of the user stories and a depth of understanding via specifications.
4. A feedback loop that delivers customer feedback to everything we do.

Notice, in the new set of instruments there is no mention of technology, how you deliver a feature is entirely up to the technologists.  Their responsibility is to deliver customer features, the expectation as professionals is that they will do it with quality.

Delivering great products comes from the intersection of  customer needs and high quality technology.  Great product can survive from lack of technical quality in the short team but it can never survive the lack of focus on features driven by the customer.

Agile Certifications - Why they aren't neccessary

Agile started many years ago with some basic (note I do not say simple) concepts related to how we should work together to build better software products.  Though I struggle with the notion that mere communication among individuals can deliver quality software, it can provide a product that is closer in alignment with the product owner's vision. I remember as Agile unfolded there was a debate on whether we needed things such as certifications.  I recall the argument that the very process of creating certifications for things such as Scrum would defeat the very benefits that the Agile manifesto was attempting to address.

Now many years into the manifesto I have to say that these certifications have brought an element of rigor that 'can' be beneficial but I think often stifle the creativity that can come out of Agile teamwork.  Certifications do not make you a great Scrum Master nor a Product Owner, they merely convey that you have taken a 1-2 day class that has provided you with the  evolved standards that Scrum has been defined to be.

I've been involved in a number of Agile transformations along with working in already high performing agile organizations and none of them are alike.  One thing I have taken  away is that teams who are provided space to try new things often find creative ways to solve the unique challenges they face.

As someone who started in Agile from the project management perspective I quickly realized that I was not your standard project manager who managed against a project plan, happily disconnected from my team.  No I was always learning, asking questions, it is how I went from a project manager into QA, because I took an active role in being in helping my team deliver great software.  Through out it all I was most focused on getting feedback from my team in order to improve our processes.

In those early days there were no certifications, we just took the concepts and did what worked and continued to evaluate how and what we did.  With certifications there is almost a cookie cutter approach to engaging Agile that I don't believe was the intent of the original writers of the manifesto.

Scrum and the processes it provides are extremely important, I'm not saying that these don't bring value.  What I am saying is that you don't need certifications in order to be good at Agile and Scrum.

I always tell my teams, Agile isn't easy, it will highlight every weakness in your delivery process and force you to ask hard questions about how much the organization is committed to changing the way they deliver a product.  Having a Scrum Master or Product Owner certification does not help in these situations.  What does help is working with an experienced Agile coach who has been in the trenches, who is experienced in the demands that Agile and the transformation present.

As an organization looking to adopt Agile, getting certifications for your team is not a requirement to working the concepts that so many teams use to be successful in Agile.  Don't let certifying your team be a precursor to moving toward Agile.  At one organization I worked at we took this approach and ultimately it wasn't necessary as the majority of the people who were 'certified' were not involved in working in daily Scrum team activities.

An experienced coach will be able to guide you through how to work as a team, manage communication and change the way that you deliver software products and your organization.

And yes I have several certifications including CPO and CSM and know that these are now almost standard requirements for anyone wanting to work in an Agile environment However if you are just starting Agile don't assume that someone who has been certified is necessarily an experienced practioner.  When looking for help in adopting Agile you should look for someone who has been involved in more than 5 different Agile implementations or organizations, perspective is worth it's weight in gold.

Product Discovery - Uncover your backlog in Agile

Much of the writing and learning that you gain about Agile focuses on the day to day nuts and bolts part of execution, however I think that teams are missing a much greater opportunity to improve the quality of both execution and delivery if they spent more time developing their backlog. My teams consistently hear me talk about getting contextually rich user stories  as part being able to delivery quickly and with high quality.

In order to get to the point that we have contextually rich user stories teams need to spend some dedicated time building out their product backlog.

Whether you are developing an entirely new product or simply adding features to your existing product, taking the time to fully investigate and build out your User Story backlog is important.

Much is said about doing just enough documentation to get the job done, but what I've seen over the years is that teams that fail to build out user stories that have a specific set of information in them will spend more time trying to figure out what they are doing IN the sprint which negatively impacts quality and the teams velocity.

There is nothing wrong with spending time before a set of sprints building a strong understanding of what the team is going to do.

You wouldn't try to build a house without a certain level of planning ahead of time.  Agile teams often arrive at the start of their Sprints with nothing more than a set of ideas.  If builders showed up at a job site to start building your home with only a rough idea of what you wanted, they couldn't go very quickly nor would they build something of quality that met your needs and expectations.  You might get what you want, but probably not.

Agile teams need to take this approach a bit more, spending time with their Product Managers to not just flush out the features that are wanted, but more importantly the lower level details needed to provide the team an ability to plan more effectively and deliver high quality products.

If a builder shows  up and wanted to pour a basement, they need to know more than that.  They need to know the size of the basement (ie how much concrete do I need) , if the site has been prepared, has drainage been considered, etc.... Building anything of quality requires planning before you can deliver.

Agile I think too often believes that you can go lite on the planning and still delivery quality.  If you think that refactoring is the golden ticket for lack of planning, it's not.  Rarely do teams have time to do the amount of refactoring they require to keep their applications clean and scalable.  This leads to applications that grow in complexity requiring even more time to add features, all the while thinking that we can go lite on planning.

As you consider Agile as a development process, don't forget that Product Discovery is an important element of delivering high quality product quickly.

New Blog Name - Sound Agile

As you may have noticed I updated the name on my blog to better reflect where I am going with content and my overall beliefs about what sound Agile practices should be. Sound Agile is derived from the attributes of sound:

sound

1. free from injury, damage, defect, disease, etc.; in good condition; healthy; robust: a sound heart; a sound mind.

2. financially strong, secure, or reliable: a sound business; sound investments.

3. competent, sensible, or valid: sound judgment.

4. having no defect as to truth, justice, wisdom, or reason: sound advice.

5. of substantial or enduring character: sound moral values.

I'll be overlaying my writing on top of Sound to reflect the need I believe to focus on sound judgement over growing process.

You will see my website www.soundagile.com take shape in the next few weeks, please check it out.

"At the end of the day, I'm being paid to write code."

"At the end of the day, I'm being paid to write code.".

Agile Discovery - Addressing fixed date/scope projects through upfront planning

Most of the Agile projects (perhaps all) that I have worked on over the years have started with an express understanding of scope AND a fixed date for the delivery.  One of the common myths I think people have about Agile is that when you 'go' Agile this issue goes away, it doesn't. By ignoring the need for some level of planning prior to taking on an Agile project, teams start with a deficit of knowledge (ie well groomed story backlog).

I'm a huge proponent of having teams take on their project backlog with an initial Discovery workshop that includes the entire team and can take anywhere from 1-5 days depending upon the size and scope of the project being considered.

I've used this approach to plan out a 6 month release with tremendous success, typically delivering more value than the stakeholder asked for and with virtually no defects.

I think this planning effort is key for teams to realize high levels of iteration productivity.  The time to build context in your stories and features is not after the iteration (or train) has left the station.

Many of you, especially Product Owners, will make the assumption that it's a waste of time for the team to perform a Discovery session that builds out stories and acceptance criteria at a lower level for more than an iteration out.  The concern that everyone has is that if we don't start coding immediately we'll be behind and won't make our commitment.  The truth?  Having a user story backlog that is well formed and understood by the team allows the team to stay focused and productive over trying to design and address context while trying to actually code the feature.

What do I mean by Discovery?

Once a team receives a project from their stakeholders with a set date for delivery, the 'scope' of the project then becomes the key to meeting the delivery expectations.

If the team just starts coding with the first few stories that are available they are already in story deficit, they don't have enough work to keep the iteration engine going, meaning Backlog Grooming, Pre-Iteration Planning and Current Iteration planning.  High functioning Agile teams understand that the iteration engine only works when you have a product backlog that is clearly prioritized, has sufficient context and can be worked on with no real impediments.

For example if a team has a six month project which consists of 12 two week iterations the team needs to identify the following:

• Story Themes - What are the functional slices of the features/product you are delivering.  Themes form the basis for building your release plan.  Themes will hold the high level user stories that are identified in Discovery, typically greater than 40 points.
• Epics - These are the larger User Stories that are identified during discovery as they relate to the Story Themes.  These will typically be larger than 40 points.
• Features - As Epics are decomposed they are further brought into focus as distinct features that can be worked on a independent units of work.  Features will typically be sized between 21-40 points and have a much greater shared understanding by the team of what it will take to deliver this.
• User Stories - As teams continue to decompose Features that are able to get to the granular set of work, complete with Acceptance Criteria (such as BDD).  These are the items that are addressed in iteration planning.

My experience over the years has seen teams be able to spend anywhere from 2-5 days working through the Themes, Epics and Features such that we have a strong understanding of how the project will unfold from a release standpoint and a lower level set of Features and User Stories that help UX work ahead of the Delivery team.  This process has proven successful for the teams I've worked with who have tried it.

I'm not suggesting that an entire 12 iteration project needs to be flushed out to the user story task level, however getting further than the Epic level with a few features and a few stories will allow teams to be very focused on iteration level delivery on a consistent basis.

This effort can provide a higher level confidence level for the team with a small spike of investment in upfront planning.

Planning is an important element of successful Agile teams, don't short change it when working through new features/functionality.

Hurdling through Product Delivery part 2

Product delivery is a discipline that requires the involvement of all segments of an organization:

1. Customers and Stakeholders
2. Product Owner
3. Scrum Master
4. Delivery Team - UX/Dev/QA
5. Operations
6. Services and other specialized teams that touch the product in anyway as it moves from concept to delivery to production.

As I mentioned in my previous entry, maximizing the smoothness of product delivery is like running the hurdles.  How so?

What happens when you first start running the hurdles with no experience?  You stand at the starting line and then you start to run.  As you approach the first hurdle you try to determine how you are going to make that first jump.

Is that first approach smooth?  Probably not.  You probably came up to that first hurdle and maybe stutter-stepped before trying to jump or even had to stop before you actually tried to get over the hurdle.   Why?  Because you didn't know what to expect, you didn't know what you didn't know as you ran toward that first hurdle.  Maybe you made it over all of the hurdles but it probably wasn't pretty, perhaps you fell a few times in the process.

So with skinned knees and wounded pride you make your way back to the starting line and you try again and again and again.

In this process you are setting your baseline performance.  Are you getting better with each attempt?  Hopefully....because we really want to be a successful sprinter.

As you continue training, perhaps even getting a coach, you start to break down your individual steps as as you go from hurdle to hurdle.  Over time and through practice and experimentation you make small changes in order to maximize your speed and efficiency in getting to, over and past each hurdle.  Not paying atttention to how you land after a hurdle means you may not approch thet next hurdle most efficiently.  As you continue this practice and feedback loop (Retrospective) you can begin to reach ever higher levels of speed and success.

Eventually you don't see the hurdles, they are just part of the process of completing the race.  They aren't obstacles anymore.

This approach is how athletes get to world class levels.

How is Product Delivery like running the hurdles?  With each step from ideation to delivery there are hurdles that we face that keep the entire delivery process from being efficienct and effective.

And more importantly, whereas a sprinter has the luxury of knowing that their hurdles are 30ft apart and either 39"-42" tall, Agile Product Delivery teams don't always know where their hurdles are at, but through effective use of Scrum, teams can begin to identify where the hurdles are and start the process of learning how to approach and exit each of those hurdles, using Retrospectives.

We too can get to a point where our hurdles are just part of the process and if you aren't running the hurdles anymore what are you running?  A sprint.....

What are some of the common hurdles that we face in Agile Product Delivery?

• UX Design not clear
• Lack of Product Vision
• Poorly formed product backlog/user stories
• Lack of technical excellence - Continuous Integration, Automation, code reviews.

Successful Agile delivery is all about identifying your hurdles, getting them lined up appropriately and working to maximize the efficiency of the steps we need to take to get to the end.

As with world class athletes we need to continue to evaluate our approach and drive world class product delivery for our customers.

Delivering Software Fast is Like Running the Hurdles

I had the opportunity to attend a couple of Dan North's Deliberate Discovery sessions at the Better Software East conference this month and as he talked about how we want to deliver software faster I started to envision that delivery of software is much more about running the 100 meter hurdles than it is about running the 100 meter sprint. With the 100 meter sprint the runner knows that from start to finish there are no obstacles and that they can maximize their speed through focus on the finish line.

Organizations aren't like that, we pose so many different hurdles that even if you believe that you are running a sprint, in reality you are probably running the hurdles.

With hurdles a sprinter must continue to work on the way that they will approach the first hurdle and then the next and so on and so forth.  Along the way anything might 'trip' them up.  When they clip the top of the hurdle they have to make adjustments almost in mid air to try to recover.  The ability for great hurdlers to continue to work on their approach to each hurdle ensure that they can run fast competitive races.

Software development is very much like the hurdles.  Even if your Engineering team is able to deliver features quickly, if your Product Development or QA groups aren't aligned with that speed then no matter how fast you run between one hurdle you will be struggling to make the next one because you haven't optimized the steps in front and behind the hurdle that you do well.

In order to deliver software fast organizations need to look at each of their Product and Software Development cycles so that each one maximizes the delivery of the previous steps. More to come on this......