Posted: What Is A Professional?

I write a twice-yearly column for Better Software magazine. The title of the column is called “Technically Speaking.” For this column, I decide to tackle the question of “What’s a Professional?” If you don’t already subscribe to the magazine, you do have to join the site. It’s a free registration to...

Management Myth #4: I Don’t Need One-on-Ones

“I know what the people in my group are doing, Johanna. Each and every one of them.” “But you have twenty-five people in your group, Stan,” I protested. “And I walk around and see what every single person is doing. I read their checkins, too. I know what they are doing.” I was working with a client on the organization’s project portfolio, the order of which projects they were going to do when, and which projects they were not going to staff for now. Stan, the engineering director, was convinced he knew exactly who was working on what. I was equally convinced he did not. I had inside information—some of the developers told me they were working on skunkworks projects, projects that people had started out of their initiative to see if they had any value. One-on-ones are great for career development conversations. And, they are great for coaching and feedback. And, if you have inquisitive, innovative, entrepreneurial leaders in your organization—especially if you subscribe to the 20 percent time idea that Google and Atlassian promote—you need to know what people are working on. But one-on-ones aren’t for status reports. They aren’t just for knowing all the projects. They are for feedback and coaching, and meta-feedback and meta-coaching, and for fine-tuning the organization. If you are a manager and you aren’t using one-on-ones, you are not using the most important management tool you have. One-on-Ones Help You See Organizational Status, Not Micromanagement If you are a manager and you read developers’ checkin comments, that smacks of micromanagement to me. But if you ask a developer if he or she...

Roll Your Own (Agile Lifecycle)

Imagine this scenario: you want to transition to agile, and you have a geographically dispersed team with people all over the world. You have two developers in the UK and two in Boston, two testers in Portland, Oregon, a product manager in Brazil, and you, the project manager are in Sweden. And, you are pretty sure that transitioning to agile would make a difference to your project, because you’ve used agile before on a different project in a different organization. And, because you are geographically distributed, you know can’t use agile-out-of-the-box. What do you do? One approach is to start with the principles of agile and decide how to create an agile environment that works for you, your team, and your context. You create your own agile lifecycle. That’s what Joakim, a Swedish project manager did. Joakim and I spoke when he was organizing the team. He asked about the iteration length. I asked if the thought the team could manage a one-week iteration. He thought not; he thought a two-iteration would be a big-enough shock to their system. Why a short iteration, such as one or two weeks? Because the team needs the feedback about everything, not just the code. They need the feedback about their planning, about their standups, about their stories, about how they work together, everything. Everything about their transition to agile is an experiment, so they need to start with a short iteration. One week is even better, but for many teams that seems impossible to imagine, so they start with a two-week iteration. This team was lucky, and the product manager flew up...

Transitioning to Agile Testing

Summary: Your developers are already working feature-by-feature in iterations, but your testers are stuck with manual tests. How do you make the leap to agile testing when the nature of agile’s iterative releases challenges testers to test working segments of a product instead of the complete package? In this week’s column, Johanna Rothman explains that the key challenge resides in bringing the whole team together to work towards the completion of an iteration. Only then will the testers–and the entire team–know how to transition to agile. Some test teams may be stumped on how to transition to agile. If you’re in such a team, you probably have manual tests for regression either because you never have had the time to automate them or because you are testing from the GUI and it doesn’t make sense to automate them. You probably have great exploratory testers who can find problems inside complex applications, yet they tend not to automate their testing and need a final product before they start testing. You know how to plan the testing for a release, but now everything has to be done inside a two-, three-, or four-week iteration. How do you make it work? How do you keep up with development? This is a common problem. In many organizations, developers think they have transitioned to agile while testers are still stuck in manual testing efforts and unable to “keep up” at the end of the iteration. When I explain to these people that they are receiving only partial benefit of their agile transition, the developers and testers both explain that the testers are just too...

Project Portfolio Decisions–Decisions For Now

If you are anything like me, you have a to-do list a mile long. Because I work for myself, I have an integrated list of everything I need to do: projects for clients, books to write, articles to write, columns to write, presents to buy, house maintenance, clothes to organize, office cleanup. The list is long and never-ending. That’s okay. That’s because, if I take something off my list and finish it, I can choose what to do next. I might rank projects one way one day and another way the next day. For example, a few weeks ago, we had some high winds, and I noticed some chimney bricks in the yard. I put “fix chimney” on my list. It was pretty low on my list. I had client work and some writing I thought was higher priority. Now, after 12 inches of rain outside and wet carpet in my office, fixing the chimney is at the top of my list. But I take an agile approach to my work, as well as teaching agile to my clients. In order to “fix chimney”, I need to call masons, get them to come out and look at the chimney, get the quotes, compare the quotes, get them start and finish their work which may require me to negotiate how to work with them, and who knows what else. What I’ve listed is the known list of tasks to the relatively large user story, “As a home owner, I want to live in a house with no chimney leaks” and the smaller stories of, “As a homeowner, I want to...