Is your agile safe or is your SAFe agile?

• Which one word would you use to define agile culture of your organization?
• What symptoms can you spot in your organization making it everything but an agile culture?

This thought came up today based on an interaction during one of the team sessions where product owner did not want to de-scope a few issues from the sprint because that would mean not delivering on work which business had asked to be delivered. It was previously communicated by the respective scrum master that committing this much work by the product owner during PI Planning was a risk considering different milestones along the way including but not limited to year end transition and holidays, major release, team’s diminished capacity and new team member. I can visualize some of your making funny faces as if there already are red flags in this situation. Let’s cut tot he end of that conversation where product owner suggests that we do not do this here as that is not delivering the work. This made me think how agile is SAFe implementation in this ART when we talk train and team level execution. In last couple of hours, I have mustered a few (many more that we can account for) symptoms that show us whether or not SAFe practiced in our organizations is agile.

First and foremost symptom being the speed of decision making and I’ll reference Crucial Conversations here for it mentions the lag time from when a conversation is started to the point of having a resolution is critical component to identifying how doomed an organization, relationship or an entity is. If team A has a dependency and it takes more than twenty four hours to get an acknowledgement of such a dependency on Team B, we have a problem. Speed of communication and decision making literally makes an eco-system agile. If developer Jim has identified and diagnosed the problem and has already reached out to subject matter expert Ali to establish triage on this situation to resolve dependency on Team B, that means Team A in fact is living breathing agile practices as Jim didn’t wait for scrum master or product owner to initiate a Skype call to have a working session. Taking ownership is a leadership trait but it is not exclusive to leaders with titles for it is the leaders without titles who make wear it so gracefully. Julie on the team is testing a few items and has a few questions on certain ambiguities on respective user stories. She reaches to product owner Sheila for clarification who suggests that product manager will have to be engaged for a decision. Twenty four hours pass and Julie hasn’t heard from Sheila till Julie brings this up in team sync next morning. This delay has now caused a loss of human hours work on those user stories and both will now be carried over. If this is happening in your train, then indeed your train is not agile. It might be SAFe but it certainly is not agile. One way to counter this is to document request, add all parties involved as soon as possible, nominate a point person and establish a timeline for resolution of this. Key here is to hold each other responsible to ensure that information is acquired and passed on to relevant team members.

Second bit here is really something that drives agilists crazy for product folks (based on my experience) fail to understand and grasp the gravity of situation this causes. When an organization’s development work is driven by annual, integrated, monthly releases then we can safely assume that we are operating in a highly waterfall version of SAFe. I’ll share a few symptoms which will help this case, One team that has had a history of carryover has started to finish sprints without any carryovers but management and product owner instead of allocating work based on historical velocity, team bandwidth and upcoming test window emphasize that all remaining work needs to be committed, whether or not team is able to deliver without incurring overtime. It is important to note here that once a specific behavior change starts producing results, it is critical to reinforce those behaviors to establish predictability and trends that will help the team improve iteratively moving forward. Just because a release is approaching and product management does not feel good about saying no to business is a classic symptom that we’re not operating in an agile environment or that SAFe train we’re part of is not agile. Development practices should be focused on quality of working based on requirements instead of time left in release for one of the most robust agile in SAFe organization I was part of was Verizon Wireless. They had a bi-weekly release which all particles were aware of but that releases did not drive development timelines. Once development teams would complete the work, they would hand that work off to group product team whose job was it to work with identified individuals from select teams to ensure that quality of code developed was good as it was put through regression and other tests prior to earmarked release. This way a feature that was completed in sprint 4 on February 28 did not have to be deployed and released on the bi weekly release the following week. It would depend on when business wanted that feature deployed with or without toggles. I have yet to see such planning and system in other Fortune 100 organizations that I have been part of. These organizations are certainly operating in SAFe but when it comes to team level agility, there are opportunity areas that can be worked on. Best way to counter this is to yes, decouple release from demand. If that can’t be done due to behemoth of an organization then next best thing is to ensure that commitment batches are small and manageable. Remember reducing batch sizes, and decreasing work in progress clock by working smaller stories.

This one really cracks me up every time I hear this. “We have worked so hard on this. Why is this not a priority anymore?” When developers, product owners and even managers fail to understand that work is driven by customer priority (internal or external) and when they want to push a certain deliverable down to teams based on funding and when they want to abort due to lack of such. One key lesson one of my coaches taught me was to never take change of plans personally. Being able to disassociate quality of work from business priority is something that enables us to keep our eyes on the prize i.e. deliver work for what has been put infant of the teams as part of the strategic vision of the organization broken down into key deliverables and defined as objectives and key results (depending on whether your organizations or teams do this). Many a times, I see feature leads, product owners getting attached to work and finding it hard to move to a more pressing priority in Q2 now then what was two weeks ago. Due to that prolonged attachment and sentiments that become part of the picture, team morale gets impacted “why does business not understand that we worked so hard on this and now they change directions?”. Allowing ourselves the freedom to realize “this was a priority but is not anymore so let’s consider new item on our plate and provide estimate and timeline” is one of the hardest things teams have to do. This is where product owners and management alongside agile coaches come into play. They should lead from the front by educating teams on strategic and operational priorities (if needs be), create environment for psychological safety where disagreements are talked about and weighed in form of pros and cons and establish a collective growth approach instead of a super star mentality view. Not being able to separate oneself from an epic that is about to be de-scoped and insisting that we can still deliver it dark despite scope changes defeats the develop on cadence, release on demand purpose. Team’s work once delivered should be ready for any subsequent testing, validation, user acceptance benchmarks before business gives the go ahead for deployment. Teams should not have to worry about dark releases unless in extenuating financial, NPS, reputation or regulatory circumstances. If yours is one such environment, then indeed your are operating in SAFe but not in an agile eco-system. This will take the most effort for coaching humans to detach them from work they’ve put their heart in is a tall order. Patience is the key and it can be achieved by showing them the results of being flexible to pivot when business shifts their priority in form of value delivered (be is in form of story points or end user value).

In the end, it is not the framework that drives organizational growth, nor it is the toolkit at disposal of those at the helm of affairs. It is the very individuals who embrace change at every turn and blend it with collective personalities to provide steam for this value enabled locomotive. Unlearning and learning how to adapt to change while juggling ever changing priorities and moving time to market timelines is the very essence where the very soul of organizational agility is defined. During times like these, it is only those fearless leaders who have the heart to absorb short term failure for long term growth who will go the distance to see an organization that successfully moves from a transformation to agile maturation stage.

I want to hear your thoughts on this so please share away!!!

APGI - Agile Practitioners Group of India 塔塔咨询服务公司 InfoVision Inc. HCLTech Soloinsight (CloudGate Platform) Agile Nepal SZABIST University - Islamabad Campus Pakistan Agile Education Agile Pakistan Scaled Agile, Inc. Agile Alliance CodeNinja Inc. Ebryx Tech Liquid Technologies Emblem Technologies VentureDive Cooperative Computing Ekkel AI 3LI GLOBAL (Previously Databeys) Octavebytes Shispare Systems Limited Datapilot LOGICON, LLC TEKHQS Venturenox CodeFulcrum Xeven Solutions Autonomous Technologies FZ LLC