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: 2 hours 26 min ago

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.

Burndown.StoryPoints

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:
StoryPointBurnup

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.

StoryPointBurnupwithIdealLine

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

Public Workshops in 2016

Tue, 01/12/2016 - 17:10

I have several public workshops this year.

I’m offering the Influential Agile Leader with Gil Broza April 6-7, 2016 in Boston and May 4-5, 2016 London. If you have not read some of my writing about leadership, take a look at these previous newsletters:

â–Ş Lead Your Agile Transition Through Influence
â–Ş Creating an Environment of Leadership
â–Ş Discovering Your Leadership

Early bird registration for Influential Agile Leader ends Feb 29, 2016.

In addition, I am offering these online workshops in March:
* Practical Product Ownership
* Writing Non-Fiction Workshop 1

Super early bird registration ends January 15, 2016.

I hope you decide to join me and we can learn together.

Categories: Project Management

Architects as Servant Leaders

Mon, 01/04/2016 - 17:06

As more teams and organizations transition to agile, they discover something important about leadership. Leadership is part of everything we do in an agile project. It doesn’t matter if it’s development or testing, management or architecture. We need people with high initiative and leadership capabilities.

That leads me to these questions:

  • We need project management. Do we need project managers?
  • We need management. Do we need managers?
  • We need architecture. Do we need architects?

As with all interesting questions, often the answers are, “It depends.” What do those people do? How do they do it?

In December, I gave a talk, “Agile Architect as Servant Leader” for IASA. That talk outlines some of the ways agile architects might work as servant leaders. See the slides: Agile Architect as Servant Leader.

 Scaling Collaboration Across the OrganizationThere is more about servant leadership in Agile and Lean Program Management, for program managers, program product owners, and architects.

Here is the link to the recording: Agile Architect as Servant Leader.

Categories: Project Management

Want to Write Non-Fiction Better?

Wed, 12/30/2015 - 17:44

If you write as part of your job, I have a new online workshop starting in March. It’s Writing Workshop 1: Write Non-Fiction to Enhance Your Business and Reputation.

Here’s the problem I see. You’re a consultant or other entrepreneur. You know you need to write to enhance or build your reputation. You see a blank page (paper or screen), and you have no idea what to write. Maybe you can start, but you get 23 words in and get stuck. Maybe you get 5,000 words in, and you know there’s good work in there, but you can’t see it.

If you would like to address these challenges (and more), and deliver non-fiction articles, blog posts or newsletters to your readers, this workshop is for you.

You’ll learn:

  • How to make writing a habit.
  • How to structure an article that people want to read.
  • Write articles or blog posts or whatever that engage your ideal reader and build your reputation.
  • What writing is. What editing is. How they are different.
  • How to decide when to place your writing where.

You will write during this workshop. We will focus on short non-fiction, such as blog posts and articles.

I am the only person who will read your writing. I have published over 500 articles and well over 1500 blog posts. I write two columns each month and two quarterly columns each year. (If you have ever been part of a critique group, you know sometimes they savage you with feedback. I won’t do that.) I am a professional technical editor, as well as a writer.

I am focusing this workshop for people who know that writing will enhance their professional prospects, who have trouble publishing finished work. You will learn many ways to structure your work and publish. If you do the homework, you can expect that you will finish at least one article, as part of this workshop.

Want to join us? See Writing Workshop 1: Write Non-Fiction to Enhance Your Business and Reputation for full details and signup.

Categories: Project Management

Taking Requests for New Edition of Manage Your Project Portfolio

Tue, 12/22/2015 - 16:37

Manage Your Project PortfolioI am about to update Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects to a second edition.

What would you like me to add? To remove? To change? What have your challenges been about project portfolio management?

Here are things I’m planning to add:

  • Many more kanban views of the project portfolio and some words about visualization.
  • Discussion (or more than one) about Cost of Delay.
  • How a project’s product backlog is not the same as an organization’s project portfolio.
  • More discussion about what you optimize and why.

What else would you like to see? Please either comment or send me email. Thanks!

Categories: Project Management

Helping Hardware Be Agile, Part 3

Tue, 12/15/2015 - 18:34

The big problem with hardware going agile is that the risks in hardware are not homogeneous. Hardware and mechanical engineering are on different cycles from each other, and they are each different from software. Even with each discipline, the risks are different when the teams collaborate together on one deliverable and when the entire program has to collaborate to create a product.

