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: 3 hours 57 min ago

Learning Opportunities for All

Wed, 04/08/2015 - 19:10

If you are not on my Pragmatic Manager email list, you might not know about these opportunities to explore several topics with me this month:

An Estimation hangout with Marcus Blankenship this Friday, April 10, 2:30pm EDT. If you have questions, please email me or Marcus. See the Do You Have Questions About Estimation post. Think of this hangout as a clinic, where I can take your questions about estimation and help you address your concerns.

In the Kitchener-Waterloo area April 29&30, I’m doing two workshops that promise to be quite fun as well as educational:

  • Discovering the Leader Inside of You
  • An Agile and Lean Approach to Managing Your Project Portfolio

To see the descriptions, see the KWSQA site.

You do not have to be a manager to participate in either of these workshops. You do need to be inquisitive and willing to try new things. I believe there  is only room for two people for the leadership workshop. I think there is room for five people in the project portfolio workshop. Please do sign up now.

 

Categories: Project Management

Do You Have Questions About Estimation?

Fri, 04/03/2015 - 20:01

I am doing a google hangout with Marcus Blankenship on April 10. We’ll be talking about estimation and my new book, Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule.

The book is about ways you can estimate and explain your estimates to the people who want to know. It also has a number of suggestions for when your estimates are inaccurate. (What a surprise!)

Marcus and I are doing a google hangout, April 10, 2015. There’s only room for 15 people on the hangout live.  If you want me to answer your question, go ahead and send your question in advance by email. Send your questions to marcus at marcusblankenship dot com. Yes, you can send your questions to me, and I will forward to Marcus.

The details you’ll need to attend:

Hangout link: https://plus.google.com/events/c3n6qpesrlq5b8192tkici26lcc

Youtube live streaming link: http://www.youtube.com/watch?v=82IXhj4oI0U

Time & Date: April 10th, 2015 @ 11:30am Pacific, 2:30 Eastern.

Hope you join us!

Categories: Project Management

Do You Know How to Say No?

Tue, 03/31/2015 - 14:48

Some of my coaching clients have way more to do than they can manage. Some of my project portfolio clients are struggling with how to say no.

My most recent Pragmatic Manager newsletter is all about what to do when you have too much to do. Read it at Do You Have Too Much to Do?

Categories: Project Management

Why Managers Ask for Estimates and What They Need to Know

Thu, 03/26/2015 - 12:26

In many of my transitioning to agile clients, the managers want to know when the project will be done. Or, they want to know how much the project will cost. (I have a new book about this, Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule.)

Managers ask for estimates because they want to know something about their ability to recognize revenue this year. How many projects can they release? What is the projected effect on revenue; customer acquisition and retention; and on service revenue (training, support, all that kind of service). We pay managers big bucks so they can project out for “a while” and plan for the business.

You need to know this in your life, too. If you are an employee, you know approximately how much money you will make in a year. You might make more if you get a bonus. You might make less if you get laid off. But, you have an idea, which allows you to budget for mortgages, vacations, and kid’s braces.

Remember, in waterfall, there was no benefit until the end of the project. You couldn’t realize any benefit from a project until it was complete: not revenue, not capitalization, not any effect on what customers saw. Nothing.

When you use agile, you have options if you can release early. Remember the potential for release frequency?

If you can do continuous deployment or even release something more often, you can realize the benefits of the project before the end.

If you are agile, you don’t need to estimate a lot to tell them when they can first receive value from your work. You can capitalize software early. Your customers can see the benefits early. You might be able to acquire more customers early.

Agile changes the benefits equation for projects.

Agile is about the ability to change. We see this at the team level clearly. When the team finishes a feature, the team is ready for the next feature. It doesn’t matter if you work in flow or timeboxes, you can change the features either for the next feature (flow) or at the next timebox. You can change what the team does.

Agile is most successful when teams finish features every day (or more often). The faster you finish a feature, the faster the team gets feedback on the feature. The more flexibility the product owners has to update/change the backlog for the team (either for flow or the next timebox). The teams do have to complete their work on a feature in a reasonable amount of time. If your cycle time gets too high, no one sees the flow of features. If you don’t get to done at the end of the iteration, you don’t get the benefit of agile. Teams need to learn how to get to done quickly on small features, so they can demo and get feedback on their progress.

What does this fast delivery/fast feedback cycle do for senior managers?

It allows senior managers to change their questions. Instead of “When will this be done?” or “How much will it cost?” senior managers can ask, “When will I see the first bit of value? Can we turn that value into revenue? When can we capitalize the work?”

