SPaMCAST 513 – Reciprocity and Passengers, Self-directed Teams, Hard Deadlines, Essays and Discussions

http://www.spamcast.net

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

SPaMCAST 513 features a second essay on reciprocity.  One of the hardest lessons I have had to learn is that some people on a team are passengers and others play different, more involved, roles. Being a passenger long-term on a team or in an organization is a form of rent-seeking and is not valued highly by others.

We also have columns from Susan Parente (I Am Not a Scrumdamentalist) and Jeremy Berriault (QA Corner).  Susan provides a spirited discussion of self-directed teams in agile.  It is a myth that agile teams just get to do what they want. One of the places to find Susan is at S3 Technologies, LLC. Rounding out the cast is this month’s installment of the QA Corner.   Jeremy discusses one of thorniest facts of life for a tester — hard deadlines.

Re-Read Saturday News

This week we tackle Chapter 8, titled The Hero In The Age of Checklists.  Heroes are a big deal; pick up any newspaper and you will see how much the cult of hero is celebrated.  Checklists and methods are viewed by many as diminishing the role of the hero which sows the seeds of resistance to change.  What role does the hero play in a disciplined process? If the hero is core to how we view ourselves and our society, do tools like checklists run the risk of being met with hostility?  Chapter 8 dives directly into the deep end to address these topics.

We have two or three more weeks left in this re-read, which means it’s time for the poll.  Vote and be heard! Write in candidates are welcome.

Remember to buy a copy of The Checklist Manifesto and READ along!

Current Installment:

Week 9 – The Hero In The Age of Checklists – https://bit.ly/2PWu2TC

 

 

SPaMCAST 508 – Product Owners and Scrum Masters, An Interview with Vasco Duarte

http://www.spamcast.net

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

SPaMCAST 508 features our interview with Vasco Duarte!  Vasco and I discuss vision and product owners. The product owner role is crucial. To be effective, the product owner must be able to articulate a vision for the product they champion.

Vasco Duarte’s Bio in his own words:

I want to transform product development organizations into product business organizations. I do that by focusing the work of the product development teams on the end-to-end life-cycle of their products. From Concept to Cash and Back!

Currently a Managing Partner at Oikosofy.

Product Manager, Scrum Master, Project Manager, Director, Agile Coach are only some of the roles that I’ve taken in software development organizations. Having worked in the software industry since 1997, and Agile practitioner since 2004. I’ve worked in small, medium and large software organizations as an Agile Coach or leader in agile adoption at those organizations.

I was one of the leaders and catalysts of Agile methods and Agile culture adoption at Avira, Nokia, and F-Secure.

I host a daily podcast where I interview Scrum Masters about their daily challenges and insights: https://scrum-master-toolbox.org/

You can read more from me at my blog: http://SoftwareDevelopmentToday.com

You can join me on twitter: @duarte_vasco

Re-Read Saturday News

In week 4 of re-read of The Checklist Manifesto by Atul Gawande (use the link and buy a copy so you can read along) we tackle Chapter 3, The End Of The Master Builder.  In Chapter 3 Gawande identifies the scenarios in which checklists have an impact.  Checklists provide value even in the most complicated scenarios.

Current Installment:

Week 4 – The End Of The Master Builder – https://bit.ly/2BmIGBc

 

Frequently Asked Questions: The Sprint Is Over, What Do I Do With Incomplete Stories?

When everything is done it is time to buckle and go home!

When I am asked what a team should do with stories that are incomplete at the end of a sprint or iteration I am reminded of the Jackson Browne song Load Out -Stay –

“Now the seats are all empty
Let the roadies take the stage
Pack it up and tear it down
They’re the first to come and last to leave”

Now the demonstration and retrospective are all done and despite the team’s best efforts, one or more stories do not meet the definition of done. The planning process that springs into action after the completion of one sprint often times feels sort of anticlimactic compared to the celebration that marks the end of an iteration. The team feels like the roadies as they swing back into action to pack up the last iteration and get the next ready to go. Shortcuts are sometimes taken with teams and product owners without thinking about “rolling-over” the escaped stories. Doing anything without thought is never a good idea. The three basic steps for dealing with incomplete stories are:

1. Return the incomplete stories (or other work items) to the backlog. Stories are either done or not done, there is no partial credit.
2. Re-prioritize the backlog based on all of the stories on the backlog. There are a number of approaches for prioritization ranging from most risky first to most valuable first. As part of the re-prioritization, reassess the approach to selecting work. At times it might be more important not to stop work on the story even when it does not meet the team’s prioritization strategy. Sometimes team members have just gotten to a point they can solve a problem and putting down might be less efficient, however, sometimes the need of the business and product owner will conflict (the product owner and business always win).
3. Plan (or re-plan) the work that will enter the team level planning process. Prioritize stories that are more important or return higher value ahead of the stories that you returned to the backlog unless there is a solid reason why that should happen.

The process for dealing with incomplete stories is straightforward. Incomplete stories have to compete for attention just like any other story. Being partially done does not generate a privileged position.

In addition to re-prioritization, items you should keep in mind when addressing incomplete stories.

1. Do not recognize any contribution to velocity or throughput for incomplete items. Remember no partial credit. Velocity is an average over a large number of sprints or iterations; it will balance out. Throughput is similar.
2. If you are tracking cycle time (and you should be) don’t reset the start date of the story. The start date for the piece of work begins when the team first starts to work on the item and ends when the story meets the definition of done.
3. If using story points and velocity as a planning tool don’t resize the story or your velocity will be incorrect and no amount of averaging will fix the problem.

Resist the urge just to roll over stories into the next sprint or iteration. Reassess whether they should be worked on in the next sprint (or even if they should be worked on at all) when compared to other work. Reassessing will make people uncomfortable; there was a commitment to complete an item when you drew it into the sprint. However, transparency and thought are core behaviors that every team should embrace.

 

Frequently Asked Questions: Can I Demo Work That Isn’t Done

Is A Demo A SAFe Area?

I have been asked many times whether it is “ok” to include work that is not complete in a demonstration/sprint review (I’ll use the term demo from now on).  The simple answer is that is a bad idea 95% percent of the time. Demos are agile’s mechanism to share what the team completed during the current sprint or iteration. The use of ‘complete’ is purposeful. It means the work meets the organization’s technical standards and is potentially deployable in production.  Complete mean stories that meet the definition of done – before the demo, not the next day. Teams define done before they begin work. Done typically includes steps such as coding, testing, documenting and reviewing. Unless the piece of work meets the definition of done (or a deviation agreed upon) then the work is not done. Demonstrating in progress material is a bad idea in most situations for many reasons.  Mixing done and not items in a demo:

 

SPaMCAST 497 – Micromanagement, Getting a Handle, Hybrid Agile Solutions

http://www.spamcast.net

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

SPaMCAST 497 features our essay on micromanagement.  Micromanagement is a bane to employees that fall under a micromanager’s control. If you ask any manager if they think micromanagement is useful they will tell you no.  The problem is that many managers still do it and then rationalize the behavior.

We also welcome back Dr. Susan Parente, with her “Not a Scrumdamentalist” column.  In this installment, Susan discusses using hybrid agile methods to deliver value. The message is that the development approach needs to meld with the organization’s culture.

Gene Hughson brings the cast home with another entry from his Form Follows Function blog.  In this installment Gene discusses his essay, Getting a handle on IT costs by eliminating chargebacks?  IT costs are a chronic problem. Ideas for getting a handle on costs are always useful.

Re-Read Saturday News

In week twelve of the re-read of L. David Marquet’s Turn the Ship Around!  (Buy your copy now).  This week we tackle Underway for San Diego and All Present and Accounted For.  Two more tools that are immediately useful.

Current Installment:

Week 12: Underway for San Diego and All Present and Accounted For – https://bit.ly/2J7AkRx

 

SPaMCAST 491- When Done Breaks Production, Personal Kanban, Real Software Quality

http://www.spamcast.net

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

Software Process and Measurement Cast 491 features our essay titled, Can “Done” Be Allowed To Break Production?  The most succinct answer to the question is always no, the story is not done. The reason is that the story is not implementable, and unless the goal of the story is to blow up production and anger customers it can’t be considered to be done.

Susan Parente brings her Not a Scrumdamentalist column to the cast this week.  Susan discusses Kanban for You and Me.  The discussion focuses on personal Kanban and how to use it to guide your day to day activities effectively and efficiently.

Kim Pries, the Software Sensi, anchors the cast this week.  Kim’s essay is titled Real Software Quality.  In this column, Kim warns us of the dangers of interventionism on quality.

Re-Read Saturday News

In week six of the re-read of L. David Marquet’s Turn the Ship Around! we tackle chapter 7, titled I Relieve You. I am breaking the two chapter pattern to layup so that we can have a clean start the second part of the book next week Chapter Seven completes Part One of the book.  Part one serves tells the story of how Captain Marquet came to be in command of the USSN Santa Fe rather than the Olympia. Much of Marquet’s leadership model was emergent (like design in agile). Change may occur even without a shock like Marquet’s reassignment, but adding energy will hasten change. In this case, the shock made the development of Marquet’s leadership model inevitable.

Current Installment:

Week 6: I Relieve You – https://bit.ly/2F7C5ag

Previous Installments:

 

The Definition of Done: Simplicity and Complexity Revisited

A Simple Life!

The Definition of Done is an important Agile technique to help teams plan and execute work.   The simplest definition of the Definition of Done is the criteria that a work product must meet to be considered to be complete. While the concept is simple, the implementation of the technique in the real world is rarely simple. Both context and interpretations make things just a bit gray!