Skip navigation
All Places > Alfresco Content Services (ECM) > Blog > 2016 > February

by Tristan Bagnall

I recently started having discussions with teams and stakeholders on what a sprint review, or kanban review milestone should look like.

There seemed to be varied opinions ranging from, it is a chance for us to show how we implemented the code to fellow engineers, to a chance for the product people to sign off each story.

In this post I will cover how get better engagement with your stakeholders.

Lets head back to core Scrum - the the Scrum Guide: Sprint Review event. There is quite a detailed set of steps that those involved must consider but it boils down to:

'A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed.' - Scrum Guide,

But what does that mean, and is the description in the scrum guide the only way to achieve it?

The review is the first chance for the team to engage with the stakeholders and get a feedback loop in place. The team can then pivot based on that feedback.

How to engage stakeholders

Have you ever sat in a review and been confused waiting to be delighted? Well it is likely that that team, like all teams is on a journey. A journey of discovery, of learning about how to take a problem, work on it and deliver it as working software, to live.

Wow, you might say, that is idealistic. No team can take a problem and put it live. There are those who can, but the majority cannot... yet. They are on their way there and if given time and support they too can get there.

Here are some examples of how teams may engage stakeholders in sprint reviews, starting with the earlier stages of the journey:

    • A play by play description of the teams activities

      'We picked up story 123, then we wrote some tests to cover scenarios xyz. Once those were done we got a red build, as the tests failed. The writing of the application code was quite quick. It passed the tests, but then we realised we needed to add a little more tests as the code was....'
    • A story by story demonstration

      'We did 10 stories this sprint, here is the list. Let me start with story 123. I have a virtual machine set-up to show you this story. On the login page we added the cancel button. As you can see it is in the correct branding styling, and is screen reader ready. Okay now let me show you story 124. This one needs me to log in. As you can see the users home page has changed after login, and it now shows their username in the top right. Great so the next in the list is story 125. Lets close the browser, and go back to the login screen. So as you can see we hae the cancel button I showed you in 123, but we also have the login button. In this story we corrected the rounded corners on that button. Over to Terry for the next story...'


    • A narrative through the system pointing out where the changes are

      'So today we are going to show you the changes we have made to the system. Let me get to the login page. Here you can see we added the cancel button and changed the login button. There were some issues around the curve on the button. Okay so now we are in you can see we moved the users name to the top right of the page....'
    • An experience for the stakeholders

      'Hi, thanks for coming along, did you all bring your machines? Great, so here are a few highlights of the changes we made and where they can be found. I will leave them up for your reference. Naturally we are after feedback on these, but we would like feedback on the general system.

      Please go to url and play. The team are all here to answer questions over IM / voice / video. They will also wonder around to ask you find out what you think. All feedback is good feedback.'

Where are you? Any other examples? - send them to me and I can add them.

We all use technology standards everyday.

We hop into our cars and play music from our mobile phones through the car speakers.  It doesn't matter who the device or car manufacturer is, as long as they both add support for the A2DP Bluetooth profile.

We connect our set top boxes to our televisions with a single HDMI cable, again regardless of manufacturers.

We send emails to people in various organizations that use different email server vendors, but we don't need to worry about how our server communicates with theirs, they just both support SMTP.

Specific to Digital Asset Management (DAM), we add captions and keywords to images in common desktop applications and most of us don't have to think about the fact that they're being embedded using IPTC.

The examples are numerous, and we usually take the end result for granted, but those standards take significant time and effort to properly define the problems and come up with solutions that satisfy everyone participating, who sometimes have competing interests.

Disconnected silos of media are widespread in the DAM space.  A large organization can have multiple, even tens of DAM systems, usually for different departments.  A common thread in the industry is that we need to make it easier to integrate these systems with each other and with the rest of the enterprise so that the entire lifecycle of content can be managed in an efficient manner.

What might those integrations look like?

Metadata. Say a web content management system needs to display an image and a crucial piece of metadata, its credit line for example.  There might be several web pages or even separate CMSes using the same image.  If that credit line needs to change the CMS users shouldn't have to have to update it in every spot it's used.  An integration could be developed to pull the image and data from a central DAM by building a connector between the two systems, but what if the DAM is switched out for another vendor, or there are multiple DAMs from different vendors?

Renditions. Lower quality renditions of rich media files (called proxies in the video world) are often used instead of the much larger original source files for various scenarios.  Let's say we have a collaborative review mobile app which can be configured to point to a DAM system in order to use or request these renditions for playback or display.  For the app to support DAMs from multiple vendors a connector must be developed for each, assuming the vendor even has a relevant API for the task in the first place.

Rights. Omni-channel customer experience management solutions (Mmmm, words, so buzzy) might need to assemble content and obtain rights information from a DAM before making a campaign live.  There again: a different integration needed for each DAM vendor.

Interoperability standards are an obvious answer to these problems.

If we, the DAM ecosystem, build these critical system to system connectors using open standards that many vendors have agreed upon and have ultimately implemented we can be assured we'll only have to do it once and will avoid vendor lock-in.

If you haven't heard, work was started on just such a standard for the DAM industry, CMIS4DAM, designed to work alongside the existing Content Management Interoperability Services standard.  It held great promise as an answer to the call that seemed to be coming from many DAM analysts, consultants, vendors, and customers with initial participation from a range of companies and individuals full of vigor to help shape what was to come.

The OASIS technical committee (TC) charter was put forth, uses cases and deliverables were defined, and work started on the specification itself.

Unfortunately the participation waned throughout that process and the monthly meetings now consistently involve only a few attendees.

Without commitment from more individuals, and perhaps more importantly vendors, OASIS will have to shut down the CMIS4DAM TC.

Consider this a call for help.

If you were on the TC and have stopped attending, was there a specific reason?

If you're a DAM vendor interested in improving the DAM technology ecosystem would you consider joining the committee to help develop the specification?

Is there a standard other than CMIS4DAM you feel would be a better match for the DAM community?

Perhaps most importantly, if you're a purchaser of a DAM system and have interest in leveraging these concepts in your implementation, contact your DAM vendor and encourage them participate.  Your demands (hopefully) drive their roadmap, let's make sure an open interoperability standard is on it!

Filter Blog

By date: By tag: