wood burning stoves*
The moose likes Agile and Other Processes and the fly likes Introducing agile at a company 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 "Introducing agile at a company" Watch "Introducing agile at a company" New topic
Author

Introducing agile at a company

Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
I am introducing agile to a large, Fortune 500 company that still uses COBOL. People seem willing and excited but it's very new. Does anyone have good recommendations to introduce agile?

Thus far I am doing the following....
1) I've had discussions with individuals about it.
2) I've handed out Advantages of User Stories for Requirements and Writing Contracts for Agile Development
3) We're going to have some group discussions shortly
4) We're starting with a small website (nothing complex, something everyone knows how to build) as a first trial
5) We're going to use XPlanner to give people more visibility into the process.

I'm also debating doing the XP Game Description. Has anyone tried it?

- Any other games people suggest?
- Any other reading materials (not books, but something lighter that people will definately read, not just browse through)?
- Any other suggestions for how to get people up to speed?


--Mark
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Mark Herschberg:
I am introducing agile to a large, Fortune 500 company that still uses COBOL. People seem willing and excited but it's very new. Does anyone have good recommendations to introduce agile?


I very highly recommend getting a copy of "Fearless Change" for yourself.

If this is (part of) your official job, you might also be interested in "Flawless Consulting", which has some very helpful things to say about on how to work out a (social) contract with your bosses.


5) We're going to use XPlanner to give people more visibility into the process.


Don't expect too much of a software tool. Ideally, you have someting tangible and very openly visible that *pushes* the information to people, like a wall of cards in a common work area. XPlanner still is very hidden and pull, in my experience. (Also note that XPlanner seems to be rather dead.)


I'm also debating doing the XP Game Description. Has anyone tried it?


Played it at an XP Day. Was a hell of fun, and quite insightful, I think.


- Any other reading materials (not books, but something lighter that people will definately read, not just browse through)?


You might want to start an internal blog, where people can report about their experiences and problems.


- Any other suggestions for how to get people up to speed?


Definitely do iteration retrospectives from the very beginning. http://www.jamesshore.com/Agile-Book/retrospectives.html is a good format to start with.


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
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
We're actually about to have a discussion later today about cards versus XPlanner. I've used Xplanner before and deador not, I found it valuable. Still, I want to give the team whatever it prefers.

Cards:
+ can touch them
+ easy to move around
+ visible to team on the wall
+ visible to others walking into the room
- no metrics


