Category Archives: Articles

IFPUG (News) Beyond MetricViews - FP for Agile / Iterative S/W Dev

With the support of QSM, Inc., I wrote and published this article on a new area of the International Function Point Users Group (IFPUG) website called “Beyond MetricViews.”

While the IFPUG already had published guidelines in this area, the key points to this article include:

  • If you want to measure productivity (or anything else) consistently across two or more software development projects – where each was developed using a different approach (i.e., waterfall vs. agile) – one must be consistent in the definition and application of the measures (and metrics);
  • Function points are defined in terms of elementary processes and agile methodologies deliver such functions iteratively (not complete in one iteration) – posing challenges to the uninitiated;
  • Regardless of whether you measure productivity, defect density (quality), costs or other aspect of software delivery – it is critical to do an “apples to apples” comparison.

Here’s the article (click on the image) for your interest.  (You can also visit the blog at www.qsm.com for details.)

ifpug

Comments and feedback is appreciated!

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

Apples and Oranges work in Fruit Salad, not S/W Measurement!

A colleague once observed at a professional conference that “Common sense is not very common” – and when it comes to the typical approach to software measurement, I have to agree.

Case in point – there are proven approaches to software measurement (such as the Goal/Question/Metric by the Software Engineering Institute, and Practical Software & Systems Measurement out of the Department of Defense) – yet corporations often approach metrics haphazardly as if they were making a fruit salad.  While a variety of ingredients works well in the kitchen, data that seem similar (but really are not) can wreak havoc in corporations.  Common sense should tell us that success with software metrics depends on having comparable data.

If only data were like fruit

– it would be easy to pinpoint the mangoes, apples, oranges, and bananas in company databases and save millions of corporate dollars.

Most Metrics Programs don’t Intend to Lie with Statistics, but many do…

I do not believe that executives and PMO’s (project management offices) have malicious intent when they start IT measurement and benchmarking initiatives.  (Sure, there are those who use measurement to advance their own agenda but this is the topic of a future post.)

Instead, I believe that many people trivialize the business of measurement thinking that measurement is easy to do once one directs people to do it.

The truth is that software measurement takes planning and consideration to get it right.  While Tom DeMarco‘s quote

“You can’t control what you cannot measure”

is often used to justify measurement start-ups, his later observations countered it.

In the 1995 essay, Mad about Measurement, DeMarco states:

“Metrics cost a ton of money.  It costs a lot to collect them badly and a lot more to collect them well…Sure, measurement costs money, but it does have the potential to help us work more effectively.  At its best, the use of software metrics can inform and guide developers, and help organizations to improve.  At its worst, it can do actual harm.  And there is an entire range between the two extremes, varying all the way from function to dysfunction.”

It is easy to Get Started in the Wrong Direction with Metrics…

Years ago, I was working with a team to start a function point based measurement program (function points are like “square feet for software”) at a large Canadian utility company, when an executive approached me.  “We don’t need function points in my group” he remarked, “because we have our quality system under control just by tracking defects.” As he described what his team was doing, I realized that he was swimming upstream in the wrong direction, without a clue that he was doing so.

The executive and his group were tracking defects per project (not a bad thing) and then interviewing the top and bottom performing teams about the defect levels.  Once the teams realized that those who reported high defect levels were scrutinized, the team leads discovered two “work arounds” that would keep them out of the spotlight (without having to change anything they did):

1. Team leads discovered that there was no consistency in what constituted a “defect” across teams (an apples to oranges comparison).  Several “redefined” the term defect to match what they thought others were reporting so that their team’s defect numbers would go down. Without a common definition of a defect, every team reported defects differently.

2. Team leads realized that the easiest way to reduce the number of defects was to subdivide the project into mini-releases.  Smaller projects naturally resulted in a lower number of raw defects. With project size being a contributing factor (larger projects = larger number of defects) it was easy to reduce defect numbers by reducing project size.

As the months ensued, the executive observed that the overall number of defects reported per month went down, and he declared the program a grand success.  While measurement did cause behavioral changes – such changes were superficial and simply altered the reported numbers.  If the program had been properly planned with goals, questions, and consistent metrics, it would have had a chance of success using defect density (defects per unit of size such as function points).  Improvements to the processes in place between teams could have made a positive impact on the work!

Given solid comparable metrics information, the executive could have done true root cause analysis and established corrective actions together with his team.

Instead, the program evaporated with the executive declaring success and the workers shaking their heads at the waste of time.

This was a prime case of “metrics” driving (dysfunctional) behavior, and dollars spent poorly.

Keep in mind that Apples and Oranges belong together in Fruit Salad

not software measurement programs.

Call me or comment if you’d like further information about doing metrics RIGHT, or to have me stop by your company to talk to your executives BEFORE you start down the wrong measurement roadway!

Have a (truly) productive 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

The importance of Being There (at work)!

Did you know?

Only 26 percent of IT employees in North America are fully engaged at work, while 22 percent are actually disengaged, according to a global study by consulting firm BlessingWhite.

Being there…

At a time when unemployment is at an all-time high, only one-quarter of IT workers are fully engaged or Wowed by their work, while the remaining 75% just go through the paces or don’t care at all.  When you consider specific industries fraught with frustrations of rework (exceeding 40% in some areas) and impossible deadlines such as in waterfall development, I would bet the excitement factor of going to work is even less.

#Kanban, #Lean, and #Agile communities are exceptions

The Agile Manifesto recently celebrated its 10th anniversary last month, and Kanban, Six Sigma, Lean, and Agile methods now share space with waterfall as leading methods in the software and systems development space.  Agile (in my humble opinion) was one of the first to restore a sense of sanity in software development.  In earlier times, a group of  business customers with rapid fire changing requirements would challenge software developers (tired of the constant change and “jello” like demands) for amorphous software products.  The result too often – failure.

It makes sense, in this type of environment, to do iterative development.  It was illogical to do the opposite: long development cycles to produce products already obsolete before they hit desktop computers.

Approaches like Kanban, Lean, Agile, Personal Kanban and others continue to transform our industry and inspire software developers to become “fully engaged” in the work.

Less head banging… but you have to engage

Certainly there is head banging and more job satisfaction in this new world (if “tweet volume” is any indication, the Kanban/ Lean/ Agile communities are a happier lot!) but it takes commitment to show up and be part of the action.

I believe that the Kanban and Lean and Agile communities know the importance of really being present and engaging at work.  We also know it is critical to create a community of like-minded people who meet in-person – at conferences, local meetings, at social events.

LSSC11 is coming soon!

The landmark Lean Software and Systems conference is only 10 weeks away in Long Beach, CA on May 3-6, 2011.  Make your choice of conference to attend in 2011 the LSSC11 (especially if you can only attend one!)  See my related post Top 10 Reasons to attend LSSC11.

Join the movement of people who know the Importance of Being There in software and systems development: The Lean and Kanban and Agile communities.  I hope I will meet you at LSSC11!

Have a Wow! and engaging week at work,

Carol

Share

Pre-flight email checklist: THINK before you click...

I AM OVERWHELMED BY EMAIL!

There I said it, I am overwhelmed with email and I can’t stand it!

I thought I was the only one until I read Tim Tyrell-Smith’s post today: How to reduce the Quantity of Incoming Email and realized that there should be a pre-flight email checklist to save our sanity… and to encourage Thinking before Clicking!

Since joining the world of social media I realize my “connectivity” has grown exponentially, but not all in a good way. Even with my SPAM filters set to high, I get so much email that it is overwhelming!

I feel like I must have ADD (attention deficit disorder) because my day is interruption after interruption (sorry TweetDeck!) and I need help (and I know I am not the only one!)

Pre-flight email checklist (THINK before you click):

  1. If it takes longer to write an email (to one person) than it does to walk across the hall / call the person, don’t write an email. Pick up the phone or get up from your desk.
  2. If multiple people are involved and you need responses, consider whether a one hour meeting would work better than filling up in baskets with back and forth threads for the next 2 weeks.  If so, schedule a tight meeting and solve the issue in one fell swoop.  (Just because it doesn’t take paper doesn’t mean email is green — it can litter cyberspace!)
  3. If 1 and 2 are not possible, consider other options: Twitter or a blog post or an update at a staff meeting might be better than email.
  4. You’ve thought through 1,2 and 3 and decide your message needs an email.  Never negligently click “Reply all!”  unless you’ve gone through these same steps:Make sure you set aside a dedicated time (10 minutes minimum) to THINK before you click:
  • Consider your recipient: Walk for a moment in their shoes and think: what would be your response to this email? Make sure to emphasize the key points (i.e., make the reason for the email crystal clear). Do not “assume” that everyone shares your knowledge so give necessary background.  In the words of Peter Drucker:  It is important to state the obvious otherwise it may be overlooked.
  • If you expect/need a response, be clear about it. Tell recipients what you need from them (each), by when, and how (call, email, comment, decide…).
  • If it is an information only email, say so. No one has time to read your mind.
  • Consider using the subject line as a filing cabinet: Use tags to identify topics and intent. E.g., ABC Department meeting notice, Feb 17, prep material attached; or Dekkers: Blog Marketing draft – comments needed by Feb 20, 2011.  In this way, recipients can quickly find YOUR email from a pile in their in basket.
  • Consolidate information! If the email is about a meeting: include dial-in information (top and center for easy access!), meeting date and time, and  attach all preparatory material all together in a single email. There is nothing worse than having to pull up 3 emails to get ready for a single meeting!
  • Preview before sending: Spellcheck, attach files, check all recipients are included.
  • If there is emotion involved save the draft email and wait a full day (or at least an hour) before doing the doublecheck and send step below.
  • If it’s a regular email (non-emotional), take a one minute break – stand up, look out the window, anything to clear your head. Then go back and re-read your email, double-check attachments, recipients, bcc’s etc.
  • When you are sure it looks right consciously hit “send”. NEVER hit send when you are multi-tasking (i.e., on the phone). Once an email has been sent it is in cyberspace FOREVER (regardless of rescinds!)

I plan to follow this checklist starting today! What do YOU think? Do you have any additions?

p.s., DON’T forget to sign up for my Feb 17, 2011 (11am – 12:30 pm EST)  FREE Webinar:  Navigating the Minefield – Estimating before Requirements.

Register here: http://tinyurl.com/6flgjwr

To your increased productivity!
Carol

Share