The Managing Leader vs the Coaching Leader!

Blog-Managing_vs_Coaching_63315415In Hindu mythology there are two great epics. One is called Ramayan and other is called Mahabharata. The centre story of both these books is around victory of good on evil. In one story Lord Ram leads his army to defeat Ravana in his land, While in the second Lord Krishna oversees Pandavas defeat Kauravas in the battle at Kurushektra.

In Ramayan, Lord Ram is the best yodhaa of his side. He leads his army from the front. Strategizes & directs different people to do things which will meet the objectives. His people are happy to follow orders & want to get all the appreciation for being the best executors. Lord Ram set direction & also tells people what to do during difficult times. Ultimately they won the war & the final outcome was achieved.

On the other hand Lord Krishna told Arjuna, I won’t fight the battle. I won’t pick up any weapon; I would only be there on ur chariot as a charioteer. And he did what he said. He never picked up the weapon & he never fought. Still, Pandavas won the war & final outcome was achieved.

ramkrishnaSo, what was different? It was their managerial style & it was also the type of people who were being lead.

Lord Ram was leading an army of ‘MONKEYS’ who were not skilled fighters & they were looking for direction. While on other hand,

Lord Krishna was leading Arjuna who was one of the best archer of his time. While Lord Ram’s role was to show it & lead from the front. Krishna played the role of a coach whose job was to remove cobwebs from his protégée’s mind. Krishna couldn’t teach Arjuna archery but he could definitely help him see things from a very different perspective.

Here are some of the basic differences in two styles:
Lord Ram : A skilled warrior, lead monkeys, was emotional, gave precise roles & instructions, motivated the army to fight for his cause

Lord Krishna : works with best the professionals, provides strategic clarity, allows team members to take lead, fights for the cause of the team, did not depict his true emotions


  1. Look at ur team/family & reflect what type of leader/parent u are, One who keeps answering/solving problems for people/kids Or Who asks relevant questions from their people/kids so that they can find their own solution.
  2. Are u someone who tells/directs all the time Or Someone who clarifies doubts & allows their people/kids to find their own ways.
  3. Are u someone who has monkeys in the team & the way u deal with it Or u have the brightest experts in their area getting stuck with issues?
  4. Younger generation doesn’t want you to tell or show how things are done, they want to know the meaning of their task and how it makes a difference in this world.
  5. They are Arjuna’s who don’t necessarily seek more skill/knowledge but they need someone to clarify the cobwebs in their mind, if u still apply Lord Ram’s style on them, u are bound to fail as a manager.
  6. On the other hand if there are people who aren’t skilled enough but rely on ur expertise to sail u through Lord Ram’s style is appropriate.

Isn’t it good for us to reflect & think what managerial style will bring the best result for u and ur team/family ? Is it Lord Ram or Lord Krishna?

The Managing Leader vs the Coaching Leader? 🙂


Agile Fatigue

In long running Agile projects there are observations that the productivity of the team(s) come down as they burnout. In the (bad) old waterfall days projects had ramp up and ramp down time which gave developers and team members some breathers but in the (good) new Agile days its sprint after sprint relentless teams hardly get time to catch a breath.

Agile Fatigue is more worse when you work with not so matured product owners, product management teams who thinks development teams as run machines and expect them to deliver sprints day in, day out without a break.

Some of the symptoms of Agile Fatigue includes user stories that drag from sprint to sprint, user stories that are too big or broken down inappropriately, lack of or improper use of epics, and QA/Test organizations falling behind because they are handed too much functionality all at once. Don’t let the team con you into waiting ‘until the next big function’ because it’s ‘too much trouble/delay/work’ to fix the problem immediately.

