Iteration a.k.a Sprint Planning: Part 3

Continued from Iteration a.k.a Sprint Planning: Part 2

Now that we have all the ingredients ready and handy let's gather together and cook a beautiful dish!! Now mind you, we are not just preparing "any" dish with whatever ingredients we have, we are preparing a "specific" dish.. so in that sense focus and have a clarity on the end goal that you want to achieve.

End goal and desired output (artifacts) of iteration planning is to - 

• The iteration goal (ensure that team is aligned to the goal that was defined during the PI planning)  
• Iteration / Sprint backlog 

Assuming that you have invited all the relevant stakeholders, here is how one can approach the Iteration planning, the "how" part -

• First, team determines its capacity based on number of members allocated to the team and vacations/off days.
• Based on the capacity, team them forecasts the story points they believe they can deliver in that iteration/sprint.
• Based on the forecast, team "loads the sprint" with the backlog items as per the priority that Product Owner recommends. Backlog items may have items those have spilled over from previous sprint, any defects/bugs, spikes etc. and/or items from product backlog based on the priority.
• Once the sprint is loaded, team re-looks at the newly created sprint backlog, breaks the items in sprint backlog into manageable tasks and re-validates the estimation to ensure it matches the capacity.
• It is recommended not to "load" the sprint to it's fullest capacity (100%). We need to reserve some capacity to perform other sprint activities such as iteration review/demo, retro, backlog grooming, sprint planning, taking care or other activities such as support, maintenance and some buffer that would take care in case certain spike / backlog items takes a bit more than what was initially planned. This totally up to the individual teams to decide on how much time they would like to reserve for such activities.
• Breaking down the backlog items in tasks helps team to clearly see what it would take to complete the tasks and adds/removes the tasks from the iteration backlog accordingly.
• Once team acquires the the confidence about completing the backlog items among themselves, they convert that confidence into commitment in the form of sprint goal that keeps the team focused on what they are planning to achieve during the sprint. 
• Sprint goal is a team activity; I had to specially mention this as many time team looks at Scrum Master or Product Owner or someone senior in the team to come up with the sprint goal which is not correct. Product Owner/Scrum Master can guide the team on the goals but team has to come up with their own words/text as sprint/iteration goals. This activity re-validates teams understanding of sprint priorities, overall picture and alignment with PI objectives.  
• We had a practice to add a backlog item (preferably smaller in size e.g. 5-10% of the team's capacity) as stretch goal item that team would attempt to complete once team takes care of the committed items of the backlog. Please note that stretch goal is not part of Sprint goals.

Once all these activities are done and team is ready with the artifacts - Sprint goal and sprint backlog, it is time to grind i.e. to execute the sprint/iteration!  

Iteration a.k.a Sprint Planning: Part 2

Continued from Iteration a.k.a Sprint Planning: Part 1

Before jumping directly to the recipe, let’s checkout the ingredients first! 😊

What are the ingredients of successful Iteration planning?

Here is the list of ingredients for successful Iteration Planning; So as a "Chef", Scrum Master must keep all these items handy. Read through them and you will realize that getting this list ready requires a good amount of homework.

• Team’s alignment to the PI Objectives
• Team’s understanding and alignment to PI Objective is one of the most vital part of successful iteration planning. Execution is seamless when team understands the big picture and what they are trying to achieve in upcoming iteration.

• Team’s PI Plan backlog
• This is team’s backlog that was created/planned during the PI planning i.e. list of user stories or PBIs (Product Backlog Iteam’s) that team considered during the Big Room Planning (PI planning).

• Ability to adapt change in priority
• Here is our chance to show “Agility in action”. Due to market condition or business priorities or any other internal/external factors there might be change in the priorities. Check the pulse, how flexible is team to adapt change in priorities?

• Prioritized and refined backlog
• Readiness of prioritized and refined backlog. This is litmus test of PO role. This shows how connected PO is with the Business/Product Management group and team. Frequent and healthy discussions with Business/Product Management Group would indicate early signs of any changes in priority and good connect with the team would result in more clear and refined user stories. Good question to ask - Do the user stories that we are about to consider for upcoming iteration meets the DOR (Definition of Ready)?

• Understanding the value that team would deliver by the end of the Iteration
• Team should be able to correlate all the prioritized user stories in the backlog and should be able to understand the value that they would be delivering as a team towards the end of the iteration. Clarity on value is important. What’s the fun in delivering something that doesn’t have any value to the customer?

• Well defined Iteration goals
• This goes hand in hand with “understanding the value”, this is my personal favorite and I have seen that almost 90% team doesn’t follow this. Team must come-up with written iteration objective in simple terms that brings clarity and focus. These written objectives should be communicated to all the stakeholders involved.

• Team’s velocity and capacity
• Iteration commitment should not be based on pure emotions, it should be backed with the facts. Taking a look at historical velocity of the team will give fair idea about the trends in the past and would help in committing to the realistic goals.

• Capacity is another factor that team should consider. This would include team member’s / SMEs / architect’s allocation to the project, availability i.e. vacations/off days etc.

• Team Capabilities
• Reality check – Does team have required capabilities/skill set to undertake upcoming user stories. If yes, to what level, if no, then what can be done about it? You want to hire/loan from other project?

• Spillover work from previous sprint
•  Important one and many times overlooked as team is more focused towards upcoming new backlog items. There could be some spillover tasks from previous iteration that might take away some of the team’s capacity.

• Additional tasks, rework, User stories coming out as a result of defects, refactoring etc.
• Tasks resulting from defect, refactoring or addressing NFRs needs to be considered during Iteration planning.

• New backlog items based on feedback from previous demo
• Completing the feedback loop from previous demo, there could be new backlog items sprouted out from the previous system demo.

• Backlog items from Retro
• Considering the backlog item(s) those were resulting from “Improvement ideas” and “what did not go well” shows the signs of team’s maturity.

Once you (as a Scrum Master) are ready with the ingredients (the above list) and have done your homework... next comes the how part - The recipe!!

To be continued….

Iteration a.k.a Sprint Planning: Part 1

If you fail to plan, you plan to fail.

-Benjamin Franklin

Iteration/Sprint planning is much of an overlooked ceremony than I initially thought. When I say overlooked I don’t mean that teams do not conduct this ceremony, they do conduct “Sprint Planning” but most of the times it just for the heck of it (without any purpose) or just for compliance.

Curious to know the reason behind the passiveness (or should I say lack of enthusiasm) in Sprint Planning, I started asking questions to number of teams, colleagues and friends and got following insights/retro points -

• Few of the members view it as “time-waste”.
• Team is not aligned to PI Objectives
• From Scrum Master's perspective - Lack of knowledge on how to facilitate it effectively.
• From Team's perspective - Lack of understanding of the desired inputs expected for Sprint planning
• Few thinks – everything has been already planned at PI level so it is just matter of loading the sprint with the pre-identified PBIs (Product Backlog Items).
• Other feels, anyways my customer is so aggressive that I am sure my priorities are going to change in mid-sprint, then why bother?
• In onsite-offshore model where onsite is driver (e.g. Scrum Master/ Product Owner / key roles are at onsite), offshore keeps mum just thinking that “anyways onsite experts and seniors are there, so they will take care”. Similar situation might happen if all the key roles are at offshore and there is just few developer/testers at onsite, in this situations onsite members would keep their lips tight!
• Lack of participation from key stakeholders (PO, key team member, vendors etc.).
• No clear deliverable … just exploration.
• Scrum Master or PO dictates what must be done in the sprint without considering any opinion from the team.
• Long pending issues are still pending and there are no actions – members losing interest.
• No follow-up / actions on the retro items – member losing interest further.
• Lack of preparation

… and there could be many more reasons but my question is are these reasons worth enough to miss our cadence.. lose our zeal or destroy team’s reputation?!! Certainly not!

Few of you might be thinking, what’s the big deal, after all it is just a ceremony and we can catch it up in few days/weeks… think again!! In my view, basically people fail to recognize that Iterations (Sprints) are basic building block of entire Agile software development process. So, unless you are aligned at this level, it is almost impossible to align to the PI objectives or at Program or Portfolio level.

Having said that, let’s revise our basics –

What is Iteration (Sprint) Planning?

• Iteration Planning is a team event where based on the priority suggested by Product Owner,  team come together to identify, organize and agree on certain realistic goal(s) that team feels they can achieve and deliver during the sprint/iteration.

When does it occur and for how long?

• When: It typically falls on the very first day in the beginning of the sprint. However, there are people who would prefer to do it on the last day of the previous sprint so that they can make a fresh and clean start from the beginning of next sprint.
• For how long: I would recommend 1 to 1½ hour per week per sprint. That is, if your sprint is 2 weeks long, you keep sprint planning activity for 2-3 hours depending upon your comfort level.

SAFe suggests upto 4 hours of Iteration Planning for 2 weeks sprint.

Who participates the Iteration Planning?

• Simple answer, entire scrum team (Scrum Master, PO & Team)!There could be occasions that few SMEs or architects or business owners might join the meeting to clarify certain things and help team with the planning. If your delivery has dependencies on external supplier or third party vendor, they must be part of the sprint planning meeting to help in deriving the sprint goals, identify/agree on the integration points and other milestones.

Sometime even RTE joins the meeting to see if teams are aligned to PI objectives and also to coach/guide them as necessary.

So what is the recipe of successful Iteration planning anyways?

To be continued…
Check out: Iteration a.k.a Sprint Planning: Part 2

Scrum Or Kanban : Choosing the one that fits the best !!

Recognized as few of the early Agile process framework, both Scrum and Kanban helped in improving the Software development efficiency.

Here is a post that discusses about brief background, principles, the factors that one need to consider to pick a agile framework that suites best based on the nature of the work, delivery frequency, scope change, time to market etc.

Scrum	Kanban
This concept was first introduced in 1986 in Harvard Business Review article “New New Product Development Game” authors Hirotaka Takeuchi and Ikujiro Nonaka described a new approach to do product development to increase speed, flexibility based on their case studies from automotive manufacturing, photocopier and printer industries. In 1990s Ken Schwaber and Jeff Sutherland collaborated their experiences and good practice to further develop Scrum concept.	Adopted from the way “supermarkets” were maintaining their inventory in late 1940s, Japanese manufacturing giant Toyota made some process changes in their manufacturing unit to bring tremendous Production efficiencies in their manufacturing plant. Kanban (meaning sign-board) is an inventory control system to control supply chain.
Seen as “holistic” development strategy, this Agile process framework uses iterative and incremental software development framework to manage and develop complex software and products.	Eliminating/ minimizing process inefficiencies, Kanban uses visual aids (billboard/card) to improve decision making and allowing better understanding of work to be done, capacity available and overall workflow.
Scrum operates with following 6 principles: Empirical process control: This principle promotes ideas of transparency, inspection and adaptation. Self-organization: When team is self-organized, it results in shared ownership and innovation and creates an environment that fosters growth. Collaboration:This principle focuses on 3 factors of collaborative work awareness, articulation and appropriation. Value-based prioritization: Concentrations on the business value right from the beginning of the project Time-boxing:Helps in effectively manage project planning and execution. Iterative development:Iterative and incremental development involving customers and continuous feedback.	Kanban operates with following 4 core principles: Visualized work:Making work visible to indicate the stage of the work and queues along with any blockers or bottlenecks. Limit Work in Progress/Smaller batches:Limiting the amount of work that can be taken in parallel, instead dividing work in smaller batches and taking them to completion. Optimize and Focus on Flow:Taking advantage of WIP limit, overall flow of the system can be optimized and improved where possible future issues can be pre \-identified by analyzing the flow. Continuous improvement:Using relentless feedback loop to identify areas of improvement to bring more efficiency and removing “waste”.
Scrum is - More prescriptive & structured Is Time-boxed, have development cadence, iteration More organized and have roles such as Scrum Master, PO and cross-functional team Team can plan better Best suited for development work Progress can be seen with the help of Burn-down/Burn-up charts Mainly used at team level in SAFe framework, by development teams	Kanban is – Less prescriptive/structured than scrum Not time-boxed, it is event driven Shared by entire team, no specific roles Estimation is optional, as this is event driven, planning is not always possible Best suited for support and maintenance work. Progress can be measured using cumulative flow or cycle time. Used at almost all the levels of SAFe framework e.g. at Portfolio level to keep backlogs of Business/architectural Epics, at Program level to maintain Features or tasks related to System’s team and at Team level to maintain support related tasks/tickets)
Best suited when – Budgets are planned based on certain functionality, release dates and resources Delivery roadmap is available and is clear Used by application development teams based on release calendars / planned releases. Change in priority is less volatile Team size is (7-9) and may have dependencies with other teams	Best suited when – Budgets are generally planned on number of change requests/tickets and resources No roadmap available, requests comes ad-hoc Generally used by application management/support teams and are managed based on hot-fixes or continuous releases. Priority continuously changes Team size is small (less than 7) and less dependency on other teams
Advantages includes – As this is more process oriented, it improves transparency Establishes credibility with the client with ceremonies like Sprint planning, demo etc. Advocates built in quality Used for product stability Over time, team reaches a sustainable velocity Gives flexibility to client to change priorities and requirement as per dynamic market conditions/demands.	Advantages includes – Kanban offers flexibility Flow and continuous delivery is the focus point Used to improve productivity and quality Improves efficiency (small, faster batches) As it gives emphasis on limiting WIP, team is more focused Focuses on Reducing waste

