File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Agile and Other Processes and the fly likes Agility & Discipline Made Easy: People factors? 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 & Discipline Made Easy: People factors?" Watch "Agility & Discipline Made Easy: People factors?" New topic
Author

Agility & Discipline Made Easy: People factors?

Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
The Agile Manifesto states that its signatories value "people and there interactions over processes and tools". And as far as I can tell, it is a well accepted fact that practices and tools "only" have a second order effect on the success of a software development process, that the people working on it are its primary success factor.

How much does your book discuss those factors?


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
Per Kroll
author
Ranch Hand

Joined: Jul 19, 2006
Posts: 31
Iija,

yes, the cultural aspects dealing with how people collaborate are crucial, and are often the hardest to change, versus procedures dealing with a set of steps for doing something.

The collaborative and cultural aspects of agile development should be integrated into every practice, rather than described as a separate thing, and we believe we accomplished that. However, we also wanted to directly attack how individual team members need to change their view of what their role is. As an example, as an analyst, your job is not to document requirements. Who cares about that. Your job is to make sure that the intent of various stakeholders is properly reflected in the end application. So, if you documented the "right" requirements, but they were not implemented, you cannot say that it is the developers problem. Your responsibilities includes communicating with testers, developers, etc. to make sure that they understand what needs to be done, to yourself use the application to make sure that it reflects to intent of the stakeholders, etc., and better yet, working on fully integrating various stakeholder into the team. This topic of changing your perception of what your role is to function in an agile team is discussed in practice 7: Everyone owns the product!

We also have a practice 12: Build high-performance teams, which deals with instilling the right values, providing clarity, building trust, etc. This one is crucial, imho.

A key aspect of agile teams is that you have small teams, ideally collocated, with high-bandwidth communication. How do you accomplish this with a 40-person team? Practice 13 deals with how to organize a larger team into smaller teams-of-teams organized around components.

So, these are some examples of specific practices focusing on the collabrative aspects, but you cannot separate collaboration from other practices on doing things, so the book really incorporates collaboration into the various practices.

Cheers

/Per
George Stoianov
Ranch Hand

Joined: Jan 15, 2006
Posts: 94
Does your book also discuss Agile programming compared to Object Oriented for example. I am completely unfamiliar with this so I am curious to know how suitable it is for someone with no knowledge on the subject.

Thanks.
George
vishwanath nadimpally
Ranch Hand

Joined: Jan 25, 2005
Posts: 116
I have heard about Agile programming and my manager keeps reading a lot about it. But how different it is from any other programming framework or work flow I wonder?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Per, thanks for your answer!

Originally posted by Per Kroll:
A key aspect of agile teams is that you have small teams, ideally collocated, with high-bandwidth communication. How do you accomplish this with a 40-person team? Practice 13 deals with how to organize a larger team into smaller teams-of-teams organized around components.


Do you know the works of Jutta Eckstein? I've heard her say that being Agile might be harder with bigger teams, but actually also is even more important...
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by George Stoianov:
Does your book also discuss Agile programming compared to Object Oriented for example. I am completely unfamiliar with this so I am curious to know how suitable it is for someone with no knowledge on the subject.


Agile Software Development an OOP are totally orthogonal concepts. Basically, the former is about how you organize your team, the latter about how you organize your code.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by vishwanath nadimpally:
I have heard about Agile programming and my manager keeps reading a lot about it. But how different it is from any other programming framework or work flow I wonder?


Agile Software Development is neither a framework nor a work flow. It's basically a set of Values and Principles that guide you in choosing how to organize your work. See http://www.agilemanifesto.org/
Per Kroll
author
Ranch Hand

Joined: Jul 19, 2006
Posts: 31
Iija, thanks for the book recommendation. No, I have not familiar with Jutta's book (but I think I was introduced to her at the Agile 2006 conference). Looks interesting, I will read it.

Cheers

/Per
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
I haven't read their book either - I never worked on that big teams yet. I've heard her talk at several occasions, though, and it has always been quite intriguing...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Agility & Discipline Made Easy: People factors?
 
Similar Threads
Sun shifts core Java unit from US to Bangalore, India
How long?? for certification
Netbeans for IDE, poseidon for UML design?
UML
can this be legal