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
Agile leadership allows the discomfort of being vulnerable and transparent, earning the respect of followers by not leading from a distance.
Gartner describes digital business as “the creation of new business designs that not only connect people and businesses, but also connect people and businesses with things to drive revenue and efficiency. Digital business helps to eliminate barriers that now exist among industry segments while creating new value chains and business opportunities that traditional businesses cannot offer.”
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”?
Overcoming Roadblocks in the Agile Transformation Process. Identify Symptoms, Find the Fix, Avoid Stagnation, and Take the Lead Today!
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.
Problematically, as with any journey, the beginnings and the ends tend to carry an inordinate amount of perceived value. If you invest too much planning in the beginning, chances are most of it will be wasteful, because things invariably change along the way. You’ll want just enough planning to get you started, and then recalibrate along the way.