Agile Digital Marketing Management – How to improve your digital marketing program's effectiveness using scrum?

Did I say Digital Marketing Program instead of Digital Marketing Project?. Yes, I did, and that is intentional because most of the digital marketing initiatives meets all the criteria of programs than projects. Programs are a collection of inter-related projects, which when done together gives us more value than doing them one after the other. Majority of the digital marketing initiatives are programs comprising of multiple projects like;

  • Revamping the company web site
  • Creating good content
  • SEO optimization
  • Blogs
  • Case studies
  • Success stories
  • Voice of the customers
  • Training component
  • Webinars
  • Benchmarking
  • Research & Development etc

If these are not synchronized well, the entire initiative can turn out to be transaction oriented than result oriented. The team with which I was working very closely was no different, till we decided to follow a ‘light scrum’ based on the scrum elements like;

  • Weekly sprint planning meetings
  • Weekly reviews and retrospectives
  • Daily reviews
  • Tracking board

One may call it as a tailored version of Scrum. Any way, I call it as ‘Light Scrum’, a kind of loosely implemented most essential aspects of scrum framework envisaged by Ken Schwaber and Jeff Sutherland in their Scrum Guide.

Weekly sprint planning meetings

Quick 1 hour planning meetings, conducted immediately after the weekly review and retrospective. It was more of a pending from the previous week and new work. Was created using a tool (Microsoft Teams), so that all the stakeholders (many of them very senior) were aware of what is being planned, and their specific actions towards meeting the weekly sprint goals.

Weekly reviews and retrospectives

Even though the marketing team was working very hard, there was not any specific way to evaluate their progress. With the introduction of the weekly sprints, plan based review and retrospectives became possible. This in turn brought in lot of visibility into the marketing teams functioning to the key stakeholders.

Daily reviews

We never had those typical stand up meetings. We sat down together for 15 minutes every day to see where we are with respect to the weekly plan and for constraint removal.

Tracking board

First we created a dump of all the goals to be achieved and the activities required to achieve those goals. This resembled the classical product backlog. From this we created the weekly sprint backlogs. The weekly sprint backlogs were classified into;

  • To be done
  • Being done
  • Done

Resources were associated with tasks with a mix of volunteering and allocation. Based on the progress made, tasks were moved from “To be done’ to ‘Being done’ and then “done’. Tracking board was shared with all the relevant stakeholders so that everyone could see what was happening in the project at any point in time.

We do not maintain burn down charts to track progress. No task level estimates. There is no actual effort capture. There is no velocity calculations yet. Just by having a product backlog, sprint backlog, sprint planning meeting, sprint reviews and retrospectives the benefits are many.

Key Results

  • Improved result orientation
  • Higher motivation levels and job satisfaction
  • Better quality and effectiveness of the deliverables
  • Better stakeholder satisfaction

Daily scrum meeting rules

Sprint planning meeting guidelines

Agile mentoring program

Unboxing PMBOK / PMP master list

The Fragile Agile List

This is an ever growing list. The sole objective of this list is to challenge the agile champions to create some new mistakes, instead of the known ones in the list, and to help me to add them to this list by sharing them with me 🙂

  1. Absence of well articulated business case for agile transition
  2. Lack of management commitment / understanding
  3. Lack of product owner commitment / understanding
  4. Bad requirements engineering and wrong source
  5. Proxy product owners without any understanding of the ground reality
  6. Bad technical design
  7. Overselling agile
  8. Lack of empiricism
  9. Lack of rigor of corrective / preventive actions
  10. Partial training
  11. Insufficient training 
  12. Lack of awareness of agile principles
  13. Cultural conflicts
  14. Lack of quality of agreements 
  15. Influence of organizational politics 
  16. Just, Certified Agile Masters 
  1. Absence of well articulated business case for agile transition – Why are you doing it?. When will you say that it is successful?. By what date?. If we have clarity on these, the probability of success is very high. 
  2. Lack of management commitment / understanding– They think that agility is something money can buy, and unfortunately money alone cannot make it part of your organizational culture. It takes commitment over a longer period of time.
  3. Lack of product owner commitment / understanding – Many product owners lack role clarity. They act as traditional senior project managers and supervises the work of scrum master and the development team, craving for control, every day. Funeral of agile. 
  4. Requirements are scheduled into sprint without validating them – On many occasions, many of the requirements turn out to be irrelevant for the end user, as the source of the requirements are wrong.
  5. Proxy product owners without any understanding of the ground reality (linked to point 4). 
  6. Bad design – Whatever said and done, only a good design can scale, can include last minute changes easily. Many times, agile frameworks are adopted half way, as a quick fix measure to solve the problems of a project resting on bad architecture. That is not going to work, unless and until the code is re-engineered.
  7. Overselling agile – The expectations are not set correctly. Agile is projected as the silver bullet for all problems.
  8. Lack of empiricism – Without empirical data, progress cannot be measured. Improvement cannot be measured.
  9. Lack of rigor of corrective and preventive actions – People are hesitant to get into the real root causes and solve them, instead they are fine with quick fixes.
  10. Partial training – The full team is not trained, they do not have a common understanding of agile. ‘Just do it’ attitude will not work.
  11. Insufficient training – The trainer might not have given proper emphasis on the value system required for agile to be successful, instead, would have focused on the framework. Understanding the agile frameworks is the easiest part, where as how all the parts of the framework work together and create the pull required to achieve improved productivity is the key.
  12. Lack of awareness of the agile principles – The trainer / coach ignoring the agile principles part and focusing too much on the framework. Mastering the framework is much easier than mastering the principles.
  13. Cultural conflicts – Very often it is about ‘self organizing teams’ within a command and control’ corporate culture, that makes it difficult.
  14.  Lack of quality agreements – Majority of the agreements in the meeting rooms are political agreements, which can be interpreted or misinterpreted as emotional intelligence. People do not really agree, when they say ‘I agree’ due to two major reasons; 1) Lack of financial security 2) Lack of expert power. Without having these two secured, one cannot be bold and correct.
  15. Influence of organizational politics –  spilling into the agile way of working. Account manager acting as the ‘product owner’ trying to control things through the ‘proxy product owner’ by passing the ‘scrum master’. This is very dangerous as no one will dare even to accept the existence of this. 
  16. Just, Certified Agile Masters – who forgot about agile, the day got certified at the end of the two day corporate training program, who attended the program because his boss asked him to attend it. 

