"Big picture" design one release cycle ahead?

[Björn Balazs]

Hi Thomas, all,

to stress your words: I think best practice for doing usability work 
in an Agile Context is to extent the current sprint in both 
directions. Not only the next sprint needs to be prepared, also the 
results of the last sprint need to be evaluated in order to foster 
the idea of continuous improvement of the team and the results.

So absolutely agreeing with what you suggest Thomas, I would like to 
bring in the idea of even doing the same thing for the smaller 
sprints on our way to the next major release.

Let's get in touch with our users - try to understand what is working 
good and where improvements are needed, as part of the preparation of 
the next sprint. And after the sprint, let's again talk to them and 
see if we managed to substantially improve the perceived quality.

We would probably need dot releases after each sprint (and hence have 
a shippable product after each sprint) and we would need to implement 
some way of talking to the users (best would probably be directly 
through the product). 

This would also allow us to ask relevant questions on our way to a 
task centric approach.

What do you guys think?

Cheers,
Björn



Am Freitag, 26. Oktober 2012, 13:21:49 schrieb Thomas Pfeiffer:
> Hey folks,
> I have a suggestion:
> I fully support Aaron's idea of small concentrated effort sprints 
with
> integrated design and development, which comes pretty close to 
agile
> development. However, product managers in the industry have found 
that such
> short design cycles do not work well for all kinds of design. They 
work
> well for small features/improvements, but for introducing larger 
changes or
> completely new concepts, longer research/strategy/design phases 
work
> better.




> One of these big changes for me is fleshing out the general concept 
of
> task-driven design for PA. Since the big picture won't be 
implemented in PA4
> anyway (we already got our hands full with small 
improvements/polish), I
> think it would make sense to use this release cycle to work design-
wise on
> the big picture of a task-driven system parallel to designing the 
detailed
> improvements for PA4 in each focus sprint.
> The big disadvantage is of course that design capacity is split 
between the
> two, but i think this is pretty much unavoidable since designing 
for a new
> metaphor requires more then just a few weeks and we probably don't 
want to
> have a full release without any actual development. In case of 
insufficient
> design capacity for both, the focus sprints would always have 
higher
> priority, of course. The biggest advantage to me is that ideally we 
have a
> broad concept for task-driven design ready by the end of the PA4 
cycle and
> can implement the details for PA5 if we wish to do so.
> So what do you guys think? Is the path to task-driven design worth 
putting
> some effort into it ahead of time?
> 
> Cheers,
> Thomas
-- 
Dipl.-Psych. Björn Balazs
Business Management & Research
T +49 30 6098548-21 | M +49 179 4541949

User Prompt GmbH | Psychologic IT Expertise 
Grünberger Str. 49, 10245 Berlin | www.user-prompt.com 
HRB 142277 | AG Berlin Charlottenburg | Geschäftsführer Björn Balazs