I agree one should have some high level architectural guidelines in
place, a nice presentation about the subject was captured during QCon
--- In email@example.com, "woynam" <woyna@...> wrote:
> We have anywhere from 20 to 30 teams working in parallel at any given
> moment. How would our lives be better if each team selected a
> different logging framework? What if they selected a different app
> server? How about a different programming language?
> That's simply crazy talk. Someone in our community once said "Doing
> agile is not an excuse to be stupid.".
> Seriously, our focus should be on providing business value to our
> customers. I don't see how creating a hodge podge software
> architecture provides value in the long run.
> Unlike many folks, I strongly believe there is still a role for
> architects in an agile organization. This is especially true in a
> large organization. One of the biggest reasons why many organizations
> struggle to achieve agility is that their systems are a complete mess.
> Everyone doing their own thing. Everyone has a specialty, because
> they've created a subsystem using technology that nobody else in the
> organization understands.
> I've read about many large organization that have successfully scaled
> agile, and almost all of them have a common platform to build upon. My
> organization is one of them. PatientKeeper comes to mind.
> --- In firstname.lastname@example.org, Ilja Preuss <it@> wrote:
> > woynam wrote:
> > > I believe that a team should be able to deviate from company
> > > *only* when they can demonstrate that there is value to be had in
> > > deviating, and the value is greater than any cost associated
> > > deviation. Simply claiming "self management" is insufficient.
> > >
> > > All decisions, whether they be the selection of features in the
> > > backlog, the creation of artifacts, an architectural decision,
> > > selection of a tool, should be driven by business value.
> > So, would you agree to a statement like "following company standards
> > only is important when doing so provides business value"?
> > > For example, if the organization has selected an appropriate,
> > > lightweight reporting tool, then then team would probably be hard
> > > pressed to show that using a different tool will provide greater
> > > value. On the other hand, if the organizational tool is a
> > > tool that's not particularly suited to agile, then the team will
> > > no problem showing how the lightweight tool provides value.
> > >
> > > Similarly, if the team decides to use a different logging framework
> > > than the rest of the organization, there is going to be an
> > > cost in the long term with respect to training and maintenance. Does
> > > the value of the new framework outweigh the costs? If no, the team
> > > should stick with the standard.
> > I think this is very much a matter of values and company culture. I'm
> > sure a company with a strong culture of innovation and knowledge
> > creation would have a quite different take on this.
> > > In a nutshell, as others have pointed out, agile does not mean
> > > own thing at any cost.
> > Of course not.
> > On the other hand, putting too many constrains on a team might well
> > inhibit its ability - or motivation - to self-organize. In
> > think that it's preferable to constrain a team in the form of goals,
> > instead of in the form of imposed solutions. If nothing else, the
> > should be able to ask "why is us using reporting tool foo of value to
> > you" and to propose alternative solutions to get that value.
> > > By using business value as the gauge for *all*
> > > decisions, including functionality, architecture, process, and
> > > the cost will be the deciding force.
> > Uh, shouldn't that be "the *value* will be the deciding force"? Often
> > enough, the cost is just a small part of that formula.
> > > One last point. There is always room for experimentation. At
> > > may not know if a new approach may not be better than an existing
> > > approach. In this case, the team should request a spike to determine
> > > if there is merit in the new approach. In this manner, the
> > > organization can allow for a bit of R&D, while still maintaining a
> > > semblance of order.
> > Why is "maintaining a semblance of order" that important to you, and
> > would that not be possible with a team simply using a different
> > framework?
> > Curious, Ilja