Git and Agile

[Glenn Block]

Hi guys

 

I know we just finished a nice thread about GIT, whether it's hot and why. We also talked about alternatives like Bazzar, Mercurial, etc...

 

A different question I have is do these tools (regardless of which one you use) actually support Agile development? Would you consider them an integral part of the agile shop of the future, or is it just "the way" to do it regardless. What I am really asking is are there specific benefits for those doing agile development?

 

Thanks

Glenn

[Justin Bozonier]

Git (or probably any DVCS) is great for agile development for me for the following reasons:

• Supports spiking unlike TFS/SVN/Others because: It decouples the notion of a check point (where I need to save the state of my working files) from the notion of publishing that state to the rest of my team. I can commit, branch, etc. all on my local machine and only the stuff I *publish* is.. well published. :)
• Network down? Who cares?? We can still work. Some companies I've worked at have had to send us home when the network went down simply because our VCS would freeze up and couldn't handle it (this was TFS '05 btw ;)
• Speed. Because everything is local I can commit, branch, w/e as fast as I can think just about.
• Adding/Deleting files: Once again SPEED. Give me the ability to sketch out my ideas like pencil to a paper but then give me the ability to carefully review my changes before I publish. I don't want to have to view every file change as a publication that's too much friction. I just want to romp around naked in the flowery meadow with my code until we've made life beautiful... then we'll get all dressed up for our formal picture to send out to the family. You know what I'm saying?? (I included that sentence as a bonus for anyone who actually read this far. Kudos to you!)

Github:

• I can go to any project and download the source extremely easily (because github practically tells me step by step what to type where)
• I can publish fixes to ANY project no matter how out of my league and...
• if I have something important to share the project leads can see my published changes without me needing special access to their project. And...
• They can easily integrate the changes if they so choose.

Stick a fork in me.

--
You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" group.
To post to this group, send email to altnet...@googlegroups.com.
To unsubscribe from this group, send email to altnetseattl...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en.

[Aaron Jensen]

Couldn't you remove the word "agile" from your reply and have it still be true? Nothing in there has anything to do with "agile". I don't think there is anything about the choice of a VCS that has to do with whether or not you are "agile". 

[Ade Miller]

These are all good points as to Git/Hg/… being better than TFS/SVN but they’re all things I want as a developer, agile or not right?

 

BTW: SVN supports offline (I use it a lot for this).

[David Foley]

Using a DVCS makes it a lot easier to keep the "master" branch clean by only integrating complete sets of work (for example working in a branch-per-feature model). This is all about easy branching & merging, which doesn't strictly _require_ a DVCS.

But, personally, I have not seen branch-per-feature work smoothly with a non-DVCS.

So, if you are making a choice between, say, git and svn, git does everything that svn does, plus a whole lot more that svn does not do, such as nearly-instant branch switching, working without a server connection, dealing with multiple remotes, better merging, preserving history across branches and merges, etc.

I'm in the way-to-do-it camp. I would like to hear from someone that has experience with both DVCS (git, hg, etc.) and server-based VCS (svn, TFS, etc.) who would make the argument against the distributed model. I don't think you will find too many people who will do that.

Now, one anti-git point (and it may apply more to git than to other DVCSes, I don't know) is that at least a couple times per month I have to help someone un-f@$k their git repository. I don't really mind this because it usually is a good learning experience (for both of us) and it's always been successful so far, but it does happen.

But: all source control systems have issues.

SVN has the "I accidentally copied the .svn folder to and now my local paths are totally fubared compared to the remote" problem. The problems I had with ClearCase, MKS, VSS and TFS were so numerous that it would almost be easier to list the times they actually worked correctly.

For me personally, even the thought of SVN, which seemed good enough at the time when I was using it day-to-day, is scary.
Maybe part of this is that I often have the source-control/code-review/merge/release-management roles on teams, and git makes that so much less painful.

[Justin Rudd]

This pretty much sums up what I was thinking.  But I don't know if I would call it "agile" (nothing about any of this is TDD/BDD/WhateverDD).  I've got projects where I didn't write any tests, no stories, nothing (*gasp*) and used all the things listed below (quick checkins, branching, etc).  It made the project itself more agile, but not "agile".

On Thu, Jan 14, 2010 at 9:29 AM, Justin Bozonier <darkx...@gmail.com> wrote:

[Glenn Block]

It's obvious that GIT/GitHub is not specifically designed to support agile practices. Agile in the traditional sense seems to be a dying bread anyway, meaning the strict "I am agile". However the question I have is for folks doing TDD, BDD, CI, etc would they see GIT/GitHub as an important part of their arsenal.

 

Glenn

[Glenn Block]

How does that relate to how it fits with Agile practices (or not)? Or are you implcitly saying "Not"

[Justin Bozonier]

Couldn't you remove the word "agile" from a lot of agile practices and patterns and say that's what all devs should want and could adopt individually?

The question I think Glenn was asking is is Git or DVCS integral in your agile development process? To which I say yes it is.

Non-Agile devs could do unit testing for example. But A) a lot don't B) just because they do doesn't mean unit testing isn't important to "agile" devs.

[Glenn Block]

I think Justin nailed it about the question.

[David Foley]

I think of branch-per-feature as an "agile" practice.

[Aaron Jensen]

Let's say what we mean then instead of obscuring it behind the word "agile"

Call them what they are. "Good" Devs, or Devs that "value learning and improvement".

Not trying to be pedantic here, but I think it's time we step out from behind the "mystique" (though now-a-days it is only mysterious to a few) of agile  and start putting the focus on learning, improving and thinking rather pointing people to some 9 year old manifesto ;)

[Glenn Block]

Dude, I so agree. Symbols like "Agile" can totally get in the way.

[Charlie Poole]

Hi Glenn,

 

I consider DVCS to be agile on a philosophical and practical level.

 

Philosophically, agile is supposed to be *not* so much about tools. DVCSs remove many of

the restrictions imposed by centralized tools. Most of them work well in either mode, so a team

can set up it's own practices and not be limited by what the tool can do.

 

One proof of this is that some shops forbid DVCSs because they don't give enough central

control over developers - a very non-agile viewpoint.

 

In practical terms, a DVCS allows me to work how and where I want, creating a feature

branch if I need to, or keeping a common personal branch for small changes. I can work

quickly on a spike, throwing it all away or merging it in as I like. This is something I used

to do with multiple workspaces under SVN or CVS, but when I wanted to merge two

different workspaces without touching the repository, I had to do it manually.

 

So I'd say that DVCSs are a win no matter how you develop, but are a particularly

good fit for agile development.

 

Charlie

 

---

From: altnet...@googlegroups.com [mailto:altnet...@googlegroups.com] On Behalf Of Glenn Block
Sent: Thursday, January 14, 2010 9:08 AM
To: altnet...@googlegroups.com
Subject: Git and Agile

[Charlie Poole]

Hmmm... It sure all has to do with my definition of agile. Maybe we should trade definitions. :-)

 

