Øredev 2016
November 9 – 11
Malmö, Sweden

Øredev was AWESOME!  The short review reads: good sessions, good food, good people and great conversations.  Here’s the longer version . . . (more…)

I am participating in QAI TesTrek 2013, October 28 – 30 at the Eaton Chelsea Downtown Toronto. 

On October 28th I will be facilitating the “Agile Practical Techniques Workshop.”

Agile Practical Techniques Workshop helps developers, testers, business analysts, scrum masters and project managers to develop an understanding of Agile development techniques focusing on concepts such as test driven development that integrate testing into the Agile process. 

On October 29th i will be leading the “Lean Software Development Workshop.”

Lean Software Development Workshop (e.g. Kanban, Flow and Kaizen) uses a lean-agile focus to help everyone involved in developing, enhancing and maintaining software employ the Principles of Lean to enhance the delivery of value-added work.

Both workshops will be great time!

On October 30th I will be presenting “Agile Under-performing? Keys to Improving Delivery.  Just because you have implemented Agile techniques does not mean you are performing to the level which your organization is capable!

I hope to see you there!  If you are going please contact me and perhaps we can have a beer or join up for a morning jog!

http://www.qaitestrek.org/2013Toronto/

Flyers:

TesTrek2013_NewFormat

TesTrek2013_MWInvite

As many of you know, I interview Cheryl Jones on the SPaMCAST 82 – Cheryl Jones, PSM, Optimism .  If you are interested in PSM specifically and measurement general I would suggest checking out 14th annual PSM Conference.

PSM 14th Annual Users’ Group Conference, 26-30 July 2010
New Orleans, Louisiana

I want to invite each of you to attend our Practical Software and Systems Measurement (PSM) 14th Annual PSM Users’ Group Conference.  It should be a terrific conference!  The theme this year is “Ensuring the Integrity of Measurement Information”.  We will discuss how to making measurement information useable for decision makers.  Presentations will cover implementing and using fact-based information, measurement to support improved life cycle decision making in an evolving environment, business intelligence using fact-based measurement and risk management information, using measures to improve efficiencies and guide performance improvement, measuring affordability of systems and software, and measurement at the enterprise, organization, and project levels.

The conference is being held at the New Orleans Marriott at the Convention Center in New Orleans, Louisiana this year, a venue that provides great opportunities for networking in a relaxed and fun atmosphere. This is a fabulous city, and all participants will receive a reduced hotel rate of $89 per night (this is less than the per diem rate). There are many nearby attractions including the French Quarter. The registration form is available on the PSM web site, under “Events”.

Please note – you will receive the reduced conference rate if you submit your registration and hotel reservation by June 18th.

At the conference, there will be keynote presentations, as well as a series of presentations by measurement practitioners and users, with a focus on actual implementations and lessons learned.  We will also host a series of interactive workshops to explore various measurement topics. Workshops are being considered in the areas of: Decision Making in Engineering Management, Organization/Enterprise Measurement, Risk Management and Measurement, Advanced Analytical Techniques, Sample Measurement Specifications, Systems and Software Estimation, Measurement for Service Management, Measurement for ERP systems, and Maintenance Measures.

The conference will begin with a 1-day training session, for those who are new to PSM, and a 1-day session for PSM trainers, to review the revised training course.  A preliminary agenda with presentations and workshop descriptions will be posted on the PSM web site (www.psmsc.com/events.asp), as plans are finalized.

If you are interested in providing a presentation, or hosting a workshop, please review the call for speakers that is available on the PSM web site, and send in an abstract.

For more information, contact the PSM Support Center at PSMUG2010@psmsc.com, Dave Morris at 703-405-2191, or Cheryl Jones at 973-724-2644.

Last week I attended the Better Software Conference in Las Vegas.  It was an excellent conference, go next year!  At the conference  “When Good Numbers Go Bad” won the best paper award!  

Here is an update of an in-process essay that will be on SPaMCAST this weekend. 

“Why Are Requirements So Hard To Get Right: Process” Thomas M. Cagley Jr. As noted in the first component of “Why Are Requirements So Hard To Get Right: People”, getting requirements right is a complex task.  People, process and environment must align (or be aligned) to create an outcome that has value and can stand the test of time.  In this second installment of the essay we will explore the influence of process of ‘getting it right’.   One of the common process problems is approaching each requirement gathering or development situation in an ad hoc manner.  Assembling (or making up) a process as you do the work is it at best inefficient and at worst ineffective. My observation is that natural selection will erase this problem over time.  Assuming a stable workforce and failing to get requirements right (at least at delivery) is generally viewed as a career limiting move. The tactics that work will naturally be selected overtime if for no other reason than to avoid the beatings that follow failed projects.  Unfortunately the process of natural selection takes a long time and with the high probability of staff turnover that occurs in this type of shop, the outcome of trying to all the process without intervention until you find the right on one is . . . ambiguous. There are as many requirements processes as consultants in the world and maybe a few more as a garnish.  Processes come in many shapes, sizes and perceived level of discipline. Equally variable as process are the cultures and subcultures of organizations where processes will be applied. The challenge presents of trying to match process or method to culture. While basic rules for matching are quickly apparent, such as not matching Agile methods to highly regimented organizations (or if you do, to understand the risks). There are however fewer basics rules than there are gray areas which require guidance.  Gray areas abound which makes process selection and tailoring more than a simple trip to the mall to try and shoes on. Before addressing process (requirements or any other process) spend time building a culture map.  A culture map is a wonderful tool for planning organizational change, communication and for process selection.  Finally, recognize that most change agents go through several iterations before success. A second process issue, albeit similar, is the failure to recognize that not all business problems can be addressed by a single method. One size certainly does not fit all. As an example, one of my favorite techniques to investigate requirements is the use of brainstorming and affinity grouping sessions.  Both are powerful techniques to drive out information and group data. The technique works best for relatively small, semi-homogeneous groups (also some cultures better than others).  They have issues when you are dealing with an auditorium full of people or where groups have very different views of the world.  Techniques such as interviews, focus groups, and surveys might be more appropriate these types of situations.  One word of caution, even when you have a palette of techniques to apply as the requirements process just because a process works once does not mean it will work again.  People and culture change and time go by.  I once watched a site manager rip handfuls of little yellow sticky notes off of a conference room wall.  He was frustrated that ideas were being grouped differently than he saw them in his mind.  In retrospect interviews would have been better in that environment even though a week before the same environment (on a different less emotionally charged topic).  The past is an imperfect predictor of tomorrow.  You must have multiple processes and an understanding of when to use and not use each.   One reason requirements are so hard to get right is that the improvement is not as simple as just getting ‘a’ process. While it might be heresy, just getting the wrong process might be worse than none at all. The correct process is one that matches the organization’s culture and the business problem, now