Rod Claar

Agile  and it’s various implementations, including Scrum,  while most often discussed in software development circles,  can correctly be classified as Product Development methodologies.  Most of the time the product being developed has software as a major component, but they are products developed to solve a problem or make a job easier or more efficient.  When we think about products in this broader context we can often identify some impacts on product management rooted in the Agile practices and thought process.  We need to understand these impacts to be prepared to mitigate them and propel the organization to the next level.

The first and most obvious is the impact of faster release cycles.  There are many things that Agile teams do to achieve faster release cycles, but the primary driving reasons are faster return on investment and quicker feedback.   In my experience the product management team are often not prepared for the high level of interaction that the Agile team will demand.  Even if they had prepared well in traditional terms, the depth of detail that will be required by the Agile team will outpace the product management team and make it harder for them to prepare the vision and business capability plan for the next release.  When the development team delivers early with fewer problems and the product managers are not ready to reload the team poor decisions on what to do next often result.  Then scrambling to fill the gap the desired feedback can be passed over leading to more bad decisions.  The cycle is almost unstoppable without a significant change in product management and market research practices.

The next common goal of an Agile team is continuous shippablity.   An organization delivering more reasonable  scope, quality higher and a robust base of automated tests, sooner or later someone will ask why we can’t just ship it to meet a new market, for a special customer or to beat the competition.   This is like having a 225 m.p.h. car and trying to get it up to speed wearing a blindfold.  You might get lucky, but more often you will be off the road very quickly.  A few years ago when working at a software company, sales asked us to adapt our product to a different market.  The engagement was a total disaster.  We did not take time to understand what this new market wanted.  Our brains were tuned to our normal market and could not understand the context and the paradigms in place in the new market.

In both of these scenarios what is missing is more information about the customer and how they use the product.  Traditional market research can deliver the answers, but it takes a lot of time and generally a lot of money.    Some products can support the cost of the market research, but many medium to small organizations cannot afford formal market research.  Trying to go to market without having the knowledge of how customer will use the product can sink even the best product.

What  is required are techniques to get the market research to make good product planning decisions in pace with the development team.  The Agile planning cycles of iteration, release, vision, roadmap and portfolio need to match up with processes that answer the questions about near-term product improvements, product evolution and other markets.

If we could lower the cost of market research and product planning while still delivering valuable and accurate results, we would have a better shot at delivering the best value to our customers as fast as possible.  This is the true promise of Agile.

Recently I had the opportunity to attend Luke Hohmann’s Innovation Games® Consultant Master Class in San Ramon, California at the Chevron campus.  The class was held in Chevron’s Innovation Space and attended by 20 or so of the smartest Agilests on the planet.   This class was aimed at helping this group of world-class consultants understand how Innovation Games® can be used to deliver cost-effective market research for the Agile team.

Luke is a great facilitator and this two days was packed with great concepts and practices.  He and his company is on a mission to restore the concept of serious games to business.  The idea of serious games was all but destroyed by computer games and online gaming.   Serious games are still fun but have a purpose.

Luke told us that “Innovation Games® are serious games that power innovation by enabling you to better understand your customers”.

With the knowledge and skills gained from this class we will immediately start offering a new course “Innovation Games® for Agile Teams”. This course will contain some lecture but will be predominantly discussion and hands-on exercises to help you understand how Innovation Games® can be used by Agile organizations to help provide the right vision and feature set to the development team and in turn your customers.

Agile teams who employ Innovation Games® find some of the dull and repetitive practices of Agile comes alive in a fun and engaging way.  Scenarios might include:

• Using Product Box to identify customer requirements.
• Using Speed Boat to improve retrospectives.
• Using Buy A Future to prioritize the product backlog.
• Planning a project using Remember the Future.
• Clarify the release plan with Prune the Product Tree.
• Understanding how your product is used through Me and My Shadow and Start Your Day.

Each student will receive a copy of Luke’s book Innovation Games: Creating Breakthrough Products Through Collaborative Play.

Course Outline

• Overview of Innovation Games®
• Customer Collaboration
• Continuous Planning
• Portfolio Prioritization
• Product Backlog Prioritization
• Strategic Planning
• Release Planning
• Agile Retrospectives

