• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Agile Development - looking for more information

 
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,

I am trying to do some research into Agile development. I have found several sites that list what it is and its underlying principles and practices, however, what I really need are a more detailed look at the stages involved and the deliverables of each stage. Do I need to look at a particular implementation--XP, Scrum, Crystal, etc--to get these or are they some common stages and deliverables across all of these implementations?

Also, does anyone know of any links to stories of people trying to (un)successfully implementing Agile development into a development shop?
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Chris Johnston:
what I really need are a more detailed look at the stages involved and the deliverables of each stage. Do I need to look at a particular implementation--XP, Scrum, Crystal, etc--to get these or are they some common stages and deliverables across all of these implementations?


Here's a general pattern that more or less describes the various agile processes around:

1) the selling phase (getting the contract signed)

2) the inception phase (a week or two, maybe a month, where the development team together with the customers and other stakeholders brainstorm what the project is all about, what are the major functionalities required of the software, what architectural constraints can be foreseen, etc.)

3) the iteration phase (the development team together with customers starts to develop the software by means of looping through requirements gathering and prioritization, design, development and testing, every once in a while releasing an increment to be deployed to production)

Phase 3 will never stop. Or at least not until the stakeholders decide to kill the project/product.

Having presented that outline, I feel uncomfortable with using the term "phase" in describing agile software development. The whole notion of having phases tends to lead people back to their old habits of thinking in terms of a V-model and iterations being just checkpoints along a huge waterfall-style development phase instead of being real increments, units of value delivered to the customer.

Originally posted by Chris Johnston:
Also, does anyone know of any links to stories of people trying to (un)successfully implementing Agile development into a development shop?

You might want to hang out at the XP Yahoo! group for a while or browse the archives. There's a lot of history of obstacles in introducing/adopting an agile processes with and without resolutions.

Also, (and I'm sure you've already done at least some of this) I'd really recommend reading some of the literature on the topic such as the work of Jim Highsmith, Kent Beck, Alistair Cockburn, etc.
 
Chris Johnston
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the reply. I have been doing some reading across many of the different websites related to Agile development.

In each "phase", what would the deliverables or artifacts be, i.e., what documents would be produced and/or what do you have to show at the end of each iteration besides the code? Agile must require some documents to be produced---design documents, requirements of some kind, specifications, code review details, etc?
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Chris Johnston:
In each "phase", what would the deliverables or artifacts be, i.e., what documents would be produced and/or what do you have to show at the end of each iteration besides the code? Agile must require some documents to be produced---design documents, requirements of some kind, specifications, code review details, etc?


The exact documents and other non-code artifacts being produced in each stage will (ideally) vary between projects based on their respective needs. Here's what to me seems to be a pretty common set of artifacts:

1) The deliverables from the inception phase are the initial requirements, both functional and non-functional, represented in a compact format such as one-liners on index cards, brief abstracts in .txt files or Word documents or on a project website where everyone has write access. It's important that these deliverables are considered by all parties as being drafts and that they can and will be iterated upon when it comes the time to actually implement a particular requirement.

