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.

Advertisements
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

Scrum MVP

If you come from a traditional development background, one of the more difficult transitions you will make is moving from working solely in your area of expertise to doing whatever it takes to finish a Story.

You’re used to having your assigned tasks and being responsible for completing your tasks. You might be paid to write software, or create designs, or write test cases, or execute and automate tests. Suddenly you’re part of a Scrum Team and you’re paid to finish Stories. (That’s not absolutely true, of course. You’re actually paid to add Business Value. But the way a Scrum Team adds value is by finishing Stories.) So you get paid to make sure the Story is designed, coded, tested, fixed, reviewed, and finally accepted by the Product Owner as ready for Production. If the code is amazing and the Product Owner loves the approach, it adds no value if there are open bugs and it’s not Production ready.

Doing whatever it takes means that you have to become competent at areas outside of your expertise. You will rely on the experts to provide direction, but you will need to help out with something that wasn’t originally in your job description. And this means that you need to take every opportunity to learn. What makes a good test? What do the ETL guys do? What are the elements of a good user experience, or a good design? How do you optimize your access to a database? Ultimately you’re asking,  “What can I do to get this Story to done?”

The more things you know how to do, the more of a Scrum MVP you become.

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

Islands in the Stream

When scaling Agile, most people still talk about a Scrum of Scrums. This is a meeting where the individual ScrumMasters discuss issues that have impact across teams. I’m not sure the Scrum of Scrums name is correct, because these meetings can’t wait for risks to become blockers to address them. By the time a blocker is caused by another team there’s usually no quick way to have the blocker resolved. ScrumMasters need to be addressing those risks before they become blockers.

In reality, Scrum of Scrums is a way to ensure ScrumMasters talk with each other. A Scum-type meeting shouldn’t be required for this as ScumMasters should be excellent at encouraging communication. However, it is a good idea to have a way to keep track of issues that pose cross-team risks.

At my current assignment, we’re using Agile for JIRA. One project ran a successful experiment of making sure that each team that is facing the risk creates a JIRA issue to track its responsibility for the Story. That is, if I have work that I have to complete at a certain point for Project B, Project B’s ScrumMaster creates a zero-effort Story in his/her backlog that can be linked to the corresponding Task or Story in my Backlog. In this way, the two ScrumMasters have a reminder to continue to communicate.

A key point to remember is that these tasks are constraints. Project B has placed a constraint on my team, often with a due-date that needs to be met for a specific reason. I need to treat this task as a constraint from another team. I either need to make this due-date or communicate issues to Project B’s ScrumMaster early and often. Since Scrum considers the backlog to be fluid, much like a stream of Stories, I consider these constraints “Islands in the Stream.”

Let me explain. In Scrum, the Product Owner can re-arrange priorities based on changing technical realities or changing business needs. This may move some items earlier or later in the Release Plan. But these constraints can’t move. In the case of work that our team owes another team, we can’t move the item later because that would impact the other team. If another team is constraining us, we can’t move constrained work earlier because the other team won’t be finished. In both cases, those Stories or Tasks are immovable. They’re the islands in the otherwise fluid Backlog stream.

All constraints can be viewed in this way. Sometimes you need to keep parts of your Backlog on schedule because your sales cycle has fixed dates and you have to be able to promise certain functionality by those dates. Sometimes new functionality can’t be built until you receive a new version of a third-party library.

What happens if you can’t meet a deadline that’s a constraint for another team? The same thing that would happen in any project with cross-team dependencies. You discuss the problem with that team’s ScrumMaster so you can work out a solution that works for both. This needs to be done as soon as possible, which is the purpose of linking the Stories or Tasks in JIRA.

For those not using JIRA or not using technology, there are other ways to mark the Stories or Tasks as impacting another team. If you’re using sticky notes, you can put a colored dot on the note. If you’re using other tools that don’t allow linking, put a special word in the title of the Story or Task such as CONSTRAINT:. Anything that will trigger the conversation will meet the need.

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