Category Archives: Communication

Image

In a few words: why IT is so intimidating


As a project manager and software metrics expert, I’ve learned that simplicity and clarity are the keys to effective communication.  Consider that when we meet someone from another country, we use simple words, phrases and paraphrasing to communicate our meaning. Most of us would consider it rude and intimidating to talk to a foreigner using complex English and idioms.

Yet, that’s exactly what happens when we, software professionals, talk to … well almost anyone but ourselves.  We are technical professionals with access to reams of data, and you might think the idea of simplicity and clarity would be common sense.  Sadly, it’s quite the opposite.  Like medicine, engineering, and other technical professions, we seem to take pride in creating acronyms and continually redefining the English language to suit our purpose.  Then, we scoff at anyone who doesn’t understand, and expect them to bone up on their vocabulary.

It really only takes a few obscure words to intimidate someone, in IT we can do it with one or two (such as “artifact” or “construct” or “provisioning.”)

I’ve seen it for decades – instead of using common English words (with known definitions) or inventing brand new terms, the software industry tends to complicate things by using words that are already known, and changing the definitions.

I noticed this trend in my first post-college job when someone in my department (pipeline engineering) set me up to use the mainframe computer.  As luck would have it, my system crashed on the first day and I had to call computer services.  When asked for my “terminal address” the group howled when I said “the fourth floor” when obviously they had referred to the 16 digit serial number on the right side of my computer monitor.  When I took a job working in that same technical group months later, I had to learn a whole new vocabulary.  Instead of talking about documents or papers or manuals, my co-workers talked about “deliverables” which also included hardware and software among other things.

I learned that DASD and TCPIP were words in themselves used to mean specific things but few could remember what were the words that made up the acronym.  As confused as I was as a graduate engineer with programming experience, I wondered how much more confused our customers must be.

Then along came new SDLC’s (software development “life cycles”), new methodologies (approaches and guidelines for developing software), and new concepts such as object-oriented programming. Each new wave washed ashore with a mixture of new, re-defined and sometimes arcane terms with very specific meanings. Sometimes the “common English usage” definition prevailed, other times the term had an entirely new definition.

Take the word “artifact” for example.  The first definition is the way that it is defined in common English usage (Google.com) and the latter is specific to IT.

artifact

artifact it

 

 

 

So, now instead of saying document or manual or deliverables in general conversation and in meetings, artifact was used.  Ugh…. customers shrugged, IT didn’t notice the misunderstanding.  Business chugged on with an ever widening communication gap, and projects missed their targets.

Today things are beyond mere terminology changes.  We’ve even started banning certain words we don’t think fit our purpose – in spite that a term is well-understood.  For example, I recently read a post that proposed banning the word “project” from the vocabulary and replacing it with “initiative” to redirect professionals to focus on product delivery instead of start and end date.  It’s a great idea to focus on product delivery and getting all the teams on board to focus on output, but terminology is already a fundamental divisive issue. Ugh.

All in all, I believe that one of the biggest chasms in software development today lies in communication between technical professionals and the business.  We’re really two different cultures (more about that in another post) and the use of simple, common English terms (with standard definitions) could bridge some of the gap.

As the title says:  In just a few words… IT is intimidating.

What do you think?

Have a great week!

Carol

Combining Soft Skills and Hard Tools for Better Software


One of the more interesting topics in software development (at least from my perspective) is the culture of the industry.  Seldom does one find an industry burgeoning with linguistics majors, philosophers, artists, engineers (all types – classically trained to self-named), scientists, politicians, and sales people – all working on the same team in the same IT department.

This creates an incredible diversity and richness – and leads to sometimes astounding leaps and bounds in innovation and technological advancement, but it can also create challenges in basic workplace behavior.  This post takes a look at the often overlooked soft skills (empathy, leadership, respect, communication, and other non-technical skills) together with technical competencies as an “opportunity” (aka challenge or obstacle to overcome.)

It was published first on the Project Management Institute (PMI) Knowledge Shelf – recently open to the general non-PMI public.

soft skills

Added bonus here:  I referenced the You Tube 2013 University of Western Australia commencement address by Australian comedian/actor Tim Minchin at the University of Western Australia in 2013 in my post (he shares his 9 recommendations to graduates, my favorite -and the one I quoted – is #7 Define yourself by something you love!)  I believe it’s worth the watch/listen if you need to take a break and just sit back and think about soft skills during your technical day. (Warning to the meek of heart – it’s irreverent, offensive, and IMHO, bang on in his core sentiments.  If you’re offended, I apologize in advance!)

If you’d like a pdf copy of the post above, please leave me a comment with your email address!  (And even if you don’t, I’d love your opinion!)

Have a great week!

Carol

Measurement and IT – Friends or Frenemies ?


I confess, I am a software metrics ‘geek’… but I am not a zealot!  I agree that we desperately need measures to make sense of the what we are doing in software development and to find pockets of excellence (and opportunities for improvement), but it has to be done properly!

Most (process) improvement models, whether they pertain to software and systems or manufacturing or children or people attest to the power of measurement including the CMMI(R) Capability Maturity Model Integration and the SPICE (Software Process Improvement Capability dEtermination) models.

But, we often approach what seems to be a simple concept – “Measure the Work Output and divide it by the Inputs” back asswards (pardon my French!)

Anyone who has been involved with software metrics or function points or CMMI/SPICE gone bad can point to the residual damage of overzealous management (and the supporting consultants) leaving a path of destruction in their wake.  I think that Measurement and IT are sometimes the perfect illustration of the term “Virtual Frenemies” I’ll lay claim to it!) when it comes to poorly designed software metrics programs.  (The concepts can be compatible – but you need proper planning and open-minded participants! Read on…)

Wikipedia (yes, I know it is not the best source!) defines “Frenemy (alternately spelled “frienemy“):

is a portmanteau of “friend” and “enemy” that can refer to either an enemy disguised as a friend or someone who’s both a friend and a rival.[1] The term is used to describe personal, geopolitical, and commercial relationships both among individuals and groups or institutions. The word has appeared in print as early as 1953.

Measurement as a concept can be good. Measure what you want to improve (and measure it objectively, consistently, and then ensure causality can be shown) and improve it.

IT as a concept can be good. Software runs our world and makes life easier. IT’s all good.

The problem comes in when someone (or some team) looks at these two “good” concepts and says, let’s put them together, makes the introduction, and then walks away.  “Be sure to show us good results and where we can do even better!” is the edict.

Left alone to their own devices, measurement can wreak havoc and run roughshod over IT – the wrong things are measured (“just measure it all with source lines of code or FP and see what comes out”), effort is spent measuring those wrong things (“just get the numbers together and we’ll figure out the rest later”), the data doesn’t correlate properly (“now how can we make sense of what we collected”), and misinformation abounds (“just plot what we have, it’s gotta tell us something we can use”).

In the process, the people working diligently (most of the time!) in IT get slammed by data they didn’t participate in collecting, and which often illustrates their “performance” in a detrimental way.  Involvement in the metrics program design, on the part of the teams who will be measured, is often sparse (or an afterthought), yet the teams are expected to embrace measurement and commit to changing whatever practices the resultant metrics analysis says they need to improve.

This happens often when a single measure or metric is used across the board to measure disparate types of work (using function points to measure work that has nothing to do with software development is like using construction square feet to measure landscaping projects!)

Is it any wonder that the software and systems industries are loathe to embrace and take part in the latest “enterprise wide” measurement initiative? Fool me once, shame on you… fool me twice, shame on me.

What is the solution to resolving this “Frenemies” situation between Measurement and IT?  Planning, communication, multiple metrics and a solid approach (don’t bring in the metrics consultants yet!) are the way.

Just because something is not simple to measure does not make it not worth measuring – and measuring properly.

For example, I know of a major initiative where a customer wants to measure the productivity of SAP-related projects to gain an understanding of how the cost per FP tracks on their projects compared to other (dissimilar) software projects and across the industry.

Their suppliers cite that Function Points (a measure of software functionality) does not work well for configurations (this is true), integration work (this is true), and that it can take a lot of effort to collect FP for large SAP implementations (can be true).  However, that does not mean that the productivity cannot be measured at all!  (If all you have is a hammer, everything might look like a nail.)

It will require planning and design effort to arrive at an appropriate measurement approach to equitably and consistently track productivity across these “unique” types of projects. While this is non-trivial, the insight and benefits to the business will far exceed the effort.  Resistance on the part of suppliers to be measured (especially in anticipation of an unfair assessment based on a single metric!) is justified, but a good measurement approach (that will fairly measure the types of effort into different buckets using different measures) is definitely attainable (and desired by the business.)

The results of knowing where and how the money is “invested” in these projects will lead to higher levels of understanding on both sides, and open up discussions about how to better deliver!  The business might even realize where they can improve to make such projects more productive!

Watch my next few posts for further details about how to set up a fair and balanced software measurement program.

What do you think?  Are measurement and IT doomed to be frenemies forever? What is your experience?

Have a good week!
Carol

The Death of Brainstorming? Say it isn’t so…


I love the articles in the New Yorker, and the following one caught my eye because of the Brainstorming topic. In leadership courses, I’ve espoused the value of brainstorming when done right (without judgement and analysis) – and I’ve seen positive results.  Could it be that the creative process might actually work better when criticism is allowed to fly?

Say it isn’t so

When I teach brainstorming techniques, I always find it interesting that the creative (right brain dominant) thinkers in the group really love and contribute more during the “Brainstorming” free flow of ideas phase (before analysis sets in), while the linear, engineering style (left brain dominant) thinkers in the group can’t wait for the second phase where the ideas are analyzed and critiqued.  Divergent thinking followed by convergence of ideas.  Made perfect sense to me and the students demonstrated how safe each group felt – depending on which side of the brain dominated their idea flow.

So now, it appears that the “Steve Jobs” style of criticism before acceptance, domineering boss-like, judgment first ways of working have merit, or do they?  Read the article then read on and comment (please!)

Here’s the link to “Groupthink” if you cannot reach it above.

I’m conflicted…

about this latest “research” and given my international experiences in presenting in over 30 countries to technical audiences, I have to say that Information Technology and software development are as much about the people and psychology (trust and communication) as they are about technology and engineering problems.

I’ve seen success with collaborative approaches like Kanban, agile, Rational (Use Cases) – which I believe succeed because we bring disparate viewpoints of the customers and suppliers together and address various learning styles (visual, audio and kinesthetic) to gain the highest levels of understanding.  Brainstorming is one such technique whereby the most dominant (i.e., typically the most critical of all ideas except his/her own) no longer gets to direct the problem solving.

What’s BEEN your experience?

I look forward to your comments – do you agree with these findings? – and to further research… and to hopefully announcing that Brainstorming is NOT dead, in fact, it just needed a wake-up call to re-energize the benefits for a new iPad generation!

Trust and Verify are the (IT) Elephants in the room


As a party involved in some aspect of software development, why do you think projects are so hard?  Millions of dollars in research work to solve this question, with the result being new models, agile approaches and standards, all intended to streamline software development.

What do you think is the core reason for project success or failure?  Is it the people, process, requirements, budgets, schedule, personalities, the creative process or some combination?

Sure, IT (information technology) is a relatively new industry, plagued by technology advances at the speed of light, industries of customers and users who don’t know what they want, budgets are preset, schedules are imposed, scope is elusive, and, ultimately computer scientists and customers still speak their own language.  Some people argue that it boils down to communication (especially poor communication).  After all, isn’t communication the root cause of all wars, disputes, divorces, broken negotiations, and failed software projects?

I disagree.

I believe that TRUST and VERIFY are THE TWO most important factors in software development

