Soft skills -- Cultural awareness

I believe this characteristic is very high on the list of required characteristics if not in the number one spot.

One of the benefits I’ve received from being a contractor and working in numerous businesses is the awareness that one size definitely does not fit all. What I mean by that is that having a keen awareness of both the personal cultures of the people you work with and the corporate culture in place will do more than anything else to determine where you and your projects will ultimately sit on the ‘over the top wildly successful’ – ‘absolute failure’ performance scale. This is especially important when there is already a dichotomy between management and worker views on the value of a particular strategy, communication needs, readiness for change, risk tolerances, etc. Depending on your perspective, the same situation or even a single conversation could be positive, neutral or negative. Of course, this also presumes you’re coming into the position with at least a minimum baseline of technical skills.

The most valuable piece of concise advice that comes to mind at this moment is ‘Go slow to go fast’. This tidbit of wisdom is one of the things I think that took me a relatively long time to truly appreciate. Personally, for me, it says so much more than the expression of ‘a bull in a china shop’. Sure, for those of us who have been around for even a while have all seen this situation play out at one time or another, and it’s not pretty. Some newbie PM or high priced consulting firm that should really know better comes riding in like the cavalry to the rescue and the smart ones of us sit back and watch until they either smarten up or fall on their faces.

This is why I truly love the workplaces that have already done some kind of True Colors exercise and everyone has their primary colors posted at their desks. They may as well have a sign up that says “Hi, I’m so-and-so, you can best interact with me by . . .” and you fill in the blank part of that line. Of course, if they appear to be stressed for whatever reason (most of us are at some point or another) you’d probably do best to be observant (aware) and proceed with the color that person has when they’re stressed. By then collectively leveraging and offsetting each other’s weaknesses and strengths and enabling your team with this awareness you then create synergies. And that synergy of awareness to cut a long story short then creates highly productive project teams.

Project Management Soft Skills

I’ve seen what seems like a lot of on-line discussions lately about the level of arrogance of people who choose project management as a profession, soft v. hard skills required to be effective, what qualities make a good program/project manager, etc.

Using Dictionary.com definitions as my premise, …

‘Quality’ is an essential or distinctive or distinguishing characteristic or attribute with respect to level of excellence in personality and traits.

‘Character’ is the aggregate of features and traits that form the individual nature of a person and the moral and ethical qualities and reputation.

These factors are the two sides of the same coin that help me differentiate between Bob, Mary and Bill. Just to be clear; these are made up names referring to no one in particular.

Arrogance, however, is the offensive display of superiority or self-importance; including overbearing pride.

The following five factors listed in order of importance I believe are deterministic for predicting the level of success achievable for a program/project manager; or for any leader for that matter.

1.      Cultural awareness

2.      Honesty and Integrity

3.      Vision – having one … to a detailed level

4.      Self-awareness / wisdom / insight

5.   Communication skills

I will elaborate on each of the above points over the coming days.

I will also say at this point that this list may differ from yours. That’s okay. It’s our unique perspectives that make this world an exciting and enjoyable place to live. And yes, I’m very much aware and excluding the more negative issues that exist in this world; there’s enough of that on the news already.

Story Points are Quantitative ... well kind of

One of the most fervent, ongoing dichotomies I continue to hear about is that of defining Story Points; SPs for the remainder of this post. This includes a Q&A discussion on a recent webinar I attended. The frustrating part of me is that this dichotomy is a justification in some people’s minds on why Agile is an immature methodology. Thus, the reason for this post.

As fervent as both sides of this debate are about whether or not Story Points (SPs) translate into time / effort / duration tangible numbers. The reality is that they're both correct. I can hear the gasps, gfaws, angry mind squirrels seeking the comment area now! What! How ridiculous!  To that, I say "LOL". :D

Seriously, the whole point of story points is not to have just another way of saying how much work there is to do! Yup, you heard me! It's not some conspiracy to create even more and new overhead. It's about creating visibility of scale to get people moving forward on something that will create something tangible and of benefit to customers, users, and yes even the company who hired people to develop, test, document, release, market and sell it.

Okay, let's get into the weeds of this debate shall we?

 

Dichotomy side 1:  SPs Have No Time Correlations

