aspose file tools*
The moose likes Agile and Other Processes and the fly likes Agility and Discipline Made Easy: What role plays technology? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Agility and Discipline Made Easy: What role plays technology?" Watch "Agility and Discipline Made Easy: What role plays technology?" New topic
Author

Agility and Discipline Made Easy: What role plays technology?

Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Hi Per and Bruce,

once you decide for a specific technology to go with, like J2EE, it becomes hard to mix technology and design.

How do you handle the technology issue in your book ?

Regards,
Darya


SCJP, SCJD, SCWCD, SCBCD
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Darya Akbari:
it becomes hard to mix technology and design.


I'm not sure I understand what you are talking about - could you please elaborate? Thanks!


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Hi,

isn't the aspect of technology important ? What sense does it make to talk about a theory (Agile Methodology) when you don't take the technology into account?

You can say lots of nice things about methods and principles. But they have to work in combination with the technology.

It's not only that you can extract a clean use case from whatever artifact like a requirement specification. You have also to think how to bring this use case with your technology to work.

Doesn't it depends on your techonology how you create your issue list, your estimates, your planning, etc. ?

Regards,
Darya
Per Kroll
author
Ranch Hand

Joined: Jul 19, 2006
Posts: 31
Darya,

the book focus on good engineering practices that work for most types of technology. As an example, I can do iterative development no matter what technology your are using. With some technologies it is easier than with others, but the overall thinking about how to approach the problem of iterative development.

Sure, when you go into more code-centric practices such as automated testing, you may find yourself in an environment that provides no tools for test automation, and it would be hard for you to follow that practice, but assuming that you have automated test tools for your environment, it does not really matter that much whether you work on J2EE or .NET, as an example. Similar tools with similar capabilities are available to you.

So, I think that you will find that most practices work well with most technologies.

Actually, if you look at what has been good software engineering practices, many of them are quite old. We want to think that we are so state of the art, but practices that were known +15 years ago to lead to better software, such as iterative development, are still not very broadly adopted... and they have nothing to do with technology, but all about changing the culture and the way we work...

Does this help? Cheers

/Per
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Darya Akbari:

Doesn't it depends on your techonology how you create your issue list, your estimates, your planning, etc. ?


No, not in any significant way.

Why do you think it should? Can you give an example?
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Originally posted by Ilja Preuss:

No, not in any significant way.

Why do you think it should? Can you give an example?


Hi Ilja,

was that your answer on my question? Instead of asking me a 2nd question, how about answering my 1st question ?

Regards,
Darya
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Hi Per,

I am not sure why technology, even when its orthogonal as Ilja like to say, should not be an issue in Agile processes.

If I only wanted to describe the rules of Agile processes then I think an article (say 5 to 10 pages) would be enough, but not a whole book. The rest would be to link to Tom DeMarco or books that are concerned on how to motivate people.

Let's stay with the issue list. I think this artifact is in every Agile process. If transaction management, securitty, persistence etc. is important for the customer, then they too should be important for all Agile processes. Since these requirements depend on technology I would say that the technology also must play a part in Agile processes.

If I don't include such issues into the issue list, how can I do my planning?

Regards,
Darya
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Darya Akbari:
was that your answer on my question?


Yes, it was. Wasn't it?


Instead of asking me a 2nd question, how about answering my 1st question ?


It's hard for me to answer your question in a more specific way without knowing more about where you are coming from.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Darya Akbari:
If I only wanted to describe the rules of Agile processes then I think an article (say 5 to 10 pages) would be enough, but not a whole book.


Well, I'm not sure why you would think that. The fact is that there are whole books out there about *single practices*, such as planning, pair programming or test driven development.



Let's stay with the issue list. I think this artifact is in every Agile process.


Can you please explain what exactly you mean by an "issue list"? Is that some kind of list of requirements? Or a list of risks? Or...?
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Originally posted by Ilja Preuss:
Can you please explain what exactly you mean by an "issue list"? Is that some kind of list of requirements? Or a list of risks? Or...?


