Archive for Project Management

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]

Scrum and Agile in a Fixed Price Project Environment

Posted in Agile, Business Value, Contracts with tags , , , , , , on January 16, 2009 by vikramadhiman

A lot of people have been writing that they like what they read and hear about Agile and Scrum. They then give presentations to their senior management about Agile and they seem to like what they read and hear too. However, the biggest stumbling block is fixed-cost environment. This is primarily true for almost all services companies [and these outnumber new product development companies by a margin - my guess]. An amount of funding is bid for at the start of a project. The problem is how to come to a number for these bids.

Here are a couple of approaches to tackle this [which work for me]:

Approach One : Try using Scrum as a management tool without changing your current bidding structure. Once the team has experience with Scrum, then you should have some metrics collected. The team(s) should have an idea about their velocity and more people involved at bidding stage [think of planning for a fixed-cost project as any other Scrum planning session], the team should be able to give a good estimate for the first 2-3 sprints, even for the full
project if that is what’s required. More importantly, they will ask the Product Owner/ Manager/ Client very pertinent and relevant question about priority and testing to evaluate the story. The fixed costs are based on the knowledge you have at time of planning, so you can post these on the contract too. As time goes by, and your sprints commence, the requirements will change and so will your estimates. You can negotiate them using the existing negotiation framework. However, at the end of your budget [fixed price], the product should have these functions implemented that she wanted the most.

Approach Two : Try bidding low, not in price but what are you able to give to the customer as well as be aggressive on the date when you can launch the product. Most customers and product owners/ managers would give their right leg for the same. Try it on a low risk project/ low risk client [one where you have an option of trying]. If you are bidding low, chances of getting the bid right are higher [again that's just my guess]

You may also like to read Myths about Agile Software Development and Scrum, Agile Collaboration Schemas, Agile Contracts, Contracts in Agile, Business View, Learning and Evolution and Agile Estimating.

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

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.

Scrum not equal to Agile | Scrum is not Agile

Posted in SCRUM with tags , , on November 26, 2008 by vikramadhiman

I have seen many a people say that Scrum is not Agile in strictest sense. Why? Because it forces down processes on people rather than have people fix the process. In fact in much of the CSM classes, you are told this is something you can tweak and this is something you can not. For instance, you do need a Sprint Planning, you need to do a Sprint Review and Retrospective and a Daily Scrum, have a Product Owner, Scrum Master and a Team. I guess you can omit the last part because you will need it anyways. You can not choose not to have a Scrum Master or a Product Owner or worse not do Daily Scrum. What if a team does not want to? Well the simple answer seems to be, you don’t have to do Scrum by the book. It pays to do it by the book till you get used to it and once you get used to it you can start questioning the wisdom of the roles and practices. There is nothing, that says you can not question the wisdom at the start itself – however, if you question after trying something out a hundred percent, you might be able to question better [or at least that's what I think and I can be wrong on this].

My take on this and something I tell the teams I deliver sessions to is : Agile is like a religion. You can be religious without following “a” religion [like Hinduism or Christianity]. But following Hinduism or Christianity can be a good starting point to be religious for some [but not all]. Further, you can be Hindu and Christian at the same time [many Hindus study in Convent Schools and celebrate Christmas]. In addition, you can never be more Hindu or Christian than another Hindu or Christian. Both of you are at your own levels. Similarly, Scrum can be a very good starting point and you can mix it with some of XP or less of XP. Also, unlike rabid Scrummists, I also suggest that you can never be doing more Scrum or less Scrum than others. Tests like the Nokia Test for Scrum are a good reference and starting point but the team should be able to come up with their own tests and revise it often.

Just like having fanatics in a religion does not make a religion bad, having a group of aggressive consultants market Agile, does not mean Agile in itself is bad. Similarly, you often hear : “Religion is always private and something that you share with God, you don’t want others to preach it down.” The problem with this viewpoint is that it is your viewpoint. You might not want priests to help you connect with the God, but others might. Similarly, much of Agile might be common sense but getting this common sense across might need an external consultant. This is what blog posts like The Agile Disease, Scrum fails to come to grips with Human Psycology and Technology is already Extreme get wrong.

I always tell whom ever I talk to Agile about, Agile is not a destination, its a journey. Take Scrum, XP, and everything else as milestones that help you savor and experience different aspects of Agile. Eventually your own journey could help you define and discover, what you think they [Agile, Scrum, XP or <insert your framework name here>] should contain.

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 http://www.wiziq.com/educational-tutorials/presentation/9291-Manager-2-0

Scrum Masters and Managers

Posted in SCRUM with tags , , , on November 1, 2008 by vikramadhiman

As per the Scrum Primer, written by Pete Deemer and Gabrielle Benefield:

In addition to these three roles (PO, TM and SC), there are other important contributors to the success of the project: Perhaps the most important of these are Managers. While their role evolves in Scrum, they remain critically important – they support the team in its use of Scrum, and they contribute their wisdom, expertise and assistance to the project. In Scrum, these individuals replace the time they previously spent “playing nanny” (assigning tasks, getting status reports, and other forms of micromanagement) with more time “playing guru” (mentoring, coaching, playing devil’s advocate, helping remove obstacles, helping problem-solve, providing creative input, and guiding the skills development of team members).

In addition, Pete generally conducts a Manager 2.0 game [I need to write about this] [a variant of the same is also available by Rajesh Pandey's Manager 2.0 Concept]. The basic crux here is the difference between managers and Scrum Masters. Some people new to Scrum, like to appropriate managerial tasks to the role of Scrum Master. This is wrong. A Scrum Masters only job is to make sure that the Team’s Usage of Scrum is appropriate. It is important to note that Scrum Masters:

  1. Do not have any direct authority over the team – but they can help them surface obstacles and issues.
  2. Do not have any power over anyone in organization – yet they can apply pressure to get things done, but they can rarely get things done
  3. They can practice servant leadership but they can’t do stuff like performance reviews, salary negotiation, appraisals, promotions, leave sanction, play referee in a dispute — these have to be taken care by either the manager or the team. In an ideal case, the latter – but in most cases the managers.

The role of managers in Scrum is very important but different. In a traditional organization functional managers tend to spend their time allocating tasks, tracking tasks and applying pressure to make the team meet expectations with respect to scope, schedule, budget, behavior and so on. In Scrum, the functional manager has to to shift focus toward resolving organizational impediments. In essence, the manager and Scrum Master work together to remove the impediments while manager also does other tasks like hiring, firing, pay reviews, appraisals etc. Eventually, these tasks can be taken care of by the team [or senior members of the team, as deemed fit]. In this scenario I like to rephrase the Managers role in Scrumas : “Remove all impediments they can through their power [direct and covert] to an extent where the team does not need them anymore”. In essence that is what Scrum Masters do as well but with one key difference : “they just make sure that the team does not need them anymore for implementing or using Scrum”. This is important, because the team might still need a Scrum Master [if it keeps loosing the Scrum focus], while not needing manager [the organizational design is such or the team has divided the managerial tasks amongst themselves], or they may need a manager [they can't agree on how to divide managerial tasks] but don’t need a Scrum Master [they can go through the Scrum Framework - in mechanics and spirit].

Follow

Get every new post delivered to your Inbox.