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/sources/19' 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!

Managing Product Development - Johanna Rothman
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.
Syndicate content
Expert in Managing Product Development
Updated: 1 hour 53 min ago

When is Agile Wrong for You?

Tue, 05/24/2016 - 15:04

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?

Tue, 05/24/2016 - 15:04

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

Discovery Projects Work for Agile Contracts

Fri, 05/20/2016 - 16:50

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

Thu, 05/19/2016 - 14:44

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

Thu, 05/19/2016 - 14:32

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

Wed, 05/18/2016 - 14:47

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

Mon, 05/16/2016 - 16:56

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

Thu, 05/12/2016 - 13:48

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

Wed, 05/04/2016 - 15:49

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

Thu, 04/28/2016 - 15:56

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

Mon, 04/25/2016 - 15:14

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

Agile and Lean Program Management is Done

Wed, 03/30/2016 - 12:50

I sent my newsletter, Scaling Agile and Lean to Programs to my subscribers yesterday. (Are you one of them? No? You should be!)

If you are trying to use agile for several projects that together deliver value (a program), you might be wondering what the “right” approach is. You’ve heard of frameworks. Some of them seem to be a bit heavy.

Instead of a framework, consider your context. You and your organization are unique. Do you have hardware to integrate into your product? Do you have agile and non-agile teams who are supposed to deliver? Are you trying to work in iterations and they don’t quite work at the problem-solving level?

 Scaling Collaboration Across the OrganizationYou have many choices. In Agile and Lean Program Management: Scaling Collaboration Across the Organization, I offer you options for how to think about and solve these and many other problems. The book is principle-based, not practice-based. That way, if you consider the principles, you’ll be in great shape, regardless of what you decide to do.

Please do check out the book. It’s available everywhere fine books are sold. (I love saying that even if it is passive voice!)

Categories: Project Management

Influential Agile Leader on Projects at Work

Fri, 03/18/2016 - 22:09

I spoke with Dave Prior on a podcast for Projects at Work. The podcast is titled “Influential Agile Leader.” We spoke about how leaders need to practice coaching and influence, and how to use experiential approaches to helping people learn how.

You can learn with Gil Broza and me at the Influential Agile Leader. We are leading sessions in Boston April 6-7 and in London May 4-5. We will close registration March 24, so register now.

Categories: Project Management

How Agile Changes Testing, Part 4

Tue, 03/08/2016 - 16:07

In Part 1, I discussed the agile project system. In Part 2, I discussed the tester’s job in agile. In Part 3, I discussed expectations about documentation (which is what the original question was on Twitter). In this part, I’ll talk about how you “measure” testers.

I see a ton of strange measurement when it comes to measuring the value of testers. I’ve seen these measurements:

  • How many bugs did a single tester report?
  • How many times did a tester say, “This isn’t any good. I’m sending it back.”
  • How many test cases did a tester develop?

All of these measures are harmful. They are also surrogate measures.

The first rule of measurement is:

Measure what you want to see.

Anything other than what you want to see is a surrogate measurement.

Do you want to see many bug reports? (Notice I did not say defects. I said bug reports.) If you measure the number of bug reports, you will get that. You might not get working software, but you’ll get bug reports. (Rant on: Bug reports might not report unique problems, defects, in the product. Rant off)

Do you want testers to pass judgment on the code? Ask how many times they threw something back “over the wall” or rejected the product (or the build).

Do you want to measure test cases? You’ll get a large number. You might have terrible code coverage or even scenario coverage, but you’ll get test cases.

In waterfall or phase-gate, you might have measured those surrogate measures, because you could not see working product until very late in the project.

In agile, we want to see running tested features, working product. Why not measure that?

Running tested features provide us a possibility of other measures:

  • Cycle time: how long it takes for a feature to get through the team.
  • Velocity: how many features we can finish over a time period.
  • If we look at a kanban board, we can see the flow through the team. That allows us to see where we have blockers for the team. What’s queued for test?
  • When can we see working software? If we only have running tested features every week or so, we can see new working software only that often. Is that often enough?
  • What is the team happiness? Is the team working together, making progress together?

You “measure” the team, looking for throughput. If the team doesn’t have throughput, do some root cause analysis and impediment removal. That’s because we have a team approach to product development. (See Part 1.)

Back in the 80’s and early 90’s, we learned we had a software “crisis.” Our systems got more complex. We, as developers, could not test what we created. The testing industry was born.

