Thoughts on Infrastructure, Technical Debt, and Automated Test Framework

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 for the automation. But automation is a project. You should have a vision and release criteria. You should adapt to change in that project, just like any other project.
  7. As you work on a story, whomever you are, you help out wherever you are. If you are, by nature, a code developer, you start with the code. Here’s a story to illustrate what I mean:

You happen to be Platform Paul and you do some development, some refactoring, maybe some rearchitecture, some unit test development, whatever it takes to make your code work and checked in. Fine, you are done.

You check with Tina the tester. She is having trouble with the system tests. You do not abandon her, saying, “My part is done.” Oh, no no no no you don’t.

You say, “Hey, Tina, what’s going on? What can I do?” She tells you. The two of you work on her automated test framework, refactoring it until it works for the new code you checked in and her tests. Once it works, and her tests work, now the two of you walk over to Willie Writer.

Willie glares at both of you and says, “I keep writing the online help, but you two kept refactoring all afternoon. I keep chasing you two and those guys!” as he pointed to the other two developers. The three of you laugh and then all three of you complete the online help in the next hour.

Willie and Tina and you do a little exploratory testing under Tina’s guidance, because what do you know about exploratory testing? She calls it “session-based testing.”

Now, the three of you check with the other two developers who have finished the GUI and the middleware, and only now do you move the story to done. Because the feature required a little platform work, more middleware, and a little GUI to be complete.

Product owners, if you don’t want to fund technical debt, you will create more of it. You will slow down the rate of creating features. I have example graphs of this in Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects.

You don’t have to have the perfect automated test framework, not at the beginning of a project. You don’t know what it is at the beginning of a project. You only know you need one. But you can write a little and refactor it. I wrote a column about that.

And, when it comes to creating technical debt, the one thing you must do is, stop. No matter what, you must not create more. And, if you wander into some code or tests that have technical debt, I do not see how you can be a professional and leave it there. At the very least, you can create a defect report that says, “We have technical debt here.” You know it’s going to bite you on the tush at the most inopportune time.

I am not a fan of “go rewrite the system to avoid technical debt.” But you and I both know that technical debt slows down system development and often slows down system performance. I want to avoid rewrites. I want to clean up as I go. If you clean up every single one or two-day feature, you don’t have to pay a huge price, ever.

Posted in project management | Tagged , , , , , , | 12 Comments

Podcast about Transparency Posted

Tom Cagley interviewed me a few weeks ago on his Software Process and Measurement Cast. It’s posted now, as # 180.

When Tom interviews me, he makes me think. This is good. I would love to hear your comments about this one. We started with transparency and wove our way around to several topics. I even ranted about the craziness of individual raises and how that disturbs the system of working in teams.

Enjoy!

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

Leanpub Podcast Up

A few weeks ago, Peter Armstrong interviewed me for Leanpub, to ask me why I enjoyed writing on Leanpub. That podcast is up now on the Leanpub Buzz page.

What’s very funny is that the interview is a few weeks old. I had no idea he was going to post it right after I wrote Dear Author. About 11 minutes in, I talk about the boring trap, the passive voice trap in my own writing. I think this is pretty funny.

Posted in writing | Tagged , , , , | 1 Comment

Dear Author

In my role as technical editor for the Agile Journal and as a reviewer for my trusted colleagues, I have the opportunity to read drafts of articles and some books. I see some troublesome behavior. I know it because I exhibit it. In all cases, the author receives feedback the author doesn’t like, but doesn’t want to stop writing.

Decide on One Idea

I am the prime example of this one, so I will use an example from my writing. I was trying to write one of my Pragmatic Manager emails last week. I sent it to Esther. It was only about 200 words. She counted the number of ideas, in the opening story of fewer than 60 words and stopped at 9 ideas. She could not read anymore.

“JR, what is the main idea of this piece?”

I just about fell out of my chair laughing at myself.

I read this in articles and chapters all the time. You need one main idea in an article or a chapter. When you are done with that idea, it’s time for another article or a chapter.

If you have lots of ideas, it’s fine to have another article or a chapter. When I write books, I have a file called, “Stuff-to-put-somewhere”. It’s ideas I can’t use now, but might have a chance to use later. Maybe you don’t need a file like that, but you need a place to put stuff you are not going to use now.

