How many effective hours are in a typical work day?

In software development, the number of effective work hours is not the same as the number of hours you are at work. I'm going to be upfront and say it is never as high as you think it is.

This article is meant to give you a feel for what your effective hours might actually be.

Effective development hours calculation

Let's start with this formula for calculating effective work hours. 

E = W - (D + C + M)

E: Effective development hours per day

W: Work hours  

D: Time for daily non-development duties

C: The time penalty for context switching x the number of non-development duties

M: Time lost for morning inefficiency

We'll fill these in as we go...

The 8hr working day

Let's assume that you are working for 8hrs, not including your breaks. Developers tend to be encouraged to estimate tasks based on this full day. 

If I was fingers-on-keyboard effective 100% of the time during all work hours, then a task that I estimate for 1 day should be my maximum theoretical output of 8hrs. But this is never the case.

E = 8 - (D + C + M)

Let's deduct time for detractors

Here are 5 non-development items (with some average numbers based on my experience).

• Emails (15min)
• Standup (15min)
• Meetings (30min - may be more or less depending on the day)
• Meetings within a sprint are likely to include:
• Scope/requirements/design discussions
• Architecture discussions
• Backlog grooming
• Sprint planning
• Sprint review (and possibly a demo)
• Sprint retrospective
• Misc.
• Helping others (e.g. to debug, code review, aid decision making) & misc duties (15min - may be more or less depending on your role)
• Random chatter (15min)

These 5 non-development items mean that 1.5hrs are deduced from each day on average. 

Now your day only has 6.5hrs.

So you are 100% effective for 6.5hrs right? No!

E = 8 - (1.5 + C + M)

What about context switching?

The multiple distractors have a cost.

Image from: https://pacohq.com/blog/guide/the-high-price-of-context-switching-for-developers/

Every time you change tasks, it takes time to ramp up to full speed. We call this getting into a flow state. According to Very Well Mind it can take around 10-15min to ramp up. For some tasks it could take a lot longer!

For the sake of this discussion, let's keep this conservative. Those 5 detractors require 15min each, totalling 1.25hrs. Note that this assumes that you only check your emails once per day, and help someone once per day.

Now your available time is 6.5 hrs - 1.25hrs = 5.25hrs

E = 8 - (1.5 + 1.25 + M)

It gets worse!

In my experience, those 5 items are spread throughout the day, and mornings are particularly inefficient. Here is an example schedule.

• 9am - Get to work and settle in
• 9:15am -9:30am - Check emails
• At this point you already lost 15min of the day
• 10:00am - 10:15am - Standup
• But what happened to the 30min between checking emails and standup?

In this example we effectively lost 45min of the day.

Subtracting 45min of the day...

Now you have only 4.5hrs of effective development time to do your tasks.

E = 8 - (1.5 + 1.25 + 0.75) = 4.5hrs

Final thoughts

Some of you will be thinking that 4.5hrs of an 8hr day is not reasonable. 

You may be yelling: What if you line-up everything back to back? 

Sure! I actually recommend this! So let's assume you can totally remove the morning inefficiency by having a 915am standup. You are still only at 5.25hrs of effective development time per day. 

But what if you could reduce meetings too? Yes! You should totally reduce meetings. However, you may find that you still need a few of those meetings per week. So you cannot just say no meetings at all! In my experience, you "might" be able to squeeze 5.5hrs of effective development time on average per day.

At this point I would also remind you that people are not robots. We have slow days, and we also make mistakes. Software development is not like building a brick wall, and you have to be realistic about your effective hours, not just count the number of hours in the day.

In my experience I typically say that 5hrs is the number of effective hours per day. This is realistic based on the numbers above, and also allows for a bit of wiggle room.

I hope this gives you food for thought.

The next time you estimate 1 day for a task, remember that your effective hours per day is not 8hrs. It is likely closer to 5hrs.

Software Engineering On A Board

I have hired dozens of developers over the years. At some point, I started keeping a list of all the skills and knowledge that I want developers to have. 

A year ago I made public this Trello board: Software Engineering On A Board

I envisioned this as being a summary of an Applied Software Engineering course.