Let's start with the side that say SPs are qualitative numbers and have no correlation to time. In this camp, it's all about T-shirt sizes, H / M / L categories, etc. The SP cards might as well be colors as Fibonacci numbers. These are the people who prefer to say "I'll tell you how long it's going to take when I'm done." or at least "I can't tell you until I've burned through 2 to 4 sprints and have an average of how many SPs we can get to 'Done" in a typical cycle / sprint / iteration.

The down side with this approach, that I've found anyway, is that it presumes everyone estimating (playing planning poker) has a similar scale of how much effort will be required to get the work done. I've actually seen scenarios where everyone agreed a story was a size of '1', told the guy in the room saying "hey, wait a minute ..." that he was just wasting their time, and then the testers asking the developers the next day if they'd have the build (that's right kiddies 'the' build, not 'a' build, 'the' build) for them by the end of the day. That was the point where the communications regressed into something less than respectful because the developers meant "one sprint" when they said '1'. Of course, this cascaded into problems where the testers had put something else on the back burner, wouldn't be available at the end sprint (in 3 weeks), and couldn't be expected to just sit around until then! You see the picture, right? :-) 

This hasn't ever happened to you; you say? Great! Congratulations! Could you perhaps add a "yet" onto the end of that sentence? Okay, enough of this side. Let's move over to the camp of people who say "everything must be quantifiable to mean anything; otherwise it's just a waste of their time!" 

 

Dichotomy side 2:  SPs Correlate to Effort

These are the people who typically have tight budgets, are in consulting, professional services groups, etc. Because quite frankly, nobody is interested in working for free. Not even the junior engineers in the other camp who want to tell you how long it will take when they're done. Let's look at this a little more closely shall we? The fact is, quantifiable numbers enable people to think about how long (when it will be ready), how much $$$ so they can pay bills, wages, etc to be around for the next contract. Ever run into a scenario where somebody delivered something 6 weeks late and was incredulous when nobody cared? The fact is they missed the boat and this is what exists a lot of the time in business. It's about both realistic and ideal costs and durations / days required to get something to 'done'. 

The Rule of 1.x

Sometimes telling someone that a story point equals a day will just get them thinking 'Agile' is 'a Guile' and BS and waterfall just using different words. That’s why I prefer to get the team thinking about the work involved rather than how much effort it will take.

On really unclear, breaking new ground types of initiatives you may well just need to start off with high, medium and low sizing; very small, small, ... XXL T-shirt size estimates. And yet no one in their right mind is going to give you a budget based on that. No one will ever go in front of a group of executives to say please give me a million dollars, we believe the project is 22 Medium t shirts big.  Amazingly though I’ve had experiences in my career where some people thought that was exactly what we should. This is only your first step to get to some focus on some subset of your backlog to get some quantitative numbers. A break down of the work into its component subsets (or some smaller, manageable chunk) until you get to a point where you've got a list of tasks so you can say if Bob does this, Mary does that, and Pat does this other thing we'll be able to demo for you our version of the newest product with this subset of specific capabilities.

If your team has a velocity of 10 SPs in sprint 1, 8 SPs in sprint 2, and 12 SPs and the team worked the same way, same number of days, etc it doesn’t mean you did anything wrong. It means you can expect to burndown 10 SPs per sprint on average. It may also mean that some of the estimates were off by 20% and just like in a bell curve everything just averages out, and that instead of planning out everything over a mind-numbing 3 to 6 weeks to the n-th degree of detail you have enough information after just a couple of days to tell the business when they’ll get their software, and the developers, testers and tech writers, etc can get onto what they do and love best.

The above is why I like to say SPs follow the rule of 1.x. 

 

 A Word of Caution

Sometimes to people getting it their heads that “oh well, it was just a estimate”; “I can come up with any number off the top of my head and say oops later”. No skin off my back; right? No, not right. Think about it in terms of an example that I think most of us can relate to, and maybe even some have experienced themselves. If you went to a garage to get your car fixed, they called you will an estimate of $200 and when you got there they handed a bill for $1150 and said “Oh well, was just an estimate” you'd probably either go ballistic or vow to never go there again. Now, when your estimates to develop a new feature are way off, this is what they’re thinking about you.  This is what I'm talking about when it comes to holding a planning poker exercise. For me, if I didn't expect you to take the work seriously, I could more easily just come up with the numbers myself using a random number generator and then blame you when you couldn't hit those probably ridiculous estimates. Of course, if that was the case you wouldn't want to work with me either. This is what is meant by mutual respect in the workplace. I take what you do seriously and vice-versa.

