In my past execution, I start with playing dual role of tech guy and scrum master as part of jump starting projects. and then transition role of scrum master partly to senior QA engineer or in full to scrum master. For change, I experienced in new context in role of technology manager for platform where scrum master joined 6 months ago and leveraged Jira
Sharing my 4 months observation and capturing evidence to understand challenge to create better collaboration of team and transition for better agile maturity. observations are
- Scrum masters had no access to source code and neither have deployed local versions of applications on their laptop. The local environment practice started for me from my individual contributor days and enables me to collect insights to influence the team beyond what I learnt from them. When I lead a project using RoR, I took teams support to setup a local application environment and also documented steps to deploy locally(DIY second time). When local environment updated had issues, I reached team members for help to get local environment up and running. When one regularly practices setup of local environment and also document steps, one learns basics of a new programming language.
- Scrum master does not access deployment environment details. Developers and DevOps engineers along with the product team are in charge of deployment. Do DevOps stories present in Jira provide details for curious scrum masters?. No. Scrum masters are less equipped to facilitate resolution to impediment in DevOps collaboration. To create a new resource, the story reads like “create a new AWS resource similar to this resource”. The time duration for which new resource is neither captured.
- Scrum masters did not have access to working product documentation. In absence of documentation in remote work, scrum master was constrained to understand bugs in completion and also enforce that bugs require description, environment context, expected output and actual output. Classification of bugs based on business units and components suffered as this was entirely dependent on the product and dev teams.
- Scrum master spent significant effort to conduct agile ceremonies religiously time boxed and track product based on epics, storis, tasks and bugs and to calculate velocity and arrive at burn down charts. Learnt that scrum master is not facilitated to look at business agility of deliverables based on user personas and their user actions and user workflows
- To have business agility, agile development needs to incorporate practices of continuous integration, which is based on automation tests. The team had automation tests, still test execution and publishing results did not happen on a regular basis and complete results were not published on milestone. The published results were based on features and not specific to business units and end-users, reducing the clarity and visibility of test results.
Observed Jira governance was at corporate level, limited customizations possible at team level.
- Epics and stories were quite generic. While some had necessary details, they lacked sufficient details for development. Not easy for newbie to understand gaps
- Product team added epics and stories and discussion happened on Jira work items. Not sure how developers and product team got on the same page, it was tricky for a new person(me) in the team to come to the same page.
- Some questions on user stories were responded to, and detailed answers provided. Some were left without response. Confuses a new person to get grasp of the story or bug, with no clarity whether there are gaps in his/her understanding..
- Bugs have screenshots & videos, expected output & actual output written were missing. Quite possibly Qa engineers were playing safe, as they lacked clarity to write in detail. In addition, end-user requests got added verbatim to bug description and was not easy to
Neither bugs were classified based on business units
With limitations, I felt that scrum master focus was more on agile ceremonies and timeboxing and the question in my mind was “ Is the team on the path to be more tool centric or process focused rather than end-user focused or customer centric. Are Time boxing and velocity focus leading to adherence to plan, rather than responding to change required now?” .
Here are my steps to enable the team to “Respond to change” now.
- Created DevOps asset inventory ( see link), shared with team and scrum master.
- Created baseline development and deployment architecture diagram for platform and leads took charge of updating the same. This was focused to enable on-boarding of new team members ( team had contractors and churn)
- Influenced leads to create minimal documentation to understand complex modules and workflow and also around integrations. This enabled existing team members to move across and work on different areas of the platform.
- Influence engineers to write product documentation first version.
- Influenced scrum master to schedule documentation and their reviews as stories in the sprint, which can be worked by team members
- Personally Reviewed and enables team members to update documentation aligned with user personas and user actions.
- Placed minimal documentation on wiki pages and documents on SharePoint site,
- Started to show by example to be proactive to make stories and bugs complete
- Share with the team what are the gaps in stories and bugs, prior to the Sprint Grooming meeting, along with scrum master.
- When scrum master and team acknowledged gaps, they can collaborate with the product team on stories and business analysts on bugs to complete the story and to ensure bugs contain expected and actual output
When I collaborated with team by example, different team members were able to see different benefits and they took change forward
- The team members started to ask the product team and scrum master that stories and bugs have to be complete and sufficient, prior to them getting scheduled in the sprint.
- When the product team explained features different from product documentation ( reviewed by product team), I or scrum master facilitated discussion to ensure that both documentation and stories were on the same page. Either stories got corrected or the documentation got corrected, both bonus to team’s learning
- As a team, we learnt that bugs reported by end-users ( new users not trained with the platform), were received and the issues got added as Bug.
- This challenged the efficiency of the team in the eyes of stakeholders. Actually these are no code bugs and are content workflow confusion
- Working with stakeholders, to get these issues classified as Content Bugs, defined as issues fixed without change to source code or deployment.
- As DevOps asset inventory was accessible to all team members, both team leads and volunteers started to own asset sheets. In addition, the scrum master got involved and started to make the right noises in the right forums as potential risks for completion. This enabled team to take ownership to track underutilized resources to be decommissioned.
- For new team members on-boarding, the new team process for on-boarding became
- Share documentation to new team members,
- Ask new team member to explore products along with documentation
- Post week, present to the team what they have learnt
- Existing team would help them to identify gaps in their understanding .
- Team was happy that ”No more repetition of on-boarding sessions”
While there was intense work, the exercise created collaborative team culture based on support, openness and shared understanding, enabling better discussions of future fears and challenges. In addition to executing existing technical debt roadmap, I gained more bandwidth to perform.
- Created an automation roadmap and executed successfully.
- More technical debts and legacy apps debts came to the open. Create new technical proposals( with suggested solution), presented to the product team .
- Overall team quality metrics became better , in midst of massive technical debts.
Srini - who am I? 