Intro (or what you probably know already)
More and more companies & enterprises are nowadays trying to leave Waterfall’s established traditions and way of work but without optimally and carefully moving to a solid, disciplined and well-thought Scrum-based delivery model. Reasons for that are many, but require a follow-up post on their own, so I won’t be discussing this here (however lots of good stuff have been written about this topic already). This problematic adoption, usually leads to suffering the disadvantages of both Waterfall and Agile. In these cases, if the projects are successful, it is despite, not due to Scrum practices as implemented.
Very commonly, companies’ organizational structures, processes, practices and culture are not ready for and optimally defined to welcome something so transformational like Scrum. In many ways the current software development organization there, remains Waterfall-ish in nature – in some occasions with an honest attempt to use Scrum terminology (cargo cult style), but without really celebrating or employing Scrum’s essence & philosophy, hence increasing the risk of bringing no significant change on the value creation streams – As such, this unreadiness, poses very high risks of schedule overruns, inefficiencies, reduced product value and expected quality.
The Challenges (or you’ve probably seen those a lot before)
Another proud-standing silos picture for you
Below you may find an indicative list of some of the most common problems
Organizational Challenges
- Silos & walls of confusion.
- Dependencies
- “Us vs Them” & CYA attitude.
- Demotivation
- Learned helplessness.
- Limited visibility & reality-check on upper management levels.
Project Challenges
- Unrealistic timelines based on limited empirical evidence
- Fixed (almost) scope.
- Fixed (almost) time.
- Weak project governance.
- Pushy management.
Technical Challenges
- High complexity feature development.
- Parallel development & integrations in front and core backend systems.
- Environments and other backend systems frequent unavailability (due to unplanned deployments).
- Unclear specs & poorly written User Stories/PBIs.
- Problematic testing processes.
Scrum Adoption Challenges
- Teams organized per component or functional area and not per feature.
- No clear product/business representation in teams.
- Teams not sitting close or not collocated.
- Lack of value-based prioritization of product backlog.
- Lack of clear and known-to-all Definition of Done.
- Having status reports instead of Daily Scrums.
- No demo or future feature discussion in team-wide Sprint Reviews.
- No organized team-wide Retrospective events.
Scrum Mastering it (or something needs to change)
What a ScrumMaster can and should do in such a context? To begin, I would argue that the 9th stance of a Scrum Master (to add to Barry Overeem’s wonderful “The 8 Stances of a Scrum Master” whitepaper[1]) is also to be able to act as the organization’s (cognitive) psychotherapist. Like a therapist can see the problem of her patient/client because she is seeing the problem from a distance, from the outside, this way it’s a Scrum Master’s job to act as the organization’s therapist to fulfil her role as a true agent of change by exposing inherent organizational and process flaws to improve flow (and of course the mental well-being of all involved folks as well!).
Begin with some Organizational Psychotherapy sessions:
- Seeing the problems from a distance, from the outside.
- Try to understand context, people & their motivations, balances, how development organization works.
- Attending but not participating at meetings.
- Laying low and quiet but actively taking notes and talking to people.
- Systems thinking.
- Emotional and Social intel.
Then or in parallel, set the stage and the rules of the game:
- Discuss, decide & establish team’s way of work, tooling etc.
- Identify and meet with the Product Owner(s)
- Reiterate and adapt as new knowledge is gained.
- Avoid being dogmatic.
Use some Cynefin framework [2] thinking and aim for chaos reduction and process improvements:
- Focus efforts on moving from chaotic to complex.
- Introduce some clarity in the process.
- Facilitate information flow.
- Gain control over all those many things that seem everchanging and being in constant flux.
- Establish notification mechanisms and alerts.
- Staying in the loop.
- Try reducing Sprints duration to improve flow (yes!).
- Deliver smaller or less, but confidently.
- Make testing & QA involvement an integral part of development [3]
“Coming together is a beginning. keeping together is progress. working together is success.” [4]
- Know your people.
- Bring them closer.
- Relate and create bonds.
- Form small closed loop teams.
- Establish transparent, open and active communication channels.
- Speak the truth to management at all levels.
Outro (or the journey never ends)
If the below have started happening, you’re probably one small step closer to success:
- People talking more to each other.
- All those disconnected teams, now having more lively interactions
- Generation of novel ideas during problem solving activities
- Teams suggesting new and better features during product development
- Blame games have largely stopped.
- People starting feeling happier.
Royal Concertgebouw Orchestra & Mariss Jansons performing Mahler’s – Symphony No 2. ‘Die Auferstehung’, known as the Resurrection Symphony
References:
[1]: https://www.scrum.org/resources/8-stances-scrum-master , Barry Overeem, Scrum.org, May 2017
[2]: https://hbr.org/2007/11/a-leaders-framework-for-decision-making , David J. Snowden & Mary E. Boone , November 2007 issue
[3]: http://agilegreece.org/adopting-agile-testing-practices-2/, Nick Meggoudis, January 13, 2017
[4]: https://www.agileconnection.com/article/henry-ford-master-lean-agile-processes, John Yorke, October 11, 2017
spiros dimitropoulos | agile ways 