Audience

All members of an Agile team are invited to join us with a focus on product planning and management.

Format

Standard - 1 day.

Extended - 2 day with more game played by participants.

Schedule

The course is available for on-site delivery and will be offered as a public course.

For more details see http://effectiveagiledev.com/ or call 530-SCRUM-42.

My buddy Charles Sterling, Program Manager at Microsoft has posted a new webcast video showing the basics of how to create a test plan, test case, recording a test, filing a bug and playing back the test using the Beta 2 version of Visual Studio 2010.

You can see the video here:

How to create record and playback Test Cases in Visual Studio Beta2

This new central place for QA teams to create and manage test plans and tests is a great addition to Visual Studio for traditional QA teams.  However my primary interest is in how could an Agile team use this new tool to move testing forward in the Agile process.

Firstly I think that this tool could be a good place for Product Owners and Test Professionals to collaborate on the Acceptance Tests for an upcoming iteration.  The User Stories could be the basis for creating the actual test cases that would be used to validate the delivery of the anticipated business value from the User Story.

During Sprint (Iteration) planning the team could use the test case to understand the intent of the story and get clear on what the real acceptance criteria is.  I would expect that more detail and more tests would be added during the planning session as clarity is improved.

While working the story in the Sprint the team would continue to update the tests with recorded steps of the newly developed feature and run the acceptance tests to monitor the Sprint progress.

When the Acceptance Tests all passed, the User Stories would be functionally complete and they would provide a safety net for performance tuning, refactoring and integration.

I hope you have noticed that I am completely ignoring the coded automation of the Acceptance Tests.  I am a big proponent of automating Acceptance Tests.  However in my experience the road to fully automated Acceptance Tests starts with understanding the process of writing the Acceptance Tests and the Agile team using them to drive development.

I’m sure I will come back to the topic of Automated Acceptance Tests later, but if your team is looking for an easy way to get your QA professionals involved in your Agile team, using Visual Studio Test and Lab Manager to author Acceptance Tests is a great place to start!

Rod Claar to speak at Agile Adoption: The Real Story.  Rod’s talk will center on the problems of managing the software capiblity portfolio in an Agile organization.

“I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.” – Ken Schwaber, co-creator of the Scrum framework

Ouch! Who wants that? Considering Scrum is the most widely adopted agile process in the world doesn’t this say agile doesn’t work worth a darn? Well, not exactly, and that is what this seminar is about.

We want your agile adoption to go so well you are singing the praises of agile to all who will listen. If you are planning to adopt agile within the next 12 months, then you have to attend this free seminar so you can avoid being part of the 75% of organizations that fail!

This seminar is different from any you will have attended in the past. We have one goal and it is NOT to sell you anything. Our goal is to convince as many organizations as possible that they are not ready to try an agile transition! We want the organizations which are ill-prepared for agile to understand their shortcomings and address them prior to attempting an agile adoption. Our goal is to stop agile failures before they start. One of the principles we teach in our courses is to “build quality in” which in this case means making sure organizations are properly prepared to have the highest possibility of success before embarking on a difficult journey.

How will we do this? We are going to be very blunt and very reality-based. We are going to give you a peek behind the agile curtain. We are going to help you see what we look for when we help organizations like yours through an agile adoption.

We are going to do this by telling you the pluses and minuses of various methods of agile adoption which will include actual expectations for success as well as the real dollars required. We are going to tell you all about fully being an agile organization, not just what it takes to become reasonably proficient with a process. We are going to tell you the pre-requisites for true success in terms of people, skills, and structure, not just which books you should read. We are going to tell you what you need to be prepared for with various roles like project managers, product managers, business analysts and other, not just leave you looking for answers when those roles ask “what do I do now?” We are going to tell you why it is important to understand and embrace agile engineering practices, not just gloss over these items because “they aren’t part of the process.” We are going to explain why some teams find using an agile lifecycle management tool to be important, not just ignore the topic because we don?t sell the tools. We are going to tell you why scaling, time zone differences and not being collocated is so difficult, not just tell you they are hard and leave it at that. We are going to tell you the common areas of failure for agile adoptions, not just let you find them on your own. After we tell you all these things, we are going to help you to truly understand why it is all so important.

