Traits required for a successful Scrum Master

I am sure many of us would agree that getting certified as "Scrum Master" is not that difficult task. 

However, looking at the roles and responsibilities that Scrum Master needs to carry in a typical Agile setup, I must say  wearing Scrum Master's "hat" is something that requires some unique skills and traits.

Following are some personal traits that I think every Scrum Master should possess...

• Collaborative
• Must posses excellent collaboration skills to work with all the stakeholders to work towards the objective.
• Brings together the team and helps in streamlining the process


• Transparent
• Always showcase transparency in all form of communications
• No hidden agenda – what you see is what you get


• Protective
• Must guard team from outside influence that would divert team from the objective
• Scrum Master should posses acute sensitivity towards both team protection and business needs and should maintain healthy balance


• Knowledgeable
• Scrum Master must be very knowledgeable about Agile processes
• Must understand the technical and business issue team needs to address. 
• ScrumMaster need not be tech-savvy or business domain expert, however working knowledge in these areas would be very helpful


• Questioning
• Scrum Master uses his technical, business and process skills to ask logical questions.
• Asking questions in a way that would help team find their own answers.


• A good listener / Patient
• ScrumMaster is a good listener and welcome thoughts and suggestions from all.
• ScrumMaster doesn’t gives out solutions to a problem, rather patiently hears and help team to arrive at solutions by their own.

SAFe 4.5: Continuous Delivery Pipeline

Exploring SAFe 4.5 further....

While this is not a new topic to discuss, I feel Dean and his team placed the "Continuous Delivery Pipeline" in the SAFe Big picture with some purpose.

I see that governance of  "Continuous Delivery Pipeline" is 
still behind the scene in form of "Release Management & deployment strategy" (which is hidden in SAFe 4.5), details and philosophy behind maintaining a Continues Delivery Pipeline is explained quite well in SAFe 4.5.

Many organizations have been doing CICD (Continuous Integration, Continuous Deployment) for quite sometime now, this seems to be an attempt to illustrate it better and press upon the importance of adapting this as integral part of SAFe delivery.

If you see, "Continuous Delivery Pipleline" picture has been placed very cleverly. So if you are just looking at the Big picture, you might think that this is just another representation of CICD, but it goes way beyond that..

As ScaledAgileFramework defines it -  Continuous Delivery Pipeline represents the ability to deliver new functionality to end user far more frequently than current processes are able to.

Take a look at the elements of Continuous Delivery Pipeline below -

• Continuous Exploration
• Continuous Integration
• Continuous Deployment and
• Release on Demand

Giving it a Lean startup cycle start, Portfolio feeds the Pipeline with Epics those undergoes Hypothesis-Build-Measure-Learn cycle before they can make it at Program level in sort of "Pre-evaluated" Epics or Features. In this Lean Startup cycle, an approved Lean Business case and hypothesis is taken further to build a MVP which is evaluated and preserved as a part of inputs to the Epics or in form of additional features.

This cycle helps business in deciding where to invest and which Epic to invest, which circle backs to Lean Budgets.

• Continuous Exploration helps further in taking up these approved Epics/Features and explore it further at Program and Team level in collaboration with System Architects/Eng, Customer, Business Owners, Stakeholders and Agile teams keeping Product Vision and Roadmap in mind. This stage collaborates, performs research and synthesis the backlog, roadmap and even vision (if required) based on their findings. 

• Continuous Integration is about developing, testing, integrating and validating the features and keeping it "Production ready". In large solutions, integration happens at 3 levels, namely at Story level, at System level and then at Solution level. It is important for team to integrate their work frequently using automation (frequent check-in, automated build and deploy and running validation using automated tests). Once validated at Story level, these user stories should be further integrated at "system-level" by System team to ensure that nothing breaks and system is evolving as anticipated. This system level integration can be show-cased in System Demos to indicate how ART is progressing. If teams are working on very large solution that involves multiple vendors and suppliers, another level of integration - Solution integration would be required that would bring together the tasks performed by several teams and integrated as a Solution that can be show-cased during overall Solution Demo. 

• Continuous Deployment talks about delivering the solution to end users as frequently as possible. Having an ability to have features ready in preferably small batches ready to deployment and release is the key here that would help the customer in leading in their domain with the shortest sustainable lead time. Continuous deployment ability doesn't come easy and requires team to follow the practices religiously - Maintaining dev and test environment matching production, staging matching production, deploying to staging every iteration, automated testing & deployment and decoupling deployment from release.

• Release on demand is the last stage in the cycle that actually "releases" the feature/ solution to customer/end user based on right time and/or market demand. The once visible "Release Management" icon (in SAFe 4.0) appears here (still invisibly) in form of Release governance. SAFe 4.5 articulates various release strategies based on various situations, namely - Release on PI Cadence: that is, releasing towards the end of each PI; Releasing less frequently: releasing when it is feasible, i.e. based on availability of solution and required hardware/software resources etc.; Releasing more frequently: Releasing as frequently as possible leveraging on DevOps capability; and Release on demand: based on market demand, compliance requirement, complex solutions etc. 

So what are the key takeaways or bare minimum things (sort of "essentials") so that we can leverage on Continuous Delivery Pipeline? 

I would say -

• Collaboration for exploration
• Automated testing and automated frequent and Continuous integration at Story, System and Solution level
• Dev, test, integration and staging environment closest to production for better integration
• Release governance to support various release strategies with a strong DevOps

Benefits of having a Continuous Delivery Pipeline is enormous but not many organizations have realized this. They are still debating on the basic stuff like - 
Is automation really necessary? Why do I invest in infrastructure... can’t you work on existing one? Infrastructure is costly and takes ages to procure and configure? Why do I need DevOps?

Answer is simple – automation is not separate, it is integral part of agile delivery; procuring infrastructure now a days is fast, easy and comparatively less expensive – try cloud; having environments in sync is necessary to minimize the integration issues and DevOps… don’t you love to have the control and increased capability of release on demand to stay ahead as market leader?! Choice is yours.