Skip to content

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

Methods & Tools

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

Project Management

Blockchain for Software Developers

From the Editor of Methods & Tools - Tue, 12/20/2016 - 09:18
In a lot of software developer conferences, there are talks about the technical aspects of the blockchains, how to develop smart contracts on top of Ethereum and things like that. But before looking at those, it is crucial to take a step back and understand what is the blockchain, what it brings to the table […]

Quote of the Day

Herding Cats - Glen Alleman - Tue, 12/20/2016 - 04:03

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.

Categories: Project Management

The Ultimate Top 200 Best Novels, Ever

NOOP.NL - Jurgen Appelo - Mon, 12/19/2016 - 18:56

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:

(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.

The post The Ultimate Top 200 Best Novels, Ever appeared first on NOOP.NL.

Categories: Project Management

Logically Fallacious Friday

Herding Cats - Glen Alleman - Mon, 12/19/2016 - 01:05

20 Logical Fallacy Found in Agile and related topics

  1. Appeal to ignorance – Thinking a claim is true (or false) because it can’t be proven true (or false).
  2. Ad hominem – Making a personal attack against the person saying the argument, rather than directly addressing the issue.
  3. Strawman fallacy – Misrepresenting or exaggerating another person’s argument to make it easier to attack.
  4. Bandwagon fallacy – Thinking an argument must be true because it’s popular.
  5. Naturalistic fallacy – Believing something is good or beneficial just because it’s natural.
  6. Cherry picking – Only choosing a few examples that support your argument, rather than looking at the full picture.
  7. False dilemma – Thinking there are only two possibilities when there may be other alternatives you haven’t considered.
  8. Begging the question – Making an argument that something is true by repeating the same thing in different words.
  9. Appeal to tradition – Believing something is right just because it’s been done around for a really long time.
  10. Appeal to emotions – Trying to persuade someone by manipulating their emotions – such as fear, anger, or ridicule – rather than making a rational case.
  11. Shifting the burden of proof – Thinking instead of proving your claim is true, the other person has to prove it’s false.
  12. Appeal to authority – Believing just because an authority or “expert” believes something then it must be true.
  13. Red herring – When you change the subject to a topic that’s easier to attack.
  14. Slippery slope – Taking an argument to an exaggerated extreme. “If we let A happen, then Z will happen.”
  15. Correlation proves causation – Believing that just because two things happen at the same time, that one must have caused the other.
  16. Anecdotal evidence – Thinking that just because something applies to you that it must be true for most people.
  17. Equivocation – Using two different meanings of a word to prove your argument.
  18. Nonsequitur – Implying a logical connection between two things that doesn’t exist. “It doesn’t follow…”
  19. Ecological fallacy – Making an assumption about a specific person based on general tendencies within a group they belong to.
  20. Fallacy fallacy – Thinking just because a claim follows a logical fallacy that it must be false.
Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Fri, 12/16/2016 - 17:39

What can asserted can be dismissed

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
Categories: Project Management

The Myth of Standish Reports - Update Number 2

Herding Cats - Glen Alleman - Thu, 12/15/2016 - 16:39

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.

IT Dashboard
When you go here you'll see 61% are green, 33% "need attention," and 4.84% have "significant concerns."

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.

Related 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
Categories: Project Management

Software Development Linkopedia December 2016

From the Editor of Methods & Tools - Wed, 12/14/2016 - 12:21
Here is our monthly selection of knowledge on programming, software testing and project management. This month you will find some interesting information and opinions about project management personalities, better teams, starting a new job, code reviews, agile testing, scaling Agile, IoT and tests quality. Blog: Implementers, Solvers, and Finders Blog: Giving better code reviews Blog: […]

Consider Onions or Round Trip for an MVP

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:

  • Minimum means it’s the smallest chunk of value that allows us to build, measure, and learn. (Yes, Eric Ries’ loop)
  • Viable means the actors/users can use it.
  • Product means you can release it, even if to a small, specific group of test users

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.

Categories: Project Management

How to Reward Agile Teams

Mike Cohn's Blog - Tue, 12/13/2016 - 16:00

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.

Should I:

  • Give the same amount to each person? If I gave each person $6,000, that seemed unfair to those with high salaries and overly generous to others.
  • Give an amount proportionate to each person’s salary? This seemed the opposite.
  • Weigh the amounts by how many months the person had been on the project? It seemed unfair to give the same amount of money to a developer who joined the project a month ago as someone who had worked six months on it.
  • Give to the developers who had worked on this project but had been transferred off? It seemed unfair to leave them out, but if they weren’t there during the hardest period, did they deserve as much?

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?

Quote of the Day

Herding Cats - Glen Alleman - Tue, 12/13/2016 - 15:00

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).