To help the teams overcome Agile fatigue , some of the industry practiced best practices are

  1. Ensuring the backlog is “just good enough” : Don’t waste time perfecting a list of product features or tasks that, by the nature of agile, is going to change over time. Start with an imperfect and still well defined backlog and transparent communication to keep anxiety and fatigue from building and know that the grooming and retrospectives will mature the backlog quickly and continue over time.
  2. Learning & Innovation Sprint: Make every 5th or 7th sprint lean and learn and innovate, in the sprint the team took fewer story points and committed to learning a new technology/trick , this kept the teams ticking.
  3. Plan hardening sprints : Give tech debt ownership to development teams and ensure we had planned hardening sprints where the team took care of upgrading frameworks/libraries, clearing technology backlog, refactoring quick and dirty hacks , fixing defects, fixing performance issues that piled up over a period etc.  This often gave the team a sense of technical ownership.
  4. Encourage and make Automation part of Sprints: Identify repetitive manual tasks as part of retrospectives and add stories to automate them. This keeps the Enthusiasm moving across the teams.
  5. Team Building/Reset Day – A fun day where the team creates working agreements/charters, builds trust and has fun. It is essential all teams do this as setting expectations when times are good will see you through the times when they are not.  Money in the bank so to speak.
  6. Sprint Retrospective Action items Folow UPs: Over a period, sprint teams gets bored and lose interest as they feel there are no takers to the action items discussed in the Sprint Retrospective meetings. Especially for long running sprint teams , this is more evident. Teams actually improve more often and quicker due to heightened transparency on Retro action items. Having the support from the Product Owner, Business Owners is very important, because it gives a clear sign that whatever the team agrees to improve upon is really important and should be solved!.

A more Optimistic CAN-DO Attitude without understanding the reality is more dangerous than a more practically approached attitude understanding and balancing the reality and yields more results 🙂


p_03_1PMO office is a committee of project managers and senior management that defines and maintains standards for project management within the organization.

PMO generally will become the source for guidance, documentation, and metrics related to the practices involved in managing and implementing projects within the organization.

Set Project Management standards:– The PMO builds up a common set of practices, principles and templates for managing projects. So that the project managers can switch more easily between different projects and new project managers get up to speed faster.

Ensure project management standards are followed:– While the PMO sets project management standards, it also must ensure they are followed by performing regular assessments of projects.

Assistance to Project Managers:– The PMO assists the project managers who need expert judgment in cost and duration estimations, risk identification, changes evaluation as well as defining metrics for the project. PMO extends their assistance whenever there is a critical issue in Project.

Projects status for management review:– The PMO will track the status of all projects in the organization based on updates from the project managers. PMO will consolidate the project’s status and send updates to management review using project dashboards which provide a clear way to keep track of the status of projects.

Guidance new project managers:– Most PMO’s develop into a center of excellence for project management and can provide guidance and coaching to novice project managers or new project managers who need to understand how the organization runs projects.


7 – traits which makes mangers successful managers to make highly productive teams


People don’t leave company but they leave their managers. That is why it is very important to understand the chemistry between manager and team members.

We must understand why some managers are able to execute projects after projects without much difficulty while some managers struggle to even execute a simple project.

Successful managers have certain traits which makes them popular and results in highly productive teams.
Here are some of those traits:

1. Make well defined goals for team members – You can not hit a target unless you see it. That’s why top performing managers have well written goals for the whole team. They identify the most important goals required for the project execution and align their teams.

2. Set clear priorities – Good managers are able to set clear priorities for the team and individual members. They help identify most important tasks for them which keeps team focused.

3. Create reasonable Timelines and Expectations – Managers who can understand the strength and weakness of its team, sets reasonable timelines and expectations for its members. Their expectations are based on facts and capabilities of its team. Remember there are no unreasonable goals but unreasonable timelines.

4. Demarcate of responsibilities – Good managers do not micromanage and have clear roles and responsibilities defined for its team members. They do not want to get involved in each and every decision. They delegate the power.

5. Trust Team– Trusting the team comes naturally to top performing managers. They believe in their team and their capabilities. They like to give them a problem and then get out of their way. They let them solve problem. Having said that, they are always eager to help them whenever required.