I don't think Justin is saying you *must* have a DVCS to be agile - only that it's a really

good fit.

 

Charlie

---

From: altnet...@googlegroups.com [mailto:altnet...@googlegroups.com] On Behalf Of Aaron Jensen
Sent: Thursday, January 14, 2010 9:37 AM

To: altnet...@googlegroups.com
Subject: Re: Git and Agile

[Charlie Poole]

Ah... the "Agile is defined as a set of practices" definition. :-)

 

As soon as you start telling people how to do things, agile is out of the building.

 

Charlie

---

From: altnet...@googlegroups.com [mailto:altnet...@googlegroups.com] On Behalf Of Justin Rudd
Sent: Thursday, January 14, 2010 9:41 AM

To: altnet...@googlegroups.com
Subject: Re: Git and Agile

[Charlie Poole]

Hi Justin,

 

I'm with you. You can even do TDD in a non-agile project - it's better than not doing it.

Nevertheless, TDD helps you be agile if you use it right. Same with DVCSs.

 

Charlie

---

From: altnet...@googlegroups.com [mailto:altnet...@googlegroups.com] On Behalf Of Justin Bozonier
Sent: Thursday, January 14, 2010 9:44 AM

To: altnet...@googlegroups.com
Subject: Re: Git and Agile

[Charlie Poole]

I do too. But I also think of single-code-line (which is pretty much the opposite)

as an agile practice when used by some teams.

 

Charlie

---

From: altnet...@googlegroups.com [mailto:altnet...@googlegroups.com] On Behalf Of David Foley
Sent: Thursday, January 14, 2010 9:54 AM

To: altnet...@googlegroups.com
Subject: Re: Git and Agile

[Charlie Poole]

Well, we have to use symbols of some kind. For me "agile" has a very definite meaning,

much more definite than "good"

 

As far as the manifesto goes, I think it does the proper job of a manifesto, which is

not to instruct or provide a cookbook, but to inspire. Based on that inspiration, thousands

of programmers have figured out different ways to work, so it has been good for something.

 

Now we're living in a more cynical age, where people want things to be spelled out,

tied down and proven with data. They try to create recipes to replace that vague

manifesto. Schwaber says that as soon as you reduce Scrum to a cookbook, it's

no longer Scrum. I'd say the same for agile.

 

With my clients, I define agile as "Rapid, incremental delivery of well-tested software."

I suppose someone could say that's not specific to agile, but I like it. If you're doing

that (not just hoping to) you're agile, if you aren't (even if you do TDD) you're not.

 

Charlie

---

From: altnet...@googlegroups.com [mailto:altnet...@googlegroups.com] On Behalf Of Aaron Jensen
Sent: Thursday, January 14, 2010 10:05 AM

To: altnet...@googlegroups.com
Subject: Re: Git and Agile

[Robert Ream]

Does a DVCS help your team:

1) facilitate and improve interactions between individuals
2) produce *working* software
3) collaborate with the customer better
4) respond to change better

 

I'd say if it does any of these things without impeding any of the others, then I would consider it to be Agile©. Although I would not say that tools are orthogonal to "agility", they are a secondary concern: interactions and individuals over tools right? The value a tool provides your team regarding 1-4 can help answer the question of the tool's "agility", and with value being subjective and all, the arguments pro or con are always contingent upon circumstance.

 

Sure, as Martin Fowler has said, the word has suffered from "semantic diffusion", but I agree with Charlie and don't at all find the ideas that the manifesto articulated to be dated, and by implication without utility.
 

[Aaron Jensen]

I wasn't trying to imply that the manifesto if lacking utility. I just worry that labeling Git as an "Agile" tool allows people to dismiss it wholesale when they're not "Agile". Perhaps that is an unfounded worry.

Git certainly does help agile teams accomplish their goal. I do not dispute that. It also helps people that do not necessarily and/or knowingly subscribe to Agile. 

Aaron

[Glenn Block]

Agree on both. My point on prescriptive agile dying is the "blind following" of agile principles just because they are well "agile". I see more and more folks looking at "what works".

 

Glenn

[Glenn Block]

I agree Charlie. I wasn't intending to imply that you MUST use it.

 

Glenn

[Glenn Block]

My position really resonates with Dave's and yours. Which is "No, it is NOT an agile tool". It is a tool that fits very well with teams that are adhering to agile principles and practices. Though it provides benefits to those that aren't as well.

[Jeffrey Palermo]

Every VCS supports agile.  Agile is the way the team works with the VCS, not the other way around.  DVCS systems make branch-per-developer seamless.  With Subversion, it is easy to have multiple people working off the trunk, and the merging is great.  Tools like JetBrains TeamCity will do auto-patch-upload and run the private build remotely at any time so you have build-per-developer without waiting for the local machine.

TFS and VersionManager need more work in order to have multiple people making changes to the same files simultaneously, but agile teams still use them.

Also, the VCS features have a lot more to do with supporting a team SIZE, not a team PROCESS or PHILOSOPHY.  A BDUF team of 2 and an agile team of 2 will probably have similar experiences in wide range of VCS's.  BDUG teams of 10 and agile teams of 10 will have VERY different experiences based on the VCS in place.