Developers who work with me will experience most (if not all) of these learnings at some point. Many of these topics will definitely challenge people to think differently, and hopefully wholistically about code,  architecture and systems.

This board is definitely open to contributions. So if you want to contribute to making it better, please get in touch!

Project Management Methodologies - Agile or Waterfall?

When it comes to project methodologies, the answer is not as simple as just doing Agile or Waterfall. It often really depends on the project, the type of work, the stakeholder, and the types of people in the team.

There is one word which really gets under my skin and that is “Wa-gile”. There are companies who say that they are Wa-gile. It seems that this means that they have adopted some of the terminology, but have not bothered to read or understand the agile manifesto. So they use the terminology but not the practices.

Waterfall - What is it good for?

The type of work and the stakeholder may necessitate doing things in a Waterfall fashion. 

If you are working with design jobs (no development) they go from scoping to concept, to versions, to final sign-off. These types of projects are very much Waterfall by nature. You can however make them more efficient by reducing documentation in favour of "versions". In design projects you will typically go back and forth with multiple versions anyway. So there's little value trying to document every design element before you even do a mockup.

Government projects also tend to be very prescriptive, and front-loaded with specifications. Therefore Waterfall is quite common even with technology builds. This is a scenario where the stakeholder basically forces the start of the project to run in a certain way. 

Sneaking In Agile

In software development, running an entire project in Waterfall often leads to disaster. The projects over run, and the tail end of the project and drag on longer than the original project. Fear not though...

It's totally ok to have a front-loaded Waterfall project, because you can still run a Waterfall project in an Agile way. Some clever stakeholder hand-holding may allow you sneak in some agile principles to help the project run smoother.

Ways to sneak in some Agile

• Reduce the word length of any documentation in exchange for diagrams, and external links to definitions & other documentation
• Do sprints during the build
• Define a tangible sprint goal
• Each sprint must deliver a "done" increment of the product
• Demo to the client as often as possible
• Ask for frequent check-in points
• You can even call these status meetings
• Tell the client: Even though things are heavily scoped, there are always some stakeholders who wont like something at the 11th hour, so we want to try to be proactive so the project doesn't over run

If you can’t get the stakeholders time, then ask for someone to be in their place. If there is total resistance from anyone on the stakeholders side to be engaged in the project then I would suggest that you nominate a person in your organisation to be a surrogate stakeholder. This person would try to understand the stakeholder’s motivations. 

Hopefully you can see that even though a Waterfall project is very front-loaded, internally you can actually have a few rituals in place to run it in an Agile way.

Final Thoughts

I hope I have shown you that it's not always as simple as Waterfall vs Agile. Waterfall is ok for some types of work, and sometimes the stakeholder (eg. Government departments) forces this on the project team. In software development this can be a disaster, so in my opinion it is really important to add Agile principles into the project. You can still have a Waterfall project, while using Agile principles.

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

Introduction

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.

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.

Introduction

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 scrum.org

Attitude

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 scrum.org 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.

Tooling 

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:

• Scrum.org Professional Agile Leadership Review
• Which Scrum Certification Should I Get?

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 People
9. Tips To Improve Developer Retention (coming soon)
10. Tips When Hiring Lead Developers (coming soon)

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!

Stop Booking Developers

Introduction

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.

Job Titles Form Mindset - Digital Producers VS Project Managers

Introduction

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 scrum.org 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:

• Scrum.org Professional Agile Leadership Review
• Which Scrum Certification Should I Get?

Scrum.org Professional Agile Leadership Review

Over the Easter break I decided to take the certification exam on scrum.org for Professional Agile Leadership. This is my review of exam and reading material.

Reading Material / Resources

The reading material is quite an easy read. It consists of bite sized chunks of information and concepts.

There is a significant focus on scrum/agile values. In my opinion it seems geared toward convincing managers to embrace new concepts. Ie. If the person is a micromanager or doesn't allow their staff much freedom to think, then this course helps convince them to be more supportive rather than authoritarian.

My only issue with the reading material is that it seems splattered among many articles, blogs, and disparate videos. I wish it was better structured. I would have preferred something more resembling a textbook.

Practice Exam