6. Value time – Time is money. That’s why they are always focused on keeping meetings on time with right agenda. They do not keep people waiting unnecessarily. If required they inform them well in advanced. They plan things meticulously so that team does not have to spend more than required time in office or weekends.

7. Have Empathy – Managers or team members, are all human beings. That’s why best managers have empathy deeply ingrained in their blood, which sets them apart from all others. They understand emotional needs of their team members. Empathy is one of the most important element for being a top manager.

These seven traits are not exhaustive but are one of few most important qualities every successful managers should embraced for success.

Global Team Leading

imagesLeaders who are willing to adjust their style, expectations, and timelines are far more successful than those who expect others to adapt.. They harness the strengths of the team’s background, experiences, cultures, and traditions within the context of what will work in each situation and each market across the globe.

How is leading people globally different from leading people locally?

  1. You are leading a more diversified population with varied backgrounds that provide a totally different environment and completely different challenges than leading domestically.
  2. Scope and complexity complicates communications and relationships and this requires more interpersonal and intercultural sensitivity.
  3. Emotional intelligence looks a little different in each culture. Observation and cultural clues requires one to vary his/her style and lead people appropriately.
  4. Labor laws are different from one country to the next. One must be very careful to ask the right questions.
  5. Local, regional and global business teams require sensitivity to diverse cultures. People from one place may view things differently than those from another.
  6. It’s much harder to create a collaborative multicultural team than one that is more culturally homogeneous. Within a single country you have a familiar cultures and a single language. Culture, language, and people differences are challenging.

As we integrate teams around the world, knowing these key differences is the starting point to developing the skills and behaviours necessary to be a successful global leader.

Matrix Organization

How an organization operates, identifies projects, and supplies resources to those projects can vary from company to company. Most organizations uses a matrix structure for running and staffing their many project engagements. Matrix management generally refers to an environment where resources may report to many managers…such as a direct supervisor and possibly several project managers.

The matrix environment

Matrix management involves coordinating, organizing and executing a sometimes complex web of relationships that come about when people join the project team and are subject to the resulting multiple authority-responsibility-accountability relationships in the organization. This type of organization is an attempt to take advantage of the benefits of a pure project organization while maintaining the advantages of the functional organization. It is rare to find pure-project or pure-functional organizations in business any more – the matrix organization usually makes the most sense in terms of efficient use of resources where 100% utilization and beyond is important to the bottom line of the company and each department. Matrix organizations are typical today, even when other project management tools aren’t involved.

In a matrix organization, a clear project team is established that crosses organizational boundaries. Thus, team members may come from various departments. A project manager for each project is clearly defined, and projects are managed as separate and focused activities through the use of web-based project management software. The project manager may report to a PMO Director (if a PMO exists), higher-level executive or to a delivery manager. However, the specific team members still report to their functional departments and maintain responsibilities for routine departmental work in their functional areas. In addition, people may be assigned to multiple project teams with different responsibilities. The problem of coordination that plagues other project structures is minimized because the most important personnel for a project work together as a defined team within the matrix project structure.

The management responsibilities in these projects are often temporary – a supervisor on one project may be a worker on another project, depending on the skills required. If project managers in a matrix situation do not have good relationships with line managers in the organization, conflicts may arise over authority over employees’ work and priorities and it may become quite cumbersome trying to manage everything in the online project management software schedule. Because of this, the matrix environment is not necessarily a happy place for everyone.

The complexity that a matrix organization causes is clear: People have multiple managers, multiple priorities and multiple role identities. Because of these complexities, before an organization enters into matrix organizational structures, at least two of the following criteria for the project or the enterprise should be met:

  • Scarce or unique resources. A need to share scarce or unique resources that are required in more than one project or functional area. This can be tricky but most project management software scheduling tools can prove to be quite helpful.
  • High-end communication. A requirement for management to provide high levels of information processing and communication to complete the project.
  • Centralized project control. Pressure from the outside by customers or agencies to have one person or group centralize control of the project even though the project may be carried out by other groups in the organization.

Source code management system – A Closer Look

What is SCM?
Source code management systems are a common feature of large software development environments. They are used by both commercial and open source projects. It is far less common, however, to see SCM used in Web development, although larger development firms and projects do use SCM to manage their code.

SCM solutions are based on a simple principle: the authoritative copies of your source code, and other project files, are kept in a central repository. Developers will check out copies of files from the repository, work on those copies, and then check them back in to the repository. This is where SCM becomes an important tool; SCM manages and tracks revisions by multiple developers against a single master repository and provides:

  • Locking and concurrency management 
  • Versioning and revision history
  • Synchronization
  • Project forking

Locking and concurrency management
Working in a team-based development environment that didn’t use an SCM solution, people will probably encountered examples of the concurrency problem and its implications. Concurrency refers to the simultaneous editing of a file by more than one developer. This creates a contention problem which can lead to loss of revisions by one or more developers, especially if they are editing a single master copy of a file.

Consider a simple example: developers A and B both need to make changes in a file at the same time:
1. Developer A opens the file.
2. Developer B opens the file.
3. Developer A changes the file and saves it.
4. Developer B changes the file and saves it overwriting A’s changes.
Clearly this has the potential for serious loss of work. Even if individual developers work on their own copies of files instead of a master set of files, after developers A and B make their changes, those independent changes to the same file must, somehow, be reconciled and then distributed out to all developers.
SCM systems manage the concurrency problem with file locking which makes it possible for files to be flagged as “in use” when a developer is editing them. Two main approaches exist to file locking: exclusive locks and unreserved locks.
Exclusive Locking
With exclusive locking, the SCM prevents more than one developer from ever checking out a file to edit it. If a developer checks out a file for editing, all other developers are prevented from checking out the file; they will be able to view the file or get a copy (as opposed to checking it out) but they can’t edit the master repository copy until the current developer checks it back in and, in the process, releases their exclusive lock on the file.
This solution can provide a foolproof way of preventing simultaneous editing but comes with its own problem: what happens when Developer A checks a file out and forgets they have the file checked out and leaves the office? When Developer B has an urgent change to make to the file they can’t and would have to wait for Developer A to return to check the file back in. In a large development environment it’s a challenging problem of human management and communication, particularly in a distributed development environment common in web development spanning multiple time zones.
Unreserved Locking
Because of the problems described with exclusive locking, most major SCM systems in widespread use adopt a different type of locking: unreserved locking. In this model, multiple developers can check a file out and obtain a non-exclusive lock. Multiple developers then edit the file as needed.
The SCM system then implements mechanisms and algorithms to manage the merging of changes as files are checked back in to the repository. These algorithms range from the simple (inform developers of conflicting changes and ask the developers to resolve the changes) to advanced (attempt to determine and combine changes intelligently and ask for developer intervention or confirmation only when needed).
At first glance, it may seem like this does not offer much more than not using an SCM at all, especially for working on a shared set of files. But, this isn’t the case. The SCM system knows who has checked out copies of files and prevents file overwriting by ensuring some type of manual or automatic merging of changes occurs. Combined with other SCM features discussed in the following sections, this makes an unreserved SCM system a powerful development management tool.

Versioning and Revision History
SCM systems not only handle editing by multiple developers and merging of changes when conflicts arise, they also implement versioning. Under versioning, a complete history of revisions of files in the repository is maintained. Every time a version of a file is checked back in to the repository, a copy of that version is archived. At any time, it is possible to pull back a previous version of a file, or roll-back the current version to any earlier revision.
Versioning systems also generate log reports of who checked in changes and when, as well as storing comments from developers about the changes they are committing back to the repository. Some systems can even show the specific changes made or each new version of a file that is checked in.

