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

Quote of the Day

Herding Cats - Glen Alleman - Fri, 02/24/2017 - 21:50

Simplicity is key, because it is tied up with being fundamental - Harvey Freidman

Now the question really becomes - how simple is simple enough? When we hear some phrase like this, and we don't hear the units of measure of how simple, how to reach simple, then there is only a platitude - no actionable outcomes. How can we measure simplicity? How can we measure the coupling and cohesion of all the parts that make up a simple design, process, or system - to confirm the result is the simplest? How can we learn to ignore the platitudes of those making claims about simple systems are the best when they provide units of measure of the system, simple, or best?

So remember

Explanations exist; they have existed for all time; there is always a well-known solution to every human problem — neat, plausible, and wrong. - H.L. Mencken

Categories: Project Management

Dunning-Kruger and Modern Software Project Management

Herding Cats - Glen Alleman - Thu, 02/23/2017 - 20:33

In "Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments," David Dunning and Justin Kruger state that the less skilled or competent you are, the more confident you are that you're actually very good at what you do. Their central finding is not only do such people reach the erroneous conclusion and make unfortunate choices, but their incompetence robs them of the ability to realize it.

This, of course, is true of everyone in some way. We think we have a great sense of humor when we don't. We rate ourselves higher than others in a variety of skills

Lake Wobegon - where all the children are above average

Turns out though that less competent people overestimate themselves more than others. 

The reason is the absence of a quality called metacognition, the ability to step back and see our own cognitive process in perspective. Good singers know when they've hit a sour note, good directors know when a scene in a play isn't working, and intelligently self-aware people know when they're out of their depth. 

When I hear unsubstantiated claims, usually from sole proprietors, working on de minimis projects, I think of Dunning-Kruger. I've vowed to ignore them and move on. If it works in their domain, then any advice they provide is usually limited to their domain and their experiences in that domain. But the continued chant that certain processes, methods, fixing for dysfunction continue. Getting louder when they are asked to show the evidence their idea has a basis in principle.  This is the confirmation bais for their misunderstanding of the principles on which they are making their claims. 

 

 

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Making Conjectures Without Testable Outcomes Deadlines Always Matter
Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Tue, 02/21/2017 - 05:49

“I am not much given to regret, so I puzzled over this one a while. Should have taken much more statistics in college, I think.” — Max Levchin, Paypal Co-founder, Slide Founder

Perhaps anyone conjecturing that decisions can be made in the presence of uncertainty may want to call  their High School Probability and Statistics teacher and find out what they missed

Categories: Project Management

Software Development Linkopedia February 2017

From the Editor of Methods & Tools - Mon, 02/20/2017 - 11:08
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 being a better leader and software manager, component teams, UX & Agile, writing less code, handling incidents, preventing Scrum to fail, test automation and lean principles. Text: How to be […]

Quote of the Day

Herding Cats - Glen Alleman - Fri, 02/17/2017 - 22:58

The real world is fraught with risk.
Forecasting with empirical data - the #NoEstimates approach to estimating - ignores this fact. In the NE version of forecasting there is no place for uncertainty, which is why No Estimates advocates assert Forecasting is not estimating. In this version of Estimating without calling it Estimating, the past behaviour represents the future behaviour, with not adjustments for reducible and irreducible uncertainties that create risk to the project's success.
When we try to plan, knowing we cannot predict the future precisely, the mismatch between the planning and the real world, creates confusion. This confusion creates biases and distortions, resulting in padded estimates and undue optimism as well as misuse and even dysfunction of the management in the presence of uncertainty.
There needs to be an approach to planning and forecasting that is connected with reality, an approach that acknowledges uncertainty from the beginning and continues to manage in the presence of that uncertanty throughout the life of the project.
This approach mandates estimating all our work that not de minimis. This work is driven by uncertainty - reducible and irreducible.
This uncertainty creates risk and Risk Management is How Adults Manage Projects - Tim Lister.

Practical Risk Assessment for Project Management, Stephen Grey, Wiley Series in Software Engineering Practice, 1995. Nothing has changed since these words. We still live, operate, and manage in the presence of uncertainty. Here's how we manage in our software intensive system of systems domain. Your domain may be different, but the principles of managing in the presence of uncertainty are the same.

Here's the now familiar briefing for how we management in the presence of uncertainty in our Software Intensive System of Systems domain.

