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

SPaMCAST 566 features our interview with Christopher Gerg. Security issues can range from clicking on the wrong thing in emails to ransomware and is painful and costly. Security might be everybody’s responsibility however someone needs to lead the charge. Our conversation covered the role of the CISO in today’s organization, security in software development, and cybersecurity in the real world.   (more…)

Definition of done

Definition of done

In “User Stories Are For Technical, Operational and Risk Stories Too!” we made the case that user stories are not just for customer facing user interfaces.  But, we only partially answered the question:

“I would like to see some sample user stories in infrastructure projects such as network migration or upgrade, storage provisioning, or server provisioning.  I think storage provisioning would be a little bit complex due to hardening and other security requirements.”

The nuance in the question centers on the phrase “hardening and other security requirements.” There are two approaches that I often use for stories with nonfunctional requirements.  The first (and not my favorite) is through a final hardening sprint. The second approach is splitting the user stories into thin slices and then incorporating the nonfunctional requirements into the definition of done. (more…)

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

SPaMCAST 426 marks a milestone!  SPaMCAST 426 is the end of Year 10.  The Cast features our second annual round table.  Almost all of the SPaMCAST contributors gathered virtually to discuss a number of topics, including:

  1. Is software quality really one of the most important focuses in IT in 2017?
  2. Even though people are adopting agile, is agile a as principle-driven movement over?
  3. In 2017 will security trump quality and productivity?

The multiway discussion was exciting and informative! This was a great way to finish year 10 and get the motor primed for year 11!

Re-Read Saturday News

This week we begin the re-read of Carol Dweck’s Mindset: The New Psychology of Success. We will start slowly as I read ahead and give you time to find or buy a copy of the book.   I am reading the 2008 Ballantine Books Trade paperback edition version of the book (I had to re-buy the book as my first copy seems to have a new home).  

I was excited that the Software Process and Measurement Blog readers selected Mindset for Re-read Saturday.  I am looking forward to refreshing my understanding of the powerful ideas Dweck identifies as growth and fixed mindsets.  Mindsets are very useful for understanding why some people grow and others don’t and why some teams excel and other less so. Also, Mindset is easily the single most quoted book  I have seen in presentations at conferences for the past few years.

Next week we start in on Chapter One of the re-read of Carol Dweck’s Mindset, buy a copy this week.

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

Next SPaMCAST

The Software Process and Measurement Cast 427 begins Year 11 with an essay on the Post-Agile Age.  It is coming and it is a bed that human nature and commercial pressures has created. (Not sure what I mean?  Tune in, stream or download )  We will also have columns from Jon Quigley, Jeremy Berriault, and Kim Pries.  SPaMCAST 427 will celebrate the new SPaMCAST year in style!

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.

 

Definition of done

Definition of done

In “User Stories Are For Technical, Operational and Risk Stories Too!” we made the case that user stories are not just for customer facing user interfaces.  But, we only partially answered the question:

“I would like to see some sample user stories in infrastructure projects such as network migration or upgrade, storage provisioning, or server provisioning.  I think storage provisioning would be a little bit complex due to hardening and other security requirements.”

The nuance in the question centers on the phrase “hardening and other security requirements.” There are two approaches that I often use for stories with nonfunctional requirements.  The first (and not my favorite) is through a final hardening sprint. The second approach is splitting the user stories into thin slices and then incorporating the nonfunctional requirements into the definition of done.

The first solution is leveraging a final hardening sprint. In this scenario an integrated solution is assembled, tested and tuned. Many organizations wait to perform security testing until they have a fully integrated system. In some cases, such as a high security environment or scenario where entire solution is not available to integrate into a single environment, this approach is difficult to avoid. The difficulty with this approach is that it puts off gaining valuable feedback on security and integration until very late in the project. Finding problems late in the project can imperil delivery or cause defects to be pushed into production (Go fever is the pressure to implement even though there are known problems).

The second solution begins by incorporating hardening and security requirements into the story’s definition of done. The definition of done is the requirements that the software must meet to be considered complete. Adding hardening and security requirements to the definition of done will cause the team to add specific tasks to both ensure the requirements are built into the solution of the story and then prove they are implemented. The added tasks will either require the team to accept fewer stories into the sprint or to more thinly slice each story.  This approach is optimal in organizations that continually integrate and test functionality as it is built, however I recommend it for any organization even when an overall final test is required.

A better approach is to combine the both options.  For example, a manufacturer of financial hardware I spoke with recently develops hardware and software on different development tracks which requires a final integration, security and a stress test sprint. In order to avoid potential shipping delays, which are viewed as potentially catastrophic to the business, security and hardening requirements were added to the definition of done for both hardware and software stories. Teams built testing appliances and harnesses to generate early feedback on the nonfunctional requirements.     

Security and hardening are nonfunctional requirements that affect how hardware or software requirements are built, tested and delivered.  These nonfunctional requirements are tasks, not separate stories.  Task and process requirements are better suited as components in the definition of done that are applied to stories and help teams plan their work.