In one of my recent assignments, I had an opportunity to implement Scrum in an IT Services Space.
When I say IT Services Space, I am referring to a function providing Infrastructure & Technology services in 4 physical offices(To give a bit more granularity, a core team of 14 people with a leader providing IT services to 2000 plus people). The services the team offers are categorized as Site services and Application services.
On the site, services range from issuing hardware and accessories like Laptops, Monitors, Mobile phones, Desk phones, Printers, networks support, etc. In the Application Services, the services range from maintaining Servers to resolving issues in the organization supported applications.
Definition of Scrum
As per the Scrum Guide, Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
- November 2017 edition
Here in this context, the scrum framework is used to address complex adaptive problems, while productively and creatively delivering services of the highest possible value.
With the help of the Cynefin framework, the nature of work is sensed mostly to be in a complex domain(more of unknowns than knowns). So it was decided to Probe-Sense-Respond. Wherever possible, identified the smallest possible experiments to sense the outcome.
If found positive, we amplify it else dampen it. To deal with the complexity, we followed the emergent practice with the help of Scrum.
Image source — Wiki
Nurture culture through values
M3.0 quote: “The primary function of the leadership is to nurture culture through values.”
The leader of the function is aligned with the need for emergent practices. With the increase in complexity in the environment, it was clear for the leader that the team needs to create their change rather than external factors forcing them to change. Also, for the change to be sustainable, he believed the right environment needs to be created, which fosters interaction and collaboration.
Implementation of Scrum initiated the shift towards emergent practices. In turn, it helped to create an environment for the team to act upon. But the real challenge was to get the team aligned to the values needed to implement Scrum. That, too, with teams distributed in four locations, made it more difficult.
The strength of the team was its longevity; the average years of people working together in the team were six years. Commitment towards the function to be successful was evident. Still, the team needed a common goal to work together. Also, the team needed a clear focus on working on the right problems. The team had faith in the leader and had the courage to work on any tough work leader brings their way. Still, it lacked the courage to challenge the leader. The team had the intent to be open within the team, but the distributed nature of the teams was a hindrance to be completely transparent. The team had good respect among everyone, thanks to longevity.
With the introduction of Scrum brings an opportunity for the team to follow empiricism (Transparency, Inspection & Adaptation). The values the team exhibits shall go well with the help of empiricism and add more trust among everyone.
Various collaboration tools were used — Zoom, Slack, Miro, Polleverywhere along with JIRA to increase the level of interaction and communication within the team.
On top of Scrum, a strategic alignment was used to align ourselves to the vision.
Outcome-oriented goals are being intentionally set up to help the team think of the customer journey. For that, we try to use Josh Seiden’s concept below.
Impact — Sum of all variables that create business results
Outcome — A change in human behavior that drives business results
Output — Increments of delivery that generate outcomes
Next in line is to incorporate OKRs (Objectives and Key Results). On getting better at outcome-based planning, the outcomes are to be made as more specific measurable ones and make it as Key Results. It helps to enhance our strategic connection to be much more relatable.
I am using Gunther Verheyen’s ten questions about Scrum to relate the Scrum implementation in the IT team.Can you say ‘yes’? (10 questions about your Scrum)I call myself a Scrum Caretaker. I aspire inspiring people using Scrum. I prefer showing that I care by sharing…guntherverheyen.com.
1. The accountabilities of Product Owner, Development Team(s) and Scrum Master are identified and enacted?
Product Owner — Leader of the function
Development team — Team
Scrum Master — Scrum Master
As part of the Product Owner role, it was natural for the leader to optimize the value of the team’s work through appropriate decision making. Management of the Product Backlog was shared among everyone. Then, the team, along with the Product Owner, co-creates the Product Backlog. The Product Owner did the ordering of the backlog.
The team was more a component team, delivering services in collaboration with other specialized teams. The team was provided autonomy to work with anyone in the organization to provide value. The team was able to manage the collaboration outside of their team but were transactional. There was a clear drive to move from transactional to thought partnering.
As a Scrum Master helped the team understand the Scrum Framework and its purpose. On the impediment removal, it was more on the mindset shift. Continually challenging the team’s established thinking pattern and helping them move away from activity-driven delivery to value-driven delivery.
Scrum Events & Artifacts
2. Work is organized in consecutive Sprints of 4 weeks or less?
Considering the level of uncertainty like the work the team does, it was agreed that the risk should be limited to a two-week iteration. As the level of dependencies across different functions was on the higher side, the two-week iterations are used as an opportunity to create smaller experiments.
When the situation demands, the team adapts its Sprint Cadence in consensus to everyone. During the COVID-19 pandemic, the team had to move to a Daily Sprint, to control the risk of uncertainty. Then when the new normalcy of remote working emerged, the cadence was made to be a week sprint.
3. There is an ordered Product Backlog?
The Product Backlog constituted different natures of the work. It was categorized as New capabilities the business needs to equip them to get better at what they do. E.g., A new application or product a business needs to make their work better.
Then Foundations, stable base for capabilities to be built upon. E.g., Base systems to have the ability to host the new applications.
Other is Operations, more of day to day operational activities to keep the ball rolling. E.g., Accessory dispensing, IT Bar, etc.
Intentional ordering of Product Backlog is done to balance the type of work the team focuses at a given point in time to ensure that the team is not overdoing one area and leaving other areas behind. The Product Owner — being a leader in the organization with the vantage point that he has, adds his views to order the backlog based on business impact, risk, etc.
4. There is a Sprint Backlog with a visualization of remaining work for the Sprint?
5. At Sprint Planning a forecast, Sprint Backlog and a Sprint Goal are created?
The leader comes with business objectives needed, but agreeing on a coherent Goal was a constraint that the team had to live up due to the nature of the work. But the team understood the value of moving towards goal-driven work than task-driven work. So the team created multiple goals for a sprint. It is an improvement area to move towards a Single Goal.
The team followed no estimates.
During the Sprint Planning, the team picked up items and created Sprint Backlog with the Goals for the sprint in mind. They forecast and pick items based on what is known at that point in time with the empirical mindset to inspect & Adapt. A safe environment was given to the teams to experiment and learn continuously.
The visualization of the remaining items in the Sprint Backlog is done through a simple Scrum Board in JIRA with a To-Do, In Progress & Done swimlanes. Work item age is the leading indicator the team used to identify bottlenecks and acted upon to ensure the flow is optimal.
Note: During the COVID-19, the team was able to agree on a coherent goal as the need of the hour was business continuity. It made the team collaborate and leverage the expertise within the team to solve most of the problems efficiently. Now the purpose of the coherent goal is clear for the team, and everyone acknowledged the benefits that it brought to the team. The team recognizes this will be the new way of working when normalcy resumes.
6. The result of the Daily Scrum is work being re-planned for the next day?
Initially started with task level updates from the team members, then moved on to goal-driven collaboration. Still a lot of room for improvement available. As the team has multiple goals, the Daily Scrum at times inclines towards updates rather than collaboration.
Room for re-planning the work is available and is done on a need basis. Even the team does the scope negotiation to achieve the Sprint Goal based on the discussion in Daily Scrum.
7. No later than by the end of the Sprint a Done Increment is created?
8. Stakeholders offer feedback as a result from inspecting the Increment at the Sprint Review?
There isn’t an increment in the team’s context. But incremental services are delivered through different types of services the team offers.
The IT function has multiple stakeholders to interact with. Some are listed above in the image below. At the moment, the nature of working is more transactional with the stakeholders. There is a clear identification to scale the IT services function to become more of thought partners with stakeholders.
The stakeholders attending the reviews are an improvement area. But the feedback for the services is collected through different surveys and different forums. Stakeholder interaction is
9. Product Backlog is updated as a result of Sprint Review?
10. Product Owner, Development Team(s) and Scrum Master align on the work process for their next Sprint at the Sprint Retrospective?
The sprint review is being done as a Collaborative feedback session with all the team members available. The team reviews the outcomes of the sprint with the leader and updates the product backlog. Mostly it is done with the help of a reflection tool to help people ensure the learnings in the sprint are sticky.
Also, to reflect on the experimentation outcomes, tools like celebration grids are used to celebrate the learnings of the team.
Sprint Retrospectives were made more productive with the effective use of tools. We try to keep it non-monotonous by blending different types of liberating structures — 1–2–4-All, Conversation Cafe, Max-Min Spec, etc.
Sprint retrospectives are ensured that the team aligns on work processes and improvement items are taken to the next sprint. Apart from this, the team also reflects on the people, and their relationship — Online Kudo cards are provided to team members to acknowledge people’s behaviour.
On reflecting on the entire scrum implementation, we relate to the below points of the continuous improvement model.
Improvements are based on small changes, not only on major paradigm shifts.
Individuals’ ideas are considered valuable.
Incremental improvements are implemented rather than big bang improvements
Individuals take ownership and are involved in the improvement
Improvement is reflective and potentially repeatable