I actually found this very easy as I had previously done the Professional Scrum Master Certification. The questions were short and easy to comprehend. I was able to get 100% very comfortably. This gave me a sense of confidence that I would do fine with the actual exam. I was wrong...

The Actual Exam

The exam was 36 questions in 60 minutes. The pass mark was 85%. This meant that I needed 31 to pass. In comparison, the Professional Scrum Master exam had 80 questions in 60 minutes with the same 85% passing grade. With this in mind I entered the exam thinking that it should be easier to obtain as it was less than half of the questions. I was wrong.

The actual exam far more difficult than the practice exam. The questions where heavy in text, with most them setting up scenarios over a paragraph. It wasn't simple, so it was very much an exercise in English comprehension to understand the depicted scenarios.

I did actually pass (here's proof!), but there were times during the exam where I was questioning whether I actually understood the scenario. Be prepared to be caught out by wording if you are not careful.

Summary

The course material is a pleasure to read. Everything is in bite sized chunks which is easy to understand. The practice exam is way too trivial compared to the real exam, and will give you a false sense of confidence. The actual exam is heavy in text, and hence your English comprehension skills will be flexed.

Definitely a worthwhile certification to have, and it did open my eyes to how I can become a better leader.

Which Scrum Certification Should I Get?

Recently I decided to brush up on my Agile/Scrum knowledge. I decided to do some reading on scrum.org, and even decided to do the sample tests. The pass mark is 85%, so they're not for the faint hearted.

This week I did quick skim through the materials for 4 of the certifications, followed by the sample tests. Here are my quick thoughts, and exam results :)

Professional Scrum Developer

Firstly, I want to say that this certification is a MUST for developers. In fact, the very day I looked into it, I suggested that all Cogworks developers be certified. If only I had known about it years ago!

The material also covers topics which you would not normally expect from a scrum course. 

Just to name a few: 

• Good coding practices
• Continuous integration
• Continuous deployment
• Test driven development
• Quality

If you are a developer (of any level), this is the course for you!

BTW, my mark on the practice test was 26/30 (86.7%).

If you have been working in a good dev team for a few years then you can probably pass this certification without doing the course. Just put aside some reading time.

Professional Scrum Master I

This is an interesting certification, as the role itself typically sits in the middle of developers and the Product Owner. There is a huge emphasis on being Servant Leader who facilitates development. I have worked with some great Scrum Masters in the past, and is really a great feeling having someone there to help unblock the dev teams obstacles. 

Project managers who get long well with developers and prefer to be less exposed to stakeholders might enjoy being a Scrum Master. If you come from a traditional Project Management background then you might find this material a bit challenging of your beliefs. Try to keep an open mind.

If you are a senior/lead developer who is process oriented, then this course could open your mind to another perspective of the project lifecycle. Just don't expect to be both a developer and scrum master. At some point you will need to chose which one you want to commit to. 

My score was much better in this course at 29/30 (96.7%). I owe this to the fact that the material and exam have commonalities with the Professional Scrum Developer course, so this might be a good choice for a 2nd certification for developers. 

If you have been working in a scrum environment, team for a few years then you can probably pass this certification without doing the course.

Professional Scrum Product Owner I

This certification puts you directly in the line of fire when it comes to stakeholders. If you are lucky enough to be in an organisation which gives you budget power, then this role can be like a "mini-CEO" of a product. There is a focus on stakeholder management, and the Product backlog.

If you are a project manager who already knows how to write user stories, then you will find aspects of this material familiar. 

My mark was 14/15 (93.3%). After doing the previous 2 exams, this one was relatively easy as it crossed over a lot with the Scrum Master material. This could be an "easy-ish" 2nd certification for people who already have the Scrum Master certification. Be aware though, scrum specifically says that you cannot & should not take on 2 roles in the team.

If you have been working in a scrum environment, team for a few years then you can probably pass this certification without doing the course.

Professional Agile Leadership

This material felt geared toward managers, CEOs, Technical Directors etc. 

If you are interested in organisational change, and you are at the appropriate level in your organisation then this is a very valuable course.

If you are a head of an organisation and you have problems with micromanagers, then send them all to this course. It will hopefully get them to be more collaborative.

