Search

The Required ‘Cultural Transition’ For Agile-Scrum Teams

"It is not the strongest of the species that survives, nor the most intelligent. But it is the one who is most adaptable to change" - Charles DarwinTechnology today is evolving rapidly at an exponential rate. Business entities in order to survive and thrive must adopt and adapt to technological advancements at a rapid rate. The dwindling profit margins, the shrinking in time to market, globalization, and the technological advancement of competitors mandate organizations to innovate put out their products and services as soon as possible.Software project management has evolved rapidly over the last few years. Organizations large and small alike are rapidly transitioning into using Agile software development and engineering frameworks resulting in technology advancement at an exponentially rapid pace. The struggle of adopting and adapting to Agile delivery for organizations and teams alike is well understood and documented. The culture of the organization and the team plays an important role to facilitate this agile adoption.The effects of globalization and technology have a direct impact on the Software Development Industry as well. Software project management too has evolved rapidly over the last few years to cater to this change. Organizations large and small alike are transitioning into using change-driven software development and engineering frameworks rather than sticking with plan-driven software project management approaches.However, the struggle of adapting to Agile practices is a universal problem and this may the case for years to come. An area of difficulty in terms of this adaptation to agility is organization and team culture. Today, through this article we will look at the culture of traditional plan-driven software development organizations and then the requirement of culture for change-driven Agile Software Development organizations.Culture as an enablerCulture is often defined as ‘the way things work around here’.  Schein (1980) defines culture as the pattern of basic assumptions that a group learns, or which is taught to new members as the correct way to perceive, feel and think in relation to situations they encounter. Many organizations do similar activities, but no two organizations do activities or tasks in the exact same way as the other, and no two organizations feel the same.Transformation into an Agile team should first happen at an organization level that they can be cascaded down to the team level. It is the senior leadership’s responsibility (owners and CXO’s) to embrace agility, and then to create the corporate values, beliefs, behaviors, and practices necessary to activate this culture. Scrum masters as the Agile leadership of the organization must understand this corporate culture and then adapt the same to teams as necessary. Schein defines the culture at 3 levels.Level 1: Artifacts or the visible features, which reflects the culture (roles and people, symbols, narratives, activities etc.)Level 2: Beliefs and values which the organization and the scrum team (leadership, integrity, trust, etc.)Level 3: The deepest and most important level which consists of assumptions which shape level 2 and level 1 elements listed above.The Agile leadership is responsible for creating and communicating cultural elements at all 3 levels to team members so that they understand, embrace and develop the Agile culture.The transition in Agile cultureBelow is a depiction of 4 basic types of culture as defined by Handy (1999).Traditionally software development organizations followed plan-driven SDLC approaches to develop and deliver solutions. The Power and Role cultures were evidently visible in these sort organizations. The power in terms of initiating a project, deciding on the resource requirements, deciding on the budget and deciding on the scope was with a few key individuals within the organization. Role of the customer account manager, project manager and the other project roles such as developer, business analyst, QA engineer was clearly defined. If any information was required or if a client demonstration was to be carried out the team had to wait for a considerable period of time to communicate, take necessary approvals and to implement the same. These organizations and teams inherently had the problems of role conflicts, contradicting priorities, miscommunication and slow decision making which ultimately resulted in delayed low-quality projects.The task and person cultures are more suitable for Scrum projects. Yes, the scrum master, product owner, and implementation team roles and the communication lines defined properly for an Agile project to run smoothly. But the team must be self-organizing to identify tasks to perform in order to create and deliver value to the relevant stakeholders. Each team member must be a cross-functional team player capable of fitting into any role and perform any task as required to deliver the solution. The scrum master must facilitate discussion within and across multiple teams and stakeholders as deemed fit to remove impediments and move the project forward. Team and individual success must be celebrated along with the achievement of common project objectives.For more information on types of culture please watch the video through below link.ConclusionAgile requires a paradigm shift, which is more specifically a shift in the culture of management to leadership. This must come from the top down and be embedded in corporate strategy. Harmonious dissemination of this information to all relevant stakeholders both internal and external will ensure the success of Agile projects.
The Required ‘Cultural Transition’ For Agile-Scrum Teams
Rumesh
Rated 4.5/5 based on 2 customer reviews

The Required ‘Cultural Transition’ For Agile-Scrum Teams

