Hi David,

On Tue, Feb 2, 2016 at 1:28 AM, David Nugent <[email protected]> wrote:

> Hi Brian,
>
> Just my 2c worth...
>
> Like yourself, I've worked in this industry a lot of years, and
> personally found that the word "agile" is very overloaded. In fact, the
> term itself is just a broad methodology of incremental development that
> is in no way industry specific, and it covers a few variant disciplines.
>

I agree.  I have worked in several "agile" environments (both good and
bad).  All incremental, but none of them have born much resemblance to the
Scrum sheet earlier in this thread.  In my current job, we follow all four
of the fundamental agile manifesto "We prefer A over B" - and I like that.
We don't do Scrum, and I don't mind that.  Maybe not all our practices are
perfect, but they work for us and our customers, and that's kinda more
important than having the right "agile" tick.

It feels like it wasn't too many years ago when Extreme Programming was the
one everyone talked about.  Now Scrum seems the one.
To me, one of the important things is choosing an agile process for the
right reasons.
When I was in Uni, "agile" meant "Not having to do all the annoying massive
design documents our lecturers said we should do".
I've seen "extreme programming" used to mean "Let's just ignore the design
of the system and see what happens when we wing it"  (hint: XP has checks
and balances that are meant to guide the design while keeping it simple...)
Yes, I've seen issues with massive documents and unwieldy design up front,
and I'd much prefer not to do either of those things.
But the process has to be picked to try and develop better software and be
more responsive to the customer's needs, not because of laziness or
buzzword compliance.


> But what most call "agile" in the software industry is a discipline
> called "scrum"; referring to a highly collaborative team-based approach
> that follows a particular set of principles and role structure. In
> practice, workplaces implement it slightly differently, with various
> degrees of success, depending on the personalities and capabilities of
> those involved.
>
> While there's certainly something to be learned from adopting an agile
> approach, it isn't the utopia that some make it out to be. It takes
> people to drive it, and at the end of the day it's people and not the
> process that gets stuff done.
>

Good call.
I'd just stress again that in many industries a lot of the "people" you
work with or that influence the decisions will be customers, not
developers, and they will have a big say into whether agile meets their
needs and what the process should look like.

Jon


>
> > > "... as long as the candidate showed a willingness to operate in an
> > > agile way."
> >
> > Hmmm. Wonder if I need to be better at communicating this. Just a
> > thought.
> > --
> > Brian May <[email protected]>
> > https://linuxpenguins.xyz/brian/
>
>
> Regards,
> --
> David Nugent ([email protected])
> _______________________________________________
> melbourne-pug mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/melbourne-pug
>
_______________________________________________
melbourne-pug mailing list
[email protected]
https://mail.python.org/mailman/listinfo/melbourne-pug

Reply via email to