Jai's Blog: 2020

How Scrum Changes with the Scrum Guide 2020

Scrum has witnessed many applications beyond its origins of software development over recent years. Being a real framework, Scrum has been augmented by many other practices, techniques, and tools, embracing many of those so tightly that they seem indistinguishable from the framework itself. Or, could you imagine running a Sprint without a Sprint board?

Consequently, the calls for accessibility and inclusion have become louder, and Ken and Jeff managed to answer them compellingly.

My Top Changes Regarding the Scrum Guide 2020

I do believe that everyone interested in Scrum as a framework should take an hour and read the Scrum Guide 2020 or the Scrum Guide 2020 Reordered thoroughly. The call for accessibility and inclusion has been heard, and the proposed changes are plenty and far-reaching.

Foremost, the new Scrum Guide is less prescriptive, eliminating many suggestions such as the Daily Scrum questions, at least one mandatory action item from the Retrospective becoming a part of the Sprint Backlog or the advice on why Sprint cancelations are rare events. The Sprint Review lost its detailed recipe on how to run the event. Also, the obvious is no longer stated: Scrum is indeed not trivial to master.

Interestingly, the authors also axed other elements of the 2017 edition of the Scrum Guide that I thought less contested, for example, the magnitude of work allocated to Product Backlog refinement and servant-leadership.

Here are ten changes in the Scrum Guide 2020—in no particular order—I consider remarkable:

No more roles: “The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.” (There are no more roles.)
There is no more Development Team: “Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.” (I have supported many marketing and PR teams in exploring and using Scrum for their purposes. Not once have I encountered someone who could not understand the concept of the ‘development team member’ and apply it to their situation accordingly. Nevertheless, this simplification is welcome.)
The focus on the Scrum Team: “The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.” (This holistic approach was overdue; the Scrum team wins, the Scrum team loses—there are no factions within the Scrum Team but shared responsibility to create value for the customers. This strengthened team idea is also reflected in the point that the Scrum Team is now self-managing than (merely) “self-organizing.”)
Servant leadership no longer mentioned: “Scrum Masters are true leaders who serve the Scrum Team and the larger organization.” (I have always considered servant leadership to be integral to Scrum’s success. This change probably positions the Scrum Master role closer to project managers and delivery managers.)
The Product Goal: “The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. […] The Product Goal is the long-term objective for the Scrum Team.” (I have never encountered a Scrum Team lacking an overarching goal, but probably that is a welcome clarification.)
The Product explanation: “A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.” (Scrum points beyond software; see above.)
Sprint Reviews are no gates: “The Sprint Review should never be considered a gate to releasing value.” (This is another good pointer at the Scrum Team’s empowerment.)
Increment releases are no longer a prerogative of the Product Owner: “The Sprint Review should never be considered a gate to releasing value. […] If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review.” (As the Scrum Guide 2020 states, the “Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.” This notion includes the decision of what to release when to whom.)
Commitments: “Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured.” (There is now a home for the Sprint Goal, the Definition of Done—now without quotation marks—, and the previously mentioned Product Goal as all of them are linked to one of the three Scrum artifacts as commitments.)
“Done” now creates a (potentially releasable) Product Increment: “The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born.” (Another welcome clarification: when work from the Sprint Backlog meets the Scrum Team’s quality standard, it constitutes a releasable Increment.)

As mentioned earlier, there are numerous additional tweaks here and there. To mention a few: The Product Backlog items are no longer estimated but sized, the Scrum Master is no longer removing impediments, but is now “causing the removal of impediments.” Moreover, the “Why is this Sprint valuable?” question has become a part of the Sprint Planning.

Conclusion—The Scrum Guide 2020

Read Full Article here - https://www.leadinganswers.com/2020/11/illuminating-the-intangibles-of-agile.html

Organizations fail when they try to switch to an agile way of working by just implementing the visible agile work practices without the invisible supporting components. They fail because they are missing two key elements:

A psychologically safe environment in which to work
Belief in the core agile mindset and values

These factors may sound soft, fuzzy and hard to define, so let’s examine some of the thinking behind them…

1. Psychological Safety
Psychological safety is a subset of emotional intelligence. It is part of working with others and deals with how comfortable we are at interacting, contributing and questioning others at work. In the book The 4 Stages of Psychological Safety, author Timothy Clark outlines a model for understanding psychological safety. As the book title states, it progresses through four stages:

