Search

Designing Shared-Services Teams in SAFe®️ with Service Trains

Shared services teams always pose peculiar challenges to successful Scaled Agile Framework (SAFe®️) implementations. The nature of their work which is mostly determined by the requests from the other Agile teams on the framework often leads to priority mismanagement, political conflicts and uncontrolled chaos in the system. One of the major issue organizations face is to deal with multiple shared services team under one ART or a solution train.In this article, we present an approach called “Service Train” to facilitate that scenario. Also, this article will help you in managing  the shared service teams in SAFe®️ with service trains.How to design shared services in SAFe®️ with service trainsSAFe®️ aims to scale-up the agility of multiple teams by aligning them to Agile Release Trains (ART), Solution Trains and Portfolios. Multiple teams deliver in cadence, the results committed to, at various layers viz., Team, Program, Solution and Portfolio. (Refer to the SAFe site  for more information)                                                                                         Scaled Agile Framework (Source: scaledagileframework.com)Tips for shared services Design in SAFe®️ with service trainsThings get trickier when multiple Agile teams started using service trains in SAFe®️ at shared services and Team request the services to the shared services teams. SAFe®️recommends the operation of the shared services of teams at the ART level but it gets difficult to facilitate them when those teams tend to grow big in numbers.The simple idea of having all of them at the program level leads to chaos and confusion at times. For example- imagine a team of 30 people trying to help the other teams out. Moreover, when the members of those teams are not generalists, then organizing them by skills would get problematic too.One workable solution to this problem is to organize all the shared-services teams into a “Service Train” which is similar to the ART but acts as a service pipeline to one or more ARTs. It spreads across multiple ARTs and Solution Trains providing requested services. The teams on this service train may be Scrum or Kanban teams adhering to the SAFe principles and implementing its practices.While implementing shared service teams in SAFe®️ with service trains, the service teams run their usual cadences (recommended to sync with the ART cadences) and they deliver services to the ARTs continuously on demand. The ART delivery pipelines tie up these deliverables to their own during the continuous integration activities and deliver solutions to the Stakeholders.The service train differs from an ART in the following ways:The PI's on the service trains are optional. The teams may opt for sprint to sprint ( Or cadence to cadence ) planning on the Service train. In such cases, all the teams plan the sprints/cadences together.There may not be a dedicated “Train Engineer”. The role could be rotating or replaced by a team of facilitators.The backlogs of the service teams are generated by the requests of the teams on the ART.The metrics on the train are in the context of the metrics of corresponding ARTs.Their program board may be linked to one or more program boards of the ARTs.The service trains come in as valuable constructs as:They eliminate the chaos-generating out of having too many service team members at the program levelCross-functional teams may be formed around dedicated service areas, so the Agile teams know where to place the requestsThe trains can deliver services to multiple ARTs at the same time - in other words, they are not constrained by the ARTs (Or the Solution trains)However, there are a few things to watch out for:1. Some traditional leaders may use this as an opportunity to impose the “Matrix Structure” on the teams and misuse this design as a way to break cross-functional teams.2. There is a scope of the service teams getting siloed, resulting in poor collaboration3. The service train may become a bottleneck to the ARTs, if it doesn’t run slightly ahead of their schedules.Skills needed for Shared servicesThe team members of Shared services need to grasps the following type of specialized skills:Agile and Software/Systems Engineering CoachesApplication/web portal managementConfiguration managementData modeling, data engineering, and database supportDesktop supportEnd-user trainingEnterprise architectureInformation architectureInfrastructure and tools managementInternationalization and localization supportIT Service Management and deployment operationsSecurity specialist (InfoSec)System QA and exploratory testingTechnical WritersRoles and Responsibilities in Shared servicesThe shared services employees handle the following roles and responsibilities.Participates more actively in Program Increment (PI) planning and pre- and post-PI planning as well.Managing the requirements wherever needed, adding to the backlog and taking ownership of that particular task.Collaborating with the Agile teams to achieve the Program Increment execution dependencies.Actively taking part in the Inspect and Adapt(I&A) workshops, System demos, and Solution demos when any improvement backlog items show challenges with the availability of specialized skills and dependencies on the team.  Generally, the team members of Shared services choose to work as a single team. In such case, the team members iterate on the same cadence because the Agile Release Train (ARTs) work like any other Agile team.ConclusionAgile teams need the support of either sustained or transitional specialty expertise. The staff of Shared services might become a part of an Agile team for the shorter duration. During this period, the staff of Shared services not only experience the Agile dynamic but also understands the speed of the development and the quality of the product. It also allows a knowledge transfer decreasing a dependency on specialized skills.
Designing Shared-Services Teams in SAFe®️ with Service Trains
Bhardwaj
Rated 4.0/5 based on 2 customer reviews

