After leading a SCRUM team for the last few months, these are my top 5 lessons learnt that I would like to share with anyone that is about to start this journey.

 

1. Not all programs of work can be delivered in Agile

An Agile framework such as SCRUM is great for software development and IT because of the short cycles. Most pieces of work is sized for a quarter and within those 3 months, value needs to be created every sprint (2 weeks). These short cycles allow for constant feedback and conversations on minimal viable product (scope).

If we imagine staging an EMS by splitting into capability and features, we can see how it can be delivered successfully under SCRUM. However, imagine staging nationwide infrastructure for EVPN. We can see that there will be many sprints that are just enablers. Value will not be delivered till an EVI is introduced and connectivity between two sites is confirmed.

Therefore, I believe a company should be flexible enough, to have programs choose the best framework to be delivered under. For the imaginary EVPN network above, it should be initially delivered under waterfall. When it is ready for services to be provisioned, these services should be seen as incremental changes and delivered under SCRUM.

 

2. Like in network migration, BIG BANG is always the quickest

If an organisation decides to only adopt an Agile framework, it should be adopted everywhere and at the same time. Similar to network migrations, BIG BANG is the most painful but it is the quickest to the end goal. However processes and departments that are not aligned to the Agile framework can influence the negative practise of “Waterfall in Agile”. This leads to a double edge sword, where teams are cutting corners due to Agile’s empowerment but introduce additional process to bridge a gap between the old and new frameworks.

 

3. Give your SCRUM team actual problems to solve

Agile believes in small autonomous teams that are empowered to deliver a solution that will bring value to the customer. However some individuals do not share this belief and refuse to take this leap of faith. So they introduce unnecessary roadblocks and processes.

Trying to put myself in their mindset, I can imagine some scenarios will influence technical members to sacrifice quality to meet certain deadlines. Also some members will have tunnel vision on their EPICs and introduce changes that will impact the stability of a network.

However locking down the architecture and forcing teams to deliver copy and paste solutions is not the answer. Great engineers will not be challenged and will leave the company to protect their careers. So a compromise needs to be made. I propose business problems should be given to SCRUM teams and a mechanism to seek architecture; operations and security endorsement should be implemented. Therefore engineers will receive fulfilment from their work and changes to the network will be properly assessed.

 

4. Documentation is still king

It is popular belief that Agile is anti-documentation and I have observed the effects of this belief at a previous company. Agile actually believes in the right amount of documentation to be delivered at the right time.

Is there still value in traditional documentation such as High Level Design and Low Level Design? These documents provide great value in Waterfall but are perceived as overhead in Agile. Especially for programs of work that are introducing minor augmentation to existing services. However, lack of documentation leads to tribal knowledge and after 1-2 years of high turnover, the side effects can be catastrophic.

To mitigate this, I believe it is best to evolve these documents. Engage the end users and reassess the purpose of these documents. Make them relevant and lean so they can be delivered in time instead of becoming a casualty of Agile.

 

5. What is my velocity?

In SCRUM there is a concept of story points and velocity. These values are personalised to a team and promotes continuous improvement. My team had a difficult time deriving the initial numbers as we had no starting point. After many attempts, I believe the following process outline below can help other teams come up with these values.

• Story Point

My definition: A story point is a unit that reflects the amount of effort required to complete a user story. It should capture both time and complexity. It is personalised to each delivery team.

After an EPIC is broken down to user stories. Identify the smallest user story and give this the least amount of points in your chosen scale. Then compare all other user stories to this initial story and relatively estimate their size. The whole team should play story point poker to capture the complexity and capability of the team per user story.

• Velocity

My definition: Velocity is the number of story points a team can deliver in a sprint. The end goal is to keep this velocity consistent and gradually increase it over time.

To initially work out a team velocity, a team can do a trail run of sprints to eventually capture the average velocity over time. However some companies want to perform excessive upfront planning. So the alternate method is to reflect back to waterfall and compare a task that is similar to a user story. This task would have taken a certain amount of person days during waterfall. Using these values, we will be able to calculate a ratio between story points and person days. Finally, use this ratio and multiple it to the capacity of your team per sprint. This is now a very rough estimate of the team’s velocity. Once the team have performed a few sprints. A more accurate velocity number should reveal itself.