Wednesday, 24 July 2019

Azure Naming Conventions

I have gone back and forth with Azure naming conventions over the years. There are various trade offs to consider, but I think I have settled on a format... for now.

I prefer to see the resource type as a prefix, while the environment (dev, qa, uat, prod) as a suffix. In the middle, I like to see the purpose of the resource.

So my format is:

What: The resource type
Why: The purpose / project
Where: The environment (eg. dev, qa, uat, prod)

This naming convention allows me to see all the resources ordered by their type (eg. sql for SQL Server). In the following example, I can visually scan for "sql"

Notice that this allows all the sql resources to be grouped by project name. Using the suffix, I can then easily see the environments related to those projects.

In the examples below, the I use "nicename" for the "purpose".


General rules:
  • All resources (including resource groups) are lower case
  • Where hyphens are not permitted, simply omit them. eg. storagenicenameprod 
  • Use industry accepted abbreviations (eg. vnet, app, net)
  • Where there is no widely accepted short abbreviation, use full words (eg. search for Azure Search)
  • Where character limits are imposed, fall back to acronyms (last resort as this is harder to understand)

Resources groups

For example:

The reason I have separated web, data and network related resources is because putting all resources in a "production" group could get very messy. The separation allows for the types of functionality (within an environment) to be grouped nicely.

Data Group - Data / storage related
  • Database server
  • Blob Storage
  • Table Storage
  • Azure Search 

Net Group - Network, Security and Protocol related
  • Virtual Network
  • Network Security Group
  • Application Gateway
  • Azure Front Door
  • Load Balancer

Web Group - Web App & Content Delivery related

  • App Service Plans & App Services
  • Functions
  • Sendgrid

Resources In General

<resource type>-<purpose>-<environment>


The reason I like the resource type first is because I often look at the entire resource list, so (for me) it is helpful to put the resource type at the start of the name. Yes I know that you can order by resource type, however there is something I personally don't like about that.

App Service Plans


Example Resource Group: rg-web-prod

App Services


Example Resource Group: rg-web-prod

SQL Database Server



Example Resource Group: rg-data-prod




Example Resource Group: rg-data-prod

Azure Search 



Example Resource Group: rg-data-prod

Virtual Networks


Networking is an interesting exception, as I prefer to take a numbering approach at network levels. This is because networks can be used for all types of purposes. I also like to keep the network dependencies together. So I will prefix the Network Security Group (nsg) with the name of the the vnet.


Example Resource Group: rg-net-prod

Network Security Group's related to a VNet should follow the pattern:


Example Resource Group: rg-net-prod

In this example the "purpose" is to attach a Network Security Group to the Vnet for the Application Gateway and Azure Frontdoor

Application Gateways



Final Thoughts

Naming things is a balancing act which I (and many) struggle with. Something that you are happy with might start annoying you years later. What ever you choose, try to ensure that your naming is understandable, consistent, and easy on the eyes.

Also, keep in mind that you probably won't like your naming convention in the future :)

Friday, 28 June 2019

Estimating - There is no such thing as a 1 hour task


Estimations in software development have always been a problem. Many teams and organisations struggle with finding the right way to do estimations. There is no right answer, and it really depends on your organisation. 

If you are measuring by the hour, then perhaps you have struggled with understanding why you are not as profitable as you could be. This may arise from the fact that your lower estimates are just not realistic. I will explain what I mean in the following examples.

In these scenarios we assume that the developer deploys to an environment, then confirms that the functionality works before handing it to a QA/UAT person.

Example 1 - The perfect case (no defects or problems)

In this example I will outline a 1hr task in a "best case" scenario which has no defects or problems. The order of events will differ depending on your processes. 
  1. Download repository & get code running locally - up to 0.25hrs
  2. Do the work - 1hr 
  3. Deploy to a development environment & test (0.25hrs)
  4. Commit code, create pull request, & participate in the code review (0.25 x 2 devs = 0.5hrs)
  5. Deploy to a QA environment & test (0.25hrs)
  6. Tag & cut the release (0.125hrs)
  7. Deploy to a UAT environment & test (0.25hrs)
  8. Deploy to production environment, put live, then quickly smoke test (0.5)

As you can see, a single 1hr task can actually take 3hrs in a good scenario. This does not even factor in the time of the QA or UAT people. Also, the context switching of doing all these different steps is a significant time drain.  

