Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Managing Product Development - Johanna Rothman
Syndicate content
Expert in Managing Product Development
Updated: 6 hours 25 min ago

What Development & Test Managers do in Agile Organizations

Thu, 01/29/2015 - 14:28

Is there room for functional managers, such as development and test managers, in agile organizations? Maybe. It depends on whether they take the role of an agile manager.

If you have organized as a feature teams-based organization, the functional managers (development, test, analysis, whatever) can take these responsibilities:

  • Develop trusting relationships with the people on the project team, and in their function.
  • Provide coaching and mentoring opportunities for people.
  • Provide communities of practice for the people.
  • Remove obstacles for the people and team.
  • Start and nurture the hiring effort whenever you need to hire new people.
  • Help people with career development.
  • Provide feedback to people, and help people learn how to provide feedback (meta-feedback).
  • Provide coaching and meta-coaching when people want it.
  • Help the organization understand its capacity and make decisions about the project portfolio.
  • Help influence the rest of the organization with the agile culture.

Functional managers are champions for the team, and shepherds for the process. They are servant leaders.

Here’s what functional managers do not do:

  • Have status conversations. If the team is agile, the team understands its status. If you need help seeing their board, that’s a problem the team needs to solve. If they need help seeing their status, they need to change their board or their process for updating each other.
  • Move people on or off teams, once you or the team establishes itself.
  • Ask people to do something the team has not committed to, or that the product owner has not added to the kanban board. That’s right. “Your” team doesn’t work for you; the team works for the product owner.
  • Micromanage any part of the project work. Or, manage any part of the project work.

What does this mean? It means that the team members are leaders. Agile pushes responsibility into the teams, and away from traditional management. Agile requires leadership at all levels.

Agile challenges managers to recreate their jobs. An agile transformation requires managers work in an agile way, and work differently than before.

If you want to learn more about the role of leaders and managers in agile, join Gil Broza and me at The Influential Agile Leader, either in San Francisco or London this year. We still have an early bird price until mid-February. Don’t miss this opportunity to help your agile transition and your career.

Categories: Project Management

We Need Planning; Do We Need Estimation?

Wed, 01/21/2015 - 14:37

As I write the program management book, I am struck by how difficult it is to estimate large chunks of work.

In Essays on Estimation and Manage It!, I recommend several approaches to estimation, each of which include showing that there is no one absolute date for a project or a program.

