planning – Page 2 – In Search Of

Top 5 Reasons to use Sequence rather than Priority

Posted on February 6, 2013Leave a comment

I influence software delivery. Software delivery is abstract and complex. It is abstract because most people don’t really understand what happens behind the bit curtain. It is complex because it requires the translation across many layers of abstraction and back and sometimes the value is lost in translation.

I say that I influence it, because my job is to increase the probability of success. To make projects more effective. I do not manage the team. I do not decide the deliverables. I do not even run the process. I do not write the code, very often.

What I do, mostly, is give delivery teams ideas and concepts that can help them increase their probability of success. What I do, secondly, is to convince their customers that those ideas are important, and that their (the customer’s) role is as or more important in the success of the delivery than the technicians who are writing the code.

What is my number one idea? Sequence! Continue Reading

Yak Shaving Unleashed!

Posted on January 20, 20133 Comments

Yak shaving is the time honored tradition of needing to complete tasks that relate more to the path we have chosen than to the goal we seek.

My most recent incident involved upgrading my wife’s version of Adobe Lightroom on her iMac. My wife is a professional photographer, and she uses Adobe Lightroom to develop and organize her images. She had decided to prepare a “cheat sheet” for herself for the most common tasks, so she could make sure to be more consistent in the way she does things. She decided, though, since she was a version behind on Lightroom to upgrade to the latest and use that to make the cheat sheet, and that is where the trouble started.Continue Reading

Local Optimization

Posted on October 25, 2011Leave a comment

I am clearly aggravated. I have been for a while, and I finally understand why.

In the world of systems thinking, it is called Local Optimization. That is where, in a multivariable system I optimise for one variable at the expense of other variables, and subsequently reduce the overall output of the system.

In more understandable business terms, I am optimizing one or more of the means, without regard to the “ends”. As my seventeen year old son put it I am maximizing one benefit without regard for the overall goal.

In organizational management, in a business with multiple business entities or sub-units – we are trying to maximise the profit of each entity, rather that maximising the profit of the whole. In process optimization, we talk about optimising throughput of one subprocess, without regard for the throughput of the whole.

Here are some examples that should resonate with everyone:

1) I spend so much time working to earn money, that I don’t have time to enjoy my wealth.
2) I build an educational system optimized for a specific metric (standardized tests) but have not taught my students how to learn independently.
3) I construct a business enterprise optimized to grow the stock price quarter by quarter, but do not produce anything of value.Continue Reading

Planning Bug Fixes

Posted on October 18, 2011Leave a comment

Jason Yip posted recently about scheduling bug fixes. I liked what he had to say. He is a very thoughtful person. I wanted to extend his thoughts with my own…

1) Fixing bugs is unpredictable – you never know how many you will have or how long they will take to fix.

Defects in delivered code fall in to categories:

non-working new capabilities
usability issues
collateral damage to surrounding code

If your goal is to have a quality product, there is no way to prioritize these apart. They all need to be addressed. So this taxonomy or similar taxonomies usually do not give you reasonable leverage for prioritizing defects.

2) Usability issues can be prioritized based on time, risk and frequency

usability issues may be deferred:

if the usability issue does not add unacceptable business risk.
if the usability issue does not add an unreasonable amount of user time to a business process.
if the usability issue does not affect a frequently used feature or path that would generate an unacceptable support call volume.

3) Defects can be caused by poor code design, or less thoughtful implementation

Sometimes, the problem is that the new capability is not adequately supported by the current design. The developer ended up playing whack-a-mole with the issues because he couldn’t quite wrap enough duct tape or baling wire around it to get it to stay working. Sometimes the prior releases duct tape needed to be re-wrapped.

Other times, the problem is that the developer simply didn’t think through the implications of his design pattern or understand the usage scenarios deeply enough so his design was simply inadequate.

Still other times, the implementation was just plain sloppy, so it passes the happy path scenario, but fails most alternates or edge cases.

These defects all mean that the fix may take as long as the original implementation of the capability to correct. They can result in a story getting backed out of a sprint if they are found late.

4) sometimes the source of the defect report is an important determinant of priority.

Defect reports from key users or evangelists tend to get prioritized above those of testers or non-savvy users. Sometimes also defects reported by users who are know to have the ear of management also get prioritized, as a noise limiting mechanism.

5) Assuming all bugs reported represent defects. Sometimes testers and users report how they “thought” things would work or should work.

Many times a validation is necessary to ensure that all reported bugs are really defects. Sometimes reports are simply enhancement requests masquerading as defects. Other times the tester simply mistook a working feature for a defect because of how they had envisioned it working, or because they assumed (untrue) things about the solution. Often these types of defect reports are an indication of counter-intuitive design, other times they are just wishful thinking. We need to be very careful about working on these defects as they can add uncommitted scope to a sprint, and can add risk to the committed scope via collateral damage.

6) When you have enough time and resources, prioritization is not necessary.

The closer to the completion of a feature the testing (and bug reporting) is executed, the less prioritization is necessary. When testing is done the “day after” the feature is complete, we often have the luxury of working on defects in sequential order. When testing is done days or weeks after the feature is complete, we can end up with more defects than we can fix and a larger completed codebase to re-engineer if the defect is related to a design issue. The opportunities for thoughtful re-design are often long past, and we end up wrapping duct tape and baling wire around the feature to fix the defect. This is one way we accrue technical debt. Perhaps the sequence of our testing and user feedback activities relative to our development activities is as or more important to manage than the sequence of our defect remediation.

Pragmatically Agile

Posted on October 4, 2011Leave a comment

In a conversation recently, I was reminded how being agile is awfully like being pragmatic.

We were talking about topics of interest to project managers like estimation and forecasting and measurement.

One of the topics discussed was about grooming the backlog, and backlog sequencing strategies: Walking Skeleton vs. feature by feature? Do you build just bones, and then add the skin? or do you build one complete body part at a time.

Another topic was about “sprints as phases”: requirements works a sprint ahead of development, testing works a sprint behind – this strategy might work for a longer duration effort (many sprints), but not as well for a shorter duration (4 or less) – it might drive you to more shorter sprints than fewer longer ones.

Yet another topics was about planning margins or slack. Budget or Schedule margins are not on the surface agile concepts, but when they are valuable or necessary risk management tools, they must be implemented in ways that do not interfere with measurement. A budget margin implementation means that I have the ability to spend more but stay on schedule. Pragmatic strategy for that is to overstaff at the beginning, and reduce staff as velocity stabilizes as sufficient, and risk is retired. Adding staff in the middle of a project decreases the stability and predictability of the team.

Our last conversation was about choosing a sprint length. Sprint lengths should be consistent – so that the measurement (velocity) is useful for projection. Sprints should be immutable – once a sprint is started, it cannot be shortened or lengthened. If there is a need to have “variable” length sprints then a shorter consistent measurement period should be adopted (weekly) so that the feedback loop doesn’t elongate. Last, the shorter the overall project, the shorter the sprint size – again, so that the feedback loop is timely enough to make adjustments.

There is no one right way – just ways that make more sense and ways that make less sense. We all learn more from failure that we do from success – but using a framework that fosters timely feedback and rapid adjustment provides ability to see failure coming and get better faster.

Emergent Vs. Inverted Thinking

Posted on September 27, 2011Leave a comment

In agile communities developers, project managers, testers, there is a phobia or paranoia about big ANYTHING up front – that is we should not spend more energy up front than is absolutely needed to get the committed stories/features done in the next iteration.

The concept that we use is emergent thinking. Requirements emerge as we bootstrap our thinking by delivering early features. Design emerges, as we build features that have similar needs, and we refactor towards opportunities for generalization or re-use. Plans emerge as we estimate and sequence the stories in the backlog.

So what happens when the requirements don’t emerge. When the design doesn’t emerge. When it feels like we are just skating on the surface, because there is too much fear of bigger change, or spending energy building anything now because it will all change in 3 weeks. When the product owner is unable to sequence the backlog because there are unmade business strategy decisions that are inhibiting the emergence of plans, requirements, and designs.

I use inverted thinking. It is the opposite of big anything up front- I envision a result (it doesn’t have to be the right result) and I build a plan to acheive that result. I work backwards from a conclusion, as if my decisions were made. I propose a design (as thin as possible) that I think will support the envisioned result. I build a plan (as thin as possible) and propose needed skills and resources.

I pretend I know everything, and when I need an answer, I make one up. But every answer I make up, I list as a decision – because that is the schedule I want. What decisions need answers in what sequence, by what date, and what deliverables are dependent.

Then I dare every stakeholder to tell me why my proposal (that I just completely fabricated out of BS) is wrong. If you can’t give me a good reason not to do this, we are going to move forward in this direction.

When the fear of making a wrong decision is inhibiting the emergence of requirements, plans and designs – Invert the thinking from “What should we do?” to “Why shouldn’t we do this?”…

…and watch decisions emerge.

Procrastination

Posted on February 16, 2009Leave a comment

In his excellent management skills blog, Tom Foster posts a brief series on Procrastination. Brad, a middle manager, procrastinates and brings the organization to a state where they are months behind on a major project. Tom spends a lot of time talking about time-span, as a predictor of management qualification. I appreciate this, as it has made me more aware of my limitations.

I can’t help but ask what is someone to do, to help an employee (or manager, supervisor, or executive) to improve their time span. There are many symptoms of a person who is expected to work beyond his time span. In my experience, most people, get used to working within a certain time span. The longer they are in a role, without specific challenges to increase that time span, the harder it will become for them to improve this capability.

Here are two tools that can be coached into a person, to help them become more effective at longer time span tasks:

1) Progressive Plan Elaboration – Start with a plan that is at a very high level, where the plan deliverables are each about the size of the person’s normal time span without worrying about smaller details. Order these deliverables in a reasonable sequence without worrying about smaller details. Agree on a schedule for starting work on each of these deliverables, and make sure that the plan includes a task to plan the smaller details of each deliverable, before the work on that deliverable is scheduled to begin. This technique works because most of us get hung up around the many details, rather than the basic work structure. We worry about things that we won’t know until we have done some of the work, and so we can’t always plan in detail in advance. For some people who think from the details up, this can be paralyzing, and the top down approach, ignoring the details until we are close up can really help.

2) Iterative Measurement – There are some times when the work cannot be broken up into discrete deliverables, other times, when there are many deliverables being worked on in parallel. Project Plans with these features can be difficult to organize, so we can break things into discrete time boxes or iterations. This specific work (list of tasks) will get done in this time frame (use a iteration time span that is within your graps). Make sure that you are planning each time box in advance, enough to make work assignments and manage schedules.

How could Brad, in Tom Foster’s post, use these two approaches to reduce the impact of procrastination? It sounds like Brad has a team of supervisors who can get the work done. He could probably work with them to set up a deliverable based plan, and have them work the schedule, and report the details of the plan for each deliverable before the work on that deliverable is stared. Alternatively, he could break the work into time boxes that he can manage (2 months) and set goals that are 2 months out and work toward those, re-establishing the goals, every months for a 2 month period. This approach could be called “rolling-wave” planning because there are overlaps between the iterations or time-boxes. If every month, I plan two months out, then I can respond to problems in the now, and adjust the plan, before a crisis becomes intense. By measuring my progress each month, I can feel myself starting to get behind, and I can adjust, rather than simply waiting for time to run out and making a mad dash to the goal.