2) The deliverables from each iteration are first of all working, tested source code, and any other documentation the customer has prioritized into the iteration. Note that documentation should not be considered something the customer gets for free -- it takes a lot of effort to produce documentation and that effort will be away from implementing new features. The customer must prioritize documentation (and other non-development tasks) along with the "regular" requirements. The code may or may not be feasible for production deployment after each iteration (sometimes it just doesn't make financial sense to deploy a limited set of functionality to production), but it should always be production quality nevertheless.


Regarding design documents, code review reports, specifications, etc., that's all something that you have to decide on based on your project's needs. A good rule of thumb is to sit down every now and then and go through your process, questioning whether the practices you have in place are still worth their salt and whether you should perhaps adopt a new practice to handle things the team recognizes as being problematic and so forth. If you have a lot of documents that are never actually used, consider the rationale for writing them in the first place. If the code review reports are filed in writing in order to comply with a government policy, file those reports in writing. If those reports are written because you thought they might be useful at some point, think again.

Stop. Reflect. Adapt.

There's a saying that a good process never stays the same.
 
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You might find Agile Documentation to be of interest.

Agilists insist that you travel light by developing and then maintaining as little documentation as possible. You should also maxmize stakeholder investment and question the value of all of the documentation that you write, and ask if there is a better way to proceed. When you do this you quickly realize that documentation has very little to do with software development, and very much to do with enabling the bureaucrats among us to justify their existence.

- Scott
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Chris Johnston:
Agile must require some documents to be produced---design documents, requirements of some kind, specifications, code review details, etc?



Why? Of what value are those documents to the customer when he gets a system that he can put into production?
 
Chris Johnston
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I finally caught your attention Ilja, good. I was hoping you would join the discussion.

The artifacts and documents are of probably no good to the customer, but what about management and management's management and so on? What about trying to capture a developers intent in case they leave the team in the form of a design document?

I am in a shop with no development process at all, it is all very ad hoc right now and we are looking at putting into place some form of process. Currently in first place is RUP. To me this seems to be a bit heaving for our shop. However, it is probably going to be something that the managers will like because it contains a lot of documents and templates. It contains a lot of paper that can be used to jsutify the project.

I would like a more Agile development process be put in place. However, to appease the bosses, whatever process is used, it must contain documents and documentation.

I have been doing a fair bit of reading about Agile development, XP, and Crystal and nowhere do any of them say to not produce documents. Therefore, there must be some common artifacts that are created in each iteration and in each phase of an iteration.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Chris, if you need documentation to keep management happy, I'd suggest you do documentation. However, that doesn't exclude an agile process. Just pick those required documents wisely and especially the words your process documentation uses in describing those required documents.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This seems to be converging with another thread on design docs. The Agile methods that I pretend I understand focus intently on producing software from requirements. The authors and pundits never tell you not to do other things that people outside that focused activity require. You may have some luck negotiating reduced requirements from them, but maybe not.

You can treat those other poeple as customers, prioritize their document-producing stories along with all the others and see what documents cost you, but I wouldn't do that too literally. We just treat all that outside stuff as overhead; it shows up as slightly reduced velocity I suppose.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Chris Johnston:
The artifacts and documents are of probably no good to the customer, but what about management and management's management and so on?



They should get what they need, in the most effective way possible. *What* that is will very much depend on the type of project, type of organization, individual management people etc., so the Agile methods refrain from proposing some specific documents here.

What about trying to capture a developers intent in case they leave the team in the form of a design document?



A design document isn't very effective, mostly because in software development there is a whole lot of tacit knowledge involved - knowledge that is very hard to put down into written words. So if you rely too much on written documents, that knowledge will be lost.

Agile methods follow a different strategy: they try to disperse that knowledge *before* anyone leaves, mostly by close collaboration practices, such as design discussions on the white board, working together in a war room (fostering "osmotic communication") and pair programming.

With other words: you don't need that knowledge in the paper, but in the heads of your developers. Paper is just one communication media to use to get it into the heads, and in many cases not the most effective one.

Alistair Cockburn's "Agile Software Development" is a very good book on this topic.

It contains a lot of paper that can be used to jsutify the project.



In which way does paper justify a project for them? Can those needs be met in a more lightweight way?

However, to appease the bosses, whatever process is used, it must contain documents and documentation.



How would they feel about a burn down chart, that shows an uptodate projection of when the project will be finished at the current development rate?

What about an extensive set of Acceptance Tests (FitNesse style), that show exactly (and as formally as it can get) what the system should do, and what parts of it it already *is* doing?

I have been doing a fair bit of reading about Agile development, XP, and Crystal and nowhere do any of them say to not produce documents. Therefore, there must be some common artifacts that are created in each iteration and in each phase of an iteration.



The ones mentioned above are the ones that come closest, as far as I can tell.

There is also the Release Plan and the Iteration Plan, of course (or the Product Backlog, if you are using Scrum, for example).

But mostly Agile methods rely on the team to find out what documents they really need - because they assume that it will be different for every team, for every project, and even for different points of time in one project.
 
Chris Johnston
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I hear what you are saying about agile development and role of communication to disseminate ideas amongst the group. However, this is not going to sell well with the people above me. They are too concerned with figuring out how to integrate Microsoft Project into the process and tracking everything single little part of the project.

They need their little check marks on a page for some reason.

In addition, the programmers are accustomed to going off on their own and working on something till they are finished. Introducing something like pair programming would be a very hard sell.

For an organization that already contains way too much bureaucracy (in terms of levels of managers) and wants to introduce even more (in terms of documenting the development process) how does one go about selling them on the idea of Agile Development?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Chris Johnston:
They need their little check marks on a page for some reason.



Sounds unlikely that you will be able to achieve something before you understand that reason...

For an organization that already contains way too much bureaucracy (in terms of levels of managers) and wants to introduce even more (in terms of documenting the development process) how does one go about selling them on the idea of Agile Development?



Very slowly and carefully.

Which Agile technique do you think you would most benefit from?

I'd strongly suggest to get a copy of "Fearless Change": https://coderanch.com/t/93700/Book-Reviews/Fearless-Change-Patterns-Introducing-New
 
Scott Ambler
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If your management is truly interested in documentation, then you need to spend some time at www.agilemodeling.com. It has the most comprehensive discussion of modeling and documentation within agile projects available on the net, including a discussion of how to do these things on XP projects.

- Scott
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
MS Project! Make a one-page project with two or three-week iterations marching across & down the page. There ya go!

Seriously I put a bunch of iterations across the top of the page and make about 3 lines for each major release ... a long bar for coding, a short bar for QA, a milestone for production. Managers have more detail showing the lead times required to have external partners ready for the release date but no more detail in the coding activity.

More agile shops may tell you they don't need anything beyond the iterations because they can release any given iteration to production. Fine for them, not for me.
reply
    Bookmark Topic Watch Topic
  • New Topic