Question_Agile Process_ UIE Virtual Seminar

[Srinivas Manda]

Hi,

have a question .... on what Jeff said ..

I would say " Doing a high level design for all the features " and
"Getting Ready to design for the first feature of Iteration 1 ( in depth
)"   in ITERATION ZERO is a lot TO accomplish in just an iteration ( 3 -
4 weeks ),

And also the entire core team should participate when we are doing this
high level design ...

Can we achieve all these in just three or four weeks?


Any thoughts ?

-Srinivas






--- In agile-usability@..., Jeff Patton <jpatton@...> wrote:

>
> Hi,
>
> I know the thread on this is very long. I'm about to respond to this
> not having reviewed the thread, so it's likely I'll mention things
> others already have.
>
> On iteration 0 or sprint 0: There always seems to be a "getting
> started" phase to an agile project where we get our backlog in order.
> This is the place where I expect to see high-level design.
>
> For me high-level design means identifying the business goals that
> motivate the product's creation, the customers and users of the
> product, and what they'll be doing as user tasks and activities
> (roughly how Larry Constantine defines those terms). I use user tasks
> and activities as large user stories suitable for both understanding
> the prospective system from the usage perspective and for planning. I
> also find that using these tasks I can identify screens and build
> basic navigation models and simple wireframes of the whole system. I
> likely don't have time for much validation - maybe a few reviews of a
> key scenario and sketchy prototype with prospective users. Sometimes
> maybe not. it depends on the risks in the project. I definitely make
> plans for how I'm going to involve users in the coming weeks and
> months of sprinting.
>
> In your question, you mentioned 6 features. Assuming all features are
> in scope for the release, my high level design (napkin sketch level of
> detail) incorporates all 6 features. It's not just for one. I want
> to think of the product holistically - even though I intend to
> construct it iteratively and incrementally.
>
> Then those 6 features need to be sliced very thin. User stories that
> go into a sprint are ideally very small - completable in a matter of
> days. So, a system with 6 features may decompose to dozens if not
> hundreds of stories. As a UX person you need to help with this - get
> good at this. If you're not involved with the planning and slicing up
> of your design into smaller stories, expect to "lose the plot" pretty
> soon.
>
> UI prototypes help make some early design decisions visible - more
> concrete. They help me break the features down into smaller buildable
> chunks. They help developers estimate. Ideally they estimate time
> and consider implementation ideas while estimating and discussing the
> features.
>
> Taking Lynn Williams recommendation, the design I prepare for the
> first sprint is for a critical feature low in IxD concerns and high in
> engineering concerns. This buys me time to start to get ahead on IxD.
>
> Your question below was "If there is a technical problem/Limitation
> that arises for the designs that we already worked on ITERATION ZERO
> how do we handle it?"
>
> On iteration 0 you also said: "in Iteration ZERO developers may not be
> ready to participate with designer as they will work on some other
> technical tasks"
>
> I'll tell you if developers don't participate in some way with design,
> all bets are off. What makes agile agile is this collaboration - is
> the back and forth discussion between those who design and those who
> implement. Without the discussion you're practicing a sequential
> development approach - a waterfall approach. You may be using words
> like "user story" and "iteration" or "sprint" - but don't be fooled.
> It's not an agile approach.
>
> Assuming I understand your questions correctly, if developers aren't
> involved early you're more likely to encounter technical constraints
> later - more likely to be surprised. It's a project risk that you
> mitigate by overlapping development and design concerns. Choosing not
> to overlap them is simply choosing to accept the risk. If developers
> don't have time to talk, make sure the whole team is aware of the risk
> we've all chosen to accept.
>
> Finally, stuff happens. Unforeseen technical challenges will arise.
> The reason for slicing big features into smaller stories is to see
> work being built, measure how long it took, and evaluate the
> incomplete product that came out. By doing this you learn about
> technical challenges sooner - ideally soon enough to respond to them.
> Ideally soon enough to face reality and adjust schedules or thin out
> features further to keep schedules.
>
> Hope this helps - and frankly I'll be shocked if the other smart
> people on the list haven't said all this already.
>
> Off to catch my plane. I'll read through the remainder of this thread
> on the plane.
>
> Thanks very much for posting - and thanks very much for listening to
> the webinar.
>
> -Jeff
> -----------------------------------------
> Jeff Patton
> jpatton@...
> +1 801.910.7908
> skype; jeff_patton
> www.agileproductdesign.com
>
>
>
> On Mar 9, 2009, at 2:21 PM, Srinivas Manda wrote:
>
> >
> > Hello Everyone...
> >
> > I am referring to the model that is given in
> > UIE Virtual Seminar
> > The Essentials of Agile Development that is given by Jeff
> > recently... (SLIDE 30)
> >
> > We are already working on this model but we have an issue.
> >
> > Scenario: Assuming that we have six features to a project and
> > business and the designer will be working on "First feature" in
> > Iteration ZERO with the Requirements/ Screens / Spec for three weeks
> > and they are done with it. (in Iteration ZERO developers may not be
> > ready to participate with designer as they will work on some other
> > technical tasks)
> >
> > Once we move on to SECOND Iteration and we will give Requirements /
> > Screens / Spec of the First feature to the developers so that they
> > can code it.. and this is where the problem comes
> >
> > Problem: If there is a technical problem/Limitation that arises for
> > the designs that we already worked on ITERATION ZERO how do we
> > handle it?
> >
> > -laksinu
> >
> >
> >
> >
>

[William Pietri]

Srinivas Manda wrote:

>
> > Regarding 3, I'd encourage you to move to a whole-team model, where a
> > cross-functional team, all sitting together, commits to work together.
> > Designers should still be doing some work on stories a bit ahead of
> > developers, but you don't have to manage that in lock-step with the
> > development iteration cycle.
>
> *Srinivas - I agree to what you say we would like to sit together and
> that is what AGILE says , if everyone is working on same set of
> features for 3 weeks then*
>
> *1)  when do we have time to do a usability test to the feature that
> we worked on with the end users and get feedback from them   ?  cause
> we may take the whole 3 weeks to work on a set of feature ...  say if
> we do the test after the iteration and we get some feedback from user
> ..if it is a good amount of change then should there be a rework and
> that extends the project deadline ..*
>

As others have mentioned, you may want to consider parallel workstreams.
With the teams I coach, they're all on weekly iterations, so usability
tests happen both before and after the development work for a story, but
rarely during. A given story might flow something like this:

    * Week N: The story is proposed. As part of a regular planning
      meeting, a product manager, a developer, and a designer kick the
      idea around a bit, sketch a little on a whiteboard, and write up a
      card with 4-8 words on it. They put the card in the backlog.
    * Week N+3: The story starts to look more important, and so it gets
      pulled up a bit. The product manager does a little thinking and
      research. The designer does a rough visual treatment and talks
      through the interaction flow with a peer.
    * Week N+4: At a regular estimation meeting, the developers estimate
      the story, forcing the product manager and the designer to flesh
      the story out a little more. Given current velocity, the story
      looks like it will come up in a couple of weeks, so the designer
      schedules a couple of chats with target users.
    * Week N+6: The story is scheduled early in the following week's
      iteration, so the designer does enough detailed design that they
      are comfortable they can get the developers right to work.
    * Week N+7: The developers build the story. As they start it, they
      spend some time with the designer and the product manager working
      out more details. As they work, every few hours the show bits to
      the product manager or the designer. As things are working, a
      developer pairs up with a designer for a few hours of "pixel
      pushing", where they work out the last details of the interaction
      and the visuals.
    * Week N+8: The story is now live. Stats are gathered on usage, and
      feedback is collected from users.
    * Week N+10: A few minor tweaks are now obvious, and the team ends
      up with a little spare time this week, so the fixes are quickly
      executed and released.


Does that make sense?

Of course, when there's an emergency, all of this can happen in very
short order. With my best teams, the product manager can come in with
something important Monday morning, scrap the planned iteration, and
have the story ship on Friday as usual. But because most shops have a
little more predictability in their work queues, and because there's
some benefit to letting ideas sit a bit, both the product management and
the design tend to happen gradually as the story gets closer.



William

P.S. This is covered, with diagrams even, in the video:
http://assets.pivotallabs.com/talks/10-22-2008_Meshing-Gears_Amanda-W_William-P.mov

[Srinivas Manda]

Thanks William, it helps

-Srinivas

--- In agile-usability@..., William Pietri <william@...> wrote:

>
> Srinivas Manda wrote:
> >
> > > Regarding 3, I'd encourage you to move to a whole-team model, where a
> > > cross-functional team, all sitting together, commits to work together.
> > > Designers should still be doing some work on stories a bit ahead of
> > > developers, but you don't have to manage that in lock-step with the
> > > development iteration cycle.
> >
> > *Srinivas - I agree to what you say we would like to sit together and
> > that is what AGILE says , if everyone is working on same set of
> > features for 3 weeks then*
> >
> > *1)  when do we have time to do a usability test to the feature that
> > we worked on with the end users and get feedback from them   ?  cause
> > we may take the whole 3 weeks to work on a set of feature ...  say if
> > we do the test after the iteration and we get some feedback from user
> > ..if it is a good amount of change then should there be a rework and
> > that extends the project deadline ..*
> >
>
> As others have mentioned, you may want to consider parallel workstreams.
> With the teams I coach, they're all on weekly iterations, so usability
> tests happen both before and after the development work for a story, but
> rarely during. A given story might flow something like this:
>
>     * Week N: The story is proposed. As part of a regular planning
>       meeting, a product manager, a developer, and a designer kick the
>       idea around a bit, sketch a little on a whiteboard, and write up a
>       card with 4-8 words on it. They put the card in the backlog.
>     * Week N+3: The story starts to look more important, and so it gets
>       pulled up a bit. The product manager does a little thinking and
>       research. The designer does a rough visual treatment and talks
>       through the interaction flow with a peer.
>     * Week N+4: At a regular estimation meeting, the developers estimate
>       the story, forcing the product manager and the designer to flesh
>       the story out a little more. Given current velocity, the story
>       looks like it will come up in a couple of weeks, so the designer
>       schedules a couple of chats with target users.
>     * Week N+6: The story is scheduled early in the following week's
>       iteration, so the designer does enough detailed design that they
>       are comfortable they can get the developers right to work.
>     * Week N+7: The developers build the story. As they start it, they
>       spend some time with the designer and the product manager working
>       out more details. As they work, every few hours the show bits to
>       the product manager or the designer. As things are working, a
>       developer pairs up with a designer for a few hours of "pixel
>       pushing", where they work out the last details of the interaction
>       and the visuals.
>     * Week N+8: The story is now live. Stats are gathered on usage, and
>       feedback is collected from users.
>     * Week N+10: A few minor tweaks are now obvious, and the team ends
>       up with a little spare time this week, so the fixes are quickly
>       executed and released.
>
>
> Does that make sense?
>
> Of course, when there's an emergency, all of this can happen in very
> short order. With my best teams, the product manager can come in with
> something important Monday morning, scrap the planned iteration, and
> have the story ship on Friday as usual. But because most shops have a
> little more predictability in their work queues, and because there's
> some benefit to letting ideas sit a bit, both the product management and
> the design tend to happen gradually as the story gets closer.
>
>
>
> William
>
> P.S. This is covered, with diagrams even, in the video:
> http://assets.pivotallabs.com/talks/10-22-2008_Meshing-Gears_Amanda-W_William-P.mov
>

[salmanwadood]

Hello friends,

 

Iam Salman in my final semester of masters and I assigned a project by the college. I need around 50 data samples of this survey after which I’ll analyze the data and prepare my reports.

 

If you are working in Software Development, Web Development, Testing or similar field, please I would appreciate, if you would take 5 mins of your time to give feedback.
 

http://www.kwiksurveys.com/online-survey.php?surveyID=HNIJK_41b94243 

 

PLEASE FORWARD IT TO YOUR FRIENDS/COLLEAGUES WHO ARE ELIGIBLE TO TAKE THIS UP.

 

Thanks a lot for your help J

 

Regards,

Salman

Srinivas Manda wrote:

Hello Everyone...

I am referring to the model that is given in
UIE Virtual Seminar
The Essentials of Agile Development that is given by Jeff recently...
(SLIDE 30)

We are already working on this model but we have an issue.

Scenario: Assuming that we have six features to a project and business
and the designer will be working on "First feature" in Iteration ZERO
with the Requirements/ Screens / Spec for three weeks and they are done
with it. (in Iteration ZERO developers may not be ready to participate
with designer as they will work on some other technical tasks)

Once we move on to SECOND Iteration and we will give Requirements /
Screens / Spec of the First feature to the developers so that they can
code it..   and this is where the problem comes

Problem: If there is a technical problem/Limitation that arises for the
designs that we already worked on ITERATION ZERO how do we handle it?

-laksinu