New Scrum Team – Basic Ground Rules

I love to take various workshops with my teams, especially when the team is new, it adds fun to it.

Workshops can be on anything, e.g. workshop for deriving ground rules (guidelines) for the team, improving delivery quality, resolving a problem/impediment, building trust, alignment, respect etc.

It gives me goosebumps to see the unique outputs from each workshops. Team too realizes the beauty of collective learning.

Here are some abstracts of bullets those were collected when I was assigned a new team few years back and I wanted to align them on certain “behavioral” and “professional” aspects.

I asked them to come up their understanding of – What is “Basic Ground Rules”? And if our team needs to have some guidelines defined on “behavioral” and “professional” front of the team.

When you go through bullets below, it might seem trivial points to few of you, but it lays down the basic foundation of “alignment” and once team is aligned to a “Purpose” people can do wonders!

Here is what I got from the team:

What are ground rules in our context (Scrum Team)?

"Ground rules are a list of behaviors and rules a team decide are useful for working together as a team in a productive and respectful way to increase overall team’s performance and efficiency."

Suggestions on ground rules/guidelines :

• Members must be available for daily scrum or other scheduled meetings on time.
• Individuals JIRA tasks/comments must be updated before coming to daily scrum.
• Leaves/vacations must be planned as much as possible, let’s try avoiding ad-hoc off-days.
• Vacation alert must be added to the email signature and should setup out-of-office note during their vacation. Weekly once, member should update about their upcoming vacations, if any.
• We must use common email signature structure to depict ourselves as “one” team.
• Once Sprint starts, no JIRA tickets should be in unassigned state.
• All the User stories must have story point estimations.
• During daily scrum, make sure that everyone gets heard (updates must be precise and clear so that everybody understands what you are doing)
• All the clarification related to user stories must be done using JIRA comments sections so as to keep a log of discussion (add all the stakeholders/team-mates as “watchers” so that all are notified whenever there is an update)
• Avoid informal/social talks during team meetings.
• Inform team if unable to complete work on time.
• Treat each other with respect.

Other suggestions for improving team’s performance

• Ownership must be evident
• When time calls, confront issues directly and promptly.
• Take initiative by offering ideas and volunteering for tasks
• Play an equal role in the team by contributing equally to every task.
• Ask for help from the team or other resources if “stuck” or falling behind.
•  Accept responsibility and accountability along with the authority given.

Simple and precise; created by the team, for the team !

PI Execution & RTE Responsibilities: Part 4

My first 3 articles on RTE responsibilities were more inclined towards one of the biggest ceremonies in SAFe – PI (Program Increment) Planning.

You can find these articles here –

PI Planning & RTE responsibilities -

RTE Responsibilities: Part 1

RTE Responsibilities: Part 2

RTE Responsibilities: Part 3

PI Planning ceremony “tests” RTE’s Preparatory, Planning and Facilitation skills to the core. Next comes “PI Execution”, the “doing” part, where rubber meets the road!

PI Execution

Keeping overall ART objectives in back of his/her mind (Applying Systems Thinking), RTE along with Scrum Master and PO, starts aligning team right from the basic building block of the PI that is Sprints or iterations.

RTE overlooks overall iteration planning of the teams and ensures that iteration goals of the teams are aligned with Team’s PI objective and aligns to ART objectives. While RTE may or may not take part in team level ceremonies (depends on his availability) such as Iteration planning, Daily stand-ups, Team/Iteration demo, Retro etc. as a “Chief Scrum Master” it is RTE’s responsibility to guide Scrum Masters’, POs’ and teams’ in performing these activities more effectively.

