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.

How to become a better online marketeer?

I recently had a discussion with my team on how to keep up with the constant changes in online marketing. The take away was that each of us should have a personal learning strategy.

Here are my recommendations:

1. Identify the latest and top rated literature

Here are a few links I came up with:

TOP 10 Marketing books in 2014
The best online marketing resources
20 Books Every Marketer Should Read in 2015

I will also review some of the books in this blog.

2. Identify experts and subscribe to their blogs.

I use feedly as a reader, which allows me to also read on my iphone while commuting to work.
Top 10 Online Marketing Experts To Follow In 2014


3. Set-up your own small e-commerce business
Set up a small business / site on your own to test certain things at small scale. Actually this is being done by a few people in the team. this knowledge needs to be shared, however.

4. specialize, but also train general skills

Some of you might know that in professional sports, you do not only train within your discipline, but also  integrate training methods from other sport disciplines. Reasons are to avoid injury, but also to be more of an allrounder in terms of speed, agility,.. The same applies here, you can read specialized literature, but taking into account broader mgmt literature outside your specialized field, will definitely make you a better marketeer.

ASK, Ryan Levesque (Book Review) or how to turn surveys into sales instruments

This book is an easy 200 page read, written in a very conversational style. The main advices of the author is to stop asking your potential customer "What they want?" but rather what they do not like? The main assumption is, that people have a tough time formulating what they want, but are pretty good at saying what they do not like with certain products features.

Ryan Levesque turns this main thought into the a system of survey cycle and sales cyles, which he calls the ASK Formula. In principle engage your potential customer with survey until you know which microsegment exists, what this segment needs, and which of you survey participants belong to which segment. After you potential customer are attribute to such microsegment run context specific sales and marketing message, which draw on the segment specific information from the survey.

Example from my recent experience:
I recently completed a hotel reservation via the mobile web site of HRS. After finalizing it, I get a small survey request, asking me 2 Question and I get a button to download the app. While the idea of the survey is a good one, it should acutally explore the reason why I did a booking via mobile web vs. app vs. desktop, then based on my response I should get a target message.

lets say, I respond:  "I say, I do not know the HRS app" --> Message with advantage of app and call to action to download it. Alternatively I respond " I know the app, but I do use HRS infrquently it is not worth installing" --> Message, thank you for using our mobile website, call to action with a bookmark..

Ideally as a company you can directly link the survey results to your CRM database and trigger direct mailings.

Takeaway:
Not a completely new approach but written in a convincing and very practical way. Also I agree that there Marketers love traditional survey design and usually do not start the survey process in a discovery mode, but actually seek answer which fits their mindsit. Overall easy read, which could actually be summarized in 100 pages, but is absolutely worth buying.

BOOK REVIEW: Reinventing organizations by Frederic Laloux (Is Marco Nussbaum running a - teal hotel organization-?)

Having read quite a few business and economics papers and books, I am first of all critical if someone claims to "reinvent" something. I have to admit, however, that this book is exciting to read from beginning to end. It really give food for thought and will cause you to challenge your current way of running your business.

Funnily, you also started to think of people, who run such "next generation organization" (called teal organization in the book). The name in the hotel industry, I came up with was Marco Nussbaum. Marco calls himself a CEO - Chief Enabling officer - which in a nutshell summarizes the central ideas of the book: Selfmanagement, Wholeness, Purpose. Not sure, if Marco is a pioneer without knowing it (like many of the CEOs/companies mentioned in the book). I will certainly ask him next time we meet.

here is an existing and well written review in case you want to learn more.

For me personally, I came up with the following takeaways

1. I think the principle outlined in the book are easiest to apply in the service industry, as you usually have direct customer feedback. Naturally, the hospitality industry would be a perfect candidate for it.
2. Also, if the author is right, our society will turn more "teal" and in particular young and highly qualified employees, will look for
• places with no to little hierachy-but strong principles of selfmanagement, 
• wholeness - being yourself, instead of turning into a "corporate servant" 
• Businesses with a strong purpose (in which purpose is much more than making profit)
3. Biggest challenge will be in consequence how far one can take the principles above in a traditional business organization. The book tries to answer the question, but bottom line the author is convinced that it either all or nothing.