You do not need to put everything you know into this article or this book. Really. I promise you.

BTW, Joyce Statz was the first one to give me this advice on my very first paper in 1995. Joyce, I am still learning. Esther gave me this advice last week. BTW, when I see this with authors, I ask them questions, as Esther did with me to help them see which ideas they want to address, or how they want to rewrite the piece.

Boring Writing Stays Boring Until You Change Something

Unless I know you well I don’t tell you your writing is boring. I may tell you that you need a story. Or, I might tell you the writing is dry. Or, that you need a story. Or that I need an example. But, a story with people yelling at each other or working through a project is a great idea.

If I tell you need a story, believe, me. You need a story or an example. I don’t tell you that because I want to hurt your feelings. I’m telling you because I fell asleep reading your work. At 8am. After I woke up and worked out. Or, took a shower. I gave your writing the best shot I knew how. It put me to sleep.

If I tell you your writing is boring, you have several choices:

  1. You can insert a story;
  2. You can take a different perspective on the entire article;
  3. Put the piece down for a week or two and come back to it later.

When Esther and I wrote Behind Closed Doors, Jerry gave us feedback on our first draft and told us it was boring. We rewrote the entire book. He told us our second draft was more boring! Esther is the one who had the transforming idea that we should write the story of Sam the perfect manager and pull out the lessons after we told the story, and that we should pair-write the book.

Do not write more words. Please. Unless you change something. If you write more words in a piece that’s already boring, it will become more boring. If you take words out, it might become less boring. Maybe. No guarantees.

90% Done Is Not Close

You are convinced you are within a few hours of finishing the piece. This is just like a software project. You are not. You are days or weeks or months away from finishing that piece in this form.

Writing in a natural language is not so different from writing code. When authors tell me they can’t take the time to put in a story because they are “almost done,” I know the piece is going to stink. I know I am going to iterate forever trying to get a great piece of writing from the author.

Throw it out and start over. It will be faster.

Sunk Cost Grabs You Every Time

When I suggest to an author that he or she try another approach, or read the piece out loud or redo a picture in a new tool or even write in a new tool, and the author rejects my advice because “I’m almost done and it’s so close,” I know the author is thinking of the sunk cost in the project already. I see this with books more often than with articles.

I want to shake the author. “Author,” I want to say, “Do you want a great article? Or do you want a crappy article? Because what you have right now stinks. Do you think I am suggesting this to you because I want to make you crazy? No. I am suggesting this to you because what you have right now is not worth publishing. I am going to go around this article with you 1700 more times and we will still be working on this graphic from now until doomsday.” I don’t say that. What I have said is, “PowerPoint is not a good tool for graphics.”

Too many authors get stuck in their thinking because of their tools. Do not write a book in Word. Do not develop graphics in PowerPoint. Those tools will constrain your thinking for the book and the graphics. If you think of them as tools for an initial rough draft of two or three pages or two or three drawings, that’s fine. But they get in the way for really writing.

For those of you who are writing books, I suggest either TextMate with leanpub or Scrivener. I much prefer TextMate with leanpub. You will need to rearchitect your book at least 6-7 times. That is, you will need to take large chunks of words and move them from here to there. If you don’t, your book will become more boring. You want to keep each chapter in a separate file. Word does not work that well for books. Oh, like any other tool, you can make it work.

(Yes, yes, I know some of you have succeeded using Word to write your books. Fine. You are the exceptions who prove the rule. If you want me to review your book, use leanpub.)

Passive Voice Stops Your Writing Dead

When I read passive voice, I question it. Not because I am a copyeditor. But because I can’t tell who is talking. Who is doing the work? Who is talking?

Search for passive voice and excise it. I just discovered a passive voice bundle for TextMate and installed it. I am one happy woman.

Noun-Verb Phrases are For the Birds

Noun verbs or noun-verb phrases are two-word verbs or phrases such as: “set up” instead of arrange, “get rid of” instead of eliminate. They weaken your writing and make me wonder what the heck you mean.

If you are wondering what “for the birds” means, it’s an idiom that means useless. That’s what those noun-verb phrase idioms are. Useless.

Use them for your first drafts. Then find them and replace them with strong verbs. Think of them like adverbs.

Excise Adverbs

If I see the word “basically” one more time, I might have to vomit. Or actually. Or, firstly. Firstly? Come on. Make a numbered list if you must.