I have not seen/heard many RTEs performing the role of “Chief Scrum Master”, instead they would just operate at Program level and seldom attends any Team ceremonies. I would personally urge RTEs to attend Team level ceremonies whenever possible so that they can guide the teams and also to get an early idea about trends and behavioral aspects of the team and re-assuring that teams are aligned to the PI objectives; besides this, it keeps the team motivated to see RTE participating at team level ceremonies.

Let’s take a quick look at important responsibilities of RTE during the PI Execution and what it takes -

• First and foremost duty of RTE is to bring alignment in ART; RTE needs to ensure that business vision and roadmap reaches to all the teams and teams are align to the PI objectives.
• Strong understanding of SAFe framework and Software engineering practice will help RTE to ensure that teams are following the SAFe principles and practices effectively.
• Support the Strategic Program Management team in ensuring governance standards from the client as well as serving organization are applied within the team.
• Creating/updating train wide overall plan that describes the Goal and Objectives of the train, Scope, Roles and responsibilities, overall governance, tracking and reporting, escalation matrix, Change Management, Training plan/requirement, Risks and issues etc. This sort of documentation would bring common understanding among all the stake holders involved in the train.
• As a Chief Scrum Master coach and support Scrum Master to optimize team’s sustained output/velocity and quality and maintain team’s motivation.
• Making sure that teams are working towards building something that would provide value to the customer and not mere concentrating on velocity.
• Encouraging collaboration among Scrum Teams, System Architect and System team.
• Conducting effective Program level ceremonies such as SOS, PO/ART sync, System demo, I&A, Prep activities for next PI etc. Let’s take examples of SoS and I&A -
• E.g. Scrum-of-Scrum (SoS): Ensuring that it is not status update meeting. Team is actively identifying the dependencies (using Program Board) and ROAMing the risks and dependencies as self-organizing teams or coming-up with action plan/escalation as appropriate and overlooking how team is progressing towards iteration/PI/ART Objectives.
• Effective Inspect and Adapt (I&A) ceremony: Inviting all the stakeholders, facilitating PI System demo, presenting Metrics and trends, Retrospective and conducting problem solving workshops. Take the feedback from demo and retrospective and add them to backlog.
• Help team in keeping the Program Board up-to-date.
• Ensuring that Iteration demos (Sprint Demos) are happening as planned and solution increments are integrated after each iteration.
• Ensuring NRFs (Non Functional Requirements) are taken care along and team is focused on continuously reducing the technical debts.
• Possess better understanding of component, application and feature teams and their inter-dependencies for better facilitation of discussion among the teams.
• Work with the Product Manager, Scrum Masters and stakeholders to identify, describe, track, prevent and resolve risks and remove or facilitate removal of impediments.
• Drive delivery and continuous improvement by utilizing feedback and metrics (Team’s Self-assessment, Burn-down, Velocity, defect rate, etc.) to identify areas of opportunity and improvements.
• Understanding vendor’s/supplier’s dependencies, and ensuring their availability for all possible program level/team level ceremonies.
• If vendor/supplier are following other methodology, ensure that their deliveries are aligned with the PI/ART level milestones.
• Conduct analysis of metrics and performance data to help the teams on the ART self-optimize and report progress.
• Provide regular and open communication across the program and stakeholders for transparency and awareness of progress and impediments.
• Create timelines, milestones, and cadence of increments and releases.
• RTE to be in regular touch with the SAFe Program Consultant / SAFe Coach to seek guidance on the metrics trends, coaching at Train and team level, have better understanding of SAFe framework, managing impediments etc.
• CoP (Community of Practice) is another area where RTE can share experience from his train while trying to understand and learn from his peers about best practices being followed in other ARTs.
• RTE can learn from or can join Lean-Agile Leadership forum to be part of leading the change, develop teams/fellow RTEs and help the leadership develop an area that promotes continuous learning and apply those learnings to work.
• RTE overlooks the overall progress and Kanban board of System team and DevOps team to ensure that there are no blockers for Dev teams from environment availability or continuous integration and delivery (CICD – Continuous Delivery Continuous Progress) perspective.
• Ensuring that team is in-sync with the miles stones and release planning.
• Following up with the System Architect, Program Management and PO to do preparatory activities for upcoming PIs, i.e. prioritizing Epics/Features, feature splitting and draft user stories.
• Following the agreed governance plan and updating the stakeholder with absolute clarity and transparency.

RTE Responsibilities: Part - 3

RTE Responsibilities: Part 1

RTE Responsibilities: Part 2

….Continued from RTE Responsibilities: Part 2

Now come the tasks those needs to be taken care after the PI Planning ceremony.

Post PI Planning Tasks

Some of these tasks needs to be executed right after the PI Planning ceremony and few of the tasks/follow-ups can be done next morning or during the course of Iteration (Sprint) 1.

• RTE to collect/capture PI objectives from all the teams to derive ART level PI objectives and communicate to the stakeholders.
• Capturing the Program board details and sharing it with the remote teams at the same time moving the physical Program board near team’s area so that team can update the board throughout the PI Execution period.
• Follow-up items including risks & dependencies those are to be discussed later are well documented and followed-up post PI planning to take it to the closer
• Sending invites for Program level ceremonies like – Scrum-of-Scrum, ART Sync, Inspect & Adapt, PI System demo etc.
• Finally cleaning up the mess in the facility (Removing post-its from wall, removing charts, cleaning up whiteboards etc.)

If you just consider this ceremony (PI Planning) alone, the degree of coordination and support a RTE would require to ensure that PI Planning goes smoothly is humongous! This efforts grows multifold when PI Planning happens at multiple locations.

Okay, I understand that in ideal world, all the stakeholders/teams should gather in one facility for a successful PI Planning, however many times bringing all stakeholder together might not be possible because of certain logistical/financial constraints. During such times, RTE can identify and appoint a Proxy RTE at each location to ensure that events of PI planning goes smooth.

