Tag Archives: Agile

Agile governance: Part I (Need)


I am working with a client to achieve Org level Agility and methods to sustaining it. It should be such that once I am out of the system, and which is going to be real soon, they should not miss me, they should be self-reliant and be able to drive further changes themselves. In this transformation journey, I will be working with Process, Quality, Tools and Support teams in conjunction to development teams, Product Management group and other enabling bodies (Like UI/UX, Technology Experts, and Architects etc). We know why Organizations need enterprise Agility, and in this blog I am reflecting on factors that ask for Governance to keep Org level Agility intact.

For any organization to achieve enterprise agility or sustain it, governance is an important consideration. In case of technologically advanced and innovating Start-ups who are multiplying workforce and products every year, it becomes difficult to maintain their INTRINSIC Agility. They can only get away with fairly informal governance when they are small, but as they grow larger, they cannot function effectively without formal controls in place.

As a Transformation Agent, my goal is to find the right balance between the complete chaos of no governance based lean Start-up and the overpowering impact of governance on Agile benefits.

Let’s have a look at factors that call for the need of Governance:

  1. Disoriented and disengaged workforce:

The initial group that forms the Start-up is highly motivated, they create vision and mission. But as expansion happens, new people joining workforce might not share vision and mission of initial group. Naturally they will not have same passion, same accountability and of course clarity of vision and mission. There arises need for clear directions, enrollment of new folks into company’s vision and mission. This also creates need for few guiding roles like leads, PMs, Domain Experts etc, which were not needed earlier.

  1. Disconnected focused groups:

When team was small, everyone was doing everything possible, and if not possible, then they learnt to make it possible. That is secret sauce of success for Start-ups. But as they grow, it becomes difficult for everyone, on same BIG team to even know everything. Teams start needing resizing and reorganizing. Doing that is not a problem, but keeping them connected, so that you don’t form silos, so that they still roll up to same vision and mission – that becomes a challenge. So you need some common grounds where they all meet.

  1. Increasing Knowledge Gap:

With creation of focused group, and new people joining workforce, the valleys and mountains of knowledge gap starts emerging. If that is not taken care, it starts backfiring complete strategy.

  1. Missing accountability:

With the smaller group, everyone is doing everything and ensuring the delivery. But with the bigger group and wide range of people (motivation, engagement, focus, knowledge) the chances of missing something important is very high because group accountability starts fading in case of bigger group, and so there comes the need of process that ensures that every check box is ticked. This will give rise to a few new roles clearly defined responsibilities ensure accountability of delivery group.

  1. Need for a Product visionary group:

There had always been a product visionary group, the same group which found organization and let it’s developers to create that wonderful product. Product creation is one aspect and taking it to market, finding clients and living up to their expectation is another. Many Start-up die at this very stage, and those who make it, they struggle with growing customer base. Once these two are achieved. There comes third stage, and which is expansion. With expansion comes the need to clearly communicate vision of company, and separate management of different sub-products / new products. And this can’t be done by initial group of leaders. Its like using same light source everywhere. You need more of them, not the visionary, but their mirrors. This group is called Product Management Group, which takes feed from multiple product stakeholders, treat developers as well as stakeholders, and create 80-20 principle filtered features list.

  1. Better Product Support Group:

Initially this was also part of development group’s job. It was definitely served best this way. But with time team changes, team grows, product line grows, product architecture changes and almost everything becomes so big, that a need for new group that can respond to the P1s and customer calls on priority arises. With multiple teams in existence, there is always confusion about who should actually be fixing the prod bug, and so there has to be one support team that fire fights, and fix it, and then later finds the real culprit (not to crucify but to ensure safety in future).

  1. CI Tools Group:

If you talk about speed and have to bring in automation and CI, and hence, not very big, but a team to manage and support these tools is needed. This team also ensures that everyone adheres to the tools usage process.

These are few top of my mind factors calling for some regulation and checks and balances in place. In the next blog I am going to talk about the paradox here – Agility and Governance. Agile means decide as per need of team, product, customer, so that you are flexible enough to accommodate change; and Governance means controlling and directing; and it was this control and directive approach that killed creativity, beauty of human connection and welcoming change for customer satisfaction, which gave birth to Agile. So we’ll talk about in next blog about Agile Governance.

The “Sir” conversation

Back from Agile India 2016. Most prestigious, India born international Agile Conference, a must go for everyone who really want to know real world Agile, and I must admit it was one of the best conferences so far. Why best – great talks, interactive talks, and all of them offer different flavors – some last for a month, others stretch to quarter or year, and a few even have potential to become flavor for a lifetime. Organizers know what it takes to pull the show, trading sleep for dreams. But one thing that always turns me off is that everyone is busy in those fake conversations where they are just trying to make an impact on others, make their presence felt and looking for quick fixes for their problems – new Job, consultant, and all sorts of AgileFAQs. People don’t really understand what these conferences are supposed to give them. You get everything in books and papers and videos, then why waste so much money and go to these conferences? Just to do that “Hello Sir, I am another brick in the wall, please use me as appropriate”. I call them sir conversations. Everyone is more or less busy in Sir Conversations. So what is it that I look forward for in these conferences, and how they help me in growing?

  1. Inspiration.

These conferences are like windows to the new world. The world which is already (doing so much), or trying to do, or struggling with. These are all opportunities. These conferences connect me to those opportunities and inspire me to do something more, live each day extraordinarily.

  1. Perspective.

So I could not have known why Adam and Eve shouldn’t have tasted that apple, and why ships can you beyond horizon without falling from the edge of the world. If I was not there, like many others, I would have invested in Church’s ticket to heaven. My perspective changed; I could see things, which within my box never existed.

  1. Connection.

We all thrive for connection; civilizations cease to exist if not up-to-date with world outside. Why do we want to connect, why the hell we can’t be just with assigned people, why can’t we just stick to script? But the fact is we can’t. I am sure we all have better friends outside our teams and work places, we can’t stay limited by our work boundaries nor for that matter manager’s instruction to build a better team, stay connected to assigned team.  I get depressed if I don’t get to meet and talk to people who bring some freshness in my life. I go to these conferences to meet such wonderful people, and not to those who can help me with a new assignment.  Opportunities automatically follow those who have right skill and attitude, and you can’t develop new skills, knowledge without seeing places and people around, without being open. (Don’t confuse this with collaboration, not going there).

I hate The Sir conversations, I am a social scientist, I love connecting with people like me and unlike me which inspire evolution inside me.

You don’t have Agility if you don’t have it at Enterprise level


Have you ever felt that your Scrum team is a power-puff, super performing team, but it fails as soon as it comes to collaborate and take feeds from other teams in the enterprise? Do you feel that you always get approvals from your Technical Architect unit but show stops when it comes to take approval from Enterprise Architecture Team? Did you ever find that various organizational processes derail your Agile development train, and breaks momentum of your team? Does all this demotivates your team and hence your team fails to see benefits of Agility, which in turn breaks confidence of your management in giving approval to Agile Product Development methodologies?

If that is your case then you need system thinking, you need to consider Agility at Enterprise level. Any transformation, that doesn’t show result immediately, is mostly opposed. People do not want to change for something they don’t believe in, something that they don’t know, something for which they can’t envision how it will improve their own condition. And if they can’t see that, they can’t be enrolled in your mass movement.

Every organization with its pre-existing Org Structure, defined roles and hierarchies, different teams for different activities, finds it very difficult to enable enterprise level agility because agility demands close collaboration and no formality tools and processes, which are flexible enough to make changes as per Org agility achievement needs. In short, for any rigid environment, you need something that can work in parallel to existing system. SAFe is that one approach. From the product inception point to product delivery time, SAFe creates an Agile Release Train (ART), which is a temporary, virtual body within your enterprise that takes care of everything around one unique product in your organization. This train dissolves as soon as product is delivered, and value is achieved. It doesn’t impact existing Org structure, doesn’t change roles, and doesn’t disturb what is already going on.

If you want agility, do it right way. And right way in above scenario is SAFe.  I am conducting SAFe Agilist Batch on 20 -21 Feb, come join me and learn the art of Enterprise Agility:


Why, in the first place, we need Agile? We have been so good without it.

WhyAgileHow will you feel if you are told that your job is to code or build or maintain and support the best way you can, you get all the help you need, you know what product you are creating or contributing to, and you have complete freedom to make recommendations, and changes are made as per them. In return only thing that is asked from you is to stay committed to the product you are aligned to. Will you give your 100% and try to create best possible product with your team?

This is most NATURAL expectation that every IT professional has, irrespective of his role as a developer, tester or system admin. Things get little complicated when you mix hierarchy, processes, audits, employee ranking, employee appraisal, team management, motivation by competition and then one more factor that creeps in with all this – dirty politics. All this demotivates employees and creates a massive incoherence in the entire organization. Everyone is burning themselves to 100% of their capability, yet results are disastrous. Customer is unhappy and company is in loss. Nothing seems to work.

In 2001, many such factors motivated thought leaders from all over the world to come and propose Agile Manifesto. Most of these leaders were developers at core, who had experienced what it takes to make and what can possibly break. They were the soldiers at war front, the peasants who make food for entire nation, the backbone of their organizations. They were the actual DOERS. They proposed a manifesto that was based on their understanding of needs of DOERS and TAKERS (Customers) –

  1. Let DOERS understand what TAKERS need. Do not let Process and Tools, which are supposed to help them, become impede them.
  2. Let TAKERS see for themselves what has been done, instead of making them rely on intangible information.
  3. Enroll TAKERS in creation process, so that they have complete idea of what will be created. This also enables futuristic thinking for them. For DOERS, it makes them more realistic in making commitment on their side. And hence no one feels cheated, and most practical and achievable plans are made.
  4. And last and most important – Change is inevitable. If both DOERS and TAKERS as already enrolled for one mission, they both are change ready. Their plans evolve with changing time and needs, and hence create what can serve and not just sit there as Humbug.

Point to be noted here is that this manifesto majorly talked about DOERS, their NEEDS and their ENROLLMENT with TAKERS. It did not talk about organizational hierarchies, practices, Employee assessment, control and utilization. This manifesto only focused on how best product can be created. And the way chosen was one that came naturally. Give DOERS freedom to do their best, and you will get what you are looking for. This natural approach, this instinctive science of product development is called AGILE.

By default we all are Agile virgins. We love freedom, we love to create. We are self-motivated, our motivation comes from within. Our motivation gets killed by various surrounding factors, various prevailing Organizational hypocrisies and over the years the circle completed itself and called for its Agile environment to restore the internal motivation without which its a dead world.

What do I need to do before doing CSM / taking CSM class?


Many of my friends ask me this question. Should I take “Scrum Fundamentals course” for some XYZ training institute? They are offering really cheap study material, and it’s a money back offer if I don’t clear exam. I really feel bad for them. C’mon folks if you have extra bucks, please give it to some charity or may be buy something nice for yourself.

Its like do I need to do anything before taking birth. No dude, your mom and dad will take care of everything. Just GO, get out there already!

CSM i.e. “Certified Scrum Master” is a certificate issued by Scrum Alliance. This certificate shows that you have complete knowledge about Scrum Framework, including team roles, activities, and artifacts; and are eligible to fill the role of ScrumMaster or Scrum team member in yur organization.

So does that mean that there are no prerequisites for being a CSM?

The answer is YES! Go to Scrum Alliance site and look for next available course of CSM and take it. Or google for next available batch of Scrum and take it. If you are the ‘Proceed only prepared’ kinds, then reading Scrum Guide will be enough (You can get it from Scrum Alliance Site for free). Also you can look at Resources section on Scrum Alliance, in fact the entire site is a good collection on information about Scrum and various courses offered.

Btw what is the process of becoming Certified Scrum Master?

You enroll for 2-days Scrum Alliance’s CSM course. Scrum Alliance’s hand-picked trainers (CSTs) will deliver this training and you will then have to take certification exam. The exam is very simple just like Agile and Scrum. And Ta-da! You are CSM.

Wait a minute. Does that mean anybody can be ScrumMaster?

Well yes and no both. Yes because Scrum is very simple, it’s the natural way of working. So understanding Scrum, taking up CSM exam and clearing it is very easy, anybody can do it. BUT each job has its own challenges. Everyone can play Cricket or Scrum, but can’t be a good coach, can’t train others to do right for their team, and get the goal.

So, I hope you got all your answers. Do write me in case you have any more questions about CSM at deeptijain@agilevirgin.in .

Why is Acceptance Criteria so important?

09/12/2010 - Lady Gaga - 2010 MTV Video Music Awards - Press Room - Nokia Live Theater - Los Angeles, CA, USA - Keywords:  - False - Photo Credit: David Gabber / PR Photos - Contact (1-866-551-7827)It was my sister’s wedding, and I was too excited, as it was only wedding of someone that close where looking your best and everything-like-princess was a must. I googled the best possible designs for my dresses and took services from one of the best boutiques in my city. I was all set to look my second best ( I already looked my best in my
wedding). Please note that I already bought dress material, provided dress designs and so I did not intend to pay much just for stitching.


Now when I was called for trying my dresses, I could not control my tears, I was highly disappointed. Designer told me that my expectations are unrealistic, and the designs that I told were out dated. She created what she felt was best as per my physique, dress material and occasion. I was like, I want to commit suicide and put her as reason for this in my suicide note. My only argument was, if she did not understand or like what I asked for, she should have told me before hand. When I was explaining her, she agreed to everything I explained. I had no choice but to pay her whatever she asked. As per her she was in loss, she had to add a lot of laces and buttons to make the fabric look good.

That was it. I never went back to her. She lost her customer, who could have gotten her many more customers. But, there is another side of story. Every time I wore those dresses, I was bombarded with compliments. BUT THAT NEVER MADE ME HAPPY!

REASON – I did not get what I wanted and I may not have that opportunity again.

So what could have been done – We should have set our Acceptance Criteria very clearly.

First time as Scrum Master?


Most of us start from somewhere, and that somewhere is God knows where. We all keep thinking on how to go about it. And if you are asked to lead it then its really crazy shit because everyone thinks you know it and you think that they know it but the matter of fact is nobody knows what anybody else knows or what to know. Wow that completely meets the very first criteria for any project to be agile. My mom always told me two solutions for any problem:

#1. Jab jaago tabhi savera: This means “As soon as you wake-up, consider it dawn”. Which means don’t waste time in regretting what you already have lost. Its never too late to do the right thing. Look at the problem in hand and think of a solution, no matter for how long you have been ignoring it. Think that you just got this issue in your hands. Past doesn’t exist as far as regretting is considered. We can always look back for learnings. So don’t worry about where you are standing on your agile project, let it be your first or seventh sprint, or how much time has lapsed in getting things officially on board. As soon as realize that all is not well or at least something is not, call for a quick retrospective meeting and try to find solution to the issues noted. But instead we let things go the way they are going because we feel that it too late, we can’t ask our team to change or tell management to get their nose out of an agile project. We fear that we will be held accountable for previous mistakes that everyone was doing. But trust me its totally OK. I realized that its wrong only after I did it once, and now I want to correct it, as SM its my job. Period.

#2. Shuru se shuru karo: This means “Start from the beginning”, from the very first page of book (She literally use to say this). Have you ever experienced lost in your journey? Did you ever feel like starting your day all over again? You get this feeling because nothing is working. Well those are the scenarios are generally result of working with a team which is completely out of sync. Even if your team claims that they know Agile and have been on a Scrum Project in past, there is no harm in organizing a training session. I generally call it “Let’s Catch-up” meeting, generally do it over coffee. First 15 minutes are about how is everybody and how did last night match go and who is top model these days, and then we talk about Scrum fundamentals, what do we know about scrum roles, artifacts and ceremonies. And if team sounds a little confused, I insist on taking a small training session. Always remember a quiz session in the end is very important, when a team looks at subject academically, they disassociate themselves from old beliefs which they might have accumulated over past Scrum projects, and started believing them to be the correct fundamentals. Then you discuss answers to that quiz. From here team gets in to receptive mode, this new Scrum Master gets a little acceptance in the team. And from here it depends on your talent on how good you are in taking your people along, how you win their trust and never let them down.

I think that’s all for tonight. Will be back again with more from my world.

You can stay tuned to my blogs on: https://agilevirgin.in