What do you think of the new Apigee Accelerator Methodology?

dcouldwell
Participant III

We've just launched a new version of the Apigee Accelerator Methodology. It outlines the best practice that Apigee uses when helping customers build their API platform. Please let us know what you think, what practices have you used to accelerate your API Program?

https://community.apigee.com/accelerator-methodology

0 7 942
7 REPLIES 7

kkleva
Participant V

I've not been subject to the "New" Apigee Accelerator Methodology, but I have been working with the previous adaption that I believe was more humbly called Blueprinting.

What do I think of it? In two years we've successfully executed 57 "Extreme" sprints and over 90+ releases including hot-fixes ;0)

Compared to our previous delivery methodology of waterfall planning, purely manual testing and seven-week release cycles, the guidance provided by you and @Diego Zuluaga transformed the way our team is able to continuously deliver value to our business.

I'd say that's a pretty good turn-around!

One area in the article you referenced that I noticed wasn't highlighted that I would call attention to is making sure work is "Ready" before the team starts sprinting. I've found really quickly that when moving at this pace it is incredibly important as a product owner / technical lead to make sure the API Team is only working on things that are:

Available - It's amazing how many request come in my email to proxy an API that hasn't been built yet or is in the process of being tested. To prevent this, the cost of entry is that the target system owner must be able to supply at least a single working curl command before the API Team can consider it ready for a sprint.

Testable - If there isn't clear testing criteria or a concept how the API will be used in real life, it isn't considered ready to work on.

Hi Kris, thanks for the feedback!

Blueprinting is definitely still a core part of the methodology, see the Blueprint section of the Accelerator pages. What we've done is broaden the methodology to make sure the same approach is taken during all phases of the API program.

Definitely agree that your 'Definition of Ready' is a key part of the approach, we talk about that in a little more detail in the article Agile Assurance: Best Practices for Running Effective Sprints which we link to from the Blueprint page.

Glad so see the approach is still working for you and would welcome any additional feedback on how we can improve it further.

Not applicable

Should there be consideration around a "Success Workshop" that involves key stakeholders and leadership in advance of the Blueprint in order to ensure organizational alignment and cross-functional understanding of overall business, digital & API strategies?

@DaveHurlbrink Yes!!! We consider a "Success Workshop" as paramount to getting starting with an API Journey, prior to Accelerator Methodology. A relatively new concept, the Success Workshop takes portions of the Blueprint Prep and pushes for earlier alignment with more strategy conversations and creating an execution plan in place to first launch. Customers come away from these sessions energized and with a clear path on priorities to get started more quickly.

A key difference is that Success Workshops should be delivered with Apigee leading, whereas our methodology is open to have led by Apigee, Apigee Partners or by customers themselves. Though to start, we feel a good investment is to have Apigee-experienced and Apigee Accelerator Methodology-experienced resources lead the Accelerator Methodology through the first 6 sprints before having companies lead this themselves. This creates the muscle memory that is critical in creating consistent sprints and production deployments.

Not applicable

I like the methodology. It resonates with the agile practice that we use to develop APIs and manage projects. A couple of things that could be emphasized a bit more is to measure and materials / checklists that can be used by developers. For example, some of the sections could be turned into a spreadsheet or downloadable files that with little modification would be usable by teams.

@jose.cedeno

thanks for the feedback. Are there any particular parts of the methodology that you'd like to see in downloadable format? Several of the articles that we link to on the site have templates and examples but if there's more you'd like to see please let us know.

I'd also add that if you have something you've used in the past that you'd feel comfortable sharing a blank template, we'd be very interested in adding this for others to use. Thanks.