XPlanner:
+ easier to organize (we're expecting 500+ stories)
+ visible to anyone in the company
+ good metrics with graphical representations
- not as easy to see big picture
- not as tangible


Then we could consider hybrid models, such a cards + excel (for metrics), or XPlanner + current iteration cards (for the wall).

Any thoughts? What else have I missed?

--Mark
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
The James Shore article was a good recommendation. I've read Kerth, but this is a great framework for an itration retrospective.

--Mark
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Mark Herschberg:
The James Shore article was a good recommendation. I've read Kerth, but this is a great framework for an itration retrospective.

Regarding retrospectives, I just bumped into a blog entry on the topic by Jeremy Miller.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Mark Herschberg:
The James Shore article was a good recommendation. I've read Kerth, but this is a great framework for an itration retrospective.

--Mark


Yes, it was a great starter for us. After half a year, doing it once a week, it became stale, tought - so we are now adding more variability. Just something to watch out for in the long run...
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Mark Herschberg:
I've used Xplanner before and deador not, I found it valuable.


Well, we actually have some serious technical problems with the latest version, so having no perspective of them becoming fixed *is* an issue for our team.


Still, I want to give the team whatever it prefers.


Not a bad idea, although it's also good to remember that you can't fully assess the impact of something before you have given it a serious try. And it's always easier to add something than to remove it, therefore trying a minimal approach first is often a good idea, too.


Cards:
+ can touch them
+ easy to move around
+ visible to team on the wall
+ visible to others walking into the room
- no metrics


I would add

+ easy to use collaboratively


XPlanner:
+ easier to organize (we're expecting 500+ stories)


Can you tell more about this? Our management actually didn't find XPlanner adequate to organize release plans, because organizing a big amount of stories just was too tedious. I wonder what you do differently...


+ visible to anyone in the company


True.

I still plan to try a webcam on the story board at some time.


+ good metrics with graphical representations
- not as easy to see big picture
- not as tangible


We found that the metrics as presented by XPlanner were also too inflexible. We once tried Excel and put a printed chart on the wall, but finally decided to draw them manually, on flipcharts. We found this had the benefits of

- being easiest to adapt to our current needs,
- being most striking
- having to do it manually fostered thinking more deeply about the metrics


Then we could consider hybrid models, such a cards + excel (for metrics), or XPlanner + current iteration cards (for the wall).

Any thoughts? What else have I missed?


Hybrid models have the disadvantage of duplicated effort and data, but often they are the best approach. I think the best approach to come up with them is to start very simply, and to only fill in gaps iteratively when they show up and you don't have an idea how to fill it with the already used tools.
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
My $.02 is that while most meetings become stale after a few months ("moving on to Item 17) weekly update of...") which isn't great, the issue is more critical for "creative meetings." Such meetings include brainstorming sessions and retrospectives. While some structure is needed, keeping it new and differet helps stimulate creative ideas. I see this is a great format to start with, but I'll be pulling n different methods and techniques over the next few months just to mix it up.

We used XPlanner 0.7b2. What were the technical issues you found? How many stories did you have? We had I think somewhere between 100-150 and about 30 of them went into a 1 month sprint.

As a side note, what story size have you found works well? I've seen anything from a few days to a few weeks in methodology descriptions. I prefer a few days as the upper limit, but we may have to go slightly larger for some particular stories given that we're still defining the business.

The metrics with XPlanner seemed sufficent to me, but this was over a year ago, so maybe I'm forgetting something we wanted that it didn't have. What did you want that it didn't provide?

Of course, following the standard practice of reviews, if we don't like how we're doing it, we can switch later.

Does a webcam provide enough resolution that people can see it?

As for using cards and XPlanner, I agree 110% that it's a risk/problem duplicating work. That said, this is what the team thinks is most efficent. We'll keep the master record in XPlanner (one of the big concerns of team members, rightly or wrongly, is that physical cards can accidentally fall off the wall and get lost), and put stories (or maybe just story titles) for the current session on the wall.

On that note, have you used color coding schemes, and if so what works well?

--Mark
M Easter
Ranch Hand

Joined: Feb 11, 2007
Posts: 133
Originally posted by Mark Herschberg:
- Any other suggestions for how to get people up to speed?


It's andecdotal, but here's a real-world success story of a former client site of mine. They went from "fragile" to "agile" and drank the whole kool-aid. This article goes into test-driven development but it does contrast the progression somewhat. I'm guessing a lot of people can relate to the "before picture" with respect to cube farms and directionless meetings.

http://codetojoy.blogspot.com/2007/02/im-believer.html

[ May 04, 2007: Message edited by: M Easter ]
[ May 04, 2007: Message edited by: M Easter ]

M Easter
Software Composer - http://codetojoy.blogspot.com
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Mark Herschberg:
As a side note, what story size have you found works well? I've seen anything from a few days to a few weeks in methodology descriptions. I prefer a few days as the upper limit, but we may have to go slightly larger for some particular stories given that we're still defining the business.

Most of the smoothly going teams I've seen have used relatively small stories, each being max. 2-3 ideal days of work.
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
Out of interest, we are running approximately weekly iterations/releases at the moment, and any stories which even seem as if they might be more than a few days tend to get postponed.

Sometimes we get a story which we all agree has value, but it keeps getting postponed because it seems too complex/risky to tackle right now. In this sort of case we have an informal process of splitting it up into things which take at most two or three days. Then it gets done.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Mark Herschberg:
We used XPlanner 0.7b2. What were the technical issues you found?


We also have a 0.7bx version. One problem we have is that when you change the description or add a comment to a story/task, sometimes XPlanner would then hang when trying to view the story. And we aren't able to update to the latest beta, because the database update scripts don't work, according to our administrator.

How many stories did you have? We had I think somewhere between 100-150 and about 30 of them went into a 1 month sprint.


We have around 15-20 stories per weekly iteration.

As a side note, what story size have you found works well? I've seen anything from a few days to a few weeks in methodology descriptions. I prefer a few days as the upper limit, but we may have to go slightly larger for some particular stories given that we're still defining the business.


We find that anything above three person days is much too big.

I'm not sure I understand the reference to "still defining the business" - care to elaborate?

The metrics with XPlanner seemed sufficent to me, but this was over a year ago, so maybe I'm forgetting something we wanted that it didn't have. What did you want that it didn't provide?


Take a look at pages 15-16 at http://www.disy.net/fileadmin/disy_dokumente/pdf/events/irip-slides.pdf - the show three variants on burn up charts we used at different times in the project. Not only are they highly adapted to the current situation, they also very much evolved over their time of live.

Of course, following the standard practice of reviews, if we don't like how we're doing it, we can switch later.


Yes. Notice, though, that improving isn't always only about not doing what you don't like. It can also be about trying things to find out whether you might like them better. For example, most teams that now prefer open work spaces didn't know before they tried.


Does a webcam provide enough resolution that people can see it?


I don't know. That's why I want to try it at some time.


As for using cards and XPlanner, I agree 110% that it's a risk/problem duplicating work. That said, this is what the team thinks is most efficent.


Well, there is a risk involved in doing what you *think* is most efficient. Of course you can't try *everything*, but it's probably also not wise to totally ignore that risk.

(one of the big concerns of team members, rightly or wrongly, is that physical cards can accidentally fall off the wall and get lost)


Did you asses how likely that would be? What would the cost of a card getting lost?

I'm reminded of a story by Ron Jeffries: the C3 team - the one that invented XP - feared to loose cards, too. So they began scanning the cards for backup. In three years, they didn't use the scanned cards once.

On that note, have you used color coding schemes, and if so what works well?


We have tried several things. We now use colored cards to show which CVS branch a story needs to be implemented on. We give stories that touch the web frontend a colored border, because that is the strongest differentiator regarding expertise and partialities in our team. We use colored dots to indicate the state of a story: in progress, finished, blocked.
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Quick response. (I still have more to respond to.)

By "defining the business" I mean on most of your project you knew how the business worked, you mght be replacing a legacy system, or automating a process, or implementing a new process smeone dreamed up. Right now we're at the stage of, to use eBay as an anaology, "let's create an online auction house." Which leads to questions like "how do we make money?" "how do people register?" "what are the legal implications?" "how is money transfered?" "how is responsibile if something goes wrong?" We don't have those questions answered, since the business is onl a few weeks old. We're working through them.

One other question (I'll respond to your other comments tonight), on previous projects I've used "developer stories." That is the business owners never think about things like logging, but the developers, knowing that they'll need it, and not having it fit into any other stories, create what I've called "developer stories." These are stories they think should be a part of it. They don't add "direct" business value but do provide issues like stability and reliability to the system. It still gets to be prioritized by the business owners (although usually the developers get a little more influence in terms of pushing for these stories). How else do companies handle things like this?

--Mark
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
WRT to losing cards, I've discussed it, but the anxiety is still there. I have to pick my battles, and this is one I'm not going to fight now. Agile is uncomfortable enough for them. As I think they will get more comfortable with experience, I'll encourage them review this choice a few iterations down the road.

BTW, I picked up Cockburn's book. I skimmed it this weekend and noticed quite a few references to a certain practicioner and JavaRanch sheriff. :-)

--Mark
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Mark Herschberg:
One other question (I'll respond to your other comments tonight), on previous projects I've used "developer stories." That is the business owners never think about things like logging, but the developers, knowing that they'll need it, and not having it fit into any other stories, create what I've called "developer stories." These are stories they think should be a part of it. They don't add "direct" business value but do provide issues like stability and reliability to the system. It still gets to be prioritized by the business owners (although usually the developers get a little more influence in terms of pushing for these stories). How else do companies handle things like this?

Another term for this kind of items I've heard used a lot is "technical stories". You might want to try expressing such stories in a way that brings out the benefit to the business. For example, if you now have the following story...

Implement a uniform logging solution

...then that story could be expressed in a more business-friendly style as, for example...

Implement a uniform logging solution so that the mean time to fix a defect is reduced

That already makes the "indirect" business benefit explicit. You might even try to experiment with quantifying the improvement, if applicable.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Mark Herschberg:

By "defining the business" I mean on most of your project you knew how the business worked, you mght be replacing a legacy system, or automating a process, or implementing a new process smeone dreamed up. Right now we're at the stage of, to use eBay as an anaology, "let's create an online auction house." Which leads to questions like "how do we make money?" "how do people register?" "what are the legal implications?" "how is money transfered?" "how is responsibile if something goes wrong?" We don't have those questions answered, since the business is onl a few weeks old. We're working through them.


If I understood correctly, you said that this might lead to bigger stories that you can't break down further?

I'm wondering why that would be the case. And I actually wonder how you could implement a story that you can't possibly break down further.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Lasse Koskela:

Another term for this kind of items I've heard used a lot is "technical stories". You might want to try expressing such stories in a way that brings out the benefit to the business. For example, if you now have the following story...

Implement a uniform logging solution

...then that story could be expressed in a more business-friendly style as, for example...

Implement a uniform logging solution so that the mean time to fix a defect is reduced

That already makes the "indirect" business benefit explicit. You might even try to experiment with quantifying the improvement, if applicable.


Even better, in my opinion, is having the work done as part of stories coming from the customer.

When I'm working on a story where I think logging is necessary, I'll just implement it as part of the story. It's a technical decision, just like the decision to write a test, to refactor, or to use a for loop. I don't need to ask the customer to do that - if I subscribe to the idea that logging is part of developing a system effectively, it's just part of my professional behaviour.

When I implement logging in the second story, professional behaviour just asks me to not duplicate code. That will naturally lead me to a "uniform logging mechanism", as part of my normal work. No need to ask for permission to do that.

Assuming that we already have a working system where I think the logging is insufficient, I still don't need an explicit story. It's just part of my professional behavior that fixing a bug also includes reducing the likelihood of the same or a similar bug being introduced again, and when the bug was hard to fix because of missing information, making it easier to get that information in the future. So introducing logging - if it's the right solution - will just be a natural part of fixing a bug.

Well, that's the ideal, at least. I can't say that I always find I'm able to follow it, but that's what I'm trying to get closer to.

Does that sound reasonable?
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by Ilja Preuss:

If I understood correctly, you said that this might lead to bigger stories that you can't break down further?

I'm wondering why that would be the case. And I actually wonder how you could implement a story that you can't possibly break down further.


I wasn't being clear. Stories go through different phases of clarity, from "I have an idea" and you write a sentence on a card, to working code which implements a story.

That one sentence may be as vage as "create a rating system for sellers" on an e-commerce site. That story is more than 3 days. I actually call these mega-stories and have seen projects that might have 10-20 of them. This might break down into 4-5 stories which may be a few days to a week each--bigger than the metric we'd like. However, because it's a lower priority, we'll leave it on the backlog, only refining the stories when they need to be "focused" enough to get an "accurate" enough estimate for potential inclusion into a sprint. (Note: it may be we don't need it in this sprint, but the customer may want some clarification just to prioritize what to focus on in the next few sprints.)

Given that we don't fully understand how the business works yet some of the stories will have less clarification and thereful will be on the larger end of the spectrum as defined above. As we define the business more, those larger stories can more easily be broken down. Certainly by the time they are in a sprint, we'll need to have them well defined and withing our 3 day limit, but while on the backlog they may stay in larger chunks.



Originally posted by Ilja Preuss:

When I'm working on a story where I think logging is necessary, I'll just implement it as part of the story. It's a technical decision, just like the decision to write a test, to refactor, or to use a for loop. I don't need to ask the customer to do that - if I subscribe to the idea that logging is part of developing a system effectively, it's just part of my professional behaviour.

When I implement logging in the second story, professional behaviour just asks me to not duplicate code. That will naturally lead me to a "uniform logging mechanism", as part of my normal work. No need to ask for permission to do that.

Assuming that we already have a working system where I think the logging is insufficient, I still don't need an explicit story. It's just part of my professional behavior that fixing a bug also includes reducing the likelihood of the same or a similar bug being introduced again, and when the bug was hard to fix because of missing information, making it easier to get that information in the future. So introducing logging - if it's the right solution - will just be a natural part of fixing a bug.


I'm still dubious on this, but I think it gets back to our debate a few years back where I think one of the wekeaness of agile is sometimes you don't see the forrest for the trees (and I'm skeptical of walking skeletons and the spike method).


BTW, what other mailing lists/forums do you recommend for questions like these?


--Mark
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Looks like we won't go with XPlanner. It's giving us some trouble. I remember haven't a non-trivial install at a prior company, but my developers quickly figured it out. As my current client has architects who don't code, and sys admins who control acess to boxes, it's going to be more of a headache and not worth it.

We may go with a commercial product, but I'm not sure it's worth it.

Does anyone have any good burndown templates for excel? I've found some online, but was wondering if anyone had one they have used and liked. We'll stick to cards on the wall, but I want to have a burnchart chart and velocity measure.

--Mark
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Mark Herschberg:
Certainly by the time they are in a sprint, we'll need to have them well defined and withing our 3 day limit, but while on the backlog they may stay in larger chunks.


And that's exactly how you should do it, in my humble opinion. Thanks for the clarification.


I'm still dubious on this, but I think it gets back to our debate a few years back where I think one of the wekeaness of agile is sometimes you don't see the forrest for the trees (and I'm skeptical of walking skeletons and the spike method).


OK.

Just to be clear, to me that doesn't mean that the developers shouldn't talk about the need of a uniform logging mechanism, for example. But even then, it still can (and possibly should) be implemented in an incremental manner.


BTW, what other mailing lists/forums do you recommend for questions like these?


The lean development Yahoo group is of very high quality.
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
When trying to convince management to adopt agile, or anything for that matter, you need to talk their language. You might find that Pitching Agile to Senior Management provides some good advice.

- Scott


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Hi Scott,

Thanks for your input. I realize my question weren't clear. Senior management has signed off on agile, but the tricy parts are getting it adopted. This includes training people using it, working in a larger environment that operates with a different mentality, and getting people to understand different information flows.

For example, right now the CIO wants a set of milestone dates so that if we miss any of the dates, they can appear as alerts on her dashboard. With an MS project there would be clearly laid out dates by which certain tasks will be completed and we either hit them or we don't. Agile doesn't inherently promise any functionality by any date.

--Mark
[ May 11, 2007: Message edited by: Mark Herschberg ]
Michael Finney
Ranch Hand

Joined: Jan 25, 1999
Posts: 508
As you know, Extreme Programming promises as much functionality as possible by a certain date.

http://builder.com.com/5100-6374-5121760.html
Searching for "Manager rights" and noticing the "reflecting the investment to date." part.


Michael Finney - "Always Striving To Serve You Better Every Day"
http://www.smilingsoftwaresolutions.com/
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Mark Herschberg:
For example, right now the CIO wants a set of milestone dates so that if we miss any of the dates, they can appear as alerts on her dashboard.


What would she do with those alerts?
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Thanks Michael, good article.


Ilja, when the alerts arent' good she'll take action. It might be helpful action like removing obstacles; it could also be detrimental action such as requiring daily status reports. (Irregardless of what we may think of such actions, she thinks they are important and believes they work.)

--Mark
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
It's right that with an Agile approach you don't *promise* functionality by a date. But we still *project* on what functionality will likely be done by which date. And that projection should become more accurate the longer the project is under way. Sounds like that's the information the CIO really wants, doesn't she?

Would a burn chart, like used in Scrum, give her what she needs?
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
Sri Addanki
Ranch Hand

Joined: Apr 27, 2001
Posts: 195
Hi Mark,

I'm interested in knowing how it worked out at your company.

I'm trying to do the same at my company too.

Any tips? Also, did you check out Mingle from Thought Works?

http://studios.thoughtworks.com/mingle-project-intelligence

Thanks and appreciate all your help!
Stuart J W Bell
Greenhorn

Joined: Nov 23, 2006
Posts: 23
I worked for a small, Java development team and was one of the senior leads. We attempted to use various XP or Agile techniques, here is what worked:

- XP Game - gave people an idea of the principles of XP
- Whiteboards - we had three big ones on the walls around our area, great for technical discussion and promoting information.
- Co-locating our business teams - we had various representatives from the business areas sitting with our dev and test team. Having them on hand to answer questions and make decisions was invaluable.
- Continuous unit testing.
- Frequent builds.
- Using tools such as findbugs and checkstyle.
- Going lighter on documentation - we used a UML format for capturing information.
- Every second day we would have a 5 min stand up meeting.

Make sure that you keep management up to date with what you are doing. They need to have visible deliverables so that they are comfortable with the technique. We found that because we were not producing 300 page requirement docs or 500 page design docs, they got gittery and clamped down on us - causing a processing of retrospective documenting.

Personally, I wouldn't sling terms such as eXtreme Programming around and go for a hybrid approach. See what approaches would be easy for your organisation to adopt early on and slowly introduce each one. Remember it won't happen over night.

We never used anything like XPlanner, although the idea sounds good. I was very interested in calculating the team's velocity, but never got as far as that unfortuantely.

Hope that helps.


Stuart
Sri Addanki
Ranch Hand

Joined: Apr 27, 2001
Posts: 195
Thanks Stuart! Yes, I need to check on the XP Game too.

I apologize for the delay, I just checked your reply.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Introducing agile at a company
 
Similar Threads
How does Architecture fit with Agile?
Team size of Agile
The Art of Agile Development - is Agile for anybody
team size and scrum
When to use the point card "0" and "?"?