Software Projects fail, mostly in the waterfall model. Period, The Project Manager is blamed at most times. One of the key effectiveness in the failure is the tool-centric process or Process-centric tools. The time taken to effectively learn a process, its entire life cycle and how it could be used is missed drastically by most project managers, even if they are qualified and certified. Agile practices are to be tried to roll to perfection.
Replacing a Project Manager in the middle of the project with another Project Manager is a kill to the project. These risks are never taken and if taken by chance, a clear knowledge transfer (KT) that runs to months are formed by organizations. The question points to why this is a kill? Is the project manager the driver of the project? No. He is the driver of the process. This is missed from the organization point of view. The project changes or fails due to the unclear understanding or misunderstanding by the stakeholders (en all).
These points to majority of the work that is done below:
- Awarding Client relationship and the movement to a new manager is a threat.
- Project documents collected and reviewed need to be agreed and reorganized.
- Direct Reports have a psychological issue.
- The threat of the new manager taking command and new directions along with the results of the direction are threats.
- Time to settle down in the new arena is a dead time.
- Above all, the organizations power to substitute a time centric manager for an on-going project is critical and a threat.
What if the project is in an agile model with a Scrum Master (SM) at work? These above threats are never felt in the first place. The power of the designation is as simple as a practicing Scrum Master. (above all).
I have the art practiced in moving SM from one project to another in different phases of Scrum. I have seen the effectiveness of how a master can work with his inputs to yield super deliverables, “the threat of moving, replacing the efficient Scrum Master is not a threat but the ability the position gives you to handle your projects”.
The Scrum Master is not a project Manager but a facilitator, Coach, mentor and a practice guide. In transforming organizations and transformations projects, The SM is the 361 degree key. (361 degree is a level above 360 as 360 is also 0 at a point in time).
Why do people transform or change the way they deliver software projects?
I have seen projects that span years with their vision statement changing once in year,
- Changes to the organization hierarchy happen in a pizza move.
- Alignment to the Business Idea or Value,
- Core Strategic makeover,
- Technology subversion
- Logistical transformation
- Cultural dependencies
- Compliance guarantee. &
- Requirement for a project all keep changing all the time, just to reflect what the business ultimately wants to do.
Improvise trends, use newer, safer technologies and work with unanticipated change and anticipated risk has become more of a sign language. Leaders in the organization think wide with the current role or fade it away with their juniors who are informed leaders at most times and just plug and play the game called change.
Today Leaders showcase “Change” as a centric, dynamic and objective oriented approach with a strategy build over in multiple loops. Yet they fail to deliver what is expected at the end of the deliverable. As I have seen it, the failure itself brings the need for the change. Then there is another new game to start with.
End of the deliverable is what needs to be changed. The deliverable should be progressive, measured and on the move of inspect and adapt approach. In-fact other than the software development industry (as a whole), most business does a unknown mistake and learns from it, recovers from it and draw a tar road to allow people to follow and miss the holes. But here, in the software development industry, there are proven ways to fall and ultimately points to the managers who hold the failure. The failure is known for sure over the period of changing. The only reason is because the organization focus is on the change and not on the fall back of the change. The sure reason why Scrum is effective today is for the same reason.
Today, the software industry needs the change to prove the platform can be solid to multiply its branches above than re-engineering the platform, again and again. The computing industry is starving with known failures from the waterfall model and each organization has in one way or the other seen, felt and failed multiple times.
Change itself should be digested as a process than looking at it as a new paradigm in shift. The core of change is static, if a change is envisioned to a business model of shifting things or a strategic change to pull over sheets of vertical and horizontal moves, it still doesn’t change the core of applying process to a set of defined way of working. This can be termed as Change Innovation. Where change is continuous and the methods or approach towards them are new.
The guy who is ready for the change, ready to take the ball and being prepared to play the Rubix from any point is a Scrum Master. He understand where he stands now, what he needs to do, perform a change when required and go back to the place he belongs.
From (Do Better Scrum – Peter Hundermark)
The responsibilities of the SM role are:
- Empowering and shepherding the team.
- Removing impediments
- Keeping the process moving
- Socialising Scrum to the greater organization.
Recruiting the Scrum Master
Its one of the hard challenges to find a really qualified Project Manager to manage a similar, scaled project. Its quiet easy to find a Scrum Master.
While recruiting a Scrum Mater, I have found and used the following:
- Is the master trained?
- Is the master certified or planned for a certification?
- Can he present what lessons he learned while practicing scrum?
- Can he start a new scrum team and follow process?
- Is he detailed oriented?
- Does he have the courage to speak what the truth is?
- Ways that he performs a Sprint Daily Standup?
- Ways he helps / coaches to clear away impediments
- Solutions that he can bring in a scenario.
- His skills in introspecting and retrospecting.
- Can he follow process? ( I don’t want a innovator here)
- Finally, what is his personal interest in growing up?
Forming a new Organization Change (Role of the SM)
The framework which is the body of Scrum should be well defined by a SM. He should be able to adapt himself best as a coach, to a mentor and facilitator when needed.
As a coach, I would admire the capabilities of a SM to teach the basic principles. Stick with time-boxed practices, detail results of what was expected and if it was achieved and further to anticipate and work with risks that he may come across in the future.
Even though risk planning is not a part of the game and we require it on daily basis to understand while working with impediments.
As a mentor, I would like him to scale from a manager to boss, to make sure peers follow procedure, understand and create a cross functional team, work with multi talents and have a clear collaboration ticket while dealing with resources.
There are known risks that I have seen over the past that the mentoring changes to bossing and practise rude rules to follow procedures. I would like to handle them with maturity and politely as possible and when required to be real rude, bring in an essence of the act wouldn’t be willing.
While in the process of creating a self organized culture, we make several mistakes, one of the common one is to forget what the individual tries to achieve as best as it can be. “To code, To test, To deliver”. Scrum is just a walnut shield. The core being nuts cannot be avoided. We need to be matured enough to thing deliver is important in the framework of scrum in regular intervals and we need to keep the space in between to make sure the resource understand the need to deliver in the framework. Mostly of what I’ve seen is the framework being important than the deliverable.
As a facilitator, I would like my SM to be thinking before time, being an active participant in the Sprint Planning I & II, Sprint Review and Retrospect and identify, inspect and adapt principles at all times. He should be a core replacement or sometimes fully responsible for the changes in the Sprint backlog, release planning and burn downs and up charts.
Lastly, I would love him on the attitude he has with the framework, not as an innovator but to ideate process in bringing peers to communicate, collaborate and co-ordinate clearly.
A New Scrum Team
A perfect place, to perform. New organizations or communities of projects that are formed are the perfect place to start a scrum or transform to scrum. Even if the requirements are frozen, estimated and risks analyzed, Scrum gives you the opportunity to gel well.
The Appointed SM, should be a team player to understand what he needs to deliver. Be aligned with the process and make sure he is available at all time with the team to remove impediments.
- His active role would be to train team members on ground rules of scrum.
- Aid with Stories, Epic’s & Theme creations.
- Planning mechanism to size and create backlogs.
- Spread the value of volunteering, the freedom Scrum gives to perfect what a resource could do all by himself to learn and grow.
- Practice Daily standups and stick to the time.
- Make sure the team members efficiently create a self sustained organization of solid deliverable’s.
- Help team members in show casing what has been completed in Sprint Review and be a proactive member, inspecting and adopting in Retrospect.
Hand in Hand with the Product Owner
Scrum Master and Product Owner should know each other well and have a good rapport. It is extremely essential to think our product owner is our internal customer. He creates and maintains the Product Backlog with the help of the team. The SM should keep the Product Owner informed at all times, including the Sprint Planning 1 (and if needed) Sprint Planning 2. The major stakeholder’s vision should be digested and the deliverable showcased properly in Sprint Review and Retrospect.
In our office, we have a dashboard in a meeting room where the artifacts are placed at all times. (Prior to use of the customized software program). All our meetings happen in the same room and outside the room we all share common desks other than the Product Owner. PO doesn’t share desks and he is seated at the same floor in corners of the building.
As we work in an Agile Platform, our bills are totally different from waterfall model billings. Each day the Scrum Master takes an extra effort to work down the ‘Resource Allocation Planned vs. Executed’ with the help of burn down charts and actual hours indicated by the resource. We have principled that our offices in India close by 5:30 for all development and testing teams and 15 minutes of time is taken out to fill the hour sheet for that date.
This information is collated and global billing sheets are updated each day, till the Sprint review to create the invoice for the Sprint by the practicing SM. Our clients are well aware of day to day chargeback details as they are available on the Sharepoint that our clients can access.
Sprint, Release Planning 1 & 2
One of the most important activity in Scrum that helps the entire team to focus on risks, estimation, tasks breakdown and incremental deliverables.
SM should invite the Product Owner and make sure his participation is valued as he guides the team in the right direction. SM should also bring in required stakeholders needed to guide the team in understanding requirements.
With my experience, I strongly recommend to have this meeting well planned for a whole day to focus on the requirement and baseline it.
Velocity is planned in the phase, updated on the Sprint Review for the next Sprint.
Daily Scrum Meeting:
The primary host of the meeting is the Scrum Master. A single meeting would be able to show us how the scrum framework is followed in the project. The SM, learns, inspects, adapts and guides the entire team on the next move to win the game.
Few activities in the daily scrum apart from the 3 questions:
- Make sure each resource has specific task’s to do.
- The task’s are estimated, sized and prioritized (not ordered).
- The tasks are in the order of execution or helps to delivery the package to the current Sprint.
- Make a note of repeated events and by repeated team members on impediments.
- Track and resolve the impediments list on priority (urgency).
- Track team members idle time and leave details.
Once the meeting is over, The SM should start capturing values in the Risk Register, Impediments list, Cross check the product Burn down chart and finally inform the Product Owner if there are specific events that needs to be discussed. (Discussions doesn’t happen on daily basis after the Daily Stand-Up, Its only when events or incidents have happened).
The most crucial part of a Scrum is the Review. In our organization, we have dedicated Quality & Planning team (Q&P) who are a part of each Sprint Review. (They are previously involved in Sprint Planning too). We have divided our Sprint Review into 2 parts.
SR Part 1
Here each resource provides statistics on the individual velocity, no of user stories completed and done. This is compared with the Resource allocation, Task allocation, Product Breakdown chart, Testing related details and Quality Metrics used.
We have brought in Functional Point (FP) Estimation along with PP to estimate sizes for our user stories. The stats are again validated on the SR1.
No demo is showcased here.
SR Part 2
Each resource showcases a demo in an ordered method of their inputs and output and what process has been worked. This confirms with the agreed Done statement of the deliverable which is signed by the SM.
No stats are discussed here.
Our SR’s gives us a clear indication of our agreed ‘Done’ statement to deliver the results for the Sprint. It specifically showcases the “dirt”, both in stats and demos and helps the SM to identify and zero the problem if he has missed it in Daily Stand-Ups and creates a way to rework and adapt an appropriate solution for the sprint.
When the Program / Account / Portfolio manager is involved in a Sprit Review, it helps them to understand how the framework is effectively used or ineffectively individual’s activity and showcases what needs to be done focusing on the solution.
Immediately follows our Sprint Review on the same day or the following day and no activities are done in between these two meetings.
Notes from the SR Part 1 are taken to make any process improvements, quality changes and allows the SM to guide the team.
The meeting is normally closed door. Only the Scrum members including the PO & SM are involved. Here everyone takes a turn to speak what they have done best and what they could have done best. We also take turn to “Start”, “Continue” & “Stop” activities inside the team.
When SM and PO takes turn to introspect, they make sure they spill the dirt outside and make sure the whole Scrum team works for the vision that has been defined. Many times, in my organization this has become a war room, with maturity over a period of time, we understood what needs to be done as a team than to find difference between each other.
The phase plays an important role if there is a Sprint termination during the execution of the sprint.
The SM works with the following artifacts in creating, updating on a regular basis.
- Resource Allocation.
- Resource Utilization.
- Resource Leave Calendar
- Notes (from Sprint Planning, Daily Stand-up, Sprint Review & Retrospect and Process Improvement)
- Sprint, Release, Impediment & Product Backlogs.
- Burn down/up Charts
- Risk Register
- Velocity Chart
- Planning Poker
- Functional Point Estimation Template
- Story Cards
- Process Improvement Template
- Lessons Learnt Template
Texts marked in Italics are not a part of Scrum and followed by our organization.
Tomorrow is just going to be like today as it was just like yesterday is not the agenda for a Scrum Master. Each day is a challenge, struggle, lot of quality paper work and lot of planning to be “Done” to deliver what is planned.
The day starts with a Daily Standup, if necessary Scrum of Scrum, Updates to the burn downs, updates to the resource allocation, utilization, update to the backlogs and reports to the PO.
Rarely in a case does the Sprint terminate? I have seen close to 6 Scrum sprints being terminated. One of the obvious reasons where I had found 2 cases where the Master was just a project manager to handle things and the team weren’t educated on what needs to be done from their end. The sprint dint last for 3rd cycle and the backlog was still untouched.
In a particular case, the project manager was a SM had no backlog and had all in his mind the Sprint backlog was a set of requirement documents that kept revisions in the version as detailed design documents.
A recent show that I witnessed was in a transformation project, when they wanted to move from a waterfall model to scrum and moved in the coding phase and started up by having a standup for 2 hours each day. The deliverable was really messy as peers dint want to volunteer to work and the named SM had to push the WBS tasks to each.
Whatz Next to Scrum Master
Moving up the ladder is not so easy, Practicing Scrum as a Master is a continuous learning process as each project differs in resources, magnitude and deliverables. The role helps you to look to a project level, growing up or Scrum of Scrum and becoming a professional or a coach should be the target. Most SM practise coaching as a day to day operation and facilitates process to deliver high valued, incremental deliverables. Using this as your key stone, the next move is to certify yourself in CSP and raise the community and the framework as a Coach.
To conclude, I would use (Do Better Scrum – Peter) words that follows as…
he SM role must provide process leadership to the rest of the Scrum Team and to the rest of the organization. Classroom training, such as the Certified SM course, is an insufficient means to gain the required tacit knowledge to master Agile practices and the Scrum framework. The team and the organization need the skills of an experienced practitioner to guide them through the maze of challenges they will inevitably face in transitioning to Agile.