Agile approach as a configurable set of practices

1 view
Skip to first unread message

Roman Muntyanu

unread,
Sep 13, 2007, 5:44:16 AM9/13/07
to Agile Software Development Group, Ukraine
2 Alimenkou Nikolay

Hi Nikolay,

You have mentioned that you tend to consider Agile as a set of
practices out of which you can pick out certain items for certain
project.
I did not practice any of Agile methodologies yet. But I plan to try
them out at next opportunity.
Anyway I think I'd rather share your vision.
What I plan to do is just take Scrum routine as a framework and plug
it with valuable practices perfectly described in XP. I have mentioned
important word here: "valuable".
I expect both Scrum Framework and XP practices to be adjustable to
bring maximum value. But what is more "valuable"?

Now I'm getting to the core of my question.
How would you pick out certain practices for new project?
In other words: how do you measure which improvement brings you (or
not) more value?

Thanks,

Roman

Serhiy Yevtushenko

unread,
Sep 13, 2007, 6:00:47 AM9/13/07
to agile-...@googlegroups.com
Hi

I would not be so easily looking in the agile as a set of interchangeable practices

Agile methodologies is very often (for example, XP) is a set of pieces, which fits together very well,
Adjustment of the methodologies, or throwing away some pieces leads to detioration of performance of other pieces.

From that viewpoint, Scrum is more general. in the way, that it does not prescribe set of engineering practices, but only prescribe some generic rules  (deliver tested, release ready software every two weeks, communicate progress, have one responsible for product vision, clear obstacles).
In order to implement Scrum, you may get to something very similar to XP.

But again, for example, Scrum is a balanced framework. If you throw away some one thing, that you will pay back dearly for it's absence.


Therefore, I would suggest trying interchangability only after implementing full basic framework.

Considering improvements and measuring them - this can be done
1) on retrospective, by voting of the team
2) Using some tools, for example Impact Estimation table from Evo
3) Using some tools form Theory of Constraints or Root Cause Analysis

But, in my opinion, the main problem is getting improvements to fly, and not choosing them.


2007/9/13, Roman Muntyanu <muntyan...@gmail.com>:

Max Pendyschtschuk

unread,
Sep 13, 2007, 6:24:44 AM9/13/07
to agile-...@googlegroups.com
Hello Roman,
 
"You have mentioned that you tend to consider Agile as a set of
practices out of which you can pick out certain items for certain
project."
 
- it is reasonable. Do you now about "Crystal" family from Cockburn? He recognizes that each project is a unique situation, and no methodology, no matter how good, is one-size-fits-all. I'm not familiar to this methodology (unfortunately) to tell more about it.
 
On the other side - the company, I work for, doesn't "build" scrum here, we try to be "agile", but... we want it or not, all we have doesn't conflict with scrum.
 
Is it possible, that something from Scrum is at variance with another agile methodology?

Roman Muntyanu <muntyan...@gmail.com> schrieb:

Wissenswertes zum Thema PC, Zubehör oder Programme. BE A BETTER INTERNET-GURU!

Alimenkou Nikolay

unread,
Sep 13, 2007, 7:00:59 AM9/13/07
to Agile Software Development Group, Ukraine
I can suggest you some interesting books that have answers on your
questions.
Here are some of them:

Addison Wesley Professional - Refactoring to Agility
Pragmatic Programmers - Practices of an Agile Developer Working in the
Real World
Pragmatic Bookshelf - Agile Retrospectives
Pragmatic - Release It Design and Deploy Production Ready Software
Pragmatic - Ship It! A Practical Guide to Successful Software
Projects

>From my own practice I introduce new practice only if there are some
issues that
this practice may help to fix (if it promises that it will help). I
always try to analyze
results of using that practice in different projects and then decide
if it will be helpful
for my project. Never try to introduce practice just for fun. ;) Then
I gain some metrics
as results of using new practice and decide is it suitable for team
and project. From
my point of view if some team members don't like practice and all your
attempts to
show advantages of it was unsuccessful then remove this practice from
your project or
change project/team. ;)

Alimenkou Nikolay

unread,
Sep 13, 2007, 7:06:10 AM9/13/07
to Agile Software Development Group, Ukraine
It is very interesting theme to discuss, I mean Crystal Clear. Have
you already read book
Crystal Clear: A Human-Powered Methodology for Small Teams (Addison
Wesley,2004)?
May be somebody have tried this methodology himself? Can somebody
share his experience?

