Launching SoundAgile Consulting

I’ve been involved with Agile with many different organizations now for over 12 years.

In these years I’ve primarily been involved with being a contributing individual over a being an Agile coach.

The business of Agile has grown to a significant size and has now become a product that is sold to businesses who want to move their organization to Agile.  The very people who started Agile off as a movement have splintered off into several factions, each having their own opinion or approach in how to help organizations adopt Agile as a capability within their organization.  We now have Scrum, SAFe, DAD and LeSS to name a few in our acronym vocabulary.

Agile can indeed bring about valuable changes to an organizations ability to deliver software product more quickly.  These areas of Agile are fairly thought out, User Stories, Continuous Integration, Automation and Scrum.  You can move your development teams to a faster pace with some focus on specific team and development techniques that require some time to learn with some level of ease.

What Agile is struggling with is at the organizational level.  The Agile manifesto is specifically focused on building software better with a goal of delivering high value and quality software to our organizations.  A noble cause for sure and one that was sorely needed, given the changes in our software capabilities over the past 20 years.

Sr. Leadership however hasn’t changed much, still managing in a large up front analysis budgeting process which creates a painful friction between fast moving product delivery teams and slow moving hierarchical management structures .

For those organizations who are being sold Agile as a product that will deliver ‘x’ benefits know this about what is occurring.  These organizations are finding people who have done ‘some’ to ‘no’ real Agile, meaning they haven’t actually worked on an Agile team. Getting people who have the ‘right’ certifications doesn’t provide those people with the ability to coach teams in the reality of Agile, only the theory of Agile and their current frameworks.

They are also focused only on the product development area of your business, letting you believe that you will receive huge benefits from moving to Agile without the corresponding changes necessary throughout your entire organization to support a fast paced product delivery teams.

Agile is not a small change management effort, rather it is a multi-year impact to your organization, that if done well will lead you to great success.  If done poorly will provide you with significant pain without any corresponding benefits.

I’ve spent many years thinking about what I might offer from an Agile consulting perspective and I’ve come to the conclusion that any Agile ‘consulting’ work that I would want to engage in must include both Sr. Leadership down and the team level.

Another thing I have concluded is that successful organizations that want to become Agile, must do so with a much smaller footprint of coaching.  You don’t need full-time coaches for a long period of time.  In relying on full time coaches you are asking them to be your organizational Agile cop over owning the change within your organization.  The most successful Agile organizations I’ve worked in never had an Agile coach. Let me repeat that, never had an Agile a coach.  Instead they owned the move to Agile from the top down.  They provided the opportunity for teams to be empowered and fail and were not afraid to change organizational processes when they became impediments to improving Agilty.

SoundAgile will provide two levels of support and coaching for your organization.

1. Team Level – Coaching and training will be accomplished through a combination of online training videos, 1:1 coaching and targeted onsite sessions for specific techniques such as Discovery/User Story Mapping, User Story Writing and Behavior Driven Development.
2. Management Level – This will cover every management level in your organization, especially focusing in on your most impacted people, your technology managers.  Coaching and training will again be accomplished utilizing videos, 1:1 coaching and probably most importantly, targeted 1-2 day sessions that will continue for a multi-year time period. These sessions will provide for a longer term inspect and adapt change management process.

I’m really excited to be launching SoundAgile and am looking forward to working with people and organizations as they engage and encounter this thing called Agile.

SoundAgile will be live within the next two weeks.  I look forward to working with people who are motivated to move to Agile and make it work for them and their organizations.

Baking In Quality with Agile

One of the things that I love about Agile and especially the related techniques of BDD and Test Automation is that if done correctly your teams are essentially baking Quality into your products AS they develop, not after.

Traditional SDLC (read waterfall) took a very linear approach to project delivery which in turn translated into a similar approach to how we developed and delivered our software products.

In our traditional delivery methods, quality was not ‘baked’ in but tested out and we never ever got to the point where we are able to test out all of the ‘defects’ that are found, instead we create a bug database where ‘bugs’ go to die.  Every organization typically has some form of a bug database with bugs that were ‘found’ sometimes years ago and were never fixed (of course begging the question were they ever bugs in the first place?)  In Agile we really don’t want to see a bug database because we should be instilling a zero defect policy for each sprint, meaning that we should never be introducing new tech debt into our product.

As I progressed on my Agile journey I came to realize that there are actually two types of ‘bugs’ that we encounter when we develop software:

1. Bugs as Missed or Undefined Requirements
2. Bugs as True Bugs

— Bugs as Missed or Undefined Requirements – I will argue (and in a book that I am starting to write about this topic) that a majority of the bugs that we find and document aren’t really bugs at all, but rather functionality that has been misinterpreted based upon the requirements definition that comes out of segregated development processes, ie Write Requirements, Develop Software, Test Software and Deploy Software.

Language is such an imprecise way of communicating that it almost virtually guarantees that if you have more than 1 person developing the software for your product you will get different interpretations of how to implement the requirement functionally.

Remember the old ‘The System Shall’ statement? that is commonly used in writing Business Requirements documents?  I always thought that this missed the scope of the requirement, what about what the System Shall Not Do?.  We focus so much on happy path for our functional development that we miss large segments of functionality based upon what an application shouldn’t be allowed to do.

Let’s take an example of an English word to convey what I’m meaning:

What do you think of when you see the word – BASS

Do you think of this:

OR this?

These have the same spelling in the English language yet they have two entirely different meanings. Our life experiences become a prism for how we interpret what we read and how we react to it. (PS, I’m a musician so I think of the instrument before the fish)

Teams that rely on written requirements documents that are reviewed and worked on independently, meaning developers develop the code/functionality and then pass it on to testers will inherently have issues/bugs related to how something was interpreted and then developed.  In the above example the developers may have thought they were delivering a bass guitar, but the testers were expecting a bass fish (yeah extreme I know) but I believe this is the root of many of our issues when trying to deliver what the business expected in the first place.

— Bugs as True Bugs – I believe that true bugs are more technical than functional (or should be).  Bugs related to how integration happens are very common because although we can describe the behavior of our feature we can’t always anticipate issues related to how independent systems will work together.  Many ‘true’ bugs in Agile are caught in the moment and fixed before they ever make their way to production.  For the Finance people out there this is a tremendous cost saving that has been proven time and again.  ROI is greatly enhanced when you deal with tech debt up front rather over time.  And please don’t ever think really that it is more important to get ‘something’ to production over making sure that the product is operationally sound.

So what to do?

To address the  inherent limitations with our  communication, we need to abstract our thinking into more concrete descriptions of behavior over broad-based statements such as the System Shall.

User Stories and the corresponding BDD acceptance criteria are a great way to do this as a BDD example table clearly defines the behavior of our product functionality via outcome based upon inputs.  The ‘language’ of BDD is unique so that everyone can begin to have a shared understanding of what the story and behavior of the product(aka system) will do.  BDD abstracts our communication and removes individual interpretation.

In Agile we start by ensuring that the teams understand that they OWN the quality of their delivery. One of the things that I absolutely love about high performing Agile team is that there is no finger-pointing, if a Sprint fails to deliver what the team committed to then everyone shares the blame, not just an individual or functional group.

How we bake quality into our products is by understanding how to write User Stories that provide context without the ability to misinterpret the meaning of the requirements.

To do this we must first ensure that we have a well written user story, what does that look like?

A good user story needs to identify the What and then the Value statement.  Many teams that I have worked with start to write stories that only identify the actor and What but leave out the value statement, which is really the proof that what we are working on is of sufficient value to devote our resources to.  A good user story should never have any Creative or Technical design conveyed, I know that many people like to show their technical knowledge by writing stories that convey what they think the design or system will need to utilize, but all that does is start the team down a path before exploring all options.

Behavior over language interpretation is what you are striving for when writing contextually rich user stories.

BDD with its accompanied Example statements takes an otherwise basic user story and brings it to life.  Much like we do when we take basic ingredients for cookies and then bring them together in the right amounts to deliver awesomeness every time.

Software quality is much like baking, you need:

• The right ingredients – Good individual team members, honest communication, commitment to quality
• The right process – Write good user stories, add quality BDD acceptance criteria, code and test in parallel and then deliver, involve the entire team in writing BDD, involve the entire team in the estimation process.

By taking the time to build contextually rich user stories and define the story with BDD acceptance you move towards a shared understanding of the ‘behavior of your product’ over one that is driven by functional requirements.  Requirements tend to convey to little of behavior and focus more on the big win that is being conveyed to Sr. Management regarding what is being delivered.

Agile is a very disciplined delivery process and in order to bake the quality into your product you need to develop efficient processes that keep the User Story/BDD train running smoothly.  If you are entering a sprint and then writing your BDD then you are already behind, you need to develop a process by which teams are working on current sprint development AND building context for the next one.  It can be done and when it is you get what I call progressive regression with the automation that comes out of your BDD work.

Agile is very disciplined and to think that going Agile will make your current life easier, well guess again.  What Agile will do is highlight EVERY current weakness you have in your current product delivery process and then focus your attention on finding ways of improving on them.

For those of you looking for workshops regarding User Story/BDD techniques, please reach out to me at soundagile@gmail.com.

Agile Testing

I was saddened to see that a meetup group that I managed for over two years was coming to an end because there wasn’t anyone who wanted to take on the leadership role.  When I started at a Northern Virginia startup as QA Manager I was tasked with taking on the leadership role of the DC Agile Software Testers (DCAST) meetup.

When I took over we had 25 people and when I left the group two years later  we had grown to a robust 450 and had developed a reputation as a place where QA professionals could meet to learn how they could be successful in an Agile environment.

I’ve always said that QA is the last to come around when organizations move towards Agile.  Early on in my career in Agile the QA leaders would tell me ‘yeah you guys develop however you want and when you are done, then we’ll test’.    The notion that QA couldn’t test anything until everything was done (though in reality it never was) was strong.  The feeling of power in finding defects that were typically not defects but mis-interpretations of requirements was palpable.  The force was strong with us then. (cue the light saber sound).

With DCAST I saw quickly that the people who were coming didn’t understand how they could engage in the process and more importantly they didn’t understand how they could deliver ‘quality’ without having the entire feature delivered for testing.  Iterative testing just didn’t compute.

There are many things that QA teams need to understand in order to be successful in Agile.  Some of the key elements include:

1. Automation – For QA this needs to be a key focus of development.  Automation builds what I call ‘progressive regression‘.  Instead of thinking of regression as the final end to end activity, look at it as a growing entity.  With waterfall development and more manual focused testing, you get an opportunity to perform a full regression test potentially just once at the very end of the development cycle.   This leaves little time to deal with defects that arise from your testing.  With automation and continuous integration you are effectively performing a regression test of your developed features every night.
2. Behaviour Driven Development (BDD) – The two-pronged effort to quickly develop and manage your test automation suite utilizes example based test development like BDD as your test acceptance framework.  What BDD does is ensure that the entire team is reviewing the acceptance tests that will ultimately be developed as part of the automation suite.  This process ensures highly contextual user stories that clearly define the behavior of the feature and keeps everyone focused on exactly what needs to be developed (nothing more nothing less)
3. Parallel Teamwork – With the use of BDD, QA can develop their automation code while feature development is in flight.  If the teams are working from the same story specifications then when the code is checked in the automation should be able to run with few errors.  This is a key process to develop in order for teams to deliver quickly.  By not having parallel efforts, teams will typically fall into the cadence of having automation developed in the next sprint.  Once you go down this road you will typically see automation efforts begin to fall further behind as QA will start manually testing in order to ‘stay on top of testing’.
4. Sprint Management – QA teams need to work with their team to ensure that work is being delivered throughout the entire sprint.  A common problem teams face in Agile is that we fall into the ‘mini-waterfall’ process where developers deliver the features in the last day or two of the sprint.  This leaves very little time for QA to perform ad-hoc and manual break testing along with fixing any automation breaks that have occurred once the code is checked in.
5. Zero Defect Policy – This is key.  Teams need to develop a working agreement that enforces a zero defect policy for new feature work in a Sprint.  This means that the team does not receive credit for any stories that can’t be closed out with zero defects.  This focus ensures that the entire team is focused on delivering quality.
6. Quality is EVERYONE’S responsibility – There is no such thing as ‘toss it over to QA’ in an Agile world.  Hey Developers, you have to help test if you deliver something late.   Don’t let your software engineers tell you that they don’t test.  All great developers have to be good testers ( you know TDD kind of focuses on writing tests).  The entire team is responsible for quality not just your test engineers.   Note – QA Managers this concept in no way removes the need for your existent, rather like Engineering Managers your role changes.  You should actually have time to be strategic and plan out future testing platforms and approaches for your team.

I’m glad to have led DCAST as it provided me an opportunity to help QA professionals grow their understanding of the activities and process all good Agile teams exhibit.