The engineering teams simulate to see problems in their own work and solve those problems. Each team is ready for integration at a different time. They can’t integrate until they go to fabrication. That changes the feedback cycle(s) for the entire program.

Questions you can ask are:

  • Is there an interim physical form that would provide us value?
  • How much does that form cost us to create?
  • How long is it that prototype good for?
  • If there is not an interim physical form that would provide us value, how can we obtain value and reduce risks with what kind of form or demonstration?

Here are some sample problems you could test for and avoid with early prototypes:

  • The footprint is too large/too small.
  • The design by contract work you thought was good turns out to be wrong.
  • You have a design that works but doesn’t produce the product you want.

You may have other problems.

Because the hardware parts run on different cycles than the software parts, we have at least two ways to manage these risks: set-based design and landing zones.

In set-based design, the designers iterate on the design, they rule in or out designs that do not intersect with the rest of the design components. In landing zones, the designers discuss the parameters of what makes a successful design and then converge on that success.

Either of these looks much more like “implement several features and see what architecture emerges, rather than design up front.” It’s also about using the intelligence of an entire team.

There’s a third option: is there a cost-effective way to make a prototype that can provide you feedback without having all the properties? For example, can you use a 3D printer to check the physical footprint, even if you can’t check heat dissipation? I don’t know if that would work for your program or would be a waste of time. I do know that 3D printing is much faster than going to fab for many parts of your product.

I used a fourth option some years ago. We wanted to simulate the traffic on an internal network to see if the design we had would work. I asked about 20 people to meet the architect and me (I was the program manager) in a large conference room. We organized the people according to the types of traffic. We had a metronome to help people walk on time. We simulated the network traffic—what was going where and when—with people. It wasn’t a perfect test, and it told the architect a ton of information about how the software would work with the current hardware. I’m not sure we would do that now—we did not have adequate simulators back then. At the time, it was a cheap and useful approach to help the architect realize that the hardware would not integrate with the software as he desired.

These methods are not infallible. However, they both provide feedback faster and better than waiting until the end of the project/program, when you have spent all the money and time—and you still don’t have hardware that works.

Hardware can be agile. In Helping Hardware Be More Agile, Part 1, the product owner defines when she wants to see what with a roadmap. That helps the team determine their interdependencies and make the interdependencies visible. In Helping Hardware Be More Agile, Part 2,  I showed potential kanbans and how the teams might use them. In this post, I suggested you might gain value from early integration and ways you might do that.

 Scaling Collaboration Across the OrganizationI have more discussion in Agile and Lean Program Management. I started the hardware chapter in the beta that is available now, and expect to complete it “shortly.”

Categories: Project Management

Helping Hardware Be Agile, Part 2

Thu, 12/10/2015 - 13:41

Once you have a roadmap/product backlog for hardware, the teams need to know what to do and when. As a program manager, program product owner, or other interested party, you might want to know where the work is. The roadmap shows the big picture. The demos and team-based backlogs show the details and interdependencies

One way to see the work is to ask the engineers to use a kanban board. I recommend each component have its own kanban to see the work in progress.

Here are possible kanbans for mechanical, silicon, and FPGA teams:

Possible Mechanical Engineering Kanban

Possible Mechanical Engineering Kanban

Possible Silicon Kanban

Possible Silicon Kanban

Possible FPGA Kanban

Possible FPGA Kanban

The FPGA kanban might look much more like a regular software kanban, up until you make the decision to go to physical form.

These are possible kanbans, not the way your organization might work.

These kanbans help everyone see where the work is. The roadmap in Helping Hardware Be Agile, Part 1 shows when the Program Product Owner would like the demos to be. The teams use those deliverables to decide when to integrate and test.

The more integration points your program has, the easier it is to see the entire product, not just one component.

The issue with integration points is that going to physical form can be expensive (in money and time). What is the relative value of staying in simulation mode vs. creating a prototype that people can touch and use? There is no One Right Answer. Part of it depends on the cadence of each team and the team’s risks. I’ll address hardware risks in the next installment.

Categories: Project Management

Helping Hardware Be Agile, Part 1

Fri, 12/04/2015 - 16:59

I’m writing like mad, trying to finish the program management book. I’m working on the “Integrating Hardware” chapter.

The problem is that hardware comes in several varieties:

  • Mechanical engineering
  • Silicon (part of electrical engineering)
  • FPGA (which looks like software to me)

Each component (yes, I do call these components) has a different value at different times in the product development. The program needs all of them by the end. But how do you see the product evolve? Is it even possible?