A issue list is simply a list of business activities you need to implement .

Regards,
Darya
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Darya Akbari:

A issue list is simply a list of business activities you need to implement .


OK, thanks.

Yes, of course Agile approches have such things. In Scrum it's called a product backlog, in XP it's a stack of story cards etc. pp.

And of course the technology you use will impact what kinds of "issues" (stories, backlog items, whatever you call them) they will contain. And the technology will have an impact on how big the estimates are etc.

But the way you work with that data, the process you use to write down those issues, to organize them and to decide which to implement when - I don't see why that should be impacted by the technology you use.

For example, say the customers wants users to be able to log on at a webpage. XP would ask him to write a story card that says something like "log in" on it and present it in the planning meeting. The developers then write an estimate on it (say, a "2"), and the customer decides when to implement it.

That approach works whether you are using J2EE, Ruby on Rails or Seaside to implement the feature. Of course, if the team uses Seaside, the estimate might be a "1" instead (just for the sake of this example), and the customer therefore might come to a different decision about implementation time, but the rest of the process totally stays the same.

Does that sound reasonable?
Per Kroll
author
Ranch Hand

Joined: Jul 19, 2006
Posts: 31
Just to add to Iija's great responses...

The book is describing primairly 20 practices. Each practice is described as a pattern. What problem does it solve, the context within you can apply it, and a parameterized solution.

Patterns are reusable solutions to common problems. We have design patters, analysis patterns, business patterns, process patterns, ... Each type of pattern seek to focus on a defining a resuable solution to a common problem, but forces you to fill in many of the details based on your context. So, just as you can provide a design pattern that applies equally well to J2EE adn .NET, you can provide process patterns that work equally well for J2EE and .NET. Some process patterns may work equally well for large and small teams, others will not. It all depends on the context within it applies... In our case, the patterns we choose are fairly technology independent...

See other thread on this forum on J2EE vs. Agile Development for similar type of discussion....

Cheers

/Per
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Hi,

I miss the Object Model in your talk and the Object Model's dependency on the technology.

As far as I know, eXtreme Programming or Scrum even live without an Object Model.

How can one just list all issues and have not the technologies and Object Model in it listed. I'm still not sure what value it has when we don't go the details of whether we do for example the persistence with Hibernate, JDO, etc.

Just saying "persistence" is not worth anything to me . Especially when you use the list to make your estimates or to track your progress or else.

By the way, my concerns are one of the concerns (maybe the most important) why agile methodology are not adapted in the pace as we all like them to be adapted. It's simply because they are finally not talking about technology but leave it for others.

This is not best practice :roll: .

Regards,
Darya
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Darya Akbari:
I'm still not sure what value it has when we don't go the details of whether we do for example the persistence with Hibernate, JDO, etc.


Then why you don't simply talk about those details? It's not as if XP is forbidding you to do so...

XP, or any other approach to software development as far as I can tell, certainly isn't complete in the sense that you simply follow it rigidly by the letter and magically the outcome will be good software.

What Agile processes give you is a framework which helps teams to communicate and collaborate effectively, with massive amount of concrete feedback. It is then assumed that mature and motivated team members will learn quickly to make the right decisions.

In you example, a team would be required by XP to come up with a good estimate for a story like "user is able to see his data the next day", which clearly needs some form of persistence. If the team can come up with a good estimate without talking about technology, good for everyone - we have just saved some amount of time that can be invested in something more valuable. If the need to talk about, the will do, because they are required to give that estimate. If talking doesn't help coming up with a good answer in a reasonable amount of time, XP suggests to do a focused, time-boxed experiment.

Again, all of this is so general that it would work for a wide range of issues - no need to talk about any technology in specific.
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Hi Ilja,

do you agree, that all Agile processes can describe their rules in 5 to 10 pages ?

Any book then, that talk about Agile is more about psychology on how to motivate the team so it adapts to the 10 page rules.

