Archive for the People Management Category

Manager 2.0 – Managing an Agile Team and Enterprise

Posted in Agile, People Management, SCRUM with tags , , , , , , on February 4, 2009 by vikramadhiman

If we use the SCO Model of Management to classify a variety of tasks are performed by managers in IT and other organizations, we can typically divide these tasks in three categories : Strategic, Coordinative and Operational. Strategic actions focus on long term. It is designed to achieve a particular goal through careful evaluation of current situation, future multiple scenarios and alternative choices for the same. Strategic activities and tasks are about defining a strategy [current and future scenario and how best to get there]. Strategic activities and tasks also rest on continually monitoring and adapting. The strategists typically monitor the market situation and business metrics, continusouly aligning their organizations as per market environment. They answer questions like what the organization should focus on, how they should do what they do and how to become more effective and gain competitive advantage. Coordinative tasks are mostly targeted at one specific segment of enterprise and its relation with other segments of an enterprise [and not with those segments of enterprise they are not related to]. Hence, they are based on actions used by a small unit to implement a specific objective. Hence, almost all coordinative tasks are about coordination. The focus is on optimal utilization, coordination and good processes. Operations or processes are a set of well defined, finite tasks. While there can be defined, finite tasks to do strategic and coordinative tasks as well – the main difference between strategic/ coordinative and operational tasks is repeatability. Most operational tasks are repeatable. It is also easy to come up with quantifiable measures to evaluate the success of operation, after a period of time.

Let’s take an example. “User Experience” is an important aspect of any business. As a strategist, the focus is on what are the challenges in designing good user experience, coming up with mechanisms to define who the target audience is, what is the competition and what is an acceptable level of user experience. A coordinative task in the meanwhile could be to have core product line managers focus on standards, coordinating design and HTML activities, analyzing with business analysts, process flows, coming up with design glossary etc. Operational tasks are specific activities like doing actual designs, making HTML pages, testing HTML pages etc. In most organizations, this is how work gets done. Strategy is defined by senior most managers and most managers work in the coordinative space with employees working in operational space. Agile changes this mindset slightly.

The default assumption  by providing strategic power at the top is that flow of control, information, direction is from top to bottom and some people are more equipped to handle some tasks [based on experience, stake in company etc.]. However, an effective strategy would incorporate flow from bottom to top as well. This is because this allows people to get feedback right from the people who are in touch with the market / are doing something themselves. A host of measures have been implemented by various companies for this. Formal mechanisms like feedback surveys are one way of doing this. However, making it formal, periodic makes it a process rather than actually yield results. Strategists need to know what are they missing [most often they will miss communicating with coordinators and operators clearly enough]. Also, the challenge is to understand where the operators knowledge can be better utilized and in current times, this can be anywhere. Hence, more than just jargons of flat organization, everyone is equal – it should be practiced. Management should explain business objectives, directions – get questioned by coordinators and operators on why this business direction and why not something else. After all doubts are clarified, operators will go about their job with more clarity, enthusiasm and direction. Hence, individual units to align them with goals and objectives of organization/ project “as they want to be”. One way of doing this is rather than focusing much on “how to do something”, a broad framework to be provided to the team and they figure out how to do this. In short, it changes the hierarchy.

Let’s look at some of the tasks that managers typically perform :

  1. Task Breakdown
  2. Task Assignment
  3. Task Tracking
  4. Client Communication
  5. Providing feedback to people
  6. Recommending Appraisals
  7. Interviews
  8. Team Building
  9. Trainings
  10. Strategy Planning
  11. Project Reports
  12. Attrition Control
  13. Value Creation
  14. Project Cost Tracking

There can be many more such tasks. Let’s evaluate if managers should continue doing these tasks in the Agile world as well or not. [1], [2] and [3] would not fit in ideally. [4] – [14] would undergo a significant change. For instance, as part of recommending appraisals, the managers would be involved only as one part. A 360-degree feedback along with linked appraisal or same appraisal for whole team based on collective effort are some approaches which can be used. These approaches are not unique to Agile but work well to keep the team at the heart. Similarly, team building happens by creating a spirit in each member to see best interest of the team as well as project and orient themselves towards it without being asked to do. Similarly, value creation is through building people and building systems that make the team hyper productive.  This is definitely tough to do.

The role of Manager 2.0 is to ensure that everyone through out the value chain is involved in all the aspects – strategy, coordinative and operational. This is easier said than done and requires creation of a democratic work space and choice driven coordination up and down the value chain. Some of the day to day transactional tasks like task reporting, task division etc. are no longer done by the managers [you don’t want an expensive clerk]. Some others like providing feedback, performance appraisals, salary appraisals, recruiting, firing are now done slightly differently. In addition, the managers take on more tasks. Basically, they stop being a nanny and move towards servant leadership. Let us revisit the SCO model and see how strategic, coordinative and operational activities are carried out by the The Team, Scrum Master and Product Owner.

