Hi Anne and all,
I wholeheartedly agree with many of the comments on this thread,
particularly the idea that quality (in code or product) has to be something
considered and applied throughout the entire process. Your situation sounds
a lot like some big company in Redmond I used to work for.
One thing that stood out to me about your situation was that you mentioned
set schedules and delivery dates, which sounds to me like not everyone in
the organization has bought off on the "agile" concept. Am I mistaken? In my
experience, until the whole org is on board with agile, and your delivery
dates don't come from outside of the team doing the actual work, there's
usually a fair amount of pain. I may be making some assumptions here that
don't fit your situation.
Also I'll re-iterate here that end-of-sprint retrospectives ("what worked,
what didn't work, what can we improve") are highly valuable in improving
your process, so long as the team is empowered to make real changes. And
that re-factoring is an integral part of the development process and there
needs to be enough time allotted to doing it right just as much as there
would be time alloted to any other aspect of the process.
Anyway, that's my 2 cents, hope it helps.
Mike Ibarra
On Thu, Dec 23, 2010 at 7:08 AM, Bobby Johnson <[email protected]>wrote:
> Always, I think the main take away with agile is there are no set in stone
> rules; instead measure and adjust.
>
>
> On Thu, Dec 23, 2010 at 6:55 AM, Justin Bozonier <[email protected]>wrote:
>
>> "I would also suggest that the definition of quality in your project
>> needs to be set up front with clear goals."
>>
>> I love that and completely agree (with the caveat that when things
>> change.. Well.. Things will change).
>>
>> <codemonkey expression="big smile" />
>>
>> On Dec 23, 2010, at 6:35 AM, Bobby Johnson <[email protected]>
>> wrote:
>>
>> I would also suggest that the definition of quality in your project needs
>> to be set up front with clear goals.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Seattle area Alt.Net" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected]<altnetseattle%[email protected]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/altnetseattle?hl=en.
>>
>
>
>
> --
> "The explanation requiring the fewest assumptions is most likely to be
> correct."
>
> - Occam’s Razor
> http://en.wikipedia.org/wiki/Occam's_Razor
>
> --
> You received this message because you are subscribed to the Google Groups
> "Seattle area Alt.Net" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<altnetseattle%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/altnetseattle?hl=en.
>
--
********************************
*Michael Ibarra*
[email protected]
@bm2yogi <http://twitter.com/bm2yogi>
http://dev.bm2yogi.com
--
You received this message because you are subscribed to the Google Groups
"Seattle area Alt.Net" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/altnetseattle?hl=en.
