- Now, let us talk about
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.