Developing APIs in a Scrum development model is there a difference?

[rw]

I wanted to ask this group if they have had success developing APIs within a Scrum Development Model, if so was there any changes to traditional scrum model to make is successful?  One issue I believe I see is for an  API to be successful we need some upfront design to ensure they are stable a much as possible once they released.   In the scrum model everything is suppose to be very iterative. Maybe I am incorrect with out I see scrum. 

Thanks

 

[Jimmy Bogard]

Scrum doesn't mean "don't design and figure things out ahead of time", it just provides a mechanism for a feedback loop and opportunity for course correction. We practice iterative development, and iterations allow us to break the work up into manageable chunks, get incremental verification of our work, and allow us to change focus/design/direction accordingly.

On Tue, May 13, 2014 at 7:44 AM, rw <rpwi...@gmail.com> wrote:

I wanted to ask this group if they have had success developing APIs within a Scrum Development Model, if so was there any changes to traditional scrum model to make is successful?  One issue I believe I see is for an  API to be successful we need some upfront design to ensure they are stable a much as possible once they released.   In the scrum model everything is suppose to be very iterative. Maybe I am incorrect with out I see scrum. 

Thanks

 

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[Kijana Woodard]

+1. Its unfortunate that agile/scrum has been interpreted to promote WISCY management: Why isn't someone coding yet?

[Kevin Swiber]

On Tue, May 13, 2014 at 8:44 AM, rw <rpwi...@gmail.com> wrote:

I wanted to ask this group if they have had success developing APIs within a Scrum Development Model, if so was there any changes to traditional scrum model to make is successful?  One issue I believe I see is for an  API to be successful we need some upfront design to ensure they are stable a much as possible once they released.   In the scrum model everything is suppose to be very iterative. Maybe I am incorrect with out I see scrum. 

My current team works in an agile methodology mixing some best practices I've learned over the years from Scrum, Lean, and Extreme Programming.  I've also worked on pure Scrum teams.  We currently iterate much faster than traditional Scrum.  For any large project, you need up front design.  Taking a page from Lean, it's also helpful to delay decisions to the latest responsible moment.  At this time, you will have the most information you'll need for decision-making.  I've found this to work very well in practice.

Who is your customer?  Internal?  Partner?  Any developer on the open Internet?  This doesn't impact the completeness of working software; it impacts the release scope.  Early on, your API will go through many changes as you figure out all the important models (Data, Domain, Application [API], Reporting).  If others are building clients that depend on this API, the risk of change is related to the distance between you and those client developers.  The farther away, the less chance you have of making sure those clients are updated as you iterate on your API.

For partner and open APIs, doing a limited release to trusted individuals who may be willing to help test will be helpful.

Definitely have design sessions planned into iterations.  They will help generate tasks in the first place.  Don't design too far ahead.  All the design work for something way in the future will change dramatically as soon as you start getting a taste for the realities of implemented software.  Don't sacrifice for the sake of "moving fast."  Agile is supposed to help you move forward--confidently.

Cheers,

--
Kevin Swiber

Projects: https://github.com/kevinswiber
Twitter: @kevinswiber

[rw]

All very good comments, I agree scrum should not mean we throw upfront design out the door.  Do you usually have a sprint 0 for design work then?  What do you do if you get into a spring for a given feature enhancement and discover you need a new API to expose the resource? Do you take 2 weeks to design the API then come back and tackle enhancement? 

[Jack Repenning]

On May 13, 2014, at 7:30 AM, rw <rpwi...@gmail.com> wrote:

Do you usually have a sprint 0 for design work then?  

Maybe. Or, we treat the design work as a Scrummable release all its own, and then the implementation as "release 2.0." Depends on how much unknown is involved, and (key, as always) how good and responsive your customer representation is.

What do you do if you get into a spring for a given feature enhancement and discover you need a new API to expose the resource? Do you take 2 weeks to design the API then come back and tackle enhancement? 

Probably not. By this point, you probably already know the compatibility risk points well enough to take it in stride, or at the worst to schedule one "research spike" to flesh it out.

-- 
Jack Repenning
Repenni...@gmail.com

[Jimmy Bogard]

We also have BA/Architect folks working basically one sprint ahead to refine design. Sometimes, though, design has its own process and shouldn't get jammed into scrum, which is focused on delivery.

[Philip Nelson]

Agree with all said so far on this. I personally like having time boxes for design work, it establishes an agreement on priorities and scope that helps keep you out of the "it's not quite good enough yet" cycle that I often find myself in. Exploring other possibilities is really enjoyable! Whether you call this time sprint 0, a research spike, a release, is just a label on a time box for doing real work, but not expecting an end user deliverable. 

[Kevin Swiber]

A lot of this does depend on size of your team and individual team participation constraints.  Ideally, you have a small, cross-functional team.  When enterprises start moving from waterfall to Scrum, this is typically not the case.  You often still have the "shared resource" model.  Traditional project management tends to come into play in this scenario, and you end up in that weird "Scrummerfall" model.

If this is the case, call it out.  It is possible to have short waterfall-ish iterations, as well.  It's just a matter of doing a work breakdown and tackling chunks at a time.

My current team doesn't have a group of business analysts performing requirements gathering ahead of the engineering team, and it's actually pretty great.  Technical conversation mixes in with business requirement conversation, and we get to a solution much faster.

The "Sprint 0" approach can be a little odd, having done this myself, and is usually led by traditional Project Management.  This approach makes it relatively easy to slip into waterfall with an agile facade.  (This is sometimes _still_ an improvement, though feels weird to everyone involved.)

Regarding what to do with new feature requests that emerge during an iteration: Talk to the Product Owner.  Let them prioritize.  Typically, in Scrum, once work is in play, it is fixed for the duration of the iteration.  This is one aspect where I prefer a Lean approach.  My current team is able to put a new task in play immediately if it's deemed higher priority.  Not allowing this seems like a defensive move from IT, in my experience, and sometimes takes away from shared ownership with non-technical stakeholders.

However, none of this has to do with APIs.  I can talk about this for days.  :)

[sune jakobsson]

You can scale your API's horizontally, and improve the performance vertically, but some parts are not that "scrum friendly" like security, but scrum helps you break down your API offer into manageable modules or parts.

Sune