Become a Better Manager

Quite a good article from MIT:

  • Embrace restraints. Designers are all about working with restraints (time, budget, location, materials). Identify your limitations and then create not the perfect solution, but the best solution given the restraints. If you can do it with less, why add more?
  • Take a risk. Change does not happen without taking some chances. Designers are comfortable with the notion that they might be wrong, but still they experiment and try new approaches.
  • Question everything. Answers are important, of course, but first come the questions. Designers are used to asking myriad questions that may lead to the right question — which will lead to the right answer.
  • It’s not about tools, it’s about ideas. Designers from various fields spend a lot of time away from new technology tools, using pencil and paper to sketch out their ideas.<

Source

What’s Not Agile

If your organization is looking for an Agile Coach or Scrum Master or you are just trying to improve your skills in that realm, here are some suggestions for what not to do, and what to do.

  • Don’t try to impress anyone with your agile credentials. Do try to identify things that have been successful on similar teams/organizations.
  • Don’t be preachy when trying to present new ideas. Do suggest ideas with a humble and flexible attitude.
  • Don’t rely solely on past experiences of what worked for other teams. Do spend a lot of time listening to people’s needs an challenges.
  • Don’t react when people are critical of agile. Do find a way to tie what people want back to agile principles and show them how they could enable those things.
  • Don’t press your own agenda. Do thoroughly understand how you can support management’s vision.
  • Don’t treat the agile principles as a law. Do use them as a guide for making continual improvement.
  • Don’t be too critical of a team’s existing processes. You never know how much hard work they have put into building what’s there. Do make a point to try to build on existing foundations, and position it as an improvement rather than tearing down.
  • Don’t be too quick to judge what will work best for a team. Do ask a lot of sincere questions and follow the breadcrumbs of how things became the way they are.

Source www.pmhut.com

Office Space and Productivity

Recently read Steve Job’s bio and found the amazing way he designed his Pixar office building which helped in creativity.

The building was designed to help people meet easily and more often. Besides the inspiration and cool (term given by Jobs) interior decoration this building isn’t just a straight lined where every body reaches his desk on time and starts brooding on terminals. It has large open spaces and more meeting rooms where people can meet and talk effectively. Another idea Jobs left for us to look forward to.

But for us Software Team members we have to look forward to it in different perspectives and once the Open Office Space which was more common there is another counter agreement to it, which talks about concept of FLOW of programming and helping a developer to reach there early.

http://mattrogish.com/blog/2012/03/17/open-plan-offices-must-die/

Agile Space also talks about the same open space and more communication but lets not make communication and conversations a hindrance to creativity.

Links: 1 , 2

Power by Expertise

We need to gain Power to get work done. This is Power helps a manager to sail through the problems and can manipulate/influence a team/stakeholders and organization to move in certain direction he wants. It comes through various way we already know through our books like, Position or Expertise.

Recently read about Atari and Apple, how both companies went outside computer industry and hired CEOs to sail them form a start-up culture to more organized way. And we know that Apple’s new CEO completely lost it, reason being expertise. He never invested in expertise of understanding Computer Industry at that time and lost it.

So as PM if you need a real power get into trenches and do not hesitate to understand the Arch Diagrams or at least the basic requirements of Project.

When PM is not a PM

The Vanity Project Manager
Many delivery models have got multiple PM Roles. A PM at offshore as well at onsite. When client start thinking that this PM is at our side managing processes. It becomes important to set expectations from both sides (internal team and client).Real job here is ‘manage client expectations’.

The ‘Fingers in all the Pies’ Project Manager
This sort of project manager flits around the organisation, poking into every project and attending every meeting going. They take meeting notes, and might even chase you on your action points. But that’s as involved as they get in the project.

The Buffer Zone PM
This species of project manager is just an extra layer between the staff doing the work, and those doing the management. They act as a liaison, transferring messages from one side to the other. And that’s it.
The ‘We Couldn’t Think of Another Job Title’ Project Manager

The Subject Matter Expert PM
This sort of project manager quickly becomes the ‘extra pair of hands’ available to fill in when a member of staff is ill, or deadlines have been missed. Of course, it is handy to be able to get your hands dirty when the going gets tough: there’s nothing more frustrating than watching your team toil away, while you make a Gantt chart.

However, in my mind, project managers add value by pre-empting the problems which could send the project whizzing off in the wrong direction. Not being a subject expert has its advantages, as the PM doesn’t get drawn into delivery when deadlines are tight. Once the project manager starts to become absorbed in the task, he forgets to look over the horizon and doesn’t see the enormous iceberg looming down over the project team.
The project manager doesn’t have to be a subject matter expert, but they do have to have some knowledge of the challenges that the team faces in the delivery of the work.

Source: http://www.projectsmart.co.uk/

Another video which calls out and tells us how not to be a PM.

 

Agile and CMMI

After attending few Agile Conference last year. Many questions did come up starting from Agile and Documentation, CMMI Standards, Estimations and Fixed Bid Projects. Role of QA which I have been exploring.

But with CMMI Standards have stared noticing new ideas on web now. Yes as most say they both are compatible and CMMI taking advantage of “I” in their standards say that CMMI is a model and you can follow any framework Agile or Waterfall to do your work.

Here are few good reads starting from Article by CMMI:

CMMI Article

By Scrum Alliance 

Killing Myths (The most Summarized PPT)

A Formal Doc.

Finally Agile and CMMI go together, CMMI talks about processes which completely fit in to what Agile Manifesto or say SCRUM has devised.

Hey, do good work and have best tools like Agile to do it better other frameworks based on popularity or acceptance like PMI or CMMI will follow.

Locus of control

A very interesting characteristic of a performer I recently read about – “locus of control” (location of control – internal or external)

How many times we blame about the environment or situations we are in which lead to results both negative or positive. Which leads to many internal reasons which one gives for non performance and hence tend to be ignorant and less attentive to both details and options to solve problems.

If you really believe that things happening around you due to yourself only and you need to learn new ways to improve yourself and you environment YOU ARE ON THE WINNING SIDE MY FRIEND!