I think the essence of the situation is providing the most versioned "levels of undo" possible.  In John Maeda's The Laws of Simplicity book, he talks about how putting "undo" everywhere makes the experience of using a product seem simpler.  It may not be simpler, but the impression is that it IS simpler.  With Git (the only DVCS I have experience with),:

1. I can revert a local commit
2. I can revert a push to my fork
3. I can revert a pull to the master
4. I can revert a commit on the master
5. I can revert a push to the master

With a centralized system, I can only revert a commit to the centralized branch (along with roll-your-own branch commits and merges).

We need only look at some of the large, fast-moving projects hosted with Git to see that is "supports" whatever it is that we are labeling "agile" these days.  http://git-scm.com/

Best regards,
Jeffrey Palermo

2010/1/14 Ade Miller <Ade.M...@microsoft.com>

[Glenn Block]

Thanks

How about tools like Horn and Team City, do you see those in the same vein?

On 1/18/10, Jeffrey Palermo <Jef...@palermo.cc> wrote:
> Every VCS supports agile. Agile is the way the team works with the VCS, not
> the other way around. DVCS systems make branch-per-developer seamless.
> With Subversion, it is easy to have multiple people working off the trunk,
> and the merging is great. Tools like JetBrains TeamCity will do
> auto-patch-upload and run the private build remotely at any time so you have
> build-per-developer without waiting for the local machine.
>
> TFS and VersionManager need more work in order to have multiple people
> making changes to the same files simultaneously, but agile teams still use
> them.
>
> Also, the VCS features have a lot more to do with supporting a team SIZE,
> not a team PROCESS or PHILOSOPHY. A BDUF team of 2 and an agile team of 2
> will probably have similar experiences in wide range of VCS's. BDUG teams
> of 10 and agile teams of 10 will have VERY different experiences based on
> the VCS in place.
>
> I think the essence of the situation is providing the most versioned "levels

> of undo" possible. In John Maeda's *The Laws of Simplicity* book, he talks

> about how putting "undo" everywhere makes the experience of using a product
> seem simpler. It may not be simpler, but the impression is that it IS
> simpler. With Git (the only DVCS I have experience with),:
>

> 1. I can revert a local commit
> 2. I can revert a push to my fork
> 3. I can revert a pull to the master
> 4. I can revert a commit on the master
> 5. I can revert a push to the master

>
> With a centralized system, I can only revert a commit to the centralized
> branch (along with roll-your-own branch commits and merges).
>
> We need only look at some of the large, fast-moving projects hosted with Git
> to see that is "supports" whatever it is that we are labeling "agile" these
> days. http://git-scm.com/
>
>
>
> Best regards,
> Jeffrey Palermo
>
>
> 2010/1/14 Ade Miller <Ade.M...@microsoft.com>
>
>> These are all good points as to Git/Hg/… being better than TFS/SVN but
>> they’re all things I want as a developer, agile or not right?
>>
>>
>>
>> BTW: SVN supports offline (I use it a lot for this).
>>
>>
>>

>> *From:* altnet...@googlegroups.com [mailto:
>> altnet...@googlegroups.com] *On Behalf Of *Justin Bozonier
>> *Sent:* Thursday, January 14, 2010 9:29 AM
>> *To:* altnet...@googlegroups.com
>> *Subject:* Re: Git and Agile

>>
>>
>>
>> Git (or probably any DVCS) is great for agile development for me for the
>> following reasons:
>>

>> - Supports spiking unlike TFS/SVN/Others because: It decouples the

>> notion of a check point (where I need to save the state of my working
>> files)
>> from the notion of publishing that state to the rest of my team. I can
>> commit, branch, etc. all on my local machine and only the stuff I
>> *publish*
>> is.. well published. :)

>> - Network down? Who cares?? We can still work. Some companies I've

>> worked at have had to send us home when the network went down simply
>> because
>> our VCS would freeze up and couldn't handle it (this was TFS '05 btw ;)