Alexey Krivitsky

unread,
Sep 13, 2007, 7:16:50 AM9/13/07
to agile-...@googlegroups.com
i read the overview of Crystal in Alistair's book on Agile SD, though I didn't try it

for me it sounds a little but overcomplicated (comparing to Scrum)
would be nice to see someone trying it

Roman Muntyanu

unread,
Sep 13, 2007, 7:37:03 AM9/13/07
to agile-...@googlegroups.com
Nikolay,
List of recommended reading is a valuable answer for me (even though I cant measure it's value ;) )
Thanks for reasonable advices.

Max Pendyschtschuk

unread,
Sep 13, 2007, 8:05:11 AM9/13/07
to agile-...@googlegroups.com
> Never try to introduce practice just for fun. ;)
 
As I remember, in book "Practices of an Agile Developer Working in the
Real World" there is written, that team should find its "rythm" (so nobody can't dictate, only suggest)
 
About my company - we have some group of people (currently 3 - me and two managers), and we have a meeting (once a week), where we discuss problems of process etc. and how to find solution. This "working group" isn't "closed", anybody who want to join us can do it.

Alimenkou Nikolay <lumii.su...@gmail.com> schrieb:

Yahoo! Clever - Sie haben Fragen? Yahoo! Nutzer antworten Ihnen.

Alimenkou Nikolay