Designing Shared-Services Teams in SAFe®️ with Service Trains

Shared services teams always pose peculiar challenges to successful Scaled Agile Framework (SAFe®️) implementations. The nature of their work which is mostly determined by the requests from the other Agile teams on the framework often leads to priority mismanagement, political conflicts and uncontrolled chaos in the system. One of the major issue organizations face is to deal with multiple shared services team under one ART or a solution train.In this article, we present an approach called “Service Train” to facilitate that scenario. Also, this article will help you in managing  the shared service teams in SAFe®️ with service trains.How to design shared services in SAFe®️ with service trainsSAFe®️ aims to scale-up the agility of multiple teams by aligning them to Agile Release Trains (ART), Solution Trains and Portfolios. Multiple teams deliver in cadence, the results committed to, at various layers viz., Team, Program, Solution and Portfolio. (Refer to the SAFe site  for more information)                                                                                         Scaled Agile Framework (Source: scaledagileframework.com)Tips for shared services Design in SAFe®️ with service trainsThings get trickier when multiple Agile teams started using service trains in SAFe®️ at shared services and Team request the services to the shared services teams. SAFe®️recommends the operation of the shared services of teams at the ART level but it gets difficult to facilitate them when those teams tend to grow big in numbers.The simple idea of having all of them at the program level leads to chaos and confusion at times. For example- imagine a team of 30 people trying to help the other teams out. Moreover, when the members of those teams are not generalists, then organizing them by skills would get problematic too.One workable solution to this problem is to organize all the shared-services teams into a “Service Train” which is similar to the ART but acts as a service pipeline to one or more ARTs. It spreads across multiple ARTs and Solution Trains providing requested services. The teams on this service train may be Scrum or Kanban teams adhering to the SAFe principles and implementing its practices.While implementing shared service teams in SAFe®️ with service trains, the service teams run their usual cadences (recommended to sync with the ART cadences) and they deliver services to the ARTs continuously on demand. The ART delivery pipelines tie up these deliverables to their own during the continuous integration activities and deliver solutions to the Stakeholders.The service train differs from an ART in the following ways:The PI's on the service trains are optional. The teams may opt for sprint to sprint ( Or cadence to cadence ) planning on the Service train. In such cases, all the teams plan the sprints/cadences together.There may not be a dedicated “Train Engineer”. The role could be rotating or replaced by a team of facilitators.The backlogs of the service teams are generated by the requests of the teams on the ART.The metrics on the train are in the context of the metrics of corresponding ARTs.Their program board may be linked to one or more program boards of the ARTs.The service trains come in as valuable constructs as:They eliminate the chaos-generating out of having too many service team members at the program levelCross-functional teams may be formed around dedicated service areas, so the Agile teams know where to place the requestsThe trains can deliver services to multiple ARTs at the same time - in other words, they are not constrained by the ARTs (Or the Solution trains)However, there are a few things to watch out for:1. Some traditional leaders may use this as an opportunity to impose the “Matrix Structure” on the teams and misuse this design as a way to break cross-functional teams.2. There is a scope of the service teams getting siloed, resulting in poor collaboration3. The service train may become a bottleneck to the ARTs, if it doesn’t run slightly ahead of their schedules.Skills needed for Shared servicesThe team members of Shared services need to grasps the following type of specialized skills:Agile and Software/Systems Engineering CoachesApplication/web portal managementConfiguration managementData modeling, data engineering, and database supportDesktop supportEnd-user trainingEnterprise architectureInformation architectureInfrastructure and tools managementInternationalization and localization supportIT Service Management and deployment operationsSecurity specialist (InfoSec)System QA and exploratory testingTechnical WritersRoles and Responsibilities in Shared servicesThe shared services employees handle the following roles and responsibilities.Participates more actively in Program Increment (PI) planning and pre- and post-PI planning as well.Managing the requirements wherever needed, adding to the backlog and taking ownership of that particular task.Collaborating with the Agile teams to achieve the Program Increment execution dependencies.Actively taking part in the Inspect and Adapt(I&A) workshops, System demos, and Solution demos when any improvement backlog items show challenges with the availability of specialized skills and dependencies on the team.  Generally, the team members of Shared services choose to work as a single team. In such case, the team members iterate on the same cadence because the Agile Release Train (ARTs) work like any other Agile team.ConclusionAgile teams need the support of either sustained or transitional specialty expertise. The staff of Shared services might become a part of an Agile team for the shorter duration. During this period, the staff of Shared services not only experience the Agile dynamic but also understands the speed of the development and the quality of the product. It also allows a knowledge transfer decreasing a dependency on specialized skills.
Rated 4.0/5 based on 2 customer reviews
Designing Shared-Services Teams in SAFe®️ with ...