We will end the day with a Q&A session where no question about agile will be off-limits.

Space is severely limited for this event. If you are currently employed as a decision maker, influencer, manager or executive at an organization considering an agile transition please sign-up to attend. If this does not describe you, then please consider attending a future event instead.

The event is at the Holiday Inn Express near Dry Creek/I-25 just across from Maggianos restaurant.  Doors open at 8:30 with the seminar starting at 9am.  Our goal is to finish by 4:00pm, but we have reserved until 5:00pm to make sure all questions do get answered.

Go to http://agileadoption-rc.eventbrite.com for more information or to register today!

I am asked this question quite often.  What is Agile Coaching and what does and Agile Coach actually do?  When I started thinking about how to answer the question, I found it difficult to put the answer into words because there is no real formula for an Agile Coach to help the team be more effective in product development.  However when I started thinking about some of the coaching situations I have encountered a pattern did start to emerge.

Agility in software development is about identifying the roadblocks to effectiveness for the team as well as the individuals that are on the team.  Many of these are very common, yet each instance has it’s own form and smell.

Discovering these roadblocks is like the optimization of a program or module in software.  There is always the worst problem and each one has a cost in effort and risk to resolve the issue.  And just when you get that one solved, you discover another #1 issue.

The first step is observation.   What is the team doing?  How are the team members interacting?  Can I tell what is being worked on from the outside and can I see progress day to day in the project?

Sometimes I observe problems with understanding exactly what each  goal means in terms of the actual work to be done.  This probably means the team needs help breaking the work down into smaller chunks.  Smaller, more understandable chunks of work leads to better estimation and better predictability.   Ultimately the better understanding leads to better software because the team builds what is needed instead of a guess formed from cloudy understanding of the requirements.

Sometimes I observe the team not knowing what to do next or getting in each other’s way because the work dependencies are not clear.  This can be due to a lack of project task visibility.  Visibility is a difficult issue, especially with a distributed team.  Lack of good iteration visibility can lead teams to spend too much time on tracking and reporting and other teams to doing too little.  I work with the team to find the right level and detail for project and task reporting and work with them to make the publication of the reports as automatic as possible.

Sometimes I sense that the team is not comfortable with the process they are using.  The struggle against some of the practices and ignore others.  Most of the time this is due to the fact that certain members of the team do not recognize the underlying principles that the practices are intended to follow.  Sometimes there is an unstated fear of change or loss of status, influence or control that is causing them to not follow the agreed upon process.  In this case I start (or continue) individual coaching where the goal is to uncover the lack of understanding of the principles that make teams more agile or the fear that can paralyze an individual and a team.

I could cite many more examples, but let’s get back to the answer for the original question.

Agile Coaching is a process where an experienced coach observes the team to understand what attitudes, practices and communication problems are keeping them from being more effective.  This is done over a course of several days to a couple of weeks or more.  The coach will identify issues that are disrupting the flow of work, causing rework or causing redundant work or other wasted effort.  The coach will identify patterns of behavior that are not improving the team and the product.

The Agile Coach will then work with the team to help them see the issues and work with the team and management to facilitate improvement in the issues.  This is often a very subtle and Socratic in nature.  The coach does not often tell people what do differently or that they are wrong in what they are doing, but rather helps the team and the individuals discover a better path for themselves.

Just as the agile process itself the changes are incremental and are often only seen when looking back to recognize the improvement over time.

The Agile Coach is not a team member in the traditional sense of the word. Rather they are a trusted adviser who can identify the patterns of attitude and behavior that are often not seen by the team or not understood as roadblocks to a more efficient, happy and productive team.

The successful Agile Coach will work himself out of a job. Not because the team achieved true agility, but rather learned how to chart the path to agility for themselves.