Categories: Project Management

Quote of the Month December 2016

From the Editor of Methods & Tools - Mon, 12/12/2016 - 15:48
Experience shows that architecting is not something that’s performed once, early in a project. Rather, architecting is applied over the life of the project; the architecture is grown through the delivery of a series of incremental and iterative deliveries of executable software. At each delivery, the architecture becomes more complete and stable, which raises the […]

Cost Accounting is a Problem for Agile (and Knowledge Work)

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.

Categories: Project Management

Announcement: Additional Writing Workshop

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:

  • You are thinking about writing more
  • You want to improve your writing
  • You want to develop a regular habit of writing

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.

Categories: Project Management

#NoEstmates and the System of Profound Ignorance (SOPI)

Herding Cats - Glen Alleman - Wed, 12/07/2016 - 18:04

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.

  • A solid understanding of each component from a conceptual perspective:
    • What is the variation?
    • Why do we need to know about it?
    • How will these variations favorably or unfavorably impact the outcomes of our work?
  • A solid understanding of how each component interacts with the other three, from a conceptual perspective (e.g., how does a theory of knowledge impact how you interpret a system's behavior?)
  • A solid understanding of the above as applied to a domain (e.g., software development).
  • A solid understanding of the above as applied to a specific organization (e.g., our team).

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.

  • Lack of Appreciation for the System of business management - business management is a closed loop process to maximize the Value in exchange for the Cost. Estimates of how much is it going to cost to produce the value - which is itself an uncertain outcome means the business must estimate both. Decision Analysis for the Professional is a good place to start for the business.
  • Lack of knowledge of Variation - natural variations and event based variations come from uncertainty. These uncertainties are the source of risk. And we have to remember Tim Lister's quote Risk Management is How Adults Manage Projects. No risk management means no uncertainty. 
  • Lack of a Theory of Knowledge - opinion and gut-feel rule the conversation. There is no incentive to going where the data is. 
  • Lack of appreciation of the needs of those paying for the work - the suggestion that estimates are waste doesn't define who this is a waste for. It may well be that coders see estimating as a waste. But it's not their money. Want to get paid? We need to know how much your work will cost, in the beginning, and during the work and as we approach the end. This is the Estimate to Complete and Estimate at Completion information needed by the business to make decisions. Waiting till the end of the project to know these is nonsense.
Related articles Some More Background on Probability, Needed for Estimating Risk Management is How Adults Manage Projects Herding Cats: Estimates, Forecasts, Projections Making Decisions In The Presence of Uncertainty Estimating and Making Decisions in Presence of Uncertainty Making Conjectures Without Testable Outcomes Quote of the Day Do The Math The Microeconomics of a Project Driven Organization
Categories: Project Management

The Impostor Software Developer Syndrome

From the Editor of Methods & Tools - Wed, 12/07/2016 - 17:50
Did you ever feel like a fraud as a software developer? Have the feeling that at some point, someone is going to find out that you really don’t belong where you are? That you are not as smart as other people think? You are not alone with this; many high-achieving people suffer from the imposter […]

Pushing vs. Pulling Work in Your Agile Project

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.

Push and PullHere’s the problem: there is No One Right Way to manage the flow of work through your team. Every team is different.

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:

  • Add a kanban board that visualizes your workflow before you change anything. Gather some data about what’s happening. Are your stories quite large, so you have more pressure for more deliverables? Do you have more interruptions than you have project work?
  • Reduce the iteration duration. Interruptions are a sign that you might need to change priorities. Some teams discover they can move to one-week iterations and manage the support needs.
  • Ask questions such as these for incoming non-project work: “When do you need this done? Is it more or less important or valuable than the project work?”
  • Make sure you are a cross-functional team. Teams can commit to finishing work in iterations. A group of people who are not interdependent have trouble committing to iterations.

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.

Categories: Project Management

Software Development Conferences Forecast November 2016

From the Editor of Methods & Tools - Tue, 11/29/2016 - 16:00
Here is a list of software development related conferences and events on Agile project management ( Scrum, Lean, Kanban), software testing and software quality, software architecture, programming (Java, .NET, JavaScript, Ruby, Python, PHP), DevOps and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods […]

What I’ve Been Writing Lately

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!

Categories: Project Management

Iterations and Increments

general-agile-picture-copyright-1024x645Agile is iterative and incremental development and frequent delivery with cultural change for transparency.

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):

  1. Already existing user can log in.
  2. Users can change their password.
  3. Add new user as a user.
  4. Add new user as admin.
  5. Prevent unwanted users from logging in: bots, certain IP addresses, or a physical location. (This is three separate stories.)

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.

Categories: Project Management

Registration Open for January 2017 Writing Workshops

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.

Categories: Project Management