SPaMCAST 481 – User Story Hierarchy, Extended Backus-Naur, QAs on the Loose

http://www.spamcast.net

Listen Now
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

SPaMCAST 481 will feature our essay on the Life Cycle of A User Story.  A user story – a brief, simple requirement statement from the user’s perspective – tends to follow a loose life cycle.  That life often begins even before the word ‘user story’ gets mentioned and typically by people that don’t understand (or care to understand) the concept of a user story. We zoom in from 40,000 ft down to user stories in 500 or so words!  

Read other entries on user stories by following this link: https://tcagley.wordpress.com/?s=user+story

The second column this week is from Kim Pries, the Software Sensei, Kim discusses using the Extended Backus-Naur Form as a tool to extract information out of nebulous text.

Last but not least, Jeremy Berriault brings his QA Corner to the cast.  In this entry, Jeremy discusses why QAs/testers should be given space to manage their own workflow. Jeremy has recently moved the QA Corner to https://qacorner.blog/

Re-Read Saturday News

 

Uncertainty: A Few Basics

No Uncertainty Here!

Uncertainty has a significant impact on both the business and engineering of software development (in all of its myriad forms).  Wikipedia provides an operational definition of ‘uncertainty’ as, “a situation which involves imperfect and unknown information.” Defining and understanding uncertainty is important because it is a common condition across the entirety of the software development life cycle.  The big BUT that follows the statement that uncertainty is common is that it is often unremarked or ignored, which are rarely useful responses.  Recognizing the uncertainty in any scenario is useful in selling ideas, planning, motivation and in development.  Over the course of the next several articles we will explore uncertainty across the life cycle; however, we begin with some of the sources of uncertainty and why it matters.

There are typically four macro sources of uncertainty:

 

SPaMCAST 432- Leadership Types, On-Boarding, Surprises in QA, Holy Trinity

http://www.spamcast.net

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

The Software Process and Measurement Cast 432 begins with an essay on the impact of leadership types on adopting and sustaining Agile.  Leadership style has a direct impact on an organization’s ability to adopt and sustain Agile.  Some leadership styles are more supportive, while others evoke more of a response that is epitomized by locking feral cats and dogs in a room (nobody wins).

Next up, Jeremy Berriault brings his QA Corner to the cast to discuss surprises in QA testing.  Visit Jeremy’s blog at https://jberria.wordpress.com/  Next we will have a column from The Software Sensei, Kim Pries.  Kim discusses the holy trinity of forethought, execution and follow through. Reach out to Kim on LinkedIn. Last, but not least, Jon M Quigley brings his column, the Alpha and Omega of Product Development, to the Cast. In this segment, Jon discusses on-boarding. On-boarding new people is critical even if the person is just joining from another team down the hall.  One of the places you can find Jon is at Value Transformation LLC.

Re-Read Saturday News

This week  we tackle Chapter 5 in Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along).  In Chapter 5, Dweck uses examples from the business world to illustrate and elaborate on fixed and growth mindsets.

Every week we discuss a chapter then consider the implications of what we have “read” from the point of view of someone pursuing an organizational transformation and also how to use the material when coaching teams.  

 

Efficiency

Efficiency a measure of how much wasted effort there is in a process or system. A high efficiency process has less waste. In mechanical terms the simplest definition of efficiency is the ratio of the amount of energy used compared to the amount of work done to create an output. When applied to IT projects, efficiency measures how staffing levels effect how much work can be done. The problem is that while a simple concept, it is difficult because it requires a systems-thinking view of software development processes.  As a result it is difficult to measure directly.

 

Some Moral Hazards In Software Development

Too big to fail?

Moral hazards occur when the potential outcome of taking a risk is disassociated from who will bear the cost of a risk.  Moral hazard is often caused by information asymmetry; the risk taker has more information than the person or organization that will bear the cost of a risk. Even though we assume in many cases perfect information or harp on the need for communication, information asymmetry is a common occurrence. Too big to fail is a form of moral hazard in which the organization may take larger risks with the potential the larger returns because they know they will not be allowed to fail.

 

SPaMCAST 381 – Agile Adoption vs Transformation, Myths of Greenfield Development, Gender Gap in Computer Science

http://www.spamcast.net

Listen Now

Subscribe on iTunes

