Tag Archives: agile

about goals

there’s SMART goals (Specific / Measurable / Attainable / Realistic / Timely), and then there’s STUPID goals (with more focus on strengths and what you really care for than planning and control).

some (like Leo / @zenhabits) even say it’s better to achieve without goals, or to not have goals!

or even stop trying to be more productive!

You don’t need goals to tell you what to do.

Goals as a system are set up for failure.

Toss productivity advice out the window.

…. the advice is wrong for a simple reason: it’s meant to squeeze the most productivity out of every day, instead of making your days better.

Imagine instead of cranking out a lot of widgets, you made space for what’s important. Imagine that you worked slower instead of faster, and enjoyed your work. Imagine a world where people matter more than profits.

Life where you’re always doing something you love is art.

but if you don’t have goals, or even if you do, the point is really to improve, continuously, isn’t it?

Jurgen recently asked for and received concrete advice for becoming a better manager – not abstract values or principles, but concrete advice on what agile managers should do from day to day.

so…

– should you set a specific (numeric) target or not?

– should you plan some time ahead, like in a project, or should you just think about the next step (even if in the direction of a specific vision)?

– should you focus on improving your weaknesses, or focus on excelling with your strengths?

– should you even have goals, or just follow your passion?

basic principles; starting with kanban

Leave a reply

David J Anderson is interviewed by geekwire: How an automotive secret can make for better software.

Agile methods for software development and project management …. are based on a few basic principles: it’s better to make progress with imperfect information and revise later than to wait for better quality information; it’s worthwhile to drive for high quality initially than to drive quality through quality assurance testing and rework late in the cycle; there is a dividend for encouraging a high level of trust and reducing negotiation, contracts, audit and arbitration in working relationships; and knowledge work such as software development is perishable so you should seek to reduce delays and focus on short delivery cycles.

All of these ideas are worthy and useful. Kanban also encourages these. However, it does so in a non-prescriptive, emergent way. Kanban is something you apply to an existing process to catalyze suggestions for improvement and to control variability that adversely affects predictability. The principles of Kanban are: start with the process you use now; agree to pursue incremental evolutionary change (rather than a dramatic change to a new (perhaps Agile) process); initially, respect all current roles, responsibilities and job titles.

(emphasis mine)

sw dev, design: iterating, incrementing vs backlog mapping

Leave a reply

Jeff Patton illustrates iterating and incrementing well:

incremental development – we build a piece at a time, having a finished design upfront, expecting no changes.

iterative development – we build something, then evaluate, then make changes to it, i.e., we expect to change it.

(i don’t quite like that both illustrations end up in the exact same Mona Lisa…)

i just saw a very nice description of a backlog mapping by Energized Work, described by Simon Baker. Lisa Crispin also blogged about it after a visit – The Whole Team Approach in Practice.

what i really like about this is the support for starting small, iterate+ increment, while keeping functionality and value visible.

Update:

There’s also a post about a mind-map form illustration high-level user experience replacing backlog, also at Energized Work.

The pink Post-It notes represent the different users. The blue Post-It notes represent the user activities and the yellow Post-It notes represent the high-level user tasks.

Another quote from this (emphasis mine):

We don’t use a burn-down chart to illustrate how much of the backlog is done. We consider this to be waste because the product is a moving target and the backlog can never done until the product is no longer available. However, we do visualize the investment made in the product to date.