5 Agile Tips / Techniques
On my last article [link] I talked about principles and my reasons for choosing Agile. This time we are going to talk you about some Tips and Techniques which are going to change your day-by-day work and productivity.
Do you wanna start rolling out to improve your work? Here I’ll share 5 overview Tips/ Techniques to go for it:
- JOBS STORIES vs USER STORIES
Since I have worked with scrum for the first time User Stories have been one of the main and most important concepts around –you know:
As a [type of user], I want [some action], so that [outcome] (fig.1);
which is great because it focuses on implementation and then people start working around “who” and “how” but what about “why”? We completely missed out, because of all the assumptions we have made in the middle of the Slicing process. So, in order to avoid those assumptions, we shall start working with the next sequence:
When _____ , I want to _____ , so I can _____ (fig.2).
Instead we focus on the trigger event it’s all context and causality and as you can see is focus on motivation rather than implementation.
2. CRASH PARTY
- If you had to guess each crash monetary cost, what would it be?
- And the effort spent on finding, fixing and testing bugs?
- What about the client behaviour getting the app crashing on their face?
This tip is going to help you reduce these problems in a fun way. Just pick up the entire team (dev, BA, UX, QA), the stakeholders, and the client all together for one hour for breaking the app. What is the motivation/objective of breaking the app in front of your client, you may think? 3 things for start with!
- We are going to work in pairs (1 QA & 1 Dev or 1 UX & 1 stakeholder, etc).
- Each team will get points/scores for each crash, bug and minors they find.
- The winner takes the trophy. (Motivation)
3. GOOD, BAD, UGLY
Through this technique the team will be able to write up their thoughts on post-its or any small sticky papers and put them on the board. If there is a time constraint, then here is the place to save time by asking people only to write one note for each column or limit them to a total of 5 notes or something.
Anything that makes them internally priorities. If time is not a problem, them let them keep posting until all ideas have come out. Then let everyone vote. Select those with the most dot votes –We usually aim for three. Ask the team to identify a ‘Long Term Goal’ and a ‘Short Term Action’ for each topic.
For example: Long Term Goal — Build is never broken; Short Term Action — We will write a Code Commit Checklist and everyone will follow it before committing their code.
4. SLICING PATTERN by WORKFLOW
Why ? More work fits in each sprint, easier to parallel work, reduce risk of not delivering value. Slicing allows us to define the work to be done in many small parts where each adds tangible value to the business quickly and of course is easy to understand and offers feedback and many of this patterns exist,
for example:
- by Workflow,
- by Business rules,
- by Major Effort,
- by Complexity,
- by Data,
- by Entry Methods,
- by Platform, Generic/Custom,
- by User, Spikes.
Remember the I.N.V.E.S.T. principle should always be respected. (If the scope is too big, split. If it is not enough, spike.)
5. RETROSPECTIVE DOC TEMPLATE
Retrospective meetings were incredibly useful because they made us all take a hard, honest look at what went well, and what didn’t. We learned from our mistakes and changed/added things based on those mistakes.
The team has considered how things went in the previous iteration and how to change the process. Sort of a constant tune-up of the process.
At the same time, this is imperative to take record of this session. How ? Just create a “Retrospective Doc Templates” ready for the actual session to keep everything on track, and, at the same time take bring on the table the previous session actions and goals. Remember the next doc’s structure (check out doc).
- Previous Sprint Goals.
- Previous Sprint Retrospective (Keep/Stop/Start doing or Good, Bad & Ugly).
- Sprint Retrospective (Actual — same method)
(View Doc)
Conclusion: As you can see Agile and it’s artefacts are simple but not easy, so we must make sure we put this into practice so we can integrate it into our daily work. Remember that we must commit to the process to achieve our goals.