Regards,
Darya
[ September 29, 2006: Message edited by: Darya Akbari ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Darya Akbari:
do you agree, that all Agile processes can describe their rules in 5 to 10 pages ?


I could describe the practices of XP in half a page. That doesn't mean, though, that after reading that page you would be able to effectively implement them in your team.

I recently gave a three hour tutorial on information radiators at a conference. And I would have much more to say about them than fit into those three hours. And that's a practice that typically only gets half a page of mentioning in current Agile books.


Any book then, that talk about Agile is more about psychology on how to motivate the team so it adapts to the 10 page rules.


Can you please give examples of books that you have read and that you feel about this way? I'm interested because I read a lot of books about Agile techniques, and although there certainly is a lot about psychology, there also seems to be an immense amount of practical advice on how to implement the values and principle in concrete practices.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Gian Franco Casula:
The agile concepts are not so difficult to grasp
really.


I'm not so sure.

What I'm sure is that it's not nearly as easy to actually put them into practice.

There are many teams out there struggling with how to actually plan their releases and iterations, how test their code, how to pair programming so that it doesn't feel bad and is effective, how to refactor their code, how to refactor their database, how to hold effective iteration retrospectives, how to include the customer in the team etc. pp.

And I think it's good that there are books out there giving more advice on those issues than just an overview on a few pages.
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Originally posted by Ilja Preuss:
Can you please give examples of books that you have read and that you feel about this way? I'm interested because I read a lot of books about Agile techniques, and although there certainly is a lot about psychology, there also seems to be an immense amount of practical advice on how to implement the values and principle in concrete practices.


I must admit that not only psychology but also best practices are discussed in all Agile books. However each methodologist (XP, Scrum, etc.) is of course only providing his best practices. If you add them all together you end up with tons of best practices. Isn't that more disturbing than helpful? Or should we first choose the best practices from these tons of best practices .

Ilja, you say that you've read lots of Agile books. Isn't that a characteristic that there is something wrong with Agile? Do you think that all your team member must go through this? The fact that there are such a lot competing Agile processes out there is for me a sign that we are still far ahead of being Agile.

It's sometimes laughable how people from one trench (say XP) attack people from other trenches and bite each other. We must end this nonsense and come out with one set of best practices and that's it.

Maybe this book is the first one that replaces all others which would be to my opinion best. On the other hand, I am very sceptical about it, because this book is also adding a new Agile process (OpenUP) to the existing ones .

Sorry, I got side-tracked from technology .

Regards,
Darya
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Darya Akbari:
I must admit that not only psychology but also best practices are discussed in all Agile books.


Yes. And still you seem to think that all the books are *mostly* about psychology, that the technical content can be reduced to, say, 10 pages, don't you? I'd still be interested in hearing some book titles. Seriously.

However each methodologist (XP, Scrum, etc.) is of course only providing his best practices. If you add them all together you end up with tons of best practices. Isn't that more disturbing than helpful?


No, it's more helpful, to me. Software development is a complex activity, and every trick that I can add to my bag is a good thing.

Or should we first choose the best practices from these tons of best practices .


I think the Shu Ha Ri model is suitable here. When you are at the Shu level, new to Agile development, you need strong guidance (a cookbook). Pick one of the Agile processes (I think XP is good for beginners) and follow it closely to learn how it works.

Once you get comfortable to using that one process, you reach the Ha level, where you start looking beyond your own nose. You look what alternatives other approaches have to offer to solve your problems and experiment with variants of your process.

Finally, after years - if not decades - of experience, you reach the Ri level, where you don't care about what approach you are following - you just have a big bag of tricks and apply it intuitively.

Ilja, you say that you've read lots of Agile books. Isn't that a characteristic that there is something wrong with Agile? Do you think that all your team member must go through this?


No, I don't think that it's a sign for something being wrong with Agile.

And no, I don't think that all my team members must go through it. There are also a lot of books about databases out there, but I don't need to read them all. Our database expert can do that - and he can rely on me being the process expert.


The fact that there are such a lot competing Agile processes out there is for me a sign that we are still far ahead of being Agile.


I agree that there is *some* competition out there, and that it's bad. But that has more to do with how the processes are marketed than with them existing at all.

Saying that Scrum, for example, competes with XP is like saying that a cheeseburger competes with bacon burgers. They really aren't competing - they are basically the same thing, slightly varied to serve different tastes. Searching for the one burger that is the right thing for everyone doesn't sound like a good idea to me. It's better when people just start with the one that looks most palatable to them, from time to time try a different one, and finally come up with their own favorite recipe.

It's sometimes laughable how people from one trench (say XP) attack people from other trenches and bite each other. We must end this nonsense and come out with one set of best practices and that's it.


I agree that the attacking is laughable. Well, no, in fact it's sad. I wished I could make it stop. Fortunately, there are members of the Agile community who are aware of this problem. See http://forum.agilesoftwaredevelopment.org/viewthread.php?tid=76

I don't think that one set of best practices is the answer, though. That would just create a second RUP.

Maybe this book is the first one that replaces all others which would be to my opinion best.


I don't think it will. I think it was in another thread where Per indicated that they actually disagree with some details of XP, for example. So this isn't exactly a unification, but more like another variant, or so it seems to me.

Which I actually don't think is a bad thing - it's what will make this book valuable to me! I'm in need of as many different perspectives on software development as I can get - as long as they fit into my value system, which closely aligns with the Agile one.

I think the best "Agile unification book" out there, which is more about philosphy than about practices, though, is "Agile Software Development Ecosystems". Highly recommended.
Per Kroll
author
Ranch Hand

Joined: Jul 19, 2006
Posts: 31
I think unification of agile practices is a good thing. Everybody wants to brand their own agile approach. There is more in common than not for all of these processes... I believe that there is a value in driving unification, and I think the Eclipse Process Framework (EPF) has a good chance at accomplishing just that, see www.eclipse.org/epf/.

Lately, I have talked with Jim Highsmith, Bob (Unclebob) Martin, Mike Cohn, Rebecka Wirfsbrock, Scott Ambler, Alistair Cockburn, and many others about the notion of a consolidated agile framework, developed as an open source framework under the EPF project, and they are alll interested in the idea. I hope that we can shape a joint vision in the near future.

Right now, we have OpenUP available in EPF, and soon we will also have XP, Scrum, DSDM, Agile Modeling, Agile Database Refactoring, EssUP, and a few other agile processes. This would provide a lot of open source mateiral from different sources that can be used as a starting point for a consolidated agile framework...

The idea is not to force one view of how to do agile development, but rather seek a common framework that many different agile processes can use as a baseline. EPF provides the ability to reuse common elements, and then use those common elements to create variants.

Anyhow, stay tuned, check out EPF at www.eclipse.org/epf/, or better yet, get involved.... <Post a note on the EPF Newsgroup, or send an e-mail to the developer list, all info you needs is in the right column of the EPF Website.>

Cheers

/Per
Deborah Hartmann
Greenhorn

Joined: Oct 04, 2006
Posts: 1
Originally posted by Per Kroll:
...Right now, we have OpenUP available in EPF, and soon we will also have XP, Scrum, DSDM, Agile Modeling, Agile Database Refactoring, EssUP, and a few other agile processes. This would provide a lot of open source material from different sources that can be used as a starting point for a consolidated agile framework...

The idea is not to force one view of how to do agile development, but rather seek a common framework that many different agile processes can use as a baseline. EPF provides the ability to reuse common elements, and then use those common elements to create variants....
Maybe it's just me, but I find it much more friendly and enjoyable to go to a friend's home, where she has carefully chosen some foods that look and taste good together, a nice bottle of wine, some sparkling water... so I can enjoy the food but also really focus on the company at the table, which is the objective of the evening.

A busy buffet, with a hundred choices never pleases me nearly as much... it's the care that went into creating a harmonious plate that makes the home cooked meal so much more interesting.

I don't feel a burning need for a huge smorgasbord of agile techniques to mix and match and mismatch and experiment with. Heck, wasn't RUP that? Look what a mess so many people made out of that, though they had all the information available there to make good choices! Too much information, perhaps.

I'll watch what's happing with OpenUP with interest :-)
deb
Fintan Conway
Ranch Hand