Well, yes it is possible to see a product with hardware evolve. The problem is that hardware is expensive to transition to physical form. Every time you go to physical form, you incur NRE (Non-Recurring Engineering) Expenses. If you have to fabricate a chip or board, that’s expensive. In my experience, my organizations want to fab no more than three times(prototype, pilot, real product). And, all near the end of the program.

AgileRoadmapOneQuarterHardwareThe first problem is ranking the features and organizing a product roadmap. In the book, I have a possible product, a robot arm. (None of my clients are developing robot arms, so I’m safe.) Here is the roadmap I created.

Notice that each monthly deliverable is a demo. For each of the first two months, the deliverable is component demos. The software team (OS) could show their completed software to date. The mechanical, silicon and FPGA teams would show their simulations. The simulations are separate for each component. For the third month, there is a potential joint simulation and a demo of the first prototypes.

The goal is to show every team’s work to every other team. For a complex product with hardware, the teams need to see what each other is doing, earlier rather than later.

You can try to do design by contract. It’s a great idea. My experience is it doesn’t matter what’s in the contract. The hardware is always a little different because the hardware people (mechanical and silicon) have to make tradeoffs be able to make the hardware fit the performance, footprint, or manufacturing capabilities. The earlier you can demo to each other on the program, the earlier you can see the changes.

This roadmap shows the teams what the program values first. It outlines the interdependencies. Yes, you need a product owner who either understands the interdependencies, or you need teams who can teach the product owner.

In my next post, I’ll talk about how to see the work each team does. The roadmap is insufficient for the details. The roadmap explains the big picture, and what you want to have happen. What the teams do is reality.

If you have an agile program with hardware, please comment on this post. I would love to know if this is helpful, what you do, and if you do something different what it is. Thanks.

Categories: Project Management

How Long Are Your Iterations? Part 2

Wed, 11/25/2015 - 21:39

implementbyfeature1-400x250When I teach agile, I explain I like small and short stories. I want to see value in the product every day.

Many developers can’t do that. That’s because they have interdependencies with other teams—not developers on their team, but other teams.

They can’t implement in the way the picture next to this shows: small, coherent slices through the architecture.

Instead, they implement in curlicues.


implementbycurlicue
When you implement by curlicues, you often have to wait for other teams. You might have component teams. You might have performance teams. But you can’t implement in nice “straight” features. Your features are complex and don’t take a straight line through the architecture.

When I work with people who have curlicues instead of straight lines through the architecture, I often discover that the different teams can complete parts of features in one iteration. (It doesn’t matter how long the iteration is.) But completing an entire feature? Because that takes the efforts of several teams, the team members believe they have interdependencies and the full feature often takes longer than one iteration.

The teams are correct. They have interdependencies. Sometimes, those interdependencies are quite difficult to see when you start. You only know that they exist when you get stuck partway in the feature.

Implementing by curlicue creates delays. The iteration is not the two weeks, three weeks, four weeks. No, the iteration can be as long as eight, nine, or ten weeks. That’s because each piece of the curlicue has to get to the top of each team’s backlog. The teams might have different product owners who don’t realize each arc of the curlicue is actually related to each other, that you need all of them to become one finished story.

In the meantime, each team has work in progress (WIP) and might not realize it. Or they do realize it, but they can’t get “credit” for their work.

What can you do if you are in this pickle?

  1. Consider asking the component teams to self-organize into feature teams.
  2. Ask the teams and product owners to collaborate on backlog ranking for each team according to total feature. This will allow the teams to work together, as if they are in a program.
  3. Ask one team to do the entire feature. Stop asking component teams to specialize in one component. That would allow the teams to see what the smallest value is, and implement that. (Repeat until you get the entire feature.)
  4. Make the stories smaller to see the value build. When I see this, I often see very large stories. Too often, the teams work across the architecture, doing platform work, database work, GUI work, rather than see the simplest possible feature that would allow everyone to see the value.

I bet you have other alternatives you might consider. If you see other alternatives, please comment. I would like to help more teams see how to manage their interdependencies or remove them altogether.

Categories: Project Management

How Long Are Your Iterations? Part 1

Thu, 11/19/2015 - 16:08

I spoke with a Scrum Master the other day. He was concerned that the team didn’t finish their work in one 2-week iteration. He was thinking of making the iterations three weeks.

I asked what happened in each iteration. Who wrote the stories and when, when did the developers finish what, and when did the testers finish what? Who (automated tests, testers or customers) reported defects post-iteration?

He is the Scrum Master for three teams, each of whom has a different problem. (The fact that he SMs for more than one team is a problem I’ll address later.)

Team 1 has 6 developers and 2 testers. The Product Owner is remote. The PO generates stories for the team in advance of the iteration. The PO explains the stories in the Sprint Planning meeting. They schedule the planning meeting for 2 hours, and they almost always need 3 hours.

Staggered_dev_testingThe developers and testers work in a staggered iteration. Because the developers finish their work in the first two-week iteration, they call their iterations two weeks. Even though the testers start their testing in that iteration, the testers don’t finish.

I explained that this iteration duration was at least three weeks. I asked if the testers ever got behind in their testing.

“Oh, yes,” he replied. “They almost always get behind. These days, it takes them almost two weeks to catch up to the developers.”

I explained that the duration that includes development and testing is the duration that counts. Not the first two weeks, but the total time it takes from the start of development to the end of testing.

“Oooh.” He hadn’t realized that.

He also had not realized that they are taking too much work (here, work in progress, WIP). The fact that they need more time to discuss stories in their planning meeting? A lot of WIP. The fact that the developers finish first? That creates WIP for the testers.

Sequential work makes your iterations longer. What would it take for you to work as a team on stories and reduce the lag time between the time the development is done and the testing is done?

The next post will be about when you have a longer duration based on interdependencies.

Categories: Project Management

Creating Great Estimates as a Team

Mon, 11/16/2015 - 15:18

I’ve been teaching workshops these last few weeks. A number of the participants think that they need to create great estimates. I keep hearing, “I have to create accurate estimates. My team needs my estimate to be accurate.”

I have found that the smaller the work, the better the estimate. If people work as a team, they can provide more accurate estimates than they can alone. And, if they work as a team, the more likely they are to meet the estimate.

The people in my workshops did not want to hear this. Many of them wanted to know how to create an estimate for “their” work, accounting for multitasking.

I don’t know how to create great estimates when people assume they work alone, or if they multitask.

In all of my experience, software is a team activity (especially if you want to use agile or lean). For me, creating an estimate of “my” work is irrelevant. The feature isn’t done until it’s all done.

When we create solo estimates, we reinforce the idea that we work alone. We can work alone. I have discovered I have different ideas when I pair. That’s one of the reasons I ask for review, if I am not actively pairing. I have also discovered that I find problems earlier when I pair or ask for frequent review. That changes my overall estimate.

Multitasking creates context switching, with built-in delays. (See Cost of Delay Due to Multitasking, Part 2 or Diving for Hidden Treasures.) I don’t know how to account for the context-switch times. For me, the context-switching time varies, and depends on how many switches I need to do.

PredictingUnpredictable-smallIf you want to create great estimates, estimate as a team. For hints, see Predicting the Unpredictable: Pragmatic Approaches to Estimating Project Cost or Schedule.

I urge you to make the thing you estimate small, you consider how you work with other people to deliver this thing, and you do one chunk of work at a time. All of those ideas will help you create better estimates. Not for “your” work, but for the work you deliver to your customer.

Categories: Project Management

People: Resilience Creators, Not Resources

Mon, 11/02/2015 - 13:38

I’ve been traveling, teaching, speaking and consulting all over the world. I keep encountering managers who talk about the “resources.” They mean people, and they say “resources.”

That makes me nuts. I blogged about that in People Are Not Resources. (I have other posts about this, too, but that’s a good one.)

I finally determined what we might call people. People are “resilience creators.” They are able to recognize challenges, concerns, or problems, and adjust their behavior.

People solve problems so the project can continue and deliver the product.

People fix problems so that customer support or sales can make the user experience useful.

People deliver products and/or services (or support the people who do) so that the company can continue to employ other people, deliver the company’s work, and acquire/retain customers.

We want resilient companies (and projects and environments). When we encounter a hiccup (or worse) we want the work to continue. Maybe not in the way it did before. Maybe we need to change something about what we do or how we do it. That’s fine. You hired great people, right?

People can solve problems so that the company can be resilient. To me, that means that the people are resilience creators, not “resources.”

People create resilience when they have the ability to solve problems because you asked them for results.

People create resilience when they understand the goals of the work.

People create resilience when they have the ability to work together, in a holistic way, not in competition with each other.

What would you rather have in your organization: resources or resilience creators?

Categories: Project Management