Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Managing Product Development - Johanna Rothman
Syndicate content
Expert in Managing Product Development
Updated: 1 hour 10 min ago

Possibilities for Managing Individual and Team Compensation

Fri, 06/23/2017 - 15:15

There’s a twitter conversation about how to manage team compensation. How can we pay people what they are worth and compensate a team for their value?

I know there are teams where I was quite valuable—not because I was “the” leader, but because I helped the team achieve our goals. And, there are teams where I was not as valuable. I did great work, but my contribution wasn’t as valuable as other people on the team.

That is the crux of the matter when we think about team compensation.

Here’s how I managed this problem in the past:

  • I created (with HR’s input) technical career levels. I often had 5 levels: associate engineer, engineer, senior engineer, principal engineer, consulting engineer. The principal and consulting had first-level manager and group manager as parallel. In addition, I had a couple more management levels (director and VP).
  • I wrote down expertise criteria that differentiated each level. The criteria focused on breadth of responsibility, collaboration capability, and strategic vs. tactical thinking. HR made me add “typical education” which I amended to say “or years of experience.
  • I asked my groups to provide me feedback on these criteria.
  • When I was sure the criteria were correct, I met one-on-one to make sure we each agreed where each person fit into the criteria. Some people were on the verge of a promotion. Some were not. We worked together to make sure we were both comfortable with their title and compensation.

Now, I had the ability to provide people individual compensation and promotions. And, I could provide team-based compensation. Here’s how it worked.

One guy, John, wanted a promotion to senior engineer. He was a high-initiative person. He coached and mentored people in the team. He got along with everyone quite well, and his solutions were often good. It was the often that was the difficult part. When he got an idea in his head, it would take a disaster to convince him he was wrong. His judgment was not as good as a senior engineer needed to have.

I’d provided feedback in our weekly one-on-ones explaining both my happiness and concerns with his judgment, depending on the circumstance. (This was not agile. We used staged-delivery, a feature-driven approach. I was the manager of several groups.) I asked him if he wanted coaching, and yes, he did, but not from me. That was fine. I arranged a coaching arrangement with someone who was a principal engineer (2 levels up).

The two of them met twice a week for several weeks. I think each meeting was about 20-30 minutes. The coach asked questions, provided guidance and options. The engineer learned a ton in that month and started to explore other options with his team. He started to realize his very first idea was not the be-all and end-all for the work.

It took him several months of practice, and I was able to promote him to be a senior engineer.

People need to know what the criteria are—why the org values them. If the salary ranges are too tight, there is no flexibility in hiring. If the salary ranges are too loose, it’s too easy to have discrimination in payment, especially if someone started their first job too low. (Yes, I have experienced salary discrimination.)

Let me provide a little context for team compensation. John’s team was involved in a new product. We didn’t know much about the customers and product management wasn’t much help. (I said this is before agile.) John asked the tech writer, Susan, for help in understand what customers wanted.

Susan guided the entire project. She helped the team understand the requirements. Because Susan was a principal engineer, she had customer contacts and she used them. She created what we would now recognize as a ranked backlog. John had the idea of a “pre-beta,” which were builds we provided to a select group of customers. You might think of this as a series of MVP (Minimum Viable Products) to these customers. The customers provided feedback to Susan, who used that feedback to guide the team.

We released the product and it was a great success. My VP came to me and told me I would get a $10k bonus (a ton of money back then). I said I had not enough to do with the project, and that the team would get the money. My boss cocked an eyebrow and said, “I don’t want to lose any of them.” I told him I would make it right, somehow.

I went to the team and told them I had been chosen to receive a $10k bonus, which I thought was wrong. They all agreed!

I asked them to explain how they wanted to divide the money. (I was thinking evenly.) Before I even had a chance to pass out stickies, John said, “Susan should get the most. She was the heart and soul of this project.” Everyone nodded their heads.

I said that was great, but let’s do a private vote in case not everyone agreed. I passed out stickies and asked people to write down how they wanted to divide it. Every person said: 40% to Susan, the rest evenly. Well, one person added me in the evenly part. I thanked the person and demurred.

That’s what we did. Susan asked for part of her increased percentage to be a team dinner with spouses/significant others and they invited Mark and me.

The team knows who did what. The team can manage bonuses.

I don’t know that this is the “best” approach. I have always wanted to know what my organization wanted from me. I have found a career ladder in the form of expertise criteria a great way to accomplish this. In addition, I want to know that if there is extra compensation, the team will receive that extra as a team. Every project I’ve ever been on was a team effort. Agile approaches make that even more obvious.

Categories: Project Management

Defining “Scaling” Agile, Part 6: Creating the Agile Organization

Mon, 06/19/2017 - 15:30

We might start to think about agile approaches as a project change. However, if you want to “scale” agile, the entire culture changes. Here is a list of the series and how everything changes the organization’s culture:

All of these “scaling” ideas require change.

Agile organizations become very good at small changes all the time. They are adaptive and resilient. They understand how change works and they embrace it. (Big changes are quite difficult for almost everyone. Small changes tend to be much easier.)

Here is a picture of the Satir change model. We start off in Old Status Quo with some level of performance. Some Foreign Element arrives and we have uneven performance while we are in Chaos, searching for that Transforming Idea. We discover that TI and practice and integrate that idea into our work until we reach a New Status Quo, hopefully at a higher level of performance.

The change model works for each human and for the entire organization. In fact, I don’t see how you can have an agile organization until people become comfortable with small and large changes on a regular basis. This is one of the reasons I say we should take an agile approach to agile. (See Agile is Not a Silver Bullet.)

Do you need to be a fully adaptive and resilient organization? Only you can answer that question. Maybe you start from teams and the project portfolio. Maybe you look for incentives that don’t create optimization “up.” (I need a new word for this! Do you have suggestions for me?? Please comment if so.)

You do not have to have a fully agile organization to recognize benefits at the team and project portfolio levels. Agile is Not for Everyone.

Decide how much change your organization needs to be successful. Practice change, as often as you can. That will help you more than an agile label will.

One last comment: I’m not sure “scaling” is the right way to think about this. For me, the scaling idea still has roots in silo thinking, not flow thinking. That could be just me. (Grin!) I wish I had a better way to explain it.

My ideas of scaling agile are about creating a culture based on our ability to change:

  • How do we treat each other? Do we/can we see each other as an intrinsic part of a whole?
  • What do we discuss? Do we discuss “failures” or learning opportunities?
  • What do we reward? How do we move to rewarding non-silo work? That is, work to deliver products (in either projects or programs) or other work that rewards collaboration and flow efficiency.

I hope you enjoyed this series. Please do comment on any of the posts. I am curious about what you think. I will learn from your comments.

Categories: Project Management

Defining “Scaling” Agile, Part 5: Agile Management

Thu, 06/15/2017 - 17:15