The Team :

  • Strategic : The team makes decisions regarding which practices it would use, how much work it can commit to during  a sprint. It also identifies obstacles and opportunities for growth that would help technical architecture of the practice.
  • Coordinative : The team is self organizing. They use variety of tools like daily stand up, sprint retrospectives and sprint backlog for internal coordination and others like sprint planning, product backlog and sprint review with the marketing leadership/ product owner.
  • Operational : This is left for the team to identify for themselves. A number of XP Practices like refactoring, test driven development, shared code etc. However, the choice is left for the team.

Scrum Master or Process Coach:

  • Strategic : Scrum Master is in charge of the Scrum Process/ Agile Framework. She guides, checks and consults on the teams use of Agile and Scrum, She helps the team identify obstacles and remove them. In short, she is in charge of the productivity of the team.
  • Coordinative : Scrum Master or Process Coach can sometimes work as a coordinative mechanism with other departments. Intra-team coordination is generally left to the team unless two team members specifically ask Scrum Master or Process Coach to intervene. In some situations, some tasks in this domain require expertise or responsibility that goes beyond the spirit of Scrum Master. These can be things like interviewing new people for the job, giving individual performance feedback, recommending salary appraisals, being responsible for attrition and individual growth etc. Typically, organizations employ a Manager. A Manager can sometimes work as Scrum Master + other tasks or do only “the tasks” while Scrum Master goes about monitoring the Scrum Process.
  • Operational : This is not defined. Scrum Master or Process Coach can use tools at their disposal like observance, notes etc. to do their work. As most of their work is thought process, speaking and engagement – defining exact tools is slightly wishful.

Product Owner:

  • Strategic : The success of the product is product owners responsibility. She is responsible for gathering customer requirements, prioritizing them, setting the release schedule, getting the right product built. In short, the strategic success plan has to come from the product owner. She can sometimes as a part of this, discuss with the team, the skills and requirements for this success.
  • Coordinative : The product owner engages with the team at sprint planning, sprint review and by drafting a project backlog. She is also available through out the sprint for any questions and discussions. The team works at any given time as per the priority defined by the product owner.
  • Operational : The operational tasks of Product Owner involve gathering requirements, gathering market feedback, prioritizing requirements, communication and tracking product success.

Manager 2.0 :

  • Strategic : Focuses on Value Creation. We find focus on creating processes as per Lean principles, a great starting point. Hence, a Manager 2.0 would focus on:
    • Eliminating waste
    • Building quality in processes and systems – making systems mistake proof
    • Creating a culture of respect for all people
    • Focus on the value for the end customer
    • Optimizing the whole
      • We will expand on this in the posts on Lean Engineering Principles.
  • Coordinative : A Manager can take on the responsibility for arranging resources, people, interviewing, feedback, appraisals – all the tasks which if done by Process Coach/ Scrum Master would actually hamper their ability to inspire trust. In a way, a manager’s job becomes more difficult than a Process Coach/ Scrum Master. They have to not only do some tasks which require certain authority and reporting, but also keep the environment trust worthy and open.
  • Operational : This does not differ much from operational tasks that they do anyways. However, significant percentage of their tasks are thinking and communication based. Hence, appropriate choice of tools is more important.

Overall, Manager 2.0 would be responsible for creation of a value based people driven culture. They also would be responsible for scaling Agile and helping the team identify appropriate practices. There main role is best summed up this way “They create a self organizing team and empower it so much, that they themselves are no longer needed. Hence, its more of a self burning role.


Agile Management – What is it? Is it Different?

Posted in Agile, People Management with tags , , , , , , , on January 21, 2009 by vikramadhiman

Does Agile Management require different skills than normally expected in non-Agile environment? Probably.

Does Agile Management require different skills than ones that will make a project successful? Certainly Not.

Lets see what is Agile to start with:

  • Develop in small increments [provide value early, get feed back early],
  • Focus on individuals and their interactions [make it fun, easy and great to work together],
  • Get customer involved [early feedback, early delivery, course correction] and,
  • Inspect, adapt and change rather than perish
This is what efficient project management should be focussing on anyways. It is useful to visualize Agile Project Management as “Good Management Practices”. Some posts where I blogged about this include Business Alignment over Engineering Features, Agile Metrics, Managers in Agile, Should Managers Worry about Coffee Breaks, Business View – Learning and Evolution and  Taking Everyone Along.
From what I have read, heard, seen, discussed and experienced, I think there are 05 rules of good management [or management if you prefer]:
1. Focus on outcomes, objective and what you want done [destination]
2. Explain clearly what paths you do not want to be taken with the reason and get everyone’s buy in for that [know where to draw the line]
3. Maintain positivity, enthusiasm and stay in the background [don’t be source of melancholy or threat]
4. Understand each member of your team, their aspirations and try and enable them to do what they would enjoy doing the most [you can manage only what you know]
5. Make team work important, valued and fun [teams can get more done than an individual – most of the time]

Individual Performance in Agile Team, Assessment and Individual Burndown Charts

Posted in Agile, Agile Metrics, People Management with tags , , , , , , , on January 7, 2009 by vikramadhiman

Every few months, on almost any discussion thread on Agile, the issue of assessing individual performance, individual assessment, checking how each person is performing, how to identify whether someone is performing well or bad, how to do appraisals etc. Most people respond by saying that at the heart of these discussions is “desire to control as well as fear of not being able to channelize”.  Some of the posts where authors have taken this viewpoint are Review Process for Agile Team Member, Aboloshing Performance Appraisals and Performance Management Trouble. I will not take this viewpoint in this post. I will tackle the issue from the standpoint that yes there is a problem – there is an erring employee and now you need to take action.

One of the key things with this premise [there is an erring employee] is to be factually correct as well as appear to be correct. The first is most often dealt with by clearing to an appraisee the expectations from someone and sometimes this being done in the writing, along with effective methods of measuring the performance as per these expectations. The problem in this generally is “the communication”. Managers are generally myopic in what the expectations from people are – they will lay down expectations which result in a person aiming for personal brownie points rather than help the team grow or becomes just too much of a good samaritan, almost not growing himself/ herself. The challenge in an Agile [or even any team] is to achieve this balance. Hence, your expectations would be a mix of individual as well as team behavior. Once this is achieved, the next challenge is to get the team member to agree to your expectations. There is always “Either you agree or you go strategy” – you can leverage this only if you feel you have drafted fair expectations and the employee is lowering standards unreasonably. Once the buy in is there are your expectations are clear and accepted, the bigger challenge awaits – collecting data. The best data is the one you collect automatically, and not one which others enter in spreadsheets. This truly becomes a challenge as machine collected data is easy to fake and often throws a challenge for users to fudge and overcome. In this scenario, the next best bet is to use Jeff Sutherlands technique. Basically, tweak the 360 degree feedback for something better and meaningful.

If you can get both the above points going, it would be transparent as clean air on who is performing and who is not or better still who is an asset and who is not. Now you have two options : firing or improvement. I personally try the latter. This means you have to really get to the heart of the situation on why someone is performing bad [what parameters the score is bad on leads you to this further analysis]. Once someone is beyond repair, either they would have got the hint already or you then just need to do the needful.

All things said and done, I believe and my own experience suggests that there is a better technique to manage individual and team performance and I call it SCO technique : Small Team, Close Team, Open Team.

  • Small Team : Not more than 9 people, manager but does not manage 99% of time
  • Close Team : The team generally works free of interference from outside environment
  • Open Team : You can sense when there is a problem and discuss it openly

Managers know better about people in this case and you can have a heart to heart talk and decide future course of action in this scenario. But this is not without its problems : people can sometimes become so close that they can not make the distinction between their relation and their work. Its funny how this is also the crux of Bhagavad Gita – you should know what is your karma and do it, not allowing anything you long for or love to interfere. If the team and particularly the manager is able to follow this, this is a good model. My guess is most people are not strong enough or evolved enough to follow this – hence, they keep a distance, not let go and hide behind setting expectations and measuring them.

Project Manager to Agile Coach – The Journey

Posted in Agile, Change, People Management with tags , , , , , on November 28, 2008 by vikramadhiman

One of my favorite YouTube videos about transition the project managers have to make from being a project manager to Agile Coach is from Lyassa. Here are the videos if you have not seen them already:

Lyssa, compiles some excellent points from general beliefs and principles that most Agile Coaches adhere to, primarily:

  • Many things that contributed to my success as a PM are exactly the same things that spell doom for an Agile team – especially being the center of everything on the project : from communication to task allocation to tracking to being responsible for the outcomes of the team
  • I need to know how to foster collaboration by bringing on my skills as a good facilitator
  • Servant Leadership – Not only know but practice it religiously
  • Trust on the teams – Without this, you wont get a 10% of performance from a team

I will try and gorge on other material on the Internet for the same as this is an important topic to discuss.

Manager 2.0 – An Introduction

Posted in People Management, SCRUM with tags , , , on November 4, 2008 by vikramadhiman

In the previous post on Scrum Masters and Managers, we discussed that Pete Deemer uses a term Manager 2.0 [also see Project Management 2.0] , which has also been incorporated by others recently. In the first Agile Event at Chandigarh, Rajesh presented on Manager 2.0. I thought the presentation was very good. You can catch the slides at

Should managers worry about extended coffee breaks?