It’s okay to write the adverbs when you write. In your first editing pass, remove all the adverbs. See how much stronger your writing is? Love it.

You might think, “Oh, did I say that? Wow, that’s really strong.” See what happens when you eliminate the adverb? You become powerful. Your writing becomes powerful. You tower over the world. You, too, become seven feet tall. I recommend it. Honestly. (Yes, that was a punny adverb. Are you paying attention? :-) Why do you think people are so surprised when they meet me in person? I have everyone convinced I am seven feet tall. Including me.

You are writing an Article or Book of lists instead of prose.

I like to read. Reading to me means I will read paragraphs of prose for a few pages. I like stories to interrupt my prose. Maybe a picture or two. I like sidebars, tips, and warnings to interrupt my prose. Those interruptions are fine.

A list is good, if and only if it pulls ideas together.

I do not like books of lists. I do not like articles of lists. When I attempt to read them, I wonder, “Did this author try to turn the slides into this book or article? I bet this was slide 32 and this was slide 33.”

If you have slides and want to turn them into a book, you are better off talking them first, and transcribing the talk. Make the slides a conversation with the reader.

I can read your two-by-two matrix. I have mine, you can have yours. I can read your lists, I certainly have mine. But don’t make me read an entire article of lists. I need prose to knit it together.

Larry Constantine gave me the best advice years ago when he asked me to write an article for the last page of Software Development magazine. “No lists, Johanna. One article of all prose.” Oh my goodness. I don’t think I had ever done that before. Well, I did. It’s a great article.

Larry is writing some terrific fiction these days, under the pen name Lior Samson. Read it. That’s an order.

Writers Make Mistakes, That’s Why We Have Editors

I make these mistakes, too. Do you think I’m perfect? Oh no. Not by a long shot. I make all these mistakes. That’s why I recognize them so well in other people’s writing.

If you want to be a better writer, read Jerry’s writing book, Weinberg on Writing: The Fieldstone Method. I have the paper version. Start here with links to the electronic versions. I also like Stephen King’s On Writing. I read the 2000 version.

Want to Write for the Agile Journal?

After all this, if you want to write for the Agile Journal, you know what you will get. I will challenge you to be the best writer you can. I will challenge me to be the best editor for you. Together, we will partner to create a great online experience for our readers.

I won’t copyedit you. Unless I can’t stand it. If you adverb me to death, I might say something. If you passive voice me, I might say something, because I will be confused. I might be a pain in your tush. But you will exit the experience with an article you can be proud of. And a new friend. Me.

And, if you are wondering how long it took me to write this, I don’t know. But I started writing it a few days ago, and WordPress tells me it went through 8 revisions. I’m sure there area mistakes even though I have self-edited.

Posted in writing | Tagged , , , , | 7 Comments

Public Workshop, Transitioning to Agile, in Stockholm, May 28-29

I’m offering a public workshop about Transitioning to Agile in Stockholm, May 28-29, 2012, in English.

Developers’ lives change when you transition to agile. Product owners’ lives change. Managers lives’ change. The organization’s culture changes. And, when a project and an organization transitions to agile, the testers and test managers lives’ change, too.

Through our debriefs, we will address these topics in the workshop:

  • Managing legacy test technical debt (what do you do with the tests that are useful but not automated?)
  • How do you change your idea of where you fit in the project?
  • How do you change others’ idea of where you fit in the project and the organization?
  • What does a test manager do?
  • How do you know a product is ready for release? Or, when is a project over?
  • How do the testers “keep up” with the developers? (It’s easy. You will experience how. Easy, peasy.)

Why is this especially for test-type people and project manager-type people? Not because I don’t like developers; I do! In many ways, the testers, project managers, and business analysts, the “not-developers” from more traditional projects have a very difficult transition. They may never have thought of themselves as product developers before. In agile, we ask them to think of themselves as such. Making the transition, and maintaining the transition can be a challenge. I can help.

Here are some slideshare.net resources you might find useful:

Some articles you might like:

I have more on my blog in the transition to agile tag.  Please poke around and read more.

I will address your issues in the workshop. But only if you sign up. I would love to see you there. Please do sign up.

 

Posted in workshop | Tagged , , | Leave a comment

