Bugs Bug me in an Agile World

Or as we call them, “defects”.  Can creep in during any phase – as early as user stories, requirements, or during design and of course code.  The best attempts at agile scrum, testing phases, pair programming, and other best practices and the bugs still creep in (no pardons for the pun).

So here is my issue – in a normal waterfall development cycle, there was a clear change management process – either resolve the bug during the long test/fix cycle, or schedule for a follow-on release – based on impact to customer and effort.

Now, how is this different in an agile environment? 

First challenge: does the bug get reported on the backlog or in a ticket or both?  We still use a ticket management system to keep track of where our work in progress is and who owns it at any time – think of it as our electronic Kanban board.

Second challenge: with short sprints, the likelihood of a bug not getting fixed increases.  So what happens?  Does it automatically flow onto the next Sprint backlog or does it go back to the beginning to be prioritized by the product owner?

Third challenge: Who decides the impact?  Perhaps the best approach to that is to determine where the bug first initiated and put it back to that owner – whether the product owner or SCRUM team.

Fourth challenge: Which Sprint retrospective covers this issue – the one where it was uncovered or the one where it was resolved (assuming that more data on root cause is available in the latter)?

I would like to hear other thoughts.  So much of the agile literature focuses on how to do agile by the book, and I am looking for insights on who to handle agile when things don’t go according to plan.




Bugs Bug me in an Agile World – 1st Challenge

In a previous blog, I had talked about my issues (or should I call them challenges) with dealing with bugs found during a sprint.  The first one I mentioned was

Does the bug get reported on the backlog or in a ticket or both?  We still use a ticket management system to keep track of our work in progress – think of it as our electronic Kanban board.

I’d like to elaborate a bit on this one, really hoping for some good input.

So as mentioned, we keep both a ticketing system for WIP (work in progress) as well as SCRUM Backlogs – both product and sprint.   For the most part, as bugs are uncovered during a sprint, a ticket is opened.  The first and best result is that a team member picks up the ticket and resolves the problem during the sprint.  That’s the easy one.   What about when it can’t be handled in the current sprint.  Does it go on the product backlog?  Stay a ticket?  Both?

Right now what we are doing is –

  1. If it started as a backlog item that is now failing, we add the issue to the backlog and it goes back to the start of the prioritization and scheduling process
  2. If it was uncovered during the sprint, perhaps during a regression test, but did not start on the backlog, it just stays a ticket and these tickets are added to upcoming sprints by the team

Not a solution I am that happy with – as I do not like not having a single product backlog list.  But the downside of adding every bug found to the product backlog can be guessed – too long and confusing a backlog for prioritization.

Would love to try out some alternative ideas and report on the results.

Fast Waterfall, Agile is not

An early experience I had with a development shop trying to incorporate the Agile concepts did not quite work out as thought.

Some background (with a few changes to keep the team anonymous).  We had a typical organization structure for a small software product company.  Separate groups for Marketing/Sales, Product Management, Development, and Quality Assurance.  The Development team was also responsible for all product packaging and deployments.  PM was responsible for customer support and handed most issues off directly to development.  There was one person that documented requirements for the larger items, while smaller ones where written up in tickets.

Our challenge was a huge backlog of defects as well as major pressure to incorporate new functionality from the sales staff.  Our biggest gap was reporting, which as is not unusual, was left to the end.

In an effort to pacify the customer, and a true desire by the development staff to improve and use new techniques, the release cycle was shortened from months to weeks.  Nothing else in the process changed other than compressing both dev and QA time.  While fixes where provided to the customer more quickly, the backlog reduction pace did not improve, and if anything, quality suffered.

fast water

My point in all of this is to make sure I SHOUT from the rooftops – going Agile does not equate to just reducing each phase of a waterfall process – if it looks like Waterfall, acts like Waterfall, provides results like Waterfall, then it probably is Waterfall.