In some SCM models, individual files are checked in and out of the repository. In other SCM systems, a synchronization system is essentially built-in. Developers check out their own, complete, copy of the repository and work on files as they need, committing their changes back to the master repository. Developers can periodically update their personal copies of the repository to obtain new changes submitted by other developers.
This way, the online access to the repository is not necessary for development to continue. Instead, developers can work off-line if needed; only connecting to the repository periodically to commit their changes, and update new changes from the repository to their own, local working copies.

Project Forking
Sometimes it is necessary to separate a project into two separate development streams during the course of the development cycle. These streams of development may reflect multiple versions of an application or project, or completely separate projects, that share the same base (the code developed before the separation occurs). This separate is known as forking and most SCM systems provide the ability to fork a repository and establish separate versioning, history and locking for the two forks of the project. Changes in one fork have no impact on the other fork.

Why do a team need SCM?
If you look at the main features of SCM described above it is quickly evident that even small teams of two or three people benefit from a well-implemented SCM system, even for a single developer.

At first consideration, though, it is not immediately obvious how individual developers working alone benefit from SCM. They do, however.

There are several benefits:

  • Versioning: If you have ever been debugging a nasty bug and found that the changes you are making are only making the problem worse, then you can appreciate the benefits of SCM’s versioning. By being able to roll back changes you can back out of problematic changes at any time.
  • Backups: The separation of the repository from your working copy creates an effective backup mechanism: you can keep a copy of your repository checked out while there is an effective backup of the most recent version in the repository.
  • Multiple Computers: You can work on multiple computers without being worried about transferring changes between the systems. If you make sure you finish a session on one computer by checking your changes into the repository you can move to another computer and just synchronize to get the latest updates from the repository before you continue working. You won’t need to manually manage synchronization of changes against multiple development computers, as this is handled by the SCM automatically

SCM Systems

  • Visual SourceSafe: This is Microsoft’s solution for SCM. Most large-scale commercial development environments that develop using Microsoft-based applications will use SourceSafe since it integrates well with Microsoft’s development tools. 
  • Concurrent Versions Systems (CVS): This is the leading SCM platform in the open source development community, and widely used in commercial environments as well. An open source project itself, it is widely deployed in Linux and UNIX environments, but is cross-platform and available for Windows as well.
  • Subversion (SVN): Subversion is a popular emerging alternative to CVS. Another open-source project, it addresses some of the problems with the design of CVS, and adds features lacking in CVS. SVN also allows CVS-based development environments to keep their same workflow practices after switching to SVN.
  • Team Foundation Server (commonly abbreviated to TFS) is a Microsoft product offering source control, data collection, reporting, and project tracking, and is intended for collaborative software development projects

In addition, there are other tools which, while not full-blown SCM systems, can provide some of the benefits of SCM for small teams or individual developers:

  • ColdFusion’s Remote Development Services (RDS): RDS provides basic locking capabilities and integrates well with Macromedia’s development tools, even allowing direct editing of files on a ColdFusion server. It lacks the versioning and change merging features at the core of most SCM systems but can be the basis of a small shared development environment.
  • WebDAV: This is an emerging open standard that provides remote editing and management of files on a Web server through its native HTTP protocol. The full specification of DAV (Distributed Authoring and Versioning) would provide locking, versioning, and forking, but most present implementations do not offer all those features.

In my experience, we have used both VSS, CVS and SVN. EAch has their share luck of features and drabacks, but looking at the commercial angle and if SCM is a separate from a broader application programming tools like TFS , SVN , an open source solution looks to be the best, not only because it’s open source, but has a lot of advantagee, simple to use and easily integratabel with other tools.

If you use TFS correctly, you can use it to manage every aspect of your application life-cycle, including requirements, code development, testing, and SDLC reporting. And the great thing is, all aspects of the life-cycle can be linked from one part of the process to another. It becomes really difficult to do that if you’re using SVN for your repository and FogBugz for your bug tracking, and spreadsheets for your requirements (etc.).

However, if you are already existing system for tracking other things and just looking forward for a pure SCM solution, SVN is the guy for you.