One of the challenges I see in organizations is how managers can use agile approaches. One of the biggest problems is that the entire organization is organized for resource efficiency (think silos of functional experts). Agile approaches use flow efficiency. Thinking in flow efficiency changes everything.

Many people in organizations believe that dividing up the work among specialists will get the work done faster. That’s the case in manufacturing. (Think piece work.) Manufacturing processes use resource efficiency to reasonable effect. However, manufacturing does not account for innovation or learning. (Design of manufacturing processes is innovative and requires learning. That’s why manufacturing processes often prototype (iterate on their work) when they develop the process.)

Organizations who need to optimize for innovation or learning realize that the people work collaboratively. Collaborative work—including management work—demands flow efficiency instead of resource efficiency.

Flow efficiency helps people optimize “up” for lack of a better term. (If you have not yet read This is Lean: Resolving the Efficiency Paradox, I recommend you  do so.)

Once you start to think about flow efficiency, you might start to think about throughput (and maybe cycle time and cumulative flow).  That changes the data the managers need to make decisions.

Now, it doesn’t matter what anyone’s utilization is. What matters is the Cost of Delay (or Cost of Delay/Duration). It might even matter where the bottlenecks are and who can unwedge those bottlenecks.

An organization might still need to track the run rate for a project, program, or even a workgroup such as Customer Support. Run rate might not mean as much when you can measure revenue, customer acquisition and retention, and how often you can get the customer to return and buy more. (The more often you deliver value, the more you can acquire customers who pay.)

One manager learned about flow efficiency. She was managing the team working on the “most important” project in the company. She decided to stop tracking utilization. She told her team, “I want to track your throughput as a team. I want to know what I can do improve the flow of work through your team. Please bring me your impediments to flow and I’ll address them.”

The team told her about build time (too slow), insufficient test automation (not enough and too slow). She built the case using Cost of Delay/Duration to get other teams to help this team reduce build time and increase test automation.

The teams together took eight weeks to make what they called infrastructure improvements. After the first two of those eight weeks, the team finished twice as many stories (2 instead of 1) as they had before all the improvements started. The team continued to increase their throughput. By the end of the eight weeks, the team was able to finish anywhere from 8-12 stories. The team continued their now-higher level of throughput. After three months, the organization had attracted many more customers. They decided to move to a subscription model for their product, and recognize much more revenue.

Yes, a team’s ability to deliver value fast created feedback loops for management: product management, project portfolio management.

(I’m still reading about agile-useful metrics, so I’m sure there is more here.)

If managers worry about flow efficiency, they ask the teams, “What can I do to help your throughput?” The managers manage the project portfolio. Work flows through teams, not through people.

That changes what managers do. Top-level managers (and maybe product managers) define the strategy and talk to customers to see what customers need so they can refine the strategy. Top managers also consider new options for entirely new products—changes in strategy.

Middle managers plan and replan the project portfolio to implement the strategy. First-level managers remove impediments to collaboration.

Let me summarize a little:

Agile managers have a very different role than more traditional managers. They manage differently. Agile managers might use the two pillars of lean: respect for people and continuous improvement as a basis for their management style. To me, that means building relationships with each person the manager “manages,”  the willingness to question all assumptions, and to look at the whole: what does it take for us to succeed as an organization. The idea of one function succeeding instead of all of us vanishes.

Flow efficiency changes the corporate culture: managers change what they discuss. Managers change what they reward. Managers change how they treat people and how they expect people to be treated, because it’s not about the individual “resource.” It’s about the system of work.

The posts so far aside from this post:

I’m quite sure this post is not perfect, but I have other writing to do. I expect to have one more summary post.

Categories: Project Management

Thinking About What to Call Team Members and Managers

Fri, 06/09/2017 - 15:23

Bob Sutton (@work_matters) tweeted this the other day:

Perhaps companies ought to stop using “IC” or “Individual Contributor.” It seems to absolve such employees from helping others

I retweeted it and we had some back-and-forth about what to call people i organizations.

Let’s eliminate these words for people who are not managers:

  • Individual Contributor: There are no one-person projects or efforts. Every work has at minimum, the person doing the work and the customer for that work. In what lifetime does a person work alone on anything in the organization?
  • FTE (Full Time Equivalent): FTE implies we have working units who are fungible with other working units who get paid the same amount. (Uh, no. Not at all. We have people who work.)
  • Resources: Resources removes our humanity. I have said before that people are resourceful. They are not resources.

We could call them any of these:

  • Team members
  • Employees
  • Staff (I used to use this word. I’m not so sure I like it anymore. But, I’m sure you can go back in this blog and show me places I’ve used it. I’m learning, just as you are.)
  • People

I like team members or people the best. That’s because I don’t see people working alone. Even in non-agile organizations. People work with other people. Even if they don’t collaborate together to finish the work. Even people who are part of one specific team often collaborate across the organization. Do let me know if you have a better idea.

Now, let’s go to the word, “Manager.” Managers are people and team members too. However, they float among different teams. Let’s take the first-level manager.

First-level managers are part of the team they manage, but not in the same way as the people doing the work of that team. First-level managers (project managers, functional managers, Scrum Masters) facilitate the team’s work. They serve the team.

In addition to the team they “manage” (no one manages people; managers decide on results and create the environment in which people/team members deliver results), these managers are also a part of other teams. Those teams might be people like them, such as functional managers who report to a Director or VP. They might be part of a team of project managers/Scrum Masters, etc. Those teams might not be explicitly defined in the org. However, effective managers use their peer group as a community of practice. They build relationships and learn what other people do.

Mid-level managers are often part of more explicit teams. They might be part of a program team, or a project portfolio team, maybe even a product line management team. They are often part of a team of the managers who report to them (their staff, “down” the hierarchy) and the managers they report to (“up” the hierarchy). Those teams might have a cadence of meetings to troubleshoot problems that prevent the first-level teams from delivering the results the org wants. These managers serve the organization, also.

Senior managers are often a team. They decide on the strategy together. They make financial decisions together. They set financial boundaries for the different work or departments. And, they also are part of their teams of managers “down” the hierarchy, their staff.

For me, team members are part of one feature team or work group. The managers use their small-world networks to build relationships and accomplish work throughout the organization. Managers are often part of several cross-functional teams, regardless of whether those teams have a name.

Hierarchy is a convenient way to organize, to draw boundaries around decision-making and financial responsibilities. I don’t have a problem with the words managers or team members. As with Bob Sutton, I have a problem with “Individual contributor” because no one works alone. We happen to pay people based on their “individual” contribution and that’s a leftover from the piece work days. Knowledge work doesn’t work like that.

We are all part of teams of some variety. If you think about names that are reasonable for your people (team members and managers), terrific. I certainly don’t have all the answers. (I wrote a little about what managers might do in agile organizations in several places here. I think the most recent post is What Development & Test Managers do in Agile Organizations.)

I only have a problem when we forget we are all people. Do let me know what you think.

Categories: Project Management

