The Joy of Doing
By Bachan Anand / Filed under Inspect & Adapt, Scrum / January 8th, 2013
Dreams are Exciting, Plans are Exhausting,
Attaining is gratifying – Doing is Joy!
How often have we come across people who keep going on and on about creating something beautiful and rare that the world has not yet envisaged, but never take a single step to bring themselves closer to achieving it?
All of us have beautiful dreams, but how many of us have really been able to put them into practice? There is no end to the plans one can make, for the masterpiece one aspires to create.
Contemplating a vision without putting any significant effort into realizing it, in truth, burdens us more than the effort required to accomplish it does. The idea we spent hours fantasizing on sometimes chokes us as it struggles to escape, and unless we give life to it, we will find no peace!
The same is true in the context of work as in life. Sometimes, despite the huge amount of time we spend on exhaustive and detailed planning for a project, trying to foresee the hurdles that could crop up, we still find ourselves unprepared for the uncertainties, inconsistencies, feedback and other factors that creep in during the actual implementation. The time spent on planning remains unjustified, and the time spent on implementation, insufficient.
Very often we are denied the joy of a completed task because we do not check to see if we’re on track. After all the time spent on planning, at the final stage, we realize how far we are from the product we dreamed of making, or how low its quality is. The end result? No satisfaction from work.
Scrum, the most popular of the Agile methods, seeks to remedy this situation by considering a subset of the entire project at a time and inserting checkpoints at frequent intervals in the life of the project, using Plan – Do – Inspect – Adapt cycles. ‘Plan’ takes into consideration only a small set of features or aspects, thus providing more time for the ‘Do’, the actual implementation. After ‘Do’, it is time to take stock of the lessons learnt (‘Inspect’) and check coordinates to see if we have strayed from the goal, make corrections or modifications in our approach(‘Adapt’). Then the cycle repeats. In Scrum, these steps are known as Sprint Planning, Sprint, Retrospective and Sprint Review.
The Scrum way of working takes into consideration the human element – satisfaction from work inspires us to be productive, without compromising quality. The essence of Scrum works at a deeper level alongside human thought process and emotions. There is contentment in doing things, because of the impact of working in the Scrum fashion.
So what does this method help achieve?
Quite simple.
The happiness that comes from creating your own masterpiece.
The satisfaction of making a product of excellent quality.
The ecstasy that comes from a work well done.
The Joy of Doing.
With Gratitude
By Bachan Anand / Filed under Collaboration, WORK is GOOD / November 21st, 2012
Just like the past two years, 2012 was full of action and change at Conscires and in our personal lives. As I find professional and personal life deeply inter-connected, here’s what I am grateful for in the past one year:
1. Conscires becoming a fully profit-sharing company.
2. Adopting peer-rating as a way to give feedback to each other on how each person is contributing to the company.
3. Evolution of the Pay-it-Forward Training model, as five more trainers (Derek Wade, Lizzy Morris, Lola Stice, Sanjeev Raman, and Savvy Katham) joined Pay-it-Forward Training across the US.
4. Conscires India being very successful in its first year of operations: Training around 700+ folks across 8 cities in India.
5. All our training partners in India who made our first year of operations in the country relatively effortless.
6. I am grateful for being able to do Scrum trainings in my home town, Trivandrum, and to my Uncle and Aunt for attending the training.
7. Grateful to my daughter, Thumbi, for filling our life with joy, laughter, and certainty and helping me to be a little bit more patient with life and reminding me to not take it too seriously.
8. Grateful to my wife, Rahmi, for continuing to find resources to read that enriches our life and continuing to challenge me and help me grow.
9. Grateful that we could slow down life after our move to India.
10. Being able to work with some of our close friends and still continue to be friends with them.
11. To our friends in India, especially to Indu and Neeta and their lovely families, for their support during our move to India.
12. To all our friends we happened to share a meal, sleep under the same roof, and spend time with your respective families in the past year.
Thanks, again, one and all! May you and yours have a beautiful Thanksgiving!
The Power of Visualization
By Bachan Anand / Filed under Agile, Scrum, WORK is GOOD / November 5th, 2012
A couple of months ago, a friend asked me for directions to my house. I sent out a detailed email, listing out the landmarks he should look for, the turns and exits he should take. My directions were impeccable; nonetheless, he landed up two blocks down the street. The next time I had to give directions to another friend, I sent out a hand-drawn map that I had scanned and kept ready. There was nothing new in it that I did not mention in my first email, but this friend found the way to my house without any confusion.
The impact of visualization can be illustrated with another real-life example. If you tell a small child that ‘an apple and a tomato have the same color’ he would probably blink. Instead, show him an apple and a tomato and then tell him the same, he would immediately get what you’re trying to say. It is an inherent habit that we all possess – the ability to grasp and recollect faster when information is demonstrated rather than explained verbally.
We see it in action everywhere, yet we close our eyes on its significance. We can apply it on any task that consists of a set of activities. For example, recently my wife and I utilized this method to plan and manage our monthly expenses. The exercise turned out to be quite effective and fun at the same time!
If we translate this concept to work, every project or activity that involves a set of steps can be further broken down and made into visual sequence. For most of us, reading a lot of continuous text, even beautifully bulleted ones, requires a lot of effort – that could as well be the one reason we put it for later. When there is a pictorial representation, the effort required is less. The pictures, colors and shapes jump out of the screen and impress themselves right onto our brain. It is next to impossible to ignore or forget them! It also has the added advantage of providing clarity on the complexity of the task in question. With clarity come determination, focus, the ability to prioritize and remove what is out of scope.
It is a fact that the tougher a job looks, the more lethargic we become. Even the easiest tasks can be made to look complicated by converting them into ten-page documents. On the other hand, illustrations, with colors and shapes thrown in to distinguish between their priority and status, give the impression that it is easier to achieve and help to keep the goal firmly in mind.
Taskboards, story maps and vision boards are visual depictions of a project. With one of them at hand, there is no fear of losing sight of the target or diverting from the path. They also show how close the work is to the end, and as such, act as motivators for the team.
The advantages of having a visual taskboard are many-fold.
For an individual, breaking down of a bulky task to smaller chunks, having a visual indicator of progress and setting aside each completed activity are steps that bring him closer to the target. The visualization gives a clearer picture on how much work is pending, what has been completed and how close we are to the end.
For the team as a whole, visualization creates a common understanding of the goal, gives clarity about the many pieces involved in solving a problem and helps each individual pick up tasks they can complete.
For the project, this method of depiction ensures that all the aspects are captured properly, and it avoids concerns of never getting around to address some of the items in the list.
From the leadership point of view, it is perhaps the most effective and visible way of communicating the mission of the company and rallying the overall organization around the company’s vision. The leadership, in turn, gets a glimpse of the progress that the teams make towards the completion of goals.
To make all these possible, it is essential to keep the visual tool clutter-free and up to date so as to make the most out of it. Once it is created, it is easy to weed out redundant or irrelevant data which may create a negative impact.
Vision is indeed the most powerful of all our senses. The easier we make it on our eyes, the better it engraves itself on our brain. After all, there is a child in all of us!
Top 10 failure modes of a Product Owner
By Bachan Anand / Filed under Agile, Scrum / October 8th, 2012
Top ten Failure Modes of a Product Owner – or, in other words, What are the mistakes a Product Owner is very likely to make.
1. More focused on People instead of the Product
The Product Owner has to be more focused on the product and less on the people. It is the ScrumMaster‘s responsibility to be people-centric.
2. Not able to manage stakeholder expectation
The Product Owner has to grasp and manage the stakeholders’ expectations and priorities, and act accordingly. Any failure to do so would steer the team off the desired path.
3. Fails to communicate the product vision
The Product Owner is the most important link between the customer and the team. He should ensure that the team understands and works towards the product vision.
4. Fails to communicate the reality to stakeholders
Product Owner communicates the reality of the project, its progress, bottlenecks and so on to the customer and other stakeholders.
5. Disconnected from the team
If the Product Owner is a part-timer or a person who is often pulled in different directions for purposes that are not directly related to the project, he will not be able to regularly participate in team activities and planning meetings, and provide support and encouragement to the team.
6. Unbalanced level of involvement in the project
The Product Owner has to properly involve himself in both the team activities and customer interactions. If he is not at all involved with the team, the project dives into chaos. Similarly if he is too engrossed in the project without making himself available for the customer, the customer loses touch with the project status.
7. Unavailable Product Owner
If the Product Owner is not available for long periods of time, the necessary preparations will not get done and decisions he is expected to take get delayed, thus further delaying the activities of the team.
8. Lack of Understanding
The Product Owner cannot be true to his role if he does not understand the Scrum framework or the needs of his customer.
9. Not empowered
There are several business decisions the Product Owner should take. If he is not empowered to make them, the project would not progress on schedule.
10. Fails at prioritizing and refining customer needs
The Product Backlog is an important artifact owned and managed by the Product Owner. He needs to understand the customer needs and priorities, and continuously refine them as per the circumstances.
Pair programming
By Bachan Anand / Filed under Agile, Collaboration / September 6th, 2012
Pair programming is an Agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer (or navigator), reviews each line of code as it is typed in. The two programmers switch roles frequently. [ Wikipedia ]
An often repeated argument against pair programming is that it consumes double the effort (‘man-hours’) to finish a task (since two persons are involved) than when a single person is working on it. The alternative cited is a review-cycle by one person following the completion of the task by the other.
However, I believe pairing up to work on a goal is more effective than ‘one finishing it and another reviewing it’. The reasons are:
-
When we pair up, there is a joint ownership of the objective and the task: in other words, a sense of ‘We are doing it together’ as opposed to ‘I am trying to verify or correct what you have done’.
-
When we pair up, it is not necessary that one person sits idle; there are two brains at work, and one person is at least thinking if not acting on solving the problem.
-
When we pair up, review automatically happens instead of it being a separate activity.
-
Pairing is ‘team work in action’ instead of solving problems as individuals - ’I will do it, and you can tell me if I did it right’ is the mindset when one person does the work and someone else reviews it, whereas pairing is ‘Let us think through the solution so that we can make sure it meets the standards’.
