Skip to main content

Tag: Agile

The Project Manager is not a Scrum Master

Written by Paul Oppong on . Posted in Articles. 3 Comments on The Project Manager is not a Scrum Master

A common question that arises is whether the Project Manager should be a Scrum Master.

Project Managers are sometimes expected to simply take up the role of Scrum Master when their organisation moves to taking an agile approach. This may well occur without the Project Manager being provided any training to take on this new, and quite distinct role. However, a recent survey by Scrum.org found that fewer than one third of organisations (31%) assign the role of Scrum Master to a Project Manager, and there are very good reasons for this. There are a wide variety of different people that could potentially take the role of Scrum Master, depending on the organisation, and it does not have to sit with the Project Manager role. Rather, the Scrum Master title should sit with the person who can do the best job of it. The following explains why the Project Manager is typically not a Scrum Master.

Different Skillsets and Activities

By the nature of the work that Project Managers and Scrum Masters do, the two are not particularly closely aligned, even if it seems at first glance that they are. Managing a project is not the same as being a Scrum Master. Scrum Masters have the role of mentoring, teaching, coaching and facilitating, while the role of the Project Manager is to ensure that the project runs to time and budget. This means that the Scrum Master relies on more of the so-called “soft skills” involved with helping people to move forward, while the Project Manager takes a more methodical, and arguably more of a “hard skills” approach. While both roles have an interest in ensuring a high level of team performance and driving efficiency within the team, the ways in which they go about this are very different. The Scrum Master facilitates and coaches, while the Project Manager assesses risk and manages issues and conflicts. 
Looking closer at what Project Managers and Scrum Masters do in terms of activities, differences can be seen here too. Project Managers manage projects, while the role of the Scrum Master is to is to make sure the rules of the Scrum are followed and that the Scrum Framework is adhered to. Project Managers work across all areas of the project spectrum, while Scrum Masters will largely only focus on the three areas of scope management, quality management and resource management. The Project Manager can commonly be responsible for a very large team, while Scrum Masters work within scrum teams which can be quite a lot smaller. Project Managers also plan regular project meetings as needed, but the Scrum Master will hold a meeting every day for the scrum. Even the emphasis of the work is different, since Project Managers schedule and plan, and narrow in on costs, while Scrum Masters are concerned with the value of the product. Importantly, Project Managers can serve in any industry, delivering projects. However, Scrum Masters only work in the IT industry, or similar related field. As can be seen therefore, there are both subtle and not-so-subtle differences between the skills and activities of Project Managers and Scrum Masters. 
Advertisement
[widget id=”custom_html-68″]

The Issue of Control

Ultimately, the Project Manager has a role that is focused on control. Project Managers are responsible for project costs, time spent, scope, quality of the end result, stakeholder management, risk and more. If the Project Manager is unsuccessful, they are accountable for this, and they will usually be blamed for issues. This means that the role of the Project Manager has to be based on control. This is achieved through each of the different stages of the project, such as its initiation, planning, design, running, monitoring, change control and even the final evaluation. On the other hand, the Scrum Master does not have an emphasis on control at all. Their role is ensuring everyone understands what their role is in the Scrum, getting rid of impediments, coaching people and ensuring that Scrum events occur. Importantly, they encourage the team to self-organise. This is not the same at all as the level of control that is involved with ensuring that project is managed effectively. 
As a Project Manager, being controlling is a good thing. It means that projects get delivered to time and to budget. But being controlling by nature is hard to change, and Scrum Masters are not controlling. It is very difficult for a person that is used to leading in a command and control style to adopt the very different, softer leadership style of the Scrum Master. 

What I still want my Project Manager to be the Scrum Master?

If, having considered the evidence above, you still believe that your Project Manager is the right person to be the Scrum Master, then there are some important steps you should take. You should review the experience they have working in the Scrum, and additionally provide some Scrum training. Perhaps most critical of all, you should determine if your Project Manager has energy, enthusiasm and interest for putting the Scrum in place. If they do not, then the initiative will be likely to fail, because any effective Scrum needs a great Scrum Master who is interested in and committed to making it work. The good news is, it is possible to learn how to be a great Scrum Master, but you must ensure that the passion to do so is there in the first place for this to succeed.

Summary

