Loading ...
Sorry, an error occurred while loading the content.

Re: [scrumdevelopment] SOA and Scrum

Expand Messages
  • Charles Bradley - Scrum Coach CSP CSM PSM
    Gretchen, (Good post, Kevin) I too have experience using Scrum on a team that was delivering SOA type services.  (In my experience, there is no one most
    Message 1 of 6 , Oct 17, 2012

      (Good post, Kevin)

      I too have experience using Scrum on a team that was delivering SOA type services.  (In my experience, there is no one most credible definition of SOA.  These services were ReST based -- so at least probably similar enough to SOA to have value in a Scrum context.)

      If I completely ignore the architectural decision that was made, here are my experiences using(and coaching on) Scrum in this scenario.

      Our situation was different than Kevin's, in that the inter-team dependencies were much simpler.  The system under development(SuD) in this scenario was a payment system.  It was used primarily by a retail web site, but also by about 6 other internal IT systems to process payments.  Even though the system was used by so many other systems, 80% of the functionality primarily supported the web site.

      • This team communicated with other teams primarily via Product Backlog.  When in person collaborations were needed, they occurred almost instantly, verbally, in person. This generally included agreement on creating or modifying interfaces(Rest resource URL's, as well as special attention given to their accompanying exceptions/error codes), or clarification of business logic.
      • When new services(components) were added to the system, they were moved to production quickly, regardless of the team who might need them.  When they were done, they were moved to production -- about monthly.  Typically the calling system would then test their "feature"(software used by a human user) against the SuD and verify correctness before the "feature" was shipped to production.
      • This team did no Scrum of Scrums, though there were "leads" who met on a regular basis.  I did not observe these meetings.
      • The company had a (relatively speaking)*very* small PMO, with a couple of Project Managers.  When multiple teams were working on a high visibility/impact project, these PM's were assigned to help with cross team coordination and dependencies.  They were very much servant leader type PM's, as opposed to command and control PM's.  They only got involved in the coordination and communication.
      • Over the course of my fairly close observation of this team for a year, this team delivered only one bug to production, and it was minor.   Remember, this was a payment system.  The culture encouraged very high levels of test automation.
      • The team was an intermediate/advanced practitioner of User Stories according to my Bradley User Story Maturity Model, and thus made a point to explore happy, sad, and bad paths and create story/acceptance tests to represent all of those paths.  The vast majority of these story tests were automated.
      • This team had no real trouble implementing and benefiting from Scrum.  It was not a perfect Scrum implementation(none are), but it was also not Scrumbut city.
      • It's also worth noting that this team and the depended on teams
        • were technically advanced and they did a LOT of test automation, including extensive test doubling (mocks, stubs, etc). 
        • were working in a co-located, high verbal communication culture.
      One of the key concepts at play here is the idea of "feature" teams vs. "component" teams.   While feature teams are generally preferred, component teams happen.  When lots and lots of component teams happen, then there is usually a lot of problems as the communication and coordination efforts multiply exponentially.

      Hope this helps.

      Charles Bradley

      From: Kevin Callahan <kcallahan@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Tuesday, October 16, 2012 2:52 PM
      Subject: Re: [scrumdevelopment] SOA and Scrum

      Hi Gretchen,

      We've been working along SOA-flavored lines and are actively looking at a more formal SOA architecture, built by multiple scrum teams/backlogs/PO/etc.

      It's definitely been a learning experience with some missteps that have been quite educational.

      What hasn't worked: 
      - serial development where one team is fully dependent on, and thus blocked by, another team's work.
      - not having inter-team working agreements, even if each team has them internally
      - having representatives from the teams attend each others' stand ups

      What has helped:
      - having teams communicate when they are working on items that will use APIs another team has developed. The latter can reasonably expect that there will be some degree of effort required to support the former team.
      - lining up sprint start/ends within a day or 2, and having the iteration lengths match. Makes it easier for POs to coordinate prioritization of work for the sprint.
      - daily scrum of scrums
      - lots and lots of coaching :) that at the end of the day there is only 1 team: our organization and we need to be playing the same game together.
      - shared documentation of agreements; people forget what they've agreed to. When a team representative speaks and commits on behalf of his team, that needs to be in writing. Otherwise you're looking at a game of telephone and a delivery where things don't match up.

      What I think would help even more:
      - have team representatives work together in story times to collaborate on acceptance criteria that all parties can meet.
      - where there are interfaces, have the teams design these first enough to be able to stub/mock them out to enable parallel development. As needs emerge (they always will) the interface agreements can be updated as well. For instance, we're working on RESTful HTTP interfaces, so we can relatively easily agree on the endpoints, request parameters, and responses. Even having a mocked JSON or XML fragment.

      I enjoyed very much the following blog post, and it both confirmed and expanded my understanding of building inter-operational software with multiple scrum teams:

      The only other add, is to absolutely emphasize that every team member needs to absolutely emphasize "individuals and interactions" that getting into blame games, defensiveness, or other dysfunctional behavior patterns will absolutely grind progress to a halt. There will be issues. People will make assumptions and mistakes, some of these may go weeks before being uncovered. Collective ownership of the entire system is paramount…

      Hope that helps :)


      What we've found works: to have the teams agree up front on the interfaces, or at least as much of them as we know of to begin with. 

      On Oct 16, 2012, at 3:45 PM, gswecker wrote:

      Has anyone worked on a SOA-product where Scrum was successfully used?

      Our organization's products are being migrating to SOA and the general view of engineering management is that the Scrum teams need to be organized around the services. This means that each feature will be split into multiple PBIs and then sprinkled across the respective service Scrum teams. (Horizontal slicing vs vertical slicing)

      It seems that we'll violate the basic Scrum principle of delivering potentially releasable code each sprint.

      Does anyone have experience using Scrum in such a situation? Are there alternatives that work (like sprinkling the developers who know the services well across Scrum product teams)?

      Thanks in advance for your help.

      Kevin Callahan, CSP
      Scrum Master
      mobile: 207-691-2997
      AIM: kevmocal

    Your message has been successfully submitted and would be delivered to recipients shortly.