Joined: Apr 03, 2002
Posts: 141
Originally posted by Ilja Preuss:
Searching for the one burger that is the right thing for everyone doesn't sound like a good idea to me.


What did the Buddhist monk say to the hotdog vendor?

Make me one with everything!


Sorry, sorry, sorry.

I just could not resist
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Deborah,

I love you

Regards,
Darya
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2906
Originally posted by Deborah Hartmann:
A busy buffet, with a hundred choices never pleases me nearly as much... it's the care that went into creating a harmonious plate that makes the home cooked meal so much more interesting.

I don't feel a burning need for a huge smorgasbord of agile techniques to mix and match and mismatch and experiment with.


If you want to press the food metaphor further then you have to look these two scenarios:
  • The amateur foodie who has a party coming up and buys a few cookbooks, selects a few a recipes and prepares them to the best of his/her abilities usually with a varying degree of success.
  • The host who has the means and decides to hire a cook/chef with experience in the planning and preparation of menus for these type of occasions and who is also willing to teach the host a few tricks and share insights that may only be relevant to this particular occasion.

  • The second scenario is more likely to end "successfully" (not to imply that the first one can�t be outrageously successful or that the second one can�t fail miserably � its all a matter of risk). However even the second scenario will not make you a cook/chef for all occasions to the level of competence of your mentor.

    A book can only do so much - it can show you what the options are - it can't take you by the hand and lead you through the storms ahead - for that you need a competent warm body and that's what agile mentors are for. However many of us aren't fortunate enough to have such a mentor at hand, so we are reduced to exploring as many options as we can and adopt those that seem to have value, and unfortunately that can be an error-prone process.


    "Don't succumb to the false authority of a tool or model. There is no substitute for thinking."
    Andy Hunt, Pragmatic Thinking & Learning: Refactor Your Wetware p.41
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Peer Reynders:

    A book can only do so much - it can show you what the options are - it can't take you by the hand and lead you through the storms ahead - for that you need a competent warm body and that's what agile mentors are for. However many of us aren't fortunate enough to have such a mentor at hand, so we are reduced to exploring as many options as we can and adopt those that seem to have value, and unfortunately that can be an error-prone process.


    I agree.

    And still I think that Deborah has a point: a book with a predefined menu - in contrast to one with many recipes to choose from to get your own menu - might well be a better starting point. And to start experimenting, it might actually be more helpful to take a look at other menus and start mixing ingredients from several ones, instead of just looking at a bunch of recipes and mixing those.
    Peer Reynders
    Bartender

    Joined: Aug 19, 2005
    Posts: 2906
    Hmm,
  • 3 major parts: Introduction - Guide - Reference
  • The Introduction covers the baseline and and overview basic elements.
  • The Guide contains a number of process instantiations (the "menus") presented as case studies justifying each included element and explaining its use, possibly entertaining some variations.
  • The Reference explains each framework element in detail using some standardized structure like: Motivation, Applicability, Consequences, Execution, Reference to Uses in the Guide, Related Elements, etc.


  • However in the absence of a mentor you still are left to your own devices to "look at other menus and start mixing ingredients from several ones".
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Agility and Discipline Made Easy: What role plays technology?
     
    Similar Threads
    About bad language usage in submiting profile
    Suggestion Needed - Drag & Drop UI Elements
    Updating a JSP session attribute and html code on mouse click
    Nested Subreport (2nd Level Report)
    WA #1.....word association