Prioritization: Advanced Quantitative Approaches – Pros and Cons of WSJF

WSJF can’t go everywhere!

On March 10, 2015, I wrote an entry on Weighted Shortest Job First (WSJF), in a nutshell,  WSJF allows you to prioritize units of work using the lean concept of cost of delay and duration/time to complete. The approach provides a consistent framework for prioritization. This is my favorite of the advanced quantitative approaches. Instead of rehashing an old article (go back and read it before continuing), we will examine a few of the pros and cons of this approach.

 

SPaMCAST 559 – Time To Reinvent Agile, A Conversation With Al Shalloway

http://www.spamcast.net

 

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

SPaMCAST 559 part one of our interview with Al Shalloway. I am breaking two guidelines this week.  First, rarely do I bring guests back so quickly. And secondly, I have not broken an interview into two parts for 7 years (ish). The conversation with Al was full of huge ideas, s, concepts, and calls to action cutting any of the content did not make sense. Al and I talked about about the troubles dogging classic agile, the Agile Industrial Complex, using a scientific approach to change, and FLEX.  Edited, the interview was 49 minutes (with about 20 minutes of chit chat ended up on the cutting room floor – figuratively). I have broken the interview into two parts of approximately 27 and 22 minutes.  Today we have part one and next week we will complete the interview. 

 

SPaMCAST 533 – Can Agile (SAFe) Be Interfaced With Waterfall, DevOps Online Summit, The Why of Testing, Essays and Discussions

http://www.spamcast.net

Direct Playback

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

Listen on Spotify!

SPaMCAST 533 features our essay titled, Can Agile (SAFe) Be Interfaced With Waterfall? The long answer is yes, but the short answer is yes, but try to find a way to avoid the self-inflicted complexity. If you can’t avoid mixing and matching frameworks, there are paths to success you can leverage.

Other essays in our series on interfacing SAFe and waterfall efforts include:

Can Agile (SAFe) Be Interfaced With Waterfall? – https://bit.ly/2SLUmou

Interfacing Agile (SAFe) With Waterfall? – Transparency – https://bit.ly/2MWNYFT

Interfacing Agile (SAFe) With Waterfall? –  Synchronization – https://bit.ly/2WVgLio

Interfacing Agile (SAFe) With Waterfall? –  Code – https://bit.ly/2I6eUUR

This week we also have a quick visit from Tom Henricksen.  Tom created the popular Online Agile Summit. Today he announces the DevOps Online Summit that will be held on April 8th through 11th.  After you listen, check out the website! https://www.devopsonlinesummit.com/2019

Jeremy Berriault brings a new installment of the QA Corner (https://qacorner.blog/) to the cast this week.  Jeremy leverages work by Simon Sinek and tackles the “why” of testing.

Re-Read Saturday News
This week we continue our re-read of The Tipping Point by Malcolm Gladwell. In chapter two, Gladwell dives into the law of the few.  There are three types of people that are important to pushing an idea up to and over a tipping point: connectors, mavens, and salespeople.  All three are required. Remember to dust off your copy or buy a new copy and read along!

Current entry:

Week 3 – The Law of the Few – https://bit.ly/2Buau46

 

Interfacing Agile (SAFe) With Waterfall – Code

 

Once you get to the point that you know you are going to have to interface a SAFe release train(s), with a waterfall program run outside your organization, success generally turns on three very related topics.  The three topics are transparency, synchronization, and code.  The timing of when the code from all parties is available and managing when the code can be integrated and tested is critical. Even if both programs produce the right code and the code works as it is expected, each program will produce functional code at very different times.  By definition waterfall projects create code after they have done a large part of the analysis and design while teams in a SAFe release train will have functional, demonstrable code earlier. By the time the waterfall project is ready to write code the agile project will have a significant investment in a code base.   Three suggested approaches (in addition to transparency and synchronization) for addressing the risk generated by the differential in code timing are:

 

Interfacing Agile (SAFe) With Waterfall – Synchronization

millaa millaa falls

In our essay, Can Agile (SAFe) Be Interfaced With Waterfall?, we identified three major areas that had to be addressed so that a multiple inter-related programs with different management approaches didn’t turn into a train wreck.  Keeping related programs moving in the same direction is important, and synchronization is critical. In a recent interview for a future SPaMCAST Alan Shalloway, CEO of NetDynamics, reminded me that the more complicated we make work, the more we reduce flow and increase the probability of making mistakes. Staking the organization’s success to integrating two programs moving at different speeds is complicated. Synchronizing successfully requires spending time and money to keep the programs synchronized. Three effective techniques used to implement synchronization are:

 

Interfacing Agile (SAFe) With Waterfall? – Transparency

Waterfalls!

In our essay, Can Agile (SAFe) Be Interfaced With Waterfall? we identified three major areas that had to be addressed so that a scenario of multiple inter-related programs with different management approaches didn’t turn into a train wreck. Lack of transparency causes misunderstandings and conflict. However, generating transparency has a cost.  Finding the right balance that fits cost and contract constraints is a goal for every complicated program. Generating transparency requires a specific set of behaviors. Several of the most common techniques for generating transparency include:

 

Can Agile (SAFe) Be Interfaced With Waterfall?

I was recently asked how an agile program could interface with a project developed by an outside firm.  The outside firm was using a waterfall process with a single planned delivery of code. The answer I wanted to give was “don’t do it”, but that isn’t a useful answer. Further context: The person asking the question works for an organization that leverages the Scaled Agile Framework Enterprise (SAFe); using the Essential SAFe instantiation for most of the work in the organization. While several release trains exist inside the organization, they are not closely interrelated. Therefore the organization does not need to leverage Enterprise SAFe. Assuming you cannot avoid having two separate but interrelated and dependent projects with one run by a separate organization and using a different approach than your organization, there are several major issues involved in answering the question. Three of these are:

 

An Interlude and A Book Poll!

Slow Down!

I was asked to step in and help during a SAFe Program Increment Planning event this week, therefore this entry is short.  

 

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: