A customer view on Scrum

My Motivation

Being face with agile product development practices in our company, I decided to get a closer understanding of SCRUM for the following reasons:

1. gaining a solid understanding of agile development - focus on scrum method - in order to comprehend the mindset of our product and IT people
2. understanding the institutional, process as well as cultural pre-requisites to make agile product development successful
3. pairing marketing as the central leadership philosophy (Marketing = marktorientierte Unternehmensführung) with the concept of agility (from now on "Scrum")
4. strongly interconnecting the functions Marketing, IT, Product via both frameworks Marketing (in a leadership philosophy sense) with Scrum (in a product development meta process sense

What is Scrum?

• Scrum originates from Rugby and is to restart within a rugby game that involves players packing closely together with their heads down and attempting to gain possession of the ball (Scrum in Wiki).
• Scrum is one framework with the area of agile (software) development and stands in contrast to classical "non-agile" frameworks. Such classical non-agile framework aka waterfall development are  characterized through large/ intensive upfront specification, while scrum avoids large up-front specification and deliver small product increments.
• Scrum and lean management from manufacturing have a strong philosophical overlap. Just take a look at below picture (Source: DKD presentation "Toyota Way")

• Similar to lean management, Scrum requires a certaint mgmt philosophy and centers aound the idea of "Learning", while providing a framework of processes, definitions and roles to empower a learning system.
• Scrum foresees the following roles: (1) Customer, (2) Product Owner, (3) Scrum Master, (4) Scrum Team. While the product owner is the catalyst between developers and (internal) customer, the scrum master safeguards and coaches scrum principle. Click here for Link to detailed roles

• One needs to keep in mind the notion of "learning in self-organizing teams" when thinking about roles and hierarchy. Product owner, Scrum Master and Scrum Team must not be in a hierachical relationship. Differently put, in order to have discussion at eyelevel non of the roles should report to the other.
• On the same note, it is of utmost importance to protect the notion of self-organization and continous learning in the scrum team. At the centerpiece is have intensive preview and review session among all team-members, while keeping outside interference during the development time (so called Sprint) at a minimum. In practice this means the following (See more at Scrum Alliance): 

• A product owner creates a prioritized wish list called a product backlog.
• During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
• The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum).
• Along the way, the ScrumMaster keeps the team focused on its goal.
• At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, put on a store shelf, or show to a stakeholder.
• The sprint ends with a sprint review and retrospective.
• As the next sprint begins, the team chooses another chunk of the product backlog and begins working again
• A key question is of course how to arrive at these chunks of deliverable software. Here it makes sense to taker a look at the product backlog. In the product backlog you find elements which differ in size, level of detail, as well as when they are ready to be coded in a sprint. Dependent on these dimension you will find 

• User Stories (small, very detailed, ready for introduction to sprint planning)
• Feature/Theme (Medium size, abstract, ready to be broken down in smaller user stories)
• Epic (Large size, Strategic abstract, ready to be broken down in smaller themes)

• A product backlog is therefore like an iceberg. I like the following description, when reading about this:Mastering Backlogs. 
• The top layer is a set of small detailed User Stories well understood by the team and ready to be developed in the next few sprints. Items at this level should be small enough to be implemented in a couple of days.
• The second layer is a set of features /also knows as themes, that might span the next releases. Items at the feature level are less granular than at the story level. Usually it would take a few weeks to implement one of these features.
• The last layer is a set of epics, these usually indicate the big items on the Product Roadmap for the next year or two. Items at this level might take months to develop.
• Interestingly the authors recommends that the backlog consists roughly of 1/3 of each of these items. It makes sense to look at each part in a separate way, as these items required  a different way of moving forward
• Experts therefore recommend you to apply the DEEP Criteria to your backlog. See also here Mastering Backlogs for a great description:

• Detailed Appropriately - Items at the top of the iceberg should have lots of detail, where as items in the epic level, should have very little detail. Just a few words is sufficient. 
• Estimated - This means that all items on the backlog should be estimated by the team that will build them.  Often people think only the items coming up in the next few sprints need to be estimated, but if the Product Owner wants to have a release plan or roadmap, we recommend estimating items on all levels of the backlog.
• Emergent - The Product Backlog should change over time. New requirements emerge as more is understood about the product. This is okay. We remind them that in agile change is welcomed, and expected.
• Prioritised - An important characteristic of the backlog is that it is prioritised, usually by business value. Items at the top are the most important. 

• A question which comes usually comes up is how to prioritize a epic (for which you have hardly any information) vs. a user story. My take on it is, that you would prioritize user story among themselve in order to determine the next sprint. Epics are not ready for introduction and the team needs to work to break them down in themes and subsequently features/themes .
• Let take a look meanwhile how you make sure, that you really talk about user story. A user story is a short simple text, describing the need of a customer. Here is an example: "Customers have many sign-ins/passwords, therefore they loose track of sign-ins/passwords when shopping at sites they seldomly use. Therefore they prefer social log-ins for these sites." A good user story follows the INVEST principle
• Independent from other user stories
• Negotiable, meaning all roles incl. customer can discuss it
• Valuable, meaning there is a clear tangible benefit for the customer
• Estimatable, meaning the Scrum team can roughly but easily estimate the effort to deliver the user story
• Small, meaning the user story can be delivered in sprint
• Testable, meaning that the customer can test the delivered product of the user story
• Without going further details on how scrum works in theory, most organization will be faced with the following challenges
• Architecture might not empower working in decoupled scrum teams
• Organization is strongly organized in horizontal layers: backend, middleware, front-end as well share services
• Mindset of customer-centric thinking starts and ends at the managers area of expertise. 
• This being said, I believe the biggest challenge lies in a successful transformation when trying to introduct Scrum, as you might well end-up stuck in the middle between a classical IT/Product organization and an agile Scrum organization. This might deliver the poorest result at the end. One solution to this might well be A two speed it architecture

Some Learnings

1. Scrum is a framework / meta process for software development, it does not replace product mgmt in a broader marketeer sense (4Ps, etc..). 
2. In eCommerce, however, I strongly believe that both the broader marketeer perspectice and the software product itself, need to be extremely closely connect. It makes no sense that product claims to understand the customer needs better that marketeers and vice versa. Rather both have a complementary understanding of customer needs and therefore should work in integrated team.
3. If 2. is correct the entire marketing process and well organization needs to be adjusted accordingly, ideally there is an organization and potentially disciplinary integration, to empower a fully integrated perspective and interactive scrum processes as described.
4. Such linkage should happen at all levels of optimization, at user story level when developing concrete product improvement for customers as well as epic level, when it comes to aligning market strategy with product development strategy
5. Ideally customer segmentation logic, ie marketing to a certain homnogenous customer segment with certain needs should be reflected in the product organization. Example if you work on the SME Segment in marketing with a marketing plan,.. this should be ideally matched with a SME Scrum team working on Epics, feature, user stories for this segment.
6. Creating such an alignement as in 5. requires education on both marketeer side (which tend to have a view of customer as recipients of marketing and brand message) as well as product side (which tend to have a few of customers as user of their software product/Feature)
7. Transforming your IT/Product organization into an agile organization will fail if your stakeholder and in particular Marketing as the closest advocate of customer needs is not involved from day 1. Such change should be done in increment as well / related to the view of a two speed IT strategy.