- Hi everyone,
I've been asked to lead an "Intro to agile" discussion in my organization. While we were brainstorming a short list of topics the standard "Pros and Cons" item came up. To me the pros are obvious, but there are things that are percieved cons. Some examples of these are:
-- Loss of titles/roles
-- Increased visibility (no hiding dirty laundry)
-- People actually having to work together *gasp*
To me these are positives but can be seen as negatives because of the problems they cause. Problems that need to be delt with, but problems none the less.
My question to those on the list is this. Are there any real negatives that you have encountered using Scrum? For all my reading and personal experience (which isn't that much) I can't think of any.
- For starters, the "SOA" was created before the term "SOA" was coined. :-) We started the effort in 1998 using CORBA as its basis. As CORBA had defined numerous standard services, e.g. Naming, Event, etc., we used the same pattern for business services, e.g. Order Service, Trade Service, Market Data Service, etc.
We were using RUP in the first 2 years, and adopted parts of Scrum for the management part, e.g. daily stand-ups. We were using a use case drive approach, so the functionality definitely drove the design of the SOA. There was no BUFD.
There were definitely a few areas in which we probably over-engineered, but for the most part the architecture has evolved based on business needs.
Given that were we tasked with replacing a mainframe with a new distributed, SOA-based trading platform, the functionality was basically defined. We worked with various stakeholders to refine the requirements, so we weren't working in a vacuum. We pretty much knew how the use case for order entry would be handled.
After a few years we basically ditched RUP. Even though we had tailored it in as lightweight a manner as I think possible, it was still too heavyweight. We didn't formally adopt Scrum, but the core elements of agile development were in place.
As a midsize shop, we (thankfully) don't have a formal governance model for architecture. It's really a team effort involving the various group (technical) managers. For the most part we incorporate architectural changes into the business-facing projects. However, there are a few instances where we've had projects that strictly address architectural changes. That said, there's always a business justification for the changes, e.g. reduce latency, increase capacity.
--- In firstname.lastname@example.org, "Dale" <dale_a_mcmillen@...> wrote:
> --- In email@example.com, "woynam" <woyna@> wrote:
> > [cool elephant quote removed]
> > Over the past 15 years I've been involved in building one of the largest trading systems on the planet using basically an agile approach. No, it wasn't "pure" Scrum, but it was more Scrum-like than not.
> > We conduct numerous SoS-like stand-ups during the week. Our service-oriented architecture has allowed us to scale from a simple single-server proof-of-concept to our current production system hosting 4 exchanges with close to 1500 servers.
> > Mark
> If you don't mind, I have a couple of follow up questions:
> 1. Was the SOA developed using Scrum? If so, how were "end users" and "product owners" defined if there were no consumers of these yet to be defined services?
> 2. What type of project management / governance / architectural wrapper was in place that allowed the Scrums to flourish, and how would this (obviously necessary) wrapper be significantly distinguishable from other Agile Methodologies, such as FDD?