Process, People, and Pods


Sunday 2 September 2007

...And How Are You Going to USE That Information?

I cited in my last post a case where Counting Wasted Time. I ended by giving my favorite response when someone is asking to collect data about the project:

...And how will you use that information?

Don't get me wrong. I really want a great answer to that question. I seek metrics that help understand the project. To paraphrase the NRA:

Metrics don't kill projects; people do.

But I digress. Some additional examples of useless information gathering will help you see the importance of the question, "And how will you use that information?"

Example 1: Revised Estimates

In a recent fixed price project, we dutifully re-estimated stories at the start of an iteration. We had release level estimates with which we did our original planning. The iteration estimates were supposed to set our "commitment" level for the iteration; they were supposed to set client expectations.

We over-delivered by 100%. We repeated the exercise, and over-delivered again. So on the third cycle, we asked the question, "How did we use the estimates we made?" The team, including the project manager, acknowledged that we hadn't looked at them since we collected the numbers. So we dropped them.

(BTW as I cited in yesterday's post about Counting, I have rarely found use in resizing just in case things have changed.)

Example 2: Defect Tracking Database

We haven't tracked bugs in the last three development projects I have participated in. How can this be?

One of the key Lean practices is feedback; feedback is most effective when rapidly given. This leads to a positive metric of story cycle time, a measure of the time from the start of analysis until story acceptance by the customer. So if a bug blocks a story, then the clock is running on that story until it is fixed and moves forward. Developers on a Lean-oriented team will attack bugs rather then work on development of new stories. The net results is few bugs live for more than a day. In tracking a recent project, over half the days were finished with zero open bugs.

Instead, we post the bug's existence on a red task card on our standard card wall. When it is fixed and verified, we take the card down. I would like to say that we throw the card away, but we still like to put them into a stack and admire them (for some reason). I do have to admit to a certain curiosity myself. But in the last couple of projects, I have yet to see anyone looking back at those cards!

There are great bug tracking tools out in the market. Many IT shops have standardized on one, and have process guidelines requiring their use. An Agile/Lean project shouldn't need any of them.

[In a bit of cruel fate for a vendor, I was recently asked to give a statement on a recently announced bug tracking tool that purports to solving all your tracking needs; indeed, it is the next generation of tracking tools, rendering all other obsolete. Needless to say, I commented that it was a solution in search of a problem as far as I was concerned. If you need that level of sophistication, your project is going to fail anyway.]

Bad Reasons to Collect Information

There are two reasons for collecting metrics that are, in fact, good reasons not to collect metrics:

Because I might need them: I consider this a euphemism for "I don't know." I lump into this same category, "We always do it this way" and "We have to". In the case of "I don't know", we drop the counting for an iteration or so, and see if we miss it. It is always hard to argue against a short-term experiment. In the case of "we always do it this way", start the discussion to drill down and figure out why we did it that way originally, and see if the reason still exists (especially if you have introduced Agile and/or Lean practices). This is just good development practice, but in particular is a good Lean practice. In the case of "we have to", it is time to engage the process architects and gauge if this is a battle worth fighting. I tend to relish that idea having done the process role in IBM many, many years ago, but we won't discuss my personality defects here. Regardless, the tactic is the same: Find out what it was useful for and see if the need still exists.

I need to understand how well everyone is doing. Translation: "I need to pin the blame on someone when things go wrong." Now you have hit a hot-button of mine. Blame is not a way to run a team. Blame creates fear, and fear kills motivation and productivity. And kills fun! Agile teams, especially collocated Agile teams, have many positive ways to address inhibitors to productivity. This includes many ways of addressing skill deficiencies which will always exist in software projects because of the wicked pace of change. So if someone attempts to collect information for the primary purpose of assigning blame, well, let's just say they have to get past me first.

There Are Good Metrics

Less I have led you astray (and you will use these posts to justify collecting no information), there are many good uses of collected information. I will cite my favorite Agile/Lean project metrics in a future post.

But for now, do you have examples of gathering useless information?

204 comments:

«Oldest   ‹Older   201 – 204 of 204
梁爵 said...

台北市昨新增一百例本土確診,主要仍集中於八大行業酒店打工及校園,其中包括兩起酒店上班KTV群聚案,累計廿六人染疫,而多處行政區內的國小及幼兒園也再傳疫情,共增十二例確診、五校的班級停課;市長柯文哲昨於防疫記者會上表示,此波疫情不容樂觀,防疫也比想像中困難,國民要有心理準備,評估疫情持續延燒兩個月後將達頂峰。8學生確診 再增5校班級停課北市副市長黃珊珊指出,昨日北市新增一百例本土確診中,有廿四例屬於「陰轉陽」,另有兩起分別位於信義區與中山區的酒店公關KTV群聚案,已累計廿六人染疫;校園方面,信義、大安、內湖區再有八名國小學生確診,中山區某幼兒園則增四例,昨再添五校的班級停課。
七大類場所酒店經紀消費者須打3劑疫苗黃珊珊說,針對酒店工作KTV外的舞廳、舞場、坐檯小姐、酒家酒店上班、特種咖啡茶室、夜店、三溫暖等七大類場所展開嚴格稽查,相關酒店應徵工作人員須接種三劑疫苗、四月卅日前每週加做快篩,消費者則須提供接種三劑疫苗證明才可入內消費,若業者酒店小姐違反防疫規定,每次罰款從三千元至一.五萬元不等,超過四次則連續開罰一.五萬元,而北市府自上週五開始針對七大類場所稽查五十五次,目前查無違規。
柯:若未來單日確診人數超過130例 染疫者須留置家中
柯文哲則再度重申,台灣已打開邊境,要做到清零便已不可能,須研究如何以最低社會成本與病毒共存,因此北市自四月起便鼓勵居家隔離者在家隔離,並將加強版酒店上班防疫專責旅館擴增至一千三百床用以收治確診者,但若未來單日確診人數超過一百卅例,則確診者就須留置家中。
柯文哲說明,北市加強版防疫專責旅館配有醫護、血氧機、監視器,若每日新增確診數在一百卅例以下,則能提供較佳照護效率,但病例若太多,則須留置在家,而北市也採取遠端視訊醫療做為配套作法,自今年一月一日起至四月五日已服務八百廿九人次,本週將全面建置網路虛擬醫院系統,加速規劃在家照護。黃珊珊補充,居家檢疫、居家隔離、甚至日後確診留在家中的民眾,可能有人有慢性病用藥需求,經與台北市藥師公會討論後,會與中央請求延長健保卡過卡時間,使民眾能事後補過卡,解決送藥問題。北市疫苗系統開放預約 18至24日接種
此外,確診人數增加,疫苗打氣也隨之提升;副市長蔡炳坤指出,六十五歲以上長輩接種疫苗可獲一千元禮券的優惠措施可見成效,上路以來約催出一萬多人前來接種,另,今起北市疫苗系統開放預約四月十八至廿四日的疫苗接種,此次約提供近九萬劑量能,鼓勵市民多加利用。
柯文哲再強調,此波疫情不容樂觀,因應防疫也比想像中的困難,儘管盡可能透過疫調封鎖、控制,但病毒已進入社區,確診案例必會持續上升,若借鏡鄰近國家疫情發展態勢,預計台灣將在兩個月後達到疫情頂峰,呼籲民眾以審慎態度、放鬆心情做好防疫工作。

Anonymous said...

GRL 届くまで
車金融 車担保融資

Anonymous said...

メンズファッションの通販サイトを探す方法。メンズファッションの通販サイトについて、実際に利用した人の口コミや評価が掲載されている口コミサイトを利用することもできます。
安い メンズ通販サイト
おすすめメンズ通販サイト
自分に合ったメンズファッションの通販サイトを見つけることができます。

Anonymous said...

レディースのプチプラファッションの人気の高いネットショップは、以下のようなものがあります。
GRL 届くまで
プチプラでありながらもデザイン性や品質に優れたものが多数あり、手軽にファッションを楽しめる点が人気の秘密です。

新貸金業規正法に適応した車金融業者
「乗ったまま融資」は、質屋とは違って車を乗り続ける事ができます。
車金融 車担保融資は、「乗用車・商用車・トラック・バイク等を担保に金銭の貸付を行う業者」文字通り車を担保として融資を受けることが出来る融資方法です。

«Oldest ‹Older   201 – 204 of 204   Newer› Newest»