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.

API, Web Service & Micro service - Acknowledging their uniqueness

I have seen people using the words APIs, Web Services and Micros services almost synonymously. Collating some ready-reference to acknowledge their differences and uniqueness.

Happy reading & sharing!

API (Application Programming Interface), Web Service and Micro service all serves means of interaction or communication.

API	Web Service	Micro Services
API can be seen as an interface that facilitates the communication/interaction between two or more applications or programs	Web service facilitates the communication of applications over network.	Microservices is a specialization of an implementation approach for service-oriented architectures (SOA) used to build flexible, independently deployable software systems
API has several means of communication. It could be triggered by certain application events, server events or even by system interrupts.	Web services uses HTTP (most commonly used protocol), SOAP, REST and XML-RPC as means for communication	Micro services communicates through HTTP,REST,JSON
APIs are Specific to programming language and have predefined rules on how unit of codes would interact with each other	Web Service interacts over communication protocol (e.g. HTTP), independent of any dependencies of programming language.	Services communicate using either synchronous protocols such as HTTP/REST or asynchronous protocols such as AMQP (Advanced Message Queuing Protocol).
API specifically defines methods that is to be consumed by other application/program to interact or within the same application.	Web Service performs similar (bit limited) functionalities as APIs but used over a network or Web.	Web services are generally targeted to perform just one functionality over network/web.
Desktop applications like Word, Excel, PowerPoint mostly  uses APIs that doesn’t involve web service	When application is Web-based, it may involve using API wrapped around HTTP (which is nothing but a Web service)	Micro services are loosely coupled collaborating services that might be exposed through API gateways or directly over web using HTTP.
API does not need network to interact. The APIs can be exposed in a number of ways which include: COM objects, DLL and .H files in C/C++ programming language, JAR files or RMI in Java, XML over HTTP, JSON over HTTP, etc	Web service can interact only over network.	Micro services can interact only over network.
API is more close to application and facilitates the interaction directly with the applications	Web service doesn’t interface directly with application. Interface is only open for the methods and properties those are exposed through HTTP, SOAP, REST or XML RPCs	Same as Web services
All APIs are not Web services	All Web services are APIs.	Deep inside, Micro service is still API – however a granule one.
API can perform lot more operations than a typical Web service or Micro Service can perform	Web service might not be able to perform all the operations that API would perform
Typically faster in execution, however not scalable	Slower or at par in execution with API, scalable to certain level	Slower or at par in execution with API, has highest scalability
As APIs typically responsible for number of functionalities, that is, if API is down/corrupt or missing it can bring down entire application or major functionalities	If Web services are down, it will impact only certain functionalities. It will impact the application to minimum or moderate level	Depending upon the implementation, if microservices are down, it will impact very small functionality of the application. Application as a whole will remain intact.

From Bulky, Fat ..to …… Lean & Healthy!!!

Read the heading again, nope not an easy task… you might say - I tried so many times but doesn’t look like I am losing any fats or I will start doing something about it from tomorrow (and tomorrow never comes) or I am too busy at the moment, let this phase go and I shall start my work-out. Few of my friends even argue, you need to have fats/bit of tummy that’s when the tuxedo or blazer suites you well

I bet many of us who are reading this and are on “heavier” side of BMI (Body Mass Index) knows what I am taking about. Basically what is happening – we have started “enjoying” the “fatness”, even though we know that extra fat is not healthy as soon it will start impacting our performance and comes with a hefty cost we still carry it and come up with “innovative” excuses for not taking any action to reduce it.

Yes, there are people who does take action for few days (jogging around the blocks or joining gym) but not able to continue it consistently.

Do you see some pattern here? If we/our processes are fat, somehow we start love it having around (fat), we just convince ourselves that .. that’s okay, it is not much, or I shall work on removing/reducing the fat (wastage) tomorrow coz I am too busy now.. and over time we start even acknowledging it as great “possession”… 

Hard truth - the fact remains – Fat(wastage) invites issues, slows our speed/progress, hits us both mentally and physically and starts spoiling our environment slowly...almost unnoticeable.

So how do you start towards the “Lean” and “Healthy” journey?

To start with, you need to ignite (and keep up the flame) the thought of becoming “Lean”.

How?

First, You need to visualize clearly in your mind – what is your goal (end value – in terms of specific weight, size etc).. what value/benefit you would bring to yourself or people around you when you are a lean-mean machine (Identify Value)

Second, identify and organize your steps, actions and things to achieve the end goal. Steps could include identifying a gym, searching a joggers track/park, buying jogging apparels/shoes, selecting energizing music track during the course (I personally prefer audio books), eating habits - what to eat what to avoid or may be a companion who always motivates you… that is list of everything that serves you as Value stream to achieve your end goal.