Software Process and Measurement Cast 381 features our essay on Agile adoption.  Words are important. They can rally people to your banner or create barriers. Every word communicates information and intent. There has been a significant amount of energy spent discussing whether the phrase ‘Agile transformation’ delivers the right message. There is a suggestion that ‘adoption’ is a better term. We shall see!

We will also have an entry from Gene Hughson’s Form Follows Function Blog. Gene will discuss his blog entry, Seductive Myths of Greenfield Development. Gene wrote “How often do we, or those around us, long for a chance to do things “from scratch”. The idea being, without the constraints of “legacy” code, we could do things “right”. While it’s a nice idea, it has no basis in reality.” The discussion built from there!

And a visit from the Software Sensei, Kim Pries!  In the essay, Kim ruminates on the gender gap in computer science education leading to a gender gap in the industry.

 

SPaMCAST 365 – Agile Project Charters, Improvisation, Customer-Driven Development

http://www.spamcast.net

Listen Now

Subscribe on iTunes

This week’s Software Process and Measurement Cast includes three columns!  The first is our essay on Agile Project Charters.  Project charters, done correctly, can play an extremely important role in the initiation of projects. The essay lays out how Agile projects can get the benefit of a project charter, without the bloat and shelfware that often get attached to project charters.

Software process and Measurement Cast 365 also features the return of the Software Sensei with a discussion of improvisation in software development. Kim Pries writes, “Many people think improvising means making things up, on the spot, without any advance preparation. I prefer a different definition: creating something special from whatever ordinary ingredients happen to be available. I would suggest we can go beyond this definition—good improvisation is a sign of mastery of one’s craft. Furthermore, truly great improvisation always involves ensembles (i.e., leave your ego at the door).” A powerful and important essay for anyone interested in delivering software.

Finally, Gene Hughson brings a new installment from his Form Follows Function blog to the Software Process and Measurement Cast with a discussion of his entry titled, “Maybe It’s Time for Customer-Driven Development.” Gene reminds us that the point of all work is pleasing a customer. That is a reminder that we all need to hear over and over and over to ensure it sticks!

Call to Action!

Review the SPaMCAST on iTunes, Stitcher or your favorite podcatcher/player and then share the review! Help your friends find the Software Process and Measurement Cast. After all, friends help friends find great podcasts!

Re-Read Saturday News

Remember that the Re-Read Saturday of The Mythical Man-Month returns this week when we tackle the essay titled “Hatching a Catastrophe!” Check out the new installment at Software Process and Measurement Blog.

 

Upcoming Events

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.

Next SPaMCAST

The next Software Process and Measurement Cast features my interview with Jeff Dalton.  Jeff returns to the Software Process and Measurement Cast to discuss the attributes of successful organizations. There are a relatively small set of attributes that successful organizations exhibit. These attribute don’t occur by accident, but rather are a reflection of hard work and consistency of purpose.  We can all reflect and adopt these attributes in our pursuit of success.

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.

 

 

SPaMCAST 355 – Agile Success Factors, Who Owns QA, Software Models

http://www.spamcast.net

Listen Now

Subscribe on iTunes

The week’s Software Process and Measurement Cast features three columns.  The first is our essay on Agile Success Factors.  We recently surveyed a group of people actively involved in the software development field.  In the essay we discuss the top ten (factors involved in successfully using Agile.

This cast also includes a new entry in Jeremy Berriault’s QA Corner.  Jeremy discussed the sticky topics of who owns QA (testing) and who owns quality. Jeremy’s take on ownership of testing and quality is thought provoking.  After listening we would like your take on the topic.

In the third column, Kim Pries brings his popular Software Sensei column to bear on the prototypes and frameworks in software development. Kim explores the many of the different types of models that exist and discusses when and where they can be used.

Call to Action!

It is time to start building our fall and winter interview schedule.  Who would you like us to interview or is there a topic you want to hear discussed?  Please send us an email at spamcastinfo@gmail.com.

Re-Read Saturday News

We are taking a day off this week to attend Podcamp Pittsburgh X.  We are re-visiting the first re-read we ever did which was focused on Stephen Covey’s 7 Habits of Highly Effective People.

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.

Next SPaMCAST

The next Software Process and Measurement feature our interview with Steve Turner.  Steve and I talked time management and email inbox tyranny!  As the summer winds down in the northern hemisphere, it is time to start thinking about getting in control of our time and inbox so that we can be not only more productive, but dare I say, more satisfied.

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.

 

SPaMCAST 350 – Arlene Minkiewicz, Technical Debt

http://www.spamcast.net

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 21^nd. 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.

 

Re-Read Saturday: Mythical Man-Month, Part 1

The Mythical Man-Month

The Mythical Man-Month: Essays on Software Engineering was originally published in 1975. That was the year I took my first course in programming – FORTRAN, at Memphis State University. Mythical Man-Month has been a must read for every professional involved in delivering value since it was published. The core themes in the book, which include Brook’s Law (adding people to a late project just makes it later – more in a future installment), are just as important today as they were when they were published because they still true for all types of software development and maintenance.   The Mythical Man-Month, I think on reflection you will agree, is still important because we are still trying to come to grips with most if not all of the concepts that Brooks exposed.

Here is the game plan for the Re-Read. We will be reading from Anniversary Edition of the Mythical Man-Month (Addison Wesley 1995). My copy is the 14^th printing from 2014. Part of this re-read will actually be a first read for me. I believe I originally read Man-Month in the early 1980’s, and this edition has a new preface and four new chapters. My intent during the re-read is to cover two essays/chapters per week so the re-read takes ten weeks “ish.”  Today will be the exception to the rule. We will tackle the first essay, The Tar Pit (I already used the ideas in the essay to make a point in the essay on Scrum of Scrum membership).

Preface(s):
The original preface provides background for Brooks’ perspective. Brooks came to his conclusions based on a history as a hardware architect then as the manager of the OS/360 project (IBM’s highly successful mainframe operating system). In the preface Brooks telegraphs one of his central theorems – large projects are different than small projects. It took a few years and the Agile Manifesto (2001) to recognize this fact and begin to act on it.

The anniversary edition includes a new preface in addition to the original. There were two notes in the new preface that caused me pause. The first was the observation by Brooks was that few of the central thoughts in the book had been critiqued, proven, and disproven by research and experience. I would like your feedback as we review the essays. I will explicitly point those points out during the re-read and if miss any skip ahead to Chapter 18 to keep me honest. The second point, based on my interest in the publishing industry,  from the new preface was that Brooks was able to publicly thank Addison Wesley staff that he found instrumental when preparing the first edition. The publishing world has changed. The question I pose to the Software Process and Measurement Cast blog readers is has our profession changed as much?

Chapter 1: The Tar Pit

In the Tar Pit Brooks sets the context for the system programming as a craft that is more than just the lone coder sitting in his or her office creating a stand alone app but rather a member of a team building large scale systems. The Tar Pit describes why the complexity and level of effort is different and then exposes the joy and woes of the profession.

The first takeaway from the Tar Pit is that as the product of a piece of work progresses from the delivery of a single program to programming product or system then to a programming systems product, the complexity of managing and understanding the work increases. As size and complexity increase so do tasks and activities to ensure the product works together. Brook suggests that the difference between level of effort between the creation of stand-alone program and a systems product is 9 times! The complexity of coordinating all of these additional tasks and activities while solving complex business problems impacts our ability to deliver on-time, on-budget and on-scope. At times, it also impact our ability to deliver WOW.

The second takeaway are the joys of programming.  Joys motivate programmers to put forth the effort needed to deliver value while trying to navigate the tar pit.  Brooks points out that the rewards of programming are at least four fold:

1. The joy of making things.
2. The joy of making things that are useful to others.
3. The joy of problem solving.
4. The joy of learning.

These joys are offset by several woes.  These woes are the part of the tar pit that make programming hard.

1. Expectation of perfection. Unless the code is correct and solves the requirements, it is wrong. There is little to no gray area.
2. Dependence on others. Others set your objectives, provide resources and often control the source of information. This often leads to the tension caused when individual or teams have the responsibility to deliver without commensurate authority. Agile principles, when applied to teams, are a start to addressing these woes.
3. Finding the bugs in the big picture.  Designing the big picture is significantly more fun than the tedious effort required to find bugs.
4. Dead on arrival projects.  Long running projects are occasionally dead on arrival or the market has changed and what has been delivered is not what is needed.

In 1975 when this essay was published Agile was not a word one would attach to building applications or systems. However I think we can see the seeds of the Agile revolution in this essay.