Mind the ripple effect
Have you considered the ripple effects of your day to day work?
As Scrum Masters, Tech Leads, Managers or Agile Coaches most or our actions could have all kinds of more or less predictable effects.
Let's consider a few situations.
A Scrum Master that tries to support their team on their Agile Journey, could easily get at odds with the values and principles of the larger organization that is earlier in its journey. There are plenty out there that still assume that the Scrum Master should provide the same command and control perspective and the same updates and "dashboards" and "metrics" like the Project and Program Managers in traditional initiatives.
A Tech Lead that pushes hard for the team to adopt some really advanced XP techniques - mob programming, ATDD, code analysis, etc. - too early, might turn off some other team members which will impact progression of the team through the forming-norming-storming-performing cycle. Note - adopting these technical practices is a main focus of agile teams, but the timing and approach is critical to its success.
A strong Scrum Master will sooner or later become the victim of their own success in an organization that focuses on Agile "delivery" as a means to prop up current organizations that don't realize yet the need for much deeper change and look at Agile to achieve "velocity". Don't get me wrong, velocity is a great aspect of Agile, but nowadays there is a significant amount of over-use, arguably ab-use, of the term to mean - "I don't care what you do, just get it done in half the time"!
A Tester (sometimes using the title QA Specialist) arriving into their first agile team will need some space and time to deal with the culture shock of working with user stories, acceptance criteria, spec by example, test automation, very different cadence of work, less formal environment, etc., etc. Give them the opportunity to manifest their concerns, allow them to get the answers of how would their concerns be supported in the new model, and what is it critical for them to focus on.
So if you're a Manager or an Agile Coach or a Tech Lead - please be mindful of the way in which you show your leadership and initiative, and listen to your team and to your colleagues.
Now - on the outcome side of these hypothetical scenarios, how would one deal with several potential situations:
- people shutting down due to "change overload" and falling back into denial and professional paralysis;
- the organization reacting to situations like "failed sprints" and shutting down agile teams due to misunderstanding and false expectations;
- the organization being excited about early wins in agile adoption, tasking an agile team with a "mission impossible" project, before the team reaches a maturity level where it can deliver;
- great agilists leaving the organization due to the amount of workload and responsibilities increasing much faster than recognition and personal benefits;
- great agilists in specific roles - e.g. Scrum Masters, Product Owners, Tech Leads - getting promoted to various other roles and leaving a gap behind.
So if you're in one of these roles, or if you're a Scrum Master or Agile Coach working with these folks what would your perspective be?
On the one side you could see some of these as losses to the agile transformation initiative. But on second thought, in some situation, things could turn out to be quite positive.
For example, when an agile team is dismantled, the folks on the team that have adopted both agile practices and at least some core parts of an agile mindset, will take with them to the other teams, departments and projects these practices and ideas. Most folks once they really enjoy working on an agile team will have quite a difficult time adapting back to traditional methodologies so they will advocate for agile adoption on the new team.
An early agile adopter moving off a team will actually create some space for others on the team to step up to the plate, show initiative and personal leadership and cover for the responsibilities and tasks that are now available.
Great agilists promoted to more influential roles, will bring forth core concepts from the agile mindset up the hierarchy in the organization, and hence transform it from the inside out.
So sometimes one needs to take a second look and reframe the whole picture, or maybe zoom out to look at the big(ger) picture to understand all the implications and repercussions.
Something of a butterfly effect.
Always happy to hear from you with questions, comments, criticism!
I think the company's culture and general project experience is also key. If you're running a department that has been doing projects a non-agile way for many years, they will have considerably more difficulties moving to agile methodologies than a newer department starting out-of-the-gate with agile. Sometimes a company's culture, especially one that consistently embraces change, will make the transition to agile easier.
ReplyDeleteMoving to agile really is a huge change, one that needs constant review and constructive criticisms.
Thank you for your comments! Really thoughtful ones too!
DeleteIn my experience it is indeed very important to consider the company culture and attitudes towards change. At the two ends of the spectrum I see companies that once they are trained and understand what Agility is really about, they decide that it is not something they are ready for, it's too early; and the other is to your point organizations that are "starting out-of-the-gate with agile", and it is second nature to them. In that case I'm constantly watching to make sure I'm not standing in front of them - but rather support their efforts and act as a catalyst to reinforce their journey and progress.