Inclusion Safety is the basic human need to belong and be accepted by a group. People need to feel safe to be themselves, including any unique or peculiar attributes. Without inclusion safety, people feel excluded from the group.
Learner Safety is the encouragement needed to learn, experiment and grow. It requires us to feel safe when asking questions, getting feedback, trying things out and making a few mistakes along the way. Without learner safety, people will be unwilling to try new approaches.
Contributor Safety is having the autonomy needed to build something valuable and make a difference—the feeling of safety required to contribute something and have it judged by others. Without contributor safety, people will guard their work for too long, waiting for it to be perfect and miss out on early feedback. They will also not feel like they are making a difference.
Challenger Safety is having the permission and “air cover” necessary to challenge the status quo, to question why things are done that way and suggest ways to make something better. Without challenger safety, retrospectives and improvement initiatives will suffer since no one will be willing to speak up and discuss what is wrong.

The concepts of inclusion, encouragement, autonomy and “air cover” associated with the four levels of psychological safety play an essential role in the invisible, under-the-waterline support structure of successful agile teams.

Read Full Article here - https://www.leadinganswers.com/2020/11/illuminating-the-intangibles-of-agile.html

Project managers, product owners, scrum masters and team leads establish this psychological safety by modeling the desired behavior. This is done by admitting their mistakes, asking basic questions and generally “learning out loud” to show they do not have all the answers either—and it is okay and encouraged for people to be open.

2. The Agile Mindset and Values
Agile projects apply a different mindset than traditional, predictive approaches. Predictive projects work from the idea that things can be specified upfront, and the role of the project manager is to break down the work into simpler and simpler steps until they can be handed out to team members. For predictive projects, the mantra “plan the work, work the plan” applies.

Agile projects believe the team is best positioned to co-design and co-create the solution in collaboration with the business. There is no complete upfront design; instead, it emerges through exploration and use. If agile projects had a corresponding mantra, it would contain words such as “incrementally build the highest value solution via collaboration in empowered teams.”

So, predictive projects use design followed by build with centralized coordination, while agile projects use design and build in parallel with distributed coordination.

One approach is not necessarily better than the other. Projects and programs often combine work that suits both systems. The role of the modern project manager involves being fluent in each approach and knowing when and how to implement them.

However, returning to our theme of illuminating some of the agile mindset values, both the mindset and values build on from psychological safety. They include ideas such as:

Collaboration – Together we are stronger than we are as individuals.
Build and feedback - Some things are not knowable upfront; we learn through building and soliciting feedback.
Value-driven – Take an economic view of decision making and aim to optimize business value.
Welcoming change and responding to it – Understand that we will learn as we go—and this will require ongoing change.
Continuous delivery – Deliver through small value-add slices. Frequently check priorities and reprioritize if advantageous.

In the book Collaboration Explained, author Jean Tabaka explains that collaborative teams have the following properties:

Self-organizing - The team is self-organizing vs. command-and-control top-down organizations.
Empowered to make decisions - The team is empowered to discuss, evaluate and make decisions vs. being dictated to by an outside authority.
Belief in vision and success - Team members understand the project vision and goals, and truly believe that, as a team, they can solve any problem to achieve them.
Committed team - Team members are committed to succeed as a team vs. individual success at any cost.
Trust each other - The team has the confidence to continually work in improving their ability to act without fear, anger or bullying.
Participatory decision making - The team is engaged in participatory decision making vs. bending to authoritarian decision making or succumbing to decisions from others.
Consensus-driven - Decisions are consensus-driven vs. leader-driven. Team members share their opinions freely and participate in the final decision.
Constructive disagreement - The team is able to negotiate through a variety of alternatives and impacts surrounding a decision, and craft the one that provides the best outcome.

These characteristics can be evaluated at a retrospective through anonymous surveys. The image below shows data gathered from six team members on a range of 1-5 on each of the eight collaboration factors:

We can use tools such as this—and an understanding of psychological safety—to determine if we have the requisite elements in place for an agile approach to be successful.

