Thoughts on Scrum-ban Approach?

#24

I kind of wanted to give an update and report back on this thread every now to use it as sort of a coach/mentor as my team goes through this transition.

Yesterday would have been the start of a new Sprint, but we instead switched over to a Kanban board after @mccallam2’s encouraging words. We had a lot of healthy discussions about extending the duration of each Sprint and adding a regression period back in, but the team felt we had already been down that path when we did a Sprint/Sprint/Regression Week pattern.

First off - @Scrummando, what does “Lead Time” mean on the graphic you posted? And @mccallam2, I’ve never heard the term “Shu Team” before, can you elaborate more on that?

Are there any kind of pitfalls I need to be on the lookout for during this transition? Any ground rules I should introduce to make the transition easier?

#25

@MattMorgis “Shu team” refers to the martial arts practice of ShuHaRi. In lean/agile we steal, nay borrow, a lot from the asian culture. A shu team is an emergent team that is just modeling what it sees in the prescribed framework. Writing stories in the “as a… i want…so that…” template, being insane on the ceremonies, using the practices to control the mindset because they dont know any better yet.

#26

Not sure of the specific graphic but lead time is the amount of time it takes from an items inception point in the backlog to production.

Cycle time is the amount of time it takes for an item to get through the board once its selected.

Lets take a look at a control chart in Jira. I’ll user an example from one of my old projects…

Screen Shot 2016-09-22 at 12.47.01 PM.png796×594 35.8 KB

As you can see this story spent a day being worked on in development. Almost 24 hours in the pull request column. (which in this project meant a peer code review) and 17 hours in testing for a total cycle time of 2 days and 18 hours. The thing that pops out to me is 24 hours waiting for a code review is too much. this is something that could be discussed at the retrospective, or if you notice this early in the sprint, can be brought up right away.

Improving flow will increase the chances of a successful sprint. If the flow is poor too many things will be left to the last minute and chances of sprint failure are high and possible quality reduction as well.

#27

Let me show you a “scrum” example of why its important to continuously improve flow…

burndown.jpg2448×3264 1.72 MB

That straight line is too much WIP and poor flow. In many scenarios that will cause a sprint failure or poor quality because people are rushing to get stuff done on the last day.

#28

Here is one more thing to think about…

Lets say you have 2 teams working on 1 product and in total they have 25 stories on their boards combined in varying states. Some in progress, some waiting on getting taken to the next board column, etc.

Now lets say the teams produce a total of 5 stories per week together as done.

That means the average time it takes per story to be completed is 5 weeks per story in this scenario.

The formula is WIP/Cycle Time = Delivery rate (or average wait time).

So how can we improve the average wait time to make sure items are being delivered to done more quickly?

The easiest way to do this is to limit the WIP. Lets say that we went from 25 stories being worked on by the two teams to 8.
Then our average wait time per story would be 8/5 so 1.6 weeks which is a dramatic improvement from 5 weeks.

So instead of two teams having a bunch of WIP and working in parallel, if they can only work on 4 stories at a time per team, stories will get to a done status MUCH more quickly and it will encourage cross functionality and team work.

Obviously all these numbers are just made up that’s going to depend on your team and situation but that’s just to explain the logic and math in case anyone was curious.

#29

Here’s a link to DJA’s essential kanban condensed. Worth a flip through…

http://leankanban.com/wp-content/uploads/2016/06/Essential-Kanban-Condensed.pdf

#30

I feel your pain on trying to keep iOS and Android synced up. I was in a mobile start up last year that churned out responsive design websites and apps (usually simultaneously compatible on Windows phones, Android phones, and Apple phones - which was a testing nightmare btw!)

Have you explored an option like Xamarin (https://www.xamarin.com)? My teams had great success with that because it allowed us to develop the code and then just focus on minor tweaks and UI styling to adapt to various screen sizes and platforms. We still had an iOS dev, an Android dev, and a Windows dev on the team so we could release quickly and they essentially pair programmed. Might be worth checking out…

#31

We could definitely start an entire new thread talking pros and cons of platforms like Xamarin, Phonegap, Reactive Native, etc vs native coding. I am a full time Objective-C developer and I realize I see this from side of the hill, but in my opinion - besides the fact that they are a in a language not native to the platform or the fact FB/Microsoft could drop support at any time - if you use Swift/Obj-C, you can guarantee that your app can do anything any other app can do. A 3rd party abstraction can’t guarantee that. RN does a good job of letting you bypass the abstraction and write native plugins but that’s still never ideal. You might spend weeks on a feature using RN only to realize it can’t be done and have to rewrite it as a plugin (totally has never happened to me :wink:) . That is the main risk in my eyes. If you have great native devs on standby, and plenty of contingency in case that happens, it’s no big deal. But that’s hard to budget for.

Another update: Kanban has still been a hit. We planned one batch of work - finished it and released - in 2 weeks and 3 days (so 3 days longer than our normal sprints). We then planned the next releasable batch of work and just got started on that. We are still in our honeymoon phase - but so far the team said not having to worry about the two week time boxes and being able to take those extra three days that we needed without having to break concentration made for a much smoother release process.

#32

:heart:️ kanban !