Sometimes coming up with accurate estimates is just not possible, or as one manager I know put it, "the only thing that is clear is that everything is unclear."

So ..... what are we ever to do?

That's easy, if you (and the team) have come up with story points estimates for everything in your backlog -- pick something small but not too small, something with an obvious solution but not too obvious, something of one or a few SPs. If people new to SPs and planning poker are more comfortable equating 1 SP to a day-ish of total effort among everyone involved to get whatever to 'done' try it and see what happens! Seriously, it’s really that simple. If it turns out to be about a day of work then you probably have some good estimates for the rest of your backlog. If it turns out to be a week when the team decomposes the work, you may just want to try this again with something else, expand out your estimates for everything else by a factor of 3 or 5, or some combination of these two things and perhaps something else just for good measure. If you’ve got a team with people who have worked well with each other a lot in the past and have been involved in the development of the project’s requirements you may just want to dive right in to your planning poker and estimate your stories.

The above is certainly not all encompassing on this. That’s why companies need to formally train existing employees and hire qualified ones. And please excuse me for saying so if this contrasts with your perspective but quite frankly I’m going to listen to the original Agilists and those who and widely published authors over highly charismatic webinar hosts. The following links may help you get to your next threshold in the use of SPs.

Mike Cohn’s blog -- http://www.mountaingoatsoftware.com/blog/how-do-story-points-relate-to-hours

 

Jeff Sutherland -- http://scrum.jeffsutherland.com/2010/04/story-points-why-are-they-better-than.html

It’s People then Process then Tools/Tech

. . . in that order!

A recent linkedin.com group discussion and one poster’s experience about people who just don’t seem to ‘get’ this and others who blame the tool has kicked up my ire. And equally from a humorous perspective is reminding me of the joke about a guy who throws his clubs in a lake after having a bad round of golf.

For me, having Ishikawa diagrams, 5-whys, reality trees, etc in my toolbox to do RCAs, ensuring plans are comprehensive, etc are great but that's just it. They are tools to visually represent how well we've analyzed what needs to be addressed. And like any tool, it can be misused. Ever seen anyone try to use a screwdriver as a hammer? How about a wrench as a hammer?  :-) 

I'm a visual learner myself, know others are too, and appreciate that not everyone else is. As an example, the fishbone diagram (when appropriate) I find is something best used to record what was discussed. Thus, early in the process, I've historically found it's best used as a mental tool and left at that. Pulling it out too early sometimes causes people just go through the motions of populating the bones rather than thinking about what should be populated on them.

Now, anyone who turns the People --> Process --> Tools/Tech workflow on it's head and makes the tool or the process paramount is doing something that is at its very least "counter intuitive." And at this point, some may say “Hey, you’re pretty much constrained to HTML, Javascript and CSS to create a website. And they’re all tools/tech!” And to that I would say “yes, yes they are.” And then I’d ask those people what websites they know of that were designed to serve another website.

The tool/tech cannot ever be paramount to the people or the process it is there to serve; whether or not the problem is open-ended or not. Procedures to help share knowledge to less experienced others creates progress and as such are typically very good. Procedures used to constrain thought in any ethical problem solving paradigm into predefined boxes will only serve to create mental RSIs (Repetitive Strain Injuries) and tend to be very bad at creating value-added solutions. Again, let's note that in such cases it is the people creating the problem; not the process or the tool. 

At the risk of heading down a rat hole, picking up a gauntlet, whatever, ...  Yes, I too have encountered a lot of useless tools over the path of my professional career, but they were all people. :-) LOL   

The overwhelmingly vast majority of people I’ve worked with over the last 30+ years, went to school with, or had as professors could in no way be considered blind lemmings who’d follow a process just because it exists and it’s easier than thinking. Anyone who is living with this reality I would suggest has a very depressing reality. I can honestly and thankfully say that does not apply where I am, nor I suspect do the vast majority of other people either.

Oh, BTW, the article that drove all of this ….

http://www.bulsuk.com/2009/08/using-fishbone-diagram-to-perform-5-why.html?sthash.gaBUvRA2.mjjo&goback=%2Egde_1801885_member_219060123

History is the best predictor of the future

I had a brief conversation this past week with someone who used this statement. Something about this bothered me, something just seemed off; wrong about this, but I wasn’t sure what so I just smiled politely and when on with my work. Then this morning, while I was busy doing something else, it hit me – ‘broken telephone!’