These two elements are the IT elements in the room (so to speak!) I could be wrong, but it seems like the commonly cited factors (including communication) are simply symptoms of the elephants in the room – and no one is willing to talk about them.  Instead, we bring in new methodologies, new tools intended to bring customers and suppliers together, new approaches, and new standards – and all of these skirt the major issues: TRUST and VERIFY.

Why are these so critical?

Trust is the difference between negotiation and partnership – trust implies confidence,  a willingness to believe in (an)other, the assurance that your position and interests are protected, and the rationale that when life changes, the other party will understand and work with you. A partnership means that there is an agreement to trust in a second party and to give trust in return.  Trust is essential in software development.

BUT… many a contract and agreement have gone wrong with blind trust, and that is why VERIFY is as important as trust. Verify means to use due diligence to make sure that the trust is grounded in fact by using knowledge, history, and past performance as the basis.  Verify grounds trust, yet allows it to grow.

President Ronald Reagan coined the phrase “Trust, but Verify” – but I believe it is better stated as “Trust and Verify” because the two reinforce each other.  This also suggests the saying:  “Fool me Once, Shame on You… Fool me Twice, Shame on Me.”

Proof that Trust and Verify are the Elephants in the Room

Software development has a history of dysfunctional behavior built on ignoring that Trust and Verify are key issues. It is easier for both the business (customers) and the engineers (suppliers) to pretend that they trust each other than address the issues once and for all.  To admit to a lack of trust is tantamount to declaring war and accusing your “partners” of espionage.  It simply is not done in the polite company of corporate boardrooms.  And so we do the following:

  • Fixed price budgets are set before requirements are even known because the business wants to lower their risk (and mistrust);
  • Software development companies “pad” their estimates with generous margins to decrease their risk that the business doesn’t know what they want (classic mistrust);
  • Deadlines are imposed by the business based on gut-feel or contrived “drop dead” dates to keep the suppliers on track;
  • Project scope is mistakenly expressed in terms of dollars or effort (lagging metrics) instead of objective sizing (leading metrics);
  • Statements like “IT would be so much easier if we didn’t have to deal with users” are common;
  • Games like doubling the project estimate because the business will chop it in half become standard;
  • Unrealistic project budgets and schedules are agreed to to keep the business;
  • Neither side is happy about all the project meetings (lies, more promises, and disappointment).

Is IT doomed?

Trust is a critical component of any successful relationship involving humans (one might argue that it is also critical when pets are involved) – but so too is being confident in that trust (verify).  Several promising approaches address trust issues head on, and provide project metrics along the way to ensure that the trust remains.

One such approach is Kanban (the subject of this week’s Lean Software and Systems Development conference LSSC12 in Boston, MA).

Kanban for software and systems development was formalized by David Anderson and has been distilled into a collaborative set of practices that allow the business and software developers to be transparent about software development work – every step of the way.  Project work is prioritized and pulled in to be worked on only as the volume and pace (velocity) of the pipeline can accommodate.  Rather than having the business demand that more work be done faster, cheaper and better than is humanly possible (classic mistrust that the suppliers are not working efficiently), in Kanban, the business works collaboratively with the developers to manage (and gauge) what is possible to do and the pipeline delivers more than anticipated.  Trust and verify in action.

Another promising approach is Scope Management (supported by a body of knowledge and a European based certification) – a collaborative approach whereby software development effort is done based on “unit pricing”.  Rather than entertaining firm, fixed price, lose-lose (!!!) contracts where the business wants minimum price/maximum value and the supplier need to curtail changes to deliver within the fixed price (and not lose their shirts), unit pricing actually splits a project into known components can are priced similarly to how home construction can be priced by square foot and landscaping priced by the number of trees.

In Scope Management (see www.qualityplustech.com and www.fisma.fi for more details or send me an email and I’ll send you articles), the business retains the right to make changes and keep the reins on the budget and project progress and the supplier gets paid for the work that the business directs to be done.  Project metrics and progress metrics are a key component in the delivery process.  Again TRUST and VERIFY are key components to this approach.

What do you think? 

Please comment and share your opinion – are TRUST and VERIFY the IT elephants in the rooms at your company?

P.s., Don’t forget to sign up for the SPICE Users Group 2012 conference in 2 weeks in Palma de Mallorca, Spain. See www.spiceconference.com for details!  I’m doing a 1/2 day SCOPE MANAGEMENT tutorial on Tuesday May 29, 2012.

Walking on Eggshells – a Normal part of Business?


We have all been there – walking on eggshells to avoid outbursts from  a boss, co-worker, or client.  So we skirt the issue, pretend the bad behavior doesn’t exist, ignore the problem, and spend extra time planning how to present an issue so that the person in question doesn’t explode.

While I know that this type of behavior is rampant in business (I’ve experienced it more than once!) – it has serious (and expensive) consequences in the IT industry.  The repercussions stemming from having to “walk on eggshells” to avoid the potential wrath ranges from minor  “oversights” to full scale project failure.

The Challenger disaster is one such failure where group-think and avoidance of conflict ended up costing lives and millions of dollars.  A video chronicling the group think behavior depicts the group-think behavior and steps are taken in companies to address such behaviors. This is all good.

The Walking on Eggshells “syndrome”

Aside from the pressures of group think that encourages teams to conform and cooperate with a single mindset, the “walking on eggshells” syndrome is seldom documented or even discussed.

We all know at least one offender in our workplace!  The offending person may be a narcissist, a control freak, a bully or just plain immature. No matter the clinical diagnosis, our boardrooms and our production labs suffer greatly from their presence.

How much time and money could be saved by confronting these people and addressing the cost of their ‘verbal diarrhea’? Here’s the type of situations I mean:

  • Not raising issues:  “How can we possibly bring up the design flaw for this software now?  The project sponsor will yell and rant if the project is late. Remember how he “freaked out” at the status meeting last month?  Keep going and we’ll address this as an enhancement.”  Cost: could be significant.
  • Cutting corners: “There is no way we can finish the project within the approved budget.  We had no idea that xxx would be so complex, but the steering committee will fire us if we ask for more money. Let’s just cut testing so we can finish the project.”  Cost: could be critical if public safety is at stake.
  • Perpetuating the myth that project plans are right:  “The project plan was based on incomplete data that seemed right six months ago. Now we know more, but with a fixed budget and schedule, we’re stuck. The client will explode if we bring up that the plans were flawed. Let’s just do what we can.” Cost: Corporate learning will never happen (Einstein: insanity is doing the same things over and over and expecting different results.)
  • Skirting accountability: “We messed up on the schedule because we had to program that module 3 times.  I couldn’t understand what they wanted until this time, but we can’t tell Bob because you know how he gets.  I hate it when he yells in a staff meeting.” Cost: could be significant to minor.
  • Wasting time and money: “This project is doomed – the users told us they won’t use the system even if we finish it. The rationale and vision for the project are no longer correct (it’s a dog!) but if we tell the boss about it, you know how she will blame us. I don’t think it is even worth trying to explain it.  Just keep going.”  Cost:  priceless – time and money could be better spent on REAL work!

What a colossal waste of time, money, energy, and morale “walking on eggshells” is to a business!  It is not an easy situation to fix or address – especially when we are talking about people in power who behave badly.

Walking on eggshells should never be part of the way of doing business!  What is the solution?

If YOU were the king of your IT kingdom, what would YOU do?  I’ll publish a summary of responses – add your comments below – or send them privately to me by email to dekkers (at) qualityplustech (dot) com.

Have a productive week!

Carol

Common-sense Leadership: Respond not react…


A big benefit to teaching leadership and communication workshops to adult professionals is continuous learning: every time I teach a class, new revelations come into focus.

One such “aha” moment (where one realizes something that may not have been obvious before) is that Leadership is really about learning to Respond to a situation or stimulus instead of automatically Reacting.  Why is this important?  Responding is the thought intensive process of actively listening, pausing, and then gathering ones “thoughts” before speaking.  Gathering of one’s thoughts involves the neocortex (center) of the brain whereby we override the reptilian (instinctual) brain and the limbic (emotion-induced) brain, and hopefully create a response less prone to immediate and autonomous reactions (based on instinct or emotion).

Considering how eastern cultures (such as Japan) seem to habitually pause before asking questions at a conference or before coming to an agreement gave me “pause” to reflect on how this practice conveys power and respect – and is one often used by practised politicians at press conferences.  This results in less “eating one’s premature words” and less damage control as opposed to when one speaks too hastily or without due thought.

This is a common-sense tip on how to practice better leadership in your own workplace no matter your position:  remember and practice active listening (if you are thinking of what you are going to say – you are not listening!), pausing, gathering your thoughts (and perhaps even saying “please give me 15 seconds to gather my thoughts”) and then thoughtfully responding.

Food for thought – what do you think?  Could this be helpful in your workplace?

Carol

The Most Critical Skills in the 21st Century – are they Hard or Soft?


The past few months I’ve found myself instructing a series of Leadership and Communication workshops for adult professionals across the United States, together with delivering a series of Keynote Conference addresses in Europe on similar topics.

At one particular address in Dublin, Ireland, I emphasized that the beauty of modern software development approaches (such as Kanban) is that the development team can lay bare their work pipeline and ultimately collaborate (through effective leadership and communication skills) with the business. After a series of illustrative exercises (yes, at a keynote address!), attendees by and large embraced the principles of collaboration along with the concept that we need to refrain from treating each other as “machines” at work (formulated along the lines of Margaret Wheatley‘s ideas.) By treating each other as human beings from the kickoff meeting (at least), projects can achieve resounding levels of success.

One particular conference on Quality Assurance and Testing featured not only my keynote (A Soft Skills Toolkit for Testers!) on Leadership and Communication,  but at least three others of similar slant: presentations that emphasized teamwork, respect, and collaboration.  I believe that these are essential components to the success of any project!

One key point I bring home in all of my training and keynotes is that as engineers and computer scientists, we tend to minimize the emerging importance of soft skills such as leadership and communication (I have an entire 16-piece toolkit for this) as “fluff” in favor of what we often see as superior technical “hard skills”.  As an engineer myself, I see the pitfalls of a technically competent workforce that cannot talk outside of its own niche – and many others agreed.

But, it came to fully illustration the evening after one keynote.  A group of us had gathered at a local pub to sample the local beverages when the wife of a conference chair (a science based PhD herself) approached me to comment on what she had heard about my morning keynote:

“Carol, I heard that you gave an entertaining keynote presentation today, “

she started,

“…but it was “entirely without substance.”

What she was in fact saying was that my keynote, in her and her husband’s opinion, had some redeeming entertainment value, but the lack of research-data based charts and advanced equations, rendered it “entirely without substance.”

I did suppress my inclination to applaud and say “thank you for illustrating my point so eloquently” when she said this because I realized it might be a futile discussion.  Instead, I simply smiled, thanked her for her comment, and turned back to the business and beverage at hand.

Now that I am contemplating a series of workshops for future conferences (technical software engineering and quality conferences) to continue the discussions on Leadership and Communication, it occurs to me that calling these skills “soft” may actually diminish their importance – regardless of proof that Leadership, Communication and Collaboration are some of the most important and hardest skills to teach our industry leaders in the 21st century.

What do YOU think?  Are Leadership skills (such as managing to relationships, emotional intelligence, cultural intelligence, diversity, and working with teams and people) considered more as Soft Skills or as Hard Skills (akin to programming in dot net or Java) or a mix of both?

As a technical professional – how important do you think are Leadership and Communication skills to the success of your projects?

I will be awaiting your comments!

Happy holidays!

Carol

p.s., Send me an email if you’d like to see more about the Soft Skills Toolkit for Testers presentation I did in October. I would love feedback and recommendations.

