The art of the small

First, my apologies for skipping more than an entire year. I knew it had been a while, but I hadn’t realized my last post was in December of 2014. My resolution for 2016 is to be more regular.

Most developers have a habit of delivering a lot of code at one time. In many ways the world of Java encourages this and helps developers create habits that are hard to overcome. Even a simple application requires several steps and files to render something useful, especially if you want to follow best practices with interfaces and resources. The result is that making anything work takes a fair bit of overhead. Nobody likes doing all that work and having a very little to show for it.

I’ve experienced this myself. When I add a page to an application my preference is simply to make sure I can navigate to and from the page first. Then I can start putting in the functionality. I can add functionality in small steps with full regression testing to ensure the additions don’t break working code. But I am not just tempted to cut corners, I often give in (although I’m usually reminded why I prefer to go small almost immediately).

There’s more involved, though. My current project is not fully Agile, and our CIO had asked that we stop making updates during a critical season. This meant that our end users overloaded what was intended to be the “last” release before that critical season began. (Naturally, this overloaded release was the worst we’ve ever had.) When end users are concerned about when the following release will happen they naturally want lots of functionality included in the upcoming release.

For these reasons and more there are pressures to release code in big-bang releases. But the biggest reason of all is it isn’t always easy to see how you can make a release smaller. This is an art and one that you need to cultivate in your team members.

As an obvious example, our system is a replacement for a completely manual process. We aren’t replacing any existing tech. When the end users were giving us their requirements they had business rules that they wanted our application to enforce. These were complicated rules and sometimes they conflicted. They also significantly increased our time to complete the initial release.

My tongue-in-cheek suggestion for release 1 was to akin to scanning the paperwork into a computer for viewing in PDF form. But in reality I would have recommended a system that replicated the manual process as much as possible. This meant not including the business rules at all. Since the future end-users already knew all the business rules there’s no reason to enforce them from in software, at least not in release 1. This is just one way to reduce the size of the initial release to a manageable size.

But there is much more you can do. Start working with the following exercise: Instead of asking what is necessary to make the system complete, ask yourself what is the minimum value we can add, and what is necessary to add only that. If you make each increment the answer to this question you will have made huge strides in the art of the small.

Posted in Coaching, Development, Quality Assurance, Success | Tagged , , , , , | Leave a comment

Not If But When

I hear this over and over and over. “We didn’t have time to write automated unit tests and now regression bugs are killing us.”

People always struggle with the cost of quality, but the cost of quality can’t be avoided. It can only bey delayed, and as it is delayed it compounds. To keep the cost low, you need to address it immediately.

If you’re going to build and design as you go (more on that in another post) then you have to be free to change your design as you go. And if you don’t have automated unit tests changing your design is a crap-shoot early in the project and somewhere between trouble and disaster later in the project. In addition, as you go you know you will need to refactor your code and you have to have good automated unit testing to know the refactor was successful.

Can’t you just test manually? You can if it’s a simple and small application. But with each build the regression demand increases. With any but the smallest application your time required to test a build will eventually overwhelm the time available to run the tests. Automated unit tests are the only way to keep up.

If your current project doesn’t have good automated test coverage then you are caught in a very difficult place. I recommend paying the penalty as soon as possible since it only becomes more expensive with time.

More importantly, I want to convince you to never start another project without including comprehensive automated unit testing. Use test-driven development if at all possible. If you can’t do that then make a full automated set of tests a part of your definition of done.

But what if you aren’t very good at coming up with test assertions? If that’s the case, find a mentor or do some studying and improve. But until then write the best test cases you can. At least you’ll have those to help you minimize bugs. If you add a test for every bug found in later testing your suite will quickly become the suite you need it to be.

Posted in Quality Assurance | Tagged , , , , , | Leave a comment

Agile by the numbers

If you’re reading this looking for a simple formula for implementing an Agile methodology you won’t find it. Agile by the numbers is a pipe dream because agility isn’t a task you accomplish, it’s a trait you develop. And developing traits takes time and follows no formula.

Here is a list of key steps on the path of becoming agile.

  • Stop accomplishing tasks. Agile people can’t focus on the task, they need to focus on the goal. When we’re surprised (as we almost always are) we need to be able to re-think the task in a way that lets us achieve the goal.
  • Stop being patient. I remember asking a tester if the developer was aware of a major blocking bug he’d found. He said he’d sent an email. When I pressed him it turned out he’d sent the email four hours earlier. He’d been unable to work on the Story for four hours and he didn’t even know if anyone had read his email. When one developer wasn’t getting what he needed from another he said, “I know she’s busy and I don’t want to nag.” If someone’s counting on you to get something done you can’t take these delays.
  • Stop being clever. There’s an old story about a digital toaster where a software developer overly engineered a design for a digital toaster that eventually required a high-powered (for the time) computer to run. The original intent of the story was to remind software developers that, in the real world, you only want enough software to get the job done.
  • Stop rushing. People who are rushing make foolish, sometimes harmful mistakes. We’ve all experienced this, usually realizing that we could have afforded just a little more time to think carefully. In writing software you will introduce a silly defect that’s hard to track down, or forget to log the data that could have helped you find it. In testing you will skip a key step and miss a key defect. When documenting the defect you may leave out key information that makes it harder to debug. Take the time to think and work in the most effective way possible.
  • Stop playing it safe. All of software development involves risk. Things will go wrong. Eventually something you do will go wrong. These risks are inherent in what we do. What we want to do is identify the risks early, especially if they will actually kill the project. We don’t want anyone to be foolish but we want people who aren’t afraid to experiment to find out what is possible and what isn’t. Often it’s faster and easier to do an experiment than to do an analysis.

