Thoughts on Scrum-ban Approach?


Continuing the discussion from Agile in Education:

I’m certainly looking for some advice on a shift in approaches I am considering from Scrum to a Scrum-ban idea. I’ll start off by giving some background and context.

In early 2015 I discovered Scrum, bought in, and attempted to apply it to my freelance business and with my team at my day job. Despite the few typical obstacles you face in a large enterprise, I feel as if our team is humming along nicely for the past 6-8 months, and over the summer I think we really hit our stride.

We work on a typical 21st century product; it has a back-end API, a web app, and an iOS and Android application.

There are 4 total teams:

  • Teams A, B, and C: Kanban feature teams that consistent of back-end, front-end, QA, BA, dedicated P.O.'s. They release
  • Team D (my team) - 2 iOS engineers, 2 Android engineers, 1 QA, 1 very engaged P.O. (he runs our demos!)

We have made attempts to matrix with the 3 feature teams, but if we applied 1 iOS and 1 Android engineer to each team, there would be one team that could never build in a mobile feature. Additionally, this setup has actually worked very well because the mobile apps were released within the last year and the web app has been alive for years. We have simply been trying to catch up and just get in sync with the same features the website has to offer. Now that we are caught up, we are forking and adding features to the mobile apps that aren’t exactly possible on a website. However, there are times when changes need to go live in both mobile and web around the same timeframe.

Some of the things our team does well:

  • We hold Backlog refinement meetings twice a week
  • We have consistent retrospectives and a Trello board of action items from them
  • We’ve spent the summer chipping away at automating a lot of tests - we have Android about 70%~ complete and iOS 30%~.
  • We ‘outgrew’ our B.A. and started writing our own stories, etc.
  • We do not go to production every Sprint, but we did always try to have a stable, incremental improvement completed.

However, a constant topic that comes up in retrospectives is the two week time box we set for ourselves. The common phrase is they feel like “a round peg in a square hole.” Here are some of the challenges we face that I think are pretty unique to mobile:

  • I split my time between Scurmmaster and iOS engineer, which wouldn’t be much of an issue if…
  • We have two separate code bases (iOS and Android) that, since this is a medical tool, need to be nearly identical and exact experiences regardless of the device and operating system. This means if the Android engineers finish a feature, but the iOS engineers are a little behind with it, Android must wait.
  • If there is a bad release on a website, the site can be reverted back in a few minutes. There is no rolling back a mobile app release. Only about 40% of our users have auto-update on. About 5% of our users are still on 1.0.0 from last November. This means:
    • If a hotfix is needed, only 40% of users will receive it immediately.
    • Apple review times have been consistent at 1-3 days. Fixes take days to reach users.
    • Backwards compatibility is always a pain in the ass - users are spread across multiple versions of the app and several devices and operating systems. There are a lot of devices and operating systems we need to support and test against.
  • As a result of the aforementioned items, we spend a lot of time manually regression testing the apps before a release. As the app has grown, manual regression testing time has grown exponentially. Getting the automated tests in place will help this, but there still needs to be a certain level of care before pushing to production with a medical product.

Because of the level of testing that is required by the business before we push a release, it takes our team 3-5 days to fully regression test for a release and anywhere between 4-6 days to do a full release. We normally come up with a fixed batch of work that we want to release. “Let’s support these 7 languages” for example. We will writes the stories for the epic(s) that will make the release and start Sprints to burn through the work. We make a ticket for the release with the various tasks required for it that gets pulled into a Sprint like any other ticket.

We just find the two week time boxes to get in the way more then help guide us along. This has been our typical path with Scrum:

  • A good example of this situation is something that happened today. One engineer finished a release ticket that took him two days longer than we expected to get it out the door. Since it was a fresh release, the next priority item was the start of a large refactoring effort. The ticket was estimated at 7 days - 5 for coding and 2 for testing. Being that it was a refactoring effort, we failed to break it down further. Does the engineer take the next 5 days off until he can start it in the next Sprint? There was nothing to test - we just released. Does he start it knowing that we aren’t going to complete it by the end? We struggle with this kind of thing constantly, and since our Sprints aren’t tied to releases, there isn’t much of a consequence when a story carries. We seem to always complete 90% of the work and carry a handful of tickets that are in progress.
  • We find out about a feature that is going live in the website, built by one of the 3 feature teams, that also needs a mobile component and it becomes a priority to us over the mobile-only specific feature we are currently building. This shouldn’t be a big deal. We can just branch the production code, build in the feature, release, and go back to the one that we had in progress. However, we often can’t start this work until the end of the Sprint, which feels silly to us. (This week we started a twice-a-week scrum of scrums with those 3 feature teams to stay on the same page.)
  • Sometimes we start a release ticket with 2 days left in a Sprint and let it carry. As aforementioned, a release ticket will take us a few days. Why would we wait until the next Sprint to start it?
  • We do not do a demo every Sprint - our P.O. will demo our release candidate build to stakeholders before a release, he accepts every story and defect as we go and is very in the loop as to what is happening (he’s a former dev, which comes in handy because he understands things on a technical level and knows how important an engaged P.O. is to the team).

During a team discussion around our release process and how we can possibly improve it, the conversation shifted back to how the two week Sprints get in the way more than the release process itself. We have no problem completing the amount of testing involved with the release, it’s that it doesn’t always line up to a two-week period.

The team then proposed we stick with our normal routine of weekly backlog refinement, daily stand ups, two-week retrospectives, and continue to have our P.O. demo to stakeholders on a release-basis. We simply remove the two-week time box and just let the work flow naturally flow through our process. We already have WIP limits for coding, code review and testing in our process, and we feel like it would be a minor change to the way we operate.

What are the opinions out there on this approach? Pros and cons? Are we not solving the right problem? Are we properly adapting to the situation at hand?

Scrum Situation - Opinions Wanted
Scrum Without a Fixed Timebox

Seems like you have pretty awesome things going on! An engaged PO and a team that wants to improve!

This is one of those questions that would be easier to chat thru over beers… since so much is situational. But I’ll give async a shot.

With two mobile teams that I currently support (both Shu-level) I am finding something useful about a fixed cadence. It provides nice constraints against priority trashing by a much less disciplined Product Owner. Provides a nice focused timebox for devs to get stuff to Done.

Has the team considered a three week iteration cycle? More a scrumfall approach, with the last week being your regression testing cycle for your mobile apps.

You could also eliminate the weekly backlog refinement, and use QA week to do event

With a well maintained backlog, devs could start on the next high priority issues for the upcoming three week sprint during “QA week” if it’s not too much of a context switch.

Or they can be slaying bugs in preparation for RC at the end of three weeks.

An issue I’ve run into w mobile development and kanban is trying to answer the question “when do we have enough user facing value submit a build to iTunes/Google?”

Web teams don’t have this same consideration, they can pretty much do continuous deployment.

Regarding syncing features across the web and mobile platforms, that seems like a separate problem. One the assorted PO’s should be collaborating more on, creating a better master roadmap for the entire product line. So that mobile can be ahead of web, and mobile apk’s and ipa’s can be thru the QA process, thru Apple review, and “awaiting dev release” the week web is planning to deploy.


I don’t think I can +1 this enough. This is a big challenge that exists.

Our team has expressed they too like the fixed cadence of Scrum, and I didn’t even consider how much more chaotic priority shifting could get by moving to Kanban.

We actually were doing a similar scrum fall approach as you mentioned (and @ryan gave us hell for it) where after every 2 sprints, we had a 5 day regression period. The idea was to release every 5 weeks. However, we ran into the same issues where something just wasn’t quite ready on the first day of regression week, but we didn’t want to wait another 5 weeks for it to roll around again. It was eventually deemed in retrospective it would be easier to do away with them and just roll with straight two-week iterations.

This three week schedule is slightly different however. I shared it with my team along with your thoughts and will discuss with them tomorrow. I’m curious what others will chime in with about QA/regression weeks :rolling_eyes:


One thing that I have done in this situation was to have the mobile team establish a “Code Freeze” date within the 3-week iteration. Say 5 days before iteration review. Only stories that meet the teams DoD are allowed into the branch.

All bugs that come out of QA after CF are evaluated by QA/PO as blocker/non-blockers for that release. Team is committed to fixing all blockers for RC. Non-blockers carry over to next iteration

And then I challenged the team to continually reduce the number of days in that “hardening” waterfall portion of their sprint. More unit tests, more CI red/green, more automated testing.

On one HP team, they were able to get that 5 days down to 1 day. Took 'em the better part of a 6 months but they did it.

I was proud of them. Let them enjoy it for a sprint. And then challenged them to cut it half again… They sighed, but leaned into it. A indeed got it down to 1/2 a day. With near zero carry over of defects to next sprint.


That’s impressive. How did you convince them it was worth the effort? I get a lot of push back from developers and product about writing tests.


The classic Coach 1-2-3

  1. Sync the challenge with the team’s core values
  2. Leverage one or two high-valued motivators
  3. Have at least one dev-team member on board (my secret weapon)

Maybe a 4: Don’t give them the solution (eg “you guys need to write more tests”); present the problem: “How could we get 5 days of context switching down to 2.5 days? *and then 2.5 days down to 1 day) so you guys have more focus time to write excellent code that delivers user facing value?”

If met w silence, count to 10 and then see Coaching: When to be Prescriptive


Another thought about the SM/Dev-Team combo role.

What if you there was no dedicated SM? instead the team had a rotating iteration lead that served that role?

I’m going to start a new topic on that.

Dedicated Scrum Master of Shared Role? Dedicated ScrumMaster or a shared role?


Hi Matt! What you have described here in terms of continuous flow in a Kanban system with regular cadences is what I typically coach teams toward (ie: regularly scheduled backlog grooming, standups, retros & demos). I think the biggest barrier to success in this format is that it requires more engagement from the PO- rather than every two weeks of having the backlog ready for the team, the PO is doing this everyday. The good part about this is that its easier to reprioritize as needed and respond to issues or changes. This is also helpful in your question about when to be ready to submit to the app store or deploy- it can be more fluid rather than all or nothing. Happy to talk more and share my examples of success mobile and web app teams!


I’m going to post this response here and I guess the other thread lol

Can a baseball team function without a coach and one of the players acting as the coach? Yes. Then why does every baseball team have a coach? A Scrum Master is meant to be like a Scrum Team coach.

It’s not that you as a developer cannot do the duties of a Scrum Master, obviously you are Capable of it but it’s more a matter of splitting your time and the consequences of that. Which could be…

  1. It takes away from your development time and could cause more stress on yourself than necessary possibly affecting your own sustainable pace.
  2. If you look at what a scrum master does, I don’t see how you could be fully doing a SM job while focusing on development. What I imagine you are doing is more of facilitating ceremonies (which is just one responsibility of a SM) if you are doing more than this then it goes back to my point number 1.
  3. I’m giving you this from my perspective but a good SM does whatever it takes to make the team successful. @cusack gave me a great quote last week which i’ll put here… “A Scrum Masters primary role is to help the team discover new opportunities for continuous improvement, while protecting the team from outside influences and distractions”

Part one of the sentence is an ongoing and never ending responsibility. It’s vague yes but that’s intentional because every day it will require something different. If a SM has time to focus on continuous improvement he can help the team improve on a daily basis on more of an Agile Coach role for the team.

Part two states that he should be protecting the team from outside influences and distractions, also I believe removing impediments should also be part of this sentence. Daily there could be impediments that need to be removed some examples could be…

  1. Devs computer needs new ram, or he needs a new computer.
  2. I had a situation on my india teams where every thursday the power kept shutting off and the team was sitting in the dark in 100 degrees getting bit by mosquitos. Now WHY they didn’t just work from home, that’s a discussion for another time. As a Scrum Master, I had to deal with this issue to ensure this problem didn’t happen anymore.
  3. AN impediment could be something as simple as, a team member has a new baby and got 2 hours of sleep last night. They show up to work and are exhausted already and they know they have a full day of work ahead of them. As a SM it’s his/her job to help this person, help the team in an effective way. What does that entail? Well that’s up to the individual, maybe I have to go to starbucks and get a triple shot.

I’ve been learning a lot from Dave Prior recently about his past experiences as a Scrum Master at Skype and Netflix I believe. He has told me a few stories…

One team he was the SM for, the most brilliant person was an Alcoholic and could not function without drinking. Some mornings he would have to drive to the dudes house and drag him out of bed.
Another team, a guy would get stoned at lunch and go play racquetball and come back high and sweaty every day.
Another team someone was a crystal meth addict. The SM has to deal with ALL people issues which is going to be different from team to team.