As has been seen, despite common misconceptions, the Project Manager is not the Scrum Master. The roles are different and require skillsets and activities that might be considered conflicting in nature. This is perhaps why less than a third of organisations assign the Project Manager to be Scrum Master. This is not to say that your Project Manager cannot be Scrum Master under any circumstances – they can – but the circumstances and level of interest have to be just right to get it to work. 

The Agile Executive – Marriage Made in Heaven Or Just Staying For The Kids?

Written by Paul Oppong on . Posted in Articles. 7 Comments on The Agile Executive – Marriage Made in Heaven Or Just Staying For The Kids?

Being an agile executive is not as easy as it might look at first to some.

Working in an agile environment challenges some leaders immensely, as the way of operating is quite different than may have been experienced in the past. Some executives relish in it; others find it harder. This means that in some cases for the agile executive it can be a marriage made in heaven, while in other cases it can feel like “just staying for the kids”. However, agile is the way forward for many organisations, and the agile executive is an essential component of the overall agile team, so it is best to work towards making this a marriage that everyone wants to be in. Let us have a look at the difficulties that new agile executives have in adjusting, and the value that they can add if they approach agile effectively.

When the Executive is an Impediment to Agile

When I have visited organisations to consult on agile, I have observed that the agile executive may often feel that he/she does not have much of a role to play in agile. This is inaccurate, and the agile executive most certainly should be involved. Just because people are empowered within teams does not mean that the executive can sit back and put their feet up. Stepping back too much can mean that the project does not have the support it needs throughout the organisation. It can also mean that the culture of the company is not properly adjusted in the way that it needs to be for agile to work effectively.

Another challenge with some executives is not adjusting well to feedback. An important aspect of agile, is the sharing of feedback, which team members and managers need to feel able to do. This sometimes means that people will “manage upward”, providing feedback to executives. For some, this may feel rather uncomfortable. However, if others are fearful of the repercussions of offering feedback, or feel that there is no point because it simply will not be heard, this is a problem. The agile executive needs to be able to open up and let that feedback in.

For a newbie agile executive who is used to a command and control management style, learning the new ways of agile is likely to pose some challenges. It will may feel like a considerable adjustment, to move away from the old ways of doing things. Traditional managers may find themselves wanting to step in too much, or to try and swing project management back to more of a waterfall approach where they felt more in control of what was going on. For these managers, agile may feel as if the marriage is “just staying for the kids”. Yet there are plenty of opportunities to make this a marriage made in heaven, by changing how things are done, and this may lead to the executive enjoying a more rewarding role overall.

Advertisement
[widget id=”custom_html-68″]

When is the Agile Executive Adding Value?

Agile executives have a critical role to play in the agile environment. First and foremost they need to drive transformational change throughout the organisation, so that everyone adapts to the new “way we do things around here.” There has to be cultural change to achieve this, and it must start at the top, with the executive. If the agile executive talks the talk but does not walk the walk, problems will ensue, because people tend to follow what others do rather than what they say. Saying what needs to be done and acting in the same way is essential. Importantly, transparency has a core role to play within this, and executives need to embrace this with their own behaviour. Sharing an inspirational vision and setting stretching but achievable goals are also important in this context, so that expectations are clearly set, and people know what they need to work towards.

Building the right culture within the organisation needs to focus on the behaviours that will build software (or other products/services) that will work, rather than having too much bureaucracy around project management. There needs to be less of a focus on the rigid following of processes, and rather, an emphasis on delivering a product that the customer can look at and feedback on as soon as possible. This gives the organisation the best chance of delivering satisfaction to the customer in the longer run, and less chance of the product not working in the way the customer intended at a stage that is very late in the development process.

The agile leader also has a key role in sponsorship of the agile activities. This should not be underestimated as it provides support for the agile project within the organisation. The agile executive can be a facilitator in ensuring that teams work together effectively, for example. By focusing on the big picture rather than the minute details, the executive can help to ensure that high level obstacles to the project are broken down. Another key activity is making sure that resources can be made available as needed so the project does not get impeded. These kinds of activities can smooth the project along its way. There is also an element of coaching involved to help the team members and leaders achieve their goals on the agile project. These are all important ways in which the agile executive could and should work to ensure they drive a marriage made in heaven.

Summary

Executives have an essential role to play in agile, which is often underestimated. They need to be transparent and champion the agile cause. They also have to support the agile team and managers so that the project can be executed successfully. Relying on a traditional command and control style will not work in the agile environment, and nor will doing nothing. Executives that want a smoother transformation to agile will step up and lead the way by example, showing employees what they expect of them through their own behaviour. This type of leadership will help ensure the agile transformation the greatest possible chance of success.

