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!
The Due Date doesn't mean the Do Date
If you have a Due date, you need the plan to show up on that date, with what is Due for the cost of that Due Item and have that Due Item be compliant with the attributes (effectiveness and performance) needed by those paying you.
I was asked to look at a correctiveÂ action plan this year, that had a list of deliverablesÂ that were supposed correct the root causes of the problemsÂ identifiedÂ as the reason the project was not performing as planned. The right two columnsÂ were the person performing the work and the DONE date.
A big smile came to my face.Â I see the real root cause of your troubles here.Â You don't know what Done looks like. That's the first immutable principle of project success.Â
Without knowing what Done looks like in units of measure meaningful to the decision makers, the project has little hope of success.
I love novels.
And I love lists.
What better way for me to spend some cold and rainy days near the end of the year 2016 making a list of the best novels ever written? I truly desired to know which novels I should read before I die, according to the opinions of experts and book lovers. So I started a project that took me (and my assistant) several weeks to complete. You can now download the results.
In other words, here is my Christmas gift for you:
THE ULTIMATE TOP 200 BEST NOVELS, EVER
(226 Books to Read Before You Die)
For your convenience, I have linked each title to its Amazon page. Each author is linked to the author’s Wikipedia page, and the publication year is linked to the book’s page on GoodReads.
I hope you enjoy reviewing this list as much as I enjoyed making it. If you find any errors or mistakes, or if you know a way to improve this list, please feel free to let me know.
20 Logical Fallacy Found in Agile and related topics
Those making the originalÂ assertion need to bring evidence. Without that evidence, those challenging the assertion have no need to bring evidence. For those making the assertation to ask for evidenceÂ as to why their conjecture is correct is theÂ Burden of Proof fallacy, which is common when the originalÂ conjecture has no basis in principle, fact, or experienceÂ - it's just a conjecture. All attemptsÂ by the originalÂ assertion author to invert this fallacy should be stronglyÂ rejected, since it shows a lack of understanding of who ideas are put forth and tested in the larger marketplace of ideas.Related articles Making Conjectures Without Testable Outcomes Are Estimates Really The Smell of Dysfunction? Why Guessing is not Estimating and Estimating is not Guessing Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management
The Standish Report is raising its head again in the Agile presentations I've seen recently at conferences. Forgetting for the moment all the past "criticisms" of Standish...
The numbers in the report are still being used by "agile thought leaders" to establish the basis for their proffered solutions. Forgetting even more that "agile" is a bottom-up software development solution. And that most of the issues with large IT programs are leadership at the senior executive level, externalities from the market place at large, and general inability to connect the dots between business strategy and business execution.
And of late by the #NoEstimates thought leader to further their unsubstantiated conjecture that decisions can be made while spending other people's money in the presence of uncertainty.
Further is the complete lack of transparency in the statistical numbers. But here an alternative on how to report IT project success.
The definitions of "needs attention" and "significant concerns" is provided in terms of mission suitability rather than simple - and simple-minded cost and schedule.
So it's time once more to move beyond the worn out red herrings and start to address how to Increase the Probability of Project Success with processes and tools beyond just applying Scrum to the development team.
Willian pointed out the bands for measuring success.Â http://it.usaspending.gov/faq-agenciesRelated articles Essential Reading List for Managing Other People's Money Three Increasingly Mature Views of Estimate Making in IT Projects I Think You'll Find It's a Bit More Complicated Than That
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.
I’ve been working with a company to revamp their bonus and incentive structure as part of the organization’s desire to become agile. No matter how well designed and executed an agile transition is, if incentives remain in place that encourage non-agile behavior, that’s how people will behave.
In “Succeeding with Agile,” I referred to this as organizational gravity. Unless enough of an organization’s culture is changed in becoming agile, organizational gravity pulls the organization right back to where it started.
Improperly aligned bonuses and incentives are some of the biggest sources of organizational gravity.Incentives and Bonuses Are Different
Before looking at how we can create proper bonuses and incentives, let me clarify the difference between a bonus and an incentive.
An incentive is a reward given to an individual or team for achieving a stated goal. An incentive is offered in advance and is meant to motivate behavior in predictable ways. When my youngest daughter was little, I told her that if she cleaned her room by 3:00 p.m., I would take her to see a movie. That was an incentive.
In contrast, a bonus is not stated in advance. Rather it is announced and given at the time something is accomplished. Again using my youngest daughter as an example, when she came home from school with a great grade on a test I knew she’d studied hard for, I told her we’d celebrate that accomplishment by getting ice cream. That was a bonus.
Incentives and bonuses are both rewards with the key difference being that an incentive is announced in advance whereas a bonus is announced on the spot.Some Troublesome Rewards
Bonuses and incentives can work against the goals of agile. For example, rewards that single out individual performers discourage teamwork. I’ve seen these in the form of “Programmer of the Year,” “Team Member of the Month,” “Most Valuable Contributor” and more.
Other types of rewards encourage suboptimizing behavior. Many of us have stories about testers who were rewarded based on the number of bugs they found. This type of reward led one tester I met to log over 200 entries into the defect tracking system for a single bug.
The bug was simply that a value was being improperly calculated and displayed on the screen. But the product ran on four operating systems (the current and prior versions of WIndows and Mac OS X), eight different browsers (the current and prior versions of four browsers), and was supported in seven different languages. So one bug was reported on Firefox v59 on Windows 8.1 in French. The same bug was reported on Safari 6.2 on MacOS 10.8 in English, and so on.
Bug reports like this wasted everyone’s time. But that tester sure looked productive in the “Bug Finder of the Month” contest.How About Money?
Financial rewards are almost always a bad idea. Financial rewards are often introduced by a well-meaning boss who wants a team to make a particularly aggressive deadline. The boss will offer an enticing amount to the team if they can deliver by then.
So far, so good. But the problems arise on the next project. On that, the team may start on schedule, but they’ve been trained that if they get a little behind (or perhaps even only if they report themselves as a little behind), the boss will offer a bonus. This becomes a dangerous cycle.
Besides, financial rewards don’t tap into people’s intrinsic motivations. There’s absolutely nothing wrong with money. Most of us wouldn’t show up for work without at least some paycheck. But we’d like to tap into deeper motivations than the purely financial.The Team That Taught Me About Financial Rewards
I learned a lot from a team many years ago to whom I gave a large financial bonus. This was two teams of 12 developers, and I gave them a bonus of $75,000, which would be more than $6,000 per person … if I split the bonus evenly.
And that was the trouble. I had allocated the bonus in the budget, so I had the money as a pool to give them. But when it came time to decide how I would give it to the team, I couldn’t decide.
I couldn’t decide. I went back and forth on this. Some of the key people on the project knew I was planning this bonus and wrestling with this decision. They offered advice. But each person’s suggestions were always very aligned with what would reward them the most.
And so, I gave up.
I told the team I would give them $75,000 but it was their decision how to allocate the bonus.
I told them the issues I’d been struggling with and said that whatever they decided would be fine. But they had to all agree on the process they’d use and the allocation.
A week after I shifted the problem to them, we had a team meeting. They told me they could not find a way to distribute the bonus money. They argued about it. And they felt the money was interfering with the strong bonds they’d built as a team.
And they gave the money back. They decided they didn’t want it.
I don’t think I’d ever been more proud of--or surprised by a team.
We ultimately decided to spend some of the money on a nice out-of-town trip for everyone plus a significant other. The rest was returned to the budget.
And it was the last financial reward I’ve offered a team.So How Should We Reward an Agile Team?
So how should we reward an agile team? I think the most important consideration is that rewards should encourage teamwork rather than individual performance. I favor rewards (both incentives and bonuses) that are given to everyone on the team.
This doesn’t mean there’s no role for individual rewards. I think those can be fine, but for individual rewards, I prefer to make them smaller, at least in relation to team rewards.
For example, I’ve worked with a few product owners who carry five-dollar bills and give them to team members who could quote the project’s elevator statement or three main goals when asked. No team member’s life was improved by $5. It was more the knowledge that they passed the test when asked. More than one of these team members pinned the $5 to their cubicle wall.
Similarly, a handwritten note can do wonders in this era of constant email deluge. Take the time to write a note every now and then thanking a team member for something special and specific they did.
One of my favorite rewards for a team is time. TIme is something that everyone seems constantly short of. I’ve rewarded a team with time a couple of different ways, which have been consistently well received. For example, you can offer a team an incentive of a week off if they meet some delivery milestone.
Or if a full week off is too much, offer the team a week (or a sprint) where all work is of their own choosing. They can refactor old code the product owner has been resistant to approving if they choose. They can experiment with new technologies. They can catch up on reading if they want. Whatever they choose is fine.
Another option is to give the team knowledge. If they achieve some goal, send everyone to a conference. If appropriate, everyone goes to the same conference. That’s especially good as you can include some fun time before or after. Or, if it’s better, allow each person to pick their own conference to attend some time during the year.
Or give everyone a book budget. (Yes, this is a financial reward, but it’s a little different.) Or a budget for online learning. Perhaps a Safari membership. Or even one of my video courses. But there are plenty of other options.
There is a role for incentives and bonuses on agile teams. But they need to be carefully designed to be consistent with agile’s emphasis on teamwork. But, done well, rewarding team members with incentives and bonuses can benefit the team and the organization.What Do You Think?
How do you reward teams? Or how would you like to be rewarded as a team?
The speach I love is a simple, natural speach the same on paper as in the mouth; a speach succuleant and sinewy, brief and compressed not so much dainty and well-combed as vehement an brusque - Michel de MontaigneÂ The Essays of MontaigneÂ (1580).
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.
Deming's approach to problemÂ solving is based onÂ The System of Profound Knowledge (SOPK). The anti-pattern to SOPK is The System of ProfoundÂ Ignorance (SOPI).Â
To obtain a System of Profound Knowledge, we need to start with the four components - appreciationÂ of the system, theory of knowledge, knowledge of variation, and the psychologyÂ of the people and process working within the system.
While knowledge of these understandings are standard for any credible management process of other people's money are needed, there is the inverse of this knowledge in play for the #Noestimates advocates.
The leadership of this notion that decisions can be made inÂ the presence of uncertaintyÂ without estimating seem to have missed the core knowledge of the principles of decision making. The opposite of knowledge is ignorance, so the framework of #NoEstimates is an anti-SOPK.
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.