Both RTE and RTE-Proxy should have good understanding and should be in sync with each other in coordinating and facilitating PI Planning events. For example, there should be common understanding of how artifacts will be share across multiple locations;  or how to involve remote teams in breakout discussions (Video conference, Conference Bridge, confluence/JIRA, emailing etc.) or how the vote of confidence would be collected or PI retro points would be communicated etc.

At the end of it, one has to understand that big ceremonies like PI Planning would evolve and get better over time as we focus and put deliberated efforts in improving on the "lessons learnt" a.k.a "improvement areas" and "good practice to be continued" identified during PI retro. 

RTE Responsibilities: Part -2

Continued from SAFe Release Train Engineer (RTE) Responsibilities: Part -1
  
Phew… looking at all the pre-planning activities you must be wondering is it over yet?! 
Answer is nope, not yet!

All that RTE managed to coordinate so far was about Organizational readiness and Content readiness for “THE BIG EVENT” which is PI PLANNING.

So what’s pending now ?!
Answer >> Getting the “Facility” ready for the big day!

As you might be aware, PI planning (or Big room planning as few people might call it) is typically a 2 days event. RTE must ensure that Facility is ready with:

• All the required communication devices such as Video conference facility, Phones, conf. bridge details, Projectors, Mic/Speakers, WiFi/LAN connections etc. (check and test the communication devices way before the actual PI Planning day)
• Stationary such as notepads, markers, whiteboards, Post-It notes, Pen, Pencils, Erasers etc.,
• Multiple meeting rooms that would be used during break-out sessions
• Enough collaborative tables and chairs and most important...
• Arrangement of tea, coffee, snacks and lunch or dinner.

Once the readiness of the facility is establish, RTE can take a sigh of relief and wait for the Big Day 😊

Finally the BIG Day is here -   "PI Planning" (Well, actually 2 days)

I am not going to indulge into the agenda of Day 1 and Day 2, this you can easily get it here  PI Planning 

Here is RTE’s responsibilities during PI Planning event -