M.A.S.S.I.V.E. Projects for sustainable development

Written by Massimo Longo on . Posted in Articles. 2 Comments on M.A.S.S.I.V.E. Projects for sustainable development

The current period the world is living in relation to economic, social, environmental aspects, puts people in front of important decisions.

Floods, tyfoons, hurricanes and global warming urge us to do something. The question is ‘what can we do?’.

High-scale economies, but also day-to-day issues put us in front of unconventional and urgent decisions. If we do not have the courage to take brave decisions the ‘safe operating space for humanity’, defined as the ‘planet boundaries’ will be broken and humanity will have to face a ‘irreversible and abrupt environmental change’.

After II World War, we experienced for many years an incredible economic growth. During this growth, our cities and nations have changed dramatically.

From a rural based society, we quickly became an urban-based society. Economic growth started in 1700 in England and expanded rapidly in many other countries.

Convergence in economy has also allowed reducing the gap between rich and poor countries.

The growth we have experienced worldwide was the fruit of governance strategies based only on reaching well-defined economic objectives. Until now, this is what has driven high strategic programmes and portfolios as well as small projects.

In the area of project management, the overall planning, execution, monitoring, closure of every project has still been driven by its ‘inner’ objectives without considering the wide ‘outer’ impacts the deliverables of the project will produce.

The ‘Management by Objective’ culture has developed management frameworks in which the goals are that we have to produce a lot and in the most effective way.

Nowadays executives are called to manage strategic programmes and projects considering also the ‘sustainability’ concept.

Sustainable development needs a holistic view on what the services or goods delivered by a project need to provide.

The main four areas of success a sustainable project should always consider are

  1. Economic
  2. Social
  3. Environmental
  4. Political

The link among these areas is not direct. We need to go through different levels of detailed analysis of the project requirements to shape exactly what the project needs to deliver and successfully bring value in each of the four areas.

Requirements that have to collect from all stakeholders impacted by the projects.

Project managers are mainly asked to consider cost, time, quality and scope when governing a project. It rarely happens that they are asked to consider sustainability as a critical project objective.

If sustainability is mentioned in the field of in project management, it is always interpreted as the ability of the project to deliver successfully the project only from an economical and financial point of view.

Nowadays it is important to have a much wider view of sustainability.

Not only having the goals projects as cost, quality, scope, time.

It is important that projects are not only oriented to the ‘inner’ benefits of the project, but also to the benefits that it produces towards the community that will interact with its deliverables. Those benefits in order to be sustainable will need to be positively measured over a long-term period.

Advertisement
[widget id=”custom_html-68″]

Projects must answer those needs as well!

In addition, sustainability should be seen as respectful of the environment and respectful of the social balance of the community it will influence. Thus, it is important to give high importance to the stakeholder management aspects of project management if we want to deliver a sustainable project.

I recall different cases from my project management experience in the filed of civil engineering. Projects were focused only on the ‘inner’ deliverable and not to the ‘outer’ sustainable impacts it would have.

I managed the construction of building where green areas were destroyed. A better focus on sustainability could have delivered the buildings as well as basins for collecting rainwater and playgrounds for children.

In the areas where we are experiencing climate change, it is important to consider areas free of concrete for the collection of rainwater and then usage for other purposes.

Our projects must be not only oriented to the deliverable itself but also to sustainability.

Company strategic plans must embrace the concept of sustainability. Sustainability has to be considered during strategic planning. Risk Management is the right project management knowledge area that should be used to pre-empt problems that can jeopardize the success of long-term sustainable objectives.

This of course has to go along with a well-defined list of economical, financial, environmental and social goals.

The management have to re-think about the impact of the projects in the context where it is and take specific actions.

With all this in mind projects need to be managed and sponsored by positive executives that will not only look at the business objectives to achieve. These projects will need managers that are focused towards the overall benefits. Benefits that will be reflected in every single piece of the puzzle of the end result.

I tried to find a way to summarize the needs that a project requirement must provide in the M.A.S.S.I.V.E. acronym. I believe this can properly define a sustainable project.

M = Massive

A = Ackowledge

S = Social

S = Sustainable

I = Inclusive

V = Valuable

E = Extensive

