Thoughts on Infrastructructure, Technical Debt, and Automated Test Framework

[article]
Summary:

I’ve had several conversations in email and with clients recently that have all been about this question: “What do we do about our infrastructure?” Either the project or the program has to create/update/upgraded their architecture or automated test infrastructure, pay down technical debt, or somehow do something that’s not part of a story.

I’ve had several conversations in email and with clients recently that have all been about this question: “What do we do about our infrastructure?” Either the project or the program has to create/update/upgraded their architecture or automated test infrastructure, pay down technical debt, or somehow do something that’s not part of a story.

And, that’s the part where I say, “Whoa, Nellie. How is technical debt not part of a story? Why does anyone care how you take care of the code base? Or the automated test infrastructure base? Why does anyone care how you curate the systems? Aren’t you in charge of your environment?”

There’s often a stunned silence. That’s when I realize that while the outward part of the project or program looks agile, the project culture is not agile.

An agile project culture has an empowered team, a team who knows that they must leave the code base a little cleaner than they found it the day before. A team who knows that they must improve the automation every day. A team who knows the story is not done until the entire story is done, and that includes the automated tests and the automated test framework. A team who knows they have to work together to deliver business value every day, not just at the end of the iteration.

This problem is related to the feature-itis problem on the part of the product owner not wanting to take iteration time to schedule anything other than features in an iteration. If the product owner only sees what code developers can do, and doesn’t look at what test developers can do, the project is not agile. If the code developers are the only ones estimating the backlog, that’s a huge problem.

Here are some solutions:

  1. Call everyone on the project “developers.” Or, call everyone “testers.” I call the team the product development team, and everyone on the team product developers. You have to change the idea that one part of the team is responsible for code and one part is responsible for tests and that the two parts do not operate together. The two parts (plus all the other parts) are responsible for moving the features to a cohesive approach to done. The more you reinforce one group is testers and one group is developers, the less chance you have of getting to done.
  2. Make sure you have a team definition of done or that you somehow know what done means. It’s not developer-done, or tester-done, it’s demo-worth-done, or release-able-worth-done. I know of some teams that take a while and many discussions to agree on what done means. Discuss it. Don’t worry if you don’t agree right away. Keep discussing it. This discussion is critical to your success as a team.
  3. Stop estimating altogether. If you have an item on the backlog larger than something the entire project team can complete in a day or two, break it apart–not into tasks, but into smaller stories of business value. Now, you have as many stories as there are days in the iteration, more or less. Makes estimating much easier. You have more conversations about the stories, and much less estimating time.
  4. When you work on the code, wherever you are in the code, leave it a little cleaner than when you found them.
  5. When you work on the tests, leave them a little cleaner than when you found them.
  6. Have a product roadmap which includes the automation. If your product owner doesn’t want to or can’t own the automation, then the technical people must own the goals and the plan

About the author

Johanna Rothman's picture Johanna Rothman

Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential “gotchas,” seize opportunities, and remove impediments. Johanna was the Agile 2009 conference chair. She is the technical editor for Agile Connection and the author of these books:

  • Manage Your Job Search
  • Hiring Geeks That Fit
  • Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
  • The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
  • Behind Closed Doors: Secrets of Great Management
  • Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People

Johanna is working on a book about agile program management. She writes columns for Stickyminds.com and projectmanagementcom and blogs on her website, jrothman.com, as well on createadaptablelife.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

May 04
May 04
May 04
Jun 01