My Experiences

Agile talks about self organizing teams at the heart of it. I have always found this to be a great characteristics of agile but achieving it is easier said than done. For teams / organisations who may be new to Agile and just transitioning to same from a traditional project management structure this may be not so easy to formulate. The structure where manager typically has lot of power / control to a one where the team itself totally control their plans is a journey to make. Teams who have mode to agile already are also seen at times struggling to let go off old styles. While commune but following are indeed things to do achieve self organising teams: Providing the right guidance to make sure teams understand the true concept of self organizing Building the required trust on team and empowering them to deliver – Letting team take ownership of execution plan Build transparency and strive for highest level of team collaboration Build appetite for failures and missed commit

Following have been some of my queries that I found answer to in due course of time. Hope that to some of you these are useful! Where does the Project Management role fits in Agile methodology? When it comes to agile project management roles, most agile processes - Scrum in particular - do not include a project manager. Agile “project manager” roles and responsibilities are shared among others on the project, namely the team, Scrum Master and product owner. Read more @ https://www.mountaingoatsoftware.com/agile/agile-project-management What types of projects should use agile? Agile projects work best when they are not clear upfront, they need exploration and are adaptive. So that's why they've been adopted by a lot with high-technology projects or creative projects (where as you're going along, you realize that there might be changes). The traditional project has the three constraints of Scope, Time and Cost. How does agile compares to that?

I am sure many of you (or at least some) would have been faced with this question of whether or not to adopt Agile methodology.  The decision can be based on the benefits Agile an offer to your setup / product. It is not necessary that Agile will suit each situation.  Things where requirements are quite clear upfront and the job is not complex, one can assess the overall effort and execute it in a waterfall model. But as more and more complex problems are there to solve, agile can offer a good alternative approach. Here are some reasons why transforming to Agile will make sense: Executive teams are often pressured to produce long-term budgets and milestones. So why should executives sign off for a change to Agile framework? A short answer is that they want predictability .  Long term plans don’t last. Things change every quarter. Budgets can go so wrong! So a working valuable deliverable is a safer choice.  It's better just to get something that's completed a

Project Manager Vs Product Manager - Some basic differentiating definitions

Visual demonstration of different phases of product management which a product manager executes repeatedly as part of his/her functioning.

I have come across project managers/product managers who have felt that they are bound to "less success" simply because they don't have great technical skills. There is an anxiety of not being able to judge things correctly or not being able to control project the way they would really want it to be. Well, here is how actually see it completely differently. I do agree that some bit of technical sense is certainly needed but you need not be an expert.  Why I say so? Project/Program management is a very different function. The responsibilities are very different from that of a technical manager. Project managers need to be continuously aware of the project pulse. They are the ones who need to have the most broader view of the overall project so as to connect different dots and identify risks/concerns before they hit negatively. There are so many things to be on top of just in terms of pure project management that trying to get too much into technical details can o

Never loose site of bigger picture . Remember the goals of why you are doing a certain project. Ensuring that execution is in sync with goals is super critical. Don't panic  when things start look out of hand. There are always always ways to salvage unless you choose to ignore all trigger points. Things will go wrong but be ready to handle and recourse from any unfavorable situation. Re-scoping , resourcing, re-prioritizing can help you reach a new favorable ground. Manage stakeholders coercion:  Don't let stakeholders sway things in their favor against interest of overall project goals. Call common stakeholder meetings on regular basis to share project status. Let it be a forum where if a decision is to be made can be done in agreement. Make no assumptions about communications . Always double check if intended audience is leaving with clear understanding. Send out minutes of all important meetings. Save your time.  Don't let others eat into your personal work tim

Based on my own experience of doing product management for a small sized company over the last couple of years, I feel there are some distinct challenges this type of set up offers. Listed below are top 3 challenges I have come across: Balancing short term wins vs long term product goals:  When you are working for a small sized company which typically is trying to make a mark in the market in terms of getting new customers, renewals and up-sells, there is lot of push to include features what will make a certain customer happy. While that is a perfectly fair thing to expect from product, the problem arises when there are plenty of such requests bombarded at you putting at risk a well thought out plan. What I have found is as Product Managers we tend to react first to this pressure by assuming how can all of this be part of deliverable's and that product cannot respond to numerous custom requests.  But  if you talk to your customer management team, you are going to find out tha