Sunday, December 17, 2017

HIPPO Training in Agile?



In Agile, servant leadership and self-organization are critical elements.  In traditional business, the "boss" or HIPPO (Highest Paid Person's Opinion) calls the shots.

Here's a great article on how to train your HIPPO...

http://agileatheart.com/how-to-train-your-hippo-ace2016/


Saturday, December 9, 2017

Scrum Values - Courage and Safety

"I learned that courage was not the absence of fear, but the triumph over it. The brave man is not he who does not feel afraid, but he who conquers that fear." -- Nelson Mandela


It does not seem accidental that "courage" is the first Scrum Value on the list.  When coupled with "psychological safety" - open communication becomes not only possible - but the expected norm.

Safety is the responsibility of management and the overall culture of the organization.

Courage is the responsibility of the individuals in the organization.

When Organizational Safety meets Individual Courage - the sky is the limit.  

Friday, December 1, 2017

Abraham Lincoln, Horses, Generals and Servant Leadership?

General Colin Powell (former Secretary of State, Chairman of the Joint Chiefs of Staff and Army Brigadier General) recalled a story he heard the day he was promoted to brigadier general. 
In the story, President Abraham Lincoln receives a message during the Civil War saying a Confederate detachment captured a brigadier general and 100 horses.  President Lincoln said out loud "Sure hate to lose those horses".  
When asked about the brigadier general, he commented, "I can make a brigadier general in five minutes, but it's not easy to replace 100 horses."
“What it says is it’s the horses that count, it’s the troops that count, it’s the seals that count, it’s the sailors that count,” Powell said.  "Communicate the vision and give them everything they need to be successful."
Don't think that you are irreplaceable, none of us are.  Therefore, your number one priority each and every day should be taking an active role in development of your subordinates.  Agile uses the term "servant leader" to describe this type of behavior.  
Robert Greenleaf polularized the term over 40 years ago.  You can learn more about Servant Leadership here:  https://www.greenleaf.org/

Related story:  https://www.linkedin.com/pulse/general-colin-powell-horse-sense-gratitude-growing-two-holoman/


Climbing the BS Mountain Article

Another GREAT article from OrgMindset.com

https://orgmindset.com/2017/11/03/climbing-the-bs-mountain-agile-for-the-sake-of-agile/


Wednesday, November 29, 2017

Anemic Transformation - Anti-Patterns in Agile

Thank you to Alex Yakyma from OrgMindset.com for this FANTASTIC article! 

http://orgmindset.com/2017/11/28/anti-pattern-anemic-transformation/




Saturday, November 18, 2017

Reliable Resources: If it's on the internet, it has to be true?


Agile and Scrum are frameworks with a broad range of options but also some pretty hard guardrails.

With the best of intentions, some will espouse their ideas/agenda as solid agile, but I'd recommend sticking to the core reliable sources, and look at anything outside of that circle with a critical eye to make sure they are sticking closely to the principles of Agility.

To that end, here's a few reliable resources.

Reliable Scrum Resources:

Scrum Alliance:  www.scrumalliance.org (Mike Cohn - where the most recognized certifications (CSM, CSP, CTP, etc.) come from)
Agile Manifesto:  www.agilemanifesto.org (Where it all started)
Agile in a Nutshell One Pager:  http://blog.crisp.se/wp-content/uploads/2016/10/Agile-poster-2016-ver14.pdf
Scrum Inc:  https://www.scruminc.com/ (Jeff Sutherland co-inventor of Scrum)
Version One:  https://www.versionone.com/
Rally:  https://www.ca.com/us/why-ca/about-us/acquisitions/rally-is-now-ca-technologies.html?cid=GLOB-EOA-ABUS-ADB-000083-00000151
Ken Schwaber https://kenschwaber.wordpress.com/
Robert "Uncle Bob" Martin the "clean coder":  https://sites.google.com/site/unclebobconsultingllc/

This is most certainly not an exhaustive list, but it should give you a good start and anytime you hear anything that's not covered here, or even worse, contradicts the spirit of what is on these sites is suspect to say the least.

Wednesday, November 15, 2017

The 'ONLY' thing that matters in Agile Transformation?

If you have children (or if not, if you ever were a child ;-)), at one point in time you may have experienced a child that did not want to clean their room.

One option as a parent/guardian is to educate the child on the benefits of a clean room.  Another is to offer inducements/incentives to motivate a child to clean their room.  However, in the end, without the threat of compulsion, education and inducements will only succeed some of the time with some of the people.