Some people thought testing software was like testing manufacturing. In manufacturing, you duplicate (I apologize to manufacturing people, this is a simplification) the same widget every time. ¬†It’s possible in manufacturing to separate the widget design and prototyping from widget manufacturing. ¬†The SEI and the CMM/CMMI¬†used the metaphors of manufacturing when they described software development. We emphasized process before (remember structured design and CASE tools?), but now—wow—process was everything.

Software product development is nothing like manufacturing. It’s a lot more like the design and engineering of the widget, where we learn. We learn as we develop and test code.

That’s the point of agile. We can incorporate learning, to improve and better the product as we proceed.

If you measure people as if they are widgets, they will behave like widgets. If you measure people as individuals, they may well behave as individuals, maximizing their own returns.

When a team uses agile, they create working product. Look for and measure that. When a team uses agile, they work as a team. Reward them as a team.

Categories: Project Management

How Agile Changes Testing, Part 3

Tue, 03/08/2016 - 15:41

In Part 1, I discussed how an agile approach changes testing. In Part 2, I discussed how the testers’ job changes. In this part, I’ll talk about expectations.

Since the developers and testers partner in agile, the testers describe their approach to testing as they work with developers on the code. (This is the same way as the developers describe their approach to development.) You might not need any test planning documents. At all.

If you have acceptance criteria on stories, the developers know what unit tests to write. The testers know what kind of system tests to write. All from acceptance criteria. You don’t need test case definition—the acceptance criteria define what the tests need to do.

What if your customer wants test documents? Show them working software.

What if your customer wants to see traceability? (If you are in a regulated environment, you might have this requirement.) Show them how the user stories encapsulate the unit tests and system tests.

What if your customer wants to know you are testing what the developers write? Well, I want to know the answer to this question: What else would you test?

If the developers have moved onto a new feature and you are not done, you need a kanban board to show the workflow. Your team might have too much work in progress queued for the testers. I see this in teams with six developers and one lonely tester. (That lonely tester is often time-space removed from the developers.)

Separating developers from testers and having developers run fast on coding provides the illusion of progress. In fact, in agile, you want to measure throughput, not what any given person has completed. (See my posts on resource vs. flow efficiency.)

Maybe you found a bunch of problems in a feature the developers thought was already done. If so, the developers should stop working on anything new, and work with you to fix this feature. If they don’t, they will context-switch and make more mistakes. Review your team’s definition of done.

If there is some other circumstance you encounter, let me know in the comments and I’ll update the post.

Remember, in agile, developers and testers work together to create finished features. Go back to Part 1 and look at the agile picture. You might need writers, DBAs, UX people, whatever. The team works together.

If you look for surrogate measures, such as test designs or test cases written, you will get surrogate measures. You will not get working software. That’s because people deliver the surrogate measures, not working software.

If you want working software, ask for working software. The team’s responsibility is to provide working software. What else would a customer need to see and why?

The closer the developers and testers work together, the faster the feedback to each other. The faster the customer can see working product. Isn’t that what we want?

In part 4, I’ll discuss¬†how measurements about testers change.

Categories: Project Management

How Agile Changes Testing, Part 1

Tue, 03/08/2016 - 15:27

Last week, I attempted to have a Twitter conversation about agile and testing. I became frustrated because I need more than 140 characters to explain.

general-agile-picture-copyright-1024x645This is my general agile picture. For those of you can’t see what I’m thinking, the idea is that a responsible person (often called a Product Owner) gathers the requirements for the project. The cross-functional product development team works on some of those features (which I like as small stories), and outputs small chunks of working product that have value to the customer. You might or might not have a customer with you. The Product Owner either is the customer or takes the customer role.

After some number of features complete, the team demonstrates the features and retrospects on the project and the team’s process. They get more features from the PO.

Now, let’s contrast agile with more traditional planning and testing.

If you used a phase-gate or a waterfall life cycle, you were accustomed to planning the entire project—including system test plans—at the beginning. You predicted what you needed to do.

If you were a tester, you often discovered that what you planned at the beginning was not what you needed by the time it was time for you to test. You might have been interrupted by the need to test current projects, with the promise you would return to this one. Testers were often at the end and possibly delayed by not-quite-finished work in flight.

If you could work on this project, you wrote a system test plan. In addition, you might have written system test specifications, designed test cases, and maybe even documented test cases. Why? So you wouldn’t forget what to do. And, your customer (management, maybe a real customer) would want to know what you had been doing all along and what they could expect. You planned for the future.