Posted in Agile, People Management with tags , on September 21, 2007 by vikramadhiman

I firmly believe that most organizations would run better if managers managed a bit less. The problem is that most managers do such a horrendous job themselves and drive others to do horrendous job as well, that if they did not manage at all, things would be better themselves. And they should definitely try and keep themselves away from SCRUM teams or should I say “fully functional teams.” And this means doing these [and much more]:

  • Not keeping a count of how many coffee breaks a person takes
  • Not keeping a count of how much time ABC spends on phone
  • Not raising an eyebrow seeing an employee sleeping on the desk

Its sometimes also called reactive management. In fact I dont call it reactive or proactive. Its just another style of management and pretty effective one IMO for you can focus only on results and the behavior which drove the results. In case you use Agile, you can ruthlessely focus on results every two weeks or so. This allows for self correction in teams. Self correction driven through self introspection and committment to try out new things for better results seems to be a better driver for well, better results. Is that not what the management wants in the first place?

Here is why focusing on behavior first is harmful. Lets take the example of server administration teams. Lets say the server administration team [they do a great job and thats probably why] sit idle most of the day and only mostly answer email or do jobs which are completed in 15 minutes flat. Once in a while they are busy like hell, taking back ups and what not, but mostly you find them reading hacking articles, blogging, networking and boasting. There is another team with 3 developers [who do more than some 6 member teams]. However, you find most of them in canteen, laughing, blogging and in passionate discussions. CTO just passes by and after three such sightings can not control and makes this sarcastic mark “So you guys have outsourced your work too?” Managers wandering by and making sarcastic remarks about outsourcing, or whatever half-assed other smart comments they may make, demonstrates management inability and lack of awareness. Frankly, the manager should hope to see those ‘slackers’ always ‘slacking’, because that implies there are no server administration problems happening, which has to be a good thing.

IMO you need to avoid looking at the slacking [for instance] even if it is in your face. If you are doing Agile, what you need to look at it is what was committed [and assuming this was reasonable commitment] and what was delivered. You can obviously ask question like “What made you miss the commitment?” Slacking can be one answer and Low Morale [because of a manager just walking past and seeing team engaged in tea 5 times a day and remarking sarcastically, have you outsourced your work] can be another too. The managers job is to unearth the behavior for poor performance and not “seemingly” poor behavior itself. However, day after day we see poor management results [sliding profits, non paying customers demanding bug fixes and holding teams hostage, poorly trained teams] due to management proclivity to focus on trivial and urgent but not on important but not so seemingly urgent. It makes you realize how ingrained “command and control” is in our mindset as managers. The notion of a self functioning team just does not exist. The underlying assumption is that they will surely do something wrong and when that something wrong does not happen [well obviously because they would not commit to a 45 man months of work in 5 months, which management wont have any qualms over committing to by the way], issues like longer tea breaks, too many training sessions, not pushing too hard, there is an easier way to do this work, bottom 10% need to go, appear.

Taking everyone along in Agile Implementation

Posted in Coaching at Net Solutions, People Management with tags , , on June 10, 2007 by vikramadhiman

One of the thoughts which strikes me everytime I think about Agile Implementation is our CTOs comment “Project Managers need to be on top of things all the time.” And yet, as a project manager of Agile Implementation myself, I have not been the most Agile Project Manager over the last few months. I have not adhered to the Agile principle of carrying everyone forward. I have allowed people who do not quite understand Agile to dictate how we should structure our Agile Implementation. For instance, one of the junior most designers who was earlier a part of our truncated sessions for 3rd group is no longer considered to be worthy enough to take the sessions. This is because the current thinking is that Agile sessions are for employees with certain “IQ” and “who can take us forward“. The argument put forward is that we need to explain to employees why someone is allowed to take these sessions while others are not allowed/ considered. Hence, only the very best [or at least the very best in our eyes] should be allowed to take the sessions.

The other side of the story comes from the usual office politics. Some project managers will not allow anyone from their team to take part in the sessions. This is because they either do not like what we are doing or they have problems with people in the Agile Implementation group.

In both the situations above, it indicates that the reason why we are not able to take everyone along is because we cant get people in top management to be carried along as well. The implementing group has been thinking of it as some kind of agenda that we will implement Agile without the support of top management. This is obviously not going to happen. Also, this alienates them to the extent that before Agile is going to become a total reality we have already create a group that does not want to hear anything to do with it. In the first case [where a designer was barred from attending 3rd session] it indicated failure of communication internally in the group and in the second case [where office politics was at play], we were at failure in getting along everyone in top management.

We know its hard to work with people whom you have passionately hated all your stay in the office but we need to decide what is more important for us, Agile Implementation or Our own Comfort Zone. The answer is not that simple. But one thing is for sure, we need to find a way to get everyone along.