So, to recap (not in a particular order, but at least there are numbers):

  1. Stop accomplishing tasks, start achieving goals.
  2. Stop being patient, start getting things done.
  3. Stop being clever, start being productive.
  4. Stop rushing, start working quickly.
  5. Stop playing it safe, start playing it smart.


If you’re interested in learning about Agile QA (not by the numbers) check out the 2-Day Agile QA Course to be held at the beginning of October.

Posted in Transformation | Tagged , , , , , | Leave a comment

A New Normal

“It’s just not reasonable to expect developers to <insert your Agile behavior request here>.”

I hear this all the time when working Agile transformations. The issue here is someone who is very effective in the current development process who resists an important change for working with an Agile team. This person is valuable to the organization now but will likely impede team formation and the Agile transformation. How do you deal with this situation?

We need to recognize that someone who is productive working in their own way may be very good in a traditional environment but doesn’t know what he or she is really capable of doing. The reality is that everyone in the team benefits from Agile methods. Success has demonstrated that people work better as part of a team that is focused on achieving a common goal.

Some may struggle to work well as a team member. But it’s important they learn how as the Agile transformation takes hold in more and more workplaces. Developers who object to Agile methods may not find alternatives available for much longer. Fortunately, I believe that anyone who is willing to experiment and adapt can learn to be comfortable doing things a new way.

When a team first starts moving to Agile they will become less effective in the short term. Everyone who is learning new habits puts energy into forming the habit which reduces the energy for doing other tasks. The beginning of a transformation is always marked by reduced effectiveness. The reward is after the new habits are learned a whole new normal for effectiveness becomes possible. The person who was really good in the old normal becomes part of an amazing team in the new normal. They produce more bug-free code. They produce it faster. It makes the customer happier. They enjoy work more.

That seems, to me, to be worth the effort to change.

For those in the New York City area struggling to understand how the new normal works for QA professionals, I am offering a two day Agile QA course. I’d love to meet you there.

Posted in Transformation | Tagged , , , , | Leave a comment

Is Agile QA necessary?

I’ve recently discussed an Agile QA Transformation with two clients. These clients are moving to Agile development but want specific help in transforming their QA to support Agile methods. They believe there’s specific need for Agile QA and they want me to help them get there. How different this is from the days when the Agile community (mostly developers) was telling me QA wasn’t necessary because quality was built in.

I think Agile QA is necessary. Here are 6 reasons you should consider having trained Agile QA experts on your team.

  • Making things is a different skill than breaking things. Many of the best testers find problems in places other people don’t look.
  • (related) Years of testing gives experience in things to test. Tester training provides other ideas.
  • If your development is subject to regulatory oversight you will need QA to assure the compliance requirements are met.
  • Traditional testers will naturally try to find ways to do traditional QA within an Agile iteration. That won’t work. You’ll want people trained or skilled in testing in an Agile way
  • QA (assuring good code before it’s written) is separate from QC (test). Agile gives you the opportunity to practice true QA. Your traditional QA experts will need to shift their focus back to creating quality (shift left).
  • You’ll want your developers focused on their development expertise. Even in fully cross-functional teams you will want at least one QA expert as a part of the team. Just putting a traditional QA/test expert in a Scrum team isn’t good enough.

But now we have a problem – traditional QA/test experts won’t be good fits on a cross-functional team until they become Agile but you can’t become Agile without some experience on a cross-functional team.

Until your QA/test experts gain Agile experience you can give them training and coaching. You can also just toss them in and let them learn by doing following the Agile approach of inspect and adapt. Eventually they will become powerful supporters of your methodology, but that will take time.

NOTE: For those looking for training I offer a 2-day training course for QA/Test experts who want to work in Agile teams. You can find out about the next course here.

Posted in Quality Assurance | Tagged , , , , | Leave a comment

When is ROI the wrong calculation?

If you’re trying to sell a quality improvement technology or process you’ll eventually be asked to calculate the Return on Investment. Management wants a way to monetize the pros and the cons of the change you’re proposing. Converting your proposal to dollars is seen as an easy way to put the trade-offs into a universal language.

The problem with ROI and quality improvement is that you’re measuring the dollar value of things you’re trying to prevent. And if you prevent them you can’t prove they would have happened or that your quality initiative is what prevented them.