In agile, we don’t do a ton of upfront planning. I like to plan for no more than a couple of days, including generating the initial backlog for a cross-functional team to work on. Yes, two days. More planning might easily be waste. What might you do in those two days?

  • Write a project charter as a team, which includes the project vision and release criteria.
  • Generate a story map or product backlog for the first release’s worth of stories. (If you read my roadmap posts, you know I like internal releases at least as often as every month. I prefer releasing every day. I’ll take visual working software at least once a month.)
  • If you are a new team, ¬†you might develop working agreements and a definition of done.

Do you need a system test plan? Maybe. I often discover that when we discuss the project charter, we might say something like, “We want to focus our testing in these areas,” or “These are the areas of high risk that we can see now.” My system test plan is still only one page. (See the Manage It templates for all my templates of what you might need in a project, including the system test plan.)

Now, you start the project. What happened to all that test planning and test plans and test cases? They go with the stories—if you need that level of planning. See Part 2.

Categories: Project Management

How Agile Changes Testing, Part 2

Mon, 03/07/2016 - 19:00

In Part 1, I discussed the project system of agile. In this part, I’ll discuss the need for testing documentation.

In a waterfall or phase-gate life cycle, we needed documentation because we might have had test developers and test executors. In addition, we might have had a long time separating the planning from the testing. We needed test documentation to remember what the heck we were supposed to do.

In agile, we have just-in-time requirements. We implement—and test—those requirements soon after we write them. When I say “soon,” I mean “explain the requirements just before you start the feature” in kanban or “explain the requirements just before you start an iteration” if you timebox your feature development. That’s anywhere from hours to a few days before you start the feature. We have a cross-functional team who work together.They provide feedback in the moment about the features in development and test. The most adaptable teams are able to work together to move a feature across the board.

In waterfall or phase-gate, we might have had to show the test documentation to a customer (of some sort). In agile, we have working software (deliverables). What you see and measure changes in agile.

In waterfall or phase-gate, people often defined requirements as functional and non-functional. I bet you have read, “The system shall” until you fell asleep. In agile, we often use user stories—or something that looks like it—to define requirement via persona, or a specific user. We know who we are implementing this feature for, why they want it and the value they expect to receive from the feature.

You’ve noticed I keep saying, “implementing” in these posts. That’s because for me, and for many agile teams, implementing means writing code-and-tests that might ship and code-and-tests that stay. The developers write the code and tests that ship. The testers write code and tests that stay.

The developers and testers are part of a product development team. They may well be attached to their roles. ¬†For example, when I am a dev, I don’t test my work nearly as well as I test other people’s work. Not all devs want to write system tests. Not all testers want to write product code. That’s okay. People can contribute in many ways.

The key is that developers and testers work together to create features. They need each other. What does that mean for test planning?

  • You might need something about the test strategy in the project charter. I often recommend that the team think about scenarios they want to test every day as they build.
  • You might need guidance for the testers: “We use this pre-configured database for this kind of testing.” Or, “We test performance once a day with pre-specified scenarios,” or whatever you need as team norms.
  • You do not need to separate the test planning from the testing. You might decide to automate tests you will use over and over. You might decide to explore/use manual testing for infrequent tests. This is a huge discussion that I will not delve into in this series. Make a conscious decision about automation and exploration.

I have yet to see a humongous document of test cases be useful in a waterfall team. That’s because we learn as we develop the software. The document is outdated as soon as the requirements change even a little. If you need to document (for traceability) test cases, it’s easy to document as you write and test features.

This changes the testers’ job. Testers partner with developers. They test, regardless of whether the code exists. They can write automated tests (in code or in pseudo-English) in advance of having code to test. They provide feedback to developers as soon as the test passes or fails.

When I was a tester, I checked in my code and told the developers where it was so they could run my code. I then explored the product and found nasty hairy defects. That was my job. It wasn’t my job to withhold information from the developers.

The testers’ job changes from judging the quality of the product to providing information about the product. I think of it as a little game: how fast can I provide useful feedback when I test?

This game means that as a tester, I will automate test cases I need to run more than once. I will automate anything that bores me (text input, for example). I will work with developers so they create hooks into the code for me to make my test automation easier. I have this conversation when we discuss the requirements.

Just as the stories and the code describe the stories, my tests describe my test cases.