unread,
Sep 13, 2007, 8:55:09 AM9/13/07
to Agile Software Development Group, Ukraine
> that team should find its "rythm" (so nobody can't dictate, only suggest)

I completely agree with you.

Borys Lebeda

unread,
Sep 14, 2007, 8:34:43 AM9/14/07
to agile-...@googlegroups.com
IMHO, among all Agile practices XP and Scrum are the most valuable to learn. The main reason for that is following:
XP is pure development agile approach. It has no standpoints regarding managing development process.
Scrum is pure management agile. It's so generic, that can easily be applied not only to software development industy
 
The other agile approaches are more or less recombinations of this two.
Of course, some of them quite different, but with knowledge of XP and Scrum you can imagine what are others ...

 

Serhiy Yevtushenko

unread,
Sep 14, 2007, 3:57:19 PM9/14/07
to agile-...@googlegroups.com
Hi, Boris.

I have remarks concerning two points:
1. XP does have a project management part, it is not only pure engineering approach. IMHO, the language of Scrum is more easy to understand for business, but as concerning project management practices, there XP practices a quite similar, and provide more flexibility to business, than Scrum
2. I would agree at all that other Agile approaches are recombinations of this two.
XP and Scrum are most well known.
Have a look at FDD for very different agile approach. It is definetly not a recombination of XP and Scrum




2007/9/14, Borys Lebeda <borys....@gmail.com>:

Alimenkou Nikolay

unread,
Sep 15, 2007, 7:53:09 AM9/15/07
to Agile Software Development Group, Ukraine
XP and Scrum allow us to see positive examples of using Agile in
practice, but
while you don't know your team and your project you can't find the
best solution.
You have to build development process based on the experience from
another
teams and projects (don't forget about current team and project), but
not try to
adapt Scrum and XP to every case.

On Sep 14, 10:57 pm, "Serhiy Yevtushenko" <syevtushe...@gmail.com>
wrote:


> Hi, Boris.
>
> I have remarks concerning two points:
> 1. XP does have a project management part, it is not only pure engineering
> approach. IMHO, the language of Scrum is more easy to understand for
> business, but as concerning project management practices, there XP practices
> a quite similar, and provide more flexibility to business, than Scrum
> 2. I would agree at all that other Agile approaches are recombinations of
> this two.
> XP and Scrum are most well known.
> Have a look at FDD for very different agile approach. It is definetly not a
> recombination of XP and Scrum
>

> 2007/9/14, Borys Lebeda <borys.leb...@gmail.com>:


>
>
>
> > IMHO, among all Agile practices XP and Scrum are the most valuable to
> > learn. The main reason for that is following:
> > XP is pure development agile approach. It has no standpoints regarding
> > managing development process.
> > Scrum is pure management agile. It's so generic, that can easily
> > be applied not only to software development industy
>
> > The other agile approaches are more or less recombinations of this two.
> > Of course, some of them quite different, but with knowledge of XP and
> > Scrum you can imagine what are others ...
>

Borys Lebeda

unread,
Sep 15, 2007, 5:40:55 PM9/15/07
to agile-...@googlegroups.com
1. Huh, I think we have different points of view on project management. Could you please explain what XP practices you concern to be applied to the project management? Involving customer to the development process can be such standpoint, but XP doesn't stipulate much role distributions in team.
2. Yes, FDD looks quite different ... I should reconsider ...

 

Alexey Krivitsky

unread,
Sep 16, 2007, 1:49:05 PM9/16/07
to agile-...@googlegroups.com
Borys,

I think it is a well-know mistake to think of XP as a set of engineering practices only.
Have a look at the set of XP rules there is at least 1/4 relates to PM area.

- requirements areas (user stories come from XP)
- project planning area (release/iteration planning)
- velocity metrics, stand-up meetings (project tracking and oversight area)

Serge,
I think we can go even further and call a Scrum team that does XP engineering practices as an XP team?
Does it make sense?

// Alexey

Borys Lebeda

unread,
Sep 16, 2007, 3:17:57 PM9/16/07
to agile-...@googlegroups.com
On 9/16/07, Alexey Krivitsky <alexeyk...@gmail.com> wrote:
Borys,

I think it is a well-know mistake to think of XP as a set of engineering practices only.
Have a look at the set of XP rules there is at least 1/4 relates to PM area.

- requirements areas (user stories come from XP)
- project planning area (release/iteration planning)
- velocity metrics, stand-up meetings (project tracking and oversight area)
 
OK. I am just a spoiled child who thinks that enlisted tasks are not PM. Well, I'll keep them in mind.

Serge,
I think we can go even further and call a Scrum team that does XP engineering practices as an XP team?
Does it make sense?
 
it does for me :)

Alimenkou Nikolay

unread,
Sep 17, 2007, 3:15:32 AM9/17/07
to Agile Software Development Group, Ukraine
Completely agree with you.

On Sep 16, 8:49 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:


> Borys,
>
> I think it is a well-know mistake to think of XP as a set of engineering
> practices only.
> Have a look at the set of XP

> rules<http://www.extremeprogramming.org/rules.html>there is at least


> 1/4 relates to PM area.
>
> - requirements areas (user stories come from XP)
> - project planning area (release/iteration planning)
> - velocity metrics, stand-up meetings (project tracking and oversight area)
>
> Serge,
> I think we can go even further and call a Scrum team that does XP
> engineering practices as an XP team?
> Does it make sense?
>
> // Alexey
>

> On 9/15/07, Borys Lebeda <borys.leb...@gmail.com> wrote:
>
> > 1. Huh, I think we have different points of view on project management.
> > Could you please explain what XP practices you concern to be applied to the
> > project management? Involving customer to the development process can be
> > such standpoint, but XP doesn't stipulate much role distributions in team.
> > 2. Yes, FDD looks quite different ... I should reconsider ...
>

> > On 9/14/07, Serhiy Yevtushenko <syevtushe...@gmail.com> wrote:
>
> > > Hi, Boris.
>
> > > I have remarks concerning two points:
> > > 1. XP does have a project management part, it is not only pure
> > > engineering approach. IMHO, the language of Scrum is more easy to understand
> > > for business, but as concerning project management practices, there XP
> > > practices a quite similar, and provide more flexibility to business, than
> > > Scrum
> > > 2. I would agree at all that other Agile approaches are recombinations
> > > of this two.
> > > XP and Scrum are most well known.
> > > Have a look at FDD for very different agile approach. It is definetly
> > > not a recombination of XP and Scrum
>

> > > 2007/9/14, Borys Lebeda <borys.leb...@gmail.com>:


>
> > > > IMHO, among all Agile practices XP and Scrum are the most valuable to
> > > > learn. The main reason for that is following:
> > > > XP is pure development agile approach. It has no standpoints regarding
> > > > managing development process.
> > > > Scrum is pure management agile. It's so generic, that can easily
> > > > be applied not only to software development industy
>
> > > > The other agile approaches are more or less recombinations of this
> > > > two.
> > > > Of course, some of them quite different, but with knowledge of XP and
> > > > Scrum you can imagine what are others ...
>

Reply all
Reply to author
Forward
0 new messages