Story Maps Across The Product Life Cycle

A life cycle is a series of floors!

Story mapping is a technique for visualizing and organizing a product backlog.  Story maps are useful for identifying a minimum viable product, for planning releases, for finding holes in the features product management needs and even for finding extraneous functionality that finds its way into every grouping of work. Story maps are so useful that they often thought of as a silver bullet. However, they are not a tool for every scenario that a team (or team of teams) might find itself facing.  All software products follow a fairly typical product lifecycle. Software products are created, enhanced and extended, maintained and then retired. While every piece of software follows this path, not every team participated in every stage of the life cycle. Story maps are not equally useful in each stage.

 

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.