Shared services teams always pose peculiar challen... Read More

Does Scrum Apply To All Types Of Projects?

Scrum, undoubtedly, is one of the potentially viable approaches to managing software development projects. Scrum is just a development methodology which delineates the processes and practices that help in managing software development activities.However, before adopting any methodology one should ask these questions -Is the use of Scrum being forced upon you to fit into the project?Has the research been done to predict its success rate?Have you analyzed the risks associated with this adoption?What types of projects fall into the purview of Scrum framework?I worked in the IT industry for 9+ years on a wide variety of projects where the success rate of Scrum was very high. Hence, I got the impression that it works for all types of projects. Here is my experience with one of the projects that threw away all my misconceptions about Scrum and changed my opinion.My team worked on a huge, multi-dimensional project, that included distributed teams.Multiple versions of the product were already out in the market and customer satisfaction was running high. Then we decided to switch to Scrum for this particular project. As the software product was already out in the market, customer issues and complaints piled up that were assigned a priority level in order to be resolved.The team working on the newer version was also required to support the older versions as a part of the contract with the customer.  Therefore, the same team is working on new versions of the product including enhancements and new features while also addressing the customer issues and bug fixes for the older version of the software.Now, since the product owner had already groomed the backlog for the software release, whenever any new issue from the earlier versions was raised by the customer, we took them on priority. This leads to these issues being constantly added in the midst of the sprint to the backlog and the whole team started working on the issue, leaving their current work behind.As a result of these mid-Sprint changes-All of a sudden, team had to shift their focus.No planning was done for this issue while grooming.Unplanned work being added to the backlogDelay in creating and delivering current project deliverables.Then comes the conundrum -Are we really using Scrum the right way? Is our project really getting any benefit by using Scrum?The answer is probably NOT. But the management still wouldn’t agree and will continue to force the use of Scrum for this project.Now, let us discuss the below scenarios.1) Sometimes there were too many issues from the earlier versions but the other times too few issues (but of high priority) were thereIn these cases, we need to immediately switch our focus to a high-priority issue and provide a possible solution to the customer as early as possible. The current sprint needs to be cancelled and pending tasks need to be transferred to the next sprint.2) Sometimes no issues at all.Continue the sprint.3) Sometimes issues need to be addressed but the current project is also in a critical stage.An example is the build failure of the current project and where testers weren’t able to continue the testing. This becomes a critical condition for any project which needs to be addressed and planned for.Because of this critical situation, management switched its stance and agreed to abandon Scrum for this project as it stalled both the projects and instead used the waterfall model.Few suggestions to avoid this scenario -Make two separate teams - one for handling the issues of earlier versions and one for the current project sprintsSlowly and steadily we should stop giving the support to the earlier versions (End of life) and this should be clearly communicated to the customer in advance so that they can also prepare themselves. It should be coded in the contract at the time of signing. However, this is not always possible due to complex nature of projects that run big manufacturing and production plants which may adversely affect their productivity/throughput.The above two solutions can be addressed in the following ways:Plan and allocate budget to provide support to the earlier versions of the product instead of hiring the new team. In case of no issues, the team can continue to work on the current project.For such projects, Scrum and Kanban both methodologies should be used.Conclusion:In my opinion, before adopting any methodology we should always deep dive into it and understand its success rate in different scenarios of the project. We should not impose any methodology on any project by giving justification that it is already used by other projects.Also, start off with small (maybe internal) projects having few sprints and few team members just to predict the success rate of the methodologies and frameworks.“It’s better to fail first than at the end”.So, for the projects where there is high unpredictability (don’t know when new tasks will come), chances are there that Scrum may not work; so it is better to use Kanban in those situations.Inappropriate application of Scrum can lead to its doom – Scrum is not a prescriptive method, but a suggestive approach to software development. So, the way it is implemented makes all the difference.
Rated 4.5/5 based on 0 customer reviews
Does Scrum Apply To All Types Of Projects?

Scrum, undoubtedly, is one of the potentially viab... Read More

Delivering Messages Made Easy With Azure Service Bus

