Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

SPaMCAST 466 features our interview with Ross Smith.  Ross and I discussed legacy application modernization.  Legacy application modernization delivers quantitative and qualitative value to organizations. Modernization can breath new life into old applications.  We also discussed why organizations sometimes avoid biting the modernization bullet!

Ross Smith is Chief Architect at PITSS America.  He has been on the PITSS team for five years, a time during which the company transformed from an Oracle Forms upgrade vendor into a business process and application transformation provider.  He recently spoke at Oracle Open World about the untapped potential of leaving vital legacy applications out of a digital transformation strategy, and the realities of integrating them into a modern enterprise environment.

Email: rsmith@pitss.com
Web: https://pitss.com/
Linkedin: https://www.linkedin.com/in/ross-smith-5427497

I am participating in the Agile Online Summit
30 Oct – 3 Nov 2017
At the summit, I talk about the power of storytelling with Tom Henricksen!
Register

Metricas 2017
I will be keynoting on Agile leadership and delivering one my favorites, Function Points and Pokémon Go
29 November 2017
Sao Paulo, Brazil
Register

Re-Read Saturday News

This week we re-read Chapter 2 of Actionable Agile Metrics for Predictability: An Introduction by Daniel S. Vacanti. Chapter 2 is titled The Basic Metrics of Flow. We go deep on WIP, Cycle TIme and Throughput.  Powerful metrics that every team needs to understand and leverage.  Buy your copy today and read along!

Previous Installments

Introduction and Game Plan

Week 2: Flow, Flow Metrics, and Predictability

Week 3: THe Basics of Flow Metrics (more…)

Advertisements

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

SPaMCAST 445 features the return of a favorite, Capers Jones.  It is always fun to talk with someone with their own page in Wikepedia.  Capers and I talked about his new book, A Guide to Selecting Software Measures and Metrics. Capers is passionate about software quality and measurement. Capers said, “High-quality software is not expensive. High-quality software is faster and cheaper to build and maintain than low-quality software, from initial development all the way through total cost of ownership.” from The Economics of Software Quality.  As usual, Capers was engaging, educational and controversial.  Spending time with Capers is always a learning experience!

Capers biography is long and storied.  Let it be said that Capers is a serial author, public speaker, pundit, guru and deep thinker.  Check out his Wikipedia page or Linkedin.

Capers can be contacted at capers.jones3@gmail.com.

Capers first appeared on SPaMCAST 3 and  last appeared on SPaMCAST 53

Re-Read Saturday News

This week we tackle Chapter 7 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015.  Chapter 7 shows how to generate alignment between roles, circles, and the overall organization.  Lots of inspect and adapt talk this week.

Catch up on the first four entries in the re-read

Week 1:  Logistics and Introduction

Week 2: Evolving Organization

Week 3: Distribution Authority

Week 4: Organizational Structure

Week 5: Governance

Week 6: Operations

Week 7: Facilitating Governance

Week 8: Strategy and Dynamic Control

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

 

A Call To Action

If you got a new idea this week while listening to the podcast, please give the SPaMCAST a short, honest review in iTunes, Stitcher or wherever you are listening.  If you leave a review please send a copy to spamcastinfo@gmail.com.  Reviews help guide people to the cast!

Next SPaMCAST

SPaMCAST 446 will feature our essay on questions.  Questions are a coach and facilitator’s secret power!   Do you have a favorite go to question you like to ask?  Care to share?

We will also have columns from Gene Hughson and Jon Quigley (and maybe more)!

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

 

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play MusicListen Now

The Software Process and Measurement Cast 438 features our essay on leveraging sizing in testing. Size can be a useful tool for budgeting and planning both at the portfolio level and the team level.

Gene Hughson brings his Form Follows Function Blog to the cast this week to discuss his recent blog entry titled, Organizations as Systems and Innovation. One of the highlights of the conversation is whether emergence is a primary factor driving change in a complex system.

Our third column is from the Software Sensei, Kim Pries.  Kim discusses why blindly accepting canned solutions does not negate the need for active troubleshooting of for problems in software development.

Re-Read Saturday News

This week, we tackle chapter 1 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015. Chapter 1 is titled, Evolving Organization.  Holacracy is an approach to address shortcomings that have appeared as organizations evolve. Holacracy is not a silver bullet, but rather provides a stable platform for identifying and addressing problems efficiently.

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

Next SPaMCAST

The next Software Process and Measurement Cast will feature our interview with Alex Yakyma.  Our discussion focused on the industry’s broken mindset that prevents it from being Lean and Agile.  A powerful and possibly controversial interview.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

Listen Now

Subscribe on iTunes

This week’s Software Process and Measurement Cast features three columns.  The first our essay on Reviews and Inspections.  Reviews and inspections are a critical tool for improving quality and team effectiveness. Whether you are using Agile or classic techniques improving your reviews and inspections will directly increase the value you deliver.

We also have a new entry in the QA Corner with Jeremy Berriault.  Jeremy and I discussed the value of independent QA.

Anchoring the cast is a new installment from the Software Sensei, Kim Pries. Kim contrasts planned activities and improvisation in software development.  Kim builds on the differences in the two approaches to help teams to understand when to do either.

Call to Action!

For the remainder of September let’s try something a little different.  Forget about iTunes reviews and tell a friend or a coworker about the Software Process and Measurement Cast. Let’s use word of mouth will help grow the audience for the podcast.  After all the SPaMCAST provides you with value, why keep it yourself?!

Re-Read Saturday News

Remember that the Re-Read Saturday of The Mythical Man-Month is in full swing.  This week we tackle the essay titled “The Documentary Hypothesis”! Check out the new installment at Software Process and Measurement Blog.

Upcoming Events

Software Quality and Test Management
September 13 – 18, 2015
San Diego, California
http://qualitymanagementconference.com/

I will be speaking on the impact of cognitive biases on teams.  Let me know if you are attending! If you are still deciding on attending let me know because I have a discount code.

Agile Development Conference East
November 8-13, 2015
Orlando, Florida
http://adceast.techwell.com/

I will be speaking on November 12th on the topic of Agile Risk. Let me know if you are going and we will have a SPaMCAST Meetup.

More conferences next week including Agile DC and Agile Philly!

Next SPaMCAST

The next Software Process and Measurement Cast will feature interview with Steve Boronski. Steve and I had a great conversation about Agile and Prince2. The conversation focused on the new Prince2 Agile Project Management Best Practice extension to Prince2 and why the world needs another interpretation of Agile project management.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

Listen Now

Subscribe on iTunes

Software Process and Measurement Cast 350 features our interview with Arlene Minkiewicz. Arlene and I talked technical debt.  Our discussion included the definition of technical debt, a set of philosophies for technical debt and perhaps a few solutions. Regardless of philosophy or approach, a little technical debt goes a long way!

Arlene F. Minkiewicz is the Chief Scientist at PRICE Systems, LLC with over 30 years of experience at PRICE building cost models.  She leads the cost research activity for TruePlanning, the suite of cost estimating products that PRICE provides.  She is a software measurement expert dedicated to finding creative solutions focused on helping make software development professionals successful.  She is widely published and speaks frequently on software related topics.  She has a BS in Electrical Engineering from Lehigh University and an MS in Computer Science from Drexel University.

Email: Arlene.Minkiewicz@PRICESystems.com
Twiitter: @arlenemink
Website:  www.pricesystems.com

Call to Action!

I have a challenge for the Software Process and Measurement Cast listeners for the next few weeks. I would like you to find one person that you think would like the podcast and introduce them to the cast. This might mean sending them the URL or teaching them how to download podcasts. If you like the podcast and think it is valuable they will be thankful to you for introducing them to the Software Process and Measurement Cast. Thank you in advance!

Re-Read Saturday News

We have just begun the Re-Read Saturday of The Mythical Man-Month (buy it here to support the blog and podcast). We are off to rousing start beginning with the Tar Pit. Get a copy now and start reading!

The Re-Read Saturday and other great articles can be found on the Software Process and Measurement Blog.

Remember: We just completed the Re-Read Saturday of Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement which began on February 21nd. What did you think?  Did the re-read cause you to read The Goal for a refresher? Visit the Software Process and Measurement Blog and review the whole re-read.

Note: If you don’t have a copy of the book, buy one. If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

Upcoming Events

Software Quality and Test Management 

September 13 – 18, 2015

San Diego, California

http://qualitymanagementconference.com/

I will be speaking on the impact of cognitive biases on teams!  Let me know if you are attending!

 

More on other great conferences soon!

Next SPaMCast

The next Software Process and Measurement Cast will feature our essay on distributed Agile. Distributed Agile is not just Scrum and other Agile techniques over a distance.  As distribution and cultural diversity increase what worked for a co-located team will often fall short.  We will identify solutions next week!

 

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

176

While I was attending a recent conference I heard the term framework used at least five times in five different contexts in the span of one morning.  Software development frameworks are a scaffold for developing, maintaining and enhancing software. Values and principles help shape the framework so that specific types of techniques and practices fit into the scaffold.

All major buildings begin with scaffold into which all sorts of things like windows, rooms and the façade are added.  The scaffold will only hold the parts it has been constructed to hold.  Just think of tacking the façade or windows of the MOMA in New York onto the Chrysler Building.  The result of that mess would not be fit for use.  The scaffold of the building was influenced by the values and principles that the architects chose to express in their creative vision.  Software development frameworks have the same architecture; a scaffold shaped by values and principles. For example, Scrum is a framework that is molded by the principles and values set forth in the Agile Manifesto. The CMMI© is also a framework.  Goals which embody values and principles govern each process area in the framework.

