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 is more than daily stand ups

image

Sprint planning using fibanacci series and poker results in better discussions, resulting in better knowledge sharing and estimates. These discussions results in better team capabilities which is one of the greatest benefits of agile. Do not compromise on it.