Should we go with agile or waterfall or hybrid is the major decision one should make before getting into detailed planning. There are construction projects which got great benefits by following agile during the engineering phases, which facilitated concurrent engineering by distributed teams. While that is the case with project management strategies / approach, project execution strategies are also equally important. For example, I know a construction project which could meet their tight deadline because they decided to go with pre-fabricated components in the project. Project strategies can also revolve around make or buy decisions, various contracting types, technologies used etc…
While the factors to be considered for developing the project’s strategy / approach are multidimensional , the rest of this article will discuss about the various project management strategies that can be adopted for successful execution of projects.
When to go with predictive or waterfall?
If the scope is very clear (Construction projects)
If the technology is well known
If the engineering discipline do not allow for change
If the contract type is fixed price, fixed duration
When to go with Agile?
If the scope is evolving
If the technology is new to the team
If the engineering discipline allows for change (Information technology, Engineering phase)
When to go with Hybrid?
When the team is moving from Waterfall to Agile
When some phases are ideal for agile and some phases are ideal for waterfall, within the same project some phases can follow agile where as some phases will follow waterfall (predictive) style. For example, in a construction project, the architecture, approvals, engineering, procurement, snags, punch lists are potential candidates for agile where as the actual construction phase will benefit by following predictive approaches.
Even in a predominantly predictive project management approach, adopting some of the agile ceremonies like daily meetings, short term planning, burn down charts etc can improve productivity.
Good project approaches / strategy will play a major role in meeting the timelines within cost with quality.
A Sprint 0 is the name often given to a short effort to create a vision and a rough product backlog which allows creating an estimation of a product release. Some organizations adopt the practice of having a Sprint 0 before the project actually kicks off for real. It is the foundation and most critical Sprint for any project. In my experience, it is well suited for the organizations who are in process of transitioning from Waterfall to Agile.
Sprint 0 is usually claimed as necessary because there are things that need to be done before a Scrum project can start. During Sprint 0, the Scrum team might be assembled, product backlog can be populated and any technical issues like hardware, software, architecture, infrastructure, procurement, resource and collocation issues can be sorted out.
The goal of Sprint 0 is “being ready and able to deliver business value that is usable and potentially releasable” through discovery process. It isn’t about planning the future items in detail but should be about setting the vision, creating an initial backlog to meet that vision and getting initial estimates against it.
Possible SPRINT 0 Deliverable:
Activities listed below will make the team ready for the upcoming Sprints and mainly Sprint 1 &2. This is just a checklist with all the possible items to start with in Sprint 0, which could be between 2-6 weeks, depending on the Project size. Nonetheless, every environment is different and may require specific actions tailored in the best way to address the specific needs of that environment.
Product Backlog/Requirement:
Product owner, business analyst and technical architect should closely work to prepare the Product Backlog and create the release plan so that team can visualize the PO’s vision from the product perspective.
Should review and analyze User Stories in collaboration with PO’s and relevant stakeholders.
Should prepare a Product Backlog (or decision on Definition of Done) with the Acceptance Criteria for each User Story.
Should identify and document any non-functional requirements (authentication/security, performance, 508 requirements, scalability, etc.).
Should prepare for Sprint Planning, prioritize and freeze requirements at least for sprint 1 and 2.
Infrastructure Readiness:
Without the infrastructure, team won’t be able to progress on anything. There is a high dependency on following items, and it should be worked out with the infra stakeholder:
Network Requirements
Environments readiness; to start with team at least need Dev and Test and later Pre-Prod (UAT) and Prod environments.
System readiness with all the software installed
Logistic requirements like phone, video conference etc.
All the tools up and running
Environment Specification:
Identify various tools to be used in the project, such as
Front-end Tool
Back-end Tool
Database Tool
Data Migration Tool
508 Testing Compliance Tool
Team Readiness:
Create a resource plan or team structure:
How many full time and shared resources are required with their allocations
Identify skill sets needed for the required resources
Interview and hire resources (if required)
Create team On-boarding activities and tasks
Each resource should have all the required software
Each resource should have accounts and access to the required systems
Training:
Training will make team ready for the development/testing and is critical to project success. Training on following maybe be recorded for the future use/training of new associates:
Domain
Technical
Architecture
Development Framework and Process
Testing Framework and Process
Tools
Design/Architecture:
Initial draft of high-level architecture management plan that talks about the technical architecture of the future product from the technical architect.
Project Release Roadmap:
Work with PO’s on Product Vision and prepare Release Plan with following information:
Number of Sprints
Sprint Start and End dates
Epic or functionality planned to be covered in each Sprint
Project Management Plan (High Level):
Identify Project In-Scope and Out-of-Scope
Cost Estimation: Along with Project Cost, determine other costs (if any), such as My Access Cost, Certificates Cost, Environment Cost, Security Assessment / Authorization Cost, etc.
Post pandemic, the team building challenges are different due to the fact that we all learned to work differently. Most of the organizations have flexible working policies which is a blend of work from home and work from office. Organizations have started leveraging contract workers or gig workers to accomplish their goals faster and more cost effectively. All these poses the need for innovation in the team building concepts. Tuckman ladder helps us to understand the team formation stages in a structured manner and helps to develop appropriate strategies for team development.
Tuckman ladder comprises of;
Forming Stage
Forming stage represents the stage in which the team members gets into the team for the first time. In projects, team formation and team building starts from the initiation phase and continues till the completion of execution phase. Since new team members are coming from different cultural and project backgrounds, it is important to establish the ground rules. The project vision, project charter and the team charter are of great help during this stage. These artifacts helps to lay the foundation for effective team building and team work. During the forming state of the team, the manager or leader’s primary objective must be to make the team comfortable. It is a great opportunity to leverage on servant leadership. You as a manager or leader helps the team to settle down quickly. During the forming stage, the manager or leader must wear the hat of a facilitator and counselor.
Storming Stage
Since the team members are coming from different cultural backgrounds, immediately after the forming stage, one can expect a storming stage. During the storming stage, the team members try to establish themselves resulting in power struggles. This is very normal. During the storming stage, the manager or the leader must monitor and control dysfunctional behaviors and must wear the hat of a moderator. One should play the role of a moderator here. Establishing ground rules for effective teaming helps to manage the storming stage effectively.
Norming Stage
Once the team passes through the forming and storming stages successfully, then they get into the ‘Norming Stage. During the norming stage, the team members understands their roles, responsibilities and the acceptable norms within the team (ground rules) and the goals to be accomplished very clearly. During the norming stage the manager or leader must play the role of a facilitator. The self organizing team concepts will help a lot for high performance team building during this stage.
Performing Stage
At the end of successful forming, storming and norming stages, the team arrives at the performing stage. They are ready to start the real work in a productive manner. Very often, this is the most difficult stage for a leader or manager. You picked up the team members, and transformed them into a high performance team with appropriate team building exercises. All of a sudden, they started performing well, even without your guidance. You become a kind of redundant there. This is the time one must put in extra effort in not to interfere with the team unnecessarily and interrupt their work.
Adjourning Stage
As we all know every game has a final match and after the hour of glory, the team will get adjourned. This is very true for projects as well, because projects are temporary in nature. As a manager or leader this stage is very crucial and it is very important to protect the good will generated while working together. This aspect becomes more important during these post covid work culture or the post pandemic work culture as more and more project teams are relying on contract workers or the gig workers more and more. If you are able to maintain the good will even after the project closure, it will become easier to avail great talents quickly in the future projects as well.
If teams work together for longer times as in manufacturing, all these stages will automatically happen over a period of time. In projects with tighter deadlines one do not have that kind a luxury. When majority of the teams are in the performing stage, if we add new team members then it can disrupt the teaming again. This is the reason why projects get delayed further when more members are added to a late project.
The manager or the leader must be able to drive the team through these stages very quickly in order to be productive fast. This is where the charisma and the creativity of the leaders and managers makes a big difference. We all play the game well to win, if we are playing against a common enemy. If the leader can identify and project the common enemy in the form of an opportunity or risk, half the job is done.
The fundamental principle of the situational leadership model is that there is no single “best” style of leadership. Project teams or project stakeholders belong to various experience levels and attitudes. Hence, there is no single style managers and leaders can adopt that will be effective across team members. These models helps to tailor one’s leadership style to cater to the needs of the individuals and teams.
One cannot have a one for all kind of leadership style for all team members in the team as they fall on to the various levels of Maslow’s hierarchy of needs. Based on their capability and maturity the leader has to change his leadership style. The basic principle of situational leadership is this. Based on the maturity level and the capability of the team members, the leader resorts to any one of the following styles of;
Telling or Directing
Selling or Coaching
Participating or Supporting
Delegating
This is a model created by Paul Hersey and Ken Blanchard.
Situational Leadership emerged as one of a related group of two-factor theories of leadership.
These theories are based on two main variables of task and relationship.
Effective leadership is task-relevant, and the most successful leaders are those who adapt their leadership style. They adapt their leadership style to the performance readiness (ability and willingness) of the individual or group they are attempting to lead or influence.
In this conversation Dr. Stefanie shares about her work, experiences, insights her books and Psychology4Agility with Abrachan Pudussery, Director at the Project Management Research Institute and Wrench Academy
Projects are neither completely predictive nor agile any more. They are hybrid in nature. That is the reality. So far, project management had two distinct streams, the Adaptive (Agile) and the Predictive (traditional). The purists believed in any one of the streams. They are busy justifying their views. Now, the industry has changed. Irrespective of the type of work, majority are working from home and that demands adoption of both agile and predictive best practices in the day to day work. That trend is here to stay. The Project Management Institute (PMI) was the front runner in this by including Agile in the Project Management Body of Knowledge four years back. This was followed by the new Scrum Guide 2021, which has become more generic. Scrum is the most popular among the Agile frameworks because of it’s adaptability to various disciplines of project management. According to Ken Schwaber and Jeff Sutherland, the founders of Scrum, they made the Scrum Guide 2021 more generic so that it becomes easier for all types of projects to adopt it. The trend is very clear. The boundaries between agile and predictive is vanishing, if not yet vanished.
Unfortunately, when I visited the Agile Manifesto Page, it still reads as ‘Agile manifesto for developing software’. From an EPC project practitioner’s perspective this is very demotivating. The engineering phases of any EPC project is a good candidate for agile adoption, but still the agile manifesto is maintained exclusively for software development. Like every other EPC person wanting to leverage agile I feel stranded and unsupported.
These two factors leads to the need for the Hybrid Project Management Manifesto;
The Hybrid Project Management Manifesto
As practitioners of Professional Project Management, We believe that;All projects are unique in nature,
Tailoring the processes, by incorporating the best from every project management framework is better for project success, than relying on any single framework.
For this;We will continuously update our knowledge and skills without any bias to any one particular project management framework,
We will always maintain an independent open view in all our actionsto ensure project success.
I am very optimistic about this, because there are many who opposes this view as well as those support this view. It is high time we stopped saying ‘Agile Vs Waterfall’, instead we must learn to say ‘Agile and Waterfall’ and for that the apt word is 'Hybrid'. Thanks to the traditionalists who contributed us with great tools like the critical path analysis, earned value management and the likes. These are time tested concepts which is here to stay. The agile practices like time boxing, the short term planning, daily team meetings, self organizing teams can be effectively used within phases of every project. That will result in a healthy co-existence. Think of burn down charts co-existing with earned value management and helping to protect the earned value. Nothing is good or bad, the project context determines it’s suitability.
Hope Hybrid manifesto will help us to focus on the project’s success than worrying about the technicalities of frameworks.
The Hybrid manifesto is evolving. You can help with your suggestions.