Thinking About What to Call Team Members and Managers

Fri, 06/09/2017 - 15:23

Bob Sutton (@work_matters) tweeted this the other day:

Perhaps companies ought to stop using “IC” or “Individual Contributor.” It seems to absolve such employees from helping others

I retweeted it and we had some back-and-forth about what to call people i organizations.

Let’s eliminate these words for people who are not managers:

  • Individual Contributor: There are no one-person projects or efforts. Every work has at minimum, the person doing the work and the customer for that work. In what lifetime does a person work alone on anything in the organization?
  • FTE (Full Time Equivalent): FTE implies we have working units who are fungible with other working units who get paid the same amount. (Uh, no. Not at all. We have people who work.)
  • Resources: Resources removes our humanity. I have said before that people are resourceful. They are not resources.

We could call them any of these:

  • Team members
  • Employees
  • Staff (I used to use this word. I’m not so sure I like it anymore. But, I’m sure you can go back in this blog and show me places I’ve used it. I’m learning, just as you are.)
  • People

I like team members or people the best. That’s because I don’t see people working alone. Even in non-agile organizations. People work with other people. Even if they don’t collaborate together to finish the work. Even people who are part of one specific team often collaborate across the organization. Do let me know if you have a better idea.

Now, let’s go to the word, “Manager.” Managers are people and team members too. However, they float among different teams. Let’s take the first-level manager.

First-level managers are part of the team they manage, but not in the same way as the people doing the work of that team. First-level managers (project managers, functional managers, Scrum Masters) facilitate the team’s work. They serve the team.

In addition to the team they “manage” (no one manages people; managers decide on results and create the environment in which people/team members deliver results), these managers are also a part of other teams. Those teams might be people like them, such as functional managers who report to a Director or VP. They might be part of a team of project managers/Scrum Masters, etc. Those teams might not be explicitly defined in the org. However, effective managers use their peer group as a community of practice. They build relationships and learn what other people do.

Mid-level managers are often part of more explicit teams. They might be part of a program team, or a project portfolio team, maybe even a product line management team. They are often part of a team of the managers who report to them (their staff, “down” the hierarchy) and the managers they report to (“up” the hierarchy). Those teams might have a cadence of meetings to troubleshoot problems that prevent the first-level teams from delivering the results the org wants. These managers serve the organization, also.

Senior managers are often a team. They decide on the strategy together. They make financial decisions together. They set financial boundaries for the different work or departments. And, they also are part of their teams of managers “down” the hierarchy, their staff.

For me, team members are part of one feature team or work group. The managers use their small-world networks to build relationships and accomplish work throughout the organization. Managers are often part of several cross-functional teams, regardless of whether those teams have a name.

Hierarchy is a convenient way to organize, to draw boundaries around decision-making and financial responsibilities. I don’t have a problem with the words managers or team members. As with Bob Sutton, I have a problem with “Individual contributor” because no one works alone. We happen to pay people based on their “individual” contribution and that’s a leftover from the piece work days. Knowledge work doesn’t work like that.

We are all part of teams of some variety. If you think about names that are reasonable for your people (team members and managers), terrific. I certainly don’t have all the answers. (I wrote a little about what managers might do in agile organizations in several places here. I think the most recent post is What Development & Test Managers do in Agile Organizations.)

I only have a problem when we forget we are all people. Do let me know what you think.

Categories: Project Management

Defining “Scaling” Agile, Part 4A: Sharing Agile Outside of Product Development

Thu, 06/08/2017 - 19:28

Note to my dear readers: As I write, I realize this series is growing. Thank you for your understanding in advance.

In Defining “Scaling” Agile, Part 4: Sharing Agile Outside of Product Development, I wrote about an independent workgroup with one stream of work. I used Customer Support as an example. Support has one stream: take in the tickets, work on the “most important” one first, see if you need to escalate and finish it. Everyone works towards the same goal.

What about if you work in a workgroup that has several streams of work? I’ll use HR as an example because HR often has these streams:

  • Benefits administration: retirement plans, health care, that kind of thing
  • Recruiting and hiring: how to find people and bring them into the organization
  • “Performance Management”: how to manage and improve the performance of the people in the organization. Don’t get me started on the value of this work. I have other drafts to address this wrong-headed assumption especially in an agile organization.

In that case, the workgroup rarely collaborates on the work. It’s possible that Customer Support collaborates on their work. However, the different people in HR do not tend to collaborate. It’s the same in Finance: Accounts Payable and Accounts Receivable are not the same thing. Depending on where Purchasing sits, they might be a different stream, also.

If the group wants a big picture of their work, this kind of a kanban board might help. Note that there are no WIP limits because the group does not collaborate. There is no interdependent work.

Each of these people might want their own board to show the details of their work, but that’s not this board.

There is no reason for—and it would not be helpful—for this group to have a standup. That would be a serial status meeting. They might want to monitor decisions to see if other people change their minds about what’s going on in their group. They might want to retrospect on how often they have Waiting work and what to do about it.

There is a difference between product development agile approaches and workgroup approaches. I have found that visualizing the work is the key for unlocking lower WIP limits and faster cycle time.

Yes, I have this board as an example in Create Your Successful Agile Project.

In a Marketing department, the product managers had their work and Marketing Communications had their work. MarComm had to produce videos of customer case studies, white papers, and testimonials. MarComm actually looked more like a product development feature team than the product managers did. The product managers had to continue to think about the product direction and how often they could replan. They each had their own boards (product management and MarComm). And, they put together a board much like the one for HR with streams on the bottom so other people could see bottlenecks.

If you work in a workgroup, you might need a board that shows the flow of work in your stream, and a different board that shows the overall group’s work at a higher level. There is no right answer.

Here are the posts so far:

I think I need another part about agile management and then I can talk about an agile business. I’m enjoying the rigor of my thinking. I hope you do, too.

Categories: Project Management

Defining “Scaling” Agile, Part 4A: Sharing Agile Outside of Product Development

Thu, 06/08/2017 - 19:28

Note to my dear readers: As I write, I realize this series is growing. Thank you for your understanding in advance.

In Defining “Scaling” Agile, Part 4: Sharing Agile Outside of Product Development, I wrote about an independent workgroup with one stream of work. I used Customer Support as an example. Support has one stream: take in the tickets, work on the “most important” one first, see if you need to escalate and finish it. Everyone works towards the same goal.

What about if you work in a workgroup that has several streams of work? I’ll use HR as an example because HR often has these streams:

  • Benefits administration: retirement plans, health care, that kind of thing
  • Recruiting and hiring: how to find people and bring them into the organization
  • “Performance Management”: how to manage and improve the performance of the people in the organization. Don’t get me started on the value of this work. I have other drafts to address this wrong-headed assumption especially in an agile organization.

In that case, the workgroup rarely collaborates on the work. It’s possible that Customer Support collaborates on their work. However, the different people in HR do not tend to collaborate. It’s the same in Finance: Accounts Payable and Accounts Receivable are not the same thing. Depending on where Purchasing sits, they might be a different stream, also.