There are numerous frameworks to develop, maintain and enhance software. A framework provides a structure for software developers to create or maintain software using a set practices and techniques that fit into the framework. A framework provides a blueprint to guide you you while building software. The techniques and practices you use to fill in the scaffold define how you will build.

Manufacturing, Engineering or Craft?
By Thomas M. Cagley Jr
Audio Version in SPaMCAST 181

A few weeks ago I sat next to a gentlemen on a flight to Albuquerque. After talking through a couple of glasses of wine we found we were in related fields. As the conversation progressed he confided in me that he did not understand why software projects were never on time, never on budget or never exactly what he wanted — since software development was engineering and he’d been told by his consultants that development was like a factory. I paid for the next round of wine as I tried to persuade my new friend that building, enhancing or maintaining software was not really like assembling a car.

Why has the manufacturing model as a metaphor and therefore the ideas of Fredrick Taylor been so firmly entrenched in IT? In reality, is IT a creative model (science or craftsman) or a manufacturing model (assembly line) more accurate in describing the behavior required to deliver value from development? Which metaphor is more predicative? If we introduce the term software engineering, does the use of the word, engineer complicate how IT personnel are perceived? Does the perception create a set of expected behaviors for software development and maintenance personnel that makes it harder to deliver value than it needs to be?

I have been always hard-pressed to buy the factory / manufacturing mode. I have worked on an assembly line. One of the jobs I had was building tires for Firestone Tire and Rubber Company at their plant in Memphis. That job was one of the reasons I made sure I went to University. Building tires is interesting from an engineering point of view. Tires are built shaped like a barrel with sheets of rubber and other components layered on each other, based on a specific design or recipe. In the end, the recipe metaphor might be the most appropriate as in the end they cooked and molded into the shape we know. Every specific type of tire follows the same set of steps. Any thoughts of creativity in the process are erased by the second tire you “make.” How can the metaphor of manufacturing model be used in software development, maintenance or enhancements where creativity and art are needed to deliver a solution?

One of my hobbies is craft brewing beer. Craft brewing starts with a recipe that specifies the amount of grains and hops to be used, approximate boiling times and a schedule for adding the hops as the process progresses to which is added elbow grease. As all brewers know, going from being a novice to something more, they begin to modify and tailor their recipes to meet their individual tastes. While operating within the basic recipe and laws of both chemistry and biology (brewing is cool), the brewer acts as a craftsman rather than a simple cook or assembly line worker.

I would suggest that a better analogy for software development is a scientific or engineering craftsman which mirrors my experience in craft brewing.

Words and names are important because they frame the questions that will be addressed. An engineering project begins with an idea, just like any other project. From the idea requirements are created and followed by the transformation of those requirements into something of value based on the physical laws and material tolerances. Projects following an engineering pattern include building a bridge or building a computer. The outcome of these types are predictable (assuming no major mistakes). When you build a house you generally pay a fixed price based on a fixed set of requirement. A builder is expected to answer, with high precision, the questions of how much the house will cost, when it will be completed, and when it will be delivered. When dealing with a craft or art, the answers to those questions are generally much fuzzier. While an artist might give you a fixed price for a portrait of your family the true cost, margin, and delivery date are far less predictable if for no other reason than the interplay between human, tools, and suppliers is more chaotic. Computers do not create great art . . .humans do.

So why does this discussion matter? Hasn’t this been debated many times over the years? Why does the model you leverage to describe IT matter? It matters because it sets expectations. If we use the manufacturing model why shouldn’t we expect to provide firm fixed prices? In manufacturing we should know when we can deliver the product. We should understand all the requirements from beginning of a project. In many cases the exception would be that we are delivering a product that we put on the shelf or that we assemble from known parts. This might be true if we were buying a vanilla commercial-off-the shelf product like Microsoft Office or SAP. If using an engineering metaphor, our processes will be based on the physical laws of nature and/or material science to describe how things are to be built. Examples include building a computer or standing up a set of servers. At its base, engineering is deterministic (x + y = z . . . every time). If developing or maintaining software were an art we would have very different expectations on whether we could predict the future (cost, quality, and delivery). A creative process that actually is far more chaotic and less deterministic.

Reality suggests that developing systems, enhancing systems, and maintaining systems are human dominated activities which are less than perfectly deterministic; therefore, they have at least some “craft” involved. I’m not suggesting that software development, enhancements or maintenance are art but rather a combination of science, engineering and craftsmanship.