Archive for the ‘Project Management’ Category

h1

Dysfunctional Delusions

November 28, 2016

If you want high performing teams, they have to be built first and foremost on a foundation of trust.  Patrick Lencioni cites the lack of trust as the first (of five) dysfunctions of a team.  The team members must feel that their other teammates will “have their back” when things get rough.  And as a manager or leader, that includes you too.  In fact, if you want to shift your organizational culture to a more empowered, trust-based culture, management must lead the way by demonstrating (not just talking about) the values and behavioral norms you want for the organization.

One key factor that trust is built on is consistency.  Are you consistent in your behavior?  Are you complimentary one moment and then arrogant or dismissive the next?  Are you puerile?  Vindictive?  People trust their leadership when the feel they know how you will react in various situations.  With trust they will feel they can bring issues to you for help when necessary without risking their positions.  If your behavior varies significantly, your teams realize they cannot understand what your reaction to any given problem will be.  They won’t feel safe to be honest with you.   In other words, they won’t trust you.

And if you think you can behave one way in front of your teams and another in private, you are deluding yourself.  When it comes to sensing duplicities, people seem to have x-ray vision.  They are very good at detecting such contrary behavior.  And when they do, trust may never develop.

To be a true leader you must build trust.  Otherwise your teams won’t progress and you’ll remain simply a taskmaster.

Advertisements
h1

Video Blog : Distractions Kill Teams

January 2, 2015

To see video click – www.screencast.com/t/b9lFNBIt

Also visit:

Websites:   www.ProjectPragmatics.com  and

http://www.JohncMaxwellGroup.com/bobmaksimchuk

h1

Are You Human?

October 8, 2014

Isaac Asimov’s science fiction short story “The Bicentennial Man” tells the tale of a robot named Andrew. With the help of some human benefactors, over a long time, Andrew replaces his robotic systems with biological parts, piece by piece by piece. So the question becomes: When does Andrew stop being a robot and becomes a human (or something else)?

Does Andrew’s behavior remind you of your team? Or yourself perhaps? Maybe you are well on your agile journey. Maybe you are just starting to adopt agile. Even with the best intentions you may find yourself facing the same question as Andrew if you’re not careful.
What I have found in many teams and organizations is that there is almost an innate drive to change things as soon as they learn (but have not mastered) them – ‘Now that we’ve learned this agile stuff, let’s:

a) Not have the daily scrum every day
b) Not have the whole team participate in planning
c) Just have the “leads” do the estimation and tasking
d) Not work with the Product Owner regularly – just at the end of the iteration is fine
e) Ignore our velocity when planning the iteration – the Project Manager will tell us what to commit to
f) Some of the above
g) All of the above
h) More than all of the above.’

Sound familiar?

Now I’m not an agile purist. I believe in adopting agile pragmatically. Once you have mastered the basics and are successfully delivering value regularly and you want to adopt your approach to improve how it can work better in your organization, try it. It may work.

But don’t do this haphazardly. Make sure you understand why the various agile techniques are what they are and do what they do. Consider carefully why you want to change things – to make it “easier” or “save time” or to just be more personally comfortable? Make any justifiable changes like you deliver software – incrementally. Then inspect and adapt the change as appropriate. Just be patient. Get good at this stuff first. There is no rush.

If you keep changing things too quickly and prematurely you may find yourself in a dilemma similar to Andrew. But you won’t be asking “Am I still a robot?” You will find yourself asking “Am I still behaving agilely?

For more like this, videos, and other things please visit www.ProjectPragmatics.com .

h1

Has Your Agile Ship Sailed?

December 8, 2010

Sorry agile purists.  In the real world, most development groups that are using agile techniques (a surprisingly small percentage vs. the industry hype) are not using a “pure” agile approach.  They are using a blend of agile and waterfall techniques to the tune of more than 10 to 1, according to a recent article on Application Development Trends.  The article discusses a European survey of this topic published by a tool vendor.  (Caveat Emptor – Remember if you choose to download and read the actual “study”, it is really a vendor marketing piece based on the survey results – not the actual survey).  I guess the assertion that “waterfall is dead” is as premature as that of the mainframe also being dead.

 Is anyone surprised?  Contrary to what we are constantly barraged with by the agile marketers shouting “Agile, agile!” there is no need to swallow the agile elephant whole.  If you are in an organization that is not using agile techniques, don’t be tempted to lunge headlong into adopting everything agile, just because think you are missing the boat.  Not so.  This article / survey show what other studies have recently shown – that organizations doing agile are not (yet) in the majority.  Another indicator is that the primary tools being used to manage agile projects are still Microsoft Excel and Project.  And many groups are just using ad-hoc tools or working manually.

 So you still have time.  Learn from the majority of the organizations surveyed and adopt agile practices a few at a time.  Target the areas where you have the most problems and try out some lightweight practices.  Find out what works for you, give it time to diffuse into your organization, and then move on to adding additional practices. 

 What you will find is that it is not usually about the tools or about the agile practices themselves.  Most of the challenges in agile adoption are about people and organizations.  This survey cites resource management, cultural issues, change management, perceived loss of control, and executive buy-in as major stumbling blocks.  A “tools first” approach will not solve these.  Nor will a process-only approach.  While you are adopting more lightweight techniques, also look at your people issues and assess whether those can be resolved.  Otherwise they will be the rocks upon which your agile ship will run aground.

h1

The Leadership and Communication Lessons of Josey Wales – Part 4

October 7, 2010

In the last installment, we left Josey and his rebel friend at a river crossing. There they met the boatman Sim Carstairs, Granny Hawkins, who runs a supply store, and a carpetbagger. We discussed the loquacious Sim and now let’s see what we can learn from the unforgettable Granny Hawkins.   This grizzled, toothless, wise old woman can teach us numerous lessons.  Read More…

h1

An Agile Landmine

September 14, 2010

I was innocently browsing some online agile material when I stumbled upon a landmine. I came upon a blog article that was shocking. The article recounted the concerns that the blogger had heard from developers regarding the impact that agile dogma has had on their lives. This article from Daniel Markham – Agile Ruined My Life – is edgy, hard-hitting, and touched off quite a firestorm of responses. So grab a fresh cup of java, kick back, and enjoy this wide open discussion. Agile zealots beware. Pragmatists enjoy.

h1

UML for Project Managers

September 3, 2010

The interview was going well. The interviewer was a project manager / architect. “We have identified these use cases for the project. Now what do we do?” he asked.

The UML is not just a great tool for requirements elicitation, analysis, and design, it also can help the project manager to effectively plan and direct the development cycle. Here is a very basic approach to planning your use case-driven development. Read more…