Agile adoption can be hindered by the sometimes-foreign language used in agile approaches. Yet ideas from Scrum and XP (such as transparency and courage) are just instances of psychological safety that we can trace to “working with others” in emotional intelligence.

Likewise, collaboration—the secret sauce of effective agile teams—can be tracked to buy-in for specific attributes. These include being self-organizing, being empowered to make decisions, having a belief in the vision, being consensus-driven, trusting each other and having constructive disagreements. No easy feat, but not mystical or unobtainable, either.

Summary

Read Full Article Here - https://biz-architect.com/fine-tuning-safe-with-architecture/

Most organizations view their digital transformation as a top priority. Many are full speed ahead with their digital transformation using SAFe® or another agile approach to deliver their information technology projects. Yet “83% of leaders struggle to make meaningful progress on their digital transformation,” according to Gartner [1]. Too often, architects and agile teams work in silos, as if they were conflictual approaches. It does not need to be this way. This whitepaper intends to show how harmonization between architecture and agile teams can contribute to the delivery of successful projects. Architects can prioritize strategic initiatives from other initiatives by identifying key but problematic business capabilities using value streams and several measurement techniques. Architects can also decompose value stages defining a value stream into sub-value-stages and breakdown business capabilities into sub-capabilities several levels deep for further exploration, refinement, and precision. Business and enterprise architecture model elements can accelerate and enhance with details the description of requirements, epics, and user stories. Finally, architects can detect, signal and eliminate duplicated sub-projects or sprints that can appear in different Agile Release Trains (‘ART’).

Read Full Article Here - https://biz-architect.com/fine-tuning-safe-with-architecture/

What is Scaled Agile Framework® (SAFe®)?

Lean and agile development approaches and enterprise architecture may seem to be two conflicting disciplines to deliver software initiatives at first glance. In reality, they can be very complimentary. Agility allows rapid reaction times and expedient delivery of initiatives in a continuous flow to keep up with quickly changing corporate environments. Using an analogy, agility allows you to run extremely quickly. On the other hand, the use of architecture allows you to see far enough so that you do not hit a brick wall at full speed, while your running with agility.

One of the most used and thought-out agile approach, called Scaled Agile Framework®, has started integrating some architecture into its methodology. In brief, SAFe® is a knowledge-based framework for delivering solutions that brings business value, scales agile practices, and incorporates lean principles and practices into an organization. This framework provides requirements teams and business analysts with a way to decompose strategic value streams and deliver focused value using ‘Agile Release Trains’ development teams with typically between 50 and 125 people to reduce software development cycle time. SAFe® provides comprehensive guidance to develop better systems and software in large organizations more rapidly. This framework is getting very popular and seems to generate positive results as shown in numerous business cases [2].

Read Full Article Here - https://biz-architect.com/fine-tuning-safe-with-architecture/

Agile architecture

Harmonization between architecture and agile teams can contribute to the delivery of successful projects. This is why the Scaled Agile Framework® recognizes the need for agile architects. “Agile architecture is a set of values, practices, and collaborations that support the active, evolutionary design and architecture of a system. (…) Agile architecture supports Agile development practices through collaboration, emergent design, intentional architecture, and design simplicity. Like agile development practices, agile architecture also enables designing for testability, replayability, and releaseability. It is further supported by rapid prototyping, domain modeling, and decentralized innovation,” according to Scaled Agile [3], the creators of SAFe®. Agile architects can be either business architects, enterprise architects, solutions architects or systems architects.

As pointed out in this article entitled “Agile Architecture – an Oxymoron?” [4], “it would be a mistake to expect that you can simply take traditional Enterprise Architecture delivery and ‘bolt’ it onto a framework such as SAFe® (…) – and then deliver architecture at key points in the agile process. The highly collaborative nature of agile delivery, the need for squad autonomy and self-serve, no handoff points, and the concept of minimal viable architecture all require a corresponding change in the way enterprise architecture is developed and delivered so that it too honors the principles that are reflected in the Agile Manifesto.”

In SAFe®, combining Emergent Design, Intentional Architecture to agile practices (Scrum and Kanban mostly) is referred to as the Architectural Runway [5], from which the technical foundation is extracted to create business value.
The enterprise architects’ role in SAFe® is to provide architectural governance, technical direction, collaboration iteratively, and a complete solution deployment strategy across all SAFe® value streams at the portfolio level, creating enabler epics, which are large portions of work made of several user stories as shown in Figure 2 below, to enable desired business and technical changes.