Yes I finally got 100% in one of these tests!

Final Thoughts

Doing these tests was just for a bit of fun and learning. It's definitely worth testing yourself from time to time, as we all inevitably forget terminology and get sloppy with practices.

If you just want the certifications, the prices are quite reasonable at $150-$250 USD each.

I recommend actually doing the courses first as the concepts are not necessarily light. Although, if you work in a company that implements Scrum, then you might have enough knowledge/experience to just do the reading.

Digital agile kanban boards. Is LeanKit the final answer?

The biggest gripe I've always had about Trello is that it very often forces teams/organisations to change their process just so they can use the tool. We end up using it (and tools like it) in strange/confusing/inconsistent ways, just because the tool has no better way to visualise a certain state/activity. We start labelling in strange ways, we think a card movement should send someone an alert, we even name things differently, and create "separator cards" to visually split the board.

Tools like Trello were never ever meant to dictate or change your processes. They were only meant to help to visualise and share the current state of work. The most common recommendation from any seasoned Agile/scrum/kanban consultant is to map your value stream on a physical board. Each column is a step in your process. It should make complete sense there. It should then be directly translatable to a digital board. If not, then the tool is not right. But here's the problem... there have never been any good tools that perfectly fit your processes in the way a physical board does. 

When I first created the kanban process for Cogworks several years ago (around 2015?) I researched many tools. Over the years I have tried Trello, Jira, Wrike, Asana, Kanbanize, Pivitol Tracker, and many more. We ultimately stuck with Trello only because all the other options were still bad in their own way. Why swap 1 bad solution for another bad solution?

Now after several years of searching, I have finally found the real killer online tool for workflow management. Real visualisation of processes, and actually flexible in the way that you would use a physical board. 

Introducing Lean Kit : https://leankit.com

What does Lean Kit have?

Swim lanes

Absolutely necessary for varying classes of service!

If you're running multiple projects with the same team, then you can use lanes to visualise these in parallel just like a real board. Ever tried to do this in Trello? It's stupid. Trust me. We tried!

Overview rows

Great to track higher level progress of Epics, Releases etc. You cant do this in Trello, and one common hack is to create another board to act as an "overview".

Sub-columns

Absolutely necessary for a kanban board. Many steps in your value stream have sub-steps. These steps might even involve a different department, so having sub-columns is super helpful, and quite common in physical kanban boards.

Parent/child card linking with back links

Card relationships are very useful. Perhaps one feature needs to be the super-feature of another. Or perhaps one "relies" on another.

I created a hacky linking feature in Trello which I never really liked.

Dedicated blocked/unblocked status

It just makes sense!

WIP Limits & Automatic Visual Alert

This just make sense! You always want to enforce a WIP limit so you can concentrate on delivery, rather than starting more work. Unfinished work is of no value.

Tasks 

These are cards which are never seen the actual board. They live inside a sub-kanban board which lives inside the original card! This is a killer feature. I've wanted this for so long.

In Trello we previously used a hacky workaround which involved labelling cards as a "task". However these would clutter the board, and people tend to get confused about the definition between a task, and a work item. Then everything is called a task :(

Also, tasks generally don't have any value to anyone other than the developers. eg. How does a QA person manually check a database schema or API endpoint in the context of the original features acceptance criteria?

Comments & history hidden by default

These items are kept AWAY from the card details, reducing clutter, and hopefully encouraging conversations. When you use a physical board, comments and history are never even a consideration. If you need to know something, then you ask a person.

When using Trello, people will tell me "read the comment". People think that when they write a comment on a card then they have done their job. Frankly that's just laziness.

Conclusion

These are just some of the "real physical board" features I found super useful. I bet there are many more intuitive common sense features which I am yet to even discover.

This is the tool! Everything about LeanKit is clean and obvious. As far as I can tell, it is just like how a company would use a physical board. No more strange / hacky work arounds.

Is LeanKit the final answer? Yes. I believe it is.

If you are on Trello, I strongly recommend investing time to migrate to Leankit. You won't regret it! 

ps. I have no affiliation with LeanKit at all. This is my totally opinionated review.