This is hard to do with a quality improvement process such as Test Driven Development. By any account TDD increases the amount of code written for a given piece of functionality. You may get differing estimates of the increase, such as 1:1 vs. 2:1, but you still write tests as well as functional code so there is more code written. On the other hand one IBM/Microsoft study showed a 40% – 90% reduction in bugs at code completion. If these bugs never happened, how do you justify the double- or triple-code?

If the teams have a history you can estimate the overall cost of defect remediation and reduce that amount by 40% (the low end) or 65% (the middle reduction).  Still, there are occasional defects that cost significantly more than what’s typical. You also have potentially unaccounted costs if defect remediation is built in as part of business as usual. (Consider that all defect fixes go into the next release which is tested as a whole build by the QA team. You may not be able to separate the portion of the QA effort in re-testing bug fixes vs. testing the new functionality.) And your whole argument may be lost if a critical defect does make it into production even though TDD may have kept 10 others from ever being created.

Even a 15% – 35% improvement in development speed (from the same study) isn’t a killer argument. If a team has been working together for a while it will improve its productivity so you can’t be certain TDD was responsible. In the end, your ROI calculation is fairly easy to cook depending on what result you need to deliver. More importantly, it’s very difficult to prove true or false.

So how should you approach quality initiatives if not via ROI? In many cases you have to look at the ROI of development as a whole and stop attributing ROI to specific development practices. You don’t put an ROI on using Java or C# instead of FORTRAN, do you? The question should be this: Are we delivering quality software at a cost that is profitible to the company? Will this change reduce that profitability?

The reason this isn’t the same as asserting a positive ROI of TDD is because all development practices interact. TDD may improve your confidence in refactoring your code. The refactoring may be the greatest single contributor to improved performance, but TDD enabled fearless refactoring. Which one had the positive ROI? Similarly TDD may significantly reduce the cost of your functional test automation. Functional test automation may allow you to run complete regression suites on each build. The rapid feedback from the continuous regression may be the key to reduced defects making it into the QA verification cycle. Which piece had the positive ROI?

Don’t get me wrong. I’m a big fan of putting proposals into terms C-level people can understand. But I’m not a fan of cooking results or hiding information in overly-broad metrics. If you have to calculate an ROI, there are numbers on the Internet that can help you do that. But helping your executives understand the real value of quality initiatives is a much better answer.

Posted in Management, Quality Assurance, ROI, Uncategorized | Tagged , , , , , , | Leave a comment

The Functional Manager in Agile

When doing an Agile transformation it’s generally easy to get team members on board with what we’re trying to achieve. Most people appreciate the opportunity to become empowered and to have a better understanding of the business goals they’re supporting. The improved communication with “the business side” of the organization helps team members to feel more a part of the company as a whole. They start to really own their responsibility of adding business value rather than developing code.

Likewise, senior executives generally buy into Agile quickly. They may not understand all the benefits they can achieve, but they’ve seen enough to know that Agile projects are generally more successful than traditional projects. They want to reap the benefits of that success so they encourage a transformation.

Unfortunately the functional manager is often caught in the middle of this transformation. Things are changing and they aren’t really sure of their role or the benefits they will see in their own jobs It has taken me a while to understand this because I’ve always functionally managed in a way very compatible with Agile methods. I’ve never liked working in a strong command and control environment so I’ve always resisted creating one for the people who work for me.

The Agile functional manager is no longer responsible for work product. That comes from the team and it holds itself responsible. Similarly, the Agile functional manager doesn’t task people. The team assigns itself tasks as it completes the User Stories that are in the backlog. So what does the Agile functional manager do?

Simply put, the Agile functional manager assures his or her team can achieve everything they set out to achieve. Depending on your personality and your strengths this can take different forms. In an Agile organization you should be able to find the approach that works best for you.

If you’re more people oriented you can be the coach and mentor for the people who report to you. Agile teams need highly skilled team members. As a functional manager you can help your reports see where they have weaknesses. You can provide instruction or help the report find the training they need. You can champion training to senior management to further empower and grow your team. You can attend events that help you understand what your teams need to grow and how to provide it to them.

The technically minded functional manager can focus on the high-level issues that cross Agile teams. You might identify and help mitigate cross-team risks. You might look for architectural changes that will improve the velocity or quality of your teams. You might evaluate or recommend third party products or tools your team works with. You might also create tools or integrations that help your team work more effectively.  If you’re interested in new technologies you might help chart the technical strategy based on the overall business vision of the organization.

If you’re one of the few technical managers who really liked doing reports and reviews, the Project Management Office will still need your help. You can continue to do the reporting and documentation of performance that keeps the organization running, and maybe help them find more efficient ways to accomplish their goals.

You should see the transformation to Agile as an opportunity to focus on the part of your job that you really like or are best at.  The Agile organization gives everyone a chance to do what they do best. That includes the functional manager.

Posted in Development, Management | Tagged , , , , | Leave a comment