The End of Projects

Projects are the main reason for Software Products Development failure.

Why ?

Because Projects and Software characteristics are totally different and conflict.

How ?

1- Nature:

Projects are (Temporary) and have an end date.

Software development is (Not Temporary)

and this creates two problems:

a- Quality: poor cos you would like to finish on an end date.

b- Team: dismantled which will lead to lose of experience and deep information which can not be catch by documents.

2- Success Criteria:

Projects (Budget , Time and Scope)

Software development (Value / Benefit)

3- Size:

Projects are Big (budget, time, scope, team, … etc)

which implies Feedback problem, cos of big batches of deliverable.

Software development should be in small batches so as to enable feedback and benefit as soon as possible.

4- Estimation:

Projects estimate and predict large deliverable in advance. Controlling uncertainty.

Software is inherently unpredictable. So exploit uncertainty to create more releases and more releases means options. And options have value.

5- Change:

Projects will penalized late requirements.

Software products are always changing otherwise they are not used or dead.

6- Sign-Off:

Projects suits traditional management where senior managers can sign-off big batches of work.

Software development suits self-managed teams where team members can sign-off small batches of work.

#NoProjects   #BeyondProjects

Resource: No Projects – Beyond Projects

Posted in #BeyondProjects, #NoProjects, Comparison, Projects, Software Development | Tagged , , , , | Leave a comment

The Power of Small and Simple Habits

The reason people fail to change their lives, and fail to instill new habits, is because they try to do too much at once. In simplest terms, if your new habit requires more willpower than you can muster, you will fail. If your new habit requires less willpower than you can muster, you will succeed.

You couldn’t do a 30-minute workout because your willpower wasn’t strong enough or was depleted. But you could do one push-up and segue into a 30-minute workout because it only requires a tiny amount of willpower to start, after which your body and mind stopped resisting the idea.

Willpower ,  it’s a limited resource.

Source:  How Simple Mini Habits Can Change Your Life

Posted in habits, Success, willpower | Leave a comment

Basic Features vs Delightful Features

Basic Features
Basic features that a user expects to be there and work will never score highly on satisfaction, but can take inordinate amounts of effort to build and maintain.

Delightful Features
Score very highly on satisfaction and in many cases may not take as much investment. Small incremental improvements here have an outsized impact on customer satisfaction.

Hotel example:

Hot Water: No customer is going to rave on Twitter about how good the hot water in their hotel was, but if it wasn’t there, or it wasn’t hot enough, or took too long to get hot, you bet there would be a complaint, and a loud one.

It is crucial to understand at what point you’ve met the users’ expectations and to stop there. Any further development is a wasted effort.

A user will never tell you about basic expectations. If you sat someone down and asked them to design their perfect design they will not tell you about basic design. You have to observe and research to find these basic expectations.

The beauty of delightful features is that these features can deliver so much more user satisfaction per unit of investment than basic features.

The Problem of Delightful Features

All features will migrate from delightful to basic expectations. Once a user has come to expect that delightful feature – whether because you’ve had it for a while or because all their other products have it – the feature has become something they expect. The absence of that feature would now be a frustration, and you need to discover new delightful features.

Lessons

  1. Which features are meeting basic expectations? Only invest in developing or maintaining those to the extent that you need to satisfy the customer. Which features are your delighters? Focus your efforts here and make sure you’re constantly developing new ones.
  2. Monitor your customer satisfaction and competition to ensure that features you think delight users haven’t slid into basic expectations and no longer help your customer satisfaction.

Resource: Using The Kano Model To Prioritize Product Development

Posted in Agile | Leave a comment

Managing Requirements Dependencies Between Agile and Lean Teams

Originally posted on Disciplined Agile Delivery:

Sometimes functional dependencies occur between requirements that are being implemented by different teams.  For example, requirement X depends on requirement Y and X is being worked on by team A and Y is being worked on by team B.  This generally isn’t a problem when requirement Y is implemented before requirement X, is a bit of an annoyance if they’re being implemented in parallel (the two teams will need to coordinate their work), and an issue if X is being implemented before Y.  For the rest of this posting we will assume that X depends on Y, X is just about to be implemented, and Y has not yet been implemented.  Previously in Managing Dependencies in Agile Teams we discussed strategies for addressing such dependencies, including reordering the work or mocking out the functionality to be provided by Y.  In this posting we explore the implications of managing requirements dependencies…

View original 598 more words

Posted in Uncategorized | Leave a comment

Twenty Minute Rule

Whenever you come home from a long day at work or school,  you were so tired the only things you could find energy to do were mindless life-negating nonsense– television, Netflix, Reddit, Facebook, whatever.

Every night you would somehow find hours of time to do these things (despite being extremely tired).

Replace this time wasting routine with the twenty minute ruleThe moment you get home, you force yourself to do at least twenty minutes of one of the things that makes you better, happy and closer one step to you goals.

 

When people don’t plan, they aren’t ready to take advantage of opportunities that avail themselves, and so they play Angry Birds and watch Netflix because it takes less energy than figuring out something to do at that moment.  I call this the “path of least resistance problem.”  To make ourselves more sensitive to opportunities that can decidedly improve our lives, we need to structure our routines to make the path of least resistance difficult.  One way to do this is the twenty minutes rule.

If we want to do something trivial, something that likely won’t matter in the grand scheme of our lives, like meeting a colleague for lunch, we will pencil a time in our calendars and get it done.  But when we want to do something important and enriching, something we know will matter greatly in the grand scheme of our lives, like writing a book or learning a language, we say “I’ll get around to it.”  We don’t pencil in the twenty minutes a day necessary to become the person we really want to be.  One way to do this is to challenge the impulse to relegate our passions and our ambitions to something our future selves will do down the line.

 

Resource: http://www.quora.com/Lifestyle/What-small-lifestyle-changes-have-the-biggest-impact/answer/Evan-DeFilippis?srid=uOyW&share=1

Posted in Planning, Productivity, Time Management | Leave a comment

If you are not Planning , then you are a bad Developer

No matter how many years you have, if you are not planning (white board/paper) your work and just jump and code, then you are a bad developer.

Developers face coding decisions, many of which are complex, the best developers will plan their work and make good decisions. Bad developers just ‘jump in'; they assume that they can always rewrite code or make up for bad decisions later. Bad developers are not even aware that their decision processes are poor and that they can become much better by planning their work.

Resource : No Experience Required!

Posted in Productivity, Programmers | Leave a comment

Programming Every Day

Why you should program daily (work or side projects) ?

1- Break-through solutions:

Subconscious will work while you are eating, driving, sleeping, … etc.

2- Productivity:

Everyday a little step towards your goal.

3- Satisfaction:

Feeling progress is important as achieving your goals.

4- Switching:

Easy switch to work on your project, because everything is in the front memory.

How to do it?

1- Time:

Set a specific time and period, what ever happened you should do programming.

2- Place:

Set a specific place and don’t change it.

3- Progress not result:

You are looking for sitting down and do programming, not waiting for a result. And this is better, because your subconscious will be working while you are in a middle of a dilemma.

Resource: Write Code Every Day

Posted in Problem Solving, Productivity, Programmers, Programming, Side Projects, Study, Success | Leave a comment

Release Planning

Maximize your return on investment by:

working on one project at a time;
releasing early and often;
adapting your plans;
keeping your options open; and
planning at the last responsible moment.
Use timeboxing to control your schedule. Set the release date, then manage scope to meet that date. This forces important prioritization decisions and makes the endpoint clear.

Prioritized Minimum Marketable Features (MMFs) and stories form the body of your plan. Demonstrate your progress as you develop and use that feedback to revise your plan.

To minimize rework, develop the details of your requirements at the last responsible moment.

Resource: The Art of Agile Development: Release Planning

Posted in Agile, Continuous Delivery, Continuous Improvement, Incremental, Iterative, Planning, Project Management, SDLC | Leave a comment

What Is a Customer Need?

Much of the confusion concerning the proper role of
customer needs in the innovation process stems from an
unclear understanding of what a customer need is. Solutions,
features and product requirements are not customer needs,
and yet they have all been treated as such at one time or
another.

There are two forms in which customer needs may be
stated that properly reflect the customer’s definition of value.
First, there are job statements. A job is a fundamental goal
that customers are trying to accomplish or a problem they
are trying to resolve in a given situation (e.g., prevent cavities,
learn to play guitar or hang a picture). Second, there are
outcome statements. A desired outcome is a metric that is
used by customers to measure success when getting a job
done. Customers hire particular solutions to get a job done,
and they choose among competing solutions in order to ensure
that their priority outcomes in getting a job done are satisfied.
(For more detailed discussion of jobs and outcomes and their
role in the innovation process, see Anthony W. Ulwick, “Turn
Customer Input into Innovation,” Harvard Business Review,
January 2002; Lance A. Bettencourt and Anthony W. Ulwick,
“The Customer-Centered Innovation Map,” Harvard Business
Review, May 2008; and Anthony W. Ulwick and Lance A. Bettencourt,
“Giving Customers a Fair Hearing,” Sloan Management
Review, Spring 2008.)

Although jobs and outcomes share several characteristics
that enable them to be properly valued in the innovation
process, two in particular are worth noting. First, a good job or
outcome statement does not include any references to how the
customer need might be satisfied. This seems simple enough,
but it is challenging in practice—as it means stripping away
reference to the way things are currently done (as those merely
represent the current solution). Second, a good job or outcome
statement uses unambiguous language that will lead to a common
understanding by anyone who reads it. Thus, imprecise
words such as “reliable,” “durable” and “easy to use” must be
avoided. Such imprecision introduces variation in interpretation
that hampers innovation.

When customer needs are defined as jobs and outcomes
with these two characteristics in mind, they can become the
basis for capturing need statements that customers are able to
articulate, that are relevant across geographies and time and
that are useful for decision making by diverse stakeholders
within the organization.

Resource: What Is a Customer Need?

Posted in Innovation, Jobs-to-be-done, Problem Solving, Productivity, Project Management, Requirements, SDLC | Leave a comment

5 Myths of Customer Needs

Customer needs can and should guide innovation. So where does
the problem lie?
The answer is both simple and profound: It is the failure to understand exactly what a customer need is.

Five myths that have a particularly pernicious effect.
Like all myths, they have a basis in reality, but their unquestioned acceptance as truth is leading many companies astray—leading to wasted resources, disjointed innovation executions, missed growth opportunities, and product concepts that miss the mark with customers.

Myth No. 1: Customers Can’t Articulate Their Needs

“Ignore Your Customer!” This provocative title for a 1995 article published in Fortune magazine has become the mantra of a generation of product managers who operate under the mistaken belief that customers cannot articulate their needs. Customers will mislead you if you ask them about their needs—or so the thinking goes.

“If you had asked customers, they couldn’t have told you they needed the iPhone. Therefore, it must be true that customers cannot articulate what they need.”
But there’s the rub: However brilliant it may be, the iPhone
is not a customer need. The iPhone—like the microwave and
Walkman before it—is a solution to a customer need. When
companies get solutions and customer needs confused, it confuses
the role of the customer and the company in the innovation
process. Customers articulate their needs; it is up to the
company to create a solution.
It is not the role of the customer to provide technology
ideas to the company, or even to evaluate the potential for a
new technology to satisfy their unmet needs. How would they
know? They are not technology experts.
When customer needs are defined in a manner that distinguishes them
from solutions, not only can customers articulate their needs,
but those needs become the valued foundation the innovation
process requires.

Myth No. 2: Customers Don’t Know What They Need

It is this myth that leads many product managers to conclude—incorrectly—that innovation is the process of “creating a customer need.”
“If the solution we’re going to propose does not yet exist,” the
managers say, “then how can customers possibly know that
they need it?” But again, the managers are confusing solutions
with needs. A product or service may do something that has
never been done before, but the needs it addresses will have
been long-standing.
If a company can learn how customers evaluate how well they’re
able to get jobs done using today’s solutions, then it can learn
precisely where customers have needs that are currently unmet
by any solutions.

Myth No. 3: Different Customers, Different Needs

“If you’ve seen one hospital, you’ve seen one hospital!” This humorous comment captured the recognition that every hospital has its own way of doing things. But it would be dangerous to conclude that because each hospital has its own way of doing things, each hospital is trying to satisfy a different set of needs.
Why this myth, because they are looking at the solutions
customers are currently using—rather than at the job the
customer is trying to get done.
There may be any number of possible solutions to the problems a job presents, but that doesn’t mean that there is more than one job.
If the innovation team focuses on the solution that customers are using, it will limit how they perceive the customers’ actual needs.

Myth No. 4: Customer Needs Change Quickly Over Time

Solutions come and go. Many believe that customer needs change quickly over time. Unfortunately, this mistaken belief leads many to downplay the role of customer needs in guiding strategy and long-term product planning.
If solutions and customer needs are not properly distinguished, companies can mistakenly conclude that needs change rapidly over time.
The reality is that customer needs are quite stable when
properly defined around the job the customer is trying to get
done.
If customer needs do not reference particular
solutions—such as financial planning software—they have a relevance that spans years and decades. It is true that the priorities people attach to these needs will vary over time, as society changes and new solutions are introduced. However, the underlying needs remain
the same.

Myth No. 5: Customer Needs Differ by Org. Purpose

The primary reason for these internal coordination problems
is the absence of a precise and shared language for speaking
about customer needs.
All must first agree on what a good customer need statement is—one that will inform the varied purposes of all.

Resource: Debunking Myths about Customer Needs

Posted in Creativity, Innovation, Jobs-to-be-done, Productivity, Requirements, SDLC | Leave a comment