Skip to main content

Posts

Showing posts with the label Metrics

Happy New Year! What will you do with 8,760 hours?

Time is something that puzzles me... I tend to "spend" a lot of time thinking about TIME. I don't truly know how to not "spend" time... if you find a good TIME-Bank, with a savings plan... let me know, please. I quickly calculated how much I will spend this year - 8,760 hours.  A few years ago I had a unique opportunity to spend about 8,772 hours while most of you only had the standard year - I spent New Years in New Zealand and got some extra... I think I spent it on the plane flight back to Dallas. Here's a great talk about how we use our time and what we may wish to consider doing with the very very little "free" time we have. The Time You Have (in JellyBeans)

Applying Little's fLaw to Software Development

Concept of Product Development Flow "I believe that the dominant paradigm for managing product development is fundamentally wrong.  Not just a little wrong, but wrong to its very core.  It is as wrong as we were in manufacturing, before the Japanese unlocked the secret of lean manufacturing.  I believe that a  new paradigm is emerging, one that challenges the current orthodoxy of product development."  -- Donald Reinertsen Reinertsen goes beyond the advance ideas of lean manufacturing, what he calls Flow-Based Product Development. Scrum was sparked by a paper called The New New Product Development Game by  Hirotaka Takeuchi and Ikujiro Nonaka (1986).  Are you seeing a synergy of ideas? Lean principle of Flow In the manufacturing world Toyota exemplifies the achievements one may obtain in 50 years of practicing a new mindset of principles.  Manufacturing deals with repetitive tasks predictable processes to produce component parts, hom...

Exploiting Variability: A Principle of Product Development Flow

What do these phrase have in common - what is their inherent consistent meaning? Zero Defects Take the time to do it Right Repeatability and Reliability Process Maturity Model Measure twice, cut once Six Sigma Rework is Waste, Lean processes remove Waste They are ironically consistent in their purpose to reduce variability.  Don Reinertsen will attempt to convince us that in the domain of product development (unlike other domains) variability may not be the enemy of good.  He will argue that it is the economic payoff-function of this outcome that is of upmost concern in design. Voltaire 's aphorism :   Perfect is the enemy of good. I'm in a group at work that is reading books on Agile software development topics to what purpose... well to learn I hope.  After Lyssa's book on Coaching Agile Teams  we turned the knob up to 11 with Don Reinertsen's Principles of Product Development Flow .  Since it's such a tough read, a dense book with so m...

Dash off a Fiver to the ACLU

What can you do to save the world with an Amazon Dash Button? Has a new era of enablement reached the hockey stick curve of exponential growth?  I think it has.  I've been picking up this vibe, and I may not be the first to sense things around me.  I've got some feedback that I very poor at it in the personal sphere.  However, on a larger scale, on an abstract level, in the field of tech phenomena I've got a bit of a streak going.  Mind you I'm not rich on a Zuckerberg level... and my general problem is actualizing the idea as apposed to just having the brilliant idea - or recognizing the opportunity. A colleague told me I would like this tinker's Dash Button  hack.  It uses the little hardware IoT button Amazon built to sell more laundry soap - a bit of imaginative thinking outside of the supply chain problem domain and a few hours of coding.  Repurposing the giant AWS Cloud Mainframe, that the Matrix Architect has designed to enslave y...

Big Data for Little Problems

Big Data for Little Problems -OR- What happens when the customer has better data about the service than the provider and has better networking, better press coverage, better clout, better market reach and reputations? (Feb 23) My good looking wife just spent 2 hours trying to straighten out Frontier's billing machine... it's not easy.  The amazing thing I observed for my recliner while sipping an adult beverage was her influencing techniques.  Now another amazingly disconsernation ( not a word ) is that Frontier has some awesome support people.  But oh-my-god do they have a tough job.  It's the system that has failed.  And they have to figure out how to make some legacy piece-of-crap work. But it's not going to lead to happy satisfied customers (testify). Her father, Jim, moved into the home with us in December, he loves Western movies, and is an encyclopedia of knowledge better than IMDB.  So we called up Frontier (our FiOS provider for 6 years) ...

Mean Time between Disruptions (MTD) a leadership Metric

A rant on Metric's I wish I had written...  so I'm going to just include it by reference and call it my own. One thousand Words on Metrics Here's a quote to get you even more interested in clicking that link... Conclusion In short, I find most grasping for metrics to be a reliable metric for lack of understanding of human behavior, not only that of those who would be measured but that of those who would do the measuring. If a higher-up wants a metric about a team, say, as an input to their judgment about whether the team’s work is satisfactory, oughtn’t there be some other way to tell? And if I choose nearly any metric on someone else’s behalf, doesn’t that reveal my assumption that I know something about how they do their good work better than they do? Or worse, that I prefer they nail the metric than do something as loose and floppy as “good work”?  Well - will you look at that!  Yareev's even willing to apply his own metric to his work.  What a ...

Cycle Time and Lead Time

Our organization is starting to talk about measuring Cycle Time and Lead Time on our software engineering stories.  It's just an observation, but few people seem to understand these measurement concepts, but everyone is talking about them.  This is a bad omen...  wish I could help illustrate these terms.  Because I doubt the measurements will be very accurate if the community doesn't understand when to start the clock, and just as important - when to stop it. [For the nature of confusion around this terms compare and contrast these:   Agile Alliance Glossary ; Six Sigma ; KanbanTool.com ; Lean Glossary .] The team I'm working with had a toy basket ball goal over their Scrum board...  like many cheep toys the rim broke.  Someone bought a superior mini goal, it's a nice heavy quarter inch plastic board with a spring loaded rim - not a cheep toy.  The team used "Command Strips" to mount it but they didn't hold for long. The team convinced me th...

A look at Six Years of Blogging Stats

What do you get from six years of blogging about Agile/Scrum and your continued learning experiences? Stats from Agile Complexification Inverter blog site Well the stats are just one insignificant measure of what one gets from writing about their experience. The more meaningful measures have been seeing some of these articles and resources put into practice by other colleagues, discussion that have happened (off line & sometimes in comments or twitter, etc.) with readers that require me to refine my thinking and messaging of my thinking.  Interestingly some times seeing a resource that you have created being "borrowed" and used in another persons or companies artifact without attribution is both rewarding and a bit infuriating.  I like that the concept has resonated well with someone else and they have gone to the trouble of borrowing the concept, and repeating or improving or repurposing the concept. Let me borrow someone else's concept:  "The Ba...

Team Metrics - Case Study

Let's look at an info-graphic of a beginning team's metrics and use this as a case study in Scrum Team Metrics. Description of charts: Burndown chart - a daily count of the number of task units (aspirin is this teams selected units for task estimation) not done.  This includes the task yet to be started, and task in process. Tasks in Process - a daily count of the number of tasks in process. Tasks Done - a daily count of the number of tasks that are done. Stories Done - a daily count of the number of Stories that are done. Velocity - the empirical measure of Stories that are considered done by the team and accepted as done by the Product Owner during the Sprint Review. The Back Story on this team: This team had been attempting to do some form of ad-hoc Scrum / Kanban with little guidance and understanding of the process.  The Kanban aspect came from the company's tooling (RTC) template - not from any real practices the team was implementing.   After som...

How could we measure Team Happiness?

Do you believe that what you measure you will get?  If so you want to start to measure team happiness.  So what techniques do we have to measure something so ephemeral? This TED Talk by Dominic Price lays out a simple and insightful guide to assess your happiness. The health care industry has studied measuring pain and have very good data on their ability to measure and administer pain drugs upon a subjective self report.  Maybe we could do the same in knowledge worker teams and work groups. Team Happiness Net Promoter Score sheet Here's a riff upon the classic Net Promoter Score for measuring team happiness.   "How likely is it that you would recommend our team to a trusted friend that is looking for a job?" To calculate the NPS - the continuum is divided into 3 groups; the detractors (1 - 6), the passive (7 & 8), the promoters (9 & 10).  The passive are ignored - they do not promote your objective.  The NET promoter score is the pe...

Velocity Calculus

Velocity Calculus  -- by David A. Koontz In the practice of Scrum many people appear to have their favorite method of calculating the team's velocity.  For many this exercise appears very academic.  Yet when you get three people and ask them you will invariability get more answers than you have belly-buttons.  That in its self is an interesting phenomenon, worthy of a blog post.  But this is not it. Calculus is the mathematical study of change. This video is a photo journal simulation describing how to calculate a Scrum sprint velocity.  It explains the calculus for one of the most difficult decision a team faces.  What to do with that first unfinished story.

Relative Points explained

Are your teams having difficulty understanding the relative nature of story points?  Try an analogy ... maybe one that is already well know... yet so often used that they have forgotten just how easy it is to use relative measures.  I'll bet they use it every day, multiple times per day.  That kind of practice makes usage very easy.  That is how easy story points will become for a team that practices. Here's your analogy - in less than 10 seconds.  But you might need to repeat it about 14 times... YouTube channel:  Minute Physics Don't mistake preception of temperature and the measurement of temperature.... see Derek's Veritasum experiment: Misconception About Temperature . Now... relate the misconception about temperature back to the topic of relative points...

Metrics for a Scrum Team (examples)

What metrics do you collect to  analyze  your scrum team? It's the Trends of Metrics that matter. We live in a world of data and information.  Some people have a mindset that numbers will diagnose all problems – “just show me the data.”  Therefore many directors and senior managers wish to see some list of metrics that should indicate the productivity and efficiency of the Scrum team.  I personally believe this is something that can be felt, that human intuition is much better in this decision realm than the data that can be collected.  However, one would have to actually spend time and carefully observe the team in action to get this powerful connection to the energy in a high-performing team space.  Few leaders are willing to take this time, they delegate this information synthesis task to managers via the typical report/dashboard request.  Therefore we are asked to collect data, to condense this data into information, all while ignorin...