team-scrum-a-fall
team-scrum-a-fall

There are many definitions of Agilefall or Scrumfall.  Some describe it as a waterfall design process with a design-code-test center that later goes to QA and Operations. Other versions talk about creating mini-waterfall processes within a Scrum Sprint or a shortened Iteration Time-box.  What I call a Dev-Scrum-A-Fall as depicted in the graphic below.

Dev-Scrum-A-Fall during an Iteration Time-box
Dev-Scrum-A-Fall during an Iteration Time-box

I would like to warn Project managers of another type and what I call Team-Scrum-A-Fall.

Team-Scrum-A-Fall – Bad News for your Project Schedules

Team-Scrum-A-Fall in this posting is a result of combining Scrum with Functionality Teams.  I have seen company decide to expand Scrum to all their team but leave them in tact as functional teams.  Something like unique Java Scrum teams, a UI Scrum Team, a DBA Scrum team, a Salesforce (SFDC) Scrum team, an Infrastructure Scrum team, etc…

multi sprint backlogs
multi sprint backlogs

What happens is that companies build up “Scrum” teams that are needed to deliver a potentially shippable product, so if your issue that needs fixing or concept developed it needs to be worked by multiple teams to be complete. I put Scrum in quotes because I don’t really believe those teams are really Scrum Team.  They are in name only which in the end gives Scrum a bad reputation. In most software there is always some connector or piece of data that needs to be handled by multiple systems.  However, if the multiple systems can only be handled by separate scrum teams you a  project manager are screwed.  I have seen things that should take only days to do take months to complete, even for the most basic changes.

Looking a workflow view of the effort here is what happens with functional Scrum team that can only change their Sprint Backlogs at the beginning of the Sprint.

Sprint Functional Team workflow
Sprint Functional Team workflow

If I were create a Gantt Chart of the flow above

team-scrum-a-fall
team-scrum-a-fall

Hey look Team-Scrum-A-Fall

Now as Program Manager / Project Manager and even Scrum Master this kind of work flow drives us nuts.  If we have some code that really should only take a couple of days to work in each functional area, but now since each functional area is now its own Sprint Team it will take 6 Sprints to finish.  That is Nuts!

For one customer I saw that virtually every project was one month to 6 months behind schedule.

I believe it was because of Team-Scrum-A-Fall.  No matter what we would fail on schedule.  So now take the same level of work and combine it into a Single team.

shorten sprint length
shorten sprint length

To fix this problem guess what organizations do?  They shorten the Sprint length!  This makes me laugh because they really didn’t fix the problem they just made the allowable Sprint Backlogs smaller and more frequent, they can change them more often.

I love it when people say shortening the Sprint Time Box is the solution to everything.

I say sarcastically.  But they really do say this.  Mostly because they don’t understand.

 

 

The Vertical Slice Concept.

vertical team slice
vertical team slice

All the experienced Agile people agree that a Team works best when they can work the entire vertical slice of the development.

In the graphic to the right the work that was taking 6 Sprints to finish is now done in one or two Sprints.  Some in the functional world would say that this an inefficient use of functional resources, but I would argue it is not.

In the functional view of life as seen in the previous graphics a small piece of work effort impact 4 teams or over 20 plus people and expands across 6 Sprints.  Where in a true Scrum Vertical Slice Team it only affects 4 to 6 people worst case and is complete in one Sprint.  For your functional concept I could spend the same funds on 4 Vertically Sliced Teams and get 6 times the amount of work into production.

If managers wonder well how am I going to to ensure the functional quality and expertise is maintained, well then the organization can create some sort of functional circle to maintain knowledge sharing for that function.

So in essence I just showed how a good cross-functional team can get 6x the  work into production 6 times as fast as 4 functional team do in the same period.

 

 

 

 

 

A Good Cross Function Team is 6 Times Faster Than 4 Functional Teams
When it Comes to Product Delivery

comparison of shippable product times
comparison of shippable product times

 

 

Now instead of falling down a waterfall we have more free time to enjoy more PTO to relax and go for a river tube ride.

scrum team cruising tubing on river
scrum team tubing on river