Scrum is no doubt a great methodology, that work most of the time. I have been using scrum, since long; for product lifecycle; entire my career (atleast most of it ;)). But in some cases it does fit into (if you exactly go by the books). Specially when one have tight deadlines, deliverables and bug fixes.
In those some cases one can get most out of it; by tweaking it to one’s own use. Lets assume a scenario as mentioned below:
1.) Having tight deadlines for deliverables.
2.) Having widely distributed, small teams (consisting one or two resources at most).
3.) Some resources are/may not (be) aware of collaboration tools being used.(e.g. no vcs tool exposure, never worked in agile teams)
4.) Not every team(since being small team) have a go getter resource.
Now every product owner have a dream of having dream team, but in reality it’s not 100% possible. Recruiting best talent, for required task; technology stack is itself a tough task. Mentoring, training under developed resources is time consuming and non productive.
These challanges can proove a hurdle, for 100% implementation of Scrum methodology. But by tweaking Scrum, for special cases, we can increase productivity.
Here we go for every phase one by one
We devise some roles play for our approach:
Product Owner: person who owns the product and/or has good domain knowledge.
Technology Stack superstars: Resources who has in depth knowledge of respective technology stack. (i.e. Designer, Developer, DBA). These will also act as scrum master for their own domain knowledge.
Scrum Master: Resource that integrates entire distributed team.
- Stackholder: Product Owner
Product owner prioritize features from backlog to the top of backlog (Priority needs to be done, keeping two sprint cycle expectation in mind)
- Why: By only having product owner as stackholder. He has freedom of choosing features he wish to see developing in next two sprints.
Sprint Planning Meeting:
Stackholders: Product Owner, Scrum Master, Technology Stack superstars
Why: Product owner can take advantage of actual ground realities and complexities of features in backlog, by taking inputs and initial estimation.
Get early estimations and complexities experienced resources.
Reassess/Reprioritize/resuffle two sprint backlog.
Divide features into logical individual implementable entity/unit.
Identify, asses and assign: for each unit; identify a resource that can get it implemented with best practice, after taking inputs from each stakeholder of this phase.
Devise a strategy for development best practices/approaches for each unit.
Note: Reshuffle/Re prioritisation only happens for two sprint backlog planned by product owner.
- Stackholder: Every team member
What: every team member will be given a responsibility to estimate each task in detail; for a sprint backlog. Asses and assign: give due onsideration to task (in meeting itself) can be assigned to best capable resource.
Why: By asking everyone to estimate, one will get insight of team members individual capabilities(in some manner)
Start a Sprint
In daily scrum meeting ask typical three qus. 1.) What have been worked upon/progress so far 2.) What is being worked upon 3.) Roadblocks if any
Now first two questions can be proceed as usual. On third question, being asked about roadblocks. If a team member reports a roadblock, other team member, who has good understanding of topic/module asked about, can explain best way to resolve for or bypass roadblock.
If member (facing roadblocks) does not understand issue very well, swap or reassign tasks.
- SWAP: If both member understand each other’s task
- REASSIGN: Assign blocked task to member who understand it very well, and assign some other task from backlog to other member.
This way one don’t waste time and it boosts up productivity as well.
Happy Development <3 <3 <3