According to the 'Rogers Innovation Adoption Curve' (http://www.valuebasedmanagement.net/methods_rogers_innovation_adoption_curve.html), 16% of the population will resist change strongly enough to be classified as "laggards".

Laggards are defined as:
"Traditional people, caring for the "old ways", are critical towards new ideas and will only accept it if the new idea has become mainstream or even tradition".   

In Agile Transformation, if "laggards" are in a position of power, and there is not someone at a higher level of power to correct/minimize/check them, they can wreak havoc.

A recent client was almost 2 years into their "transformation" but teams still could not accomplish the most basic maturity level (for example:  even with 70+ sprints under their belt consistently could not meet their sprint goal commitment).  When command and control managers force unreasonable commitments on teams that they can not possibly accomplish, teams become dis-engaged and sometimes even toxic.

Jeff Sutherland, co-creator of Scrum and Agile Manifesto signatory, put it this way in a recent Harvard Business Review article "Embracing Agile":

But a serious impediment exists. When we ask executives what they know about agile, the response is usually an uneasy smile and a quip such as “Just enough to be dangerous.” They may throw around agile-related terms (“sprints,” “time boxes”) and claim that their companies are becoming more and more nimble. But because they haven’t gone through training, they don’t really understand the approach. Consequently, they unwittingly continue to manage in ways that run counter to agile principles and practices, undermining the effectiveness of agile teams in units that report to them.
·      These executives launch countless initiatives with urgent deadlines rather than assign the highest priority to two or three.
·      They spread themselves and their best people across too many projects.
·      They schedule frequent meetings with members of agile teams, forcing them to skip working sessions or send substitutes.
·      Many of them become overly involved in the work of individual teams.
·      They talk more than listen.
·      They promote marginal ideas that a team has previously considered and back-burnered.
·      They routinely overturn team decisions and add review layers and controls to ensure that mistakes aren’t repeated.

-->
·      With the best of intentions, they erode the benefits that agile innovation can deliver.

So if you are thinking of Agile Transformation at your organization, or are struggling with getting at least "twice the work in half the time", the key limiting factor to how far and how fast agility comes is often management - typically middle management - likely with the best of intentions - struggling to become servant leaders - and enabled by executives hesitant to take effective corrective action.

If that is the case, could correcting that behavior be the only thing that really matters in your Agile Transformation?

"The measure of intelligence is the ability to change."  - Albert Einstein

"Intelligence is the ability to adapt to change." - Stephen Hawking

I welcome your thoughts...

Jay

Monday, September 16, 2013

Ja-Who-I Window?

The Johari Window:  Knowns and Unknowns


Made infamous by former Secretary of Defense Donald Rumsfield's "Unknown Unknowns" quote:

"There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know..."

Uhhh.... Do you know what he's talking about??

Sounds like a lot of gibberish, but it's actually very sound logic that's better explained using the "Johari Window".

One of the primary goals of agile is effective communication.  And a big part of achieving that is making sure information is 'de-siloed', or clearly spread ACROSS departments and 'silos' of organizations.

Take a look a the graphic above with Four Quadrants:  Open, Hidden, Blind, Unknown.

Open:  The upper left window "Open" (shaded in yellow) is where we want information to be.  If everyone knows about it, they we'll all make better decisions together.

Hidden:  That's information I have that others don't.  That's dangerous to others, because they may make a decision with incomplete information because I have not shared it.  The goal of that information is to move it "up" into the open window by sharing it with others

Blind:  That's information that I don't have, but others do.  That's dangerous to me, because I make a poor decision because I don't have important information that someone else has.  The goal of Blind is to move it to the left, also into the "Open" quadrant by others sharing the information they have with the team.

Unknown:  Of the four quadrants, this is the ONLY area we can't do anything about.  Things like natural disasters, terrorist strikes, etc. fall into this category and there's not as much as we can do about them, except in the most general sense like disaster recovery planning, etc.

Bottom Line:  A cohesive team is constantly working and ever diligent to move "Blind" and "Hidden" facts and information up and to the left into the "Open" quadrant so everyone on the team is working from a complete set of facts and making sound decisions.

Put it into Practice:  What are you doing in your organization to move out of the "Blind" and "Hidden" into the "Open"?

Until next time...

Sunday, January 17, 2010

Another Shot at Maturity...?

Although the blog asking the question "How Mature is Project Management" was asked more than 4 months ago, I'm still receiving responses from impassioned Project Managers from around the world.

Here's a sampling from the "LinkedIn" site, please feel free to add your comments as well.

Until next time...

Project Management is evolutionary.

PM has been around since the ancient Egyptians built their pyramids. As time has progressed and we gained more tools (PERT, project scheduling software, etc.) what it takes to 'efficiently' practice/execute project management has evolved. So too, as the needs of the job have changed such as compliance and work place personnel issues (that Egyptian PM didn't need to deal with unions or counsel low performers on a documented improvement track). Being a 'well rounded' PM now includes a lot more than it used to. Just peruse the table of contents in the PMBOK.

I believe that because our tools, techniques, and the demands of the job change so too does our definition. We are also becoming specialized in areas such as government, health care, manufacturing and construction (your Egyptian predecessors would be proud). So our definition evolves with our changing environment. I think our profession maturing and adapting to demands all the time.

This is a good thing. I doubt the definition of a buggy whip manufacturer has changed much since the 18th century.

--Brian Turner, Deloitte Consulting

Not sure what you mean by "mature." Usually, it refers to the expected ratio of what's currently known and understood to everything there is in the field to know and understand.

By that definition, I'd consider the field to be well into its adulthood. Most of the issues that come up in projects have nothing to do with gaps in what's been published and available on the subject of project management. They have to do with practitioner and stakeholder failures to master their roles in the process; poorly chosen analysis and design methodologies; insufficient budget ... issues that are very real, but that don't reflect on the question of what is known.

A lot of this discussion seems to have centered on the ratio of "art" (I'd call it "street-smarts") to "science" (I'd call this part "book-learning"). Because there are all those pesky human beings involved whenever there's a project to manage, I'd say this is a stable 50/50 or thereabouts and isn't going to change. So if more science = more mature, the field will never progress beyond its adolescence.

--Robert Lewis, IT Catalytics

Having managed large projects in corporate America and now managing projects in the Academic world, provides some insight into how you might measure maturity. It is my belief that project management as a whole may be mature; however, if the industry, or organization using the processes does not embrace them completely, it requires a project manager that is capable of situational project management.

To explain this in more detail: Successful project management stems from a resourceful, innovative project manager who can adapt the theories and practices to the organization. As one individual stated above, there is a need for evolution. I'm not so sure that it is the practices or the processes, but more the project managers adapting those elements to the situations, the organizations, and the needs of the projects.

--Linda Evans, Professor of Project Management, University of the Pacific

In my humble opinion, IT project management is more of an art. The PMI and technology have provided some tools, but it is the individual's talent rather than the tools that make for successful projects. Consequently, project management will continuously evolve. Managing a COBOL project in the 80's was different than an ERP project in the 90's or today, which is different again for the other types of projects today. There will never be a maturation, only an evolution.

--Norm Brumbergs, Infosys


In my opinion, there are elements of art and elements of science. It is definitely not a pure science (Do to the fact that it does not use the scientific method purely, ej. observation, experimentation, hypothesis, etc). It is an art because there are so many subjective variables, each company and project and different and each PM is different.

How mature is it? Its tools have evolved, the method has evolved and administration is evolving continuously. To me the answer is relative, compared to what to itself? to other disciplines? It has come a long way, but advancing o never ending road. Thats what makes it interesting!!

--Vincent Arreola, Consultant



If you look at the place where project management priciples got started. Departement of Defense. If you have any experience in DOD, you see it is very mature and is made to be flexible for software and hardware. You would see that is has been around since the 1950's. Maybe a little earlier.

Now, if you refer to the dynamically changing software and IT development methodologies, honestly, the basic methodologis have been modified to fit business policy and goals. From the claisic waterfal to Agile to Scrum, and other variations, they all use the basic PjM methodologies, but with iterations, modified gates, focus on feature delivery. But most of these are reflections of the plan that reflects the business goals of the organization.

--From Jeff MacQueen, PMP



Project Management to me is a exactly what the definition says. It is the application of knowledge, tools & techniques to meet the project objectives. This is supported by the progressive ellaboration concept which makes it evdient that this application has to improve as the project progresses through the various process groups and respective processes.
Ironically, we all have experienced in the real world that we as project & program managers have to make several adjustments to the theoritical project managemnt and create a working project managment methodology which depends on the culture of the organisation & the geographiy where the project is been undertaken.

--From Prashant Dalvi, IT Project Manager




Saturday, October 3, 2009

Adventures in Consulting - An Unexpected Risk?

(Part of the "Adventures in Consulting" series, please see previous posts for more info).

So you think you want to be a freelancer...?

Don't get me wrong -- there are some great advantages of being a self-employed consultant. I've been doing it for more than 15 years now, so I can assure you of that.

However, besides the more obvious risks like not having an assured paycheck, having to pay your own health insurance, losing 15% to employee matching, etc., here's another risk you might not have thought about...

What about if you want to eventually return to full-time work? You might end up with (as they said in the movie 'Office Space') a case of the "Muundays"



Take a long and hard look at this issue before making the jump to freelancing. Once you make that jump, then a few years later go and talk to a company about returning to full time work, expect to answer multiple questions about why in the world you'd want to come back to the full-time world. Expect polite accusations that you're only doing it until some new business idea takes off, some new client signs up for your services, etc.

You may face a situation where you are just as qualified (or more qualified) than the other people that are interviewing for the job, but many potential employers will count it against you that you ventured off of the corporate ladder and it may be tougher to get back on than you thought.

Just something to add to your list of things to consider.


Until next time...


Saturday, September 19, 2009

How do you PDU?

The Project Management Institute suggests 12 ways to earn PDU's...


Their suggestions are pretty general and generic.

Submit a comment to this blog and let me know how YOU like to earn your PDU's, and then I'll take the results and create a new reference on OMS' Project Management Resources page.

Until next time...

Tuesday, September 8, 2009

Adventures in Consulting: On-Site Travel Expenses and Your Hourly Rate


If your a freelancer, chances are you'll have to work on a 'time and materials' basis on occasion.

For me, that is my preferred method, because it gives me some assurance that my client won't take a fix-bid quote and 'scope creep' me into the poor house. Of course, if you can give your client a clear set of requirements and some sort of a 'cap' (not to exceed hours) then everyone has a stake in the game and it's fair for everyone.

Some of the work I do requires me to be on-site. Sometimes that's just because the customer wants to see what they're paying for, but also because co-location can really help communication and project progress.

If the customer is willing to pay my hourly rate + travel, then I just invoice them for actual travel costs, and they reimburse me. (Don't forget to add the per diem cost for 'meals and incidental expenses' from the IRS.)
But a little more tricky issue is what to do when the customer wants to pay an 'all inclusive' hourly rate? That puts more risk on you, the consultant, to absorb the travel costs, etc.

Fortunately, through trial and error, I've found a great formula, and it's pretty straight forward:

Travel cost
+ On-site cost
/ 8 hours/day
= Hourly On-site Travel

1. Travel costs: First, determine whether you want to drive or fly to the location, and how often you'll return home. If driving, use the standard IRS driving rate (currently 58.5 cents/mile), if flying, log onto Travelocity, or Orbitz, or one of those sites and get an estimate of what a ticket will typically cost you. Take the $ per trip and multiply that by the number of times per month you'll return home, then divide by 4.2 to get a weekly number, then divide by 40 to get an hourly equivalent:

Trips per month cost
/ 4.2 weeks in a month
/ 40 hours in a week
= Travel Costs per hour estimate


2. On-site costs: Probably the easiest way to calculate other costs for being on site is the IRS per diem rates. Simply look up the city you'll be staying in, and take the Per Diem rate and divide it by 8 hours/day to get an hourly eqivalent:

IRS Per Diem (daily) Rate
/ 8 hours per day
= On-site hourly estimate

Now you have a good idea of what it will cost you just to be get there and be on-site. Add that to your hourly rate (what you want to make per hour), and you have your billable rate!

Tip: Clients and recruiters don't always consider all of this info when they negotiate a rate with you. I have found most people to be reasonable when I show them this information and it's turned out to be a great tool in successful rate negotiation.

Until next time...





Friday, September 4, 2009

The Manhattan Project

Thanks to friend of the blog, Constantine Kortesis, for this contribution. It sure made me think...

The following excerpt is from http://nuclearweaponarchive.org/Usa/Med/Med.html

"Despite its official founding in August, the Manhattan Project really began on September 17, 1942 when Col. Leslie Richard Groves was notified at 10:30 a.m. by Gen. Brehon Somervell that his assignment overseas had been cancelled. Groves, an experienced manager who had just overseen the collosal construction of the Pentagon, seized immediate and decisive control. In just two days he resolved issues that had dragged on for months under Compton. On September 18 Groves ordered the purchase of 1250 tons of high quality Belgian Congo uranium ore stored on Staten Island, and the next day purchased 52000 acres of land to be the future site of Oak Ridge. Groves was promoted to Brigadier General on September 23. By September 26 Groves had secured access to the highest emergency procurement priority then in existence (AAA).

The era of weak, indecisive leadership was over.

Groves' pushy, even overbearing, demeanor won him few friends among the scientists on the Manhattan Project (in particular a special enmity developed between Groves and [scientist Leo Szilard]). Many detested him at the time, considering him a boor and a buffoon. It was only after the war that many scientists began to appreciate how crucial his organizational and managerial genius was to the MED [Manhattan Engineers District, aka Manhattan Project]. "

The Army clearly recognized that in order for projects to succeed, project managers need real power and authority and that must be visible power and authority. Project Management has existed for thousands of years. The recent trend of relegating project management to what often appears to be a clerical timekeeping and book keeping function is something new. I believe that this is due to pressure from government agencies that require contractors to have established formal project management systems and to achieve CMMI certifications or ratings of at least level 2. Within the past decade, corporations such as General Motors have been requiring their suppliers to follow formal project management processes.

A shortcoming of the CMMI evaluation process is that it does not measure results. It only looks at documented processes. The evaluation process does not assess the quality of leadership. In that sense, the maturity of Project Management is not the issue. The real issue is the maturity of the company in its adoption of Project Management principles.

I find the notion of Project Managers grovelling and begging for resources, project sponsors, charters and reasonable schedules to be both detestable and laughable. Organizations that expect low-level project managers to accomplish miracles without adequate objectives and resources are doomed to fail. Organizations that do not respect and appropriately compensate the profession of Project Management are doomed to poor performance.

- Contributed by Constantine Kortesis - Thanks!

Thursday, September 3, 2009

Previous Food for Thought...

At the heart of every large project is a small project trying to get out.

Wednesday, September 2, 2009

Politics, Sex and .... Project Management?

There's an old saying. "Never discuss politics, sex or religion in polite company."

On the other hand, we all agree on many things. The earth is round (well, slightly spherical, actually), the sun rises in the east and sets in the west (actually the earth revolves around the sun), and the sky is blue (it really only appears blue to us).

Well... you get the idea.

Many aspects of project management do not seem to fit into the 'earth is round' category.
What is the evidence? Here's just a few casual observations:
1. A PM on a popular professional networking site recently asked the question,
"Does anyone really know what project management actually is?"
Simple question, right? Nope! This has been the most popular 'discussion' (read: debate) on that networking site since it was launched about a month ago. This discussion/debate has more than 3x the comments then the #2 debate. And to add to the point, the #2 discussion is "There are no IT Projects".
This is a networking site for professionals in the industry, and it seems we're not sure if the earth is round or flat at this point.
2. A best selling author, and one of Microsoft's leading PM's, Scott Burkun, in his book said...
"Few people agree on how to plan projects...It's not surprising then that the planning-related books in the corner of my office disagree heavily with each other...But more distressing than their disagreements is that these books fail to acknowledge the the other approaches even exist."

I'm adding project management to my list of things you shouldn't bring up in polite conversation. Seems it's a sure way to start an argument, at least if you're talking to a PM.

So, for me, this drives the question, just how mature is the art/discipline of project management? Most would agree that being a PM is at least as much 'art' as it is 'science', but all of this disagreement reminds me of the Christmas rush over the Tickle me Elmo doll, or Wii video game -- everyone is pushing and shoving, and there's not a lot of cooperation going on.

What do you think?

Until next time...


Monday, August 31, 2009

Previous Food for Thought...



"Right answers to wrong questions are just as wrong as wrong answers to right questions."


Friday, August 28, 2009

Danger in the Comfort Zone (Recommended Reading)


Entitlement.

Back in the 80's, when I went to college, I had to work nights so I could afford to go to school during the day. Lots of 60+ hour weeks working swing shift at a trucking company + trying to handle a full load of Economics and Business Administration work was a huge challenge. I'm glad that young people can muster up that kind of energy, because I don't think I could do it now that I'm in my 40's.

Early on in my college life, there was a woman in one of my classes who was doing basically the same thing I was; working nights to pay for college during the day. We commiserated because we were the two people constantly trying not to fall asleep in class -- not because we'd been out partying all night -- but because of working late.



I ran into that same woman as a junior or senior, and I still looked like the cat dragged something in. But, to my surprise, she looked well rested, groomed and tanned.

So I asked her what she was up to, and she, in a nutshell said she had the answer. She decided to get pregnant, have the baby, and then have the state welfare system help her pay for her housing and education. She said it was a lot easier than what we had been trying to do.

Many people I talk to have a similar story they've either heard about or experienced in their lives. This book addresses the entitlement mentality, and more importantly the 'curve' that we need to be on that is a balance of fear and extreme insecurity on one end, and entitlement on the other. The ideal is to be between those two extremes in our lives.

A great read, and not only will you see the trend in our society around us, but I know I learned a little about myself as well. I hope you can read this book and have the same experience.

Until next time...