Team Dynamics…

  1. There are team dynamics that the scrum master should be removed from to help improve the team. Meaning people have issues, egos, different ways of working etc. The scrum master should not be involved in these team dynamics, he should be a neutral party.

  2. Example: A team member felt like they were being treated unfairly by other team members because they were asked to do other work outside of the scope of the sprint that he felt other team members were not asked to do. I wasn’t aware of this because this person never spoke up about it until it came to a climax and he was approaching me privately. As a SM there are a few things I had to do here, one is find out WHY outside influence and distraction was happening to my team. Once I figured that out, I had to deal with team dynamics and try to get them back to at least norming state. I had one on ones with different team members until I felt like I understood what the hell was happening and came up with a solution which in the end thankfully worked and the team is doing very well right now. This is not to pat myself on the back as of course i’m giving you a small success story and not any mistakes haha but the point is, this took TIME, energy, soft skills like ability to listen, discern, and comfort, and lastly problem solve. If I had to do all this WHILE trying to meet a commitment to sprint as a developer, I don’t see how it would be possible. And this is just one small example of a million I could potentially give.

And last thing I’ll say about this is… Check out this checklist of SOME of the duties of a scrum master and honestly tell me if one person can do this WHILE being a full time developer and not having it affect the team performance and commitments.

" A Full Time Facilitator?

An Example Checklist for ScrumMasters

