InsideSalesBox is a startup within Drishti. So everything started afresh – market, product, team, product management and everything else. Until a few months ago, the discussions between the devs and PM used to frequently revolve around the roles, responsibilities and accountability of the team. We started referring to the tons of Internet articles on agile teams to answer the questions. Getting these answers in bits and pieces meant that we were frequently hitting conflicts before solving them. If agile had answers to most of these, then why not scale our team with the principles of agile. And that very decision marked the beginning of a change. We started tasting agile in its true flavors.
The words Agile & Scrum were not new for us; we adopted scrum methodologies like delivering in sprints, conducting daily stand-ups, sprint retrospective at the end of every sprint. An external trainer, Deepti Jain, conducted an assessment to determine how good we were at delivering results as a team. Fortunately, the result of the assessment showed motivation among team members to deliver better results. However, we could judge that we were not bearing results proportional to our efforts.
We wanted to eliminate any ineffective practices and implement a transformational change to establish agile practices. The moment we implemented the changes, everyone in the team felt the positive results. I’ll talk about each of these.
Understanding the Philosophy Behind Agile
Change is inspiring but it is also challenging. The first change that we implemented in our system was to understand agile as a whole and not as a collection of methodologies. Every process that we adopt now has to be in accord this philosophy. So, every action is evaluated against the philosophy of agile – if found fit then we go ahead else modified it or dropped it. This is our reliable touchstone now.
Either Everyone Transforms or Nobody Does
When you go agile, all the team members including the stakeholders should be a part of the assessment, training, coaching and all the sprint ceremonies. We feel that such a practice encourages every team member’s buy-in for the decisions that are taken during and after the transformation.
Trust
Agile runs on trust. Traditional teams run on management and fine-grained processes. While we trusted each other in spirit, our roles were variable. Therefore, we went ahead to bring out some changes. For example, instead of just having the team-leads doing the estimation for the sprint, we chose to involve the entire team with the belief that nobody would want to over or underestimate. Transparency further helped to build up this trust.
How much management
The team-leads were spending a lot of time and energy in managing the people as a part of their responsibility. The team-leads did large part of the daily work planning for team members and at the same time ensured timeline achievement. Many a times we were struggling with the timelines and hence never felt confident without the TLs putting their mind into it.
Agile suggested otherwise – the team members should be able to manage themselves and the TLs should be happy spending more time into real work. This meant that team members could take the help of TLs whenever it is required. However, TLs would not push them.
Some questions that came up while we were thinking to implement this practice were– Is our team ready for this change? Would the change bring out the best results? Our agile coach helped us to find the courage to take this big decision. She suggested that we should be ready for some failures within the first few sprints. So, we went ahead to implement the change. In fact, we flattened the team hierarchy completely for a sprint. It did wonders – people felt empowered, opened up and owned the timeline. No more daily work assignments – team members knew what they had to do – else they asked.
Transparency
Agile methodologies are based on the ideas that teamwork is important to delivering a great product. Nothing is more pleasing than sharing out the experience of building a product along with your teammates. Every thought about the product, team, market fitment, the good, the bad and the ugly should be shared transparently with the team. This sets the mood for active participation in all the sprint ceremonies.
- Objective feedback to PM on the completeness, depth and quality of user stories
- Feedback on the final delivery at the time of sprint demo
- Retro (Retrospective) – What was great? What would have gone well? What we want to fix now? What do we want to live with now?
Success/Failure is Determined at the End
Sprints are such short cycles, that if a team member isn’t headed the right way, you need not correct him or her every hour. The sprint end success or failure will be a transparent measure. Everyone aspires to be successful and hence the team member will look for course correction himself or herself.
Time Boxing Every Event of Sprint
The first thing we decided was to schedule the sprint duration. It is said, “Great things are done by a series of small things brought together”. If you follow the most accepted 15-day sprint cycle, then it would mean there are about 10 working days. Sprint Planning Meetings, Daily Stand-ups, Backlog Refinement Meetings, Sprint Demo, Retrospective – all this would mean that the entire team would be spending time in these within those few days. It is important to time box each of these. Start a timer shorter than the intended duration so that everybody knows when time is about to be over.
With all these new changes, the sprint completions reached nearly 100% in no time, sprint demo started happening on the scheduled date and the quality of the deliverable improved considerably. New agilists emerged in our team. The sparkle of agile is now predominant and our team simply loves agile.
The change that our team envisioned is the change that we have now experienced – we have achieved agility in our mind and that keeps us going to achieve more.
kossip - by the people behind Ameyo: On technology and beyond 