What can you do? Here are some options:

  1. Plan to replan. Decide how much to invest in the project or program for now. See (as in demo) the project/program progress. Decide how much longer you want to invest in the project or program.
  2. Work to a target date. A target date works best if you work iteratively and incrementally. If you have internal releases often, you can see project/program progress and replan. (If you use a waterfall approach, you are not likely to meet the target with all the features you want and defects you don’t want. If you work iteratively and incrementally, you refine the plan as you approach the target. Notice I said refine the plan, not the estimate.
  3. Provide a 3-point estimate: possible, likely, and worst case. This is PERT estimation.
  4. Provide a percentage confidence with your estimate. You think you can release near a certain date. What is your percentage confidence in that date? This works best with replanning, so you can update your percentage confidence.

Each of these shows your estimation audience you have uncertainty. The larger the project or program, the more you want to show uncertainty.

If you are agile, you may not need to estimate at all. I have managed many projects and programs over the years. No one asked me for a cost or schedule estimate. I received targets. Sometimes, those targets were so optimistic, I had to do a gross estimate to explain why we could not meet that date.

However, I am not convinced anything more than a gross estimate is useful. I am convinced an agile roadmap, building incrementally, seeing progress, and deciding what to do next are good ideas.

Agile Roadmap When you see this roadmap, you can see how we have planned for an internal release each month.

With internal releases, everyone can see the project or program progress.

In addition, we have a quarterly external release. Now, your project or program might not be able to release to your customers every quarter. But, that should be a business decision, not a decision you make because you can’t release. If you are not agile, you might not be able to meet a quarterly release. But, I’m assuming you are agile.

Agile Roadmap, One Quarter at a time In the one-quarter view, you can see the Minimum Viable Products.

You might need to replace MVPs with MIFS, Minimum Indispensable Feature Sets, especially at the beginning.

If you always make stories so small that you can count them, instead of estimate them, you will be close. You won’t spend time estimating instead of developing product, especially at the beginning.

You know the least about the risks and gotchas at the beginning of a project or program. You might not even know much about your MIFS or MVPs. However, if you can release something for customer consumption, you can get the feedback you need.

Feedback is what will tell you:

  • Are these stories too big to count? If so, any estimate you create will be wrong.
  • Are we delivering useful work? If so, the organization will continue to invest.
  • Are we working on the most valuable work, right now? What is valuable will change during the project/program. Sometimes, you realize this feature (set) is less useful than another. Sometimes you realize you’re done.
  • Are we ready to stop? If we met the release criteria early, that’s great. If we are not ready to release, what more do we have to do?

Here’s my experience with estimation. If you provide an estimate, managers won’t believe you. They pressure you to “do more with less,” or some such nonsense. They say things such as, “If we cut out testing, you can go faster, right?” (The answer to that question is, “NO. The less technical debt we have or create, the faster we can go.”)

However, you do need the planning of roadmaps and backlogs. If you don’t have a roadmap that shows people something like what they can expect when, they think you’re faking. You need to replan the roadmap, because what the teams deliver won’t be everything the product owner wanted. That’s okay. Getting feedback about what the teams can do early is great.

There are two questions you want to ask people who ask for estimates:

  1. How much would you like to invest in this project/program before we stop?
  2. How valuable is this project/program to you?

If you work on the most valuable project/program, why are you estimating it? You need to understand how much the organization wants to invest before you stop. If you’re not working on the most valuable project/program, you still want to know how much the organization wants to invest. Or, you need a target date. With a target date, you can release parts iteratively and incrementally until you meet the target.

This is risk management for estimation and replanning. Yes, I am a fan of #noestimates, because the smaller we make the chunks, the easier it is to see what to plan and replan.

We need planning and replanning. I am not convinced we need detailed estimation if we use iterative and incremental approaches.

Categories: Project Management

Discovering Your Leadership Posted

Mon, 01/19/2015 - 19:01

I published a new Pragmatic Manager this past weekend. It’s called Discovering Your Leadership.

It has a pointer to the Influential Agile Leader event that Gil Broza and I are leading in San Francisco and then in London. You can still get early bird pricing, until Feb 15. Don’t miss this opportunity—we’re only leading it twice this year.

Categories: Project Management

Does Agile Apply to Your Project?

Tue, 01/13/2015 - 14:49

I have a new column posted at projectmanagement.com. It’s called Does Agile Apply to Your Project? (You might need a free registration.)

 

Categories: Project Management

Does Agile Work Because We are Optimistic?

Mon, 01/12/2015 - 14:50

I read the Business Week opening remarks, How Optimism Strengthens Economies.  See this quote at the end:

the group of people who turn out to be most accurate about predicting how long it will take to complete tasks—and how likely they are to succeed—are the clinically depressed. Optimists underestimate how difficult it will be to succeed. But that self-deception is precisely what makes them willing to take more risks and invest in a better future, while the pessimists slouch toward self-fulfilling failure. 

Pessimistic people are more accurate with their estimation. Optimists underestimate. Their optimism allows them to take more risks and innovate. Which kind of person are you? (I’m both, in different circumstances.)

That got me thinking about why agile works.

Agile and lean (I’m using agile as shorthand for both) help us make progress in small chunks. That creates hope and optimism in the project team. When the project team demos or releases to other people, they trust the team and a become hopeful and optimistic.

We know from The Progress Principle: Using Small Wins to Ignite Joy, Engagement, and Creativity at Work that the more we make progress with small wins, the better we feel and the more likely we are to make more progress. That leads to hope and optimism.

Is this why agile works? Because we can make progress daily?

It’s not the only reason. We also need feedback. When we provide demos to other people, as often as possible, we build trust. With trust comes the possibility of better connection and feedback.

We get feature-itis because we’re no longer in requirements hell. Other people can see that a project team can deliver. That leads to optimism and hope in the organization. (I’m differentiating the two, because they are different. See my review of Seligman’s book.) With hope, people can rise to many occasions. Without hope? I bet you’ve been there on a project. It isn’t pretty.

Agile is not for everyone. Agile approaches? Yes. Completing small chunks of work and showing it to other people? You can do that with deliverable-based planning, building incrementally, and iterative approaches to replanning. If you want a name for that approach, it’s called staged delivery or design to schedule.

If you’re doing agile well, you’re delivering new small features into the code base every day or every other day. That helps you feel as if you’re making progress. When you feel as if you’re making progress, you can be more optimistic or hopeful. That helps you see new possibilities.

I would rather work in a hopeful way, making progress on a project, than feel as if I’m dragging. What about you?

So, agile might increase optimism, which allows us to make more progress and innovate. Agile done well brings joy to our work.

People are always asking my why agile works, or to prove it works. I can’t prove anything.

I have said that in my experience, when people work in an agile way, they are more productive and more effective. Now I wonder if this is because they are optimistic and hopeful about their work.

Categories: Project Management

Change the Indispensable Employee Mindset

Wed, 01/07/2015 - 17:46

Years ago, I was the expert for two specific products in a small development organization. When it came time for my manager to divide up the work, I always got those products to add features to, or maintain. That was fine for a while, until I got bored. I went to my boss with a request for different work.

“Who will do the work if you don’t?” My boss was concerned.

“Steve or Dave will. They’re good. They can take over for me.” I knew my colleagues. They could do the work.

“But, they’ll have to learn what you do.”

“I know. I can take a few days to explain, if you want. I don’t think it will take a few days to explain. They’re smart. I’m still available if they have questions.”

“I don’t know. You’re indispensable where you are.”

I faced my boss and stood up. “No one is indispensable. And, if I am, you should replace me on those systems anyway. What are you going to do if I leave?”

My boss paled, and asked, “Are you planning to leave?”

“I don’t know. I’m bored. I want new work. I told you that. I don’t see why I can’t have new work. You need developers on these projects.” I named three of them. “Why do I have to stay doing work on the old stuff when I want to do new things. I don’t see why I should. Just because I’ve been doing it for a year is no reason to pigeon-hole me. No. I want new work. I’m not indispensable. You can hire someone and I can train that person if you want.”

My boss reluctantly agreed to let me stop working on the old systems and work on the new projects. I was no longer indispensable.

The problem with being an indispensable employee is that your options are limited. Your boss wants you to keep doing the same thing you’ve always done. Maybe you want that, too for now. The problem is that one day, you realize no one needs what you do. You have become such an expert that you are quite dispensable. You have the same year of experience for several years.

Instead of being indispensable, consider how to help other people learn your work. What do you want to learn next? You need to plan your career development.

What do you do if you’re a manager, and you have indispensable employees? “Fire” them.

I’m serious. When you have people who are indispensable, they are experts. They create bottlenecks and a cost of delay. If you need flexibility in your organization, you need people who know more than one area. You need teams who are adaptable and can learn quickly. A narrow expert is not what you need.

When I say “fire” people, I mean don’t let them work on their area of expertise alone. Create a transition plan and help the expert discover new skills.

Why should you do this? Because if not, people and projects across the organization decide they need that person. Sometimes with quite bad results.

This month’s management myth is based on a true story. The organization wanted an expert to change teams and move. All because of his expertise. That’s nuts. Go read Management Myth 36: You Have an Indispensable Employee.

Categories: Project Management

New Year’s Tips Posted

Tue, 01/06/2015 - 20:53

I have posted my most recent Pragmatic Manager newsletter on my site. Read Johanna’s 2014 New Years Tips.

I have a question for you. I send the newsletter to my subscribers the last week of the year. I call them “this-year” tips. Some people ask me if I mean “the next year”. I don’t because it’s this year. Is this confusing? Should I rename my end-of-the-year tips? Thanks for your feedback.

Categories: Project Management

How Do You Serve Your Organization?

Mon, 12/29/2014 - 16:41

A recent coaching client was concerned about the progress his team was making—or really, the lack of progress his team was making. We spoke about the obstacles he had noticed.

“The team doesn’t have time to write automated tests. As soon as they finish developing or testing a feature, people get yanked to another project.”

“Are people, developers and testers, working together on features?” I wanted to know.

“No, first a developer works on a feature for a few days, then a tester takes it. We don’t have enough testers to pair them with developers. What would a tester do for three or four days, while a developer worked on a story?”

“So, to your managers, it looks as if the testers are hanging around, waiting on developers, right?” I wanted to make sure I understood at least one of his problems.

“Yes, that’s exactly the problem! But the testers aren’t hanging around. They’re still working on test automation for stories we said were done. We have more technical debt than ever.” He actually moaned.

“Would you like some ideas? It sounds as if you are out of ideas here.” I checked with him.

“Yes, I would!” He sounded grateful.

These were the ideas I suggested:

  1. Don’t mark stories as done, unless they really are done, including all the automated tests. You might need a kanban board instead of a Scrum board, to show your workflow to yourselves, inside the team.
  2. Work as developer-tester pairs, or even better, developer-developer-tester triads. Or, add even more developers, so you have enough developers to complete a story in a day or so. When the developers are done, they can see if the tester needs help with test automation hooks, before they proceed to another story.
  3. Make sure the product owner ranks all the stories in an iteration, regardless of which product the stories belong to. That way the team always works together, the entire iteration.

I asked him if he could do these things for the team. He said he was sure he could. I’d been coaching him for a while. He was pretty sure he could coach his team.

Now I asked him the big question. Could he influence the project portfolio work at the level above him? His managers were too involved in who was doing what on the teams, and were not ranking the projects in the project portfolio. He needed to influence the managers to flow work through the team, and not move people like chess pieces. Could he do that?

He and I started to work through how and who he could influence.

Technical leads, first- and middle-managers may find influence more challenging. You have to build rapport and have a relationship before you influence people. Had he done that yet? No, not yet.

You often need to serve your organization at several levels. It doesn’t matter if you are a technical leader, or someone with manager in your title. Rarely can you limit your problem-solving to just your team.

If these challenges sound like yours, you should consider joining Gil Broza and me in the Influential Agile Leader in either San Francisco or London next year. It’s an experiential event, where you bring your concerns. We teach a little, and then help you with guided practice. It’s a way to build your servant leadership and learn how to coach up, down, and sideways. It’s a way to learn who and how to influence. We have more sessions, so you can bring your issues and address them, with us and the other participants.

Our early bird pricing expires Dec 31, 2014. Please join us at Influential Agile Leader.

Categories: Project Management

Manage Your Project Portfolio is Featured in Colombia’s Largest Business Newspaper

Thu, 12/18/2014 - 16:11

Andy Hunt, the Pragmatic Bookshelf publisher, just sent me an email telling me that Manage Your Project Portfolio is featured in La RepĂşblica, Columbia’s “first and most important business newspaper.” That’s because getabstract liked it!  

la_repĂşblica_20141204Okay, my book is below the fold. It’s in smaller print.

And, I have to say, I’m still pretty excited.

If your organization can’t decide which projects come first, second, third, whatever, or which features come first, second, third, whatever, you should get Manage Your Project Portfolio.

Categories: Project Management

Team Competition is Not Friendly

Mon, 12/15/2014 - 17:06

I once worked in an organization where the senior managers thought they should motivate us, the team members. They decided to have a team competition, complete with prizes.

I was working on a difficult software problem with a colleague on another team. We both needed to jointly design our pieces of the product to make the entire product work.

After management announced the competition, he didn’t want to work with me. Why? There was prize money, worth hundreds of dollars to each person. He had a mortgage and three kids. That money made a big difference to him. I was still single. I would have stuck that money into either my savings or retirement fund, after buying something nice for myself.

Management motivated us, alright. But not to collaborate. They motivated us to stop working together. They motivated us to compete.

Our progress stopped.

My boss wanted to know what happened. I explained. I couldn’t fault my colleague. He wanted the money. It made a big difference for him. I would have appreciated the money, but not nearly as much as he would have. (Later, when I was paying for childcare, I understood how much of a difference that money made.)

I then had this conversation with my boss, ranting and raving the entire time:

“Look, do you want the best product or the best competition?”

“What?”

“You can’t have both. You can have a great product or you can have a great competition. Choose. Because once you put money on the table, where only one team gets the money, we won’t collaborate anymore.”

My boss got that “aha” look on his face. “Hold that thought,” he said.

The next day, management changed the competition. Now, it was about the teams who worked together to create the best product, not the one team who had the best idea. Still not so good, because all the teams on the program needed to collaborate. But better.

When I had my one-on-one with my boss, I explained that all the teams needed to collaborate. Were they really going to pay everyone a bonus?

My boss paled. They had not thought this through. “I’d better make sure we have the funds, right?”

People don’t work just for money. You need to pay people a reasonable salary. Remember what Dan Pink says in Drive: The Surprising Truth About What Motivates Us. People work for autonomy, mastery, and purpose. If you exchange the social contract of working for autonomy, mastery, and purpose for money, you’d better pay enough money. You also better repeat that money the next time. And, the next time. And, the next time.

That’s the topic of this month’s management myth: Management Myth 35: Friendly Competition Is Constructive.

Software product development is a team activity, full of learning. As soon as you make it a competition, you lose on the teamwork. You lose the learning. Nobody wins. There is no such thing as “friendly” competition.

Instead, if you go for collaboration, you can win.

Read Management Myth 35: Friendly Competition Is Constructive.

Categories: Project Management

When Should You Move from Iterations to Flow?

Wed, 12/10/2014 - 14:45

I’m writing part of the program management book, talking about how you need to keep everything small to maintain momentum. Sometimes, to keep your work small, teams move from iterations to flow.

Here are times when you might consider moving from iteration to flow:

  • The Product Owner wants to change the order of features in the iteration for business reasons, and you are already working in one- or two-week iterations. Yes, you have that much change.
  • You feel as if you have a death march agile project. You lurch from one iteration to the next, always cramming too much into an iteration. You could use more teams working on your backlog.
  • You are working on too many projects in one iteration. No one is managing the project portfolio.

This came home to me when I was coaching a program manager working on a geographically distributed program in 2009. One of the feature teams was responsible for the database that “fed” all the other feature teams. They had their own features, but the access and what the database could do was centralized in one database team. That team tried to work in iterations. They had small, one- or two-day stories. They did a great job meeting their iteration commitments. And, they always felt as if they were behind.

Why? Because they had requests backed up. The rank of the requests into that team changed faster than the iteration duration.

When they changed to flow, they were able to respond to requests for the different reports, access, whatever the database needed to do much faster. They were no longer a bottleneck on the program. Of course, they used continuous integration for each feature. Every day, or every other day, they updated the access into the database, or what the database was capable of doing.

The entire program regained momentum.

kanban.iterationThis is a simplified board. I’m sure your board will look different.

When you work in flow, you have a board with a fixed set of Ready items (the team’s backlog), and the team always works on the top-ranked item first. Depending on the work in progress limits, the team might take more than one item off the Ready column at a time.

The Product Owner has the capability to change any of the items in the Ready column at any time. If the item is large, the team will spend more time working on that item. It is in the Product Owner’s and the team’s interest to learn how to make small stories. That way, work moves across the board fast.

If you use a board something like this, combined with an agile roadmap, the team still has the big picture of what the product looks like. Many of us like to know what the big picture is. And, we see from the board, what we are working on in the small. However, we don’t need to do iteration planning. We take the next item off the top of the Ready list.

There is no One Right Answer as to whether you should move from iteration to flow. It depends on your circumstances. Your Product Owner needs to write stories that are small enough that the team can complete them and move on to another story. Agile is about the ability to change, right? If the team is stuck on a too-large story, it’s just as bad as being stuck in an iteration, waiting for the iteration to end.

However, if you discover, especially if you are a feature team working in a program, that you need to change what you do, or the order of what you do more often than your iterations allow, consider moving to flow. You may decide that iterations are too confining for what you need.

Categories: Project Management

Who Removes Your Obstacles?

Tue, 12/02/2014 - 15:21

In self-organizing teams, teams remove their own obstacles. It’s a good idea. It can be difficult in practice.

In Scrum, the Scrum Master is supposed to facilitate removing the team’s obstacles that the team can’t remove. It’s a good idea. It can be difficult in practice.

And, what if you aren’t doing Scrum, or you’re transitioning to agile and you don’t yet have a self-organizing team? Maybe you have an agile project manager. Maybe you have a team facilitator. Not every team needs a titled manager-type, you know. (Even I don’t think that, and I come from project management.)

Maybe the team bumps up against an obstacle they can’t remove, even if they try. Why? Because the obstacles the team can’t remove tend to fall in these categories:

  • Cross-functional problems across several teams or across the organization
  • Problems up the hierarchy in the organization
  • Problems that occur both places, as in over there in another department and higher up in the hierarchy

Oh boy. Someone who either used to be technical or used to be a first-line manager is supposed to talk to a VP of Support or Sales or the CIO or the CTO or “the Founder of the Company” and ask for help removing an impediment. Unless the entire organization is already agile, can you see that this is a problem or a potential problem?

Chances are good that during an organization’s transition to agile, the team’s facilitator (regardless of the title) will need help from a more senior manager to remove obstacles. Not for the team. For the rest of the organization.

Now, I would love it if the person who is supposed to remove obstacles was that designated facilitator (Scrum Master, agile project manager, whomever). And, that designated facilitator had the personal power to do it all by him or herself. But, I’m a realist. In my clients, that doesn’t happen without management support.

Is it a problem if a manager removes obstacles?

I don’t think so, as long as the manager supports the team, and doesn’t prevent the team from solving its own problems.

Here are examples I would expect the team to solve on its own:

  • Not finishing stories inside an iteration because there is too much work in progress or each person take his or her own story. This is a problem the team can manage by reviewing the board, or by pairing or swarming. The team has many options for solving this problem.
  • Too much work in progress. Again, the team can often manage this problem. The first step is to see it.
  • Not getting to “done” on stories. The first steps are to make the stories smaller, to make sure you have acceptance criteria, to work with the product owner on making stories smaller, those kinds of things. Maybe the first step is to make sure you have integrated testers into your team. But that might require managers to help.
  • Having trouble deciding what team norms are and the resulting issues from that.

Here are obstacles mid-level managers or more senior managers might help with:

  • Creating cross-functional teams, not silo’d teams. I keep seeing “developer” teams and “tester” teams being told “Go Agile!” No, agile is a cross-functional team where you have all the roles you need on one team to accomplish the work. This misconception is often a management misconception.
  • Which project is #1 (managing the project portfolio). If the team has a ton of interruptions or a demand for multitasking because management can’t decide which project is #1, I would expect some manager to take this obstacle on and resolve it. The pressures for multitasking or interruptions often arise from outside the team.
  • How the organization rewards people. At some point, agile bumps up against the culture of individual rewards. Managers might be the ones who need to manage HR.
  • When the product owner goes missing, or the team has no product owner. The team is now missing a key piece to their success and what makes agile work. Very few teams can demand a product owner, especially if they are new to agile.

This is a form of management as servant leadership, where the manager serves the team.

Do you see how certain problems are inside-the-team problems and the team can solve them? Other problems are not inside-the-team problems, and are part of the organization’s system. The organization needs to decide, “How committed to agile are we?” and address these issues.

Categories: Project Management

Five Tips to Hiring a Generalizing Specialist

Mon, 11/24/2014 - 13:19

We talk a lot in agile about generalizing specialists. Scott Ambler has a terrific essay on what a generalizing specialist is:

  • Has one or more technical specialties…
  • Has at least a general knowledge of software development.
  • Has at least a general knowledge of the business domain in which they work.
  • Actively seeks to gain new skills in both their existing specialties as well as in other areas, including both technical and domain areas

(From Scott Ambler’s essay, http://www.agilemodeling.com/essays/generalizingSpecialists.htm)

How do you hire one of these mythical people?

First, they are not mythical. They are real. Second, you do a job analysis, just as you would for any job. Third, you would look at how they have acquired skills throughout their careers.

What does this mean for the hiring manager and/or recruiter?

  1. If you search on keywords only, you will miss these people. They may not have all the keywords you want on a resume. That’s because they are generalizing specialists. You have to write a job description to entice these people to an opportunity.
  2. If you say things such as, “You will have worked at a place like <insert name of your favorite company here>” you may well miss great people. You are assuming a particular class of people. You have to change your assumptions about work history, school history, any kind of history. Again, the job description or ad has to be about an opportunity where people can learn and grow.
  3. You have to look at how they have learned in their resume.
  4. You have to look at their technical leadership roles. Yes, they will show you technical leadership in their list of accomplishments. They will have made things better in any number of dimensions.
  5. You need to look at the non-technical skills, such as facilitation, collaboration, coaching, initiative, taking small steps to make progress, all the things I mentioned in Hiring for an Agile Team: Making Tradeoffs.

Remember, you want generalizing specialists. True specialists introduce a cost of delay into your projects. They end up with a queue of work and they introduce a delay, or they multitask.

Categories: Project Management

Make Stories Small When You Have "Wicked" Problems

Fri, 11/21/2014 - 15:10

If you read my Three Alternatives to Making Smaller Stories, you noticed one thing. In each of these examples, the problem was in the teams’ ability to show progress and create interim steps. But, what about when you have a “wicked” problem, when you don’t know if you can create the answer?

If you are a project manager, you might be familiar with the idea of “wicked” problems from   from the book Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms. If you are a designer/architect/developer, you might be familiar with the term from Rebecca Wirfs-Brock’s book, Object Design: Roles, Responsibilities, and Collaborations.

You see problems like this in new product development, in research, and in design engineering. You see it when you have to do exploratory design, where no one has ever done something like this before.

Your problem requires innovation. Maybe your problem requires discussion with your customer or your fellow designers. You need consensus on what is a proper design.

When I taught agile to a group of analog chip designers, they created landing zones, where they kept making tradeoffs to fit the timebox they had for the entire project, to make sure they made the best possible design in the time they had available.

If you have a wicked problem, you have plenty of risks. What do you do with a risky project?

  1. Staff the project with the best people you can find. In the past, I have used a particular kind of “generalizing specialist,” the kind where the testers wrote code. The kind of developers who were also architects. These are not people you pick off the street. These are people who are—excuse me—awesome at their jobs. They are not interchangeable with other people. They have significant domain expertise in how to solve the problem. That means they understand how to write code and test.
  2. Help those generalizing specialists learn how to ask questions at frequent points in the project. In my inch-pebble article, I said that with a research project, you use questions to discover what you need to know. The key is to make those questions small enough, so you can show progress every few days or at least once week. Everyone in the project needs to build trust. You build trust by delivering. The project team builds trust by delivering answers, even if they don’t deliver working code.
  3. You always plan to replan. The question is how often? I like replanning often. If you subscribed to my Reflections newsletter (before the Pragmatic Manager), back in 1999, I wrote an article about wicked projects and how to manage the risks.
  4. Help the managers stop micromanaging. The job of a project manager is to remove obstacles for the team. The job of a manager is to support the team. Either of those manager-types might help the team by helping them generate new questions to ask each week. Neither has the job of asking “when will you be done with this?” See Adam Yuret’s article The Self-Abuse of Sprint Commitment.

Now, in return, the team solving this wicked problem owes the organization an update every week, or, at the most, every two weeks about what they are doing. That update needs to be a demo. If it’s not a demo, they need to show something. If they can’t in an agile project, I would want to know why.

Sometimes, they can’t show a demo. Why? Because they encountered a Big Hairy Problem.

Here’s an example. I suffer from vertigo due to loss of (at least) one semi-circular canal in my inner ear. My otoneurologist is one of the top guys in the world. He’s working on an implantable gyroscope. When I started seeing him four years ago, he said the device would be available in “five more years.”

Every year he said that. Finally, I couldn’t take it anymore. Two years ago, I said, “I’m a project manager. If you really want to make progress, start asking questions each week, not each year. You won’t like the fact that it will make your project look like it’s taking longer, but you’ll make more progress.” He admitted last year that he took my advice. He thinks they are down to four years and they are making more rapid progress.

I understand if a team learns that they don’t receive the answers they expect during a given week. What I want to see from a given week is some form of a deliverable: a demo, answers to a question or set of questions, or the fact that we learned something and we have generated more questions. If I, as a project manager/program manager, don’t see one of those three outcomes, I wonder if the team is running open loop.

I’m fine with any one of those three outcomes. They provide me value. We can decide what to do with any of those three outcomes. The team still has my trust. I can provide information to management, because we are still either delivering or learning. Either of those outcomes provides value. (Do you see how a demo, answers or more questions provides those outcomes? Sometimes, you even get production-quality code.)

Why do questions work? The questions work like tests. They help you see where you need to go. Because you, my readers, work in software, you can use code and tests to explore much more rapidly than my otoneurologist can. He has to develop a prototype, test in the lab and then work with animals, which makes everything take longer.

Even if you have hardware or mechanical devices or firmware, I bet you simulate first. You can ask the questions you need answers to each week. Then, you answer those questions.

Here are some projects I’ve worked on in the past like this:

  • Coding the inner loop of an FFT in microcode. I knew how to write the inner loop. I didn’t know if the other instructions I was also writing would make the inner loop faster or slower. (This was in 1979 or so.)
  • Lighting a printed circuit board for a machine vision inspection application. We had no idea how long it would take to find the right lighting. We had no idea what algorithm we would need. The lighting and algorithm were interdependent. (This was in 1984.)
  • With clients, I’ve coached teams working on firmware for a variety of applications. We knew the footprint the teams had to achieve and the dates that the organizations wanted to release. The teams had no idea if they were trying to push past the laws of physics. I helped the team generate questions each week to direct their efforts and see if they were stuck or making progress.
  • I used the same approach when I coached an enterprise architect for a very large IT organization. He represented a multi-thousand IT organization who wanted to revamp their entire architecture. I certainly don’t know architecture. I know how to make projects succeed and that’s what he needed. He used the questions to drive the projects.

The questions are like your tests. You take a scientific approach, asking yourself, “What questions do I need to answer this week?” You have a big question. You break that question down into smaller questions, one or two that you can answer (you hope) this week. You explore like crazy, using the people who can help you explore.

Exploratory design is tricky. You can make it agile, also. Don’t assume that the rest of your project can wait for your big breakthrough.  Use questions like your tests. Make progress every day.

I thank Rebecca Wirfs-Brock for her review of this post. Any remaining mistakes are mine.

Categories: Project Management

Three Alternatives for Making Smaller Stories

Wed, 11/19/2014 - 19:02

When I was in Israel a couple of weeks ago teaching workshops, one of the big problems people had was large stories. Why was this a problem? If your stories are large, you can’t show progress, and more importantly, you can’t change.

For me, the point of agile is the transparency—hey, look at what we’ve done!—and the ability to change. You can change the items in the backlog for the next iteration if you are working in iterations. You can change the project portfolio. You can change the features. But, you can’t change anything if you continue to drag on and on and on for a give feature. You’re not transparent if you keep developing a feature. You become a black hole.

Managers start to ask, “What you guys doing? When will you be done? How much will this feature cost?” Do you see where you need to estimate more if the feature is large? Of course, the larger the feature, the more you need to estimate and the more difficult it is to estimate well.

Pawel Brodzinski said this quite well last year at the Agile conference, with his favorite estimation scale. Anything other than a size 1 was either too big or the team had no clue.

The reason Pawel and I and many other people like very small stories—size of 1—means that you deliver something every day or more often. You have transparency. You don’t invest a ton of work without getting feedback on the work.

The people I met a couple of weeks ago felt (and were) stuck. One guy was doing intricate SQL queries. He thought that there was no value until the entire query was done. Nope, that’s where he is incorrect. There is value in interim results. Why? How else would you debug the query? How else would you discover if you had the database set up correctly for product performance?

I suggested that every single atomic transaction was a valuable piece. That the way to build small stories was to separate this hairy SQL statement was at the atomic transaction. I bet there are other ways, but that was a good start. He got that aha look, so I am sure he will think of other ways.

Another guy was doing algorithm development. Now, I know one issue with algorithm development is you have to keep testing performance or reliability or something else when you do the development. Otherwise, you fall off the deep end. You have an algorithm tuned for one aspect of the system, but not another one. The way I’ve done this in the past is to support algorithm development with a variety of tests.

Testing Continuum from Manage It!This is the testing continuum from Manage It! Your Guide to Modern, Pragmatic Project Management. See the unit and component testing parts? If you do algorithm development, you need to test each piece of the algorithm—the inner loop, the next outer loop, repeat for each loop—with some sort of unit test, then component test, then as a feature. And, you can do system level testing for the algorithm itself.

Back when I tested machine vision systems, I was the system tester for an algorithm we wanted to go “faster.” I created the golden master tests and measured the performance. I gave my tests to the developers. Then, as they changed the inner loops, they created their own unit tests. (No, we were not smart enough to do test-driven development. You can be.) I helped create the component-level tests for the next-level-up tests. We could run each new potential algorithm against the golden master and see if the new algorithm was better or not.

I realize that you don’t have a product until everything works. This is like saying in math that you don’t have an answer until you have the finished the entire calculation. And, you are allowed—in fact, I encourage you—to show your interim work. How else can you know if you are making progress?

Another participant said that he was special. (Each and every one of you is special. Don’t you know that by now??) He was doing firmware development. I asked if he simulated the firmware before he downloaded to the device. “Of course!” he said. “So, simulate in smaller batches,” I suggested. He got that far-off look. You know that look, the one that says, “Why didn’t I think of that?”

He didn’t think of it because it requires changes to their simulator. He’s not an idiot. Their simulator is built for an entire system, not small batches. The simulator assumes waterfall, not agile. They have some technical debt there.

Here are the three ways, in case you weren’t clear:

  1. Use atomic transactions as a way to show value when you have a big honking transaction. Use tests for each atomic transaction to support your work and understand if you have the correct performance on each transaction.
  2. Break apart algorithm development, as in “show your work.” Support your algorithm development with tests, especially if you have loops.
  3. Simulate in small batches when you have hardware or firmware. Use tests to support your work.

You want to deliver value in your projects. Short stories allow you to do this. Long stories stop your momentum. The longer your project, and the more teams (if you work on a program), the more you need to keep your stories short. Try these alternatives.

Do you have other scenarios I haven’t discussed? Ask away in the comments.

This turned into a two-parter. Read Make Stories Small When You Have “Wicked” Problems.

Categories: Project Management

Have You Signed Up for the Conscious Software Development Telesummit?

Tue, 11/18/2014 - 19:14

Do you know about the Conscious Software Development Telesummit? Michael Smith is interviewing more than 20 experts about all aspects of software development, project management, and project portfolio management. He’s releasing the interviews in chunks, so you can  listen and not lose work time. Isn’t that smart of him?

If you haven’t signed up yet, do it now. You get access to all of the interviews, recordings, and transcripts for all the speakers. That’s the Conscious Software Development Telesummit. Because you should make conscious decisions about what to do for your software projects.

Categories: Project Management

Five Tips for Tactical Management

Tue, 10/28/2014 - 18:15

Sometimes, you just need to get on with the work. You need to give yourself some breathing room so you can think for a while. Here are some tips that will help you tackle the day-to-day management work:

  1. Schedule and conduct your one-on-ones. Being a manager means you make room for  the people stuff: the one-on-ones, the coaching and feedback or the meta-coaching or the meta-feedback that you offer in the one-on-ones. Those actions are tactical and if you don’t do them, they become strategic.
  2. As a manager, make sure you have team meetings. No, not serial status meetings. Never those. Problem solving meetings, please. The more managers you manage, the more critical this step is. If you miss these meetings, people notice. They wonder what’s wrong with you and they make up stories. While the stories might be interesting, you do not want people making stories up about what is wrong with you or your management, do you?
  3. Stop multitasking and delegate. Your people are way more capable than you think they are. Stop trying to do it all. Stop trying to do technical work if you are a manager. Take pride in your management work and do the management work.
  4. Stop estimating on behalf of your people. This is especially true for agile teams. If you don’t like the estimate, ask them why they think it will take that long, and then work with them on removing obstacles.
  5. If you have leftover time, it’s time to work on the strategic work. What is the most important work you and your team can do? What is your number one project? What work should you not be doing?  This is project portfolio management. You might find it difficult to make these decisions. But the more you make these decisions, the better it is for you and your group.

Okay, there are your five tips. Happy management.

Categories: Project Management

Is Your Culture Working the Way You Think it Is?

Tue, 10/21/2014 - 16:14

Long ago, I was a project manager and senior engineer for a company undergoing a Change Transformation. You know the kind, where the culture changes, along with the process. The senior managers had bought into the changes. The middle managers were muddling through, implementing the changes as best they could.

Us project managers and the technical staff, we were the ones doing the bulk of the changes. The changes weren’t as significant as an agile transformation, but they were big.

One day, the Big Bosses, the CEO and the VP Engineering spoke at an all-hands meeting. “You are empowered,” they said. No, they didn’t say it as a duet. They each said it separately. They had choreographed speeches, with great slide shows, eight by ten color glossies, and pictures. They had a vision. They just knew what the future would hold.

I managed to keep my big mouth shut.

The company was not doing well. We had too many managers for not enough engineers or contracts. If you could count, you could see that.

I was traveling back and forth to a client in the midwest. At one point, the company owed me four weeks of travel expenses. I quietly explained that no, I was not going to book any more airline travel or hotel nights until I was paid in full for my previous travel.

“I’m empowered. I can refuse to get on a plane.”

That did not go over well with anyone except my boss, who was in hysterics. He thought it was quite funny. My boss agreed I should be reimbursed before I racked up more charges.

Somehow, they did manage to reimburse me. I explained that from now on, I was not going to float the company more than a week’s worth of expenses. If they wanted me to travel, I expected to be reimbursed within a week of travel. I got my expenses in the following Monday. They could reimburse me four days later, on Friday.

“But that’s too fast for us,” explained one of the people in Accounting.

“Then I don’t have to travel every other week,” I explained. “You see, I’m empowered. I’ll travel after I get the money for the previous trip. I won’t make a new reservation until I receive all the money I spent for all my previous trips. It’s fine with me. You’ll just have to decide how important this project is. It’s okay.”

The VP came to me and tried to talk me out of it. I didn’t budge. (Imagine that!) I told him that I didn’t need to float the company money. I was empowered.

“Do you like that word?”

“Sure I do.”

“Do you feel empowered?”

“Not at all. I have no power at all, except over my actions. I have plenty of power over what I choose to do. I am exercising that power. I realized that during your dog and pony show.

“You’re not changing our culture. You’re making it more difficult for me to do my job. That’s fine. I’m explaining how I will work.”

The company didn’t get a contract it had expected. It had a layoff. Guess who got laid off? Yes, I did. It was a good thing. I got a better job for more money. And, I didn’t have to travel every other week.

Change can be great for an organization. But telling people the culture is one thing and then living up to that thing can be difficult. That’s why this month’s management myth is Myth 34: You’re Empowered Because I Say You Are.

I picked on empowerment. I could have chosen “open door.” Or “employees are our greatest asset.” (Just read that sentence. Asset???)

How you talk about culture says a lot about what the culture is. Remember, culture is how you treat people, what you reward, and what is okay to talk about.

Go read Myth 34: You’re Empowered Because I Say You Are.

Categories: Project Management

Podcast with Cesar Abeid Posted

Wed, 10/15/2014 - 15:42

Cesar Abeid interviewed me, Project Management for You with Johanna Rothman. We talked about my tools for project management, whether you are managing a project for yourself or managing projects for others.

We talked about how to use timeboxes in the large and small, project charters, influence, servant leadership, a whole ton of topics.

I hope you listen. Also, check out Cesar’s kickstarter campaign, Project Management for You.

Categories: Project Management