"It is not the strongest of the species that survives, nor the most intelligent. But it is the one who is most adaptable to change" - Charles DarwinTechnology today is evolving rapidly at an exponential rate. Business entities in order to survive and thrive must adopt and adapt to technological advancements at a rapid rate. The dwindling profit margins, the shrinking in time to market, globalization, and the technological advancement of competitors mandate organizations to innovate put out their products and services as soon as possible.Software project management has evolved rapidly over the last few years. Organizations large and small alike are rapidly transitioning into using Agile software development and engineering frameworks resulting in technology advancement at an exponentially rapid pace. The struggle of adopting and adapting to Agile delivery for organizations and teams alike is well understood and documented. The culture of the organization and the team plays an important role to facilitate this agile adoption.The effects of globalization and technology have a direct impact on the Software Development Industry as well. Software project management too has evolved rapidly over the last few years to cater to this change. Organizations large and small alike are transitioning into using change-driven software development and engineering frameworks rather than sticking with plan-driven software project management approaches.However, the struggle of adapting to Agile practices is a universal problem and this may the case for years to come. An area of difficulty in terms of this adaptation to agility is organization and team culture. Today, through this article we will look at the culture of traditional plan-driven software development organizations and then the requirement of culture for change-driven Agile Software Development organizations.Culture as an enablerCulture is often defined as ‘the way things work around here’.  Schein (1980) defines culture as the pattern of basic assumptions that a group learns, or which is taught to new members as the correct way to perceive, feel and think in relation to situations they encounter. Many organizations do similar activities, but no two organizations do activities or tasks in the exact same way as the other, and no two organizations feel the same.Transformation into an Agile team should first happen at an organization level that they can be cascaded down to the team level. It is the senior leadership’s responsibility (owners and CXO’s) to embrace agility, and then to create the corporate values, beliefs, behaviors, and practices necessary to activate this culture. Scrum masters as the Agile leadership of the organization must understand this corporate culture and then adapt the same to teams as necessary. Schein defines the culture at 3 levels.Level 1: Artifacts or the visible features, which reflects the culture (roles and people, symbols, narratives, activities etc.)Level 2: Beliefs and values which the organization and the scrum team (leadership, integrity, trust, etc.)Level 3: The deepest and most important level which consists of assumptions which shape level 2 and level 1 elements listed above.The Agile leadership is responsible for creating and communicating cultural elements at all 3 levels to team members so that they understand, embrace and develop the Agile culture.The transition in Agile cultureBelow is a depiction of 4 basic types of culture as defined by Handy (1999).Traditionally software development organizations followed plan-driven SDLC approaches to develop and deliver solutions. The Power and Role cultures were evidently visible in these sort organizations. The power in terms of initiating a project, deciding on the resource requirements, deciding on the budget and deciding on the scope was with a few key individuals within the organization. Role of the customer account manager, project manager and the other project roles such as developer, business analyst, QA engineer was clearly defined. If any information was required or if a client demonstration was to be carried out the team had to wait for a considerable period of time to communicate, take necessary approvals and to implement the same. These organizations and teams inherently had the problems of role conflicts, contradicting priorities, miscommunication and slow decision making which ultimately resulted in delayed low-quality projects.The task and person cultures are more suitable for Scrum projects. Yes, the scrum master, product owner, and implementation team roles and the communication lines defined properly for an Agile project to run smoothly. But the team must be self-organizing to identify tasks to perform in order to create and deliver value to the relevant stakeholders. Each team member must be a cross-functional team player capable of fitting into any role and perform any task as required to deliver the solution. The scrum master must facilitate discussion within and across multiple teams and stakeholders as deemed fit to remove impediments and move the project forward. Team and individual success must be celebrated along with the achievement of common project objectives.For more information on types of culture please watch the video through below link.ConclusionAgile requires a paradigm shift, which is more specifically a shift in the culture of management to leadership. This must come from the top down and be embedded in corporate strategy. Harmonious dissemination of this information to all relevant stakeholders both internal and external will ensure the success of Agile projects.
Rated 4.5/5 based on 2 customer reviews
The Required ‘Cultural Transition’ For Agile-S...

"It is not the strongest of the species that survi... Read More

5 Hurdles that Scrum Masters Commonly Face