One last thought so as not to leave an incorrect impression – there are some cases where sticking with a Waterfall process makes sense, if done correctly.  But don’t expect to achieve the Agile value proposition.

I am sure that there are some of you with the same experience, please share . . .

Upside down Servant Leader

My favorite aspect of the agile and Scrum concepts is promotion of Servant Leadership.  As a manager of all types of technical, support, marketing, and project management teams for enterprise software products, this style fits best with my experience of what works, specifically in managing highly knowledgable and engaged individuals.

Leadership clearly comes in many forms, and has been the subject of countless books and diatribes from business consultants and CEOs.  All show examples of how their preferred approach has been successful.  It isn’t a novel concept that the optimal form is dependent upon the individuals and circumstances.  Looking at software business and technical management, here is how I picture it.

military leader

At one extreme is the autocrat – the leader who believes in his or her way or the highway, runs the software shop in military style, simply making assignments of work and enforcing timelines.  Top down leadership.


At the other extreme is what we used to call the upside-down organization chart.  This was a dramatic concept where the manager’s sole role was to serve the employees.  The concept being that it is the leaves on the organization hierarchy that are the subject matter experts, actually do the work, and management is just there to get them what they need.  Some might believe this form is what is meant by servant leadership, but not really.

Somewhere between these concepts is the Servant Leader model.  In this blog I am not here to explain Servant Leadership, there are plenty of others that do it better than I can. For me, it is how I can lead with authority and accountability, while still having each person on the team AND the team as a whole retaining a level of authority and accountability.  It takes the best of each, from the first extreme it provides strategy and direction, and from the second the leader is the facilitator, the remover of outside roadblocks.   Teams are made up of professionals, and both the leader and each team member has a job to do, and this Servant Leadership term for me pulls it all together well.

I am sure you do not all agree with me, tell me why – or share yet another historical viewpoint regarding other approaches.

My progress from Waterfall to Agile

My progress from Waterfall to Agile

Basic Waterfall . . .

My background in software development started in the early 1980s, so the waterfall development approach was fully ingrained in my psyche.  I had always been interested in new approaches and collaborative concepts for iterative improvement and collaboration.

Quality Circles . . .

Starting in my being “volunteered” to become my department’s Quality Circle guru (Japanese Quality Circles were defined by Professor Kaoru Ishikawa in his handbook, “What is Total Quality Control? The Japanese Way”, Prentice Hall, 1985).  Remember those?  Few people do and I am not sure they got far outside of the manufacturing realm into the core software mindset.  But they were the first time many of us experienced the concepts of Brainstorming, Fishbone Diagrams, and other team based idea generation methods.

JAD Sessions . . .

Now back to waterfall and agile.  My first experience in moving from the “throw requirements over the wall” approach to collaborative software requirements was the JAD (Joint Application Development) session.  While the overall project still followed the waterfall methodology, at least the up-front specifications were done in a team setting, and with participation from all parties across the software life cycle, from customer through to the QA and Deployment engineers.

Nightly Builds . . .

The next major step was on a very large project with multiple development sub-teams (I had the one handling integrations and communication protocols), where the outrageous idea of an automated nightly build was instituted.  Radical, and fought against, it actually worked!

Developer Demos, Pair Programming, Shorter Iterations . . .

Then the changes just kept coming.  By now I was up the management chain. I switched to smaller companies and had more control over what the full software and QA teams did, and new concepts were attempted.  Resistance seemed to always be the biggest issue, but I’ll talk about that another time.  For me, each attempt brought some new insight (and much hindsight) into options other than the traditional release schedule and documentation requirements.

Extreme Programming and Agile Life Cycle . . .

Now I am deep into the concepts around Agile development, and focusing more on how to contract and specify customer needs rather than implement.  One last thought here, is that I strongly believe that there is never 1 right way, and there is still a place for pieces of each concept I learned along the way.  The challenge (and fun) is fitting the best approach to the problem and project at hand.

This was my experience, I would love to hear yours so please comment.