The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot

The Old Forum

Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Are we Agile? Does it matter?

Inspired by

I'm not knowledgeable on any Agile processes.  I hope to eventually take one on (like Scrum) - partly because the process probably has value; partly because there's software (example: Rally) and people set up to make this work smoothly.  I'm trying to keep taking on worthwhile processes that help us towards this goal.  The essay (or really, Cockburn's checklist) makes me realize we're nowhere near one definition of Agile.


We build for a brand new (read: figuring out requirements as we move forward) market within banking software (read: documented process, software audits, etc.).  I've been steadily improving our process as we move forward.  Here's some of what we do now:

- FogBugz to assign features, bugs
- Subversion (linked with FB) for source control
- MediaWiki to store spec, documentation, software processes (build, etc.), naming standards, etc.
- GTalk IM for meetings (team is across the world)
- GoToMeeting (sometimes needed for meetings)
- C#, SQL Server for development
- Source Monitor for code quality
- NUnit for testing (lots of legacy code is not covered)
- Plan to move to continuous integration

- A few ultrasmart guys (too small for "team" to really jell)
- Lots of control over their work/hours/etc.
- Work hard, but have time for refactoring, learning new processes, etc.

- Log any feature ideas, bugs, etc. into FogBugz (no matter how minor)
- Case is discussed in fb until fully fleshed out and estimated
- Cases for next release (monthly) are pulled from pile by dev (looking for similar cases, priority, etc.) with review by me
- Case is implemented (code is checked in, functional requirements in spec are changed, subversion is linked to fb case number)
- Code is (sometimes) peer-reviewed to see if it matches spec, case, coding standards, etc.
- Case is checked by case writer and closed
- Release is used internally for a month (and fixes are made to correct new problems only) before releasing externally.
- Anyone can change processes, spec, etc. in wiki (but it's monitored in rss feed)


1) Are we Agile (or at least headed in that direction)?  Are we too process-heavy?
2) Does it matter if we're Agile?
3) Are there additional worthwhile steps as we move forward (before we try taking on a formal process)?
4) Can we be molded in Scrum, RUP, or something else?
5) Do we have anything obviously wrong in our process?

Bankstrong Send private email
Tuesday, May 29, 2007
Mike - as I've said before... if i could only get my wife to move to NJ!!!!

Seriously, your monthly release cycle is something that is common in SCRUM.

My only question: what about Team Meetings? How often do you have them? What is covered?

You're doing a lot of good stuff! Keep it up!
Patrick From An IBank Send private email
Tuesday, May 29, 2007
I don't see the part where the QA person tests the code...
Sassy Send private email
Tuesday, May 29, 2007
Is this your QA?

"Release is used internally for a month (and fixes are made to correct new problems only) before releasing externally."

Tuesday, May 29, 2007
Details on QA:
1) The case writer checks the case
2) case is also checked in review process (more than code review)
3) Unit tests are run (there's some lack of coverage)
4) We sometimes use an external testing firm (not as often as I'd like)
5) We're building some automated functional tests
6) We use software internally for a month before release
7) Source Monitor (particularly complexity metrics), code review, naming standards keep code at certain quality level
8) We try to assess underlying causes of bugs as well as individual cases.
Bankstrong Send private email
Tuesday, May 29, 2007
my only concern would be that the case writer might be the person who is fixing the bug...
Sassy Send private email
Tuesday, May 29, 2007
Sassy -

Good point.  People occasionally write their own case for a quick fix.  We're moving toward a rule that someone else must always write the case (for one thing, it makes coding a little more deliberate if you need to explain the idea beforehand).

I'm happy to get the process advice, but I'm even more concerned about whether we're Agile (and if it matters).  As one developer said, we're a little like the five blind men describing the elephant.  I'm just not sure I'd know Agile if it whacked me with a sack of hammers.

Bankstrong Send private email
Tuesday, May 29, 2007
Mike it sounds like you have a very sane process and decent people working there. I'd also say you fit in the agilist corner as far as methodologies go since you're doing the sprints.
Meghraj Reddy
Wednesday, May 30, 2007
mike - i remember when we got together and you asked if i wanted to work in a Big Company or Small Company. My answer was something to the effect of, "The size of the company doesn't matter. I don't want to stereotype.I want to work at a good company. "

My point being is I wouldn't get wrapped up in Agile or not. Have an effective process that produces great software. And from everything I can tell, you are a good company!
Patrick From An IBank Send private email
Wednesday, May 30, 2007
I've been working on agile teams for almost 7 years now and I've learned that if there is any one thing to take away from Agile it's this:

Do the Right Thing. Worry about if it fits someones definition of "Agile" later.

Since you're working in an iterative manner, you're already thinking in an agile way. Why are you doing this? What are your goals for the team and the organization?

Are you working on the highest value stuff first? Is your team capable of changing directions to take advantage of new information? Are you responding to your customers?

If the answers to those questions is yes, then you're doing very well. Who cares if it's "Agile" or not?

All you need to worry about now is adding practices to support the goals you've set for the team and the organization. This is something you'd have to do with any methodology you subscribe to.
Wednesday, May 30, 2007
"Do the Right Thing. "


There's following 'Agile', and there's being 'agile'.

All of these methodologies are tools.  Use what works for your project and organization.  Don't be afraid to try something new, but don't be afraid to modify or turf it if it's not working.  The same logic applies here that applies to programming languages, IDEs and any other development tool.

The big wins out of the noise around these methodologies tend to be a broader awareness of testing (unit tests, etc), a functioning build (continuous integration), not spending 6 months on a spec, and that long meetings suck. 

