I have been reading this book and I am fond of the way Ilan has managed to mix a right combination of his experience in Agile and his sense of humour. It feels like he is sitting in front of me and teaching the same.
This book is small and sweet. If you have been an Agilian like me then I would prefer you to have this book on your shelf.
Although, I have learned many new thoughts in this book, and I would like to highlight the top 5 points that I felt is quite interesting.
1. Define Your Technical Tasks as User Stories
Whenever I have been assigned a user story, I tend to create tasks in the form that one technical person would like to hear. However, it is quite interesting to read in this book that there is an another better way to define your tasks, i.e. Define your technical tasks such that it make sense to the Business (Product Owner) as well.
Well technically it makes no sense that Business People would like to know about these tasks. However, I guess it will be good to speak their language so that they can understand that we are doing tasks to accomplish actual User Stories.
Let’s put it in a simple way that every task should aligned with Business Value. Otherwise, it should not exists.
As a user I would like to create a shopping basket so that I can checkout more than one item.
Instead of defining your tasks as
- Database Layer
- Create Functional Test
- Generate Test Data
- Create HTML PAGE WITH CSS classes for Links and Button
- Create Server Side Component for Card Management
You might want to reword your tasks as:
- Develop a mechanism that persist the basket against loggedin user (including test design and automation)
- Develop a Add Remove Functionality along with number of items, that will add remove items from current user basket (including design, test, sample data).
- Develop Navigation Page Functionality.
The main benefit of this approach is, after a task is done you can actually show it to the Product Owner. It is because the user story has been divided into sub tasks that can work independently.
2. Definition of Done (DoD)
So far all I knew that “User Stories” needs “Definition of Done”. However, as per IIan book there are two other places where definition of done can be beneficial:
We should define DoD for Tasks as well. This way the performance against User stories can be measured. This can be used as a measurement tool within the team that specific tasks are done.
Release should have Definition of Done as well. That includes:
- All code related to the release has been successfully deployed to the production level.
- The smoke testing has been executed.
- End-users have been trained,
- The release has been accepted by the Product Owner.
3. GIFTS – Daily Stand-up Meeting
IIan has referred few techniques to remember his messages. One of it is: GIFTS.
Good Start, Improvement, Focus, Team and Status.
Making SCRUM meeting (infect any meeting) productive is as important as delivering a right product.
GIFTS emphasises some qualities that can be implemented for Daily Standup meeting.
Good start: Daily Scrum meetings should be about giving energy to the team; so don’t take debates or make your stand-up meeting as a problem-solving session. Instead, the energy should come from each member through the sense of purpose that they are working on and the urgency of delivering the same.
Improvement: If I ask you to remember the last question that Daily Stand up ask is – “Do I have any impediments or blocks?” This question is commonly ignored when there is no blockers. It is advisable that Scrum Master keep a note on that this question has been answered by everyone; even if it is “NO Blocker”.
After all, we cannot fix problems that we don’t know about so a large part of stand-ups is about exposing problems to allow us to improve.
Focus: Please keep your meeting to the point. There is always going to be some points, suggestions, that needs to be discussed. However, the focus of this meeting should be on current tasks in hands i.e. Sprint.
I also liked his idea of using ball (play ball) between meeting so that everyone is active in the session. Another point he has emphasis on making sure that the speaker is addressing entire team rather speaking to scrum master only.
Team: My way is right way – well technically I heard this point many time and I hate that when one cannot adapt on situation. I guess IIan is mentioning the same about having a good team is all it matters to have a successful sprint. Hence he is emphasizing on communicating, working, and helping each other by sharing obstacles.
Status: Here is an interesting take from his book:
The status (What did you do yesterday?) should have two sub-questions:
- How is the work progressing?
- Is there anything else interesting that the team should know?
Read more about this idea on page 108. And you will find on Page 110 that he has shared some thoughts on giving an award to the person who broke the build 🙂
4. Risk Takers and Mistake Makers
Five years back when I first got to know about Agile Manifesto, I honestly felt that what is so new about in Agile?
I’ve been improving since Age 1.
I have been communicating when I need food; either crying (baby milk) or by earning a bread.
One way or another Agile Manifesto has been here. But what has made Agile so special? And most importantly why people are not adapting Agile?
IIan has answered very well.
He has further shared his knowledge about how Facebook devs’ face the fear. There is a fear of Change, Fear of cross-functional team. Even I would say that Fear of Failure has made us to write lengthy technical documents so that we don’t leave any corners’; and we all know about how effective waterfall is!
Another fear he has talked about the Fear Of Exposure ; Some developers just like to be left alone in a corner to focus on their work and can become quite defensive about perceived regular inspection of what they are working on.
Agile emphasis on – What you make should be aligning to the Business Values. Thus, Agile and TDD goes side by side. TDD is about Test Driven Development that always force you write what is required. Agile is also the same thing about getting Business Values. Thus you will write code but only if it is required.
Fear of Making mistakes – Let me be honest here that I have been told that there should not be any bug in my code, otherwise, there is a performance concerns.
Let me be honest here again that if you are going to give me such environment that produces fear then my whole energy will drain into saving myself. I will not be any creative at all.
5. Some meaningful Matrix
IIan mentioned about the importance of two more matrices. These are:
Sprint Interference: That assists teams with their sprint capacity planning:
Remedial Focus: That enables team to gauge how much of their collective effort is being spent on bug-fixing as opposed to working on new requirements.
In conclusion, This book is simply a collection of breath taking truths that you have been facing in implementing Agile. There are many other good tips present in this book, such as – The Seven P’s – Proper, Prior, Planning, Prevents, Piss, Poor, Performance. However, I found that the above five points are quite interesting to read and I would like to implement this in my next Agile Journey.
And remember, you are learning, you are planning, and it is an ongoing process…
… Be Agilian, Be Productive…