ScrumFit Agile Framework

ScrumFit - Micro Agile Framework

Mate…if it’s agile, then it must be scrum! We heard this. Right? Many teams cutting across organisations are embracing scrum framework of agile. But does it really suit you and your organisation? It’s a question which only can be answered after performing wide ranging experimentation.

As consultants, we have seen that scrum has few blocks that can make the lifecycle sober and not-so invigorating. Some of the areas where scrum was found wanting are:

1)A product which serves high volume of customers has a bigger team and scrum begins to creak under such load. It is difficult to follow scrum if team size grows beyond 10.

2)In scrum, requirements are intangible (only words). Requirements/stories/issues are gathered, refined, priority is set and time boxed. Development team doesn’t have tangible feel on the requirement to precisely come up with effort estimation analysis. The nature of scrum is subjective to say the least.

3)People say scrum is liberating by allowing innovation. In fact, we found it was partially true. The scope to innovate is less in scrum. A team deals with backlogs, sprints, reviews, etc. People are only going through motions.

Demands from customers are incessant and heavy competition virtually in every business vertical. Customer retention ratio is under pressure like never and it may wane due to delayed deliverable.  And to top it, there is a compliance angle. That’s why frameworks must accommodate and enable clients to deliver value to the clients and adhere to compliances as well rather than holding them back.

Agile is the centrepiece to whatever we design. Hence it is imperative that it delivers what it promises- build, ship, run, and gather feedback…rinse & repeat with no fuss.

As aforementioned above, scrum has few deficiencies. Also, we have seen customers monotonous approach of participating in agile ceremonies resulting in denting the Agile model. We did research with the multiple stakeholders of the customers and based on the inputs, opinions and suggestions, we have designed a custom framework in tune with the essence of Agile methodology intact and seeded ScrumFit as our approach for putting up a framework.

How is ScrumFit framework model evolved and worked?

 “A picture is worth 1000 words”. All of us heard this many time. Well, that is so true! Idea is precious and it is important to convey it well. In our approach, we took this as very important step to induce more passion in team’s participation during the agile ceremonies.

Communicating ideas through words can go wrong due to multiple reasons but not limited to

1)Bland & Ineffective communication. Not everyone is charismatic with words and stuff.

2)A person can underwhelm or overwhelm an idea with poor communication skills. It means, a person can undersell or oversell an idea.

3)The biggest challenge is misinterpretation at times by people who are trying to understand what the idea is all about.

The above are few pitfalls associated with verbal communication. A picture or visual representation can overcome limitations stated above. As part of the framework designing, we started with prototyping stages involved in Agile workflow. We have charted six steps as part of the framework.

ProFiling

• A product owner has the following responsibilities
• You must get pivotal details like profile of your end users,
• Their requirement,
• Context of their requirements,
• If any competitor has come forward with such requirement,
• Is any requirement already part of the backlog?
• Can requirements from the backlog support these new requirements (basically, does this new requirement have any link with the already existing ones)

Answers to above details would give an idea on nature of requirements (effort and time estimation mustn’t be computed at this stage. It must be effectively left blank at this stage).

BrainStorm

Ideation is the sole purpose of this stage. This stage is open to every stake holder and each person can come up with ideas that can deliver. The following points must be answered by a person who is submitting an idea.

• Idea name
• Purpose
• How is it going to be implemented?
• Any possible leak this idea might bring about after implementation (a person must forecast potential blockers)
• Dependency factors- on people, processes, tools, artefacts, etc.
• What value will this idea bring?

o  More ARPU?

o  More MAU?

o  Seamless transactions?

o  Less latency?

o  Better UX? Etc and can be more

CherryPick

A poll would be conducted, and best idea would be chosen. Stake holders can vote for their candidate, but he/she must provide a proper justification on why they feel the idea they have chosen is better than others? The reason must technically sound and it cannot be subjective.

MagicSpell

In this stage, a team works on translating idea into an MVP. Precedence must be given to utility rather than prettiness or perfection.

BioScope

MVP created in previous stage is showcased to end users. In this way, end clients would get a tangible feel. This is nothing but a mini-A/B testing. A product owner would be receiving multiple data points which would be used in refining the requirement.

BallRoll

Product Manager and his/her team by now know the effort required to complete the job, and they must come up with effort & time scoping to complete the same.

The above approach has few advantages when compared with scrum philosophy

• Team would understand whether the requirement is really that valuable or not. If it isn’t, they can scrap the requirement right away and focus on next important requirement.
• Resources are allocated to requirements which brings value
• Requirements are made tangible rather than being just some description.
• People in this process are liberated to come up with OOTB thinking. They are now not just going through scrum motions like a robot, but now they are brainstorming. This is a huge shot!

How to structure story types?

We would like to propose a standard structuring of stories in JIRA

Epics- A big story which will act as a container to multiple stories/issues. Based on the epicness (size) of the epic, a duration must be set- start date and end date. Epic’s progress can be tracked with epic burndown chart. The chart must never be linear. It must traverse down with no sharp spikes.

Sprints- Sprint is a time boxed module working towards completion and overall completion of epic. Like Epic, sprints too have burndown chart. As aforementioned, it mustn’t be linear. It should traverse down without sharp spikes.

We will standardise release window based on the organisation's preference.

How teams are created?

As aforesaid, products with bigger customer base have bigger teams. We propose to split the teams into smaller teams. For example, the teams would be split into multiple smaller teams by their functionality.

A bigger team is split into multiple smaller teams grouped by the area that they work on. For example, under Android grouping we can see two sub-groups. Sub-group A works on some aspect of android app of X app team, while sub-group B works on other aspect of android app of App team.

Each sub-group has a product owner and these product owners report to a main product owner so that everyone is aligned and apprised with overall progress. This helps immensely for the big teams and if the control is centralised. The dependency factor will be at its peak if just one PM.

Hence, the team should split into multiple smaller teams with product managers for each one of them. Each product manager was given the task of handling a certain number of applications. Person A became responsible for XXX related application support. While Person B became responsible for another application support. While Person C became responsible for OS related tasks. Like that teams were created to fasten up things.

The local product managers are clearing service level incidents for their portfolio of applications without traversing hierarchical food chain. The local product managers and their teams are responsible for how they support their portfolio of applications. The task was clear to them- maintain SLAs. It is up to them how they maintain SLAs.

We practice implementing above stated structure for development teams. In this approach, product manager will dish out user stories and his/her team must come out with ways to deliver user stories to LIVE environment. The operations team will be common across the organisation. Their job is to lay down the path so that application teams will deploy artefacts by themselves. They will help application teams in automating infra and software configuration management.

Result - We have been practising the redefined and practical approach of ScrumFit Agile framework model and we can say it had killed sober feel of just meticulous scrum model. We have seen more innovative ideas were coming out and increase of the accountability. We have been creating microservices model framework suiting organisation’s structure as one size doesn’t fit all.  

Trust the above is useful? Very keen to have experts guidance and opinion.

Kindly talk to us to know more and how we can transform your organisation ‘s Agile Model.

Thanks ? Infoseption