Communicating Quality in a Heavily Wired World – Presentation Slide Share


I’ve been on hiatus (so to speak) since mid-May, but I’m back with miles traveled, countries visited (Canada, France, Ireland), and lots of tech experiences in between – to share with you!

A Gift for you and a Favor…

I spoke as the finale speaker for our Institute for Software Excellence (ISE) conference within a conference (part of the American Society for Quality‘s International Conference on Quality and Innovation in Pittsburgh in mid-May – the topic was the subject line of this post above- which I also affectionately named – No More Death by Powerpoint!

As a presenter, I’m pleased to share with you the link to my slides (yes, with tips for using PowerPoint using PowerPoint slides themselves!) and coordinated audio.  This is my gift to you and I’d be interested in your comments – please let me know what you think!

Here’s the abstract for the presentation:  Quality professionals are passionate about the value and benefits of quality in their work, but when it comes time to present the proof to executives, communicating the value can be a challenge. We are all so busy and overcommitted that we often lose the message in the media. This session takes a look at and offers remedies to common presentation missteps such as “death by PowerPoint,” “tilt- slide overload,” and “duh?”

Now, here’s the link to the full presentation:

Now the favor – can you please fill out the poll below?

I am working with an editor to publish my ebook about Communication for Technical Professionals (Project managers, engineers, scientists, IT) using some of these blog posts –  and I need YOUR help to select a title. Will you help?

Thank you!!!

Have a great week,
Carol

Share

Technology at the Speed of Sound… Catch up at Light Speed at LSSC11!


I have to admit that I have not programmed a computer for many years and I have no idea how to write Visual Basic or Java or dot net.  (Yes, I have done raw html and could still manage in SAS if I had to!)

And I can also admit that the proliferation of models and methods from Agile, Scrum, Kanban, Lean, Six Sigma, Xtreme Programming, CMMI(R) (Capability Maturity Model), to manifesto driven systems development,  has me daunted.

Which ones are interchangeable, which are compatible, which are contradictory, and (OMG) where should one start to learn how to avoid the pitfalls?

It’s all a matter of diving in to each and learning the ins-and-outs and best practices — except I know that there are as many opinions about best practices as there are models.

Okay, I can already hear you saying:  “Carol, as a software measurement/Function Point Analysis and PMP (Project Management Professional), you probably don’t need to know much about any of these” — except that I do!

My clients will ask me about these and other emerging topics – and expect that I know the best course of action they should take with Lean/ Kanban/ Agile methods for their company.  And I simply do not have spare time to read all the books, experiment, fail, try again, and then decipher what is hype and what is real in this space!

So what is a sane, intelligent, forward thinking IT professional like me to do when faced with an overwhelming mountain of information like this so I can properly advise my clients?

The answer is: ATTEND the Lean Software & Systems Conference 2011 (#LSSC11)!

There is no other conference in the same timeframe that offers more than this growing conference!

Being held 3-6 May, 2011 at the Hyatt Long Beach in Southern California, this annual conference boasts over 90 speakers over a 3 day period on topics ranging from:

See the full program at http://lssc11.leanssc.org

All given by practitioners and experts for practitioners!  And the majority of presenters have real world, hands-on experience in the trenches with Kanban, Lean, Agile and Scrum and lived to tell about it!

Why not catch up to technology racing at the speed of sound by accelerating your learning Light Speed with LSSC?

There is no similar conference offering the breadth or depth of topics, experience sharing, or real case study results in the Kanban and Lean software development space.

And the May 5, 2011 Brickell Key awards for excellence in the advancement of Lean in software development will recognize some outstanding nominees working in the area – some of which are professionals just like you!

I know that I will catch up on these major topics and more – in record time – by attending LSSC11.  If you are an IT professional, don’t you owe it to yourself to check it out?

Read about the Program and the Speakers at LSSC11 and register today!

Wishing you an eventful and productive week and I hope to see you in Long Beach on May 3, 2011!

Regards,
Carol

Share