M.A.S.S.I.V.E. projects must have the following seven attributes.

Massive – They must have strong and long-term beneficial impacts from a sustainable point of view.

Nowadays we always have little time to manage all the issues linked to sustainability. Therefore, every choice we make now must have long-term massive impacts.

Acknowledge – There is need of full acknowledgement at all levels that a new thinking of the stakeholder term is needed. Project plans should reflect it.

Project stakeholders need to have full visibility of the project goals from the initial stages of the project. Social communities impacted by the project must be listened and all their requirements must be analysed. There is need also to keep them informed and receive their feedback during the whole project lifecycle.

Social – Projects need to be social. They have to be thought as an advantage for the community at all levels. It has to bring benefits to the local communities as well as to a wide variety of people with higher degree of influence.

Sustainable – as we have been going through this article.

Inclusive – Projects need to be inclusive. Every person influenced by the project has to be provided with the right fare amount of benefits. There must be only winners. No losers.

Valuable – The impact of sustainable project must be measurable in order to deliver sustainable value.

Extensive – Scope of sustainable projects must be extensive. They need to cover needs in the Economic, Social, Environmental, Political areas. From a time point of view, they have to cover long-term as well as short-term needs.

Modern management should make sure that every single project is a M.A.S.S.I.V.E. project.

M.A.S.S.I.V.E. projects will contribute towards a sustainable economy. Benefits will also be experienced in the economic, social, environmental and political areas that today are facing a multitude of challenges. From an ethical and social point of view project managers are called to deliver M.A.S.S.I.V.E. projects.

Communication in a Project

Written by Scot Witt on . Posted in Articles. 1 Comment on Communication in a Project

So, I’m waiting on hold, watching cut little gifs scribbling away and writing an email and writing this.

My head is exploding. I’ve run major market radio station newsrooms (back when there was radio news). My mom once saw me typing up a news\story, listening as a three-alarm fire became a four-alarm fire, assigning reporters to head out and get something while training an intern how to splice tape. Her head exploded.

I found that switching over to tech writing and ultimately to Business Analysis made for less head explosions and migraines. I can control information in a civilized manner.

IM, Voice (phone or meeting nodes), email and face-to-face are all legitimate means of communication. It’s how and when to use them. Fancy that!

Email

Will this take more than three short paragraphs? (Note: I mean “email” passwords- up to three 15-word sentences)
  • If yes, write an email
  • If not, grab the phone

Email

 

Has this email thread resulted in more than two go-rounds?

Grab the phone or the virtual IM/Meeting app

Phone

Do I need to talk to more than one person?
  • If yes, invite the principals to a meeting:

o     If a decision maker doesn’t make the meeting, close it and reschedule

o     If there’s no agenda, cancel the meeting

·      If no, Grab the phone or the virtual IM/Meeting app

Instant Messaging (IM)

Is this or has this communication taken more than 2 back and forth IMs?

Grab the phone or the virtual IM/Meeting app

Help?

Do I still appear to be wasting time because I don’t understand (this is rare for me)?
  • Use video meeting
  • Use Screen sharing
  • Use a whiteboard app
  • IM the boss and vent
Advertisement
[widget id=”custom_html-68″]

There are rationales for my rules:

Agile processes want discussion as the base means of team communication. Seriously, it works and works well. Trust me, I’m a BA working in a collaboration team.

If I have more than one thought to discuss, an email will just confuse and irritate my reader, ergo (I love that word, ergo), we need a discussion.

If I send such an email, my reader will skim it and respond to the first paragraph (graph as us writers call them)

Then you won’t be called names that mean teammates you can’t understand your emails.

This is not what you want while coaching a SME (Subject Matter Expert) on an epic.

For IM, more than two messages get me into unproductive time- that I can be using for something else. Stop the madness and talk to your correspondent

If there’s no deciders, why are we meeting? For the Danish?

If there’s no agenda, how can I prepare for the meeting? C’mon, I can’t read your mind!

So, you can stop the madness. My rules may not work for you, but it’s a start.

Protect your head. We BAs sort of need them for kick-off meetings and face-to-face SME (Subject Matter Experts) meetings for requirements and rough user stories.

Are you practicing Agile or mini-waterfalls?

Written by Paul Oppong on . Posted in Articles. 6 Comments on Are you practicing Agile or mini-waterfalls?

When I go into organisations that claim they are using agile, I sometimes see mini waterfalls instead.