STRATEGY - What's your Strategy for Managing Knowledge? (HBR 04/99, Hansen, Nohria, Tierney)

Summary (Link to text)

• This is a classic piece from 99', which gives you advice on which knowledge management stratgey is the right one for your company
• The authors distinguish between two generic strategies for managing knowledge:
• Codification, which relies on knowledge being codified into documents and made available primarily via databases
• Personalization, which aims at facilitating person-to-person communication of knowledge
• Why not do both - try to code knowledge as well as faciliate personal exchange? The authors claim, that trying to do both will lead to failure. Rather you need to choose your primary strategy and complement it with 20% of the secondary strategy. So if you choose codificiation 80% of you efforts should be aimed on implementing this strategy, while 20% should go into faciliating personal exchanges.
• Important is that your knowledge strategy needs to be aligned with your competitive strategy. The Following graph shows how two different breeds of consulting firms (strategy consulting vs. IT Consulting) would typically differ in their approach based on their different competitive strategies:

• Let us assume your market strategy is clear, how do you know which knowledge strategy is the right one? The authors recommend to look into three areas
• Do you offer standardized vs. customized products? Standardized products = Codification, Customized products = Personalization
• Do you have a mature or innovative product? Again, mature product = Codification
• Do your people rely on tacit or explicit knowledge to solve problems? Explicit knowledge can be codified, tacit knowledge cannot. 
• Who should take care of knowledge managment? The Author suggest an integrated approach between IT, HR and leadership of the company.

My Takeaways

• the creation of a strong knowledge management culture paired with strong people development is absolutely key in retaining talent. This is particular true for generation Z, which will pick and choose to stay in job as long as the learn (in order to capitalize on these learning at a later point of time)
• I also believe that most companies, and in particular Tech/Ecommerce companies will have strong tendencies to codify, using wikis, etc.. and all sort of codified documentation language. To have a deliberate discussion, on the benfits of codification and the limits, e.g. complex problem soliving, new product, should be an integrated leadership discussion
• Last, knowledge management and service excellence as well as sales excellence need to be tackled in a more integrated approach way. Key account manager with large customers will not succeed with codified knowledge given their personality as well as the need for customized solution. Handling customers complains at a service desk, on the other hand, will  benefit from codified knowledge, which might be found in templates or previous handled incidents.

STRATEGY - Your Strategy needs a Strategy (HBR 09/12, Martin Reeves, Claire Love, and Philipp Tillmanns)

Summary

• There is no one-size-fits-alls strategy process, rather you need to determine your "strategy on how to strategize"
• Firms in market environment, which are predictable, will run a different process than companies in highly unpredictable environments
• The authors discretely match the type of strategy process with a 2x2 matrix with the axis "predictablity of market" and as a second axis "influence on industry" (called Malleability)

•  Depending on the quadrant you end up in, you should align you strategizing process and style (Classical, adaptive, shaping, or visionary)

 My Take Aways

• Most people will consider their market as little predicable, as they will not be able to judge the degree of predicability in terms of absolute terms. It might help to say, that industries, which experience regular cycle (Airline industry, oil industry) should be considered predictable. Most likely these industry require large investments, resulting in high sunk cost.
• I would also argue that most companies would not consider themselves in a position to change the industry (most likely because the lack magnitude/size). Here it might be useful to rank your company in terms of innovative power, e.g. how many market leading innovation have you been able to introduce lately/ how many innovations do you aspire to introduce-
• Last and once you know which strategizing strategy is required for you company, you will still need to determine which strategic style is currently in place in your company. And how transformation into a new style could potentially happen. Here, my suggestion would be to benchmark / gain insights how similar companies or companies in the same quadrant organize the strategy process.