>> - Speed. Because everything is local I can commit, branch, w/e as fast

>> as I can think just about.

>> - Adding/Deleting files: Once again SPEED. Give me the ability to

>> sketch out my ideas like pencil to a paper but then give me the ability
>> to
>> carefully review my changes before I publish. I don't want to have to
>> view
>> every file change as a publication that's too much friction. I just
>> want to
>> romp around naked in the flowery meadow with my code until we've made
>> life
>> beautiful... then we'll get all dressed up for our formal picture to
>> send
>> out to the family. You know what I'm saying?? (I included that sentence
>> as a
>> bonus for anyone who actually read this far. Kudos to you!)
>>
>> Github:
>>

>> - I can go to any project and download the source extremely easily

>> (because github practically tells me step by step what to type where)

>> - I can publish fixes to ANY project no matter how out of my league
>> and...
>> - if I have something important to share the project leads can see my

>> published changes without me needing special access to their project.
>> And...

>> - They can easily integrate the changes if they so choose.

>>
>>
>>
>> Stick a fork in me.
>>
>>
>>
>>
>>
>> On Thu, Jan 14, 2010 at 9:08 AM, Glenn Block <glenn...@gmail.com>
>> wrote:
>>
>> Hi guys
>>
>>
>>
>> I know we just finished a nice thread about GIT, whether it's hot and why.
>> We also talked about alternatives like Bazzar, Mercurial, etc...
>>
>>
>>
>> A different question I have is do these tools (regardless of which one you
>> use) actually support Agile development? Would you consider them an
>> integral
>> part of the agile shop of the future, or is it just "the way" to do it
>> regardless. What I am really asking is are there specific benefits for
>> those
>> doing agile development?
>>
>>
>>
>> Thanks
>>
>> Glenn
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Seattle area Alt.Net" group.
>> To post to this group, send email to altnet...@googlegroups.com.
>> To unsubscribe from this group, send email to

>> altnetseattl...@googlegroups.com<altnetseattle%2Bunsu...@googlegroups.com>

>> .
>> For more options, visit this group at
>> http://groups.google.com/group/altnetseattle?hl=en.
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Seattle area Alt.Net" group.
>> To post to this group, send email to altnet...@googlegroups.com.
>> To unsubscribe from this group, send email to

>> altnetseattl...@googlegroups.com<altnetseattle%2Bunsu...@googlegroups.com>

>> .
>> For more options, visit this group at
>> http://groups.google.com/group/altnetseattle?hl=en.
>>
>>
>

--
Sent from my mobile device

[Charlie Poole]

Hi Glenn,

I'm thinking that there's a range of usefulness of tools in an
agile versus a non-agile environment.

Tools might be
* Only useful in agile settings
* More useful in agile settings
* Equally useful in agile and non-agile settings
* More useful in non-agile settings
* Only useful in non-agile settings

It seems to me that there are almost no tools in the first category.
and very few last category. I'd guess that about half the tools
we use are equally useful in both settings. Personally, I'd put
Team City in the group 2 and Horn in group 3. I'd put DVCS in group
2, but close to the group 3 border so to speak.

I think most things gravitate toward the middle for two reasons:
* Good software has certain intrinsic requirements
* Agile development is generally orthogonal to tools

Charlie

> -----Original Message-----
> From: altnet...@googlegroups.com
> [mailto:altnet...@googlegroups.com] On Behalf Of Glenn Block
> Sent: Monday, January 18, 2010 9:28 AM
> To: altnet...@googlegroups.com
> Subject: Re: Git and Agile
>

> >> These are all good points as to Git/Hg/. being better

> altnetseattl...@googlegroups.com<altnetseattle%2Bunsubscrib
> >> altnets...@googlegroups.com>

> >> .
> >> For more options, visit this group at
> >> http://groups.google.com/group/altnetseattle?hl=en.
> >>
> >>
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Seattle area Alt.Net" group.
> >> To post to this group, send email to
> altnet...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >>

> altnetseattl...@googlegroups.com<altnetseattle%2Bunsubscrib
> >> altnets...@googlegroups.com>