If the group wants a big picture of their work, this kind of a kanban board might help. Note that there are no WIP limits because the group does not collaborate. There is no interdependent work.

Each of these people might want their own board to show the details of their work, but that’s not this board.

There is no reason for—and it would not be helpful—for this group to have a standup. That would be a serial status meeting. They might want to monitor decisions to see if other people change their minds about what’s going on in their group. They might want to retrospect on how often they have Waiting work and what to do about it.

There is a difference between product development agile approaches and workgroup approaches. I have found that visualizing the work is the key for unlocking lower WIP limits and faster cycle time.

Yes, I have this board as an example in Create Your Successful Agile Project.

In a Marketing department, the product managers had their work and Marketing Communications had their work. MarComm had to produce videos of customer case studies, white papers, and testimonials. MarComm actually looked more like a product development feature team than the product managers did. The product managers had to continue to think about the product direction and how often they could replan. They each had their own boards (product management and MarComm). And, they put together a board much like the one for HR with streams on the bottom so other people could see bottlenecks.

If you work in a workgroup, you might need a board that shows the flow of work in your stream, and a different board that shows the overall group’s work at a higher level. There is no right answer.

Here are the posts so far:

I think I need another part about agile management and then I can talk about an agile business. I’m enjoying the rigor of my thinking. I hope you do, too.

Categories: Project Management

Defining “Scaling” Agile, Part 4: Sharing Agile Outside of Product Development

Wed, 06/07/2017 - 13:06

Here’s where we are so far in this discussion of what it might mean to “scale” agile approaches:

This is Part 4, where other functions want to use agile approaches. I’m calling this “sharing” agile. If these people are part of a program or a project, the product development team(s) have asked them to participate in an agile way. This part is about embedding (I’m not sure that’s the right word) agile approaches into other functions.

Some functions are workgroups where the people work mostly alone but might collaborate. Think of Customer Support for example. Customer Support has a single-function workstream. Other functional workgroups have multiple workstreams.


In Support, people take tickets (the incoming queue of work) often alone. They work their tickets until they resolve the ticket.
Here is a possible kanban board for what might happen as a flow for these tickets. The queue of tickets is all the way on the left. Notice that there are two possible Ready columns: Ready for ranking and Ready to Start.

Customer support teams might rank and rerank their work several times during a day. Certainly, they do so during the week. They rank some work so it’s Ready to Start. It’s possible that they have work In Progress, Escalated to some other team/group/function, in Test. Depending on what the product is, they might need a Deploy column and then the work is Done.

Customer support often discovers they have “inconsistent” cycle time. That is, some work takes very little time (as in hours), some work takes forever (as in weeks), and some is in the middle somewhere, in the form of days. In my experience, those cycle time ranges depend on what the Product Development teams released.

How could a Customer Support group use agile approaches? They don’t work together. They can’t possibly plan for the next week, never mind two weeks. (A Tier 3 support group might be able to plan for more time, but I doubt it.) There’s not much value in that much planning. There’s no value in standups although there might be value in walking the board to see if anything is stuck after some time period. I would walk the board for escalations, and sometimes, the escalations are the Support manager’s job.)

A Customer Support group can find much more value in managing WIP (Work in Progress), and managing escalations (their wait states and potential bottlenecks). And, there is tremendous value in retrospectives with root cause analysis. While the Support people might find problems in what Product Development released, they often discover that their processes need tweaking. Customer Support can take advantage of double-loop learning with their retrospectives.

When I ran a Tier 3 support group many years ago, I asked my staff if we could retrospect on a one-week cadence. For some huge problems, that was too often. But, it mostly worked. I checked the state of the escalations with the people who had escalated. I didn’t do this as a group because the problems were so different. That would have wasted everyone’s time. We did do once-a-week learning as a team. I was not smart enough back then to use a paper board. I used a spreadsheet.

Even I, with my love of paper boards, am not suggesting that all Support groups use paper boards. Support often requires electronic tools to be most effective. I do recommend that the group add enough columns to see their flow. Sometimes, Support groups take the escalations out and put them on a paper board for tracking, because the work cycles between different people and teams in those columns.

Agile approaches for workgroups are different than for teams. Teams have interdependent work. Groups have (mostly) independent work.

I’ll do another post about agile for workgroups with multiple streams. And yes, I have a chapter about agile approaches for workgroups in Create Your Successful Agile Project.

Categories: Project Management

Defining “Scaling” Agile, Part 4: Sharing Agile Outside of Product Development

Wed, 06/07/2017 - 13:06

Here’s where we are so far in this discussion of what it might mean to “scale” agile approaches:

This is Part 4, where other functions want to use agile approaches. I’m calling this “sharing” agile. If these people are part of a program or a project, the product development team(s) have asked them to participate in an agile way. This part is about embedding (I’m not sure that’s the right word) agile approaches into other functions.

Some functions are workgroups where the people work mostly alone but might collaborate. Think of Customer Support for example. Customer Support has a single-function workstream. Other functional workgroups have multiple workstreams.


In Support, people take tickets (the incoming queue of work) often alone. They work their tickets until they resolve the ticket.
Here is a possible kanban board for what might happen as a flow for these tickets. The queue of tickets is all the way on the left. Notice that there are two possible Ready columns: Ready for ranking and Ready to Start.

Customer support teams might rank and rerank their work several times during a day. Certainly, they do so during the week. They rank some work so it’s Ready to Start. It’s possible that they have work In Progress, Escalated to some other team/group/function, in Test. Depending on what the product is, they might need a Deploy column and then the work is Done.

Customer support often discovers they have “inconsistent” cycle time. That is, some work takes very little time (as in hours), some work takes forever (as in weeks), and some is in the middle somewhere, in the form of days. In my experience, those cycle time ranges depend on what the Product Development teams released.

How could a Customer Support group use agile approaches? They don’t work together. They can’t possibly plan for the next week, never mind two weeks. (A Tier 3 support group might be able to plan for more time, but I doubt it.) There’s not much value in that much planning. There’s no value in standups although there might be value in walking the board to see if anything is stuck after some time period. I would walk the board for escalations, and sometimes, the escalations are the Support manager’s job.)

A Customer Support group can find much more value in managing WIP (Work in Progress), and managing escalations (their wait states and potential bottlenecks). And, there is tremendous value in retrospectives with root cause analysis. While the Support people might find problems in what Product Development released, they often discover that their processes need tweaking. Customer Support can take advantage of double-loop learning with their retrospectives.

When I ran a Tier 3 support group many years ago, I asked my staff if we could retrospect on a one-week cadence. For some huge problems, that was too often. But, it mostly worked. I checked the state of the escalations with the people who had escalated. I didn’t do this as a group because the problems were so different. That would have wasted everyone’s time. We did do once-a-week learning as a team. I was not smart enough back then to use a paper board. I used a spreadsheet.