As for the solution architects or the system architects, they then begin to lay the architectural runway for the SAFe® value streams by creating architecture blueprints with a system view, based on the direction provided by the enterprise architect. Part of this involves creating a future state for the architecture, then developing a transition plan ideally with increments to improve the organization from its current state to that future state.
Business and enterprise architects can be instrumental in the delivery of sophisticated projects with there ability to accomplish these following four tasks:

Prioritize strategic initiatives,
Decompose high level value stream/value stages and business capabilities,
Assist in defining epics and user stories using architecture model elements, and finally
Eliminate sub-projects or sprints duplicates.

Strategic initiatives prioritization

Business and enterprise architects should engage early ideally before the beginning of the Scrum and Kanban continuous delivery pipeline used in SAFe®. Architects should make sure to link every value stage of the SAFe® Value Streams to its enabling capabilities, information concepts, and its various departments and business units to clarify how the business really works. By starting on early into a project, architects can prioritize strategic initiatives from other initiatives by identifying key but problematic business capabilities enabling value streams using several measurement techniques. As indicated in this 5-minute blog entitled “The Relationship Between Business Architecture and Agile” [6], “Business architecture applied to agile programs helps teams in setting a foundation on the highest priority capabilities and work on ensuring alignment to the strategy of the business. It does not get in the way of the team but rather works alongside the team to be better prepared and speed up the team rather than slow them down. It applies agility and the success of the team to the highest value parts of the business.” This way, business and enterprise architecture strengthens SAFe® at the portfolio level by defining what strategic agility must look like and how to do it. Without proper architecture, agile teams must predict, imagine, try and manage a single future that is based on many unknowns.

Decomposing high level value stream/value stages and business capabilities

Business and enterprise architects can also decompose value stages defining a value stream into sub-value-stages (if necessary) and breakdown business capabilities into sub-capabilities several levels deep for further exploration, refinement, and precision. This decomposition will allow the elaboration of much more precise epics and user story definitions at a much more rapid pace.

Furthermore, architects can also align value streams/value stages to impacting strategies and objectives, triggering or participating stakeholders (including personas and customers from various market segments), mapping business processes, delivering value proposition (often made of various products and services) and enabling capabilities. The same can be accomplished with capabilities, as shown in Figure 1 above, that shows the properties of the Contact Management capability, knowing how a capability is aligned with supporting applications, created information concepts, enabling process, impacting strategies and objectives, impacting initiative, etc.

Defining epics and user stories using architecture

Business and enterprise architects also need to translate the business strategic themes of their organization into more detailed epics. By putting more resources into architecture at the beginning of the SAFe® process, the likelihood that the program delivers systems and software more useful to its business users increase significantly. The modeling executed by architects also facilitates the epic owner’s efforts. When an epic or a user story is approved to move from the backlog for review and further business analysis, the epic owner has the responsibility of creating a lightweight business case according to SAFe®. This involves examining the size, the impact, and the exact benefits of the epic for the organization. By using the business and enterprise architects’ detailed model, epic or user story owners have a far better understanding of the business scope of their epics and of the benefits, the epic will deliver to the organization, as shown in Figure 2 above, where over 90% of the words describing a user story are elements of the organizations business and enterprise architecture model and where all the properties of the architecture element can be viewed as shown in Figure 1 above. This speeds-up the business analysis ability to expedite the epic or user story to its next phase.

This consulting role of the business and enterprise architect within the SAFe® value stream and program levels is not limited in assisting epic owners and business analysts. The same consulting role by architects could be accomplished with solution managers and product managers among others.

Elimination of sub-projects or sprints duplicates

Business and enterprise architects can finally detect, signal and eliminate duplicated sub-projects or sprints that may appear in different agile release trains. Some SAFe® programs may have well over 10 independent Agile Release Trains running in parallel, each one of them with typically between 50 and 125 people, delivering their tight milestones all in about the same time. It’s very possible that some of the sub-projects, scrums, or Kanbans in one agile release train could be identical to other parts of a totally different Agile Release Train. Architects often have the appropriate tools and mindset to find these duplicates making it possible to allocate these resources elsewhere instead and increasing further the efficiency of SAFe® programs.