I've chatted with a number of local peers on the subject, folks who have tried full SCRUM or Agile implementations down to people who picked and chose.  Most have boiled down to some set of the above, with one or two adding a couple of other things.
Dan Fleet Send private email
Wednesday, May 30, 2007
You don't really describe the way that you and your team communicate and work on a daily basis, rather you describe the tools you use to do so. The Agile manifesto states:

"Individuals and interactions over processes and tools"

So basically if you are having short, efficient stand-up meetings every day, and people are talking to each other about their work whenever they can, either directly or via IM, you are on the road to being an agile team, regardless of the toolset.

The other core aspects of agile development for me are:

- Regular demonstration of working software to development team and stakeholders

- A 'big board', real or virtual (real is always better), that clearly indicates the progress of the current iteration

- Regular or continuous software builds that incorporate unit tests and other QA programs

But at the end of the day, it's about communication - constant, easy, efficient.
Wednesday, May 30, 2007
Hi All, you see, I'm a freshman in this field. But our company is adopt Agile Methodology. Yeah, So I get a good opportunity to join one project. I list what we use in this project below:

CruiseControl.NET---For CI
NUNIT--Do unit testing
Selenium--Do function testing
NAnt--Use togethor with CC.Net
NCover--Do coverage report
TWiki--Share the info we need and do dailyreport
BugZila--Open source Issue track system
Xplanner--Task assign
Google IM--For communication.
    The developer in China,U.S,Holand
Subversion--Source Control
SmartSVN foundation version--Subversion Client
and I have implement a post-commit hook for Subversion will info all developer which had modified.

Hector Send private email
Wednesday, May 30, 2007
And I will describe how we get our work done in next part.
Hector Send private email
Wednesday, May 30, 2007
Bruce, Dan -

My process goals are:
1) react quickly to changing requirements (don't spin in place, but don't get stuck on a path for too long)
2) build a solid enough process to satisfy auditors (and therefore, customers)
3) keep devs happy by routinizing the rote portions of the work (and make sure they understand following process in these areas leaves them *more* room to think - about the product or improving the process)
4) allow new people to come aboard easier

I think we're responding to new info well (agile, not "Agile").  Ultimately, the reason why I care about "Agile" is so there's a roadmap to follow as we try to improve processes (we are figuring it out as we go right now).  A minor reason is so the devs can write "Agile" on their resumes (I figure the best way to keep someone good is to keep improving their employability).

Sam -

Good points.  I listed the tools partly because we are very dependent on them - and maybe this means we are not (and can't be) Agile.  We sometimes do a lot of work (and there's grumbling) to incorporate a new tool.  So far, each tool has made communication easier (after initial pain). 

I really believe the right tools are essential to communication for a distributed team (and Cockburn says since we don't use voice, we not Agile).  Further, I believe communication is not always through words (example: a case that is resolved and returned to me).  This may be distinctly unAgile.

Does the reliance on tools make us unAgile?  Does it matter?


We don't have certain Agile practices now (example, we occasionally chat during the day, but there is no standup meeting - probably because of tiny team).  Is this an indication that we are fundamentally not able to (gradually) shift toward an Agile process?

Bankstrong Send private email
Wednesday, May 30, 2007
Software development is dependent on tools, plain and simple. Remove the tools, and no-one could afford to build software anymore because it would take too long to construct anything of value.

As long as a tool contributes positively to your overall development process, it will contribute to an agile approach.

You should try to have stand-ups at the start of every workday, regardless of the size of your team. If your team is geographically distributed, use a tool to facilitate the meeting, as long as everyone can speak in real-time. Time zone boundaries may make this impossible, but see what you can do!

Obviously, the point of standing up is so that no-one gets comfortable, which keeps things going along quickly. Only one person speaks at a time, and they need to say, succinctly, what they worked on yesterday, what they will work on today, and if anything is affecting their progress.

There should ideally be one person that makes sure that these rules are adhered to - developers have a tendency to explore tangents a bit too readily.

If the meetings last longer than 5-10 minutes, then something is wrong. After a while, it will be innate for your team to do this.

Apologies if this is too Agile 101 for you, but for me stand-ups are at the core of agile development.
Wednesday, May 30, 2007
> Does the reliance on tools make us unAgile?  Does it matter?

Hell no. Agile is big on tools.

- Unit test frameworks
- Functional/Acceptance test frameworks
- Continuous integration engines
- Wikis
- IDE's with refactoring support (a big one)

Nothing wrong with using tools, especially if it allows people to spend more time on the important things.
Wednesday, May 30, 2007
"Does the reliance on tools make us unAgile?  Does it matter?"

No, agile benefits greatly from tools.  In fact, the better your tools, the more likely you are to get your developers to adopt the more positive agile techniques and practices.

Just don't become dogmatically married to a specific tool if a better one comes your way.  This includes being worried if you don't communicate via voice, but some manifesto indicates you should.

Agility implies the ability to balance on strange surfaces and react to change, of any sort, in a productive manner.

Likewise, don't let adherence to the method get in the way of shipping.
Dan Fleet Send private email
Wednesday, May 30, 2007
>> We don't have certain Agile practices now (example, we occasionally chat during the day, but there is no standup meeting - probably because of tiny team).  Is this an indication that we are fundamentally not able to (gradually) shift toward an Agile process? <<

Agile is just an attitude, not a methodology, set of tools, or set of practices. I think you're concerned about nothing.
Mark Pearce Send private email
Saturday, June 02, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz