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”?
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.
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.
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?
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.
How to create RESTful web services & RESTful API - where REST stands for Representational State Transfer using Python, Flask, Docker and MongoDB
So, you’ve been a part of the business analysis practice for 10+ years and with so many people being appointed as business analysts it is important to distinguish yourself and make sure your skills improve and adhere to international standards, right?
Disruptive technology significantly alters the way industries and businesses function. It can force companies to embrace the digital sphere or stay behind.
As a UI designer, I have had the privilege of witnessing weird and wonderful client comments, especially these classic and timeless ones. “Dear, *insert designers name*. Thanks so much for the latest round of designs. Really coming together nicely. Few points of feedback: *Insert long list of changes*”. That is by far my all-time favourite, and until this day I sometimes feel like I’m being punked when a client approves a piece of creative without any suggestions. It just doesn’t feel right. But I digress.
A few years ago I was part of a team tasked with presenting low fidelity (grey scale) wireframes to a large corporate client and we were going around the room introducing ourselves and sharing our roles and responsibilities. A time came for the UI team to introduce themselves and the client turned, looked at us and said “Oh so you are the guys responsible for colouring this thing in?” We giggled and continued with the introductions but that comment lingered in my brain for years.
Image credit: coloringcorruptions
Is a UI designer’s role really just to colour in wireframes? In oversimplified terms yes you could say that UI designers do colour in wireframes. There's a lot more to UI than just “colouring in” but I won’t get into that right now. If you would like to read up on UI design click here. Let’s ignore all the other hats a UI designer has to wear and only focus on the notion of “colouring in”.
Isaac Newton was one of the first humans to play around with colour, using sunlight and prisms (Photoshop wasn’t around back then). He found that clear white light was composed of seven visible colours, the colours we see in a rainbow. By doing this Newton paved the path for the likes of Johann Wolfgang von Goethe and all those who came after him including myself, to experiment with colour in a “scientific” manner.
Image credit: Granger
Goethe challenged Newton’s views on colour, arguing that colour was not simply a scientific measurement, but a subjective experience perceived differently by each viewer. His contribution was the first systematic study on the psychological effects of colour. Goethe’s views were widely adopted by artists around the world.
In visual arts, colour is the soul of everything, birthed to life by the artist into a canvas. Colour is power, actually. It can change the mood of the image in the blink of an eye. It can encourage, warn, appeal, frighten, highlight and persuade. It can support the words or vice versa – steal their power. It can share an emotion without anything being said. It can become a great weapon in the hand of a master.
In the sphere of UI design on the other hand, colour is one of the key steps to efficient results. It is actually a multi-functional and diverse tool able to fulfil several needs simultaneously. Unfortunately, humans don’t all interpret colour the same way. We somehow don’t share the exact same colour vision experience. Because the human eye and brain work together to translate light into colour, each of us sees colours differently. Your blue can be slightly bluer than someone else’s. However, sometimes differences in colour vision are tragic.
Image credit: Harry Quan
According to Colour Blind Awareness, approximately 338 million people in the world suffer from some kind of colour vision deficiency. Depending on the seriousness of the deficiency, humans can go from not seeing colour clearly, getting colours mixed up, not being able to differentiate between certain colours or lose the ability to distinguish colours at all.
Every kind of colour blindness makes it difficult for a user to have a great experience. At worst, colour blind people will not be able to use a product at all. This will upset a lot of users and a business will lose potential clients too. To avoid this, UI designers need to consider only a couple of simple rules when designing interfaces.
It is important to understand that colour blind people see the same colourful picture as the rest of us. Despite an inability to see some colours, colour blind people distinguish shades even better than average. Creating sufficient contrast between elements is an effective way of designing for accessibility. By catching the user’s attention and attracting them to particular elements supports quick and intuitive navigation and usability of the page or screen.
As much as colour is the soul of everything, one needs to understand that it doesn’t have unlimited powers. You shouldn’t expect it to solve all of your problems. However, when implemented correctly and paired carefully with considered layout, good typography, captions, iconography and so on, colour is able to beautify UI and improve UX.
Creating interfaces is not just about pure creativity. It is all about providing users with the product that will heal their pain and make their life simpler. So, in the perspective of colour choices and usage in UI, a designer should always remember that the interface should be highly usable, clear and accessible. There is never a universal solution or a one-size-fits-all solution to colour usage in UI design, so go forth, experiment, and colour in those wireframes.
Useful links
https://colorable.jxnblk.com
https://michelf.ca/projects/sim-daltonism/
https://www.awwwards.com/talk-escaping-convention-with-executive-creative-director-at-ueno-david-navarro.html
https://www.designyourway.net/blog/design/colors-and-contrast-in-user-interface-design/
https://blog.prototypr.io/how-to-use-color-in-ui-design-wisely-to-create-a-perfect-ui-interface-6e524bd023bc
https://medium.muz.li/designing-for-accessibility-the-colour-contrast-compliance-7d8902850ec7