Agile has gained a significant track and has been adopted by all organizations. Agile Methodology today has become one of the most popular and most dynamic project management styles among the software development teams. And Agile is also being adopted by various other functions. It is important to note that Agile can be applied to many types of teams and projects and should not be thought of as limited to engineers or software development projects only.We run all our software delivery through an Agile methodology called Scrum. Scrum is well-recognized amongst engineering teams, but a variety of teams across industries have come to love the Scrum way. From manufacturing to operations and education, businesses of all kinds have used Scrum practices and successfully. As long as your projects involve a concrete product, Scrum can work for you. We have been using Scrum for last few years and have some great success with it. But, still the Team come across various common Scrum Pitfalls.Many organizations are adopting Agile and Scrum for producing higher quality products and services.As per the statistics are given by PwC, “Agile projects are 28% more successful than traditional projects.”Almost three-quarters (71%) of organizations report using Agile approaches sometimes, often, or always. (source: capterra)So why not,Organizations are hiring Scrum Masters for implementing Scrum Framework. It’s a sole responsibility of a Scrum Master to make sure it’s fully implemented and followed by the team in an organization.Scrum is easy to understand but hard to implementWho is a Scrum Master?The Scrum Master is a champion for a Scrum team. He coaches the team, the product owner, and the business. The Scrum Master is a multitasker were deeply understands the work being done by the team, motivates the team and makes sure that the teams are following the Scrum processes and will also work together with them to continuously improve them.How important is a Scrum Master?Scrum Master also ranks on the top of the hierarchy on most of the Agile or Scrum Process, with an eye towards a better understanding of role and importance, here is a closer look at the Scrum Master roles. 1. Scrum Master plays a vital role in the success of the project, he serves as a glue that can hold the entire project.2. Scrum Master may not participate in daily Scrum meetings but supports the entire team.3.  Scrum Master helps in strengthening the Agile development team4.  Scrum Master facilitates team meetings, which also includes Daily Stand-up5.  Scrum Master aims to deliver the maximum value to the customer.Let’s have a look at the 5 hurdles that Scrum Master commonly face:1. Managing Role ExpectationsMany organizations, as well as the upper management, confuses the role of the Scrum Master with a Project Manager. However, the most important thing that we all should know is that the Scrum Master is a Scrum facilitator for a team as well as an organization.However, sometimes management expectations are different, which makes the life of a Scrum Master little harder. We all need to understand that Scrum Master is a facilitator, a guide, a process follower and most importantly, a Servant Leader.2. Change ResistanceAs per Mike Cohn, it is the social aspect of change that can create resistance, all resistance comes from specific individuals. Teams or departments do not resist changing to Scrum, Individuals do.So, when we talk about Scrum implementations, the Scrum Master is the change agent for the same. It’s a major hurdle faced by a Scrum Master during the implementation. Change Resistance is not a surprise, it’s the most expected reaction whenever a new change is introduced.                                                      Tip: Choose a length of the Sprints in such a way that it can resist change.There are many ways for adopting Scrum patterns and overcoming change resistance. You will get that Scrum adopting patterns in my previous article- Patterns For Adopting & Spreading Scrum In Organizations.3. Keeping everything Time-Boxed        When we talk about implementing Sprints, every event is supposed to be time-boxed in order to get productive results. For example, the Daily Scrum event should not exceed 15 minutes, but in reality, we see team members start discussing their technical difficulties and the meeting goes longer than the allotted time. It’s one of the most common challenges for any Scrum Master.Well, a funny thing to try to overcome this hurdle is to make the team members stand for 15 minutes. Hide all the chairs! They will eventually get tired and finish up the meeting.4. Handling Urgent Change RequestsScrum Masters follow the rule when implementing Scrum which is to never accept changes within the Sprint. We can handle the change requests at the end of the sprint or at the start of the Sprint but not in between. However, in a practical world, we see Product Owners/Customers/Stakeholders coming up with an urgent change requests or bugs.However, it’s also not good to blindly follow the process without understanding the business and market aspects. It’s always better to communicate, collaborate with all the Stakeholders, replan and then make good decisions.5. Distributed TeamsIt is one of the most common barriers faced by a Scrum Master. When the teams are distributed geographically, there are sometimes delays, network issues, cultural or regional issues, different Time Zones, different working hours, it is always difficult to get everyone connected and collaborate/communicate with everyone.Thanks to all the technologies, applications out there that help us overcome this hurdle whether it’s communication, video conferencing, there are many tools available.Scrum Master also come across the following challenges:1. Scrum Master acts as an admin:Basically, Scrum Master tasks start with booking meetings, scheduling events, taking notes, and inviting people to ceremonies. All these may be the primary function of the Scrum Master and these deals with making the team be effective. The tasks involve various challenges.2. Lack of Agile training for the teams:As the Scrum Master is meant for the team, it’s a responsibility to make sure all your team members have foundational Agile training. This is one of the most problem faced by Scrum Master.To summarize, I would say, these are the just the “Hurdles” commonly faced by Scrum Masters but not the “Blockages”. These obstacles can be jumped over, with good skills, expertise and, experience in Scrum implementations. Keep Learning!
Rated 4.0/5 based on 2 customer reviews
5 Hurdles that Scrum Masters Commonly Face

Agile has gained a significant track and has been ... Read More

Decision About Which Agile Method To Use - A Perspective

