Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator/categories/6&page=5' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
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!

Project Management
warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.

Tell Your Problems to the Duck

Linda Rising gave a great talk last night at Agile New England. Her topic was problem-solving and decision-making.

One of her points was to discuss the problem, out loud. When you talk, you engage a different part of your brain than when you think. For us extroverts, who speak in order to think, this might not be a surprise. (I often say that my practice for my talks is almost irrelevant. I know what I’m going to say. And, I feed off the energy in the room. Things come out of my mouth that surprise me.)

If you’re an introvert, you might be surprised. In fact, since you think so well inside your head, you might scoff at this. Yes, speech and problem-solving both work in your frontal lobe. And, your¬†brain processes thought and speech differently.

Rubber ducks

Long ago, I was stuck on a problem. I went to my boss and he told me to talk to the duck.

“The duck?” I asked. I thought he’d lost his mind.

“Yes, this duck.” He pulled out a yellow rubber duck off his shelf. “Talk to the duck.”

I looked at him.

“What are you waiting for? Do you want to take the duck back to your office? That’s okay.” ¬†He turned back to his computer.

I sat there for a few seconds.

“You don’t pray to the duck. You talk to the duck. Now, either start talking to the duck or take the duck. But, talk to the duck.”

I am happy to say that talking to the duck worked for me. I have used that technique often.

Sometimes, I talk to a person. All they have to do is say, “Oh,” or “Uh huh,” or some other acknowledgement that they still live and breathe. If I use one person too often, I suspect they prefer if I talked to a duck.

If you are stuck on a problem, don’t do the same thing you did for the past 20 minutes. (That’s my maximum time to be stuck. Yours might be longer.) Talk to the duck.

If you want the wikipedia reference, here it is: Rubber Duck Debugging. Talk on.

Categories: Project Management

When is Agile Wrong for You?

People often ask me, “When is agile¬† right or not right for a project?” I’ve said before that if the team wants to go agile, that’s great. If the team doesn’t, don’t use agile.

That answer is insufficient. In addition to the team, we need management to not create a bad environment for agile. You might not have a great environment to start. But a bad environment? That’s a horror show.

I had a coaching conversation recently. My client¬†has a typical problem. He sees multiple ways to accomplish the work. He’s taking ideas from agile and lean, and smashing them together to create a project approach that works for them, at their company. It’s not quite agile. And, that’s the sticking point.

His management wants to “go agile.” They have no idea what that means.They think agile is a way to get more good stuff faster with less cost. It’s possible that with agile approaches, they can achieve that as a by-product. To be honest, any approach that stops people from waiting for phases to finish will help. That’s not necessarily agile.

The management team does know about one of the well-known approaches. They want everyone to go through that training. My client doesn’t think this will work. He has a number of concerns:

  • Management wants to control how people work at the project level. Management wants to define the iteration duration, what the standup questions will be, who will be on which team, and what the teams will do. (That’s enough right there, but there’s more. They are geographically dispersed across the globe. Going with an out-of-the-box solution does not make sense.)
  • Management wants to use team measurements for personal compensation. Specifically, they want to use personal velocity as a way to compensate people. (This is stupid, dangerous and wrong.)
  • Every manager my client has spoken with thinks that he or she does not need to change. Only the tech people need to change. (They could not be more mistaken.)

If you work in an agile organization, you know the problems with these assumptions.

Teams manage their own work: their intake is via the Product Owner. They decide how to work, flowing work through the team. Hopefully, the team focuses on their throughput, not who does what.

Remember,¬†Velocity is Not Acceleration. When managers abuse velocity and use it to measure the team members (not even the entire team!), they create schedule games and a toxic team environment. At best, a manager’s abuse of velocity leads to people taking shortcuts and incurring technical debt. At worse, it destroys teamwork.

Managers can create the environment in which people can succeed. Especially in agile and lean, managers do not have to “incent” people, or push people to do well. People will do a good job because they get feedback often and they want to. When managers attempt to manipulate an environment to deliver more with less work (what they think agile is), I’m not sure if anyone can succeed.

I asked my client if the managers understood what agile might mean for them, as managers. He was sure the managers had no idea.