Those questions change the way teams and senior management work together.

When teams do agile/lean, and they have a constant flow of features, managers don’t need “assurances” or “commitments to estimates” from the teams. Instead, the team estimates a much smaller chunk of work–time to first delivery value.

You might not know precisely when you can deliver that first value. But, as soon as the team works together if they understand agile/lean, they can create a reasonable estimate. They can update that estimate if necessary.

What else can teams do?

  • Work to a target. If the teams and the product owners know that management has a desired release date, they can work to it. Teams can track their feature flow through their systems, understanding their cycle time. They can use timeboxes for focus. They can measure how close to done they are with a product backlog burnup chart.
  • Demo as you proceed. Always demo to the product owners. Depending on the pressure for revenue/whatever, ask the senior managers to participate in the demo. That way, they can see the product’s progress as you add more features.
  • Keep the backlog item size small. It doesn’t matter how much is in the backlog if the size of every item is small. The smaller the backlog items, the easier it is for teams to estimate. It’s also easier for teams to maintain a flow of features into the ever-evolving system. Who knows? You might be done earlier than you expect.

With agile, you don’t have to set the strategy for a year, fund the projects, and expect that the projects will complete within that year. A year is a long time in almost every market. Managers might want the ability to change their strategy, and still get to a first “delivery of value” date.

Our metrics need to change. Cost to release or time to release is inadequate. They are inadequate because we can change the backlog at any time.

Instead, consider these metrics:

  • Time to release value: How long will it take us to release something for revenue? (The smaller the number, the better.)
  • Frequency of release: How often can we release? (The higher the frequency, the better.)
  • Run rate (What the team costs per unit time)
  • When you capitalize software. I will admit too much ignorance here to provide you guidance.

I have other measurement suggestions for programs in Organizing An Agile Program, Part 5: Measurements That Might Mean Something to a Program.

It’s not about #noestimates. It’s about which estimates your managers need. Managers have a fiduciary responsibility to the organization. You have the responsibility to release often, at least internally. The more often you release, the fewer time/cost estimates your managers need. The more your managers can take advantage of capitalizing software and what the software can do for the organization and the customers.

Your managers need estimates. And, they need to change the estimates they request. It’s all about your organization’s transition to agile.

Categories: Project Management

More Ways to Visualize Your Project Portfolio

Wed, 03/18/2015 - 12:47

Every time I work with a client or teach a workshop, people want more ways to visualize their project portfolios. Here are some ideas:

Here is a kanban view of the project portfolio with a backlog:

Kanban view of the project portfolio

Kanban view of the project portfolio

 

 

 

 

 

 

 

And a kanban view of the project portfolio with an “Unstaffed Work” line, so it’s clear:

Project Portfolio Kanban with Unstaffed Work Line

Project Portfolio Kanban with Unstaffed Work Line

 

 

 

 

 

 

 

 

If you haven’t read Visualizing All the Work in Your Project Portfolio, you should. It has some other options, too.

I have yet more options in Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects.

Categories: Project Management

Four Tips for Managing Performance in Agile Teams

Tue, 03/03/2015 - 13:32

I’ve been talking with clients recently about their managers’ and HR’s transition to agile. I hear this common question: “How do we manage performance of the people on our agile teams?”

  1. Reframe “manage performance” to “career development.” People on agile teams don’t need a manager to manage their performance. If they are retrospecting at reasonable intervals, they will inspect-and-adapt to work better together. Well, they will if managers don’t interfere with their work by creating experts or moving people off project teams.
  2. The manager creates a trusting relationship with each person on the team. That means having a one-on-one weekly or bi-weekly with each person. At the one-on-one, the manager provides tips for feedback and offers coaching.  (If the person needs it or wants it from the manager.) The person might want to know where else he or she can receive coaching. The manager removes obstacles if the person has them. They discuss career development.
  3. When managers discuss career development, each person needs to see an accurate view of the value they bring to the organization. That means each person has to know how to give and receive feedback. They each have to know how to ask for and accept coaching. The manager provides meta-feedback and meta-coaching.
  4. If you, as a manager, meet with each person at least once every two weeks, no problem is a problem for too long. The people in the team have another person to discuss issues with. The manager sees the system and can change it to help the people on the team.

Now, what does this mean for raises?

I like to separate the raise from the feedback. People need feedback all the time, not just once a year. That’s why I like weekly or biweekly one-on-ones. Feedback isn’t just from the manager to the employee; it’s two-way feedback. If people have trouble working in the current environment, the managers might have a better chance to change it than an employee who is not a manager.