Integrating two different systems is often complicated and comes up with lots of challenges with respect to the availability of both systems, processing speed, scaling and many more. Amongst many recommendations for designing and developing applications for the cloud, enabling asynchronous communication between multiple services plays a vital role in achieving the reliability, scalability and the efficiency of the system.What are Message Queues?Message Queues is the solution to the challenges faced during Integration in distributed systems. It is an efficient way of enabling asynchronous communications between different software services.Following are three most important benefits Queuing solution comes with:1. Decoupling: Messaging queues provide a persistent storage and asynchronous communication and thus the availability of one service does not impact the another. They are eligible to work in a disconnected fashion.2. High reliability: Messaging queues use transactions to manage the message and help to roll back the transaction to recover the message, In case of a failure.3. Granular Scalability – Messaging queues helps to achieve granular scalability where the producer or consumer can scale on their own choice without even impacting the other.Azure Service Bus – A managed Queuing system on Azure CloudAzure Service bus is a highly scalable service that helps to achieve asynchronous messaging and exchanging data among decoupled systems. Moreover, since it is a Platform as a Service (PaaS) offering from Microsoft, thus, you don’t have to manage the Infrastructure and configuration. Azure cloud manages all this for you.Among all others, the most important feature of Azure Service Bus queue is that it guarantees messages to be delivered in FIFO order, which many other queuing solutions fail to provide, even Azure Storage Queues. This makes service bus the most suitable choice than any other Message Queues, though not the only choice. However, Other features to include high availability, auditing, Geo redundancy etc.Azure Service Bus has 3 offerings:1. Queues2. Topics and Subscriptions3. Relays1. Service Bus Queues:The queue is an optimum choice when we are implementing one-directional messaging and, we want to ensure that only one consumer can fetch the message. This is generally used when both the producer and the consumer are not online at the same point in time. All the messages sent by the producer are stored in the queue until consumed by the consumer or gets expired. Also, each message in the queue is identified by a unique Message-ID.Queues come with the assumption that the message needs to be consumed by only one service. However, in practical scenarios, one message might need to be delivered to multiple consumers on some business decisions or need to be broadcasted. To meet those requirements Service bus does have a different offering, Topics.2. Topics and Subscriptions:Topics also provide one-directional communication. However, it works on the publish-subscribe principle where the same message can be consumed by more than one consumer. A single topic may have multiple subscriptions associated with it. A Subscription is somewhat like Queue. When the topic receives the message, it delivers it to all the relevant subscriptions or distributes based on the subscription filters.3. Relays:Unlike Queues and Topics, Relays provides more sort of bi-directional communication. Relays do not support brokered messaging i.e. they don’t store any messages instead simply passes the message from one service to the other. Therefore, both the publisher and subscriber need to be active at the same point in time in case of relays. Relays are automatically created and deleted in a service bus namespace i.e. they need not be created beforehand and deleted post use by services.Azure Service Bus ArchitectureThe Azure Service Bus architecture is depicted in the figure below:Some Important Limits and QuotasAdvanced Features of Azure Service BusAzure Service Bus also has some advanced features that can help you to solve most complex messaging problems. The key features are listed below:1. Dead LetteringService bus provides dead letter subqueue to store messages that could not be delivered or processed. Dead letter queues can be used to move expired or poisoned messages from the parent queue. Those messages then can be retrieved for further investigations. Dead letter queues need not be created manually but are automatically created with the queue.2. TransactionsService bus provides transactions to group multiple operations together into one execution scope. This ensures that all the operations within a group either succeed or fail together.3. Duplicate detectionEnabling Duplicate detection helps to identify duplicate messages added on the basis of the unique message id. The duplicate message could be added by an application on restart of unexpected failure or exception scenarios not handled. Such messages need not be handled manually by the application because the service bus automatically handles those messages.4. Batch processingBatch processing feature of Azure service bus helps to add and retrieve messages in batch instead of one by one message. This extends help to the systems that have to process bulk messages.5. SessionsSometimes the messages are bigger in size say more than 1 MB (maximum message size capacity of queues). Sessions help in such scenarios by sending the message in parts and allowing the processing of the same only when all the parts are received at the consumer end.SummaryMicrosoft’s PaaS offering, Azure Service Bus is really helpful in developing and implementing highly scalable services without even care about infrastructure. It provides asynchronous communication and ensures greater reliability.Azure also lets you select from different options in service bus - for brokered and one directional message we have Queues and Topics and for non-persistent and bi-directional messages we have Relays.
Rated 4.0/5 based on 2 customer reviews
Delivering Messages Made Easy With Azure Service B...

Integrating two different systems is often complic... Read More