I suggested that trying agile in this environment would give agile a bad name in the organization. I suggested these alternatives:

  • Ask about the three questions that might help the managers articulate their goals. See Define Your Agile Success.
  • Do a simulation with management to have them feel what agile is like.
  • Explain the system of agile and how the ideas that management have is not helpful.
  • Request a reasonable environment for a short-ish timebox (I was thinking about a month, maybe two months) to show management that their ideas are not the only ideas that could work. I suggested a number of measures my client could suggest to his management.

Don’t start agile in a toxic environment. It’s not worth it. Agile is wrong for you. Remember that Agile is Not a Silver Bullet and Agile is Not for Everyone.

Remember, agile is a cultural change, not merely a project management framework. Instead of agile, consider using all the ideas of agile to show steady progress and decide how to influence your managers.

Instead of agile, consider using all the ideas of agile ( for example, teamwork to deliver small chunks of value) to show steady progress and decide how to influence your managers. Don’t ask teams to be collaborative when management wants to stay command-and-control.

Categories: Project Management

When is Agile Wrong for You?

People often ask me, “When is agile¬† right or not right for a project?” I’ve said before that if the team wants to go agile, that’s great. If the team doesn’t, don’t use agile.

That answer is insufficient. In addition to the team, we need management to not create a bad environment for agile. You might not have a great environment to start. But a bad environment? That’s a horror show.

I had a coaching conversation recently. My client¬†has a typical problem. He sees multiple ways to accomplish the work. He’s taking ideas from agile and lean, and smashing them together to create a project approach that works for them, at their company. It’s not quite agile. And, that’s the sticking point.

His management wants to “go agile.” They have no idea what that means.They think agile is a way to get more good stuff faster with less cost. It’s possible that with agile approaches, they can achieve that as a by-product. To be honest, any approach that stops people from waiting for phases to finish will help. That’s not necessarily agile.

The management team does know about one of the well-known approaches. They want everyone to go through that training. My client doesn’t think this will work. He has a number of concerns:

  • Management wants to control how people work at the project level. Management wants to define the iteration duration, what the standup questions will be, who will be on which team, and what the teams will do. (That’s enough right there, but there’s more. They are geographically dispersed across the globe. Going with an out-of-the-box solution does not make sense.)
  • Management wants to use team measurements for personal compensation. Specifically, they want to use personal velocity as a way to compensate people. (This is stupid, dangerous and wrong.)
  • Every manager my client has spoken with thinks that he or she does not need to change. Only the tech people need to change. (They could not be more mistaken.)

If you work in an agile organization, you know the problems with these assumptions.

Teams manage their own work: their intake is via the Product Owner. They decide how to work, flowing work through the team. Hopefully, the team focuses on their throughput, not who does what.

Remember,¬†Velocity is Not Acceleration. When managers abuse velocity and use it to measure the team members (not even the entire team!), they create schedule games and a toxic team environment. At best, a manager’s abuse of velocity leads to people taking shortcuts and incurring technical debt. At worse, it destroys teamwork.

Managers can create the environment in which people can succeed. Especially in agile and lean, managers do not have to “incent” people, or push people to do well. People will do a good job because they get feedback often and they want to. When managers attempt to manipulate an environment to deliver more with less work (what they think agile is), I’m not sure if anyone can succeed.

I asked my client if the managers understood what agile might mean for them, as managers. He was sure the managers had no idea.

I suggested that trying agile in this environment would give agile a bad name in the organization. I suggested these alternatives:

  • Ask about the three questions that might help the managers articulate their goals. See Define Your Agile Success.
  • Do a simulation with management to have them feel what agile is like.
  • Explain the system of agile and how the ideas that management have is not helpful.
  • Request a reasonable environment for a short-ish timebox (I was thinking about a month, maybe two months) to show management that their ideas are not the only ideas that could work. I suggested a number of measures my client could suggest to his management.

Don’t start agile in a toxic environment. It’s not worth it. Agile is wrong for you. Remember that Agile is Not a Silver Bullet and Agile is Not for Everyone.

Remember, agile is a cultural change, not merely a project management framework.

Instead of agile, consider using all the ideas of agile ( for example, teamwork to deliver small chunks of value) to show steady progress and decide how to influence your managers. Don’t ask teams to be collaborative when management wants to stay command-and-control.

Categories: Project Management

Discovery Projects Work for Agile Contracts

Marcus Blankenship and I wrote an article, Stay Agile with Discovery, to discuss how to help your clients see the benefits of working in an agile or more agile way.