Even I, with my love of paper boards, am not suggesting that all Support groups use paper boards. Support often requires electronic tools to be most effective. I do recommend that the group add enough columns to see their flow. Sometimes, Support groups take the escalations out and put them on a paper board for tracking, because the work cycles between different people and teams in those columns.

Agile approaches for workgroups are different than for teams. Teams have interdependent work. Groups have (mostly) independent work.

I’ll do another post about agile for workgroups with multiple streams. And yes, I have a chapter about agile approaches for workgroups in Create Your Successful Agile Project.

Categories: Project Management

What’s the “Right” Term for an Agile Transition or Transformation?

Mon, 06/05/2017 - 14:22

As I finish the agile project management book (Create Your Successful Agile Project), I am working on what stays in this book and what I use in the agile management book (next up after the PO book).

That leads me to this question: What do you call a transition to agile approaches? Is there a correct term?

Here’s what I’m thinking right now and I’m totally open to changing my thinking:

Transition to agile: to me, it means a transition from planning for predictability to planning for predictable deliveries. In other words, it’s the delivery of value again and again that allows us to replan again and again. This requires a change in thinking. Maybe I should call this a transition to agile thinking? (Am I the only one who thinks this way?)

Agile transformation: We transform the organization to working and thinking in an agile way. We transform the culture. For me, this is such a big idea, I don’t see it happening. I don’t even think I know what it totally means. On the other hand, agile approaches are a cultural shift from how people thought and how they organized to new ways of thinking and organizing.

Agile adoption: To me, this is about adopting an agile mindset and values. On the other hand, I’ve seen too much bounce-back when people (especially managers) talk about agile adoption. They tend to think of agile approaches as yet another project management life cycle.

Do you use another term? Do you find its baggage acceptable? Please let me know what you think the “right” term is for an agile transition or transformation. Thank you!

Categories: Project Management

What’s the “Right” Term for an Agile Transition or Transformation?

Mon, 06/05/2017 - 14:22

As I finish the agile project management book (Create Your Successful Agile Project), I am working on what stays in this book and what I use in the agile management book (next up after the PO book).

That leads me to this question: What do you call a transition to agile approaches? Is there a correct term?

Here’s what I’m thinking right now and I’m totally open to changing my thinking:

Transition to agile: to me, it means a transition from planning for predictability to planning for predictable deliveries. In other words, it’s the delivery of value again and again that allows us to replan again and again. This requires a change in thinking. Maybe I should call this a transition to agile thinking? (Am I the only one who thinks this way?)

Agile transformation: We transform the organization to working and thinking in an agile way. We transform the culture. For me, this is such a big idea, I don’t see it happening. I don’t even think I know what it totally means. On the other hand, agile approaches are a cultural shift from how people thought and how they organized to new ways of thinking and organizing.

Agile adoption: To me, this is about adopting an agile mindset and values. On the other hand, I’ve seen too much bounce-back when people (especially managers) talk about agile adoption. They tend to think of agile approaches as yet another project management life cycle.

Do you use another term? Do you find its baggage acceptable? Please let me know what you think the “right” term is for an agile transition or transformation. Thank you!

Categories: Project Management

Defining “Scaling” Agile, Part 3: Creating Agile Product Development Capabilities

Wed, 05/31/2017 - 15:36

In the “Scaling” Agile: Part 1, I wrote about cross-functional collaborative teams. The cross-functional collaborative feature team is the basis for “scaling” agile. In “Scaling” Agile, Part 2, I wrote about programs. I realized I need another part before my original part 3 :-). This new part 3 is about creating agile product development capabilities.

In Agile and Lean Program Management, I wrote about continuous planning. (I should have called it “continual” but I didn’t. Oh well. In the second edition I can do that :-).)

Here’s a problem I see a lot in organizations who want to “scale” agile. They plan and replan less often than they should. (I am working on a product owner book to help with that problem. It’s next in the queue.)

This lack of replanning is a legacy from the more traditional yearly planning.

When organizations planned the project portfolio on a yearly basis, people didn’t perceive a need to plan the products more often. However, with agile approaches, it’s  possible and helpful to plan the project portfolio on a quarterly basis, if not more often. And, in order to replan more often, the teams need to deliver finished features more often.

In Manage Your Project Portfolio, I recommend people start with quarterly planning and move to more frequent planning as the teams get better at delivering value in the form of completed features.

It’s the same idea for product management and product ownership. Product management and product ownership are two different albeit related activities.

Product management manages the product over its lifetime. Product managers meet with customers. (So should real UX people so they can create and run experiments, but that’s a different post.) Product owners are part of an agile team and work with that team on a continuous basis.

The continuous basis part is part of what the PO needs to do: create and refine (small) stories, accept stories, and replan the roadmap and the next backlog. I wrote about rolling wave replanning in Consider Rolling Wave Roadmap and Backlog Planning.

Agile approaches allow us to replan. This is particularly helpful when we want to replan the project portfolio and product roadmaps.

This graph to the left is what we hope are the product’s capabilities over time. Every project helps us create more capabilities.

Agile approaches allow us to release value on a regular basis, at least as often as every month in my world. Hopefully, every week or two. If you use continuous delivery, you can release value multiple times a day.

The more often you release, the more often the people with strategy responsibilities can manage the project portfolio. Have we done enough for this project for now? If so, feed the team another product. (In my world, there are often too many products for the number of teams. We flow work through a team, so the team can move to another product.)

The more often the product value team (I’ve been calling this the product owner value team) can replan in rolling waves and help the team(s) deliver value more often, the more often the managers can change the project portfolio, the mix of projects the organization can deliver for the number of teams.

Agile product development capabilities require:

  • Cross-functional collaborative feature teams that deliver value often. The more often a team can deliver, the easier everything else is. (This is Part 1 of this series.)
  • Product owners and their colleagues to replan often. Again, the more the team(s) can deliver value, the easier it is to replan.
  • Managers can then make small safe-to-fail bets on the project portfolio. If they realize the will “lose” a bet, replan the project portfolio. Choose another mix of projects to see different value from products.

That’s what I mean about agile product development capabilities. If the product development organization can become good at delivering value, the product value team people can replan what they have in the roadmap and backlog. The project portfolio people can replan the project portfolio. The product development effort in the large becomes agile.

If you have questions, please ask in the comments. I’m just starting to explain this in writing. I’m sure I am not as clear as I want to be.

Categories: Project Management

Defining “Scaling” Agile, Part 3: Creating Agile Product Development Capabilities

Wed, 05/31/2017 - 15:36

In the “Scaling” Agile: Part 1, I wrote about cross-functional collaborative teams. The cross-functional collaborative feature team is the basis for “scaling” agile. In “Scaling” Agile, Part 2, I wrote about programs. I realized I need another part before my original part 3 :-). This new part 3 is about creating agile product development capabilities.

