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 47 min ago

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

Stuck in the Middle with Your Agile Transformation? Part 2

Tue, 02/16/2016 - 17:03

In Stuck in the Middle, Part 1, I discussed possible management problems with agile. Those aren’t the only stuck problems I see. Sometimes, I see team problems.

What if the teams are “almost agile”—they still have too many experts, their stories are too big, they don’t always deliver value on a regular basis? You know they could see the benefits of agile if they retrospected, or changed the way they work. Maybe they don’t quite know what to do.

I also tackled some of these concerns with blog posts:

Understanding the problems—and helping the team understand the problems—is your first step in helping to solve the problems.

I wrote some newsletters that might help:

I admit, it would be nice if we could tell people what to do. I have found that telling doesn’t work so well when we want people to be self-managing. (!!) What can you do?

  • Build your coaching skills so you can coach across the organization.
  • Build your influence skills so you can influence anywhere.
  • Understand the dynamics that prevent the teams from succeeding as well as they could.

We do all of these at the Influential Agile Leader. I invite you to join us this year, in Boston or London.

In Part 3, I’ll discuss the system of agile that makes being stuck in the middle uncomfortable.

Categories: Project Management

Stuck in the Middle with Your Agile Transformation? Part 3

Tue, 02/16/2016 - 16:44

In part 1, I addressed some management challenges with an agile transition. In part 2, I addressed some team issues.

In this part, I’ll discuss why agile is a culture change and ways to consider a system change to agile.


Agile looks something like this image.

The responsible person (often called a product owner) collects ideas and creates a ranked backlog for a cross-functional team. The team works on the backlog, releasing small chunks of value. At some point, the team demos to the product owner, retrospects and gets an updated backlog.

The system depends on these ideas:

  • The team finishes small chunks of valuable work so the team and the product owner can get feedback about the story size and work to date. This requires the team finish their work. (You know, the discussions about done.)
  • The team retrospects often enough to understand and fine-tune the team’s process.
  • The team, including the product owner, retrospect enough to understand if the stories are small enough for the team to finish stories, and to change what the team works on when. Retrospectives include the product and the process.

This is a cultural change in these dimensions:

  • From a culture of commitments through documents to a culture of commitments through working product
  • From a culture of individual work (resource efficiency) to a culture of teamwork (flow efficiency)
  • From a culture of management control (of the team) to team control of itself (self-management)

Culture change does not occur overnight.  Change is hard work.

If you are one of the people nurturing your agile change, I bet you feel stuck in the middle between other managers, the manager(s) and the team(s). I invite you to join us at the Influential Agile Leader (Boston Apr 6-7, and London May 4-5) this year.

Categories: Project Management

Thinking About Servant Leadership and Agile Project Management

Tue, 02/09/2016 - 14:57

For many people, agile means an end to all project management. I disagree. I find value in servant leadership in project management.

I explain how you can think about servant leadership and agile project management in my projectmanagement.com column this month: Servant Leadership: The Agile Way.

If you are looking to increase your servant leadership and help your project team (or program), check out the Influential Agile Leader.

Categories: Project Management

What Does Agile Mean to You?

Fri, 02/05/2016 - 16:37

Over on Techwell, my monthly column is Agile Does Not Equal Scrum: Know the Difference.

I wrote the article because I am tired of people saying “Agile/Scrum” as if Scrum was the only way to do agile.

I use iterations, kanban, and the XP technical practices when I work with teams. I am not religious about the “right” way to do agile. I like any combination of approaches that help a team deliver value often. I like anything that helps a team to get feedback on their work and their team process.

I like anything that helps management ask the right questions and create an environment in which teams can succeed.

Dogma doesn’t work very well for me. (I know, you are so surprised.)

If you are thinking about your agile approach, ask yourself, “What does agile mean to me? What value will agile deliver?”

Before you decide on an approach, answer that question. You might be more Dan in my most recent Pragmatic Manager, Define Your Agile Success. Once you know what agile means to you, you might start to read more about possibilities that fit for you.

If you are a leader in your organization trying to use agile more effectively, consider participating in the Influential Agile Leader.

Categories: Project Management

What Does Agile Mean to You?

Fri, 02/05/2016 - 16:37

Over on Techwell, my monthly column is Agile Does Not Equal Scrum: Know the Difference.

I wrote the article because I am tired of people saying “Agile/Scrum” as if Scrum was the only way to do agile.

I use iterations, kanban, and the XP technical practices when I work with teams. I am not religious about the “right” way to do agile. I like any combination of approaches that help a team deliver value often. I like anything that helps a team to get feedback on their work and their team process.

I like anything that helps management ask the right questions and create an environment in which teams can succeed.

Dogma doesn’t work very well for me. (I know, you are so surprised.)

If you are thinking about your agile approach, ask yourself, “What does agile mean to me? What value will agile deliver?”

Before you decide on an approach, answer that question. You might be more Dan in my most recent Pragmatic Manager, Define Your Agile Success. Once you know what agile means to you, you might start to read more about possibilities that fit for you.