Public Project Portfolio Management Workshops in Sao Paulo and Stockholm

I’m offering public project portfolio management workshops in Sao Paulo, Brazil on May 8-9, partnering with Adaptworks. I will be speaking in English. This is a full 2-day workshop.

On May 30, I will be in Stockholm, offering a special one-day version of the workshop, partnering with Citerus. I will also be speaking in English here.

Here are some resources you might find useful:

Some articles you might like:

There are more articles at my articles page. Please do poke around. I would love to see you at the Brazil workshop if you are in South America, or at the Stockholm workshop if you are in Europe. Please do sign up.

 

Posted in workshop | Tagged , | Leave a comment

Book Review: Personal Kanban: Mapping Work | Navigating Life

As a consultant, I want the flexibility to adapt my work to take advantage of opportunities that might arise in a given week–to write an article or blog post, or to propose a project to a new client.  And, while I try to plan a week’s worth work, I need the flexibility to adapt my work on the fly. I work in small chunks, finishing work. I like seeing completed work. I have a great sense of accomplishment when I see completed work.

Sure, if I have the flu or a tough vertigo attack that lasts a while where I don’t have enough slack to absorb too many “incomings,” I become overwhelmed. But I can generally manage my work. I can maintain a sustainable pace.

I tried to explain to my system to some of my executive coaching clients, but it wasn’t until I read Personal Kanban: Mapping Work | Navigating Life by Jim Benson and Tonianne DeMaria Barry that I had the words, and clearer definitions for what I was doing. Before I read the book, I didn’t know about “The Pen.”

The Pen is the place where you corral all those call-backs that can pile up. IMNHO, The Pen is a magnificent invention! It gives me the transparency I need to see that the people I need to talk to are–or are not!–calling me back, so I can decide what to do about it. If the plumber is not calling back, I might make one decision. If a potential client is not calling, I might make another decision. What’s key is that I have all the data literally at my fingertips.

What’s great about personal kanban is that I see all my work. I use it along with one-week iterations so I can track the work I don’t do. That’s how I knew it was time to ask for help in redoing my web site. It was clear to me that “redo my site” was going to stay in “ready” and never move into “doing”.

When I read this book, I kept nodding, saying, “Yes, that’s exactly how I work! That’s how I think! Why are Jim and Tonianne in my head? At least, they are doing a good job there.”

Jim and Tonianne have written a conversational, wonderful book to help you understand how to move away from todo lists to a system that helps you see your context, your work, and your work in progress.

Personal kanban has two rules: visualize your work and limit your work in progress. That’s it. Personal kanban is the way I manage my personal project portfolio. Try it for yours.

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

Throughput or Productivity?

I’m tech-editing an article for the Agile Journal. I’m having a discussion with the author about the words “productivity” and “throughput.”

I believe that what we measure in agile teams is throughput, the number of features through the team over time. I don’t think we measure productivity, the number of features per person or per team over time.

In kanban, it’s quite clear. We measure throughput. To me, it’s clear in iterations, too. We measure throughput.

The author likes the word “productivity.” I don’t :-) And, the author is a smart cookie. We’re still in tech-edit, and we have more to do, and the author will win, when push comes to shove.

It’s a very subtle distinction. What do you think? Throughput or productivity? Productivity or throughput? Which one?

Posted in project management | Tagged , , , , | 14 Comments

Belgium Testing Days Slides Posted

I posted my slides from my keynote from Belgium Testing Days 2012 at slideshare.net. The keynote was “QA or Test? Does it Matter? You Bet it Does!

I hope you enjoy it. “This person has more stories and may be funnier in person than the slides appear to be.”

Posted in conference | Tagged , , | Leave a comment

Register Now for Geographically Distributed Agile Teams Workshop

Register now, before the end of the day, March 15, for the best single-person and team rates for Shane Hastie’s and my Working Effectively In Geographically Distributed Agile Project Teams. If you don’t subscribe to my email newsletter, the Pragmatic Manager, you have missed a number of great issues where I discussed how to solve some of the challenges of working in geographically distributed agile teams:

My most recent newsletter discussed how you might start Building or Maintaining Agility in Geographically Distributed Teams.

You can hear the webinar to hear how Shane and I teach/work together.

It’s time. Sign up today.

Posted in workshop | Tagged , , | Leave a comment