We have seen too many clients want “agile” and not want all the responsibilities that being a Product Owner or customer involves. If your client asks you to be agile and then demands you estimate “everything” and provide a fixed cost, fixed scope “agile” contract, you don’t have to say, “NO.”

You can say, let’s try a discovery project so we (as the provider) can explore what it would take to do “everything.” As we finish this first discovery project, where we will provide working product, you can provide us feedback. Based on that feedback, we might do another discovery project. In fact, you can work in month-long (or two-week long) discovery projects all the way through. Your client can ask for changes that you incorporate into the next discovery.

That’s just one way to help people learn about collaboration and resilience over contracts and guarantees.

If you are a Product Owner or a person who represents the customer, you might like our Practical Product Owner workshop.

Categories: Project Management

Velocity is Not Acceleration

I see a lot of confusion around velocity in new-to-agile teams.

Too many people treat velocity as an acceleration measurement. That is, they expect velocity to increase to some large number, as a stable state.

Velocity is a rate of change coupled with direction. When managers think they can measure a team with velocity, they confuse velocity with acceleration.

As I enter a highway, I have a higher rate of acceleration. As I continue to drive, I achieve a stable state: I get into a lane¬†and maintain a constant speed. (Well, with any luck.) I stay stable¬†with¬†respect to the road (my direction). My velocity stays the same—especially if I use my cruise control. With a reasonable velocity—that might change a little with traffic—I can get to my destination.

A note on direction: ¬†I live in the Boston area, where roads curve. North, South, East, and West are useful to other people. We have highways that literally point south that have a designation of “North.” They curve. I don’t find these directions useful. I am more likely to talk about the exit number on a highway or the gas station on a side road. Direction is as contextual as is velocity.

Direction for a project is much more about finishing features. How close to “done” are you? More on that below.

When managers try to use velocity as acceleration, they create schedule games. See Double Your Velocity. That often leads to people taking shortcuts and incurring technical debt.

What can you use instead of velocity? The feature burnup/burndown chart and the product backlog burnup chart.

Program.Feature.Chart_ This chart is an example of a feature burnup/burndown chart.

You chart the total number of features (the green line that wiggles at the top), the features complete (the burnup red line that continues to increase), and the features remaining (the burndown in blue, the line that proceeds down). I like this chart because you can see if things get a little “wonky” during the project.

If you add too many features faster than the team can finish features, you will have a large gap between the green and red lines. The blue line will go up. This chart shows you that. You can see how close to done you are for the project.

Product Backlog Burnup Chart (several iterations/milestones)

Product Backlog Burnup Chart (several iterations/milestones)

I also like the product backlog burnup chart. This shows how much progress a team (or teams) make on all the feature sets. (That helps people realize they should define feature sets. Feature sets help the team see where the product is headed.)

In this chart, the team works on feature set 1 (FS 1) and feature set 2 (FS 2). Those stories are more valuable than anything in feature set 3.

You can see that feature set 2 increased in the number of stories for the 5th milestone/iteration. That also helps people understand when they can expect the project to be done.

Measuring velocity¬†can help a team see what’s happening. See Value of Burndown and Burnup Charts.

However, velocity is for a team. Velocity helps a team see its context over some time period. They get to decide how to show it and what to do about it. If management wants to see progress, the team can measure the features complete, remaining, total chart and the product backlog burnup chart. (I would also measure cumulative flow to see how much work in progress the team has.)

Don’t measure velocity to see progress. ¬†That’s not the measurement you want or need.

Categories: Project Management

Writing Workshop Starts on August 24, 2016

I had a great time with my previous version of the Non-Fiction Writing Workshop: Write Non-Fiction to Enhance Your Business and Reputation. I am offering it again, starting this August 24.

I added another week, so you have the chance to practice more. I am also offering a personal accountability option. If you want, you can track your writing (words or minutes) in a group spreadsheet.

If you want to improve your non-fiction, start with your non-fiction writing, or nudge yourself to writing that book, please join me in the workshop. I’d love to work with you.

Categories: Project Management

Podcast About Agile and Lean Program Management with Ryan Ripley

Ryan Ripley and I spoke on his Agile for Humans Podcast, Agile Program Management with Johanna Rothman.

 Scaling Collaboration Across the OrganizationWe had a blast. We spoke all about Agile and Lean Program Management: Scaling Collaboration Across the Organization, estimation, value, and much more. I hope you listen.

