Agile vs Fragile: Strategies for breaking down the façade

Part 17 in a series of 17. To start at the beginning, first read Agile vs Fragile: A Disciplined Approach or an Excuse for Chaos.

Undoubtedly, some of you have made the determination that your team is not Agile, but is indeed Fragile.  Some of you knew it before you even read any of the blog, but now are even more convinced.  But what are you willing to do about it?  Are you ready to break down that façade and begin the journey to changing from Fragile to Agile?  If your answer to this question is yes, then I recommend the following strategies that can help you achieve that goal.  This is not an exhaustive list that when followed will ensure with absolute certainty that you will transform your organization, but these strategies have been proven to help begin that transformation.  No strategy can be effective if you don’t get people to understand that change is needed.  If you don’t have the support of your business partner in getting them to champion improving the delivery and quality of your product, you will have trouble getting this accomplished.  You have to get people to see there is a problem, before they will be willing to address that problem.

Here are some of the strategies that I have used.

• Agile Coach – Make sure there is an experienced coach in place as the org moves to agile, and then let them coach your team!

The problem most teams have is they think they can take a class or read a book and then take that education and knowledge and successfully work through it themselves.  Agile is such a fundamental change to the organization and the way we work that it really demands a very experienced coach.  There are very experienced Agile coaches out there and they are worth their weight in gold.  However; it doesn’t make any sense for an organization to bring in a coach if they are not going to listen to their advice. You have to get out of their way and let them coach.  Your organization is not as unique as you believe it to be.  Agile coaches have the experience to help your team learn and grow.

• Risk Management – Make sure requests for documentation are supported with a clear understanding of the risks associated with not producing them.  Make sure leadership is ready to accept the impacts, when the risks are realized.

One of the things that we are often challenged with is being able to defend why we need a specific document.  We say we need the document but are unable to articulate the impacts if we don’t get the document.  Be prepared to share the potential risk and impact to the project if you don’t get the document.  It is so easy for leadership to say they will take a risk, when you present them with your testing concerns.  The problem is that what they are saying is that they are willing to accept the risk because they believe (or hope which is worse) that the risk won’t be realized.  They think in terms of the risk, not in terms of the impact if the risk is realized.   Make sure they understand the full impact on timelines, cost, and reputation if the unthinkable happens.  Make sure they are willing to accept that impact, because that is what they are truly accepting when they accept the risk.  When you put it in terms of impact rather than risk, they will often backpedal on their acceptance.

• Break down the job silos.  Jump in and participate in all aspects of the project.  Show that the testers are part of the solution not part of the problem.

This is one of the biggest areas where testers cannot just claim, but demonstrate that they are part of the team.  Get out of your hard nosed defined role structures and jump in to help be a part of the solution!  There is no reason why testers can’t jump in and help load the production data into the database.  There is no reason they can’t help train users.  There is no reason they can’t help document user stories.  There is no reason they can’t help set up users, or deploy builds.  Show yourself to be a part of the team and you will become a part of the team.   Don’t compromise your responsibility, compromise your job title!  If development fails the whole team fails. At the end of the day they won’t be saying “well development sure sucked, but that testing team, they sure did a great job testing”.  They will be saying the project failed, and everyone is to blame.

• Story reviews – Host reviews of the user stories to help ensure everyone is on the same page, both formally and informally.

This is an area where testers can have a great impact.  Do you realize that a review is really a form of testing?  When you go through the process of reviewing user stories you are evaluating those stories against the business objectives, as well as, determining if there are errors or gaps.  That adds value!  If you wait for the BA or the business to set up reviews, you might we waiting for a very long time.  Take the bull by the horns and do it yourself.  After all, your success depends on the quality of the user story. If you sit by and let poorly defined stories get created, then you are hamstringing yourself, and if you don’t push for better definition, you are accepting that you are able to make up the deficiencies in them.

• Pair testing – Just as Pair Programming helps to improve the quality of the code developed, pair testing ensures better test coverage.  Partner a developer with a tester.

As many, more seasoned (translated older) testing veterans, I spent some time at a start-up .com in the early 2000’s.  You would think that a start-up would shun all process and testing, but this one was different. They embraced quality, mainly because their clients were some of the largest law firms in the world, who made their livings in litigation.  What was different about this start-up was that we defined very solid testing processes. One of the processes that I am most proud of is the concept of pair testing.  I was getting push back from one of my development peers about the time it was taking for defects to get logged, worked on, and then retested late in the development cycles.  To address this, I challenged my development peers to assign a developer to every tester.  That developer would sit side-by-side with the tester while they executed their tests.  That would give the developer firsthand knowledge of all defects, and reduce the time to get a resolution identified.  While it was comical to hear developers plead their cases with the testers as they discovered defects, the partnership paid huge dividends as the development team gained an appreciation for the unique perspectives of the test team, and the testers gained an appreciation for the desire of developers to deliver a quality product.  It improved both teams.

• Leverage “best practices”, tools, and methodology.  Leverage the experience of those who have gone before.

This strategy goes hand-in-hand with the Agile Coach strategy.  I have never been able to figure out why companies insist that they go through the same pain that every other company goes through without learning from the mistakes of others.  It is the mentality that “our company is different”, and “no other company has the same issues as us”.  Hogwash!  You are not as unique as you would like to believe.  The challenges your team faces, other companies have had to face as well, so why not learn from the mistakes that they have made.  There is a ton of literature and training for Agile that is readily available and reasonably priced.  Avail your team of training and education in the framework and ensure they have the best chance for success.  Trying to go it alone is foolish at best.