Michael James ( 14 September 2007 (Revised 2 Feb 2016)

An adequate ScrumMaster can handle two or three teams at a time. If you’re content to limit your role to organizing meetings, enforcing timeboxes, and responding to the impediments people explicitly report, you can get by with part time attention to this role. The team will probably still exceed the baseline, pre-Scrum expectation at your organization, and probably nothing catastrophic will happen.

But if you can envision a team that has a great time accomplishing things no one previously thought possible, within a transformed organization, consider being a great ScrumMaster.

A great ScrumMaster can handle one team at a time.

We recommend one dedicated ScrumMaster per team of about seven when starting out.
If you haven’t discovered all the work there is to do, tune in to your Product Owner, your team, your team’s engineering practices, and the organization outside your team. While there’s no single prescription for everyone, I’ve outlined typical things I’ve seen ScrumMasters overlook. Please mark each box with √, ∆, ?, or N/A, as described on the last page.

Part I – How Is My Product Owner Doing?
ScrumMasters improve Product Owner effectiveness by helping them find ways to maintain the Product Backlog and release plan. (Note that the Product Owner is the one responsible for the prioritized backlog.)
☐ Is the Product Backlog prioritized according to his/her latest thinking?
☐ Are requirements and desirements from all stakeholders captured in the Product Backlog? Remember: the
backlog is emergent.
☐ Is the Product Backlog a manageable size? To maintain a manageable number of items, keep things more granular towards the top, with general epics at the bottom. It’s counterproductive to overanalyze too far past the top of the Product Backlog. Your requirements will change in an ongoing conversation between the developing product and the stakeholders/customers.
☐ Could any requirements (especially those near the top of the Product Backlog) be better expressed as independent, negotiable, valuable, estimable, small, and testable user stories1?
☐ Have you educated your Product Owner about technical debt and how to avoid it? One piece of the puzzle may be to write automated test and refactoring into the definition of “done” for each backlog item.
☐ Is the backlog an information radiator, immediately visible to all stakeholders?
☐ If you’re using an automated tool for backlog management, does everyone know how to use it easily? Automated management tools introduce the danger of becoming information refrigerators without active radiation from the ScrumMaster.
Copyright © 2007-2016 Michael James. All Rights Reserved.

☐ Can you help radiate information by showing everyone printouts?
☐ Can you help radiate information by creating big visible charts?
☐ Have you helped your Product Owner organize backlog items into appropriate releases or priority groups?
☐ Does everyone know whether the release plan still matches reality? You might try showing everyone Product/ Release Burndown Charts2 after the items have been acknowledged as “done” during every Sprint Review Meeting. Charts showing both the rate of PBIs actually completed and new ones added allow early discovery of scope/schedule drift.
☐ Did your Product Owner adjust the release plan after the last Sprint Review Meeting? The minority of Product Owners who ship adequately tested products on time re-plan the release every Sprint. This probably requires deferring some work for future releases as more important work is discovered.

Part II – How Is My Team Doing?
While you are encouraged to lead by the example of collaborating with team members on their work, there is a
risk you will get lost in technical tasks. Consider your primary responsibilities to the team:
☐ Is your team in the state of flow? Some characteristics of this state3:
• Clear goals (expectations and rules are discernible and goals are attainable, aligning appropriately with
one’s skill set and abilities).
• Concentration and focus, a high degree of concentration on a limited field of attention.
• A loss of the feeling of self-consciousness, the merging of action and awareness.
• Direct and immediate feedback (successes and failures in the course of the activity are apparent, so that behavior can be adjusted as needed).
• Balance between ability level and challenge (the activity is neither too easy nor too difficult).
• A sense of personal control over the situation or activity.
• The activity is intrinsically rewarding, so there is an effortlessness of action.
☐ Do team members seem to like each other, goof off together, and celebrate each other’s success?
☐ Do team members hold each other accountable to high standards, and challenge each other to grow?
☐ Are there issues/opportunities the team isn’t discussing because they’re too uncomfortable?4
☐ Have you tried a variety of formats and locations for Sprint Retrospective Meetings?5
☐ Has the team kept focus on Sprint goals? Perhaps you should conduct a mid-Sprint checkup to re-review the acceptance criteria of the Product Backlog Items committed for this Sprint.
2 Mike Cohn, Agile Estimation and Planning. (2005).
3 Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience (1990).
4 Marshall Rosenberg, Nonviolent Communication: A Language of Life: Life-Changing Tools for Healthy Relationships (2003). Also consider enlisting a professional facilitator who can make uncomfortable conversations more comfortable.
5 Derby/Larson Agile Retrospectives: Making Good Teams Great (2006).
Copyright © 2007-2016 Michael James. All Rights Reserved.

☐ Does the Sprint taskboard reflect what the team is actually doing? Beware the “dark matter” of undisclosed tasks and tasks bigger than one day’s work. Tasks not related to Sprint commitments are impediments to those commitments.
☐ Does your team have 3-9 people with a sufficient mix of skills to build a potentially shippable product increment?
☐ Is your team’s taskboard up to date?
☐ Are the team self-management artifacts visible to the team, convenient for the team to use?
☐ Are these artifacts adequately protected from meddlers? Excess scrutiny of daily activity by people outside the team may impede team internal transparency and self management.
☐ Do team members volunteer for tasks?
☐ Has the need for technical debt repayment been made explicit in the definition of done, gradually making the
code a more pleasant place to work?
☐ Are team members leaving their job titles at the door of the team room, collectively responsible for all aspects of agreed work (testing, user documentation, etc.)?

Part III – How Are Our Engineering Practices Doing?
☐ Does your system in development have a “push to test” button allowing anyone (same team or different team) to conveniently detect when they’ve caused a regression failure (broken previously-working functionality)? Typically this is achieved through the xUnit framework (JUnit, NUnit, etc.).
☐ Do you have an appropriate balance of automated end-to-end system tests (a.k.a. “functional tests”) and automated unit tests?
☐ Is the team writing both system tests and unit tests in the same language as the system they’re developing? Collaboration is not enhanced by proprietary scripting languages or capture playback tools that only a subset of the team knows how to maintain.
☐ Has your team discovered the useful gray area between system tests and unit tests6?
☐ Does a continuous integration7 server automatically sound an alarm when someone causes a regression
failure? Can this feedback loop be reduced to hours or minutes? (“Daily builds are for wimps.” – Kent Beck)
☐ Do all tests roll up into the continuous integration server result?
☐ Have team members discovered the joy of continuous design and constant refactoring8, as an alternative to Big Up Front Design? Refactoring has a strict definition: changing internal structure without changing external behavior. Refactoring should occur several times per hour, whenever there is duplicate code, complex conditional logic (visible by excess indenting or long methods), poorly named identifiers, excessive coupling between objects, etc. Refactoring with confidence is only possible with automated test coverage. Neglecting
8 Martin Fowler, Refactoring: Improving the Design of Existing Code (1999).
Copyright © 2007-2016 Michael James. All Rights Reserved.
refactoring makes it hard to change the product in the future, especially since it’s hard to find good developers willing to work on bad code.
☐ Does your definition of “done” for each Product Backlog Item include full automated test coverage and refactoring? Learning Test Driven Development (TDD) increases the probability of achieving this.
☐ Are team members pair programming most of the time? Pair programming may dramatically increase code maintainability and reduce bug rates. It challenges people’s boundaries and sometimes seems to take longer (if we measure by lines of code rather than shippable functionality). Lead by example by initiating paired workdays with team members. Some of them will start to prefer working this way.

Part IV – How Is The Organization Doing?
☐ Is the appropriate amount of inter-team communication happening? “Scrum of Scrums” is only one way to achieve this, and rarely the best.9
☐ Are teams independently able to produce working features, even spanning architectural boundaries?10
☐ Are your ScrumMasters meeting with each other, working the organizational impediments list?
☐ When appropriate, are the organizational impediments pasted to the wall of the development director’s office? Can the cost be quantified in dollars, lost time to market, lost quality, or lost customer opportunities? (But
11 learnfromKenSchwaber’smistakes:“AdeadScrumMasterisauselessScrumMaster.” )
☐ Is your organization one of the few with career paths compatible with the collective goals of your teams? Answer “no” if there’s a career incentive12 to do programming or architecture work at the expense of testing, test automation, or user documentation.
☐ Has your organization been recognized by the trade press or other independent sources as one of the best places to work, or a leader in your industry?
☐ Are you creating a learning organization?
If you can check off most of these items and still have time left during the day, I’d like to hear from you.
There’s no canned formula for creating human ingenuity. This paper lists points which may, or may not, help in your situation.


Step #3 is CRUCIAL. You need someone who’s part of the team and bought-in to get any type of change/challenge to succeed. I have seen entire teams come around to a difficult idea just by one or two folks being completely bought-in and leading by positive example.


Thanks @Colleen!! I was hoping you would chime in since you’ve posted about Kanban before - do you have any good Kanban books/resources I can get my hands on that compare it to Scrum and the differences between the two?


This is basically the last page of Henrik’s book about Scrum and Kanban. .

<img src="/uploads/default/original/1X/d30240c8670d6142a816137763808a4e3a203f5d.png" width=“404” height="50


I would probably argue that prioritization is constant rather then optional. I do heart that you get to drop estimating and/or same-sizing items! To me this is the BIGGEST benefit of Kanban however getting the data that allows you to accurately predict delivery does require WIP limits. See Dan Vacanti’s Actionable Agile Metrics. Also check out Mike Burrows’ book Kanban from the Inside.


This is the buffet for cool metric sheets, Program modeling and the basis for my Flow based metrics.

@colleen Love Dan’s stuffs


Great Stuff. @MattMorgis, I love your dedication to the craft and continuous improvement. You have brought some good material to the table.

Getting back to your original question about scrum-ban, and getting rid of the sprint timebox…

I like what @andycleff said about how the timebox drives discipline from the PO. I would add it also creates a sense of urgency for the team, forces adoption of building quality in (Unit tests, automation, etc), and also provide that all important end date to stakeholders. We know they love that!

So I would ask you, are you still immature in any of these areas? @andycleff also mentioned that he was working with a Shu-Team. Shu teams should lean on the framework as much as possible to drive discipline and mindset shift. But mature teams need to adapt and experiment! It seems like you have a pretty mature team man, and you got them drinking the Koolaid:) So…why not “experiment” with Scrumban? You can always go back if it doesn’t work.