Somewhere along the line, that person on their own or through another imparting this little tidbit of non-wisdom dumbed down “past performance and behavior is a predictor of future performance and behavior” into one all encompassing factor of reality. Well, in their mind anyway. In essence, they played the game of broken telephone with a nice, concise piece of wisdom.

That got me thinking. I wonder what else that person and how many others in and out of their places of business play that game on a regular basis due to some combination of misunderstanding and misinformation? I wonder how many variables and constraints were completely forgotten or discarded to further cloud that tidbit of wisdom?

This statement is most accurate when no variables change. When one or more variables in the equation start to shift and depending on how dramatically they shift this black & white equation becomes more and more gray to the point where there is no relevance or correlation at all. These variables include things like changing jobs, companies, company culture, people working there, new laws (well enforced ones), and the manager(s) taking a new training course, etc.

I suspect the graying of this change becomes more exponential with the number of variables changed. I suspect that last specific example has a more significant impact than others. The behaviors and perceptions of those in leadership roles whether it’s someone that’s a SME, team lead, resource manager, or yes, even a program or project manager can have a significant positive or negative impact on others’ motivations, performance, and work and personal habits. My basis for this is remembering some research on self-efficacy. In one such study (in the U.S. mind you) grade school students’ IQs scores were replaced with their locker numbers and giving those numbers to their teachers at the start of the year. The smarter kids were generally assigned lower locker numbers and vice-versa. The results were significant. Students who were top performers were now getting B- and lower grades. Students who in previous years had average and below average grades now had slightly to significantly above average grades. And the only school where the results were not statistically significant was at a school where a teacher happened to mention something in the teachers’ lounge and they all got to talking. Still, let’s not pick on teachers shall we? The fact is a lot people in all business fields behave this way. Even today. I’ve personally lost count of how many times over just the past month I’ve heard people say things in and out of my own workplace that make me want to just shake my head and say “What!?” Things like,

• Oh, he must know, he’s a VP / a doctor / a .... !
• She couldn’t possibly know. She’s just a secretary / .... .
• It’s important for us to teach children about democracy and standing up for one’s rights (by neither showing children that adults can behave well (ahem) like adults nor allowing individual teachers to decide if they want to support extracurricular student activities on their own). Oh, BTW, don’t get me started on the ‘might equals right’ strategy of Ontario politicians!

This was also a driving factor (of many) when ITIL as of version 3 changed from a set of ‘best practices’ to ‘good practices’ perhaps realizing this.

I’ll look for an opportunity to have another chat this week at the coffee machine with that person.

Oh, one other thing, history can be a very good predictor of the future. Wars, bigotry, overspending, listening to and sharing gossip just to name a few. It all depends on how open or closed one’s mind is to continually learning new things. When behaviors like I’m too busy to talk with so-and-so; oh, I already know. I ….; and so on are commonplace in any setting these broken telephones will also be rampant. 

Introducing Innovation Story Walls

An excellent and inexpensive tool for developing innovations where you work is using Innovation Story Walls. The scope of this blog topic is to offer some ideas on how you could and should implement these story walls. Many of us already know innovation makes a difference. It’s the:


• Key to survival and growth for all companies around the world,

• One of the highest sources of value creation,

• Diversity of ideas and sources of ideas that makes this so valuable, and it’s

• Typically a bottom-up phenomenon.

This has been proven over and over again in published research journals over the years, and this is our opportunity to expand on the innovations already identified via the Eureka portal.



No one, just because their role or has the market cornered on innovative ideas. The reality is that innovative ideas can come from anywhere and a lot of companies are recognizing that. It’s all about collaboration to crate new ideas because:

• Sometimes somebody has a great concept idea but no idea how to get from ‘here’ to ‘there’,

• Sometimes somebody has an idea to contribute that will help take a good idea and make it a better one but isn’t necessarily certain how to offer or contribute that idea,

• Sometimes somebody is shy about the concept idea they have or adding their 2¢, and

• Sometimes somebody has an idea how to get from ‘here’ to ‘there’ and just wants to open it up to others to make it more complete by offering any ideas they haven’t though of yet.


Now to the meat of this post ---

1) The objective of this tool is to (at a concept overview level):

• Publicizing what you’ve done , and

• Publicizing what you’d like to get done

It’s the latter of these two we’re interested in this post.

~ AND ~

2) Determine:

• What prerequisites people believe need to exist to implement the above and make it successful . . . .

• From and for managers and the leadership team(s) and