• RTE is overall facilitator of PI Planning event for Day 1 and Day 2.
• After briefing entire ART on Day 1 and Day 2 agenda, RTE would invite Business representative to give Business context to ART (Agile Release Train).
• Business context is typically followed by Product vision by Epic/Business owners.
• Next comes System Architect and Engineering team to talk about Architectural vision/Runway and best software engineering practices.
• RTE provides the Planning context for PI, communicates the logistics about team breakout etc.
• RTE ensures that breakout sessions are well utilized and team gets all the support from required stakeholder (business, architects, SME)
• During breakout session, RTE would quickly visit each and every team to see how team is progressing with their plan and would conduct quick Scrum-Of-Scrum for short interval approx. every 45 mins to 1 hour.
• Towards end of Day 1, RTE invites each team to present their draft plans.
• Once the draft plan is presented, RTE facilitates Management review and problem solving. This could be in form of suggesting resources, change in scope, providing ideas on reducing the dependencies etc and closes day 1.
• During this time RTE also urges team to update the program board with the features and dependencies.
• Draft train/team level risks are identified.
• In Day 2, RTE ensure that team understands the feedback from business on draft plan and making required adjustments to increase the confidence level
• RTE facilitates teams to present their planning adjustments based on the outcome of Management review.
• During team breakout of Day 2, RTE visit each team and can do a pulse check to see how confident team is feeling with their plan and guide them with their planning.
• RTE helps Team to come up with realistic plan that is achievable.
• RTE ensures that Team level objectives are clear and have business value associated with it.
• Post breakout, RTE invites SMs/POs to present the Final plan
• RTE facilitates Program level Risk ROAMing   (ROAM: Resolved, Owned, Accepted, Mitigated)
• RTE collects the Vote of confidence at Train level and checks (based on vote of confidence) if any of the plan needs to be reworked
• RTE concludes the Day conducting retrospective for PI Planning

SAFe Release Train Engineer (RTE) Responsibilities: Part -1

My Last article (What makes good RTE) talked about all the technical and soft skills that RTE must possess to make a "good" RTE. It is important that companies look for these these skills when they are planning to hire/assign someone with the role of RTE.

Technical and soft skills are all good but what if RTE doesn’t know his/her responsibilities or knows just part of it ?!!

In my article (series) below, I shall try to touch-base on key responsibilities of a RTE.

Looking at huge load of responsibilities RTE carries out during and beyond a typical life-cycle of a Program-Increment (PI) while managing an ART (Agile Release Train), I am dividing the topic of “Responsibilities” in different parts as per PI life-cycle or SAFe ceremonies or the key stakeholders that RTE interacts.

Note: Since Solution Train Engineer (STE) carries out similar responsibilities in “Full SAFe” configuration especially in “Large Solution or Solution Train” context, most of these responsibilities applies to STE as well.

So, let’s start with PI Planning. Mind you, when I am talking about PI Planning, I am talking about bigger context here and not just the PI Planning ceremony or event as such.

I look at PI Planning as following –

• Tasks those needs to be taken care “Before” PI Planning ceremony, i.e. Pre-PI Planning tasks
• Actual PI Planning - PI Planning ceremony itself
• Tasks those needs to be taken care “After” PI Planning ceremony, i.e. Post PI Planning tasks

Now, let’s take a look at the responsibilities that RTE needs to carry out as part of Pre-PI Planning-

• Send out yearly (typically for 1 year) calendar indicating PI and sprint/iteration timelines for his ART.
• Next, identify key stakeholders those are closely associated with upcoming PI and ensuring their availability. These stakeholders could be Business owners, Epic owners, Subject Matter Experts, Solution/System Architects, Systems team, Scrum Master, Product Management group, Product Owners, Teams, 3^rd party vendors/suppliers etc.
• Pretty trivial and obvious it might sound, RTE should send out a compelling invite for the PI Planning with Agenda for Day 1 and Day 2 to all the stakeholders.

• Coordinate with Product Management Group/Business or Epic Owner for-
• Availability of Roadmap and Vision.
• Close coordination with Product Management group, ensuring clear understanding of ART level vison and roadmap.
• Checking and try to understand Business context for next PI.
• Train level Business/Architectural priorities are available.
• Epic owners and Product Management group are in sync and ART level/solution feature backlog is available.
• Help in deriving ART level MVP (Minimum Viable Product).
• Helping Product Management Group with right-sizing the features that can be executed in a single PI.

• Coordinating with System Architect/System Engineering Team for-
• Encouraging System engineers/architects to collaborate with Product Management Group and work towards prioritizing the overall Product backlog.
• Collaborate with System architect to understand the overall Systems view.
• Encourage System architect and Engineering team to collaborate with the Product Management Group to have a shared technical direction towards achieving the MVP.
• Ensuring high level NFRs (Non-Functional Requirements) are discussed and established.
• Ensuring that System Engineering and Architects actively participates in “Continuous Exploration” with Enabler/Architectural Epics.
• Support in establishing Kanban’s for respective teams.
• Ensuring System architects are getting all the required support to plan and develop the Architectural Runway to support the upcoming prioritized Business Epics/Features.
• Ensuring that System Architects are aligned and working closely with Enterprise Architecture while developing architectural runway.
• Establishing coordination with System Architects and Agile teams for any spike/POC work.

• Collaborating with Third Party/Supplier for-
• Ensuring the availability of Third Party/Vendor representative in PI Planning well in advance.
• Help ART identify the dependencies with Third Party.
• Ensuring that Third party’s cadence/milestone matches with that of ART milestone/PIs.

• Collaborating with PO for ensuring -
• Healthy Team level backlog and priorities are available.
• Clear understanding of ART level MVP and help defining feature level MVP.
• Features are identified and explored and high level user stories have been identified.
• With the help of PO, ensuring team level priorities have been socialized with Team.

• At Agile Teams & Train level to -
• Identify the teams and SMEs availability
• Negotiate with offshore/onsite management on resourcing.
• Help Scrum Master with capacity planning (as required).
• Understands team’s cadence.
• Understand Train’s cadence.
• Identify and manage dependencies among teams.
• Help with team/train level MVP planning.
• Flip Epic level POC/spikes/enables to teams to help Business and System Arch team with sizing and estimation.

What makes good SAFe RTE (Release Train Engineer)

Before we indulge into critical skills or behavioral aspect of an “ideal” RTE, I must say RTE must have complete understanding of overall SAFe Framework and in particular following SAFe Lean Agile Principles…

You might ask “why”; and the answer is pretty obvious… during entire life cycle of PI/multiple PIs there would be numerous occasions where RTE might have to take decision or might have to guide the team/PO/architect/stakeholders based on these Principles.

1. Take an economic view
2. Apply systems thinking
3. Assume variability; preserve options
4. Build incrementally with fast, integrated learning cycles
5. Base milestones on objective evaluation of working systems
6. Visualize and limit work-in-progress, reduce batch sizes, and manage queue lengths
7. Apply cadence (timing), synchronize with cross-domain planning
8. Unlock the intrinsic motivation of knowledge workers
9. Decentralize decision-making

Now let’s go through characters and skills that would make a good RTE.

•       Excellent facilitation skills: Must be a good facilitator to encourage attention and participation from the team/stakeholders.

•       System Thinker: Points to 2^nd SAFe Lean Agile Principle. Does your RTE have a holistic view? Is he/she able to view the solution as a system or other aspects such as people, management or processes that builds the solution as a system?

•       Servant Leader: RTE is Chief Scrum Master. Moving away from “directive” style of leading, RTE must be able to gain respect from team and stakeholders should be resourceful to get the job done.

•       Empowering: Driving and guiding an ART (Agile Release Train) and multiple teams to self-organized teams and empowering and helping teams to take decision.

•       Attitude of transparency: Being transparent to the team (downstream – Team level) and to the own organization /client /business (upstream – Program & Portfolio level).

•       Collaborative: Ability to partner with others to achieve goals at various levels throughout the organization and lead others to do so by example

•       Excellent communication skills: Does your RTE feels comfortable to communicate both good news and bad news with all levels of the organization from Scrum team members to executives? It does require some good communication skills.

•       Conflict resolution: Conflicts are not always bad. A good RTE must be able to facilitate discussion at the release train level and facilitate alternatives or different approaches to resolve conflicts or difference of opinions.

•       Continual improvement & learning: RTE must have very good understanding of Agile metrics. Should be able to understand and meaningfully interpret the metrics and guide teams to overall improvement.

•       Technical Knowledge: Technical skills can come handy when negotiating and discussing with architect/business and to understand solution and it’s technical feasibility.

•       Budgeting: Now a days there are multiple ways Agile contracts are signed. RTE must understand the budgeting part of the overall contract very well to keep an eye on overall budget vs. value delivered.

•       Ability to Remain Focused: not distracted with external and internal influence and focused on encouraging team to deliver value.

•       Leadership Skills: Able to motivate, influence and direct teams/stakeholders to achieve the business objectives

•       Enthusiastic: RTE must be passionate about the role he is playing and should possess high-energy.

•       Assertive: Always ensuring that team adheres to SAFe concepts and principles. If situation demands he/she should be able to make the tough calls.