In Agile and Lean Program Management, I wrote about continuous planning. (I should have called it “continual” but I didn’t. Oh well. In the second edition I can do that :-).)

Here’s a problem I see a lot in organizations who want to “scale” agile. They plan and replan less often than they should. (I am working on a product owner book to help with that problem. It’s next in the queue.)

This lack of replanning is a legacy from the more traditional yearly planning.

When organizations planned the project portfolio on a yearly basis, people didn’t perceive a need to plan the products more often. However, with agile approaches, it’s  possible and helpful to plan the project portfolio on a quarterly basis, if not more often. And, in order to replan more often, the teams need to deliver finished features more often.

In Manage Your Project Portfolio, I recommend people start with quarterly planning and move to more frequent planning as the teams get better at delivering value in the form of completed features.

It’s the same idea for product management and product ownership. Product management and product ownership are two different albeit related activities.

Product management manages the product over its lifetime. Product managers meet with customers. (So should real UX people so they can create and run experiments, but that’s a different post.) Product owners are part of an agile team and work with that team on a continuous basis.

The continuous basis part is part of what the PO needs to do: create and refine (small) stories, accept stories, and replan the roadmap and the next backlog. I wrote about rolling wave replanning in Consider Rolling Wave Roadmap and Backlog Planning.

Agile approaches allow us to replan. This is particularly helpful when we want to replan the project portfolio and product roadmaps.

This graph to the left is what we hope are the product’s capabilities over time. Every project helps us create more capabilities.

Agile approaches allow us to release value on a regular basis, at least as often as every month in my world. Hopefully, every week or two. If you use continuous delivery, you can release value multiple times a day.

The more often you release, the more often the people with strategy responsibilities can manage the project portfolio. Have we done enough for this project for now? If so, feed the team another product. (In my world, there are often too many products for the number of teams. We flow work through a team, so the team can move to another product.)

The more often the product value team (I’ve been calling this the product owner value team) can replan in rolling waves and help the team(s) deliver value more often, the more often the managers can change the project portfolio, the mix of projects the organization can deliver for the number of teams.

Agile product development capabilities require:

  • Cross-functional collaborative feature teams that deliver value often. The more often a team can deliver, the easier everything else is. (This is Part 1 of this series.)
  • Product owners and their colleagues to replan often. Again, the more the team(s) can deliver value, the easier it is to replan.
  • Managers can then make small safe-to-fail bets on the project portfolio. If they realize the will “lose” a bet, replan the project portfolio. Choose another mix of projects to see different value from products.

That’s what I mean about agile product development capabilities. If the product development organization can become good at delivering value, the product value team people can replan what they have in the roadmap and backlog. The project portfolio people can replan the project portfolio. The product development effort in the large becomes agile.

If you have questions, please ask in the comments. I’m just starting to explain this in writing. I’m sure I am not as clear as I want to be.

Categories: Project Management

Defining “Scaling” Agile, Part 2: Program Management for Product Development

Tue, 05/23/2017 - 22:36

The first post was about scaling functions to working as collaborative agile teams. See Defining “Scaling” Agile, Part 1: Creating Cross-Functional Teams. Now, let’s talk about moving to multiple teams working together, a program.

The good news is that you have a few cross-functional teams. They’ve been delivering as project teams. And, now you have a program, a collection of several projects with one business objective.

Programs come in a wide variety of shapes and sizes. Here are some kinds of programs:

  • You might have just one feature team and need people from Marketing or Legal to release the product. You need to bring those people into the program somehow, so they can accomplish their deliverables so the organization can release the product.
  • The project is larger than one or two feature teams. You may have several feature sets and need people from Marketing, or Legal, or Finance (or someone else) to be able to release the product.
  • You might be managing the software program, and have several feature teams or programs within the larger program. You might have the Engine program, and the Admin and Diagnostics programs. Each feature set has several teams collaborating on the code in their feature set(s). And, you probably need people across the organization to finish the work for the product. Those are the people from Marketing, Legal, Finance or others that I keep talking about.

Programs exist when you need a little structure to organize the feature teams and/or organize the deliverables across the organization. Agile programs especially don’t need too much structure. The key is to create something that helps the people collaborate and visualize the work they need to complete.

Here’s a way to think about scaling to a program:

Scale the collaboration across product development to release products. 

 Scaling Collaboration Across the OrganizationYes, I wrote a book about that:  Agile and Lean Program Management: Scaling Collaboration Across the Organization.

Here’s how I think about scaling collaboration across product development:

  • Each team thinks about how fast they can release their work to the rest of the program. (BTW, fast isn’t useful unless the work is great.)
  • Each team manages its WIP (Work in Progress) so they aren’t bottlenecking themselves or anyone else.
  • The POs work as a team so the feature teams always work on the most valuable work for the program. Sometimes, feature teams move from one feature set to another because that work is more valuable. If you’re worried about interdependencies, you might not have feature teams. Or, the POs aren’t working together. See Understand Your Project Interdependencies.
  • Teams use the power of their small-world networks (and possibly Communities of Practice) to solve problems at the team level. Teams often don’t need help from anyone with “manager” or “master” in their titles.

Aside from trusting the teams to deliver and asking them to let you know if they can’t, I also suggest these ideas:

  • Scale the visualization of the work. How do people see what other teams or people are doing?  (I have plenty of images of kanban boards so you can see if any of those work for you.)
  • Keep the hierarchy as flat as possible so problems don’t have to go up a hierarchy, over and down, and then follow their path back before someone gets the answer they need.
  • Consider a cadence of meetings that solve problems. These meetings are not standups. Standups might expose problems but they don’t solve them.

I recommend teams decide if they need to organize as small programs (such as above with the Engine, Admin, and Diagnostics programs). That allows a cadence of limited-participation program team meetings to solve problems the teams can’t solve.

In addition, measure at the program level. Sure, the teams need to measure their cycle time and velocity, whatever they choose. In addition, measure the features complete at the program level, program level WIP, and any other program measures that make sense to you. (See Velocity is Not Acceleration for two of these charts.)

Agile program management helps product development use agile approaches to release products. Next up is how to scale agile from product development to other parts of the organization.

Categories: Project Management

Defining “Scaling” Agile, Part 2: Program Management for Product Development

Tue, 05/23/2017 - 22:36

The first post was about scaling functions to working as collaborative agile teams. See Defining “Scaling” Agile, Part 1: Creating Cross-Functional Teams. Now, let’s talk about moving to multiple teams working together, a program.

The good news is that you have a few cross-functional teams. They’ve been delivering as project teams. And, now you have a program, a collection of several projects with one business objective.

