Insights

Godot Engine V3 (Open Source)

Have you ever wondered how difficult it would be to create a game in 2018? Truth is, it takes some time and effort but it’s not really difficult. There are many popular game engines available today for you to choose from. To name a few – Unity, Unreal Engine, Godot, Construct, Game Maker, Amazon Lumberyard, ARKit etc.

If there are so many to choose from why use Godot?

Well, Godot is an open source MIT licensed multi-platform 2D and 3D game engine that provides common tools so you can focus on making your game. To put this in simple terms, Godot is free to use, which means you don’t have to pay any money to use it, and after you have created the game and hosted the game there are no royalty fees involved as with other game engines. Godot Engine also supports cross-platform compatibility and makes it easy to export the game to multiple devices. The official Godot website can be found here: https://godotengine.org.

You can download Godot for your platform of choice here: https://godotengine.org/download. Godot is also available for download on steam and can then be found and launched under your software section.

To name a few of Godot’s features:

• Godot comes with hundreds of built-in nodes that make game design an easy task.
• Create node configurations with support for instancing and inheritance.
• Visual editor with all the tools needed packed into a beautiful and uncluttered context-sensitive UI.
• Friendly content construction pipeline for artists, level designers and animators.
• Persistent live editing where variations are not lost after stopping the game.
• Create your own custom tools with ease using the tool system.

What does Godot use to create these games?

You have a few options to choose from in terms of programming language. There is GDScript which is a high level, dynamically typed programming language used to create content. It uses a syntax similar to Python. Its goal is to be enhanced for and tightly integrated with Godot Engine, allowing great flexibility for content creation and integration. You can read more on GDScript here http://docs.godotengine.org/en/3.0/getting_started/scripting/gdscript/gdscript_basics.html.

There are also other options such as full C# 7.0 support using Mono, full C++ support without needing to recompile the engine. There are also additional languages with community-provided support for Python, Nim, D and other languages.

Some other supporting development features that Godot offer:

• Visual scripting using blocks and connections.
• Built-in editor with syntax highlighting, real-time parser and code completion.
• Integrated documentation. You can browse and search the whole API offline, without leaving the editor.

In this article, I will explain a few concepts of the Godot game engine and show a few of its features. I will also show some GDScript coding examples and explain what’s going on in the script. I will provide you with a sample game that you can use as a reference for creating your own game or you can add to the existing game for practice. I won’t be able to explain every single line of code in this article but the game files are available to you and should serve as a good reference and starting point.

Getting started with game creation

So now we begin with the fun stuff. Where to start when creating a 2D game? There are a number of places from which you can start. Some prefer to first create the level with all the objects in it and thereafter create the characters and in-game items such as power-ups and so on, but I prefer to start with the character and its movements and adding to the game from there.

When starting your game ensure that all contents you use are free and don’t violate any rules or laws in the way you use them. If you choose to download the character sprite sheets or background image for your game, make sure it is not copy protected or you will get into trouble if you plan on selling the game.

Now we will start with our game-specific concepts. First off you can download my sample game here: https://github.com/DewaldOosthuizen/retro_mashup.git. You can follow along with this article and use the game files as a reference to create your own game, or you can request access to this repository and add new levels and things on to this game. This game cannot be sold as the content I have used are not my own and selling them will break the licence agreement of using them. Therefore, this game will always be freely available for whoever has the link to the repository.

It this article, I will explain some of the concepts of Godot using my character scene. Before we start with our character, Godot gives you access to 3 body types for game development. First of is the KinematicBody2D type. We usually use this type of creating a game object that can move around in some sort of way. The character we will be controlling in the game will be using this body type. The next type is the RigidBody2D type. This is used to simulate objects which are affected by physics that the game engine handles for you, such as gravity. Godot automatically assigns a gravity strength to the object and you can configure the strength of the gravity. These body types should only be used when needed as they are the most resource intensive of the body types. The last body type is the StaticBody2D type. This body type is used for objects that should not be able to move. These objects are stationary. The floating blocks in Mario are stationary objects and so are the staircases, they would be built from StaticBody2D body types.

The image above shows your character scene.

The character scene exists out of all the components and nodes you are seeing on the image. The KinematicBody2d being the parent node and existing of a few child nodes.

CollisionShape2D

The CollisionShape2D is used to draw a shape around your character which you would like to identify as the shape that can collide with other objects. If you want your character to stop when walking into other objects, this would be the CollisionShape2D’s job. If the other object also has a CollisionShape2D object, the two objects will collide and they will stop. They won’t be able to pass through one another.

Camera2D

The Camera2D (which is the dark purple line you are seeing around the character) is used to make the screen follow your character as you move forward and backwards in your level. If you move out of your game screen size (which you can configure under editor settings) your character will keep moving but you won’t be able to see your character. The camera object allows for your character to always be in view as you move the character around in your world. You will need to play around with the camera position around your character until you are satisfied with the results.

Sprite

The Sprite node is the image or sprite sheet of your character. A sprite sheet is an image that consists of several smaller images. Combining the small images in one big image improves the game performance, reduces the memory usage and speeds up the start-up time of the game. You can then specify how many horizontal sprites are in the image, and how many vertical sprites are in the images. These are then split up into frames which can be used to cycle through these images and create the effect of the character walking or firing a gun etc.

Once you click on your Sprite node you will see a few options underneath your scene. These will display under the ‘Inspector’ tab. Here you will see a Texture option where you can drag and drop your image (sprite) or sprite sheet. Under the ‘Animation’ section you will see the options’ Vframes’, ‘Hframes’ and Frame. ‘Vframes’ is used to specify how many vertical images can be contained in your sprite sheet whereas ‘Hframes’ is to specify the number of horizontal images. The ‘Frame’ option can be cycled to see all images inside the sprite sheet and identify which images are assigned to which frame number.

Area2D

The Area2D object has a CollisionShape2D node as a child node. This serves as an area around your character where you would want to handle some type of event or check some type of collision. For example, if you walk into an enemy and collide, the CollisionShape2D object of the KinematicBody2D will prevent you from walking through the enemy but what would make you decide if you need to respawn or not? This is where the Area2D comes in. You can check all objects within the Area2D and trigger some function or method to handle the event needed.

Next to the KinematicBody2D node you will see 3 icons.

The first icon indicates that the node has a group attached to it. This is useful to classify certain object into a specific group. When creating enemies, you would want to put them all in the same group. Reason for this is that when an object enters your Area2D, and you identify it as belonging to the enemy group, you can trigger the right action or event.

The second icon indicates that the KinematicBody2D has a script attached to it. This means that the node is controlled by this script. It does not necessarily mean the object can move when a script is attached to it. It could have some code that just makes the object do something or perform some type of event and/or action.

The last icon, which all nodes will have, will hide and show the node in the 2D view of your editor.

Views

If you open Godot you will see 4 view options in the middle on the top of your screen. These options are 2D, 3D, Script and AssetLib. The one highlighted in blue is your current selected view. For our 2D game, we will only be using the 2d view and the Script view.

Looking at our game character

Making the character move and do things such as sliding or shooting can sometimes be a bit tricky. You will need to create this movement or action using the script view and writing some code for it. Currently, 400 lines of code make our character awesome and can still grow when adding more features to the character.

The first thing you will notice about the Script attached to our character node is that right at the top we can see that this script extends KinematicBody2D. This gives us some build in methods, variables and features specific to the KinematicBody2D type which we can then use to make the development or scripting process even easier.

Numerous activities in Godot are started by call-backs or simulated methods, so there is no need to write code that runs all the time. Although, it is still common to need a script to be handled on every frame.

Types of processing

There are two types of processing:

• Idle processing
• Physics processing.

Idle processing is activated when the method _process() is found in a script. It can be turned off and on with the _set_process(true) method. This method will be called every time a frame is drawn, so it’s fully dependent on how many frames per second (FPS) the application is running at. The delta parameter contains the time elapsed in seconds, as a floating point, since the previous call to _process(). This is useful for doing some calculations regarding movement speed and gravity setups which we will look into shortly. See the screenshot below.

Physics processing with _physics_process() is similar, but it should be used for processes that must happen before each physics step, such as controlling a character. It always runs before a physics step and it is called at fixed time intervals – 60 times per second by default but can be configured. The method _process(), however, is not synced with physics. Its frame rate is not constant and is dependent on hardware and game optimization. Its execution is done after the physics step on single-threaded games.

Though, we won’t be using the _physics_process() method for controlling our character, as our 2D game is quite simple and does not require much physics handling. Now let’s look at controlling our character with code.

The image above shows the _control() method which we pass delta into once again. This is not a build in method of Godot like the _set_process() method. You will need to create the method yourself. Inside our _control() method you will see a few other method calls such as _jump(), _move(), _set_speed() etc. These are all methods we will need to create to control our character. We will have a look at some of these methods after this.

Movement and collision

The move_and_collide() method is again a built-in function of Godot. This method takes one parameter which is a Vector2 indicating the body’s relative movement. Typically, this is your velocity vector multiplied by the frame timestep (delta). If the engine detects a collision anywhere along this vector, the body will immediately stop moving. If this happens, the method will return a KinematicCollision2D object. Vector2 is a 2-element structure that can be used to represent positions in 2d-space, or any other pair of numeric values. Whereas the first parameter of the Vector 2 is the x position and the second parameter the y position. The reason why you are seeing two of these method calls in the screenshot above is that we want our character to collide with something on the x-axis such as crates and enemies and we want our character to collide with things on the y-axis such as the floor. Our character will fall through the floor if we don’t use the move_and_collide() method. The reason we aren’t passing both parameters in on one method call is that this will make the character move very slowly, while constantly colliding with all object it touches. Even jumping up against a wall and touching the side of the wall will make the character move slowly down the wall as if it is sticking to the wall, and we don’t want this to happen.

Instead of using move_and_collide() to move the character you can use the move_and_slide() method call. The move_and_slide() method call automatically calculates frame-based movement using delta. Do not multiply your velocity vector by delta before passing it to move_and_slide(). The reason I did not use this method over move_and_collide() is because of the return type of these two functions. The move_and_collide() method call will return a KinematicCollision2D object which is useful to detect if you walked into other player objects. You will see me passing the object returned to another method called _handle_collision(), which I use to detect what should happen when my character is colliding with this type of object. Although this will not work on all object types. If you collide with something that does not have a KinematicCollision2D object type you will need some other way of identifying the object you walked into. This is where the Area2D node is useful. You can read up on these movement functions on the official documentation here: http://docs.godotengine.org/en/3.0/tutorials/physics/using_kinematic_body_2d.html.

Area2D

This is a 2D area used for detection and 2D physics influence.

The above screenshot shows how I used the Area2D object to determine if my character has picked up a power-up. The get_overlapping_bodies() method call returns a list of crossing PhysicsBody2Ds, which we can then use to look through all objects in the Area2D and decide how we would like to handle them. In this case, if the object is a power-up then we will increase the character's power by one and destroy the power-up with the queue_free() method. The safest way to delete a node is by using the queue_free() method. This erases the node safely during idle. This will release the resources hogged by the power-up object as well. When a node is freed, it also frees all its children nodes. Because of this, manually deleting nodes is much simpler than it seems. Free the base node, and everything else in the subtree goes away with it. Be careful to create many game objects and move them out of the screen but not freeing the resources they have used. This can dramatically affect your game performance.

Applying gravity to your character

Remember: RigidBody2D types have gravity applied to the automatically which you can configure in the Editor. However, our KinematicBody2D character does not have gravity applied to him automatically. Thus, we need to create the gravity effect ourselves. If you have a look at the screenshot below, this is how I replicated the gravity effect on my character:

const GRAVITY = 800
const MAXIMUMSPEED = 400

First, we will need a few constants. We will define a constant with the name GRAVITY at the top of the script and assign it a value of 800. We will also require a max speed variable for our player. We can create another constant called MAXIMUMSPEED and assign it a value of 400. We will then set our playerSpeedY equal to itself + our GRAVITY constant times the delta variable (playerSpeedY += GRAVITY * delta). This will apply our gravity for each delta time section of our framerates (The delta parameter contains the time elapsed in seconds, as a floating point, since the previous call to _process()). This will make our character come down gradually after we jumped until we touch the ground again. Even when we are standing on the ground the gravity is still being applied to our character.

The clamp function call in the screenshot above is used to lock the value of something. I have done this on the playerSpeedX variable and I have used the MAXIMUMSPEED constant variable as the measure I would like to clamp it by. This means my characters speed will gradually increase as I hold down my arrow buttons to move left and right, but it won’t move faster than my max speed I have specified. This is useful for controlling and limiting certain values.]

Since I have decided to use move_and_collide() to move my character I would need to multiply my movement speed with delta and my movement direction which will be either 1 or -1 to determine whether my character is moving left or right. Whereas move_and_slide() would automatically multiply the velocity by delta and we would not need to do so ourselves.

Animating our character

To make our character have different movements we use a sprite sheet to allow for cycling of multiple images as mentioned earlier. Firstly, we need to know when to animate our player. The above screenshot shows my characters movement frames. This will make the character look like it is running in the direction you are pressing. We want to check that it is only changing sprite images every 0.065 seconds of our current delta time which we calculate in our process() function by saying deltaTime += delta.

We will need to know which frames in our sprite sheet we will need to use for animating our character. In this case the move frames are [60, 61, 62, 63, 64, 65, 66, 67]. This is then assigned to a variable called moveFrames. You will see an if statement where I check that the current moveFrame is not greater than the amount of move frames we have, and if it is I will reset our current move frame back to the first move frame which is 0 (Remember arrays start at 0 and not 1).

We then set our player sprite frame to the current frame and increment the current frame by one. We set the player sprite variable in the _ready() method by saying playerSprite = get_node("Sprite"). We then reset deltaTime to 0 at the end of our animation phase to allow for checking the next animation frame. Now when we hold down our movement buttons, our character will be cycling through all of the movement frames and restart these frames once cycled through all of them. This makes it look like our character is actually running in the direction we are pressing.

Input Mapping

Input mapping can be found under Project -> Project Settings -> Input Map. Here you will find a bunch of input mapping already done for you, you can also add some more of your own. You can also set up multiple keys under one mapping description.

What does this mean?

Looking at our _jump() method we check Input.is_action_just_pressed(“move_jump”). This is a build in function that Godot offers us for checking if a button is pressed. On the Input Map screenshot above, where we define our key mappings, we would then need to define a new mapping called move_jump and assign a key to this mapping. I have assigned ‘space’, ‘up arrow’ and ‘w’ for my jumping action. This way players can choose their preference and play the game with whichever they are more comfortable with.

Instancing

What is instancing in Godot and where do we use it?

Instancing allows you to create one scene in Godot and then reuse that scene multiple times on different places.

Take a look at the above line of code. Here we preload a scene into our character script. This is the bullet scene we use to create a bullet when our character fires his weapon. We preload the scene because we don’t use it yet at this point. We know that we will be using it in this script and that is why we preload a reference to the scene.

This is how we actually create an instance from the scene we preloaded. After we pre-loaded a scene and created an instance of the scene, we can then work with the scene by referencing the bullet variable we have assigned the bullet_scene instance to. This can be done multiple times and saves us the effort of redoing all the code for the bullet scene every time we want to fire a bullet. It is best practice to save all your objects as scenes so that you can create instances of your objects and use them throughout the entire game without redoing the code for your object.

After creating an instance of an object, it does not add the object to your current scene or game view. You would still need to add the instance of the scene to your current view. This can be done with the below code.

Once this code has been triggered the bullet scene appears in front of your character. This is useful for altering the scene before actually adding it to the view. Before we add the bullet scene to our current game view, we set some values such as the position of the bullet and the moving direction of the bullet. Only after we have set these values we add the bullet scene into our game. If we did not do this, the bullet would not appear in front of our character and move into the direction our character is facing. It would start at the beginning of our level and always move into the same initial direction.

Exporting your game for your platform

To export your game, you will need to click on the Export option under Project.

Once you clicked on the Export option, you will find a new window opening up. At the top of the window, you will see an Add button. If selected, Godot will display all available platforms to you. Looking at the image below we can see a list of all the popular platforms.

The end

Godot makes game creation easy and fun. If you have ever wanted to try game development I would really recommend Godot 3 as your first option. Not only is Godot open source and free it also offers a large number of sample games and demos to get you started. By looking at some of the game projects offered by Godot you can get up to speed with game creation in no time.

We have not touched on all concepts of Godot, neither all the objects and code in the sample game I have provided you. But the ones we have touched on are some of the more important ones to get you started. I hope this article was useful to you and that it will intrigue you into trying game development with Godot.

You can have a look on the official Godot YouTube channel to see what some people have been working on lately and what true potential Godot has. https://www.youtube.com/c/GodotEngineOfficial.

I do not take any credit for the images used in my sample game

The images found in my sample game, I have downloaded at:
https://www.gameart2d.com/freebies.html
For the game assets in Freebies section, it's under Creative Common Zero (CC0) a.k.a Public Domain license.

You can also create your own sprite character sheets here:
http://gaurav.munjal.us/Universal-LPC-Spritesheet-Character-Generator/
All art is dual licensed: GPL3 and CC-BY-SA3

Yes, this is not a slip of the tongue - the intended term in the title is in fact “Scrum Manager”. So what could potentially turn a Scrum Master into a Scrum Manager, something which most Scrum Masters don’t even realise they are slowly becoming? Is it the things that managers are traditionally tasked with that Scrum Masters are now expected to undertake in order to fulfil their role? Let’s break this down.

If one researches what a Scrum Master is responsible for, one will most likely encounter the following terms:

• Agile process manager;
• Facilitator;
• One who lives and breathes agile values and principles;
• Servant leader;
• Protector of the team;
• Remover of barriers;
• Change agent;
• Improving the efficiency of the team;
• Encouraging collaboration;
• Coaching on all things Agile.

However, if you were to inspect some of the current roles and responsibilities Scrum Masters are being tasked with you will most likely find a plethora of different things that do not coincide with the traditional list. Let’s investigate what some of these might be:

• Being responsible for the team’s Sprint deliverables;
• Explaining why project deadlines were missed (this is wrong on so many levels!);
• Mitigating (project) risks;
• Managing relationships with stakeholders;
• Approving team members’ leave;
• Being constantly aware of team members’ working hours (clock watching?);
• Scheduling and coordinating of meetings, not just the Scrum ceremonies;
• Being the communicator of any and all requirements (even technical ones) from external sources. As in, “Send this notice of the server decommission to the Scrum Masters and they’ll make sure whatever is required will happen”;
• Being the secretary for the team; i.e. getting any team requirements, be it hardware, software, stationery, refreshments and food catering fulfilled, arranging for office moves, taking minutes at meetings, arranging functions/celebrations, etc.;
• Raising complaints with the relevant parties, and ironing out conflicts between team members, or between teams;
• Ensuring compliance of team members with HR policies such as ensuring that leave is submitted when a team member is not in the office, etc.;
• Managing and communicating production deployments - i.e. arranging all activities around a deployment and communicating relevant info to stakeholders before, during and after those deployments;
• Keeping and communicating up-to-date schedules regarding any kind of required dev standby or testing roster.

I’m pretty sure many Scrum Masters have found themselves doing at least one or more of the above tasks. Also, there are presumably many more responsibilities and tasks which Scrum Masters around the world are currently finding themselves saddled with. These roles may not necessarily be within the scope of what they usually would have perceived or accepted as part of a Scrum Master’s role.

One can clearly see that there is a mismatch between what a Scrum Master traditionally is supposed to bring to the table, and what they are slowly, and probably unknowingly, becoming: managers. The question needs to be asked: should this be allowed, is it healthy, and should Scrum Masters accept these responsibilities even though it may inevitably mean that they will have less time, bandwidth and focus to concentrate on the things that really matter? The things which help their teams continuously improve and become better at being agile? Though one could argue that having the Scrum Master undertake these tasks does, in fact, make their teams more efficient, enabling more flow and should be done.

We all know, and research confirms, that there is a definite difference between project managers and Scrum Masters. There is a reason why people choose to become the one and not the other. One focuses on the project and its delivery, while the other focuses on the team, trying to improve efficiencies and turnaround. Do organisations really believe that taking a Scrum Master and giving them (project) managerial responsibilities is the equivalent of “being agile”? Moreover, are they not selling themselves short of what they really deserve, jeopardising their noble intent of becoming agile and garnering all the benefits? Can those organisations honestly tell the world, their stakeholders, their shareholders, their own people, that they have embraced Agile, simply because they have employed Scrum Masters, yet continue to assign typical project management tasks and responsibilities to them? Or is this an evolution where an organisation aiming to become Agile naturally progresses through? Is the final destination a place where Scrum Masters come into their own and do what they were always supposed to do – incrementally and consistently improve the team’s performance via inspect and adapt?

On the other hand, one could also argue that a Scrum Master should simply accept that they will do whatever it takes to help the team perform at their highest level, whether that includes any of these “managerial” tasks or not. Perhaps we should just ignore this discrepancy between the roles and simply accept that it’s “part of the job”. Maybe the role of Scrum Manager is, in fact, a legitimate one which has evolved out of necessity. If improving our teams’ performance and our organisations’ adoption of Agile means that we will do such managerial-type tasks, then so be it! Let’s give the benefit of the doubt and ask why not? Yet if so, we cannot avoid asking ourselves the following question: are we doing ourselves, our teams, our organisations, and our profession a disservice? Is there a price to pay for becoming and being a “Scrum Manager”?

With the advent of new and far more stringent compliance rules and regulations surrounding data privacy and security coming into effect towards the end of last year, DVT is delighted to announce that we’ve completed – and attained – ISO 27001 accreditation.

Today’s decision-makers are faced with the necessity of making big business decisions faster and more accurately than ever with software solutions.

Unlock the true potential of your business with comprehensive Business Analysis. Gain valuable insights and drive informed decision-making.

Machine learning, Artificial Intelligence, Robotic Process Automation, Cognitive Services, Interactive/chat Bots. These are terms you will come across in literature and conversations almost every day. What do they really mean and more concerning to the average person what will be the role of the human employee in this new digitally transformed world that we are rapidly moving towards?

One of the burning questions for many project managers today is whether or not working in an Agile environment is a threat to their role. The short answer is no, but there’s more to this perceived ‘threat’ than meets the eye.

As a project manager, unless you’re particularly precious about your ‘title’, Agile is something you should embrace, not fear. After all, Agile is a project management methodology that uses short development cycles called ‘sprints’ to focus on continuous improvement in the development of a product or service.

But this is only part of what Agile is about; it’s a philosophy made up of 80% ‘culture’ and 20% delivery method, wrapped up into a way of being and doing that permeates every aspect of professional life – not just the project at hand

In this regard it’s a major departure from traditional project management in the way teams are structured, hierarchies flattened and tasks accomplished, and could be considered ‘foreign’ to you if you come from a strictly traditional project management background.

Earlier I mentioned this is only an issue if you’re precious about your title, because in this new Agile environment you’re no longer a project manager but rather a value generator and facilitator, working as part of a holistic web of teams all pulling in the same direction to achieve the same set of ever-changing goals.

If this all sounds like a lot to take in and getting used to, you’re right, it is. It necessarily requires you, as a traditional project manager, to change your mindset. Do you see yourself as a project manager or an enabler? A ruler or a leader? The latter is where you want to be, the former what you want to leave behind.

If, as a project manager, you’re helping facilitate people and teams through a process in the business by means of purpose and through trust, you’re already there – you’re an enabler – and in the Agile sense, you’ve arrived. If, on the other hand, you’re still obsessed with rules and structures, and like to think and act sequentially with a well-defined chain of command, then there’s work to be done….

That work involves actively changing the way you think, and therefore act. You’re literally going to be creating new neural pathways in the brain – a science called neuroplasticity, which we don’t need to get into here. It’s enough to know the old adage that ‘old habits die hard’, and so the work involves changing your habits.

Think of it like a new gym routine; the first few days are a real struggle as your body adjusts to a different way of doing things. By the third week, however, the constant repetition has created a new behavior, and within a year or less, the neural paths are set and the new behavior becomes your default. The only expectation of you is to unlock your mind so that it’s receptive to the changes it needs to undergo. The Agile frameworks that area available will help you create a new routine.

Make no mistake – Agile is here to stay, and is the way of work in the future. The days of planning, managing the plan, and sticking to the plan ‘no matter what’ are over. It is critical for you to be able to maintain a certain level of flexibility in order for you and your team to change course in response to demand. The only predictability you want to see, is the predictability in terms of the team validity. We no longer want a predictable and planned outcome in terms of scope.

The good news is that switching on an Agile mindset needn’t be difficult, and I’ve put together some pointers below that will make your journey even easier:

1. Get training.

Even if you start with a basic 1 day Agile bootcamp – Agile fundamentals training, for example – you’ll get some understanding and appreciation for what this ‘Agile thing’ is all about. It’s not a natural change.

2. Focus on keeping the scope flexible.

This is a fundamental departure from the world of traditional project management. Enable teams to ‘pull’ work rather than push work to them. Create a backlog of items that need doing, and enable teams to pull from that backlog on demand.

3. Be as transparent as possible.

Anything that you want to do, do it transparently, not only with stakeholders but with the entire team. Even share your thought process and build trust.

4. Value the voice of the project team.

Empower your people. Don’t be the know-it-all; they are the subject matter experts in what they do, so let them do it.

5. Facilitate business to prioritise the backlog

Facilitation is still 80% of what you do in an Agile project management environment.

6. Make projects fun again.

If it’s fun, your team is fully engaged. Many times in traditional environment teams are split between projects, so make them want to be part of yours.

7. Drive the minimum viable product (known as MVP) at all times.

Limit your teams’ output to something that’s functional. You don’t need to work to Rolls Royce standards if you only need a Ford to get you there. The quality will come when everything is working as it should because we did not try to be superman in the process.

Remember, drive value at all times, enable and trust your team to do the job, and don’t see yourself as more important than the team. If you think you’re always the most important person in the room, you close yourself off to changing your mindset, and in doing so, Agile becomes the threat it doesn’t need to be.

This article was written and published exclusively for ITWeb Insights on the 15 November 2018. View the original article here: https://www.itweb.co.za/content/JN1gPvO195wMjL6m

Why do we refer to usability testing as a lady? Read more to find out, as well as the difference between this and user testing and more.

A product owner is typically the project's key stakeholder. Part of the product owner's responsibilities is to have a vision of what he or she wishes to build and then to convey that vision to the scrum team. This is crucial to successfully start any agile software development project.

For the past nine months, I have been a product owner on a project and this is how it is playing out for me. But, before I get there, let's look at the real-life definition of the term.

A product owner is the stakeholder on a project who most likely has a day job but also needs to spend most of his week taking part in an agile project and all the ceremonies it brings along with it.

Based on my experience, a product owner needs an extremely clear vision of the intended outcome of the product being developed. They need to understand where the product fits in with the rest of the organisation and its related systems. Without that insight, your team will be developing a product that will not be used by the people intended to benefit from your product. It's that simple.

It is a very empowering position to be in and it should not be abused by enforcing your design ideas onto the product and the project teams. It is a collaborative effort in which everyone in the team has a say, but ultimately you know where the product is heading towards, which means the final decision-making power lies in your hands, and rightfully so. A product owner should be a servant leader where the team is empowered to deliver what you consider necessary without them wanting to exit. Therefore, ensure the team has a purpose and are working towards a common goal. Involve them in the project roadmap and the decision-making process.

How much time should you invest?

A product owner needs to manage their time adequately in order to be able to pay as much attention as required to the design and development lifecycle.

Here are the number of hours I spend on a project in order to steer a successful outcome at the end of a 2-week sprint.

Backlog Grooming	6 hours
Sprint Demo	2 hours
Sprint Planning	4 hours
Sprint Retrospective	1 hour
User Testing	4 hours

What does this mean?

It means I had to put aside at least 8 hours a week on an average sized project (4-6 members). If you are the owner of more than one product, those hours will multiply.

Being there for your team

Let's analyse a pile-up on a multi-lane highway and compare it to a product owner's role. The metro police (product owner) needs to make sure that the right decisions (backlog grooming) are made swiftly in order to avoid a traffic jam (development idle time). Whilst the rubble is being cleared (tasks in-progress) the metro police (product owner) also needs to reroute (feature prioritisation) motorists (agile dev team) in order for approaching traffic (future tasks) to know where to go so that they can reach their destination in the most effective way (adapting to requirements). In the absence of the metro police (product owner) traffic (work) will pile up and motorists (Agile dev team) will become annoyed at wasting time and not reaching their destination on time (delivery expectations). If there are queries and questions to be answered with regards to alternative routes (business rules and process changes), response time is key or else the motorists (agile dev team) will be held up instead of being able to cruise at 120kmh (continuous delivery).

Serving as a product owner is a very rewarding role especially once you see how an agile team operates to their full potential and your product comes to life.

Involve as many stakeholders as you deem fit to ensure product buy-in and at the end of the day be sure to allocate enough time in your working week to see a quality product rolled out.