• Retrospectives – Take lessons learned seriously.  Ensure that actionable plans are established and tracked by the PM or Scrum Master.

I hope that this just makes common sense for everyone who is reading this blog.  If you don’t take the time to understand what went wrong with previous sprints, don’t act surprised when the problems keep happening time and time again.  Make sure everyone is accountable for implementing lessons learned.  The way you do that is to make it a measurable part of the goals and objectives, and then measure their performance against that goal.  If you want improvement, be prepared to listen to the issues the team is raising and then do something about it.  Don’t let retrospectives turn into whine sessions where blame is doled out and nothing ever actually changes.

• Confront the brutal facts, but never lose hope.

There is a great book by Jim Collins called Good to Great Published by William Collins, October 16, 2001.  This book identifies the characteristics that differentiate those companies that are merely good from truly great companies.  Once of the core concepts in that book is the concept of confront the brutal facts of reality, yet never lose hope.  In this concept the focus is that it doesn’t do any good to ignore the facts and try to hide from them, but always confront them head on with the dogged determination that it will all work out.  In the book, Jim tells stories from great leaders who confronted the realities their companies that were not doing well and decided to do something about it.  They didn’t lose hope, but faced it head on.  You may be faced with a Fragile project team that is failing to deliver.  It doesn’t do any good to play the blame game or ignore the facts.  Great leaders address the issues head on. They put it all out on the table and show the soft underbelly, but at the same time exude great confidence that they are going to be successful in improving and overcoming the issues.  That is what you need to do. Be the person who demonstrates a positive attitude that you will overcome all of the issues and find a way to make the team successful.  If you simply raise issues without a positive plan to find a new way, you will be met with resistance all along the way.

• Metrics, Metrics, Metrics – What gets measured gets done.  Begin measuring the effectiveness of your agile process.
  • Post Implementation: Incidents & Change Requests
  • Sprint Plan vs. Actual
  • Test Planning & Progress by Sprint

One of the key tenets of Agile is the reduction of non-value added documentation.  Metrics almost seem like they are contradictory to that tenet, and in most cases I would agree.  I often say that you should only measure that which you are willing to do something about.  In other words, don’t measure for the sake of providing leadership with pretty graphs and charts; only measure if the information that you gather can be used to streamline and improve your delivery.  It is a fact that what you measure you get.  If you measure productivity, you get more productivity. If you measure quality, you will see quality improve.  Part of this is the Hawthorne effect where people will consciously improve if they believe they are being assessed or reviewed, but that doesn’t account for all of the improvement.  You will improve on whatever you put your focus on. If you focus on the accuracy and quality of each sprint you will see improvements in that measurement.  The challenge is that there are often unintended consequences for these measurements.  If you focus only on quality, you might suffer in speed or cost.  If you focus only on speed you will most likely suffer in quality.  You have to ensure that you are measuring in a balanced fashion to ensure that your improvement in one constraint isn’t achieved at the cost of another.  Again, Agile is about minimizing documentation and effort, so make sure you are efficient in how you accomplish this strategy.  This is where your test management tools can help you with out-of-the-box reporting capabilities that don’t consume precious team cycles.

• Don’t be a Victim – Take control of yourself and your team.  If you need it, be prepared to defend it, and then stand your ground with a dogged passion to help your project be a success.

I saved my victim speech for last.  This is an area that I am deeply passionate about. I hear all the time from testers that they can’t be responsible for the release because development took up all of their testing time by being late, or with a large concentration of defects.  It is easy to fall into this victimhood.  It is easier to blame others for our ability to deliver, rather than to do the hard work of finding a way to get it done.  We have a whole society of victims today who claim they aren’t responsible for their plight in society.  Testers are no different; they blame the developers; who blame the business analysts; who blame the business; who blame the customer.  It is a vicious cycle that has to stop.  It is also intellectually dishonest.  No one can force you to do a bad job.  No one can tell you not to do the best job possible.  Only you can decide that you will accept less.  I can’t tell you how many times one of my test managers came to me complaining that they weren’t going to be able to complete all of the testing on time to meet the release date because development was going to be late.  When I ask them what they did to manage developments schedule and to help keep development on track they look at me like a deer in the headlights.  They seem incensed that I would suggest that they needed to track developments timelines.  It’s the development manager’s job after all.  I am sure they feel slighted when I tell them I have no sympathy for them and that they need to figure out how they are going to get it done on time.  I inform them that they need to tell their team that it is their fault that the team is going to have to work overtime to get the project done.  You see, what I know is that the manager didn’t defensively manage the timelines of any team that impacts their ability to meet their timelines.  They willfully, through their silence, accepted the fact that the development team was going to be late and gave away their project time.  You don’t get to play the victim.  It is your responsibility to know what is going on and to help manage the entire project, not just your little piece.  You need to know in advance whether or not development is at risk and ensure that they are managing those interim milestones with the same level of passion that they are managing the end date.  Tell yourself, “I am not, and will not be a victim”.

There has been a lot of information provided in this series of blogs.  You may have recognized that your team is really hitting on all cylinders and doing great.  If so, then great for you!  Keep it up.  Still others may have come to the reality that your team is anything but Agile.  If you are on the Fragile journey, then commit today to chart a new direction for your team.  Be a part of finding the solution, and find out how to become truly agile.  In the meantime…Keep on testing!