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!
My most recent post about how to¬†Visualize Your Work So You Can Say No showing a couple of different kanbans was quite popular. Several people ask me how I use my personal kanban.
I use paper. Here’s why I don’t use a tool:
This is what my board looks like this week. it might look like this for a while because I’m trying to finish a book. (I have several more books planned, so yes, I will have a bunch of work “in progress” for the next several months/rest of the year.)
I have several chapters in This Week. I have two chapters in “Today:” That helps me focus on the work I want to finish this week and today.¬†As a technical editor for agileconnection.com and as a shepherd for XP 2017, I have work in “Waiting to Discuss.” I¬†will discuss other people’s writing.
Earlier this week, I had interactions with a potential client, so that work is now in Waiting for Feedback. Sometimes, I have book chapters there, if I need to discuss what the heck goes in there and doesn’t go in a chapter.
I haven’t finished much yet this week. I am quite close on two chapters, which I expect to finish today. My acceptance criteria is ready for my editor to read. I do not expect them to be done as in publishable. I’ll do that after I receive editorial feedback.
Could I do this on an electronic board? Of course.
However, I limit my WIP by staying with paper. I can’t add any more to the paper.
Should I have WIP limits? Maybe. If I worked on a project, I would definitely have WIP limits. However, the fact that I use paper limits what I can add to my board. If I notice I have work building up in any of the Waiting columns, I can ask myself: What can I do to move those puppies to Done before I take something off the Today or To Do columns?
I’ve been using personal kanban inside one-week iterations since I read Benson’s and Barry’s book, Personal Kanban.¬†(See my book review,¬†Book Review: Personal Kanban: Mapping Work | Navigating Life.
You should use whatever you want as a tool. Me, I’m sticking with paper for now. I don’t measure my cycle time or lead time, which are good reasons to use an electronic board. I also don’t measure my cumulative flow, which is another reason to use a board.
I do recommend that until you know what your flow is, you use paper. And, if you realize you need to change your flow, return to paper until you really understand your flow. You don’t need a gazillion columns, which is easy to do in a tool. Use the fewest number of columns that help you achieve control over your work nad provide you the information you need.
Question for you: Do you want to see a parking lot board? I have images of these in Manage Your Project Portfolio, but you might want to see my parking lot board. Let me know.
Most people I know—even the people supposedly using agile—have too much work to do. You have project work. You have support work, formal for customer support or sales, and informal for your colleagues. You have reports to write or file, time cards to fill out, or other periodic events.
You need a way to say no to more work.
I wrote an article for Better Software, which is now online. See Saying No to More Work. (You need to register for the site to see the article. No charge for registration.)
One person wanted to see the kanban boards I referred to in the article. I am happy to show them to you here.
These are two potential kanban boards. The one on the left is the basic personal kanban board. Note that there are no WIP (Work in Progress) limits (yet) on this board. I would add WIP limits. Especially if I wanted to convince my manager I was doing too much work.
On the right, ¬†you can see a disaster of a personal kanban board. There are many items To Do, three in Progress and a total of six stuck in various Waiting states. Yes, I had a board that looked like this many years ago. Then, I made a picture on a piece of paper and explained to my boss I was just one person. What did he want me to do and not do?
Now, given what I know, I would add WIP limits to each column.
If you want to see the project portfolio images for how I start at the organization level: the calendar view and kanban view, see¬†Manage Your Project Portfolio at the Prags. At the end of the blurb, there’s a link to the quick start guide, which has just two of the images in the book. (I included many possible ways to visualize the project portfolio in this edition of the book.)
Here’s the key idea: Don’t take on more work than you can complete in a reasonable amount of time. Don’t multitask. Instead, see what your work is and how you might discuss it with your manager.
I’m almost at the end of the January Practical Product Owner workshop. One of the participants has a problem I’ve seen before. They have a backlog of work, and it’s all tasks. Not a story in sight.
I understand how that happens. Here are some ways I’ve seen the tasks-not-stories problem occur:
Here’s a gotcha: When teams measure story points as opposed to features, they often feel pressure from management to do more points. (See Who’s Playing Agile Schedule Games?)
Your customers don’t buy points. They buy completed features.
Something clicked for the participant last week. He saw the feature chart, which explains how scope expands during the project and what the team(s) delivers.
This chart shows the features complete, added, and remaining to do. Because it measures features—what customers buy and use—there’s no confusion about work done or not done. Plenty of work might be done. But, if the work doesn’t add to a feature, the work is inventory (or possibly waste).
Here’s one value of this chart: Until tasks add up to features, you don’t count them.
My participant couldn’t articulate the problems before. The chart helped him see and discuss:
The chart helped him see how to separate stories and count them. He is moving from tasks and technical stories to features, real user stories.
I use this chart with cumulative flow diagrams and the product backlog burnup chart to see where our work is and how much progress we make over time for a given feature set.
I recommend you build and count features (stories). The smaller you can make a story, the faster you can get feedback and see the value in it.
If you’re interested in this workshop, I have just announced the May 2017 dates. See Practical Product Owner Workshop: Deliver What Your Customers Value and Need.
Is your agile transition proceeding well? Or, is it stuck in places? Maybe the teams aren‚Äôt improving. Maybe no one knows “how to get it all done.” Maybe you’re tired and don‚Äôt know how you‚Äôll find the energy to continue. Or, ¬†you can’t understand how to engage your management or their management in creating an agile culture?
You are the kind of person who would benefit from the Influential Agile Leader event in¬†Toronto,¬†May 9-10, 2017.
Gil Broza and I co-facilitate. It‚Äôs experiential, so you learn by doing. You practice your coaching and influence in the mornings. You‚Äôll have a chance to map your organizational dynamics to see where to put your energy. You‚Äôll split into smaller sessions in the afternoon, focusing on your specific business challenges.
If you would like to bring your agile transition to the next level, or, at the very least, unstick it, please join us.
We sold out of super early bird registration. Our early bird registration is still a steal.
If you have questions, please post a comment or email me. Hope to work with you at The¬†Influential Agile Leader.
I had a conversation with¬†Amitai Schleier last year. I told him how much I enjoyed Agile in 3 Minutes (the podcast). I learned something from each podcast.
He invited me to contribute one. Naturally, I chose management. My podcast, 34: Manage¬†is up. If you like the podcast, you should check out the book, too. See
If you like the podcast, you should check out the book, too. See Agile in Three Minutes.¬†In three minutes, I explain what agile managers do.
Teams can be agile, up to a point. If the managers are not ready to nurture the agile culture, agile won’t work. (See¬†When is Agile Wrong for You?)
I hope you enjoy it the podcast and the book.
In Manage Your Project Portfolio, I’m agnostic about who manages the project portfolio. I prefer that the managers responsible for the strategy make the project portfolio decisions. And, I recognize that the PMO often makes those decisions.
I am doing a series of webinars with TransparentChoice. The first one is live. See¬†How many ‚Äúpoints‚ÄĚ does your PMO score?¬†We spoke about how you might know if you need a project portfolio and the major measure of successful decisions:
It doesn’t matter how many projects you start. It matters how many you finish.
Hope you enjoy it!
When I talk about Minimum Viable Products or Minimum Viable Experiments, people often tell me that their minimum is several weeks (or months) long. They can’t possibly release anything without doing a ton of work.
I ask them questions, to see if they are talking about a Minimum Indispensable Feature Set or a Minimum Adoptable Feature Set instead of an MVE or an MVP. Often, they are.
Yes, it’s possible you need a number of stories to create an entire feature set before you release it to your entire customer base. And, that’s not an MVP or an MVE.
When I think about the Build-Measure-Learn loop and apply it to the idea of a Minimum Viable Experiment, I often discover these possibilities:
Here’s an example of how this affected a recent client. They have an embedded system. They thought that if the embedded part booted faster, they could find more applications for the system. In embedded software, speed is often a factor.
They chose one client, who had systems now. The Product Manager visited the client¬†and asked about other vertical applications within the organization. Did they have a need for something like this system?
Yes, they did. They were concerned about speed, not just boot speed, but application processing speed.
The Product Manager asked if they were willing to be part of an MVE. He explained that the team would watch how they implemented and used the embedded system. Yes, they would all sign non-disclosures. The client also had to know that the team might not actually implement for real what the experiment was.
The customer agreed. The team implemented four very small performance enhancements—only through the happy paths, no alternative/error paths—and visited the customer to see what would happen. It took the team three days to do this.
The team visited for one day to watch how the client’s engineers used the product.
They were astounded. Boot speed was irrelevant. One specific path through the processing was highly relevant. The other three were irrelevant for this specific customer.
This particular MVE was a little on the expensive side. It took a¬†team-week to develop, measure, and learn. There was some paperwork that both sides had to manage. If you have a different kind of product, it might take you less time.
And, look how inexpensive that week was. That week taught the team what one vertical product line needed and didn’t need. They managed to avoid all those “necessary” features. This client didn’t need them. It turned out a different kind of vertical needed two of them, and no one appears to need the remaining one.
The Product Manager was able to prune many of the ideas in the backlog for this vertical market. The Product Owner knew and (knew why) which features were more important and how to write stories and rank them.
That’s one¬†example of an MVE. Your experiments will probably look different. What’s key here is this question: What is the smallest thing you can measure that will provide you value so you can make a decision for the product?
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