7.5: Enterprise-level Agile Transformation - Video Tutorials & Practice Problems

<v ->Now, let us talk about</v> Enterprise-level Agile transformation versus Team-level. Agile at scale is defined as the ability to drive Agile at the organizational level by creating Agile culture and mindset. Also, we apply Agile principles, practices, and outcomes at an enterprise level. This is extremely important because in large organizations it's almost impossible to succeed in an Agile environment without scaling agility. So let's review an example. Let's imagine a software agility team that decides to implement Scrum at the team level in their company. In our example it's a large bank. In their previous organization three of the seven team members worked on Scrum teams. So they're not new to Scrum. They were excited about team empowerment and collaboration that they had with their customers in an Agile environment. They shared the experience with other team members and introduced them to Agile manifesto, Scrum guide. And initially other team members were a little bit skeptical and didn't think that team self organization would work in a large financial services company. But then they decided to be open-minded and to try it out. The first thing they did was to get support from their functional managers. Their managers did not mind them trying some Agile practices as long as the team members deliver high quality software on time and keep them in the loop. Managers asked for weekly updates, offered help and advice to team members. So that was a really helpful first step. Next, the team came up with the name of Transformers, because they were transforming the way of working in the organization and the way it delivered software to their customers. They agreed to provide weekly updates about the number of users, stories, tasks completed, bugs resolved, and functionality delivered to their managers. And they started sprinting. In four sprints, the functional managers said they don't really need those reports because they could see all up to date information in Jira which was the tool that the team selected to manage their work. So without this overhead, the team became even more productive. This of course didn't mean that everything was perfect. Sometimes they would get a blocker that they did not expect from a new tool, or sometimes they had to tweak a solution because of security review and so forth. And they didn't hit every single sprint commitment, but if they missed, they missed by little, maybe one user story. They learned not to get upset with missing the commitment and they decided to turn every challenge into an opportunity. So what they did, they discussed the problem at their retrospective and expressed any concerns about inefficiencies and then took their delivery to the next level with new improvements. As a side product of this transition, team members were actually very happy and committed. They had control now. They felt rather than getting tasks, they were getting a direction. And then they had the freedom to make their choices, in terms of implementation details, sequencing, or planning their work, and overall self organizing the team into delivery. They also felt there was almost no overhead in the way they managed the work or at least compared with their prior experience. And also they didn't have to submit those RAG reports, red, amber, green, about the project status and a lot of explanations they had to do previously. And also they worked at a sustainable pace versus their prior constant weekend heroics. They were motivated by showing their work to the users and hearing their direct appreciation and feedback. So compared to really high attrition on other adjacent teams within the organization, no team member has left the Transformers team since the Agile adoption started. Actually on the opposite, multiple people within the company heard about this team and were reaching out to them and said they would like to join. Also of course, things were not all smooth and easy. One problem was Transformers team was not the only team in the organization, so they depended on many other teams for infrastructure, solutions, software integration, data backup, legal compliance reviews, and so forth. They did not work in a vacuum and it was becoming more and more apparent to them. Because those other groups did not have the same level of agility, they did not have flexibility and customer centricity as they did. Within a few months there were multiple challenges that transpired. There were three most impactful challenges. The first one, management still required long term plans with every activity detailed out with timelines and delivers, and they still wanted RAG status, red, amber, green. The burn downs and roadmaps were not sufficient to them. The second challenge was with the legal and compliance departments. They required four to eight week notices. And in many features that were delivered they would require changes after their reviews which disrupted the following sprint. The third challenge is that software dependencies on other teams that did not practice Agile were really challenging. Even though Transformers did their best to decouple features and request those early from the teams, the teams took a lot of time to process and deliver those and that slowed down Transformers sprint. So those three challenges made it really hard for Transformers to exist within the organization. In addition to all these challenges the attitude towards Transformers within the organization itself was not that positive. Some of their peers thought they were just trying to stand out and make life more difficult for the others. Some of the managers were clearly annoyed by the lack of enthusiasm related to advanced planning on all those requirements months and months in advance. It was easy to understand the managers had to plan a year ahead based on the annual budget cycle. So incremental planning was seen by them as an impediment to their own job. The chief software architect was taking Transformers' agility almost personally. She saw it as a threat to the architecture board that she chaired. The concept of emergent design in an Agile environment challenged the whole existence of the architecture group because they would have to review every changes to the architecture very, very far in advance. Also their organization CTO, chief technical officer, used to say that perception is reality. And the perception was that there was no planning in Agile, no architecture and no collaboration outside of the team. So others felt that Agile was the wrong way for the organization to go. And unfortunately it didn't end very well. The Transformers team was restructured with the team members individually assigned to different projects, and many of them left the company.