Introduction:Agile methods have gained widespread acceptance in software development organizations for formulation and development of solutions for enhancing existing products or creating new ones. The method has been very effective in the continuous delivery of new and effective solutions.Organizations trying to introduce Agile methodologies, in the beginning, are faced with a choice of which type of Agile methodology is best suited for their environment and types of project work. You may learn more about the challenges encountered by the first-time Agile organizations here.The Agile Manifesto favors the delivery of working software in comparison to comprehensive documentation. There is a constant emphasis on a relation between organization and developers rooted in-Trust,Integrity, andTransparency.It may not be a huge shift, but is still a powerful challenge for many companies. The team should be trained well, should be aware of Agile concepts and should have the required tools needed to perform. A team of experienced and skilled developers is more efficient to take decisions when compared to a less experienced team and understands customer commitment much better. Agile delivery values direct interaction and business user collaboration instead of uneven communication in the life cycle  at fixed points. Effective involvement of the  business reduces the delivered features risk that do not meet customer requirements.How to decide the best Agile methodology that is suitable for an organization?Despite the fact that every Agile methodology offers incremental and iterative delivery of software, the differences lie in the way artifacts produced and each methodology is executed.Let us discuss in detail the most popular Agile Methodologies:Scrum: Scrum is focused on self-organizing teams. Its core principles are aligned with client-driven adaptive planning. Scrum method’s main priority is the delivery of working software in no more than 30 days. Delivered software needs to be in releasable shape.Minimum documentation is supported. Scrum is most used in the Agile framework. Its widespread usage and benefits have made it the most popular Agile method.Extreme Programming(XP): It keeps things simple and concentrates on the continuous implementation of best practices such as-Ongoing testingRefactoringCode reviews (pair programming)Continuous integration.In this method, there is a focus on the developer’s capability and getting into the development of the working prototype as fast as possible.Feature Driven Development (FDD): Breaks down the delivery of a larger product into small features. Typically, FDD is characterised by-Short iteration cyclesSimple processesSuitability for predictable evolutionThe method needs experienced resources to define the required features in great details to make them implementable.Kanban: It is based on Toyota’s just-in-time (JIT) production system. The salient features are as follows-Focuses on eliminating bottlenecksIncredibly simple and powerful Kanban boardsKanban uses Flow and visual methods to bring elements of agile in the overall development process.Makes elaborate use of visual tools.Typical usage involves a space in the office area with printed boards showing status of the activities as shown in the diagram below.Lean Development: Lean Development concentrates on offering value for money. It recommends amplifying learning, avoiding unnecessary errors, delivering as early as possible and deciding as late as possible. The first and foremost principle of lean project management is diminishing waste in an established process. It is more frequently applied to production and manufacturing than in product development. Lean mainly focuses on key process improvement points, such as standardizing means of production and reducing bottlenecks. Although Lean has a different application than the Agile methodology, there are certain common elements such as-Valuing a strong facilitator andPipeliningDSDM: It is developed from a business perspective and lays a strong emphasis on project management. The plans produce based on increments.Sometimes, a combination of multiple methods is the best solution. For example, a combination of Scrum and Kanban is a preferred combination for projects that need the iterative approach of Scrum and the visual elements of Kanban. Similarly, pair programming aspects of Extreme programming (XP) are borrowed for Scrum development teams. It is also advisable that, Agile is not a suitable methodology for some projects. This also should be kept in mind while evaluating an appropriate Agile methodology.In Summary:Agile method to be used for an organization depends on the objectives and desired outcomes. The methods can be implemented either in an existing program or for a new one. Current state and resources available will be of prime importance in deciding the approach and the timeline of implementation. It has been proven time and again that Agile methodologies help an organization to improve the speed of product delivery and quality. They also help establish clear communication channels within the organization and with critical customers and have an approach and method to incorporate customer feedback quickly in the product roadmap.
Rated 4.0/5 based on 0 customer reviews
Decision About Which Agile Method To Use - A Persp...

Introduction:Agile methods have gained widespread ... Read More

Deliver High Business Value With Agile Opportunity Canvas

