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!
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.
One of the questions I hear all the time with people transitioning to using agile is this: How do we organize the project if we don’t have a project manager?
If you read Manage It!, you know I don’t buy the idea of a controlling project manager. But a facilitative project manager? Oh my. That is a horse of a different color.
In organizations where plan-driven approaches have reigned supreme, managers think about managing people, not projects. Nope, managers exist to create the environment in which people can do great work. Project managers might even be quite helpful. I have talked before about when I am the “wall around the team, protecting the team from management mayhem.”
Here is a list of what an agile project manager might do:
Assist the team in managing the team‚Äôs risks. This can be many different things:
There may well be more PM functions. (If you know of any, please comment. Thanks.)
Project managers who act as servant leaders fulfill useful functions.¬†Project managers can be especially helpful if managers don’t understand the difference between resource efficiency and flow efficiency.
Controlling project managers? Not so much.
In part 2, I’ll describe what agile PMs do not do.
If you’ve been watching my writing (and speaking), you’ve noticed that I like both agile and lean. I like the cadence of milestones and demos that iteration-based agile provides. I like the limiting of work in progress and seeing the whole that lean provides. For me, both are necessary to deliver value.
You might have noticed that I’m big on delivering value, too. I see this in my work, in my clients’ work, and in the way people have trouble when they don’t deliver value.
In my Practical Product Ownership workshop, I’ve been talking about rolling wave deliverable planning, and how to see value every day or so. I have an¬†agile and lean project workshop that I’ve evolved as I teach it. My clients have found ¬†it quite valuable.
If you read Agile and Lean Program Management, you saw that I used the principles of ¬†both agile and lean to help “scale” larger efforts.
I’m delivering a one-day version of the agile and lean workshop at PNSQC in October. See Experience Agile and Lean to Deliver Business Value. If you are curious about how to make your projects discover and deliver the promise of agile or lean, please join me.
I’m also writing a book about this. I don’t have a good title yet. Andy told me my proposed title was boring. If you have a good title that combines agile and lean for delivering value and creating successful outcomes, please let me know. If you would like to be a reviewer for this book, let me know that too.
In the meantime, look for more posts about combining agile and lean to deliver value. And, please join me at PNSQC. It will be an experiential workshop where you learn by doing. It will be fun!
As I’m teaching my Practical Product Owner workshop, some POs are having trouble understanding how big a defect is. Sure, they want to have small(er) stories, but a defect isn’t done until it’s all fixed, and the team has decided if they need automated regression tests added to the smoke tests.
So, here are three possibilities for sizing defects:
Here’s what you get when ¬†you use these possibilities:¬†No one works alone. And, the team has some idea of value (either estimate or finished work) at the end of one day.
One thing I’ve noticed about defects, especially those from legacy products, is that they are often more complex than they seem. When people work together, regardless of how they work together, they can review those complexity risks as they proceed.
IF team members work together to pair or swarm or mob to fix the problem, great. If the team members work together to assess the defect size, they start to think about possibilities and risks.
I don’t know if this will work for you. It might. Let me know what you think or how you have tried to size defects. In effect, we always timebox initial defect fixing to one day, and the only difference is how we do it.
The problem I’m addressing is defect fixing that is unknowable and takes forever.