Mature teams with the discipline and agile mindset should have the freedom to explore other “practices.” There is a-lot of stuff out there from some really great thought leaders. I encourage mature teams to pick and choose what works for them. I think your team is in this position. You can only find out by experimenting, measuring, and learning.


I would Agree with the time box giving pos and teams the drive to get stuff done as mentioned by @mccallam2 and @andycleff.

I would argue thought at the heart of kanban is a metric of through put… Guess what there is a time box hidden right there. Using a refresh cadences for the teams initial step on there board of 2 weeks simulates the sprint planning. When you then slap the pos refine process up on the wall as an input to the teams cue… Makes it nice and visible of what everyone is doing and really makes the lead time to value right in your face.

I recommend Retros and demos at the trough put intervals.

Eventually with the flow based metric analysis the team can become a continuous value stream engine.


I’m not sure that a mobile team can become a continuous delivery engine, though.

Apple makes it tough. Gotta send cupertino an .ipa and wait a few days for approval.

You got that plus the internal QA regression testing.

And then on Android, while Google doesn’t put up their own approval gate, you’ve got dozens of hardware/os configs to regression test the teams apk against.

So there has to be a code freeze at some point, and QA cycles.

Anytime something else is merged in, QA needs to begin again.

I’d say press for more unit test coverage and automated testing suites within first.

Which to me still feels like Scrum…


@MattMorgis - David Anderson is the godfather of modern kanban practices. He has several books, but his blue book (like the Weezer album) is his pinnacle work. I am curious if @Colleen has other suggestions. One other thought - shell out some bones to see yours truly in his Lean Fundamentals course :stuck_out_tongue:


I came across this quick read this morning:


I’m excited that you dropped a Weezer reference into this thread, I cant find a sweater emoji to reply with! I’ve still got a few spots left for the getKanban game this Tuesday afternoon in Times Square, happy to pass on the comp code to make it free for AgileUprisers who would like to come!