Archive for Management

Product Vision : The Key Role and Responsibility of Product Owner

Posted in Agile, Business Value with tags , , , , on October 19, 2009 by vikramadhiman

Continuing with the discussion on Product Owner role and responsibilities, and based on two excellent comments from Martizza and SJJH, let us review the key role and responsibility of the Product Owner. One can argue that the four skills/ competence areas highlighted in the Who can become a Product Owner post along with people management and interaction skills, help the Product Owner articulate, defend and refine the Product Vision. One can also argue that this is a separate skill and competence area and some people can just be better at this job even if they do not have the domain knowledge, are not technically sound or have the necessary experience. What will these people then typically possess? I think it would be a mixture of ability to learn [learn very fast], a highly analytical mind [capable of drawing analogies], intuition [strong emotional connect with real and abstract] and a thinking mind [one that can think even when it does not know it is thinking]. These people would generally believe hopelessely in what they are working on – and it is this belief and the conviction that helps them exude the product vision. Hence, when one is looking to appoint or hire someone for Product Owner position, one should see if they identify with the product and what are the ideas they bring to the table. If the connect is established, the rest of the work would flow a lot better.

So, what exactly does a Product Owner do with the Product Vision. They do 03 things:

1. Define the Product Vision – This involves close connect with the customers and market needs. Hence, domain expertise and exposure to tech support/ marketing comes in handy. Further, exposure to some sort of modeling methods helps the Product Owner define the product vision. Often, the Product Vision phase can take long. As a Product Owner, you may consult other domain experts, technical team or embark on marketing feasibility studies to confirm and reconfirm the vision.

2. Articulate the Product Vision – This is more important than 1. Typically, the Product Owner should be available to the development team anytime and everytime. The Product Owner should be able to sit down with different team members – together, in groups or alone – and discuss aspects related to the product – what will happen in 02 years, 02 months and what do they think could happen. This helps build the trust and orients the developers from a Product Owners perspective – a key requirement to build a great product. One of the means available with the Product Owner, to articulate the Product Vision is Product Backlog and ceremonies like Sprint Planning, Sprint Review help achieve this too.

3. Refine the Product Vision – Each time the Product Owner meets people from marketing, sales, technical support, development team, testing team or customers – they will keep uncovering new things about the product. It could just be new technology [Google Wave was launched a few days back for instance] or a new trend [micro-blogging and social media]. This can represent opportunities or threats. Product Vision is not stagnant. It is dynamic.

If a Product Owner can take care of the Product Vision, the Product would largely take care by itself.

Advertisements

When Should You Implement Scrum or Agile?

Posted in Agile, Change with tags , , , , , on August 19, 2009 by vikramadhiman

Are there circumstances that are more favorable for implementation of Agile and Scrum and ones that are not very favorable for its implementation. Generally, the ideal conditions for implementation and spread of Agile/ Scrum in an organization depend on the market and customer scenario, rather than the development team scenario. Some such factors or conditions include:

  1. Unclear product direction or a research oriented product – the fact that the direction is unclear, makes you plan only for a small time in the future, when you reassess and reorient
  2. Too many changes/ feedback too often in the product – again this means that you take the minimum [agreed, clear or consensus] work – complete it – get feedback and move from there
  3. Competitive industry/ market scenario – this generally would mean you have to get the features out to the market sooner rather than later as well as have more customer connect in the product [some will argue this should be the case anyways]

There are some factors at organizational end as well, which can impede/ aid the Agile Implementation. For instance, if there is no management buy in, or team buy in or worse if there is no customer buy in [in service industry scenarios]- it will be hard if not downright impossible to implement Scrum, Agile or any other framework. In addition, where a deliberate slow and assured pace is mandatory [think software for nuclear reactors or space ships] – there might be significant overhead. Hence, small increments or sprints might not be possible in such a scenario. Turning, this around, you should go all out to implement Scrum or Agile, if:

  1. There is a relative buy in at all ends – customer>>management>>team [not necessarily in this order in all organizations].
  2. The cost of a single bug is very high.
  3. Everyone understands or make attempts to understand what is Scrum or what is Agile.

When you combine the outside [market/ customer] conditions with inside [organization] factors – you get a ripe condition for implementation of Scrum or Agile.

Management Today : What All Managers Should Know About Agile and Lean Online Teaching Class by Vikrama Dhiman

Posted in Agile, SCRUM with tags , , , , on February 24, 2009 by vikramadhiman

I am conducting a Webinar on Management Today, where multiple topics of interest to managers in various industries would be discussed every fortnight. These Webinars focus on Agile and Lean and will introduce these concepts to Managers. You can join and watch the class right here too.

Vodpod videos no longer available.

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.

Lean Thinking – An Introduction

Posted in Agile, SCRUM, WiZiQ with tags , , , , , , , on December 21, 2008 by vikramadhiman

I have done an online webinar on Lean Thinking Introduction for Beginners and Dummies on WiZiQ. This presentation has been the basis for the same – I have compiled this from various sources and keep improving it when I find an example from real world experience or web, that I feel should go here. I hope you find this a useful resource for Lean Thinking Introduction.

Lean Thinking Introduction by Vikrama Dhiman

Vodpod videos no longer available.