Programs come in a wide variety of shapes and sizes. Here are some kinds of programs:

  • You might have just one feature team and need people from Marketing or Legal to release the product. You need to bring those people into the program somehow, so they can accomplish their deliverables so the organization can release the product.
  • The project is larger than one or two feature teams. You may have several feature sets and need people from Marketing, or Legal, or Finance (or someone else) to be able to release the product.
  • You might be managing the software program, and have several feature teams or programs within the larger program. You might have the Engine program, and the Admin and Diagnostics programs. Each feature set has several teams collaborating on the code in their feature set(s). And, you probably need people across the organization to finish the work for the product. Those are the people from Marketing, Legal, Finance or others that I keep talking about.

Programs exist when you need a little structure to organize the feature teams and/or organize the deliverables across the organization. Agile programs especially don’t need too much structure. The key is to create something that helps the people collaborate and visualize the work they need to complete.

Here’s a way to think about scaling to a program:

Scale the collaboration across product development to release products. 

 Scaling Collaboration Across the OrganizationYes, I wrote a book about that:  Agile and Lean Program Management: Scaling Collaboration Across the Organization.

Here’s how I think about scaling collaboration across product development:

  • Each team thinks about how fast they can release their work to the rest of the program. (BTW, fast isn’t useful unless the work is great.)
  • Each team manages its WIP (Work in Progress) so they aren’t bottlenecking themselves or anyone else.
  • The POs work as a team so the feature teams always work on the most valuable work for the program. Sometimes, feature teams move from one feature set to another because that work is more valuable. If you’re worried about interdependencies, you might not have feature teams. Or, the POs aren’t working together. See Understand Your Project Interdependencies.
  • Teams use the power of their small-world networks (and possibly Communities of Practice) to solve problems at the team level. Teams often don’t need help from anyone with “manager” or “master” in their titles.

Aside from trusting the teams to deliver and asking them to let you know if they can’t, I also suggest these ideas:

  • Scale the visualization of the work. How do people see what other teams or people are doing?  (I have plenty of images of kanban boards so you can see if any of those work for you.)
  • Keep the hierarchy as flat as possible so problems don’t have to go up a hierarchy, over and down, and then follow their path back before someone gets the answer they need.
  • Consider a cadence of meetings that solve problems. These meetings are not standups. Standups might expose problems but they don’t solve them.

I recommend teams decide if they need to organize as small programs (such as above with the Engine, Admin, and Diagnostics programs). That allows a cadence of limited-participation program team meetings to solve problems the teams can’t solve.

In addition, measure at the program level. Sure, the teams need to measure their cycle time and velocity, whatever they choose. In addition, measure the features complete at the program level, program level WIP, and any other program measures that make sense to you. (See Velocity is Not Acceleration for two of these charts.)

Agile program management helps product development use agile approaches to release products. Next up is how to scale agile from product development to other parts of the organization.

Categories: Project Management

Defining “Scaling” Agile, Part 1: Creating Cross-Functional Feature Teams

Mon, 05/22/2017 - 17:34

I keep encountering confusion about what scaling agile is. I’m writing what I think is a 4-part series to define it so we all talk about the same thing.

When I ask people to define what they mean by scaling agile, they talk about these possibilities:

  1. They have agile developers. They want agile testers. This is creating cross-functional agile teams for projects.
  2. They have had successful one- or two-team agile projects. Now, they’re ready for an agile program.
  3. They have agile product development (it might be called IT or Engineering or R&D or something else), and they want to share agile approaches across Marketing, Finance, HR.
  4. They want to build an entirely agile business.

Each of these is different. Each solves a different problem for the organization. This post is about #1: the developers have been agile in their single function team. They want to bring the testers along and create cross-functional teams. (It could be the other way around where the testers are agile, but I haven’t seen that. I have seen testers using iterative and incremental approaches, but often that’s a reaction to the developers.)

I wrote about the problem of staggered iterations in How Long Are Your Iterations, Part 1. When the developers are on a different cadence than the testers, they don’t act like a cross-functional feature team. The “team” isn’t delivering a finished feature. They’re not solving problems like a team. They often have a ton of WIP (Work in Progress). Using iterations does not make a team agile.

On the other hand, if this is where you can start, do start there. The next part in your “scaling” of agile is to move to cross-functional feature teams. That’s where the team works together, in a collaborative fashion, to create finished features. You might do this in iterations, especially if you’ve only heard of Scrum. You might use a kanban board to see all the flow of work through your team and your bottlenecks.

I keep talking about “your team.” Agile approaches use cross-functional teams who focus on delivering features. I’m not big on component teams. That’s because they postpone delivery of finished features. I also hate the idea (and name) of “shared services.” I’ll blog about that later.

You might think, “The developers are agile. We’ll scale agile to the testers.” If that’s the way people think about agile in your organization, maybe that’s the best you can do. Here’s a possible reframe for you:

Scale agile from one function to a cross-functional team.

When you (and your managers) start to think about cross-functional teams rather than functions, you start to realize the benefits of agile.

If you think scaling agile is sharing agile between functional teams, consider reading my upcoming book, Create Your Successful Agile Project. I’m still in editing and then it goes out for review. We expect it will be available in July.

I do have reviewers, but if you are struggling with your agile approach, let me know if you would like to be a reviewer. We might have room for another couple of reviewers.

Categories: Project Management

Defining “Scaling” Agile, Part 1: Creating Cross-Functional Feature Teams

Mon, 05/22/2017 - 17:34

I keep encountering confusion about what scaling agile is. I’m writing what I think is a 4-part series to define it so we all talk about the same thing.

When I ask people to define what they mean by scaling agile, they talk about these possibilities:

  1. They have agile developers. They want agile testers. This is creating cross-functional agile teams for projects.
  2. They have had successful one- or two-team agile projects. Now, they’re ready for an agile program.
  3. They have agile product development (it might be called IT or Engineering or R&D or something else), and they want to share agile approaches across Marketing, Finance, HR.
  4. They want to build an entirely agile business.

Each of these is different. Each solves a different problem for the organization. This post is about #1: the developers have been agile in their single function team. They want to bring the testers along and create cross-functional teams. (It could be the other way around where the testers are agile, but I haven’t seen that. I have seen testers using iterative and incremental approaches, but often that’s a reaction to the developers.)

I wrote about the problem of staggered iterations in How Long Are Your Iterations, Part 1. When the developers are on a different cadence than the testers, they don’t act like a cross-functional feature team. The “team” isn’t delivering a finished feature. They’re not solving problems like a team. They often have a ton of WIP (Work in Progress). Using iterations does not make a team agile.

On the other hand, if this is where you can start, do start there. The next part in your “scaling” of agile is to move to cross-functional feature teams. That’s where the team works together, in a collaborative fashion, to create finished features. You might do this in iterations, especially if you’ve only heard of Scrum. You might use a kanban board to see all the flow of work through your team and your bottlenecks.

I keep talking about “your team.” Agile approaches use cross-functional teams who focus on delivering features. I’m not big on component teams. That’s because they postpone delivery of finished features. I also hate the idea (and name) of “shared services.” I’ll blog about that later.