• From and for everyone else too

• What governing rules or constraints do you want in place? – i.e.

• Are anonymous story cards acceptable?

• Can people move or remove story cards that already exist?

• Do people want to use thread or strings to tie strong cards together or how will you string story cards together into a complete story?

• etc

• Where should innovation idea themes come from or should we have any at all?

• Should there be a maximum number of innovation ideas on the board at any one time?

• How do innovation opportunities can be added? – i.e.

• Should there be a spot on the wall for ideas in queue?

• What is the maximum time an innovation opportunity will remain up on the board and active . . . .

• Before it’s nullified / rejected,

• Before it’s formalized, or

• Before it’s removed due to inactivity

• Do you want to score ideas based on interest factor or some other criteria?

• Where the physical placement of the story boards should be in the workplace

• Which group(s) should govern this activity – i.e. who do people go to if they have questions?

• Who transposes the story cards into some on-line form or whatever before they are removed from the wall?

• Etc.


Need more convincing?

Two good, on-line articles on this topic are available at:

• http://www.forbes.com/sites/work-in-progress/2011/04/01/how-to-tear-down-the-walls-to-business-innovation/

• http://www.cognizant.com/business-consulting/Site%20Documents/fourwalls%20exec-sum.pdf

Classes or Categories of User Stories

Please see below. I couldn't easily find a site that has all of these definitions together in one spot. 

Epics 

Epics are large user stories, typically ones which are too big to implement in a single iteration and therefore need to be chunked into smaller user stories at some point before the effort required to complete them can be reasonably estimated. 

Themes 

A theme is a collection of related user stories.  For example, for a university registration system there might be themes around students, course management, transcript generation, grade administration, financial processing. 

Themes are often used to organize stories into releases or to organize them so that various subteams can work on them.   

Spikes 

The purpose of a spike is “to figure out answers to tough technical or design problems”. Spikes are considered useful when a more accurate time (and cost) estimate is required for an upcoming piece of work. 

Foundation development, investigation work and the set-up of a lab environment so it's ready for use when a software build becomes available for testing are all good examples of spikes. 

User Stories 

A user story is a high-level definition of a requirement, containing just enough information so that the developers and testers can produce a reasonable estimate of the effort, potential risks, key complexities, etc that need to be considered and are required to implement it. 

Tasks 

Tasks are single units of work such as checking out a code branch or installing a build in a test lab. 


Would you like this elaborated upon further? Just let me know. 

Us & Them ... Really

My kids and I were going through boxes of clutter this weekend to see what we could donate to the Sally Ann or just purge, and free up some space in the process. We did some sorting though too; to make sure we were not inadvertently disposing of something we wanted to or should keep -- like income tax receipts from 2009. :-)

During that effort, I came across the following hand written note; don't recall where it came from or what the original context was, and for all I know its a note for a speech given by the Dalai Lama. Regardless, I've seen a lot of "us & them" conflict, me-me-me, not my problem types of behavior and discussions as of late on-line, in the news, and elsewhere in multiple contexts. And the more I thought about it, the more this note seemed to apply to all of them whether it was a topic about implementing Agile strategies, coding versus testing work, leadership practices, or even some so-and-so on the news that didn't have enough forethought in his head to think "gee, I'm having un-diagnosed seizures (as reported by family members). Maybe I shouldn't drive!" The last example resulted in the death of an 11-yo girl. I agree; this is an extreme example. It's also a very good example of how serious the following applies. Thus, at the risk of being perceived as all philosophical and such hopefully this 'awakening' and 'it' noted below comes as some measure of serendipity the next time(s) any of us directly or indirectly experience those divisive rather than teaming behaviors.

Who are they? It's you, me, your family, friends; all of us. That is until we've experienced the awakening because its already happened, its about to happen to us, or some one we truly care about. For a lot of us, we awaken after it's happened and we struggle harder than we ever could have imagined. For some of us, we awaken while its happening and maybe there's a chance to stop it right there and then. For a few of us, we awaken before it happens and can stop it before it begins. The only question left is what are you doing to help awaken those who are still asleep, to help those who still have a chance to avoid or overcome the chaos.

Happy thoughts.

P.S.

For me, 'awakening' in the above refers to the known awareness, the epiphanies we all have at one time or another that help shape who we are as people and members of a society. Things that stay with us for the rest of our lives even if we don't recall exactly why. 'It' can be anything we encounter or endure.