Scrum


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 Checklistshttps://bit.ly/2PWu2TC

 

(more…)

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

https://oembed.libsyn.com/embed?item_id=6969007

SPaMCAST 509 will feature our essay discussing if you can demonstrate incomplete work.  My knee-jerk reaction is no…or maybe heck no, but knee-jerk reactions are not always right.

Blog entries in the what happens to incomplete work theme:

Frequently Asked Questions: The Sprint Is Over, What Do I Do With Incomplete Stories? https://bit.ly/2P9mm09

Frequently Asked Questions: Can I Demo Work That Isn’t Donehttps://bit.ly/2wfJzXv

Frequently Asked Questions: Can I Resize A Story If It Is Harder Than We Thought?https://bit.ly/2MvkB0a

Frequently Asked Questions: When Can I Demo Work That Isn’t Done https://bit.ly/2PCs0Zz  

We will also hear from Gene Hughson (Form Follows Function). Gene talks Architects!  Gene and I discussed his essay, So what exactly does an Architect do? Contact Gene on LinkedIn – https://www.linkedin.com/in/genehughson/

Bringing the cast home this week is Jon M. Quigley.  Jon brings his marvelous Alpha and Omega of Product Development to the cast this week in order to discuss the root cause analysis. Process improvement is most effective when we diagnose the real problem rather than just a symptom.

Re-Read Saturday News

In week 5 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 4, The Idea. In Chapter 4 Gawande shows how checklists can help push decision-making outward, which empowers teams and makes them more responsive.

Current Installment:

Week 5 – The Ideahttps://bit.ly/2PCs0Zz (more…)

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 Builderhttps://bit.ly/2BmIGBc (more…)

Buckle-Up Sign

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.

Sign saying propane tanks are not allowed in store.

Sometimes no is the right answer and sometimes it is not!

I have been asked many times whether it is “ok” to include work that is not complete in a demonstration/sprint review.  The simple answer is that is a bad idea 95% of the time. If the answer is no most of the time, what would the default answer to “yes”?  The only good reason to demonstrate an incomplete user story is when feedback is needed or desired to allow the team to progress and the people participating in the demo are the right people.  Allowing the team to progress is not the same demonstrating progress …we have discussed the definition of bad. Occasionally I have seen the need to show progress for reasons of organizational politics.  Not a great reason, but sometimes you have to do what is necessary to stay employed. Both of these reasons should be RARE. I have a rule: I do not spend money that is older than I am — demo’ing incomplete stories should be at least that rare.  An unasked question that is even more important when the “can I demo incomplete work” question is asked, is how can you demo incomplete work items and stay safe. (Note – Generally when people ask if they can demo incomplete items they already have or are going to do it anyway and are looking for absolution.)  

Demo’ing Incomplete Story Safety Checklist

(more…)

Sign for a weather shelter

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: (more…)

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 Forhttps://bit.ly/2J7AkRx (more…)

Next Page »