[juliebooth36]

At Con-way,  we have the luxury (right now) of being in the same geographic location. But there are only two of us UX types... We work very closely with the BA and the Developers on the teams and have established a process where we participate in stand-up as much as possible and have a weekly revolving door ux session on whatever is testable.  I posted a chart and a quick explanation about how we are using Mingle to manage that here:
http://www.uxsuccess.com/2009/10/ux-and-agile-co-mingling.html



--- In agile-usability@..., "Srinivas Manda" <laksinu@...> wrote:

>
> Mike, we as a team are still trying to understand Agile, and we are working based on how easy it is for us that suites our working model.
>
> Agile says that we (designer, dev, testing etc) should be at one place and work on stories that team buys for that iteration
>
> But in realistic how can that happen?
>
> Say everyone is at one place for 3 weeks and start working on features and as a UX designer I should design the feature and get that validated with users  and get a feedback from them .. But if we follow agile then the dev team should be boiling the code before I get the results ...if they do coding and if I get feedback from the users to change some design then should the dev need to recode it ?  
>
> Please comment on this
>
>
> --- In agile-usability@..., "Mike Dwyer" <mdwyer@> wrote:
> >
> > WHOA!   Look dude, Ron was being very nice.  We are not talking about
> > letting developers in to the initial design meetings. Agile is about
> > everyone being engaged.  You may have been an UI or UX Prima Donna in the
> > conventional world but in the Agile sphere, you are a member of a team, each
> > of whom brings their own unique skills that you, in all likelihood lack as
> > you have chosen to be a UI wizard.  Here is the secret message inside the
> > Agile bottle.  Users don't buy software, or UI or databases or any of the
> > stuff we love to work with.  Users buy value and it is our combined job to
> > work with the users to make sure we are all on the same page.
> >
> >  
> >
> > So if you are going to be Agile, understand this.  Your skills are no more
> > or less valuable than the most junior newbie tester or coder or BA.  It is
> > the sum impact of the team that delivers.
> >
> >  
> >
> > If this bothers you or you think that your world is an exception, please
> > look up the word Scrumbutt or Cragile and start using it to refer to what
> > you do.
> >
> >  
> >
> > Mike Dwyer
> > Principal, Agile Coach
> >
> > BigVisible Solutions
> > url:    http://www.bigvisible.com <http://www.bigvisible.com/>
> >
> > cell:   [phone]
> >
> > email: mdwyer@ <mailto:asingh@>
> >
> >  
> >
> >  
> >
> > From: Srinivas Manda [mailto:laksinu@]
> > Sent: Tuesday, March 10, 2009 2:18 PM
> > To: agile-usability@...
> > Subject: [agile-usability] Re: Question_Agile Process_ UIE Virtual Seminar
> >
> >  
> >
> > Thanks everyone for your input... will make it as a mandit to include
> > developers in my initial design meetings and will say this will be a
> > roadblock if not included...
> >
> > Thanks Everyone again..
> >
> > -laksinu
> >
> > --- In agile-usability@...
> > <mailto:agile-usability%40yahoogroups.com> , Ron Jeffries <ronjeffries@>
> > wrote:
> > >
> > > Hello, Srinivas. On Tuesday, March 10, 2009, at 8:51:00 AM, you
> > > wrote:
> > >
> > > > I agree to what you say , I would love to have Developers / Designers to
> > > > be in the same team but it is not possible
> > >
> > > Why? Are some of them in prison?
> > >
> > > > once example as i said earlier ... if developers and designer, BA's are
> > > > working at the same time and if the screen design is done ... and we
> > > > test the design with the USERS ... it is not really possible to get
> > > > feedback from the USERS in 2 weeks or so.. by the time we get the
> > > > feedback from USERS developers are done with there coding ... and if we
> > > > have some changes .. developers need to change the code ...
> > >
> > > Yes. This is an obstacle. You must remove it.
> > >
> > > Ron Jeffries
> > > www.XProgramming.com
> > > www.xprogramming.com/blog
> > > Attend our CSM Plus Course!
> > > http://hendricksonxp.com/index.php?option=com_eventlist
> > <http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28>
> > &Itemid=28
> > > Thousands of years ago, the first man discovered how to make fire.
> > > He was probably burned at the stake he had taught his brothers to
> > > light - Howard Roark (The Fountainhead, Ayn Rand)
> > >
> >
>