I would like to start this blog with a question. Business case, quite commonly used term in Project Management. Do we agree?It is a document explaining the justification for a project and expected outcome. Let us have a look at Project, Program and Portfolio Management in the image below.Every single initiative or project within an Organization is aligned to Organizational strategy.In an Enterprise level, we tend to see a lot of ideas and requests emerging from stakeholders, clients, internal teams, outcomes of market research. These ideas and requests will convert into a Project, if we see a potential opportunity. In traditional approach or Agile approach, every idea or request should be validated to ensure the right investment is made. Agile is a widely used terminology in IT industry. People often stumble upon understanding Agile and Lean. Lean Methodologies focuses more on value, elimination of waste and delivering the product in small batches. Agile is a subset of Lean thinking. Agile movement was formed in 2001, Outcome of which is Agile Manifesto and 12 Principles for Agile Software development. Agile is an umbrella term covering different methods and frameworks such as Scrum, Scrumban, XP, FDD etc. All Agile approaches/frameworks emphasizes more on Agile Manifesto and 12 Principles.Agile Model:Demand Management in Traditional Approach/Waterfall model: In the traditional approach, a project is selected over another project through Project evaluation tools such as Cost-Benefit analysis, Decision Matrix etc. A project charter will be created during the initiation phase of the project which captures business case, high-level requirements, timeline/milestone, risks, costs and other constraints. A detailed scope in the form of "Statement of Work" is approved during the planning phase. Planning is one time in a Waterfall model and will take a considerable amount of time in the project. Scope(Feature) is Fixed, Time and Cost is flexible in Traditional approach. Any changes to the scope will be difficult to handle in Waterfall model. There are a lot of risks involved in Traditional approach, as planning is one time.                                                                                                       Fig: Iron triangle- Traditional Approach Demand Management in Agile Approach: In the Agile approach, planning is continuous. Planning is done at different stages. This reduces risks.Strategic PlanningPortfolio PlanningProduct PlanningRelease Planning – Quarterly by entire teamIteration Planning – Bi-Weekly by entire teamDaily Planning – Daily by entire teamFrequency and required participants for Strategic, Portfolio and Product planning will differ across organizations.                                                                                                         Fig: Agile Estimating and Planning In the Agile approach, Feature remains flexible, Time and cost are fixed. Agile approach is incremental and iterative in nature. In the Agile approach, we do not have a detailed scope slated during the start of the project. As we evolve during the development phase, there might be new features or enhancements identified by the customers.                                                                                                          Fig: Iron triangle- Agile Approach In Agile Demand Management Cycle, an idea/requirement/enhancement is chartered in an Opportunity Canvas which gets reviewed by Investment cabinet. As per agile manifesto # 3- Customer collaboration over contract negotiation and Agile Principle # 1: Satisfying the customer is of highest priority: "Agile opportunity canvas" creates more visibility to the customer and the product owner to prioritize new requirements or enhancements over others. (Enhancements which needs a development effort of minimum 2 months would be considered to be chartered in an Agile opportunity canvas). Demand Management process is followed in both Traditional and Agile approaches. In Traditional approach, since the scope is clear it will be a one-time activity. But in Agile, as we do Rolling wave planning on shorter time span to deliver customer value, we would need a robust demand management process to ensure the right requirements were approved and investment is made for right product or feature.                                                                                              Fig: Opportunity Canvas & Demand Management Agile Opportunity Canvas: Agile Opportunity Canvas also referred to as Agile Project Charter is used to ensure whether the business value is captured in the right format, which gives visibility to higher management and decision makers to ensure the investment is made to the right effort. An opportunity canvas is similar to a lean business case. It will help us capture the essential fields. Drafted opportunity canvas will move through the approval process before any project work is initiated. Sample Agile Project Charter template:There are different elements in an Agile Project Charter. These elements are customized according to the Organizational needs.  Opportunity Canvas is a living document and it should be in One page.In a nutshell, we should have the required elements populated to move it across the Demand Management. Generic elements to be part of the Opportunity canvas are listed below:Current Problem Statement – Why do we need to implement this idea? What is the Problem statement?Strategy/Value Justification – What is the value proposition this idea provides and what strategy are we adopting.Scope – In scope and Out of scope details for the generated idea/ enhancement.Sponsors and Stakeholders – This could be internal or external to the organization.Financials – What are the costs and benefits associated?Success Metrics – SMART Metrics towards the investment. (Specific, Measurable, Achievable, Realistic, Time related)Resources -  Who are the resources going to be engaged? What are the procurement needs? What are the infrastructure needs? Etc.,Agile Project Charter Benefits:Agile Opportunity Canvas creates transparency across the entire organization.Provides a rational route and logic of purpose to the entire team from the beginning to the end.Product Portfolio is maintained and prioritized effectively.It helps avoiding duplicate efforts.It also helps in identifying, if the idea/project/ feature is the latest trend in the market.Agile opportunity canvas can be updated during the planning phase and execution phase. During evaluation or closure phase, the project or solution is validated against the success metrics scripted in Opportunity canvas. Success Metrics in Opportunity canvas does not need to be Objective (directly related to Monetary benefits) all the time, it can be subjective (related to value achieved) as well, depending on the nature of the solution and project.
Rated 4.5/5 based on 1 customer reviews
Deliver High Business Value With Agile Opportunity...