You might think, “The developers are agile. We’ll scale agile to the testers.” If that’s the way people think about agile in your organization, maybe that’s the best you can do. Here’s a possible reframe for you:

Scale agile from one function to a cross-functional team.

When you (and your managers) start to think about cross-functional teams rather than functions, you start to realize the benefits of agile.

If you think scaling agile is sharing agile between functional teams, consider reading my upcoming book, Create Your Successful Agile Project. I’m still in editing and then it goes out for review. We expect it will be available in July.

I do have reviewers, but if you are struggling with your agile approach, let me know if you would like to be a reviewer. We might have room for another couple of reviewers.

Categories: Project Management

With Agile, No Warnings Needed

Mon, 05/01/2017 - 20:20

Have you ever worked on a project where the management and/or sponsors felt it necessary to provide you warnings: “This release better do this or have that. Otherwise, you’re toast.”

I have, once. That’s when I started to use release criteria and check with the sponsors/management to make sure they agreed.

I happen to like release criteria. Even better is when you use agile on your projects. You might get feedback before the release. Here’s what a client did on a recent project:

  • They had release criteria and the sponsors agreed to the criteria.
  • They released internally every two weeks and asked people to come to the demos.
  • They asked the product managers and product owners to review the finished work and to make sure the managers/sponsors liked where the roadmap was going.
  • The team worked in ways that promoted technical excellence, so they could (relatively) easily change the code base when people changed their minds.

The project didn’t fulfill all the wishes that managers and sponsors wanted. Those folks wanted the proverbial 15 pounds of project into a 5 pound bag. On the other hand, the team is on the verge of delivering a terrific product. (They have one more week to finish.) They are all proud of their effort and the way they’ve worked.

This morning, the project manager emailed me. “I’m so angry I could spit,” she said. “One of our sponsors, who couldn’t be bothered to see any demos just told me that if he doesn’t like it, he’s going to send us back to the drawing board. Do you have time for a quick call so I don’t get myself fired?”

This is a culture clash between the agile project’s transparency and request for frequent feedback vs. the controlling desires of management.

We spoke. She realized it was a difference in expectations and culture that will take a while to go away. There are probably reasons for it, and that doesn’t make it any easier for the team.

These kinds of situations are why I recommend new agile teams have a servant leader. I don’t care if you call that person an agile project manager or some other term, but the person’s role is to run interference between the two cultures.

The worst part? With the project’s transparency and interim delivery of value, no one needed to warn anyone about anything. The data this guy was looking for was in the demos, in the meeting minutes and was easily accessible.

I don’t know why people think they need to provide dire warnings. It’s not clear what effect they want to create. Dire warnings make even less sense when the team uses agile and provides interim value and demos.

If you’re using agile approaches, and you see this happening, decide what you want from this relationship. If you think you’ll have to work with this person again and again, it might make sense to have a conversation and see what they really want. What are their concerns? What are their pressures? Can you help them with information at other times instead of a week before the end of the project?

Don’t be surprised if you see this kind of a culture clash in your organization as teams start their transformation. Managers have a lot to do with culture (you might say they are the holders of the culture) and we’re asking them to use different measurements and act differently. A huge change. (Yes, after the agile project book, I’m writing an agile management book. I know, you’re not surprised.)

Categories: Project Management

With Agile, No Warnings Needed

Mon, 05/01/2017 - 20:20

Have you ever worked on a project where the management and/or sponsors felt it necessary to provide you warnings: “This release better do this or have that. Otherwise, you’re toast.”

I have, once. That’s when I started to use release criteria and check with the sponsors/management to make sure they agreed.

I happen to like release criteria. Even better is when you use agile on your projects. You might get feedback before the release. Here’s what a client did on a recent project:

  • They had release criteria and the sponsors agreed to the criteria.
  • They released internally every two weeks and asked people to come to the demos.
  • They asked the product managers and product owners to review the finished work and to make sure the managers/sponsors liked where the roadmap was going.
  • The team worked in ways that promoted technical excellence, so they could (relatively) easily change the code base when people changed their minds.

The project didn’t fulfill all the wishes that managers and sponsors wanted. Those folks wanted the proverbial 15 pounds of project into a 5 pound bag. On the other hand, the team is on the verge of delivering a terrific product. (They have one more week to finish.) They are all proud of their effort and the way they’ve worked.

This morning, the project manager emailed me. “I’m so angry I could spit,” she said. “One of our sponsors, who couldn’t be bothered to see any demos just told me that if he doesn’t like it, he’s going to send us back to the drawing board. Do you have time for a quick call so I don’t get myself fired?”

This is a culture clash between the agile project’s transparency and request for frequent feedback vs. the controlling desires of management.

We spoke. She realized it was a difference in expectations and culture that will take a while to go away. There are probably reasons for it, and that doesn’t make it any easier for the team.

These kinds of situations are why I recommend new agile teams have a servant leader. I don’t care if you call that person an agile project manager or some other term, but the person’s role is to run interference between the two cultures.

The worst part? With the project’s transparency and interim delivery of value, no one needed to warn anyone about anything. The data this guy was looking for was in the demos, in the meeting minutes and was easily accessible.

I don’t know why people think they need to provide dire warnings. It’s not clear what effect they want to create. Dire warnings make even less sense when the team uses agile and provides interim value and demos.

If you’re using agile approaches, and you see this happening, decide what you want from this relationship. If you think you’ll have to work with this person again and again, it might make sense to have a conversation and see what they really want. What are their concerns? What are their pressures? Can you help them with information at other times instead of a week before the end of the project?

Don’t be surprised if you see this kind of a culture clash in your organization as teams start their transformation. Managers have a lot to do with culture (you might say they are the holders of the culture) and we’re asking them to use different measurements and act differently. A huge change. (Yes, after the agile project book, I’m writing an agile management book. I know, you’re not surprised.)

Categories: Project Management

Team Size Matters, Reprise

Thu, 04/13/2017 - 17:47

Several years ago, I wrote a post for a different blog called “Why Team Size Matters.” That post is long gone. I explained that the number of communication paths in the team does not increase linearly as the team size increases;  team communication paths square when the team increases linearly. Here is the calculation where N is the number of people on the team: Communication Paths=(N*N-N)/2. 

  • 4 people, (16-4)/2=6
  • 5 people, (25-5)/2=10
  • 6 people, (36-6)/2=15
  • 7 people, (49-7)/2=21
  • 8 people, (56-8)/2=24
  • 9 people, (81-9)/2=36
  • 10 people (100-10)/2=45

Here’s why the number of communication paths matter: we need to be able to depend on our team members to deliver. Often, that means we need to understand how they work. The more communication paths, the more the team might have trouble understanding who is doing what and when.

When team members pair, swarm, or mob, they have frequent interconnection points. By working together, they reduce the number of necessary communication paths. Maybe you can have a larger team if the team mobs. (I bet you don’t need a larger team then

Categories: Project Management