Metrics help to measure qualities.

Given below the list of Metrics tracked in each phase of Project Life Cycle.

Phase	Derived Measure/ Metrics	Formula	Definition
Project Monitoring and Control	On Time Delivery Index (%)	1. # Implementations completed on time # Implementations delivered 2. # Migrations completed on time # Migrations delivered	% implementations competed on the Implementation end date (Planned) % migrations competed on the Migration end date (Planned)
Project Monitoring and Control	Schedule Variance (%)	(Actual # days to complete implementation – Planned # of days to complete implementation) Planned # of days to complete implementation (Actual # days to complete migration – Planned # of days to complete migration) Planned # of days to complete migration	% variance between the planned and actual schedule for implementation % variance between the planned and actual schedule for migration
Project Monitoring and Control	Size Variance (%)	(Actual Size - Estimated Size) Estimated Size	% variance between the planned and actual size for implementation/migration
Project Monitoring and Control	Requirement Stability Index (%)	(1- (# changed requirements + # deleted + # added/# initial requirements))	Provides perceptibility to the scale and effect of requirements changes.
Design	Design Review Effectiveness (%)	(#Design Review Defects / (Design Review Defects + Code Review Defects + Unit Testing Defects + QA Testing Defects + User Acceptance Testing )) *100
Design	Code Review Effectiveness (%)	(Code Review Defects / (Code Review Defects + Unit Testing Defects + QA Testing Defects + User Acceptance Testing))*100
Project Monitoring and Control	Effort Variance (%)	(Actual Effort - Planned Effort) Planned Effort	% variance between the planned and actual effort for implementation/migration
Project Monitoring and Control	Resource Utilization (%)	(Actual Effort / Actual Variance Effort)*100
Testing	Test Coverage (%)	# Test Cases Executed/# Test Cases Written	Gives an understand of what is being tested and how much is being tested
Testing	Defect Leakage (%)	(# Pre Defects/(# Pre Defects + # Post Defects))*100
Testing	Defects Removal Efficiency (%)	# QA Defects (# QA Defects + # Post QA Defects)	Efficiency of QA team in unearthing defects for the Implementation and Migration teams to remove them before UAT
Testing	Delivered Defects Density (Defects per CP)	# Post QA Defects Actual Size	% of injected defects that escaped QA to UAT
Testing	Design Review Defect Density	Design Review Defects Size in Complexity Point
Testing	QA Test case review efficiency	Test Case Review Defects Effort Spent on Test Case Reviews
Testing	QA Defect Density	QA Testing Defects Size in Complexity Point
Testing	UAT Defect Density	User Acceptance Testing Size in Complexity Point
Testing	Unit Testing Effectiveness	(Unit Testing Defects/ (Unit Testing Defects+ QA Testing Defects+ User Acceptance Testing))*100
	Productivity (Complexity Points per Person Hour)	Actual Size of Implementation [or] Migration Actual effort for Implementation [or] Migration	# of complexity points completed in 1 person hour
	Effort Overrun	(Total Estimated Effort - Actual Effort on the project) Size in Complexity Point
	First Time Right (%)	# Implementations [or] # Migrations closed with zero QA and post QA defects # Implementations closed	% of Implementations/Migrations closed with zero QA and post QA defects

Tags:

#Metrics , #ProjectManagement , #SoftwareMetrics

How Scrum Changes with the Scrum Guide 2020

My Top Changes Regarding the Scrum Guide 2020

Conclusion—The Scrum Guide 2020

Search this Site

Translate Articles

Total Posts

Total Pageviews

Contributors

Certifications

My Favorite Links

Contact Form

Connect with Me

Blog Archive

Recent Posts

Followers

Report Abuse

Popular Posts

Comments

How Scrum Changes with the Scrum Guide 2020

My Top Changes Regarding the Scrum Guide 2020

Conclusion—The Scrum Guide 2020

Search this Site

Translate Articles

Total Posts

Total Pageviews

Contributors

Certifications

My Favorite Links

Subscribe To

Contact Form

Connect with Me

Blog Archive

Recent Posts

Followers

Report Abuse

Popular Posts

Comments