In agile, we use deliverables—especially in the form of running tested features—to see progress throughout the project. Test cases lose their value as a deliverable.

In part 3, I’ll talk about what customers or managers need to see and when.

Categories: Project Management

Waving the Agile Flag?

Thu, 03/03/2016 - 15:21

I spoke with a potential client last week. She said, “I’m waving the agile flag. But no one cares.”

I wrote a Pragmatic Manager to sort through what I wanted to say to her. Read it at Feeling Alone on Your Agile Journey.

If you feel stuck in the middle, or you’re alone, or you don’t know what to do to help your agile transition succeed, join Gil Broza and me at the Influential Agile Leader in Boston (April 6-7) and London (May 4-5).

You don’t have to feel alone. You don’t have to be stuck in the middle. You have options.

Categories: Project Management

When You Need All the Requirements

Mon, 02/29/2016 - 17:44

A number of my clients are attempting to use agile as they transition from a strict waterfall to a more adaptive approach to their projects.

One problem the change artists have is this: The managers, product managers, and maybe even the customers want to define all the requirements up front. I have not found the requirements definition of all the requirements possible in any life cycle. (I wrote about this in Manage It! and what to do for different life cycles.)

What can you do?

  • Ask for the deliverables people want to see at different times. Now that you know what people want to see, build a roadmap.
  • Timebox the requirements generation. I like to¬†workshop¬†the requirements in a one- or two-day timebox for agile projects.
  • Ask why people want to see all the requirements. What is their reasoning for wanting to see everything before you start?

Example.AgileRoadmapOneQuarterThis image shows what a roadmap might look like. The roadmap has deliverables in the form of an internal release each month. I like deliverables more often, and I’ll take a one-month deliverable, especially for a program. You don’t have to work in iterations, although that makes it easier for me to show you what the deliverables might look like.

I assume that in kanban, you deliver features every day or so.

Beware of these problems:

  • People in your organization do not realize they have more options than Scrum. I wrote a column about that here: Agile Does Not Equal Scrum: Know the Difference.¬†The point in using an agile approach is that you have options for what to deliver when, by making your project more adaptable.
  • People think agile is about faster. They don’t realize you get faster and better by creating an environment in which agile allows people to learn early, which might change what people work on when.
  • Agile is a cultural change. People need time to think and practice when they change culture.

 

In all of my experience, the only projects I know that don’t have requirements changes are those projects that require two or three people and take less than a month, such as patches or fixes. All the other projects—even the ones that seem straightforward—have some sort of requirements changes.

One good reason to use agile is to adapt to those changes. If you need all the requirements up front, maybe you don’t need agile? Or, maybe you need to help your colleagues think in a more agile way. Join us at the Influential Agile Leader, if this is one of your challenges.

Categories: Project Management

Stuck in the Middle with Your Agile Transformation? Part 1

Tue, 02/16/2016 - 17:10

Here’s something I see in many organizations: Management wants to “control and manage” the projects/efforts/work (whatever they call it) in the same way they did before the organization started agile. They want Gantt charts. They want commitments. They want assurances that the work will proceed in the same way they thought of it before the project started.

In the meantime, the project teams revel in the adaptability of being able to re-rank the backlog and show value. They progress on the work the Product Owner wants, in the order the PO wants it.

If you are a manager, project manager, or a change artist in your organization, I bet you are dismayed. Management is not nurturing an environment in which agile can thrive—and more important—the managers don’t receive the value of agile.

You are stuck in the middle.

Agile (and lean) help us to deliver constant streams of value. Once we deliver, we can change what we work on next. If you have small stories, you can deliver and change every day. I don’t recommend changing every day—I prefer a slightly longer perspective. But you could. I wrote about this in a Pragmatic Manager last year, called¬†Commitments or Resilience.

You have a problem. What is it, and how can you solve it? You might need some data:

  • What problems does your management have?
  • How will agile help solve those problems?
  • What does agile success look like for your management?

These questions are part of getting ready to coach and influence your management. When you ask these questions, you learn what is in it for the managers (WIIFM in influence terms), and what you might need to measure to help everyone understand how agile can help. If you feel stuck in the middle, join Gil Broza and me when we address these issues in the Influential Agile Leader in Boston and London this year.

Sometimes, it’s not just management who is a little stuck in the agile transition. Sometimes, it’s the team(s), too. I’ll address the team concerns in Part 2.

Categories: Project Management