Managing in the presence of uncertainty from Glen Alleman

 

Related articles The Flaw of Empirical Data Used to Make Decisions About the Future The Flaw of Averages and Not Estimating Herding Cats: Decision Making On Software Development Projects Monte Carlo Simulation of Project Performance
Categories: Project Management

Decision Making On Software Development Projects

Herding Cats - Glen Alleman - Fri, 02/17/2017 - 21:38

Decision Making on Software Development Projects
Is Both Simple and Complex at the Same Time

All projects operate in the presence of uncertainty.

Real-world decision making is performed under uncertainty.

Decision makers must make decisions which best incorporate these uncertainties.

These uncertainties come in two forms – reducible (I can do something about it) and irreducible (I can't do anything about it).

Irreducible (Aleatory) uncertainty is the natural variability of the processes and technology on the project. These are stochastic, they may be nonstationary, and are due to chance from the underlying statistical distributions.

Aleatory uncertainties are modeled as random variables described by statistical distributions  (Triangle is a common one when the actual distribution is not known) 
In aleatory uncertainty, decision makers make assumptions about the distribution's descriptive statistics - the Mean and Variance are needed along with the Most Likely (Mode) at a minimum. The shape of the curve is needed as well.

Irreducible uncertainty can only be dealt with margin. Cost margin, schedule margin, technical margin.

Reducible (Epistemic) uncertainty is subjective, with the subjectivity coming from lack of knowledge.

This lack of knowledge comes from the probabilistic nondeterministic behavior of the system or the environment.

Reducible uncertainty is addressed with redundancy, experiments, prototypes, models, measures, empirical data to reveal knowledge about the underlying probabilities of the process.

All Uncertainty Creates Risk.

Reducible risk requires estimating the probability distribution of the occurrence.

Irreducible risk requires estimating the statistical distribution of the naturally occurring processes.

Risk Management is How Adults Manage projects – Tim Lister.

Risk management requires estimating.

Adult management of projects requires estimating.

Not Estimating means not managing as an Adult.

  1.  “Treatment of aleatory and epistemic uncertainty in performance assessments for complex systems,”J. C. Helton and D. E. Burmaster, Reliability Engineering and System Safety, vol. 54, no. 2-3, pp. 91–94, 1996.
  2. “Uncertainty quantification using evidence theory,” W. L. Oberkampf, in Proceedings from the Advanced Simulation & Computing Workshop, Albuquerque, NM, USA, 2005.
  3. “Treatment of uncertainty in performance assessments for complex systems,”J. C. Helton, Risk Analysis, vol. 14, no. 4, pp. 483–511, 1994.
  4. S. N. Rai, D. Krewski, and S. Bartlett, “A general framework for the analysis of uncertainty and variability in risk assessment,” Human and Ecological Risk Assessment, vol. 2, no. 4, pp. 972–989, 1996.
  5. “Understanding uncertainty,”W. D. Rowe, Risk Analysis, vol. 14, no. 5, pp. 743–750, 1994.
  6. Possibility Theory: An Approach to Computerized Processing of Uncertainty, D. Dubois and H. Prade, Plenum Press, New York, NY, USA, 1988.
  7. “Judgment under uncertainty: heuristics and biases,”A. Tversky and D. Kahneman, Science, vol. 185, no. 4157, pp. 1124–1131, 1974.
  8. Methods for representing uncertainty. A literature review, Enrico Zio and Nicola Pedroni, Foundation for an Industrial Safety Culture, Toulouse, France
  9. Estimating Software-Intensive Systems, Richard Stutzke, Addison Wesley
Related articles Making Decisions in the Presence of Uncertainty Managing in the Presence of Uncertainty Herding Cats: Cone of Uncertainty - Part Cinq (Updated) Herding Cats: Managing Uncertainty, Risk, Threat, and Opportunity Some More Background on Probability, Needed for Estimating Estimating is Risk Management IT Risk Management Risk Management is How Adults Manage Projects
Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Fri, 02/17/2017 - 21:32

People behave the way they are managed
- A Wise old Navy Captain as told by LCMDR Nicholas Pisano

Categories: Project Management

Fifty Great Project Management Blogs

Herding Cats - Glen Alleman - Thu, 02/16/2017 - 19:06

Screen Shot 2017-02-16 at 11.03.57 AMOn Line PM Course has listed the 50 Greatest Project Management Blogs in alphabetical order

Categories: Project Management

Serverless Architectures

From the Editor of Methods & Tools - Wed, 02/15/2017 - 13:46
Serverless architectures have been touted as the next evolution of cloud-hosted software. Indeed, the promise of resiliency and scalability without the need for infrastructure management sounds too good to be true! But what exactly does a serverless architecture look like? And what are the trade-offs to weigh up when considering using one on your next […]

Hey, Join My New Project!

NOOP.NL - Jurgen Appelo - Tue, 02/14/2017 - 20:24

I am going to challenge you.

I want to see you do things you’ve never done before. I want you to learn, experiment, fail beautifully, and then try again. And I want to see you make progress in areas that few people in the world have explored.

I am talking about my new project.
You are welcome to join.

Why are you checking your Facebook or Twitter streams multiple times per day? Is it because you were sent to a social media workshop by your manager? Or because these companies are smartly targeting your intrinsic motivators?

What has caused millions of people to start running, exercising, and monitoring their calorie intakes? Was there a government campaign promoting healthier lifestyles? Or is it because thousands of apps, smartphones and wearables have made it a lot more fun?

What convinced me to switch from taxis to ridesharing, from radio stations to streaming music, and from workstations to tablets and notebooks? Is it because it’s part of someone else’s change program? Or because I wanted a more convenient work-life?

I’m sure you get my point.

People don’t change because they’re told to change. People change because smart companies make them want to change. It usually involves techniques borrowed from gamification, behavioral economics, and habitualization.

Consider a fitness tracker, for example. I run three times per week because the metrics of the fitness tracker on my smartphone have gamified the exercises so that I’m competing against myself. By showing me statistics, and comparing those with others, the tracker uses “nudges” borrowed from behavioral economics to influence my behaviors further. And by reinforcing the good behaviors with various triggers and rewards, the app has turned my regular exercises into habits.

Games, nudges, and habits.
That’s how people change.

We now live in a time where manuals, workshops, promotion campaigns, and change programs are not sufficient anymore to achieve organizational change. To really understand and influence people, we can now use smartphones, wearables, big data, artificial intelligence, and a healthy dose of applied psychology and sociology.

Do you find that fascinating?
Let’s try and improve organizations in a more modern way.

JOIN ME

The post Hey, Join My New Project! appeared first on NOOP.NL.

Categories: Project Management

New OnDemand Course - Scrum Overview

10x Software Development - Steve McConnell - Tue, 02/14/2017 - 18:23

Hello, Steve McConnell here. We are always updating our Construx OnDemand training, and I’m happy to announce a new course: Scrum Overview. Scrum enables software development teams to address complex adaptive problems, and in this course you’ll learn Scrum’s elements—its roles, events, and artifacts—as well as their purpose: how they’re all bound together to make Scrum hum. In short, you’ll learn what’s different about Scrum and what makes it so effective.

With the myriad Scrum courses available today, why would you take a course called Scrum Overview? If you’re a nontechnical stakeholder, such as an executive or sales and marketing staff or even a product owner, you might find value in getting an introduction to Scrum without diving into all the details, and the context that’s set in this course can very valuable. Even if you are a practitioner and you expect to get into the in’s and out’s of Scrum on a daily basis, it can useful to start with the context of Scrum so that you understand its full scope before diving into all those implementation details. Either way this can be a valuable introduction and overview of Scrum.

Your instructor in this course is Jenny Stuart. Jenny has been Vice President of Consulting at Construx for more than 10 years, and in that role she has overseen Construx’s work in implementing Scrum, and implementing Agile practices more generally, in organizations throughout North America and around the world. Jenny has worked effectively with individual contributors on Scrum teams, with Scrum Masters, and with executives who are supporting Scrum at the organizational level, and she has learned numerous lessons about how to support Scrum effectively by working at all those different levels. You’re in good hands with Jenny as the leader of this course.

  • Here’s the top-level outline for the course:
  • Introduction
  • The Scrum Framework
  • Scrum Roles
  • Requirements in Scrum
  • Agile Estimation
  • Plan a Sprint
  • Execute a Sprint
  • Wrap Up a Sprint
  • Adoption Pitfalls
  • Conclusion
If you want to go deeper with Scrum, follow this course with Construx OnDemand’s Scrum Boot Camp, which will teach you what you need to know to become certified in Scrum.

If you’re a Scrum Product Owner or want to become one, Product Owner Boot Camp drills down into the details you need to successfully plan releases, reflect stakeholder priorities, ensure the team builds the right product, and communicate with project stakeholders.

For more on developing requirements in Agile scenarios such as Scrum, see Agile Requirements Boot Camp, which teaches you how to use story mapping to define project scope, write user stories, size stories (agile estimation), and develop acceptance criteria for user stories.

Try Construx OnDemand for free today (no credit card required), and enjoy the course!

New OnDemand Course - Scrum Overview

10x Software Development - Steve McConnell - Tue, 02/14/2017 - 18:23

Hello, Steve McConnell here. We are always updating our Construx OnDemand training, and I’m happy to announce a new course: Scrum Overview. Scrum enables software development teams to address complex adaptive problems, and in this course you’ll learn Scrum’s elements—its roles, events, and artifacts—as well as their purpose: how they’re all bound together to make Scrum hum. In short, you’ll learn what’s different about Scrum and what makes it so effective.

With the myriad Scrum courses available today, why would you take a course called Scrum Overview? If you’re a nontechnical stakeholder, such as an executive or sales and marketing staff or even a product owner, you might find value in getting an introduction to Scrum without diving into all the details, and the context that’s set in this course can very valuable. Even if you are a practitioner and you expect to get into the in’s and out’s of Scrum on a daily basis, it can useful to start with the context of Scrum so that you understand its full scope before diving into all those implementation details. Either way this can be a valuable introduction and overview of Scrum.

Your instructor in this course is Jenny Stuart. Jenny has been Vice President of Consulting at Construx for more than 10 years, and in that role she has overseen Construx’s work in implementing Scrum, and implementing Agile practices more generally, in organizations throughout North America and around the world. Jenny has worked effectively with individual contributors on Scrum teams, with Scrum Masters, and with executives who are supporting Scrum at the organizational level, and she has learned numerous lessons about how to support Scrum effectively by working at all those different levels. You’re in good hands with Jenny as the leader of this course.

  • Here’s the top-level outline for the course:
  • Introduction
  • The Scrum Framework
  • Scrum Roles
  • Requirements in Scrum
  • Agile Estimation
  • Plan a Sprint
  • Execute a Sprint
  • Wrap Up a Sprint
  • Adoption Pitfalls
  • Conclusion
If you want to go deeper with Scrum, follow this course with Construx OnDemand’s Scrum Boot Camp, which will teach you what you need to know to become certified in Scrum.

If you’re a Scrum Product Owner or want to become one, Product Owner Boot Camp drills down into the details you need to successfully plan releases, reflect stakeholder priorities, ensure the team builds the right product, and communicate with project stakeholders.

For more on developing requirements in Agile scenarios such as Scrum, see Agile Requirements Boot Camp, which teaches you how to use story mapping to define project scope, write user stories, size stories (agile estimation), and develop acceptance criteria for user stories.

Try Construx OnDemand for free today (no credit card required), and enjoy the course!

Three Questions to Ask when Being Micromanaged

Mike Cohn's Blog - Tue, 02/14/2017 - 16:00

One of the foundational principles of agile and Scrum is a belief in the power of self-organizing teams. This makes a micromanaging boss, ScrumMaster or product owner a particularly difficult problem for agile teams.

I’ve found asking three questions helpful in dealing with micromanagers.

Who?

The first question is Who? Who is being micromanaged? If you are being micromanaged but the rest of the team is not, this tells you it is your own performance that someone is worried about. If so, you’ll need to improve your own performance and that stakeholder’s view of your performance.

But if your entire team is being micromanaged, the behavior is just part of who that stakeholder is.

To determine whether it’s just you or your entire team being micromanaged, spend a sprint or two noting what types of things draw the micromanager’s attention. Log all micromanaging activities so you can look back at the data and determine who is being micromanaged.

When?

A log of micromanagement activity will also help you answer the second question: When is the micromanaging occurring?

Does the stakeholder micromanage shortly before or after a meeting? For example, a product owner might leave their customer call every Tuesday feeling stressed and more inclined to micromanage. Or a Scrum Master might be prone to micromanage the day before the monthly meeting with the engineering VP.

Some people are more prone to micromanage at a specific time of day. A boss early in my career was particularly prone to micromanaging before his first cup of coffee.

Others may be more prone to micromanagement at specific times during an iteration. Perhaps the person you’re dealing with is most prone to micromanaging during the last few days of the iteration when he or she gets nervous about whether everything will get done. Again, log this type of information so you can later look for patterns.

I use a spreadsheet with the following columns:

Date: The actual date (e.g., March 8, 2017). This usually won’t help identify patterns but can be useful if you look back on the data and need to remember what might have been going on in the organization at the time.

Day of Week: Sometimes micromanaging occurs most frequently on certain days (e.g. Friday) so note the day of the week.

Day of the Sprint: To help see if micromanaging occurs most frequently at certain points within a sprint, note the number of days into the sprint when the micromanaging occurred. For example “Day 3” or perhaps “7 / 10” to indicate it occurred on day seven of a ten-day sprint.

Time: Note the time of day when the micromanaging occurred (e.g., 10:15 A.M.)

Who Was Being Micromanaged: Note whether it was you personally, the entire team, or perhaps a teammate being micromanaged.

What Was Being Micromanaged: Note the issue in this column.

Context: Note whether the micromanaging coincided with anything else occurring within the sprint, project or organization. Did it occur right before or after a meeting? Which meeting? What was occurring during the iteration overall?

Notes: Include anything additional worth remembering about the incident. You can see a sample in the following table.

 

Date

Day of
week

Day of
Sprint Time Micromanager Who? What? Context Notes March 8 Wed 6

10:30

Anne me Story about adding data sources    

Anne asked me for the 3rd time in two days how this was going.

March 8

Wed 6 2:15 Arie team Next week’s new client launch  

Arie emailed the full team to remind everyone how important the new client launch is

 

March 8
 

Thurs 6 9:28 Anne teammate  

Story about Salesforce integration

While en route to daily scrum, Anne asked me to tell Ashish

to see her sometime about the story he’s working on for her.  

Ashish has been providing her a daily update already as she requested.

 

Why?

After you’ve logged a couple of weeks of micromanaging activities, it’s time to ask the third question: Why is the micromanaging happening?

Scan your log looking for patterns. See if there are triggers that create the micromanagement. Perhaps your product owner micromanages you after her weekly meeting with her boss.

Perhaps your line manager is prone to micromanaging at the end of the month when he has to prepare a report for his boss.

Based on the patterns you see, try to identify conversations that may be worth having with whoever is micromanaging. You’re unlikely to get far by merely saying, “Please stop micromanaging.” Instead, talk to micromanagers in an attempt to learn what concerns them that they’re behaving as they are.

Once you’ve identified some of the triggers for micromanaging, it’s time to anticipate and eliminate those triggers.

Anticipate and Eliminate

If you can anticipate micromanaging behavior by noticing when it occurs, work to eliminate the trigger. Often you can do this by proactively providing information to the micromanager.

For example, if you know your product owner gets stressed and micromanages after a weekly meeting with her boss, schedule a meeting with your product owner ahead of that meeting. Be sure your product owner is well informed and prepared for her meeting.

Proactively provide information to stakeholders who are prone to micromanagement. Try to do it just in time so they have (and remember) the information in advance of whatever triggers them.

Avoid creating burdensome new processes for yourself. But you can assert control over a stakeholder (or boss) relationship by proactively providing information rather than waiting to be asked for it and then being forced to provide it on someone else’s schedule.

Some People Are Incurable

By following the advice here, you won’t always be able to eliminate micromanagement. Some stakeholders are incurable micromanagers. But the tips here will help you take greater control over most situations and generally make them more tolerable.

How Have You Handled a Micromanager?

What’s your worst story of being micromanaged? How did you handle the situation? Please leave your thoughts in the comments below.

 

Get Your Free Micromanagement Log

Start tracking to help eliminate micromanagement

Download Now!

Micromanagement Log cover

I’ve Had Enough

NOOP.NL - Jurgen Appelo - Mon, 02/13/2017 - 18:50

I can’t take it anymore.

I’ve had enough of people asking me how they can improve their team, while none of the team members are willing to run any experiments and learn from their failures.

I’ve had enough of organizations that want to scale with agile, while the change programs that managers roll out are still mainly about cutting costs and optimizing profits.

I’ve had enough of politicians promising change and making things better, while the policies of their parties are all about scaremongering and protectionism.

I firmly believe that most people are good. They usually mean well. But more often than not, group performance is abysmal. Progress stalls because teams, organizations, and political parties lack a systemic approach to purposeful evolution. I fear that, in most cases, the whole is less than the sum of the parts. In other words, great people, terrible systems.

Can we help improve those groups?

I’m sure we can. But history proves that writing books, running workshops, and organizing conferences are not enough to achieve sustainable improvement. And despite their heroic efforts, coaches and consultants often see their hard-earned results evaporate after yet another idiotic organizational system failure.

I am convinced that the solution is staring us straight in the eyes. The very reason that teams, organizations, and political systems perform badly is that the world is changing faster and faster. Have you ever seen the adoption rates of smartphones, social networks, or streaming media? Did you see how fast people are learning to use wearables and robots?

Anyone who claims that “people resist change” is just flaunting his or her incompetence.

They key to improving collaboration and performance across teams, organizations and other groups is understanding how some human behaviors are adopted at a rate that is similar to a global epidemic. If you have a good idea, and people aren’t picking it up, it doesn’t mean that they resist the change. It also doesn’t mean that your idea is wrong. It just means that there is no platform enabling the idea to go viral.

I’ve had enough of good people wasting their time in bad teams and organizations. I’ve had enough of fantastic books, workshops, conferences, coaches, and consultants achieving only temporary performance fixes. We need a platform that allows good ideas to spread across teams and organizations at Internet-speed. And like the adoption rates of new technologies, we need that platform to make any behavioral changes sustainable.

I want the whole to be more than the sum of the parts. There should be a platform that helps people grow awesome systems.

Do you want to build that platform with me?

JOIN ME

The post I’ve Had Enough appeared first on NOOP.NL.

Categories: Project Management

Why I Use a Paper Kanban Board

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:

  • I am too likely to put too much into a tool. I put all this week’s work, next week’s work, next month’s and next year’s work, even though I’m not going to think about anything that far out. Paper helps me contain my To Do list.
  • When I collaborate with others, they want to break down the stories (large as they may be) into tasks. No!! I can’t take tasks. I need to see the value. See my post about From Tasks to Stories with Value.
  • I change my board, depending on what’s going on. I often have a week-based kanban because I retrospect at the end of the week. I often—not always—have a “today” column.

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.

I recommend it for a job search. (See Manage Your Job Search and  Personal Kanban for Your Job Hunt.

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.

Categories: Project Management

Visualize Your Work So You Can Say No

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.

Categories: Project Management

Quote of the Month February 2017

From the Editor of Methods & Tools - Thu, 02/09/2017 - 16:40
One of the most important expectations to set early on is about involvement in the process. Many project stakeholders accustomed to traditional-style development view their role in a software development project as akin to dropping a car off for service: You tell someone what you need done and come back at appointed time to pick […]

From Tasks to Stories with Value

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:

  • The technical people see the work they want to accomplish. They create a list of tasks to get there: design database, create infrastructure, fix these typos in the UI, and more.
  • Or, someone (such as an architect) is in charge of breaking down work, not team members. That person creates tasks.
  • Marketing or sales (or someone not in the product development team) says something like this: “I want a drop-down menu,” or a radio button or another report. They don’t remember to explain who the value is for, or why they want that value. Pretty soon, the idea of value is gone altogether, and only tasks remain.
  • Teams start to create stories, and the stories are so large, they create tasks to cover the stories. Pretty soon, they stop creating stories at all. They only create tasks.

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:

  • Tasks—by themselves—might not add up to a feature. He wants features.
  • When he counts features, he can describe what’s in a feature set—a collection of features that you might call an epic or a theme.
  • He can explain why he wants just this small feature, and not necessarily all of a feature set for now.

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.

Categories: Project Management

Influential Agile Leader, May 9-10, 2017

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.

(See the servant leadership tag for the Pragmatic Manager  and the leadership tag on this blog to see relevant articles I’ve written before.)

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Sat, 02/04/2017 - 23:14

Every systematic development of any subject ought to begin with a definition, so that everyone may understand what the discussion is about.
Marcus Tullius Cicero (196BC ‒ 16BC), De Officiis, Book 1, Moral Goodness

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Making Conjectures Without Testable Outcomes Deadlines Always Matter
Categories: Project Management