This is not altogether surprising when you consider that almost 90% of organisations report that their company works on projects in an agile manner – there are bound to be some misinterpretations. However, agile is a very specific approach to project management, and one that mini waterfalls cannot form a part of. Let us look at the differences between the waterfall and the agile approach, and warning signs of mini waterfalls developing, to understand what can be done to rectify this problem.

What is Waterfall?

The waterfall approach is named as such, because the project management process represents the flow of a waterfall through the various stages of activities. At the top of the waterfall is the requirements gathering stage, followed by design, development, integration, then testing, training and roll out. The approach is considered highly structured and managed, and it does work well for certain types of projects – in particular those that are unlikely to have evolving requirements and where there is certainty about the end goal.

In a waterfall development approach, all of the analysis and requirement building is done up front. This is followed by a stage where all the design is done. Then the development is all done in one go. Later on there is a stage when all of the testing is done.

What is Agile?

Agile differs significantly from the waterfall approach to project management. It evolved in the face of continuous business change. It is helpful for when there are fewer certainties and when business requirements may adapt over time, or may not be well known, or both. When projects are run in an agile manner, they are iterative. Each stage is run incrementally and there is a lot of collaboration between people in varied teams.

When project work is operating in an agile manner, all the different work streams happen at the same time and they all conclude at the same time. Analysis, design, coding and testing all operate concurrently, and they all finish together at the end of the sprint. This is quite distinct from taking a waterfall type of solution to project management. Another important difference is that in agile, teams are self-organising. This does not occur in the waterfall project management approach.

Advertisement
[widget id=”custom_html-68″]

Mini Waterfall Red Flags

It is all too common an error that agile teams start operating in the manner of mini waterfalls and continue calling it “agile”. Fortunately, there are warning signs that teams can look out for to avoid this scenario happening. One trap that teams may often fall into is having the team work in silos. This is advantageous from the perspective of some developers as they have much more control over what they are doing). However, it does lead to mini waterfalls. This is because while it may seem efficient, it results in a longer wait for testing results because testing starts happening after development.

Another key warning sign is when small aspects of the project (user stories) start becoming more than just short placeholders. When user stories start having their own specification documents, this is not agile. Everything starts getting documented out for the user story, and the development is no longer iterative. Again, the testers then start working one stage behind the developers and not in the same iteration. What happens is, an iterative waterfall approach starts to build up – with each user story becoming a mini waterfall project in its own right. However, this is not what it means to be agile.

Other mini waterfall warning signs include the situation where only certain parts of agile seem to actually be going on in the project. An example scenario might be that the team is self-organising and collaborating across disciplines, but that design has evolved to start happening at the beginning of the sprint and testing at the end. The fact that the team is self-organising and collaborative may throw people off realising that this is a mini waterfall in disguise, but that is what it is.

While mini waterfalls may feel comfortable for those working within them, the main problem with them is that the user will not get what they want. Not only that, but the timeline for project delivery starts to drag out. This will be dissatisfying for the customer.

True Agile Project Management

True agile project management is a way of operating that is embraced throughout the organisation. Simply telling teams they are going to start working in an agile way, but not having leadership on board with this, will not lead to agile working. Traditional project management needs to be set aside, and the scrum must be used.

In true agile project management, planning does not occur upfront the way it does in a waterfall system. As soon as planning and design starts happening at the outset again, the team are working in a waterfall, albeit often a mini one. Tight and short feedback loops are required for agile to be effective. This helps the project team to actually build a product that will meet what the user/customer actually wanted, because users can give their thoughts much earlier during user stories. It is this process of continuous feedback that helps the project more quickly evolve into an end product that will meet the user/customer’s needs.

To move back from mini waterfalls to agile development, stop looking at the development in phases of requirement production, design, development and test. Instead, go back to considering one aspect of what the user wants, developing a small part of this and checking in to see if it is right or how it could be better, and then continue building iteratively until the user is satisfied.

Summary

Where agile is not fully embraced through the organisation, it is possible for so-called “agile” teams to revert to the old ways and start developing mini waterfalls within sprints. This is detrimental to the project because it not only extends project timelines, but it means that user feedback is gathered later on, leading to more work to produce something they actually wanted. True agile occurs when all aspects of the project happen at the same time including analysis, design, coding and testing. Ultimately, the aim is to deliver value to the customer as often as possible.