I’m sure that you all know the story of how the term “bug” got associated with a computer failure.  It was a moth in a computer which caused a hardware failure.  However, since then the term bug  has become synonymous with a software error.  There is a bug in the program.  Yes, there is a bug in the program, every program.  Many software development organizations spend a large portion of their time and effort finding and fixing bugs.  However the situation rarely improves.

This leads organizations to start tracking bugs and applying all sorts of analysis and pressure to fix them.   How do we know which bug to fix first?  The priority (how important we think it is) is assigned and the severity (who and what does it affect) is assessed.  Then when we figure out what to fix based on priority and severity, then who should fix it?  All too often the analysis is that the primary development team is too busy and important to fix bugs, so let’s create a bug team and have them fix all the bugs.

Quite often the situation gets worse again.  More bugs are found by customers and the QA team.  The backlog for the bug team gets bigger and the time from bug discovery to fix delivery to customers increases.

If you have been around software for any time at all, you will recognize this pattern.  Lots of bugs being tacked separately from new requirements and an increasing slice of all development effort being allocated to the effort to attempt to slow the erosion of software quality.

I believe we need a different approach.

We have to understand what caused the bug in the first place.  We have to make sure our goals are clear and that we are applying the right people and talent and money to reach our goals.

Should the goal of the software development organization be to deliver quality software?

Trick question.  Of course we need quality software, but quality should not be the goal.  The goal should be the delivery of business or customer value.  That’s why we are building software.  If we deliver poor quality then we will have to spend more time and effort fixing it so that we can deliver on the solution we promised.  However the focus should be on the delivery of business value.

If we turn away from tracking and prioritization of bugs and turn towards the delivery of business value quickly and effectively, we can change the entire landscape of software development.

We need to understand where the bugs come from.  Contrary to the belief of some, the code does not just rot.  The gremlins don’t attack source control at night.  Except for the occasional corruption of source and binaries from hardware failure, most of the time the bug was written by a developer.

I think there are two kinds of bugs.  The first is just a mistake.  Someone used the wrong variable, used a wrong value, called the wrong method.  Stuff happens.  This type is blocking functionality that was assumed to be working.  Hopefully an Agile team using TDD will find these before the end of the iteration.  If not, there are few things of higher priority.  Track it if you have to, but get it on the next sprint backlog in the form of a story.

The other kind is when the team did not understand ( or was not given ) the full scope of the requirement.  This one often includes unrecognized interaction with other systems.  This type is much more common and the priority cannot be determined by the development team.  The Product Owner must make sure that they understand the value of the missing or wrong functionality and present that story back to the team for sizing and prioritization.

We will probably need a system to track the errors that are found, but we need to quickly decide which type it is.  The first type is the failure to really deliver what we said we delivered.  The second is the failure of the Product Owner to deliver the requirements to the development team in such a way that they are able to deliver an appropriate solution.

In either case, I think that the work needs to be prioritized alongside the other stories.  What is the business  (customer) value?  How much effort and risk is there in completing this story?  If you must use a bug tracking system to be responsible and responsive, then do so.  However your decisions to deliver business value should be contained in a story that the team can deliver.

This, by definition obviates the need for a “bug” team.  The delivery of business value is the responsibility of the whole team.  The team can and must learn from its mistakes.   How did that error get into production (the mistake type)?  What tests should have been in place to make sure that the code was correct.  What about that requirement did we not understand ( the second type)?  How can we better understand next time?  How will we make sure that we understand it now?  These are all questions that the team should investigate and try to answer.

The first type of bug is lessened by unit testing by developers.  A test first approach using Test Driven Development is best.  TDD all but eliminates this type of bug.

The second type of bug is lessened by an Acceptance Test Driven approach to requirements understanding.  Virtually all requirements can be tested with Automated Acceptance Testing.  Basically what we are doing is repeating back to the Product Owner the requirements in the form of a test that says,  “when this happens, the code will respond with this behavior.”  The Acceptance Test can be written before the object code is even named.  The test can fail on day one of the iteration.

Scrum and Agile are about delivering business value quickly and repeatably.   Prioritization of business value must drive the project.  Prioritize all work together and drive the process with Acceptance Tests and Test Driven Development.  Your team will deliver more business value quicker and will deliver higher quality software in the process.