What about merit raises? This is tricky. So many managers and HR people continue to think one person is a star. No, on well-functioning agile teams, the team is the star—not individuals. You have options:

  • Make sure you pay each person at parity. This might not be trivial. You need expertise criteria for each job level.
  • When it comes to merit raises, provide a pot of money for the team and ask them to distribute it.
  • Distribute the merit money to each person equally. Explain that you are doing this, so people provide feedback to each other.
  • Here’s something radical: When people think they are ready for a raise or another level, have a discussion with the team. Let the team vote on it.

Managers have to not get in the way when it comes to “performance management.” The people on the team are adult humans. They somehow muddle through the rest of their lives, successfully providing and receiving feedback. They know the worth of things outside work. It’s just inside work that we keep salary secret.

It might not fit for you to have open-book salaries. On the other hand, how much do your managers and HR do that interferes with a team? You have to be careful about this.

If you reward individuals and ask people to work together as a team, how long do you think they will work together as a team? I don’t know the answer to that question.

Long ago, my managers asked me to be a “team player.”  One guy got a huge raise—and I didn’t, although I had saved his tush several times—I stopped working as a “team” member. I got my big raise the following year. (Year!) This incongruent approach is why people leave organizations—when the stated way “we work here” is not congruent with the stated goals: agile and self-organizing teams.

What do you want? Managers and HR to manage people? Or, to lead people using servant leadership, and let the teams solve their problems and manage their own performance?

If teams don’t know how to improve, that’s one thing. But, I bet your teams do know how to improve. You don’t have to manage their performance. You need to create an environment in which people can do their best work—that’s the manager’s job and the secret to “managing performance.”

Related posts:

 

Categories: Project Management

Agile Misconceptions: Agile is Just a Project Management Framework

Tue, 02/24/2015 - 18:14

If you read least week’s post about agile misconceptions, There is One Right Approach, you will like this one. This week’s article is Agile Misconceptions: Agile is Just a Project Management Framework.

If you would like more common-sense approaches to agile, sign up for the Influential Agile Leader. We’re leading it in San Francisco and London this year. We offer discounts for multiple people from your organization. Sign up now.

Categories: Project Management

Please Help Me Title Essays on Estimation

Wed, 02/18/2015 - 22:40

I have finished the content for Essays on Estimation. But, I need a new title. The book is more than loosely coupled essays. It reads like a real book, with progression and everything.

I have a number of ideas. They are (in no particular order):

  1. Predicting the Unpredictable: Essays on Estimating Project Costs and Dates
  2. Essays on Estimation: Pragmatic Approaches for Estimating Cost and Schedule
  3. How Much Will This Project Cost or When Will it be Done? Essays on Estimation
  4. Essays on Estimation: How to Predict When Your Project Will be Done
  5. Pragmatic Estimation: How to Create and Update Schedule or Cost Estimates
  6. Practical Approaches to Estimation: Create and Update Your Prediction Without Losing Your Hair
  7. Essays on Estimation: Practical Approaches for Schedule and Cost Estimates

Do you like any of these ideas? Have a better idea? I would like a title that explains what’s in the book.

I numbered these so you could respond easily in the comments with the number, if you like. Or, you can type out the entire title or a new title. I am open to ideas.

Thank you in advance.

Categories: Project Management

Agile Misconceptions: There Is One Right Approach

Mon, 02/16/2015 - 16:59

I have an article up on agileconnection.com called Common Misconceptions about Agile: There Is Only One Approach.

If you read my Design Your Agile Project series, you know I am a fan of determining what approach works when for your organization or project.

Please leave comments over there. Thanks!

Two notes:

  1. If you would like to write an article for agileconnection.com, I’m the technical editor. Send me your article and we can go from there.
  2. If you would like more common-sense approaches to agile, sign up for the Influential Agile Leader. We’re leading it in San Francisco and London this year. Early bird pricing ends soon.
Categories: Project Management

Early Bird Ends Soon for Influential Agile Leader

Sun, 02/15/2015 - 21:46

If you are a leader for your agile efforts in your organization, you need to consider participating in The Influential Agile Leader. If you are working on how to transition to agile, how to talk about agile, how to help your peers, managers, or teams, you want to participate.

Gil Broza and I designed it to be experiential and interactive. We’re leading the workshop in San Francisco, Mar 31-Apr 1. We’ll be in London April 14-15.

The early bird pricing ends Feb 20.

People who participate see great results, especially when they bring peers/managers from their organization. Sign up now.

Categories: Project Management

Posted: Creating an Environment of Leadership

Wed, 02/11/2015 - 13:55

My most recent Pragmatic Manager , Creating an Environment of Leadership is up.

If you like these tips and the ones in Discovering Your Leadership, check out the Influential Agile Leader.

Gil Broza and I are offering the Influential Agile Leader twice this year: once in San Francisco, and once in London. The early bird deadline for registration is Feb 15.

If you are trying to transition to agile and you’re having more challenges than you expected, you owe it to yourself to participate.

If you have questions, contact me. I’m happy to answer them.

Categories: Project Management

What Model Do Your Estimates Follow?

Wed, 02/04/2015 - 13:50

Cone of UncertaintyFor years, we bought the cone of uncertainty for estimation—that is, our estimates were just as likely to be over as under.

Laurent Bossavit, in The Leprechauns of Software Engineering, shows us how that assumption is wrong. (It was an assumption that some people, including me, assumed was real.)

This is a Gaussian (normal) distribution. It’s what we expect. But, it’s almost never right. As Laurent says,

“Many projects stay in 90% done for a long time.”

What curve do our estimates follow if they don’t follow a Gaussian distribution?

Troy Magennis, in “The Economic Impact of Software Development Process Choice – Cycle Time Analysis and Monte Carlo Simulation Results,” suggests we should look at the Power-Law (Weibull) distribution.

What this distribution says with respect to estimation is this: We are good at estimating small things. We get much worse with our estimation quickly, and for the long tail  (larger and larger chunks of work), we are quite bad.

Why? Because creating software is innovation. Building software is about learning. We better our learning as we proceed, assuming we finish features.

We rarely, if ever, do the same thing again. We can’t apply precise estimation approaches to something we don’t know.

You should read Troy’s paper because it’s fascinating. It’s well-written, so don’t worry about not being able to understand it. You will understand it. It’s only 10 pages long.

The question is this: What effect does understanding an estimation model have on our estimates?

If we know that the normal distribution is wrong, then we won’t apply it. Right, why would you do something you know to be wrong? You would not estimate large chunks and expect to have a +/- 10% estimate. It doesn’t make sense to do that.

But what can we do? On the printed paper, what the proceedings will show p. 5061, Troy has a table that is telling. In it, he says that if you have large unique work items or you have large WIP, you will have poor predictability. (He has suggestions for what to do for your process.)

My suggestions for your estimation:

  1. Estimate small chunks of work that a team can complete in a day or so.
  2. Keep WIP low.
  3. Replan as you finish work.
  4. Watch your cycle time.
  5. No multitasking.

What should you do when people ask you for estimates? What kind of requirements do you have? If you have large requirements, follow my advice and use the percentage confidence, as in We Need Planning; Do We Need Estimation? Read the estimation series or get Essays on Estimation.

You can predict a little for estimates. You can better your prediction. And, you may have to predict a large effort. In that case, it helps to know what distribution model might reflect your estimate.

Categories: Project Management

You Need Feature Teams to Produce Features

Mon, 02/02/2015 - 16:54

Many organizations create teams by their architectural part: front end, back end, middleware. That may have worked back in the waterfall days. It doesn’t work well when you want to implement by feature. (For better images, see Managing the Stream of Features in an Agile Program.)

Pierce Wetter wrote this great article on LinkedIn, There is no “front end” or “back end.” Notice how he says, referring to the yin/yang picture,

Your product isn’t just the white part or the black part above. It’s the whole circle.

That has implications for how you structure your teams.

If you have front end, back end, or middleware teams, you lose the holistic way of looking at features. You can’t produce features—you produce components, parts of features that work across the architecture. Even if everyone does their job perfectly, they still have to knit those pieces together to create features. Too often, the testers find the problems that prevent features.

Instead, you want a product development team, a feature team. That team has someone from the back end, someone from the front end, someone from middleware, and a tester, at minimum. Your team may have more people, but you need those people to be able to create a feature.

You might call these teams product development teams, because they produce product chunks. You can call them feature teams because they can create features.

Whatever you call them, make sure—regardless of your life cycle—that you have feature teams. You can have feature teams in any approach: serial, iterative, incremental, or agile. What differentiates these teams from functional or component teams is that feature teams can produce features.

Features are what you offer to your customers. Doesn’t it make sense that you have teams that create features?

 

Categories: Project Management

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 Predicting the Unpredictable 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