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!
Software Development Blogs: Programming, Software Testing, Agile Project Management
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!
A couple of weeks ago, I spoke locally about Manage Your Project Portfolio. Part of the talk is about understanding when you need project portfolio management and flowing work through teams.
One of the (very sharp) fellows in the audience asked this question:
As you grow, don’t you need component teams?
I thought that was a fascinating question. As agile organizations grow, they realize the value of cross-functional teams. They staff for these cross-functional teams. And, then they have a little problem. They can’t find enough UX/UI people. Or, they can’t find enough database people. Or, enough writers. Or some other necessary role for the “next” team. They have a team without necessary expertise.
If managers allow this, they have a problem: They think the team is fully staffed, and it’s not. They think they have a cross-functional team that represents some capacity. Nope.
Some organizations¬†attempt to work around the scarce-expertise problem. They have “visitors” to a team, filling in where the team doesn’t have that capability.
When you do that, you flow work through a not-complete team. You’re still flowing work, but the team itself can’t do the work.
You start that, and sooner or later, the visitor is visiting two, three, four, and more teams. One of my clients has¬†12 UI people for 200 teams. Yes, they often have iterations where every single team needs a UI person. Every single team. (Everyone is frustrated: the teams, the UI people, and management.)
When you have component teams and visitors, you can’t understand your capacity. You think you have capacity in all those teams, but they’re component teams. They can only go as fast as the entire team, including the person with the scarce expertise, can deliver features. When your team is not first in line for that scarce person, you have a Cost of Delay. You’re either multitasking or waiting for another person. Or, you’re waiting for an expert. (See CoD Due to Multitasking and CoD Due to Other Teams Delay. Also See Diving for Hidden Treasures.)
What can you do?
Here’s the problem. When you allow teams to compete for scarcity (here, it’s a UI person), you don’t get the flow of work through the teams. Everything is slower. You have an increased Cost of Delay on everything.
Visualizing the work helps.
Flowing the work through the constrained people will show you your real capacity.
Needing component teams is a sign someone is still thinking in resource efficiency, not flow efficiency. And, I bet some of you will tell me it’s not possible to hire new people with that skill set locally. I believe you.
If you can’t hire, you have several choices:
I am not a fan of component teams. You could tell, right? Component teams and visitors slow the flow of releasable features. This is an agile management problem, not just a team problem. The teams feel the problem, but management can fix it.
I just read¬†Zappos is struggling with Holacracy because humans aren‚Äôt designed to operate like software. I’m not surprised. That’s because we are humans who work with other human people. I want to talk with people when I want to talk with them, not when some protocol tells me I must.
It’s the same problem when managers talk about “resources” and “FTEs” (full-time equivalents). I don’t know about you. I work with resourceful humans. I work with people, regardless of how much time they work at work.
If the person I need isn’t there, I have some choices:
There are other options, but those are the options I see most often.
We each have unique skills and capabilities. I am not fond of experts working alone. And, I want to know with whom I can build trust, and who will build trust with me.
We build relationships with humans. (Okay, I do yell at my computer, but that’s a one-sided relationship.) We build relationships because we talk with each other:
When we talk with each other, we build relationships. We build trust. (Some of us prefer to talk with one person at a time, and some of us like to speak with more. But we talk together.) That discussion and trust-building allows us to work together.
This relationship-building is one of the problems of geographically distributed teams not feeling like teams. The feelings might be missing in a collocated team, too. Standups work because they are about micro-commitments to each other. (Not to the work, to each other as humans.)
I’m a Spock-kind of person, I admit. I work to build human relationships with colleagues. I work at these relationships because the results are worth it to me. Some of you might start with the people first, and you will build relationships because you like people. I’m okay with that
I have a new article up on projectmanagement.com,¬†Continuous Agile Program Planning: Think Big, Plan Small. It’s about how to use rolling wave planning especially for an agile program.
If you are a Product Owner or you are responsible for planning what when, and want to learn how to do this, join my PPO Workshop, starting next week.
I don’t know if you retrospect on a regular basis. I do. (I know, you are so surprised!)
Andy Kaufman asked me to share my biggest learning for his podcast. Take a listen to¬†The Most Important Lesson You Learned Last Year. I’m pleased and proud to be in such good company. Thanks, Andy!
Sometimes, that works quite well. You have deliverables, and everyone understands the order in which you need to deliver them. You use agile because you can receive feedback about the work as you proceed.
You might make small adjustments, and you manage to stay on track with the work. In fact, you often complete what you thought you could complete in a quarter. (Congratulations to you!)
I rarely meet teams like that.
Instead, I meet and work with teams who discover something in the first or second iteration that means the entire rest of the quarter is suspect. As they proceed through those first few features/deliverables, they, including the PO, realize they don’t know what they thought they knew. They discovered something important.
Sometimes, the managers in the organization realize they want this team to work on a different project sometime in the quarter. Or, they want the team to alternate features (in flow) or¬†projects (in iterations) so the managers can re-assess the project portfolio. Or, something occurs outside the organization and the managers need different deliverables.
If you’re like me, you then view all the planning you did for the rest of the quarter as waste. I don’t want to spend time planning for work I’m not going to do. I might need to know something about where the product is headed, but I don’t want to write stories or refine backlogs or even estimate work I’m not going to do.
If you are like me, we have alternatives if we use rolling wave, deliverable-based planning with decreased specific plans.
In this one-quarter roadmap example, you can see how the teams completed the first iteration. That completion changes the color from pink to white. Notice how the last month of the quarter is grayed out. That’s what we think will happen, and we’re not sure.
We only have specific plans for two iterations. As the team completes this iteration, the PO and the team will refine/plan for what goes into the 3 iteration from here (the end of the second month). As the team completes work, the PO (and the PO Value team) can reassess what should go into the last part of this quarter and the final month.
If you work in flow, it’s the same idea if you keep your demos on a cadence.
This is exactly what happened with a team I’m working with. They tried to plan for a quarter at a time. And, often, it was the PO who needed to change things partway through the quarter. Or, the PO Value team realized they did not have a perfect crystal ball and needed to change the order of the features partway through the quarter.
They tried to move to two-month horizons, and that didn’t help. They moved to one-month horizons, and almost always change the contents for the last half of the second month. In the example above, notice how the Text Transfer work moved to farther out, and the secure login work moved closer in.
You might have the same kind of problem. If so, don’t plan details for the quarter. Plan details as far out as you can see, and that might be only one or two iterations in duration. Then, take the principles of what you want (next part of the engine, or next part of search, or whatever it is that you need) and plan the details just in time.
Rolling wave deliverable-based planning works for agile. In fact, you might think it’s the way agile should work.
If you lie this approach to roadmapping, please join my Practical Product Owner workshop. All the details are on that page.
I’m teaching a Product Owner workshop this week, and I had an insight about a Minimum Viable Product.
AN MVP has to fulfill these criteria:
My insight came when I was discussing with the class how their data moves through their system. Think of data like an onion: there is an inside kernel and concentric rings around the inside. (If you prefer, a cut-down tree, but I like the onion.) Often, you start with that inside and¬†small (round) piece of value. You then add layers around it, every time you do another MVP (or Experiment, if you’re prototyping).
The data has to do a round trip. That’s why I thought of it in circles like an onion. If you only implement half (or some other part) of the entire round trip, you don’t have the entire circle of minimum functionality.
This image on the left, where you see the feature go through the architectural layers might be a better image.
The actions that the user—whomever the user is—has to go into the system and come out. In an MVP, you might not have a very thin slice all by itself, but it still needs to be a thin slice.
When I think about the idea of the onion, I think, “What is the smallest piece I can define so we can see some results?” That’s the idea of the MVP.
I realize that MVPs might be useful for the team to learn about something in a small test environment. And, the smaller chunk of value you deliver, the more experiments you can run, and the faster you can learn. Maybe the idea of the onion, or the round trip through the feature will help you think about your MVPs.
BTW, I still have room in my online Product Ownership workshop that starts in January. Please join us.
The more I work with project portfolio teams and program managers, the more I understand one thing: Cost accounting makes little sense in the small for agile, maybe for all knowledge work. I should say that I often see cost accounting in the form of activity-based accounting. Each function contributes to some of the cost of the thing you’re producing.
Here’s why. Cost accounting is about breaking down a thing into its component parts, costing all of them, and then adding up the costs as you build it. Cost accounting makes sense for manufacturing, where you build the same thing over and over. Taking costs out of components makes sense. Taking costs out of the systems you use to create the product makes sense, too.
Cost accounting makes some sense for construction¬†because the value is in the finished road or building. Yes, there is certainly knowledge work in parts of construction, but the value is in the final finished deliverable.
Software is neither construction nor manufacturing. Software is learning, where we deliver learning as pieces of finished product. When we have finished learning enough for now, we stop working on the deliverable.
Agile allows us to deliver pieces of value as we proceed. Other life cycles, such as incremental life cycles or even releasing your product in short waterfalls allows us to see value as we proceed before the whole darn thing is “done.”
We might need to know about costs as we proceed. That’s why we can calculate the run rate for a team and see how our feature throughput is working. If we start looking at feature throughput and the cost per feature, we can put pressure on ourselves to reduce the size of each feature. That would reduce the cost per feature. Smaller features allows us to learn faster and see value faster.
Cost accounting has a big problem. It does not account for Cost of Delay, which is a huge cost in many organizations. (See Diving for Hidden Treasures: Uncovering the Cost of Delay in Your Project Portfolio to read all about Cost of Delay.)
This is one of the reasons I like feature sizes of one day or less. You count features for throughput and use run rate as a way to estimate cost.
I don’t know enough about accounting to say more. As I learn with my clients¬†and especially learn about the pressures on them, I’ll post more. I do know this: the more we talk about the cost of a feature without talking about its value, the less we understand about how our software can help us. The more we talk about velocity instead of feature throughput, the less we know about what it really costs for us to develop our software.
Cost accounting is about surrogate measures (earned value, the cost of tasks, etc.) instead of valuing the whole. Agile gives us a way to see and use value on a daily basis. It’s opposed to the way cost accounting works. Cost accounting is a problem. Not insurmountable, but a problem nevertheless.
There are alternatives to cost accounting: throughput accounting and lean accounting. To use those ideas, you need to enlist the finance people in an agile transformation. As always, it depends on your goals.
I have enough people in the Writing Workshop 1: Write Non-Fiction to Enhance Your Business and Reputation to add a second section. You are right for this workshop if:
If a blank piece of paper scares you, this is the right workshop for you.
If you are an experienced writer and want to bring your skills to the next level, you want Writing Workshop 2: Secrets of Successful Non-Fiction Writers.
If you’re not sure which workshop is right for you, email me.¬†I can help you decide.
Oh, and if you’re a product owner, please do consider my Practical Product Owner workshop. I still have room in that workshop.
The early bird registration ends December 16,¬†2017. If I fill both sections earlier, I will stop registration then.
If you’re thinking about agile or trying to use it, you probably started with iterations in some form. You tried (and might be still trying) to estimate what you can fit into an iteration. That’s called “pushing” work, where you commit to some number of items of work in advance.
And, if you have to service interruptions, such as support on previous projects, or support the production server, or help another project, you might find that you can’t “push” very well. ¬†You have trouble predicting what you can do every two weeks. While the iteration duration is predictable, what you predict for the content of your iterations is not predictable. ¬†And, if you try to have longer iterations, they are even less predictable.
On the other hand, you might try “pull” agile, where you set up a kanban board, visualize your flow of value, and see where you have capacity¬†in your team and where you don’t. Flow doesn’t have the built-in notion of project/work cadence. On the other hand, it’s great for visualizing all the work and seeing where you have bottlenecks.
Iterations provide a cadence for replanning, demos, and retrospectives. That cadence, that project rhythm, helps to set everyone’s expectations about what a team can deliver and when.
Kanban provides the team a perspective on where the work is, and if the team measures it, the delays between stages of work. Kanban helps a team see its bottlenecks.
Here are some options you might consider:
Teams who use only iterations may not know the workflow they really have, or if they have more project or support/interrupting work. Adding an urgent queue might help everyone see the work. And, more explicit columns for analysis, dev & unit test, testing, waiting (as possibilities) in addition to the urgent queue might help the team see where they spend time.
Some teams try to work in two-week (or longer) iterations, but the organization needs more frequent change. Kanban might help visualize this, and allow the team to change what they commit to.
Some POs don’t realize they need to ask questions about value for all the work coming into a team. If the work bypasses a PO, that’s a problem. If the PO does not rank the work, that’s a problem. And, if the team can’t finish anything in a one-week iteration, that’s a sign of interdependencies or stories that are too large for a team. (There might be other problems. Those are the symptoms I see most often.
You can add a kanban board inside your iteration approach to agile. You might consider moving to flow entirely with specific dates for project cadence. For example, you might say, “We do demos every month on the 5th and the 19th of the month.” That would provide a cadence for your project.
You have choices about pushing work or pulling work (or both) for your project. Consider which will provide you most value.
P.S. If you or your PO has trouble making smaller stories, consider my workshop, Practical Product Ownership.
You might have noticed I have not written as much in this blog for the past couple of months as I normally do. That’s because I’ve been involved in another writing project that’s taken a ton of my time.
I’m part of the writing team for the Agile Practice Guide. The Guide is a joint venture between the Agile Alliance and the PMI. See Bridging Mindsets: Creating the Agile Practice Guide.
We work in timeboxes, iterating and incrementing over the topics in the guide. We sometimes pair-write, although we more often write and review each other’s work as a pair.
If you would like to review the guide as a subject matter expert, send me an email.¬†You’ll have about a month to review the guide, starting in approximately January 2017. I am not sure of the dates yet, because I am not sure if we will finish all our writing when we originally thought. Yes, our project has risks!
What do the words iterative and incremental mean?
Iterative means we¬†take a one-piece-at-a-time for creating an entire feature. Iterative approaches manage the technical risk. We learn¬†about the risk as we iterate through the entire feature set.
Incremental means we deliver those pieces of value. Incremental approaches manage the schedule risk, because we deliver finished work.
Agile works because we manage both technical and schedule risk. We iterate over a feature set, delivering chunks of value. (One reason to deliver value often is so we can change what the¬†team does next.)
Here’s a way to think about this if I use a feature set called “secure login.” Now, no one wants to log in. But, people want to have security for payment. So secure login might be a way to get to secure payment. The theme, or what I have been calling a feature set, is “Secure login.” A feature set is several related features that deliver a theme.
If you want to iterate on the feature set, you might deliver these valuable increments (I first wrote about this in How to Use Continuous Planning):
If you implement the first story, you can use a flat file. You can still use a flat file for the second story. Once you start to add¬†more than 10 users, you might want to move to some sort of database. That would be a story. It’s not “Create a database.” The story is “Explore options for how to add 10, 100, 1000, 10000 users to our site so we can see what the performance and reliability implications are.”
Notice the explore as part of the story. That would lead to a spike to generate options that the team can discuss with the PO. Some options have performance implications.
Every time the team iterates over the feature set, they deliver an increment. Since many teams use timeboxes, they use “iterations” as the timebox. (If you use Scrum, you use sprints.) Notice the term “iterate over the feature set.”
In incremental life cycles, such as staged delivery, the team would finish all the features in the one feature set. Incremental life cycles did not necessarily use timeboxes to timebox the incremental development. In iterative life cycles, such as spiral or RUP, the team would develop prototypes of features, or even partially finish features, but the final integration and test occurs after all the iterative development was done.
In agile, we iterate over a feature set, delivering incremental value. If you don’t finish your stories, you’re in an iterative life cycle. If you don’t limit the features you finish and finish “all” of them, you are in an incremental life cycle.
There is No One Right Way to select a life cycle for your project. If you want to use agile, you iterate over a feature set in a short time, delivering chunks of value.
If you are having trouble slicing your stories so you can create feature sets, see my Product Owner Workshop (starting in January). Super early bird expires this coming Friday.
If you are thinking about writing more or better for next year, take a look at my writing workshops.
I am offering Writing Workshop 1: Write Non-Fiction to Enhance Your Business and Reputation again, so you can learn how to create a daily writing habit, write in small chunks, and start to publish.
I am offering a new writing workshop for people who want to publish more (and be paid for their writing): Writing Workshop 2: Secrets of Successful Non-Fiction Writers.
Take Workshop 1 if you are unsure of your writing. It’s a terrific overview and will help you start with a regular writing habit.
Take Workshop 2 if you are ready to take your writing to the next level. This workshop is about getting paid for your writing, and publishing more often and broadly.
If you’re not sure which workshop is right for you, email me and we can¬†discuss what would work for you.
Super early bird registration ends November 18, 2016 for Workshop 1.¬†Super early bird registration ends November 25, 2016 for Workshop 2.
If you are thinking of writing “more” in 2017, commit now. Make it happen for you.
Today he tweeted this: “How do you optimize for features? That’s flow efficiency.” Yes, I said that.
There were several Twitter rants about the use of the word “efficiency.” Okay. I can understand that. I don’t try to be efficient as much as I try to be effective.
However, I’ve discussed the ideas of resource efficiency and flow efficiency in several places:
And more. Take a look at the flow efficiency tag on my site.
Here’s the problem with the word, “efficiency.” It’s already in the management¬†lexicon. We can’t stop people from using it. However, we can help them differentiate between resource efficiency (where you optimize for a person), and flow efficiency (where you optimize for features). One of the folks discussing this in the hashtag said he optimized for learning, not speed of features. That’s fine.
Flow efficiency optimizes for moving work through the team. If the work you want is learning, terrific. If the work you want is a finished feature, no problem. Both these require the flow through the team—flow efficiency—and not optimization for a given person.
I’ve mentioned this book before, but I’ll suggest it again. Please take a look at this book: This is Lean: Resolving the Efficiency Paradox.
If I want to change management, I need to speak their language. Right now, “efficiency” is part of their language. I want to move that discussion to helping them realize there is a difference between resource efficiency and flow efficiency.
I hope you decide to join us on the chat (which is about hiring for DevOps). I will be typing as fast as my fingers will go
I started this series writing about the need for coaches in¬†Coaches, Managers, Collaboration and Agile, Part 1. I continued in¬†Coaches, Managers, Collaboration and Agile, Part 2, talking about the changed role of managers in agile. In this part, let me address the role of senior managers in agile and how coaches might help.
For years, we have organized our people into silos. That meant we had middle managers who (with any luck) understood the function (testing or development) and/or the problem domain (think about the major chunks of your product such as Search, Admin, Diagnostics, the feature sets). I often saw technical organizations organized into product areas with directors at the top, and some functional directors such as those test/quality and/or performance.
In addition to the idea of functional and domain silos, some people think of testing or technical writing as services. I don’t think that way. To me, it’s not a product unless you can release it. You can’t release a product without having an idea of what the testers have discovered and, if you need it, user documentation for the users.
I don’t think about systems development. I think about product development. That means there are no “service” functions, such as test. We need cross-functional teams to deliver a¬†releasable product. But, that’s not how we have historically organized the people.
When an organization wants to use agile, coaches, trainers, and consultants all say, “Please create cross-functional teams.” What are the middle managers supposed to do? Their identity is about their function or their domain. In addition, they probably have MBOs (Management By Objective) for their function or domain. Aside from not working and further reducing flow efficiency, now we have affected their compensation. Now we have the container problem I mentioned in Part 2.
Middle and senior managers need to see that functional silos don’t work. Even silos by part of product don’t work. Their compensation has to change. And, they don’t get to tell people what to do anymore.
Coaches can help middle managers see what the possibilities are, for the work they need to do and how to muddle through a cultural transition.
Instead of having managers tell people directly what to do, we need senior management to update the strategy and manage the project portfolio so we optimize the throughput of a team, not a person. (See Resource Management is the Wrong Idea; Manage Your Project Portfolio Instead and Resource Efficiency vs. Flow Efficiency.)
The middle managers need coaching and a way to see what their jobs are in an agile organization. The middle managers and the senior managers need to understand how to organize themselves and how their compensation will change as a result of an agile transformation.
In an agile organization, the middle managers will need to collaborate more. Their collaboration includes: helping the teams hire, creating communities of practice, providing feedback and meta-feedback, coaching and meta-coaching, helping the teams manage the team health, and most importantly, removing team impediments.
Teams can remove their local impediments. However, managers often control or manage the environment in which the teams work. Here’s an example. Back when I was a manager, I had to provide a written review to each person once a year. Since I met with every person each week or two, it was easy for me to do this. And, when I met with people less often, I discovered they took initiative to solve problems I didn’t know existed. (I was thrilled.)
I had to have HR “approve” these reviews before I could discuss them with the team member. One not-so-experienced HR person read one of my reviews and returned it to me. “This person did not accomplish their goals. You can’t give them that high a ranking.”
I explained that the person had finished more valuable work. And, HR didn’t have a way to update goals in the middle of a year. “Do you really want me to rank this person lower because they did more valuable work than we had planned for?”
That’s the kind of obstacle managers need to remove. Ranking people is an obstacle, as well as having yearly goals. If we want to be able to change, the goals can’t be about projects.
We don’t need to remove HR, although their jobs must change. No, I mean the HR systems are an impediment. This is not a one-conversation-and-done impediment. HR has systems for a reason. How can the managers help HR to become more agile? That’s a big job and requires a management team who can collaborate to help HR understand. That’s just one example. Coaches can help the managers have the conversations.
As for senior management, they need to spend time¬†developing and updating the strategy. Yes, I’m fond of continuous strategy update, as well as continuous planning and continuous project portfolio management.
I coach senior managers on this all the time.
Let me circle back around to the question in Part 1: Do we have evidence we need coaches? No.
On the other hand, here are some questions you might ask yourself to see if you need coaches for management:
If the¬†answers are all yes, you probably don’t need management coaching for your agile transformation. If the answers are no, consider coaching.
When I want to change the way I work and the kind of work I do, I take classes and often use some form of coaching. I’m not talking about full-time in person coaching. Often, that’s not necessary. But, guided learning? Helping to see more options? Yes, that kind of helping works. That might be part of coaching.
In¬†Coaches, Managers, Collaboration and Agile, Part 1, I wrote about circumstances under which a team might want a coach. It wasn’t an exhaustive list. It had several questions defining when coaches might help the team¬†to become agile, not be cargo cult agile.
One of the reasons we might need coaches for a team is because of the changed manager role in agile.
In functional organizations, managers coached the team members on how to do their jobs better. (Okay, some managers did.) Development managers coached developers. Test managers coached testers. Project manager-managers coached project managers, etc. Each functional manager coached the people in their functions on how to do their functions better.
Some managers learned how to coach the functional people to perform better in teams. To be honest, that was often quite difficult. The organization rewarded the function, not the teamwork.
Agile is changing this mindset of “coach the function, let the teamwork take care of itself.” (Yes, that’s a generalization, and not fair. However, I see a lot of it.)
In agile, we want a product as a result of team effort. That leads us to think about the role of managers and teams and coaching in different ways. (Well, it does for me.)
If you are not aware of Human Systems Dynamics, let me introduce you to the ideas of Containers, Differences, and Exchanges. I read about this in¬†Adaptive Action: Leveraging Uncertainty in Your Organization.
When people and projects choose agile, the managers have new and different roles. ¬†People no longer affiliate with managers (the container part). They affiliate with projects. This means that manager-as-coach changes in any number of ways.
Instead of being able to, or even having the time, to coach people on their functional roles, the manager might create communities of practice, or other ways of encouraging people to learn about their role better. If the manager knows about the function, the manager can coach the people.
And, many managers only know about or have experience in their own functions, such as strictly development or testing or writing. I call these managers “ignorant.” That’s because unless a manager can see the entire picture (including the dynamics of a project, the manager might not realize the problem with the impediments the team faces.
Ignorant managers cannot create the environment in which a team can deliver working product. Yes, the team has responsibility for a significant part of that environment, especially working as a team to move features across the board. And, the manager creates the container in which the team works.
I’ve seen ignorant managers create these problems for the team:
You might see other problems in your organization.¬†An ignorant manager cannot help the team or the team members at all, because the ignorant manager does not realize the problems these impediments cause.
The agile manager’s role changes, especially managers who “manage” technical teams. I wrote about this years ago in Agile Managers: The Essence of Leadership.
Agile managers help facilitate the environment for the team (possibly along with an agile project manager/Scrum Master or a program manager). They are servant leaders. They provide coaching and feedback and meta coaching and meta feedback. The manager’s role is about facilitating what the team members can deliver, to the team, to the product, and to themselves. It’s about inspect and adapt for team members.
That’s where we encounter the affiliation problem. Who do we want the team members to identify with? With the functional manager—who with good intentions—ask a team member to do work not on the board? Or, do we want team members to identify with the team? I vote for the team. (I vote for the team regardless of the approach, agile or otherwise.)
Managers might need coaches so they learn about what the team members do. Then, managers can provide feedback and coaching and meta feedback and meta coaching as someone who can see from the outside of the team. Managers can learn what the impediments are for agile (too-long duration commitments, resource vs. flow efficiency, HR and finance issues). Managers can help lead the organization’s agile approach.
And, many managers need coaching to do this: agile coaching and how the functions work in an agile team. That’s because we want managers to be the best managers they can be to help the organization move to agile.
When managers change what they do, they might need coaching to learn how, and to get the feedback to see the possibilities of their decisions. Management coaching is not about weakness. It’s about the realization that if we want to change culture, we change behavior. Not just team behavior. Management behavior is a key part of the agile transformation.
In part 3, I’ll address coaching and collaboration for middle and senior managers.
There was a fascinating Twitter conversation last week when I was busy writing other things. (I also find Twitter to be a difficult-for-me arena to have a conversation. I need more than 140 characters.)
The conversation started when Neil Killick tweeted this:
orgs need coaches not because “agile is unintuitive”, but because effective sw delivery is a team game requiring folks at their best.
I liked that and retweeted it.
Mohinder Khosla asked (quite reasonably, in my opinion):
Do we have stats that this is real? Just saying
Mohinder, I am sure we do not have stats. We rarely do what I would categorize as real research in how software product development works. That’s because we continually learn and even if we start a new project with exactly the same people, we have learned to work together in previous projects. If we don’t keep teams together, we have to relearn how to work together. (See Hackman’s Leading Teams book for this and much more insight on teams.)
Agile challenges all of our previous assumptions about how software product development works.
One of the big changes in agile is that we work as a team. We work as a team to move work across the board. We don’t hand off work from developers to testers. We don’t hand off work from architects to developers. We don’t hand off work from testers to operations.
Can each team do that now? Probably not the first time they try to use agile. This notion of the cross-functional team being the team in question challenges everything we, our managers, and our organizations “know” about product development.
Coaches can help teams and managers learn what it’s like to create the agile mindset and an agile culture. Do you need a coach? Maybe not. Here are some questions I have asked my clients when they asked whether a coach would be useful for them:
Notice that these questions are about team collaboration and delivery.
Agile creates transparency. We can see when a team is not “performing.” I put that in quotes because often the environment is what causes teams to not “perform.”
Some teams have trouble working as a team. Coaches can help. Other teams cannot answer yes to my four questions. If so, coaches can help the team and the managers. Can the organization help itself? Of course. Would it be easier with a coach? Probably.
You don’t need agile coaches to be successful. You can do it yourself. And, if you look at people and teams who fit your definition of success, they will often tell you they have coaches. (I do.)
Agile teams deliver working product on a regular, frequent cadence. They can use flow-based agile or iteration-based agile to do so. It doesn’t matter.
When teams deliver on a regular basis, they work as a collaborative team. That idea and practice might be quite new to everyone in the organization. Coaches might help.
The next post will be the role of managers in coaching in an agile environment.
In¬†What Agile Project Managers Do, Part 1, I described what facilitative agile project managers do. In What Agile Project Managers Do Not Do, Part 2, I described a number of roles a more traditional project manager might think is their job still, even if they are supposed to be/use agile.
Sometimes, people get confused with what they should facilitate and what not to do. That’s because their role has changed. The agile project manager facilitates work that the team decides how to do. The product owner (a new role in agile) decides what to do and the ranking of the work for the team to deliver.
These changes lead to problems in expectations and in how the team works.
I’ve seen expectation problems in these ways:
When the POs don’t understand their roles, the agile project manager can help the PO understand what to do and how to treat the team. See my PO series. The summary post is¬†Product Owners and Learning, Part 5.
I’ve also seen team problems, such as experts taking a story (or, even estimating “their” stories and taking “their” stories).
In teams that don’t (yet) understand flow efficiency and still use the ideas of resource efficiency, the PO might even encourage individual experts to take their own “stories.” (These things are often tasks, not stories.) The PO wants the feature done, in the most productive and efficient manner. The PO might encourage team members to take their own stories. Or, the PO might demand that.
Here’s the thing: everyone wants to produce features and finish work in the most effective manner. If the agile project manager understands the ideas behind flow efficiency, the agile project manager might say or do any of these things:
If you are an agile project manager, you might say or do totally different things. I have tried all of these, with different teams. I have had varying results. If people are open to hearing about flow efficiency, we can make progress. Sometimes, people feel such stress, they cannot imagine another way to work. That means I have had to work at a different level to understand why people felt that stress.
What about when someone wants the team to deliver some feature(s) by a certain date? That’s all in the PO’s purview. All of it. What happens if the PO is not strong enough to stand up to the pressure. That’s where the agile project manager can help the PO by:
An agile project manager performs different work than a command-and-control project manager. The agile project manager focuses on systemic obstacles for the team and the flow of work. It’s not easy!
In What Agile Project Managers Do, Part 1, I spoke about what agile project managers might do. Here’s what agile project managers do not do:
For many new-to-agile teams, this is a huge change. In plan-driven approaches, such as waterfall or phase-gate life cycles, there is no such role as the Product Owner. In the plan-driven approaches, the project manager assesses the requirements and decides what features/requirements/whatever, the team should do first, second, third, and so on. The project manager decides on the deliverables and performs rolling-wave planning¬†if the project manager understands about deliverable-based planning.
In agile, the product owner performs rolling wave deliverable-based planning. The PO decides which features (deliverables) the team needs to implement now, and what rank they are.The PO decides when to replan. The agile project manager might assist/suggest/facilitate, but the deliverable-based planning is the PO’s job.
These changes have several implications:
This can be a very large change for more traditional project managers, who were accustomed to making their deliverable-based rolling wave plan work. (Yes, you could make a waterfall project work with deliverable-based rolling wave planning. It was much more difficult¬†but possible.) Some project managers have a difficult time reconciling their role to be one of servant leader, facilitating the team’s work rather than directing in.
I will post about how the product owner and agile project manager might work together in part 3.