I would like to start this blog with a question. ... Read More

DevOps In 5 letters: Should We Say CALMS or CALMR?

When someone asks me to explain what DevOps is about, I usually do this using the different letters of the acronym CALMS.CultureCulture is the foundation of DevOps. If you omit culture, you're only doing some symptoms of DevOps (like using a whiteboard, working in timeboxes and doing daily standup meetings won't make you an Agile team).Culture is about the people, about self-organized teams, about T-shaped profiles, about tearing down the wall between Development and Operations. A DevOps team takes end-to-end responsibility of an application or system: "you build it, you run it".If your organization has always been working in a command-and-control style, then the first thing to do is to instill a culture of team empowerment. And don’t underestimate this: this will probably take years to change.AutomationThis is where a lot of focus goes into and can be considered as the easiest to obtain. The heart of DevOps is the CI/CD pipeline: the continuous flow process that is triggered upon check-in of new versions of code. Continuous integration was already known in eXtreme Programming. In a DevOps context, the continuous delivery/deployment makes the story complete. To make your CI/CD pipeline work at its full capacity, you have to consider everything as code:Your source code of courseYour automated tests - unit tests, integration tests and so onYour configurationIncluding your infrastructure configurationYour database changesYour documentationBut automation is also about closing the feedback loop: getting observations, metrics from running system fed back into your team’s product backlog.Lean principlesDevOps is not about moving big chunks of changes to production, but instead, moving to a constant flow of small and easier to control changes. Flow, as in Kanban: limited work in progress, small batches. And moving to the production does not automatically mean: "going live". If there is a dependency with other code that is not yet ready, you can still disable your code via feature toggling until everything is ready to be activated.MeasuringThis is crucial to improving: define metrics on your process. How good are the things going in your organisation? Where is room for improvement? And the apply the typical Plan-Do-Check-Act/Adjust approach to gradually improve your way of working.SharingDevOps teams take full responsibility over their system. But this does not mean that they have to reinvent the wheel over and over again. They learn from their peers.Common senseThere are plenty of resources on the internet - blogs, pictures, slide decks and videos - that explain DevOps using this CALMS acronym. So by now, this acronym has become common sense for anyone who searched for some kind of definition of DevOps. Or hasn't it…?DevOps according to SAFe®, in 5 slightly different lettersRecently I had a discussion with a colleague who is a certified SAFe® Program Consultant and trainer. According to this colleague, SAFe® doesn’t talk about CALMS but about CALMR instead. She wanted to be sure we tell the same story and don’t confuse the people we train and coach. I am not going to give a full explanation of SAFe's definition of Devops, you can read it yourself on the SAFe® site (more specifically on this page www.scaledagileframework.com/devops).But I will briefly explain what the acronym CALMR stands for according to SAFe®:Culture of sharing responsibilityAutomation of continuous delivery pipelineLean flow accelerates deliveryMeasurement of everythingRecovery enables low-risk releasesThis discussion made me wonder: if a large part of the world talks about CALMS to define the principles of DevOps, then why does SAFe® talk about CALMR and what is the difference? And why do they call it "SAFe® DevOps"? So I did some investigation and this is what I found.What's the difference?In all honesty, whether you speak about CALMS or CALMR, in the end, both are equal, or better, equivalent. Let me explain why.In the CALMS acronym, the S stand for sharing. Sharing of knowledge, of experiences. Call it communities, or chapters and guilds if you are more into the way Spotify works. I deliberately don't call it "the Spotify model" because there is no Spotify Model (says Marcin Floryan, a Spotify chapter lead in this presentation: https://www.infoq.com/presentations/spotify-culture-stc).But that’s entirely different story.Sharing in CALMRIn "SAFe® DevOps", sharing is a part of the Culture. People work in teams. But teams together form a release train. So, these teams will not only need to align planning-wise, they also inspect and adapt during the IP sprint. And they learn continuously. OK, fair point. But sharing clearly is there in both definitions.Recovery in CALMSSo, what about the recovery aspect of SAFe® DevOps? Is it a part of the CALMS acronym too? In my opinion, yes, of course, divided over other aspects. The first thing that the SAFe® site tells about Recovery is "Stop the line mentality".Now, that is a Lean principle. Mary Poppendieck (Lean Software Development) mentions this in her presentations: "The greatest productivity comes from not tolerating defects. Create ways to detect defects the moment they occur” (see slide deck https://accu.org/content/conf2007/Poppendieck-Stop_the_Line_Quality.pdf ).The other parts, Plan for and rehearse failure and Build the environment and capability to fix forward and roll back, these are typically automation aspects. Plan for and rehearse failure talks about the chaos monkey.The Simian Army is a bunch of tools and concepts that will create chaos in your ecosystem: kill processes, slow down processing and so on. Chaos engineering is really great, but most likely not the first thing you will implement (even though it is a very good enabler for resilience). More information on the Simian Army can be found on the Blog of Netflix. (https://medium.com/netflix-techblog/the-netflix-simian-army-16e57fbab116).Fix forward or roll back: these are the capabilities of your CI/CD pipeline, the heart of your automation efforts in DevOps. Your Continuous deployment should allow to roll back changes. Or do canary releases: for certain changes you don't go full park all the way, but deploy on a very limited set of servers/containers as a try-out and roll back if "the canary dies".ConclusionI could not find any explanation on the internet why SAFe® talks about SAFe® DevOps. The only thing I can think of is that they want to stress how DevOps culture, principles and practices seamlessly integrate with SAFe®. Similarly, SAFe® talks about SAFe® ScrumXP, where the good practices of Scrum and eXtreme Programming help to deliver good quality software every iteration and every program increment, not only on team level, but integrated with the other teams of the Agile Release Train.As far as the difference between CALMS and CALMR is concerned: they both cover the same ideas. In my humble opinion, the difference between CALMS and CALMR could be a matter of focus: maybe the initial focus of CALMS was to stress the importance of sharing knowledge, whereas the CALMR stresses more the need to be able to roll back a failing change.Bottomline, CALMS and CALMR may not be entirely equal, but they are definitely equivalent.Anyway:
Rated 4.0/5 based on 2 customer reviews
DevOps In 5 letters: Should We Say CALMS or CALMR?

When someone asks me to explain what DevOps is abo... Read More

How To Save Up To 40% On Azure Bill Without Buying Any Cost Management Software

I have seen many projects get shut down because of the Azure usage cost. Being a senior developer, I was asked to look over the azure usage and optimize the usage to reduce cost. In this article, we will discuss various ways for effective Azure cloud architecture cost optimization that can easily save up to 40% on Azure cost without purchasing any Cost Management Software. I'll also share some deep insights, which IT Managers doesn't care about, and which has a huge impact on Azure Bill.Different cost management system:1.CloudynCloudyn is an Azure cost management software that provides features like Report on cost and usage, Categorize by resource tags, Create and manage cost and usage budgets, Create alerts on cost and usage budgets, Eliminate idle cloud resources, Right-size cloud resources, Chargeback features including cost markup, redistribution, and custom charges, Customize recommendation thresholds and Categorize costs with custom meta-tags2. ProXcioProXcio contains features like cost analytics, usage analytics, filtered table views, exec dashboards, best practice reports, tag-based analytics, tag-based budgeting, budget analytics, aggregated reporting, limits data stored, limit range for analytics, CSV data import, EA Account drill down, multi-users support, no credit card required, support, cost forecasting, e-mail alerts, data export, Reports scheduling, API access, azure list price invoicing3. RackNapRackNap contains features like White-Label Marketplace, Subscription Billing, Support Helpdesk, Customer Self-service Portal, CRM, Sales and Marketing, Business Intelligence, Own Catalog Management, Partner Management, Inventory Management, Core Customizations, 3rd Party Integrations, Online Training, Admin Users, Deployment Countries, Deployment Model, Services for Launch.4. Azure CostsAll Azure Plans (incl. EA), Unlimited data retention Includes all Professional Features, Multi-Contract & User Support, Team & Enterprise Support, Subscription Based Permissions, Branding & Customizable Widgets, Azure Active Directory Support, Data Access via RESTful APIPrice Comparison:The table below compares the prices of different Azure cost management software available:Review Azure usage and costsCost Analysis Vs Cost AllocationDrill into various data segments itemized from the billing file using Cost Analysis Reports. The reports enable granular cost navigation across Azure raw billing data.After you create a cost model, Cost Allocation reports are available. It matches the data to the usage and tag data of the Azure Account.Cost Over Time:Cost Over Time report displays spends over time to allow you to observe trends and detect irregularities in your deployment. It includes main cost contributors such including ongoing costs and one-time RI fees are being spent during a selected time frame.Use Actual Cost Over Time to see cost trends over time and find irregularities in costAmortized Cost:Amortized cost is that accumulated portion of the recorded cost of a fixed asset that has been charged to expense through either depreciation or amortization. Amortized Cost Reports shows non-usage-based service fees or one-time payable costs and spread their cost over time evenly during their lifespan. For example, one-time fees might include:Reserved Instances purchase feesAzure Marketplace itemsAnnual security component feesThis report displays the main cost contributors within a specified time range and includes ongoing usage costs and one-time RI fees, amortized over the term of the asset or reservation.Custom Charges:Enterprise and CSP often provide additional services to their customers along with their own cloud consumption. You can define these customs charges for added service and additional discounts if any. The list of customs charges doesn't show the different rates that you may be charging.5 things to consider saving to save costIf you are using a public cloud like Azure, it is crucial to know the ways to save cost as your bill is based on consumption. Below are the 5 tips explained to lower Azure pricing and optimize hosting costs:1. Select Azure Reserved VM instancesWhat is RI (Reserved Instance)?An Azure Reserved Virtual Machine Instance (RI) is a virtual machine (VM) on the Microsoft Azure public cloud that has been reserved for dedicated use on a one- or three-year basis.RIs require a one-time, upfront payment and offer customers a discount of up to 72% when compared to Microsoft's standard on-demand, pay-per-use VM pricing model.Azure shows 3 options for Discount -Pay as you go -  You only need to pay for how much you will use.1 year reserved (~29% savings) – 29% discount will be given for reserving VMs for 1-year use.3 years reserved (~43% savings) --43% discount will be given for reserving VMs for 1-year use.2. Compare cost before choosing datacenter regionThe different VM pricing tiers do vary in price from region to region.https://azure.microsoft.com/en-in/pricing/calculator/It combines the pricing data for all VM instance sizes across all Azure regions.Estimate your expected monthly bill using our Pricing Calculator and track your actual account usage and bill at any time using the billing portal. Set up automatic email billing alerts to be notified if your spend goes above an amount you configure.3. Make use of Azure Hybrid BenefitThe most cost-effective cloud for your Windows Server or SQL Server migration which helps you-Save up to 80% on Windows Server with Azure Hybrid Benefit and Reserved InstancesSave up to 55%1 on migrations to Azure SQL Database2 with Azure Hybrid BenefitGo at your own pace - move a few workloads or entire data centers)Maximise your investment in Microsoft Server SoftwareNow is the time to move to Azure and reap the rewards of cloud technology, including the ability to scale up or down quickly, pay only for what you use and save on compute power. Whether you are deploying new virtual machines, moving a few workloads or migrating your data centers as part of your hybrid cloud strategy, the Azure Hybrid Benefit provides big savings as you move to the cloud.4.  Use different load calculator to identify the required loadThere are few additional Database resources whose price cannot be calculated based on days and storage. It needs to specify throughput, DTU, and many additional add-ons.Two types of calculators for databases-1) SQL Database Calculatorhttps://dtucalculator.azurewebsites.net/If you are a developer using SQL Server, you've probably heard of Azure SQL Database and you've probably been thinking about migrating your on-premise or VM-based SQL Server database(s) to Azure SQL Database. If so, you've probably asked yourself, "which service tier and performance level should I use and how many database throughput units (DTUs) am I using now?" This calculator will help you determine the number of DTUs for your existing SQL Server database(s) as well as a recommendation of the minimum performance level and service tier that you need before you migrate to Azure SQL Database. Knowing the minimum service tier will allow you to get the performance you need while minimizing your costs.2) Cosmos Db Calculatorhttps://www.documentdb.com/capacityplannerTo help customers fine-tune their Azure Cosmos DB throughput estimations, there is a web-based tool to help estimate the request unit requirements for typical operations, including document creates, reads, and deletes.5. Make use of BYOL (Bring Your Own License)What is BYOLBYOL, or “bring your own license,” is the process you can use to deploy software that you already have a license. When you BYOL, you are responsible for managing your own licenses. You are responsible for managing true-ups and renewals as required under your Volume Licensing agreement. In addition, you must submit a new verification form when you renew your agreement and when you deploy any previously unverified products.How to go for BYOL?As a customer using License Mobility through Software Assurance, you must complete a license verification process. Microsoft will verify the eligible license with active Software Assurance and send a confirmation once the verification process is completed.Azure now have to Bring Your Own License (BYOL) images of Windows Server and Windows 10 directly in the marketplace.This is what you needed to do before:Install Windows 10 or Windows Server on an On-Premise machineSysprep the installationUpload the vhd to a storage accountCreate a VM (by template or script) using the custom imageThis is what you need to do now to achieve the same thing:Create a VM (by template or script) using the new marketplace BYOL imageHope you found this article helpful to reduce and optimize your Azure costs. Understand and manage your Azure spend effectively with the help of above 5 cost optimization strategies for Azure bill.
Rated 4.0/5 based on 2 customer reviews
How To Save Up To 40% On Azure Bill Without Buying...

I have seen many projects get shut down because of... Read More