Agile Certified ‘X’ – Zombies

XACX where the first ‘X’ is for the certification body, and the second ‘X’ is for the role. That is the best way I could represent the ever growing agile certifications and alliances. The agile certifications and the certification bodies are mushrooming, and there is no dearth for demand. They churn out the agile certified nobody’s who are victims to the greed of some, who want to encash the demand and then vanish. Now comes certified agile assessors and auditors.When will you start believing in yourself and start building something worthwhile and showcase it. There is nothing else to boost your confidence and value than real results which demands deep work. Do not fall prey to the certification syndicates. Atleast don’t belittle yourself by publishing the photo of your certificate on social media. Do not get suprised if agile maturity models and certifications surface soon. Learn and master the frameworks and go for your own flavour which works for you and optimise it continuously to increase agility. The real challenge is in building the agile culture. I am really shocked to see the lack of understanding of agile basics by some of the ‘certified’ masters from one of the leading agile certification alliance.

Dos and donts of daily scrum (stand up meeting) – The scrum checklist

image

  1. The daily stand up meeting is also known as ‘SCRUM’. Both are same. 
  2. Daily stand up meeting is the most recurring scrum ceremony. Hence it will help if you have a fixed place, start time and end time for daily stand up meetings. 
  3. Always start the daily stand up meetings on time, and finish it on time.
  4. Each person gets 2 minutes to update the status of his work to the rest of the team (what did I do yesterday, what am I doing today and what are the issues I am facing.
    Do not convert it into an issue resolution meeting
  5. During the daily stand up meetings, very often the team members will talk to the senior most person in the group. If you happen to be that senior person getting unwanted attention train your eyes to cut the eye contact with the team member trying to talk with you.  By doing so, she will be forced to have eye contact with the rest of the team. Eventually that person will learn to talk to a group than to an individual. 
  6. For issue resolution have separate meetings. 
  7. In case you are clubbing the scrum with the issue resolution meeting, formally divide the meeting into two and at the same time ensure that the scrum follows its rules. 
  8.  Every body in the team need not attend the issue resolution meetings. So, after the scrum only those required for the issue resolution need to stay back. Others can proceed with their sprint related work. 
  9. Please remember that going for a meeting late or skipping an agreed upon meeting are not positive indicators of mutual respect.
  10. If somebody violates the meeting norms anyone in the team can highlight it so that the correction happens then and there itself.
  11. Every one must stand up during the stand up meeting.
  12. Switch off mobiles
  13. When a person talks listen. That is a great way to show respect. 
  14. Meeting must not take more than twenty minutes.
  15. Stand up in a circle, so that there is no hierarchy (at least in a stand up meeting 🙂 )
  16. Do not stand with the boss on one side and others on the other side.  This creates a divide. Always stand in a circle.
  17. Who will start the meeting?. The person standing on the right side or left side of the scrum master. Though this norm is not mandatory, having a norm like this can avoid unnecessary starting trouble. 
  18. Whenever someone requests help please note it down, so that you can help him after the meeting. 
  19. Always have the scrum meeting near the tracking board. This helps to refer back to the tracking board if required. 
  20. Conclude the meeting by putting your hands together for the progress made. Celebrate even small achievements.

This daily stand up meeting checklist (scrum checklist) is prepared based on my hands on experience with scrum teams. As and when I gain more insights I will be updating this scrum checklist. 

Read Agile Outsourcing Checklist

Agile cheating stories….see how the founder’s comment about scrum got blocked on amazon

I got this message from Ken Schwaber, one of the founders of scrum, on how the real scrum got abused by extending the sixteen page scrum guide, written by him and Jeff Sutherland to three hundred plus pages, by a group and published on amazon. Shocking, yet interesting case on professional ethics or lack of it.

Here is the message.

A group called ScrumStudy has published a book, Scrum Body of Knowledge, also calling it a Scrum Guide. It is posted on Amazon. When it was first pointed out to me, all of the reviews were five star. I bought a copy to see what was so great. First, it had extended the Scrum Guide where Jeff and I define Scrum from 17 pages to the 340 in the book. Second, it simply threw together every known practice about agile around Scrum and created a methodology which (their words) is appropriate for any project of any size in any industry. Whew. Worse, the book was written by thirty or so people, none of whom are active in the Scrum or agile community.

I went in to look at the reviews, unsure how other people in the Scrum community could view this as useful, particularly with such glowing comments. I found that all of the people were from the same country where ScrumStudy is located (India) and that most had never reviewed anything on Amazon before. Amazon reviews were being gamed.

I emailed some friends and we entered what we thought of the book. The lead author of Scrum BOK, Tridibesh Satpathy did the following:

1. Objected to my review (see below for the review and his objection) and had it removed.

2. Had his friends write more positive reviews.

If anyone here knows amazon and can help, please do so. This is an absolute corruption of Scrum principles and values, and is an abuse of amazon. Also, if you want to flood the book with negative reviews, I won’t object.

Thanks,

Ken

My Review:

Tridibesh Satpathy, whom I have never met or communicated with (nor any of his co-authors or reviewers), removes the heart, soul and values of Scrum with this book. Singlehandedly, he attempts to turn Scrum into a formulaic methodology that can be used without thought or empiricism. The Scrum Guide that defines Scrum (http://bit.ly/1ixDnJK) is 17 pages long. Tridibesh et al have added every known practice, technique, and defined gated process to it to create a 300+ page monument to the failures of predictive methodologies.

You can pick up this book, apply it, take the certifications, and feel comfortable that everything is in place. It isn’t. Tridibesh et al have never seen your organization, your projects, your context, or your goals. How can they possibly believe that they can formulate a solution for you?

I might have once believed that arrogance prompted this effort, particularly since none of the authors or editors are known in the agile community. However, experience has taught me that this is purely driven by a need for money. Studied from all angles, the is a money making scheme that should be avoided by those who understand the basis of agility, empiricism, and lean thinking.

As the first step in lean thinking, to identify and eliminate waste, throw out this book and avoid its authors.

Ken Schwaber
co-developer of Scrum, signatory to the Agile Manifesto, founder of the Agile Alliance, Scrum Alliance, and Scrum.org

Scrum on!

How Tridibest got it removed:

Scrumstudy support says:

This review is completely inaccurate and unethical, and should be removed by Amazon for the following reasons: 
1) This review is inappropriate because he works for competition Scrum.org (http://www.linkedin.com/in/jessehouwing). He wants to promote books from people in his organization (i.e. Scrum.org) and to discredit the books written by Scrumstudy. So this should not be allowed by Amazon as per “Promotion of illegal or immoral conduct” – Objectionable Material.
2) He has not read the book (this is not an Amazon Verified Purchase); hence how can he comment that the book is not relevant and call it a `sham’?
3)This person is only interested in selling books from his organization and from authors who work for his organization (and does not provide any specific reason why SBOK is not good except that the book discusses concepts which he is not familiar with). Here this person is a direct competitor with SCRUMstudy and is posting negative reviews about SCRUMstudy for his personal financial benefits. So, it contains inappropriate content. 
4) SCRUMstudy.com is a very reputed organization for teaching Scrum globally. The Scrum Body of Knowledge (SBOK) was written by 18 authors who are expert Scrum Practitioners and is being widely appreciated in the industry. The SBOK was reviewed by 25 experts and draws from the combined knowledge and insight gained from thousands of projects across a variety of organizations and industries. This whole review seems to discredit SCRUMstudy and the Scrum Body of Knowledge (SBOK) for the benefit a competitor (Scrum Alliance) for financial benefits. 
5) We will request interested students to do a free introductory course about Scrum from SCRUMstudy.com (which includes the first chapter of SBOK, instructional videos and a simple real-life Scrum case study) and judge for yourself about the quality of the courses offered by SCRUMstudy (instead of reading through negative reviews from vested interests and competitors). The first chapter of the SBOK is available for you to view in SCRUMstudy.com or in Amazon.

Scrum on!

Read Agile outsourcing checklist