Categories: Project Management

New Practical Product Ownership Workshop Dates

I just posted the dates for the next Practical Product Ownership workshop: Deliver What Your Customers Need. It starts Aug 23, 2016.

You need this workshop if:

  • You are having trouble doing everything in your PO role, you might be trying to do too much. See Product Manager, Product Owner, Business Analyst?
  • You are having trouble deciding how to organize your backlog, roadmap, and everything.
  • How to value the items you do organize. We discuss Cost of Delay and seven other possibilities to rank the items.
  • How to help people articulate the problems they want the team to solve, not the solutions.
  • And much, much more.

We meet twice a week for six weeks. Our first meeting is a 90-minute teaching call, where I teach and you ask questions. We meet later that week for a 60-minute coaching call, where you bring your problems, concerns, and challenges.

I estimate you will have about 60-90 minutes of homework every week. Any other questions? Email me.

Categories: Project Management

Survey About Technical Managers

Marcus Blankenship and I are conducting a survey of technical managers. If you are or have been a technical manager, please take the survey here: Software leadership 2016 survey.

Oh, and I was so curious about how many female/male managers there were, we had to ask that question. Yes, I said to Marcus, “We have to ask!” He laughed and added that question.

It should take you less than 10 minutes to fill out the survey. We will leave the survey open for no more than a couple of weeks. We’ll send the results to people who asked for it, along with publishing the results in the article we are writing.

We will not add your name to any email lists. It’s safe for your mailbox to take the survey. The link is Software leadership 2016 survey.

Categories: Project Management

A Working Definition of Agile

In a recent workshop, a¬†participant asked me, “What does agile mean? How do you know if you are agile?” He wants to use kanban to see the flow of work through his group. Someone told him he needed to use iterations to be agile. (I had a little rant about this in¬†What Does Agile Mean to You?)

I suggested this could be his working definition:

  • You can deliver what you want (some form of value).
  • You can deliver that value ¬†when you want.
  • You can then change to the next most important chunk of valuable work.
  • You learn from the previous work you did, both about the work and the process of doing the work.

That’s not all agile is, but it might be a good working definition. If you work towards being able to deliver what and when you want, move to the next thing, and learn, you have the feedback cycles. (You might also look at the agile principles behind the Manifesto.)

These are practices that increase your agile capabilities:

  • Iterations, because they limit the work a team can commit to in a given time period.
  • Kanban with work in progress limits, because they limit the work a team can do, and show the flow of work.
  • Retrospectives because you learn from previous work. (Someone important said if they only did one practice it would retrospectives. I can’t remember who said that. Sorry.)
  • Standups because they reinforce micro-commitments to finishing work.
  • Technical excellence practices from XP, because they make changing the code and tests easier.

You don’t need any of these to be agile. They help. You might find other practices to be more helpful in your context.

I have some previous posts that might be interesting if you also are wondering what agile means for you:

For me, practices are interesting, especially if I choose to experiment with them. What could I do to increase my throughput and learning, and therefore, my ability to adapt? Agile is not about specific practices. It is about a mindset of finishing small valuable chunks, feedback, and change.

Categories: Project Management

Podcast About Geographically Distributed Agile Teams

Lisette Sutherland posted a podcast we recorded about geographically distributed agile teams. See Organize Your Distributed Team over on the CollaborationSuperpowers site.

We covered how you can think about your geographically distributed agile team:

  • Why you want a distributed agile team (yes, there are some great reasons)
  • How you might organize your team.

Here are the articles I mentioned:

Managing Multicultural Projects with Complementary Practices

I wrote about the timezone bubble chart in Managing Timezones in Geographically Distributed Agile Teams

Here are three posts about Geographically Distributed Teams Have Choices for Lifecycles about options for how you might do agile with a geographically distributed agile team.

I even had a chance to rant about management. We had a blast, as you can tell. Hope you enjoy it.

Categories: Project Management

Small-World Networks Article Posted

I’m a new contributor to the TechBeacon site. I have an article up, called¬†Small-world networks: a lightweight alternative to SAFe for scaling agile.

 Scaling Collaboration Across the OrganizationYes, it’s based on Agile and Lean Program Management: Scaling Collaboration Across the Organization.

Hope you enjoy the article.

Categories: Project Management

Thu, 01/01/1970 - 01:00