Does your business know their business?

It's a question that most people are scared to ask because it rocks the boat; self preservation leads most people to avoid doing that, as you never know who might fall off.

I remember reviewing a product backlog and wondering how the prioritization was done. The highest value stories did not appear to be at the top - nor the smaller stories that might give the "biggest bang for buck". 

Then I noticed it was stacked with requirements from our most "vocal" customer and the most recent requests. Essentially whoever nagged the Product Manager recently got their requirements moved to the top.

On another project - it was clear that the Business Analysts didn't understand what they were really asking for. They were copying and pasting requirements from an existing list. There wasn't much analysis going on.

When this occurs - it doesn't matter how good your delivery team is. You need a good Product Owner.

DDD - Defect Driven Development. Do you need a Defect Management System?

A friend coined that term on a recent project. He was shaking his head after a painful interaction and said - "We don't do TDD here man. We do DDD."

This post is going to cause some arguments, but hear me out.

I had never worked on a project that did not have some system for tracking their bugs, even if was just a horrible spreadsheet. Then I worked on one where we purposefully delayed setting one up, and delayed it again.

And then I questioned if we should ever have one.

Some observations:

On the projects that I did have intricate tracking systems, I spent a lot of time reviewing, prioritizing and assigning defects and escalations. So did my Development and QA managers; which was a significant loss in productivity. It got to the point that they implemented an "Aging" process. 

<Cue screaming from QA folk.>

Yep - There were so many bugs logged that every few months they'd run a query to close out any incidents that were older than x days.  If it was really that important - someone would have made noise or it would have been re-raised. Keeping them there was cluttering up the queue and making it hard to identify the real issues.

So what behaviors did I see when I didn't have a Defect Tracking system?

• Testers bringing issues to the devs straight away rather than bugs queuing up.
• Face to face interactions and discussions as opposed to relying on a system as the intermediary
• Less noise was created  - bugs were actual bugs, requirements or anything sufficiently large got moved into the backlog and prioritized appropriately.
• Less lag time as a ticket was passed back and forth for "more info", "not reproducible" or "works on my machine"
• People started taking pride in the quality of their work
• I never had to deal with another "bug fix" sprint.

What are the usual arguments against this crazy concept?

• "I need reporting to track what quality levels are like" - That should be a quick report. You have zero bugs. Here's a pie chart.
• "But aren't you distracting developers who should be working on features?" The developers are currently writing code on top of existing buggy code. so they're currently coding more bugs, not features.
• "But the Devs are 'in the zone' I don't want to disturb them." Try disturbing them in 6 months with something they should have fixed at the time or that some other developer did and they have to debug.
• "Doesn't that impact your velocity?" Not noticeably. If you have that many defects  - you have a much larger code quality and development process issue. Its going to impact your velocity much more if you pile up the technical debt and try and deal with it later. 
• " This isn't a two-bit project like the one you're describing - This is large and really complicated"….

Trust me - I didn't think it would work either. 

Then it did.

Embrace the WAG

I think this is also an British acronym for Wives and Girlfriends - that could get you in trouble. Don't do that.

I'm talking about the "Wild Ass Guess".

Trying to prioritize a product backlog is like Window shopping. You can prioritize all the things you want at the top of your list, but unless you have some sort of idea of cost, it's not really effective.

In a waterfall project, you'd have a design phase where you worked out how to accomplish the requests, then do detailed work breakdowns to identify how many hours/days/weeks are involved to complete the work.

That's a lot of effort and time to invest in something that you may not even want to build.

In most cases the WAG is good enough to allow the Business and Product Owner to prioritize. 

I've taken a liking to T-Shirt sizes:

• Small, 
• Medium, 
• Large 
• X-Large etc. 

It allows the Product Owner to compare the features, but doesn't get you bogged down in the "How many hours?" discussion - which isn't really useful.

Perception is reality. Especially to the boss.

How involved is your senior management in the day to day?

Probably not a lot.

Which is why it's important to involve them in the Iteration demo's and publicize team achievements and project milestones. This isn't about blowing your own trumpet - it's about keeping the team productive.

The concept of the self organizing team is alien to most managers. A lot of them have probably gotten to where they are using a directive management style. When those management types can't see progress - they usually assume that none is being made. Then they start interfering and trying to fix things that aren't broken.

So make sure progress is visible and publicized - because perception is reality.

I like to spike.

One of the hardest parts of moving towards an agile delivery approach is guiding teams to build functionality in thin slices. We've been so accustomed to building using traditional design techniques that it's hard to let it go. 

With technology projects, so much of your design is based on assumptions and unknowns. When you eventually build it out, you've usually deviated from the design in multiple places due to things encountered during the project. So if the design is more of a "guide" why spend so much time on it?

A spike is there to help you discover those unknowns, whilst delivering a thin slice of functionality. 

This allows you to show something to the business to validate whether you're on the right track, understand whether the technology can do what you want and whether your initial WAG is accurate.

Always keep a spike in the tool belt.