Johanna Rothman's Blog, page 8
October 22, 2012
Many months ago, Rebecca asked an interesting question about technical debt in projects. She asked,
How to start when there’s a really big mess? In that case, small, just being a professional clean-up acts may not even make a dent.
Of course, as with any good question, the answer is, “it depends.” And the biggest flavor of depends is whether the project is large or small and if the project is collocated or distributed. For the sake of argument, let’s assume it’s small and collocated.
When you transition to agile and you have a reasonably size codebase, chances are quite good that you’ve been working on the product for a while. You have legacy code. You might have legacy tests. You certainly have legacy ways of thinking about the code and the tests. How do you work yourself out of the technical debt you have accumulated over time? Can you approach the work in the way I outlined in Thoughts on Infrastructure, Technical Debt, and Automated Test Framework?
Yes and No. Let’s assume that for some small set of features you can eat some small pieces of debt. And, you have so much debt, that there are some areas of technical debt that you just do not want to touch those areas of code, or that if you touch those areas, you know you are going to wade into quicksand. You know you have to create more tests than you have “time” to create. That is, the size of the story is significantly smaller than the size of the debt, even with swarming.
Now, what do you do?
You tell people. You tell the product owner. You tell your colleagues. Me, I would probably write some tests for the code anyway, because I would want to know the next time I wade into quicksand. But I have much more gray hair experience now than I did when I was younger, so I make different choices about the product.
If I was a project manager for this project, I would want to know, because I would want to manage the risk. In my experience, that much technical debt affects a team’s ability to produce features. And, if I was a product owner, I would want to know, because the technical debt would affect our ability to do anything with the product.
And, this is a case, where you might want to consider having three backlogs as a funnel into one backlog for an iteration. Read Might Three Backlogs Be Better Than One? And, make sure to read all the comments. They are quite insightful.
The idea is you still only have one backlog for the an iteration. But you have visibility into all the work you have to do that you want to rank for the product.
It’s easy in hindsight to say, “Don’t get into that situation.” Well, duh. But organizations are in this situation. And, they need help. I still think the best answer is to pay off the technical debt is to work in small features and pay off the debt as you find it. That way you never pay off more than you need to, you never do more architecture work than you need to, and you never have this strange backlog issue.
On the other hand, some people don’t realize how much debt they have. Anything that helps them see what they have is useful. But maybe there is a better way. Maybe you have a better way?
Let me summarize:
Pay off technical debt when you implement a story, if you can.
Swarm to start and finish a story. This will help you avoid and pay off debt.
Write more tests to expose the debt, so no one is surprised in the future.
Expose the debt by creating a debt backlog so the debt can be ranked in preparation for iteration planning.
When planning an iteration, take the top item off the debt backlog. Do pairwise comparison of that item with the top item on the feature backlog. Which item has more value? Put that item on the iteration backlog. Continue until the team says, “Stop, we cannot do more in this iteration.”
Your very last solution is rearchitecting. Why? Because it prevents you from making progress in the project. Read Startup Suicide – Rewriting the Code. It’s not just suicide for startups.
Always make sure the technical debt is visible. That is key to managing it. Whether you like my solution(s) or not, make the debt visible. And, if you don’t like any of my ideas, please do comment. Heck, comment if you do like them. I would love to know what you think.
October 17, 2012
I’ve been having some strange email conversations with two testers, one business analyst, and a project manager. Yes, a total of four new people. They have each found jobs on projects. And, they are in over their heads. Each of them wrote to me, hoping I would help.
The testers wanted to know how to write test plans and tests. The business analyst wanted to know when to get involved with the project and how to write requirements for her project. The project manager wanted to know how to organize the Gantt chart for his supposedly agile project. I told him he didn’t need a Gantt.
These poor people. In each case, I asked, “Do you want private coaching from me?” Oh, no, they replied. No, I don’t. Each one of them said so. They just wanted the answer to their question.
Well, the answer to their question requires private coaching, because the answer is project- and context-dependent, I explained. After a bunch of back and forth, I told them to start reading because they don’t know how to ask the right question. (Yes, that sounds arrogant. Sorry.) I also told them to talk to the rest of their project teams, and ask for help, because floundering by themselves is a no-win situation.
This is a management failure. It might also be a team failure. That sounds harsh, but why else would these other well-meaning people who want to succeed come to an outside expert? They don’t know what they don’t know. They don’t know who to ask down the hall. But, the answers are inside their buildings. Or, on their wikis. Or on their intranets.
And, if the answers are not written there, an external expert can’t help them find the answers. The only way they can find the answers is by talking with the other project team members. “What we have here is a failure to communicate.”
There is a reason I advocate a buddy system for new people in Hiring Geeks That Fit. With a buddy system, new people learn how to do what they need to do for this project in this context. Once they learn that, they can generalize it to the larger context.
These folks are in over their heads. Are they qualified for their jobs? I can’t tell. That’s because I suspect there are funky and suspect requirements for these projects. I think some of these organizations are in a transition state where they are not quite agile and not quite waterfall and their project teams are not quite sure what to do. That means new hires need even more coaching than they might otherwise receive.
Managers need to conduct one-on-ones, especially with new people. Managers might not need to perform the on-the-job coaching, but they need to make sure the coaching gets done by someone. Right now, all I see is the people get plunked into a project and they are not set up to succeed. They are flailing. They find me, because I write a lot.
So they ask me what they think is a reasonable question. But, it’s not reasonable, because it requires knowing about the project. These folks are frustrated, I sound like an arrogant jerk, and everyone loses.
Managers, have you hired someone recently? Are you concerned about that person’s performance? Make sure you are not contributing to their lack of performance. Start having one-on-ones.
Teams, do you have a new person? Make sure someone is coaching that new person. Make sure that person becomes a real member of your team. Don’t let that new person start asking some random expert on the web basic questions about your project. You can do better than that. Let that new person ask the expert hard questions about your project.
October 10, 2012
I wrote a column for Gantthead, How to Use Iteration Zero (or Not). I’m not a big fan of iteration zero, except for learning. In which case, it’s a great idea. Go take a look and see what you think. Please leave comments over there.
October 9, 2012
I delivered a keynote last week at StarWest, Becoming a Kick-A** Test Manager.” If you want to watch me in action, you can register for the virtual conference, and see a number of the keynotes and talks. I had an interview, too.
I try to build interaction into all my talks, including my keynotes. I asked people what some of their obstacles were. The three questions I took were meetings, supply vs. demand of testers, and hurry-and-wait syndrome.
What do you think got tweeted? Not the great content I so carefully prepared. Some of that did. But when I explained you don’t have to go to meetings with no agendas, no minutes, and no action items, that got tweeted. That surprised me! I covered this in Manage It!, but clearly, it’s time to blog more about this.
October 3, 2012
I have another management myth posted on Stickyminds. This one is about training. “Management Myth #9: We Have No Time for Training” is up on the site.
Now, I have to admit, that when I was a new manager, I fell for this myth. Oh, I knew enough to make sure that we had lunch-and-learns. I knew enough to make sure we learned from people inside the organization. I knew enough to buy books. But it took one of my testers, Meredith, to poke at me to go to a Star conference because she thought we were being too insular with our testing. She was right.
You know what’s really funny? Today, I’m keynoting at another Star conference. That’s because I take my own advice and don’t stop learning and training myself.
So, read the article. Then plan your self-improvement!
Meredith, I appreciate you for nudging and poking me all those years ago. I’m not sure I ever said that to you. It’s time I did!
October 1, 2012
I’m finally writing a Pragmatic Manager email to my faithful readers. That’s when I noticed I had forgotten to post my July email newsletter. Yikes! So, here is What Does Your Organization Reward? I am committed to emailing another email newsletter this week.
Are you on my newsletter list? Sign up on my site or on my blog. Or, if you think you are on my list and you stopped receiving the emails because you changed jobs or something, email me, and we’ll figure it out.
September 28, 2012
When I was in Brazil teaching the project portfolio workshop, one of the participants explained that his organization sometimes did a form of gold/silver/bronze comparison among the projects.
Here’s how it works. Everyone wrote their project names on stickies. The first cut is everyone self-assigns their projects to Gold, Silver, Bronze categories. That’s right, everyone does a pair-wise kind of comparison before everyone else adds their projects to decide if their projects are #1 projects, #2, or #3.
Now, everyone puts their stickies in Gold, Silver, or Bronze. Silently, they divide Gold, Silver and Bronze into thirds (Gold, Silver & Bronze), and continue, dividing into thirds, Gold, Silver & Bronze) until all the projects are ranked.
I would not do this with more than 30 or 40 projects. I would also not do this without a highly collaborative team who has been doing project portfolio management for a while, who is accustomed to developing a ranked project portfolio. But if you are such a team and you are looking for a new way to rank your project portfolio, consider this.
September 5, 2012
My most recent management myth is up on Techwell, Management Myth #8: I Can Still Do Significant Technical Work. I see managers catch themselves in this one all the time. Maybe you do too. Maybe you disagree with me. Comment over there, please.
BTW, This article is a partial attempt to answer the question, “How technical should a manager be?”
September 4, 2012
I facilitated a project management clinic last week at PSL. One of the questions was this:
We have a product owner who persists in changing the contents of the sprint during the sprint. This is difficult for us. It costs us to change the content.
Okay, this is a huge pain in the tush. It’s just like multitasking, and you know how much I like that. (Not at all!)
I suggested my colleague ask the product owner what business pressures the product owner is facing that he/she is feeling that is forcing the changes more often than two weeks. Yes, they have two-week iterations. So, what is going on that they have to change direction more often than 10 business days? Those are some fearsome business forces. Or, the Product Owner or the business have no idea what they are doing. Or something else. This is a great time to empathize with the product owner and understand more about what is going on with the business. Do they have a roadmap for the product? It’s worth knowing what’s going on.
Then, I asked if they could go to one-week iterations. That might alleviate the issue of changing requirements mid-sprint. I heard this:
No, the overhead of moving to releasing for one-week iterations is too high.
Danger, Will Robinson, Danger! You heard the “overhead” word. What does that mean? That’s code for hidden impediments.
That means it’s useful to move to one-week iterations to know what the impediments are and clear them, so that if they wanted to release at any time, they could. That would allow the Product Owner to see the value earlier, and while not change the contents mid-sprint, at least, see the value of the requests sooner.
When Product Owners want something that appears crazy, it’s useful to see if our team behaviors are pushing them into this “crazy” behavior. In this case, it’s a combination of not-so-sane behaviors. If the technical team could match the release frequency to the Product Owner mind-changing, I bet the frequency of mind-changing would decrease. Or, maybe the mind-changing would change to “Let’s do A/B experiments.” Because that might be what it is.
But, when the technical team has impediments that prevents easy releasing, everything is too hard. You have to ask yourself, “How short can the iteration be?” There is no easy answer.
When a Product Owner wants to change the iteration contents mid-sprint, and the Product Owner realizes this is a no-no, look deeper for systemic forces at work. It won’t be an easy answer, and will likely be a combination of answers. If you are lucky, it will be a relatively easy-to-diagnose problem, as this one was.
August 20, 2012
In my talk, How Much Will this Project Cost? at Agile 2012 last week, I got to say, “Short is beautiful.” For those of you who have never seen me, I’m five feet tall.
The question was something like this: For programs, don’t you want longer iterations, so people don’t have the overhead of planning, of retrospectives, of demos, of all of that?
Note: when you hear the word “overhead,” you are hearing someone who has not yet fully transitioned to agile. Overhead is code for “we have impediments and we don’t yet realize what they are, so we are calling them overhead.”
For programs, since you have many teams, you want shorter iterations and small stories. Why? To make sure you have as many interconnection points with the rest of the feature teams as possible. You want to make sure you integrate often and demo informally to anyone who will watch. Why? So you can get feedback and make sure you are on the right track.
For programs, the risks are too high to have longer times between integration points and demos. Waiting too long increases potential delays which increases risks. You have many people on a program. You want to see that they are all working together, so you want to see that their work comes together as often as possible.
At Agile 2012, Esther Derby talked about scaling agile teams being like a network. When you have networks of people and teams, you don’t always need formal communications. You know the rumor mill in your organization and how well that works. The information on it might not be so good, but the rumor mill itself works quite well. That’s exactly the model you want in programs. Small pods of people who connect with small pods of people frequently. Short iterations, short stories, that connect often with each other all over the place. (I don’t care if you work in flow. I’m using iterations as an example.)
These reasons all add up to “Short is beautiful.”
I gotta tell you, I was thrilled to be able to say that in a talk. I almost did a happy dance.