If you are a leader in your organization trying to use agile more effectively, consider participating in the Influential Agile Leader.

Categories: Project Management

Value of Burndown and Burnup Charts

Tue, 02/02/2016 - 15:58

I met a team recently who was concerned about their velocity. They were always “too late” according to their manager.

I asked them what they measured and how. They measured the burndown for each iteration. They calculated the number of points they could claim for each story. Why? Because they didn’t always finish the stories they “committed” to for each iteration.


This is what their burndown chart looked like.

A burndown chart measures what you have finished. If you look at their burndown, you can see there are times when not much is done. Then, near the end of the iteration, they finish more. However, they don’t finish “everything” before they run out of time.

An iteration is a timebox, by definition. In this case, having to “declare victory” and assess what they were doing should have helped them. But, when this team saw the burndown, two interesting things happened. They beat themselves up for not finishing. And, when they didn’t finish everything, they didn’t always do a retrospective. In addition, the product owner often took the unfinished work and added it to the next iteration’s work. Yes, added, not replaced. That meant they never caught up.

BurndownwithideallineThey tried this burndown chart next, to see if they could meet their ideal.

They realized they were “late,” off the ideal line from Day 2. They felt worse about themselves.

They stopped doing retrospectives, which meant they had no idea why they were “late.”

A burndown emphasizes what you have completed. A burndown with the “ideal” line emphasizes what you have done and what you “should” be doing. I have used story points here. You could look at story points against time, looking at the available hours or people days or something like that.

For me, a burndown is interesting, but not actionable. Think about what happens when you take a trip. You plug your destination into your favorite GPS (or app), and it calculates how much longer it will take to get to your destination. You know you have driven some number of miles, but to be honest, that’s done. What’s interesting to you is what you have remaining. That’s what a burnup chart helps you see.

For me, a burnup is a way to see what we have accomplished and what’s remaining. I can learn more from a burnup than I can from a burndown. That’s me. Here’s a burnup of the same data:

I made these charts from exactly the same data. Yet, I have a different feeling when I see the burnups.

When I see the Story points Done without the ideal line, I see a hockey stick. It’s not as bad a stick as the image in Is the Cost of Continuous Integration Worth the Value on Your Program?, Part 1, and it’s still a significant hockey stick.


When I see this burnup, I can tell by Day 3 that we are “behind” from where we want to be. By Day 5, I know we cannot “make up” the time. As any team member, I can raise this as an impediment in the daily standup. If I am a leader of any sort, I will put this on my list to discuss in the retrospective, if not problem-solve before.

Maybe that’s just the way my mind works. I like seeing where we are headed and what it will take to get there. I’m interested in what we’ve done, but that’s in the past. I can’t address the past except to retrospect. I can address the future and say, “Is there something we can do now to help us accomplish what we thought we could in this timebox?”

George Dinwiddie has a great article on burndown charts: Feel the Burn: Getting the Most out of Burndown Charts.

Oh, and the team I discussed earlier? They decided they were trying to cram too much into an iteration. They made their stories smaller. That put more pressure on their product owner, but then they realized lack of PO time was an impediment. They thought they were to blame with a burndown. They saw their data more easily with a burnup. Maybe we all had a mind-meld going on.

It doesn’t matter which chart you generate. It matters how the chart makes you feel: what action will you take from  your chart? If it’s not prompting you to act early, maybe you need a different chart. One project truism is: You cannot “make up” time. You can choose actions based on what your data tells you. Can you hear your data?

Categories: Project Management

Influential Agile Leader, Boston and London, 2016

Thu, 01/28/2016 - 17:50

Is your agile transition proceeding well? Or, is it stuck in places—maybe the teams aren’t improving, maybe the people are multitasking, maybe you are tired and don’t know how you’ll find the energy to continue.

You are the kind of person who would benefit from the Influential Agile Leader event in Boston, April 6-7, and in London, May 4-5, 2016.

Gil Broza and I co-facilitate. It’s experiential, so you learn by doing. You practice your coaching and influence in the mornings. You’ll have a chance to map your organizational dynamics to see where to put your energy. You’ll split into smaller sessions in the afternoon, focusing on your business challenges.

If you would like to bring your agile transition to the next level, or, at the very least, unstick it, please join us.

Super early bird registration ends January 31 for London. Our super early bird for Boston is sold out, and the early bird registration is still a steal.

If you have questions, please post a comment or email me. Hope to work with you there.

(See the servant leadership tag for the Pragmatic Manager  and the leadership tag on this blog to see relevant articles I’ve written before.)

Categories: Project Management

Four Tips for Pair Writing

Wed, 01/27/2016 - 16:25

I am shepherding an experience report for XP 2016. A shepherd is sort-of like a technical editor. I help the writer(s) tell their story in the best possible way. I enjoy it and I learn from working with the authors to tell their stories.

The writers for this experience report want to pair-write. They have four co-authors. I offered them suggestions you might find useful:

Tip 1: Use question-driven writing

When you think about the questions you want to answer, you have several approaches to whatever you write. An experience report has this structure: what the initial state was and the pain there; what you did (the story of your work, the experience); and the end state, where you are now. You can play with that a little, but the whole point of an experience report is to document your experience. It is a story.

If you are not writing an experience report, organize your writing into the beginning, middle, end. If it’s a tips piece, each tip has a beginning, middle, end. It depends on how long the piece is.

When you use question-driven writing, you ask yourself, “What do people need to know in this section?” If you have a section about the software interacting with the hardware, you can ask the “What do people need to know” and “How can I show the interactions with bogging down in too much detail” questions. You might have other questions. I find those two questions useful.

Tip 2: Pair-write

I do this in several ways with my coauthors. We often discuss for a few minutes what we want to say in the article. If you have a longer article, maybe you discuss what you want to discuss in this section.

One person takes the keyboard (the driver). The other person watches the words form on the page (the navigator). When I pair-write with google docs, I offer to fix the spelling of the other person.

I don’t know about you, but my spelling does not work when I know someone is watching my words. It just doesn’t. When I pair, I don’t want the writer to back up. I don’t want to back the cursor up and I don’t want the other person to back up. I want to go. Zoom, zoom, zoom. That means I offer to fix the spelling, so the other person does not have to.

This doesn’t work all the time. I’m okay with the other person declining my offer, as long as they don’t go backwards. I become an evil witch when I have to watch someone use the delete/backspace key. Witch!

Tip 3: Consider mobbing/swarming on the work

If you write with up to four people (I have not written with more than four people), you might consider mobbing. One person has the keyboard, the other three make suggestions. I have done this just a few times and the mobbing made me crazy. We did not have good acceptance criteria, so each person had their own idea of what to do. Not a recipe for success. (That’s why I like question-driven writing.)

On the other hand, I have found that when we make a list of sections—maybe not a total outline—pairs of people can work on their writing at the same time. Each pair takes a section, works on that, and returns to the team with the section ready for review. I have also been in a position where someone did some research and returned to the writing team.

I have also been in a position where someone did some research and returned to the writing team.

Tip 4: Use a Short Timebox for Writing

When I pair, I write or navigate in no more than 15-minute timeboxes. You might like an even shorter timebox. With most of my coauthors, I don’t turn on a timer. I write for one-to-several paragraphs and then we switch. We have a little discussion and then we’re writing again. Most of my timeboxes are 5-7 minutes and then we switch.

Pair Writing Traps

I have seen these traps when pair-writing:

  1. One person dictates to the other person. That smacks of first-author, all-the-rest-of-you-are-peons approach.
  2. One or both of you talk without writing. No. If someone isn’t writing in the first 90 seconds, you’re talking, not writing. Write. (This is the same problem as discussing the design without writing code to check your assumptions about the design.)

I didn’t realize I would make this a series. The post about writing by yourself is Four Tips to Writing Better and Faster.

I have a special registration for my writing workshop for pairs. If you are part of a pair, take a look and see if this would work for you.

Categories: Project Management

Four Tips to Writing Better and Faster

Tue, 01/19/2016 - 14:52

A colleague asked me for some tips about writing. With hundreds of articles, blog posts, and 10 books, I know what works for me. I suspect some of these ideas will work for you, too.

Tip 1:  Write every day.

Write for 15 minutes every day. This practice exercises your writing muscles. For me, it’s a little different than all the email I write :-)

Tip 2: Think about the stories you want to tell in an article.

People love stories. If you include a story, they will identify with it and love your work. That’s because they can identify with the situation, regardless if they agree with you.

You might not like my story approach. Think about what you like to read. What pulls you in? Write like that (not the same words, the same approach).

Tip 3: Writing is not editing.

For me, writing is about 3 parts:

  • Gather the ideas. If you want to outline, this is a great time to do it. Just remember that an outline is a guide, not rules.
  • Write down. 
  • Edit. This is where you use the red squiggly lines and the spell/grammar checker. I excise passive voice in my non-fiction. I look for a lower grade level (about 6 is what I aim for) and a high readability score. 

When I write (down), I don’t edit. I spew words on the page. It’s almost a game: how fast can I write? I write about 750-1000 words an hour. That’s pretty darn close to an entire article. (1000 words) After I’m done with the writing-down, I can edit. 

Tip 4: People will disagree with you

When you write non-fiction, people will disagree with you. (Heck, they probably disagree with fiction, too!) That’s fine. It’s their loss if they disregard your ideas. Everyone has their own experience. If you tell stories/provide tips/write from your experience, you are authentic. You also build your self-confidence. The writing is easier over time.

If you would like to practice your writing, I have an online workshop starting in March. See http://www.jrothman.com/syllabus/2015/12/writing-workshop-1-write-non-fiction-to-enhance-your-business-and-reputation/. You will write at least one article during the workshop. 

Categories: Project Management