You are thinking that many tasks together can be bundled, so we would save time on deployments. As you will see in the next example, the math still does not work out.

Example 2 - The perfect case (no defects or problems) with multiple work items

In this example I will outline 5x 1hr tasks in a "best case" scenario which has no defects or problems. 
    1. Download repository & get code running locally - up to 0.25hrs
    2. Do the work - 5x 1hr 
    3. Deploy to a development environment & test (0.5hrs)
    4. Commit code, create pull request, & participate in the code review (5x 0.25 x 2 devs = 1.25hrs) - Note: each task has it's own code review
    5. Deploy to a QA environment & test (0.5hrs)
    6. Tag & cut the release (0.125hrs)
    7. Deploy to a UAT environment & test (0.5hrs)
    8. Deploy to production environment, put live, then quickly smoke test (0.75)
    As you can see, 5x 1hr tasks can actually take 9hrs in a good scenario. We are not really saving much time by bundling. On average, our  1hr tasks are actually taking almost 2hrs per task.

    Example 3 - The bad case (defects & problems)

    In this example I will outline a 1hr task in a "bad case" scenario which has defects and problems. 
    1. Download repository & get code running locally - up to 0.5hrs
    2. Do the work - 1hr 
    3. Deploy to a development environment & test (0.25hrs)
    4. Code does not work. GOTO step 2
    5. Commit code, create pull request, & participate in the code review (0.25 x 2 devs = 0.5hrs)
    6. Code is rejected. GOTO step 2
    7. Deploy to a QA environment & test (0.25hrs)
    8. Fails QA. GOTO step 2
    9. Tag & cut the release (0.125hrs)
    10. Deploy to a UAT environment & test (0.25hrs)
    11. Fails UAT. GOTO step 2
    12. Deploy to production environment, put live, then quickly smoke test (0.5)
    I hope my following calculations are correct...
    0.5 + 
    1 + 0.25 +
    1 + 0.25 + 0.5 +
    1 + 0.25 + 0.5 + 0.25 +
    1 + 0.25 + 0.5 + 0.25 + 0.125 + 
    1 + 0.25 + 0.5 + 0.25 + 0.125 + 0.25 +
    1 + 0.25 + 0.5 + 0.25 + 0.125 + 0.25 + 0.5
    = over 12hrs

    It is important to note that this is a really bad scenario. Something has gone wrong at every part of the process. Failing Code Review and QA and UAT should be very rare. However failing at least one Code Review or QA or UAT is quite common, and should be expected.

    Programming is very difficult. So the reality of bugs/issues falls somewhere between the ideal (no defects or problems), and the bad (has issues at all stages).

    It is also important to note that unknown obstacles pop up which a developer must address. For example, any frontend developer will know about versioning/dependency issues with their tooling. I have never met a seasoned .net backend developer who has not yelled at the top of your lungs when they realised a Windows update has broken something.

    Final Thoughts

    In reality there is no such thing as a 1hr task. Even the most ideal scenario has parts of the process which are not accounted for, which can easily push the real time spent to 3hrs. Even bundling items together does not effectively eliminate this reality. 

    Programming is hard, and there is no such thing as bug-free software. A release with multiple tasks will have at least one item which is rejected at Code Review, QA, or UAT. Good processes only mitigate defects and problems. 

    I hope that this article has given some insight in what it is like to estimate effort in hours. There is no such thing as a 1hr task. What ever your estimation strategy, you need to account for this reality so you can stay profitable.

    Sunday, 9 June 2019

    Umbraco Codegarden - Moving to dotnet core

    A little over 2 weeks ago I ran an open circle which was aimed at getting Umbraco transitioned to dotnet core. The discussion group centred around what the community can do to help speed up the transition.

    Umbraco's Current Structure

    As it stands, the current Umbraco solution structure looks like this:

    Umbraco's Future Structure

    Moving forward, the proposed solution structure will look something like this:

    Note: The new solution structure will be maintained in a separate branch. The rationale is that the changes required to get there will create many frequent breaking changes.

    Community Tasks

    The stages to reach the proposed structure will require significant refactoring. There are various tasks which are simply too complex (with too many interdependencies) for non-HQ people to accomplish. However, we managed to pull out specific tasks which are isolated enough for the community to have a go with.

    I have created issues on the Umbraco issue tracker for these items:

    Requiring Discussion

    A more complicated issue arose from the discussion around how Umbraco does imaging. Namely, how do we abstract that functionality? 

    Shannon suggested to create an RFC so it can be discussed:


    Final Thoughts

    Dotnet core 3.0 is coming out at the end of the year (November?). Umbraco realistically needs to wait until at least this time before it can investigate MVC related refactoring. In the mean time, there is a huge amount of refactoring to do. The items in this article are available to the community, and are just the first wave of refactoring which is required.

    Sunday, 2 June 2019

    Good Help Is Hard To Find - Tips When Hiring Digital Producers

    This is the seventh in a series of articles which will summarise my last half decade of hiring/outsourcing/offshoring experience as Head of Technology at the Cogworks.

    Firstly, I will only be using the term Digital Producer, rather than Project Manger.

    Read more about Digital Producers vs Project Managers.


    The best Digital Producer I ever worked with was a great facilitator. They didn't manage people. They managed obstacles. They lined-up work and unblocked our path.

    Hiring a Producer with the right background and attitude can be great for your work and company culture. If you work in software development you can almost always benefit from Agile methodologies, and that's what this article will feature.

    On a related note, in Scrum there are no Project Managers, only Scrum masters and Product owners. This article will dabble with a few Scrum terms, however it is aimed at companies who are not yet very Agile, and are still hiring "Project Managers".  Learn more at


    Having a good collaborative attitude is probably the most important attribute to any Digital Producer. 

    Developers can self-organise, and don't need an overlord *ehem* "Project Manager" to question what they are doing. They just need someone who can line up features so the developers can swarm on them. They need a person who can manage obstacles, not people. 

    Here are a few useful questions I wish every company would ask during the interview process:

    1. On a scale of 1-10, how much do you trust the developers in your current company.
    If the answer is anything less than an 8, then you should raise an eyebrow. They are essentially saying that they don't really trust the people they work with, and might be micro-managers.

    2. When a developer told you that something was taking longer than expected, what was your response?
    The answer you're looking for is something similar to: "I asked them is there was anything I could do to help us deliver?", then "Let's talk about the things we can deliver, and then go talk to the Product Owner / stakeholder to discuss re-prioritising the backlog and next steps".

    3. Can you tell me about your daily stand-ups?
    The answer you are looking for is: I try to facilitate the team talking to each other to solve blockages. I don't understand everything they're saying, but after 10-15mins if they have determined a plan of action for the day then I've done my job.

    Agile / Scrum / Kanban

    If your organisation is producing software then Agile experience should be very important for you. MVP, iterative releasable sprints, get feedback, adapt. 

    If you have Producers who are not at least scum certified, then definitely make this your first priority. 
    The certifications have a pass mark of 85%, so if the person has a certification from there, it is an indication that they have actually learned something about scrum and agile. The courses really challenge your views on how a project should operate. Someone who is Scrum certified is much more likely to be a facilitator. 

    Kanban is all about smooth flow, throughput, visual cues, measurement, and swarming. If person has this experience (ideally a certification), then it is more likely that they know how to facilitate smooth running of a team. Kanban doesn't care about assigning tasks to people, but rather encourages a pull based workflow where anyone can do the work. Kanban coupled with Scrum is a sweet spot which will see benefits of both.


    An experienced Producer should be able to tell you about the pros and cons of the tools they have used in regard to:
    • Feature mapping
    • Task tracking
    • Burn-down & burn-up charts
    You should be able to ask them about Stories on Board, Feature Map, Jira, Kanbanize, Leankit, Trello, spreadsheets. They should have an opinion. 

    If they are struggling to articulate their options then you should support them in their learning. Give them the task to review other platforms and present their views to other Producers. 

    Prince 2 & Waterfall Experience

    I'm not a Prince 2 expert, but I'll do my best...

    This type of certification has specific uses. For example, fields where safety and regulation matters such as construction, medical, legal all lend themselves to heavy documentation / regulation / check & balances. The functional requirements and initial documentation are heavily front-loaded.

    It is useful to understand different methodologies, however if you are working in digital agencies, software, or an organisation which is wanting to "be more agile", then this qualification / experience is not a priority on your search. People with this experience will likely be more inclined to be a "classic" PM who "controls" the workflow, rather than facilitates it. It might be hard to shake that habit. That said, if the person is smart and has a good attitude then get them Scrum certified ASAP and see how they adapt to your environment.

    On side note, you can definitely run a Scrum/Scrum-ban workflow inside a waterfall project. Just keep in mind that if you already have Scrum running relatively well, then a person with only Prince 2 experience might appear as being a micro-manager.

    Final Thoughts

    Attitude is super important. It can make or break your culture. Put heavy emphasis on finding out if the person you hire can jump in and facilitate your team, not "run" it.

    Having Agile experience (ideally scrum and kanban certifications) can give you some confidence that the person will be more likely to be collaborative, and facilitate smooth workflow.

    Check out my Scrum certification reviews below:

    Posts In This Series

    1. Interview Tips for Technical Leaders
    2. Tips To Ensure Quality Delivery When Outsourcing
    3. Tips When Taking On An Intern
    4. Tips When Hiring Senior Developers
    5. Tips When Hiring Junior Developers
    6. Tips When Offshoring Development Teams
    7. Tips When Hiring Digital Producers
    8. Tips When Hiring Remote Developers (coming soon)
    9. Tips To Improve Developer Retention (coming soon)
    10. Tips When Hiring Lead Developers (coming soon)
    11. Tips To Improve Developer Retention (coming soon)

    Saturday, 1 June 2019

    Technical Director at Radley Yeldar

    Three weeks ago I ended a 7.5 year run at Cogworks. I was planning on taking a big break, do some contracting, and see what the universe had to offer. Then came along a role which I could not pass up.

    Where Did I Land?

    Three days ago I started at Radley Yeldar (based in Shoreditch) as their new Technical Director. The organisation came from a business reporting background. They moved into print, brand & strategy, and now into digital.

    Staff perks include a roof terrace with a BBQ and a hot tub, and yoga on Tuesdays.

    What Will I Be Doing?

    Organisational and production processes are the things which I find very interesting, and I have been hired to usher in a new age for the digital side of the company. In the coming months I will be putting my energy into educating people from various disciplines about what it means to be Agile. I will be talking about Scrum, Kanban, and Lean Agile at every level of the company.

    I will also be looking at the current technology stack, how to optimise dealings with technical partners, project rituals, workflow management, and even sales incentives. Exciting right?!

    What About Tech?

    There is a lot of work coming up, and this is a very exciting opportunity. The team will help guide improvements in all of aspects, so this will be a clean slate where the team can choose the right technologies, the right tools, the right processes, the right training, and the right new people. I started this initiative on the second hour of my first day, where I held developer meeting and asked these questions:

    What do we do well?
    What can we do better?

    And before you ask...Yes Umbraco all the way!

    What About Developers?

    To meet the needs of up coming work, the team needs to expand rapidly! I have already put together a plan to hire 7 more developers. I will immediately seek to hire 1 lead, 3 seniors, and 3 mid-weights, with an initial requirement of 5 contractors (Umbraco) until we fill those roles.

    Final Thoughts

    When I left Cogworks I didn't actually want to take on another a full-time role so quickly. However, this role at Radley Yeldar  was so appealing to me that I could not resist. Organisational & Production processes are really interesting to me, and the prospect of rapidly scaling a development discipline is too exciting to turn away.

    Keep an eye out for great new tech deliveries coming soon from RY!

    Monday, 27 May 2019

    Stop Booking Developers


    If your organisation is booking developers then your quality could be better, your delivery could be faster, and your developers could be happier. 

    Organisations with digital/development departments will very often have projects, maintenance, support, and emergency work. When trying to mix these types of work, common questions you will hear include: How is this work scheduled? Who is working on this task? If your company is asking these questions then you are doing it wrong. 

    Class of service Issues

    Projects & Large Features

    Note: I tend to lump Projects and Large features into a single category as the development cycle tends to span many weeks. Projects tend to take months.

    This type of work would typically be booked in for specific developers to start on a specific date. That sounds quite normal, but what happens when their current work is taking longer than expected? What if a work item is super hard and a dev doesn't know how to do it by themselves?

    Support & Maintenance 

    Support & Maintenance work is typically small and might include small-medium features. The timing would likely be hours to days and is normally scheduled for specific developers to work on. That sounds quite normal, but what happens when they are sick, or are taking longer on previous tasks?

    Bugs & Emergencies

    If bug is not critical then it is common to schedule it in the same way as Support & Maintenance (see above). If the severity of a bug is high, then you will often see devs pulled off from other projects / work so they can deal with the emergency issue. That sounds quite normal, but what if the emergency is super hard to diagnose by a single person? Also, didn't you just kill the velocity of another piece of work?

    The Problem with Booking People

    All of the scenarios above have been examples of optimising for utility. As you can see, the practice of booking specific people for specific work is very fragile and susceptible to variances (eg. sickness, delay). Another important issue is that very often devs need help from other devs. How does this affect the other work?

    If you are booking developers then you might often see Project Managers fighting over "resource". This is really dehumanising for their colleagues, and causes a great amount of unhappiness.

    A better approach is to forget about booking individual people, and start thinking about how to optimise for throughput. After all, it's the delivery (throughput) which the customer requires.

    Optimising for throughput

    The first thing you need is a mindset shift. Forget about booking people. Throw this practice out the window. It's full of problems. The key is to have a pool of developers who organise themselves to adapt to the situations. 

    When developers self-organise this will often involve 2 or more devs swarming on a single work item. For example, it is very common for a single dev to take 2 hours to find a solution to an issue, where 2 or 3 devs working together might solve it in 10mins. This is optimising for throughput. Do the math!

    When developers self-organise, the work will be done quicker, and actually be better quality as the devs will need to come to a consensus about the approach. There will be less bugs!

    Kanbanizing Bugs & Emergencies

    In this situation we have a team of devs who tackle tasks together like a wolf-pac. All you need to do is line up the work in priority order, and they will handle it.

    If and emergency comes in then it goes to the top of list. Just notify the wolf-pac and someone / some people will deal with it. 

    Kanbanizing Support and Maintenance

    This class of service can be handled in the same way as Bugs & Emergencies. Depending on your requirements, you may have a team that can handle small work from several projects. This is ideal as it spreads knowledge among many people. Depending on the situation (eg. size of team), you could merge this team with the bugs and emergencies team. The key is to have enough devs to actually swarm on work.

    Rotating For Projects and Large Features

    But what about Projects & Large Features? Shouldn't you "book" those developers? Well kind of but not really.

    For example, every project should have a technical lead. However, it doesn't mean that they need to be developing. They can take a technical oversight of the project, and attend initial meetings. In fact, I recommend at least 2 technical people attending all meetings. So you really only need to ask the devs who will be the tech lead.

    The devs on a project should come from a rotation of the the other teams (Bugs & Emergencies, Support & Maintenance). Obviously you need to have enough devs for all classes of service otherwise they cannot rotate. When some work comes in that requires you to augment your capacity, then the new developers go into the pool, and the existing developers will help decide who is best suited for the new project.

    But When Will It Be Started?

    I have been in situations where people are pushing for work to start. This inevitably means stretching out the developer pool to only 1 developer per task. This means no more wolf-pac, and no more swarming. It is totally bonkers!!!

    Asking "when will it be started" is the wrong mindset. It means nothing without knowing your Cycle Time.

    The questions should be "What is our Lead Time?" and "What is our Cycle Time".

    This is a very easy question to answer. Based on the current team, they will have a known average throughput. If a team delivers 5 items per week, with a standard deviation of 1, then 20 items will be delivered in 4-5 weeks. This is our Cycle Time. If we already have 5 items in the pipeline from a previous set of work, then our Lead Time is about 5-6 weeks. I hope my maths is correct :)

    You don't need a gantt chart or even a burn down chart to figure this out. More on this in a later post.

    To find out more about Kanban and statistics, check out Lean Kanban University.

    Final Thoughts

    Booking developers comes with so many problems. You will constantly be chasing people, asking when people will be available, wondering why another work item is taking too long, appologising to clients etc. Creating developer pools really elevates all of this stress. Using Kanban to manage workflow also gives you very clear statistics of how the workflow is going. 

    I hope you have seen the benefits of optimising for throughput. The work output will be more predictable, faster and better quality.

    Monday, 13 May 2019

    Job Titles Form Mindset - Digital Producers VS Project Managers


    Job titles form mindsets and behaviour. I have been working in digital/web since 2007, worked at several companies and with dozens of Project Managers. Many organisations want to be "more agile", and it is my opinion that one of the first baby steps is to fix job titles. An attitude change requires a mindset shift.

    In this article I will discuss how to get your Project Managers to become more collaborative and less authoritative. This is a stepping-stone to a more collaborative Scrum mentality, as Scrum does not have the job title of Project Manager.

    If you come from a traditional project management background, then I ask that you please keep an open mind.

    Project Managers

    Project Managers are not evil, and most of them are not jerks. Very often the pressures that are felt by designers and developers are due the pressures "pushed" onto the PMs from further up stream (eg. client services, the company). This can exacerbate undesirable behaviours such as micromanagement.

    Many would agree with the opinion that this stems mindset of what a "Project Manager" is meant to do. They are meant to "manage". However, this elicits certain types of communication and behaviour which can dehumanise their colleagues. It is obviously not the PMs intention, however this is a result.

    Every time I hear these phrases / questions, I cry a little inside:
    • How do I book a designer for my project?
    • How do I know which developer will be assigned to my project?
    • When will you be done using Greg? I need to use him for my project
    • Can I have Greg next week?
    • I need a QA resource

    These are common things you will hear in a standard digital agency. The problem with these phrases is that they dehumanise the people who they are referring to. The people you work with are no longer people. They are resources to be handled and monitored. I have seen how developers and designers have been micromanaged and traded between PMs as if they were sauce bottles on a dining table. I have also seen really poor behaviour where PMs have become aggressive when it came to "protecting their resource", they were untrusting, micromanaging, and have even stopped other developers asking "their developer" for advice/help. This totally sucks, and is very bad for your work culture and morale.

    But but but... how else is a Project Manager is meant to manage things? Isn't a manager meant to manage tasks, people, time, etc. My project success means that I will get a promotion/pay increase.

    It doesn't have to be this way...

    The Best Manager Does Not Manage Anything

    The best "PM" I have ever worked with was an absolute joy. He didn't manage people, he didn't manage our time, he didn't manage our tasks, he didn't manage the client, he didn't assume any type of authority over anything in the project at all. He wasn't a Project Manager in the traditional sense. He was a facilitator

    He lined-up work, collaborated at ground level with everyone, asked if we needed him to do anything, he let everyone make their own decisions, he unblocked our obstacles, he cleared our path so we could succeed. He was an absolute joy to work with. He helped us produce great products for our customers. But he was not a "Project Manager". He was part of the project team, and trusted his teammates to do their part. The projects where he was involved in were the smoothest I have ever had the pleasure to work in.

    What I have just described is a person who would pass a certification without even doing the training.

    The Mindset of a Digital Producer

    When you refocus people on producing value rather than managing people/things, then a shift in mindset occurs.

    If you work in the digital space, you may have come across the role of Digital Producer at some point. It is very interesting that when a Project Manager title is changed to Digital Producer, then a load of different behaviours can emerge.

    There are plenty of PMs out there who are "managing" projects which have little value to the stakeholders/customers. However, a Digital Producer is actually meant to "produce" value. This is a mindset shift which can encourage more a collaborative attitude and behaviours.

    Many would agree that the job title Digital Producer better suits an Agile environment. The job title of Digital Producer not only sounds cool, it doesn't come with all the baggage of being a traditional PM. There is no longer an expectation for you to "manage" anything or anyone. The team/company/organisation only expects the person to facilitate the "production" of value for the customer/stakeholder. 

    If you are a Project Manager at a digital/advertising agency, you should totally ask for your title to be changed to Digital Producer. It is so much cooler!

    Digital Producers, Scrum Masters and Product Owners

    Let's talk briefly about Scrum...

    The next evolution of Digital Producers, is a splitting into 2 different roles which are Scrum Master and Product Owner.

    In scrum a Product Owner understands the stake holder's needs. They line up the features, and have full control of the backlog because they know what is most valuable to the stakeholder/customer. The Scrum Master is the facilitator of smooth workflow. This person is a coach. They prompt and facilitate conversation, and encourage people to be more mindful of good habits and processes. They are a servant leader.

    I have seen scrum work properly. It is amazing!

    Final Thoughts

    Job titles actually form a mindset, and these mindsets form behaviours. "Project Managers" are not bad people, however their title and role elicits some behaviour which really can dehumanise the people who are meant to be their colleagues. This is especially the case when the PM is getting pressure from further up stream.

    By changing the job title of Project Manager to Digital Producer, it can drastically affect the mindset of those in this position. People will start to be focused on "producing" value, rather than "managing" tasks & people. It is one potential first step in becoming more agile, and on the right path to facilitating production and fixing your work culture.

    I hope this article gave you some food for thought.

    Agile Mindset 

    A mindset shift starts from the right knowledge and training. If you are a leader who wishes to promote a real organisational change, then I highly recommend the Professional Agile Leadership certification.

    Check out my Scrum certification reviews below: