Tag Archives: TDD

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.

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