Third, create a habit, rhythm a flow … best way to do it to internalize the process. Coz when it comes from within, you will start enjoying it, you will not take it as burden. It should happen in a way such that you should be drawn/pull towards your “end goal”, as you are with your “Value stream” and “flow”, you will start observing that waste is slowly getting removed/ disappeared as you would start taking initiatives to eliminate the obstacles in your flow. So, who is removing those hurdles and impediments? It is you, as you've started enjoying the journey, you've started feeling light and healthy. Remember -You don’t just create the flow – maximize the flow / the grind.

Fourth, as things are in flow, you ought to motivate/empower people around you. After all whats the fun in keeping the joy and benefits to yourself when you see that people around you are still carrying the burden of bulkiness? Tell your success stories and benefit of staying lean, light, healthy and energetic. Guide/help/train people around you to take lean journey with you. Create and standardize the process, a kind of ready-reckoner for people to refer and inspire and empower people to follow the path for great results.

This last one, Fifth, circle backs to the entire process. In simple terms, how do you optimize it? Make it work better? It is Continuous improvement.
PDCA – Plan, Do, Check, Act/Adapt offers us a methodical way to solve problem and improve. It is about observing each of our steps to see what works, what doesn’t and what can be done to improve/optimize the entire life-cycle of becoming lean and taking those actions. It is about always trying to seek optimal and innovative ways stay lean all the time.

Follow this and I bet you will be a lean-mean machine soon...and if you pay attention to the "Fifth" step, you would stay lean.

What more, apply the above five steps/principles at your work and soon you will establish a “Toyota” like culture at your workplace.

Wondering can we use the metaphor above and map it to the five principle of “Lean Thinking”? (check the text in bold)

What do you think?!

PS: About me, nope I am not Lean yet, but nevertheless I am already on my way and started enjoying the journey itself :-)

Reducing Technical Debt - My code, my responsibility

• Let's get the core functionality implemented and tested first and in later release we can retrofit and concentrate it on quality...
• Coding standards?! But, I always used to write in this way..
• I have already developed 90% of the feature during the spike itself, it is just matter of promoting it to integration...
• We discussed this during code review, but since functionality was working we just avoided to touch the code..
• I was in hurry...
• What difference does it make anyways?
• This piece of code doesn't need to follow the framework, it is a "different" functionality...

Sounds familiar...? Yes, I too have come across this and may other so called "genuine" reasons when I see some features getting dragged for iterations or even PIs (Program Increments) together. Unfortunate, but true.

Now how do we address this? Simple, by educating them on basics, be it "software engineering" practice or basics of agile principles.

Here are some questions to ask ourselves or teams on how do we avoid or reduce technical debt -

• Prevention is better than cure... yes, first step is to prevent it from happening or reduce the possibility of it happening it to maximum extent. Gather the team, architect, SMEs etc. and ask them - How to avoid creating technical debt in first place rather than dealing with it at later stage?
• Does the team understand (and have access to - this is funny but I have to mention it explicity) application framework and coding standards?
• Does my team understands the overall architecture of the system as well have fair idea about enterprise architecture? Is team align and following the same architecture?
• Is there anything already developed that can be reused?
• Is my System Architect collaborating with the team?
• Is System Architect aligned with Enterprise architect?
• Was the estimation done by an individual "bright" member or by the team?
• Do I have good DOD (Definition of Done) in place?
• Is team aware of NFRs (Non Functional Requirements)?
• Is team working on too many user stories in parallel?
• What are the software engineering practice that team follows?
• Was the design reviewed by someone else as well?
• Is my code structured and looks simple or complex to understand?
• Am I applying any design pattern thinking?
• Am I learning from past.. say retros, defects etc?

... and list can go on and on and on... Sometime team or the member involved can be bit in hurry or unaware or even lazy and would cut corners; but reducing technical debt is not a matter of choice, it is "responsibility" and we have to inculcate this habit in the team.

Here are some prevention-cum-cure tips:

• Get the entire team involved - Ensure that team has awareness of system and enterprise level architect - and proposed solution is aligned to the same
• Publish coding standards, guidelines to follow
• Ensure that team is collaborating with architect
• Help team identify the strategy - MBSE(Model Based System Engineering) or Set Based?
• If it is getting overwhelming, dedicate iteration(s) to address technical debt
• Encourage collaborative design
• Identify and suggest best software engineering practice
• Help team to develop a strong a clear and DOD for each delivery unit - be it user  Story, Feature or even Epic 
• Look back, refer to retros, defects past discussion and improve. Identify the defect patterns.
• Keep the WIP (Work In Progress) limits low.
• Plan the code/test coverage (TDD-Test Driven Development, BDD-Behavior Driven Development) better
• Level of automation planned and keeping the automation in sync with development
• Effective and frequent code reviews, preferably reviews of small chunks of code rather than taking it up as a last activity once the feature is developed
• Encouraging design pattern thinking
• Clear understanding of NFRs (load, response time, concurrency, security etc.)
• Simplifying the code rather than making it complex and unstructured
• Promote pair programming and share your insights about good and bad code and promote the learning about preventing the technical debt rather than fixing it later. 

There could be many more... and I welcome readers to add them in comments.

As uncle Bob says -

“Go well, not fast. Care about your code. Take the time to do things right. In software, slow and steady wins the race; and speed kills” –Robert C. Martin , president of Object Mentor and agile methods author.

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.

SAFe 4.5

SAFe 4.5 is out! Checkout the new look at: http://www.scaledagileframework.com

Quick visible differences -

• Program Portfolio Mgmt is now Lean Portfolio Mgmt
• Lean budget makes an interesting read!
• Configurable SAFe (FULL, LARGE SOLUTION, PORTFOLIO and ESSENTIAL)
• Could not find VSE, found STE instead, stands for Solution Train Engineer
• Solution Train.. earlier we use to just call it as ART at Value stream
• Continuous delivery Pipeline at Program level with Continuous Exploration, Integration and Deployment
• Special place for SPC... makes "base" for the framework along with implementation roadmap
• Palette is vertical... yes this makes sense
• System Team is on palette but DevOps at Program level

Do you see any other differences?

Now that SAFe is configurable, enterprises will have less "guilt" in answering the question if they are following SAFe "fully" or "partially" as they have more options now (Full, Large solution, Portfolio and Essential)

Fixed Price Agile projects

Now a days, I hear that more and more Agile projects are being offered at fixed price, which client is considering a sort of "Stop-loss" option for them. 
Reason could be anywhere from - technology partners are not able to deliver value on time .... to "stringent" budget constraints.

Here are my thoughts on Fixed Price Agile projects – 

• As a technology partner might not directly go for fixed price, instead observe the rate at which you are delivering value and velocity for 2-3 PIs and consider the “normalized” velocity at which you are delivering value for the fixed pricing. So it is T&M to start with and later switching to FP.

• Another option is fixed price per PI. Technology partner would provide the team(s) say 3-5 teams, with optimal pyramid and that team (fixed team) will continue working in PI over PI to deliver the value. From customer point of view, the price will be fixed (for a team), however customer can reap the benefit over time as the team become more mature and starts increasing their velocity and deliver value. Here time is fixed (per PI), Price is fixed (onsite/offshore blended rate) however scope is what customer defines. This option would work great for customers who is looking for long term tie-ups with a technology partner. (it won’t work in short terms for obvious reasons)

• Have a combination of both fixed and variable price. Clearly define what all services will be offered as FP. E.g. Quality, governance etc. and things that would be offered as T&M.

• Assume a minimum velocity based on your historical data – have a cap on fixed price and then if the technology partner achieve more PI over PI, the technology partner gets incentives or if performance is lower than the minimum it is penalty for the technology partner. For this to happen both the side needs to be mature enough to understand the factors that affects the high/low performance. 

• Have a higher level price limit as well as lower limit – E.g tell the clients the clients that you (as a technology partner) cannot come down lower than this price per team pyramid and at times the cost might serge up to specific high limit because of certain situations/reasons (say more resources, adding few architect/ SME/ specialist to the team to resolve certain issues etc)

• You can also offer fixed price and fixed scope bid, but then it just takes away the gist of being Agile. Agility can be restored by allowing them to come-up with the change request that are based on T&M. So, upto certain level say 10-20% scope variation is allowed (this needs to be really worked out carefully) and beyond that say any scope change over 20% it should be T&M. Many things to consider here.. e.g. how to manage change request, can I spin—off a new work order by bundling n number of change requests. How am I delivering, How my delivery is being measured and I do I report my progress. Ownership of risks/impediments etc.

• Fixed price based on the features category – Critical Value features / Arch features / High Value feature / Moderate features / trivial changes / GUI changes.
For this to work well, technology partner must have very good understanding of the systems they are about to work and there should be clear roadmap (2-3 PIs ahead) of what a portfolio/ART is trying to achieve over time. However as all of us knows that requirements changes quite often, so we should have outline of the requirement and assume the variability(may be limit it to +-15% to 20%) and inherent risks. I would says this would be little uncomfortable contract to have.

Your thoughts and comments are welcome!