Continuous Workflows and ways of working

Kanban? Be careful...

Times they are a changin...

You may want to skip straight to the summary for a few key observations, the rest of the article is an anecdotal walkthrough of transitioning from SCRUM to Kanban and some of the problems experienced.

My last post was in January this year regarding some TDD exercises I had undertaken, however I have actually been more involved in helping run our dev team for around 2 years in my first lead role for quite some years.  Lead roles where I work are far from strictly technical and I have seen myself - not with the greatest expertise it has to be said - performing BA/PO, SA, and ADM(aka SCRUM master) type responsibilities with a little bit of time left to do the thing I enjoy most. I am writing this with a ruffled SCRUM master hat on.  Unlike a famous beer I am probably the worlds worst SCRUM master (Well, maybe not that bad.. but I guess I am saying its not really an area I truly feel I can excel in - its more than just the SCRUM master certification you know...)

Our team underwent a lot of change mid-pandemic when Agile Delivery Managers (basically SCRUM masters) were rudely turfed out of our organisation and our team personnel changed significantly at the same time to boot.

Using the  SCRUM framework was the well defined, and at one point, only way of helping organise work in our organisation and by extension our team.    

The organisational transition brought with it the chance to start thinking about how we, as a team,  were working and assessing if we could (or should) change to a continuous workflow. 

This was not without some considerable debate and discussions about how to ease into a  continuous workflow way of working.  Some colleagues were vehemently opposed to moving to a new style of working suggesting that  without exhaustive metrics and data to back up our need to change, we shouldn't, but also that we should make sure we were "doing" SCRUM properly first - these aren't entirely unreasonable asks, it would seem.

My manager wasn't quite as strongly against change, and ultimately supported our transition,  but stated that the preference would be to use data to prompt the need to change. 

My "opinion" was that even if we were a bit rash moving, setting ourselves up properly in our new system upon transition didn't mean we were being negligent or irrational (avant-garde trendsetter? I think not, more like hit and hope maybe!)

Noting these opinions and taking a team vote and discussing within our team, each members maturity with Agile methodologies generally and with a view to potentially moving away from the SCRUM framework (with an absence of true empiricism (violations all over the shop eh?) we decided to continue to forge ahead with little supporting data , our lead and cycle times and what this meant were generally understood,  but we were driven by slightly different expectations and wants (more in a minute on this).  

After studying both the SCRUM master course and KMP-1 course and bouyed by the chance to try Kanban, me and the team designed our new workflow and signboard, which represented the way we worked, and slowly but surely started to transition to using it and bumbling our way to using WIP and pre-conditions/gating to move between stages in our workflow and shouting out "pull from the left...." at stand up!

The board on its own, has generally worked well.  The signboard is clear with relevant columns, WIP which has been tweaked once or twice, swimlanes for classes of work and inspection points for entry to and from work columns. We took our time moving over from the sprint board to the sign board, but this is our main view point of the flow of work now. The specifics are kept confined to the sprint board (a level down effectively) . 

Agile without the ceremonies

Some would hope so! Kanban, isn't actually about this. The nub of it is to visualise pinch points and be able to identify them and get things unpinched as quickly as possible.  The nuances come in defining the policies correctly using math and little's law to help define WIP (5 will do + 1 thanks mate...) and quickly inspecting and adapting. Everything that is done in SCRUM but just more loosely defined

A key part of Kanban teaching I undertook was what to do around pinch points.  In effect retros and meetings often left to the end of a sprint with SCRUM are encouraged to take place as and when needed, there is no mandate for this but as there is no stipulation it makes sense to reflect on a problem when it arises to drive in improvements to help fix processes and get stuff moving.

SCRUM is opinionated about  stand ups, retros, reviews, backlog refinement, sprint goals etc, sprints and their timeboxing .  Kanban seems less opinionated but shares standups and a signboard is about the only real stipulation I can remember.

What I personally like about SCRUM is the stipulation of a fixed amount of time within which to do some work, the sprint.  When it is done, review and reflection (via a retro) occurs and then the cycle starts again.  Coming from a previous employer where we lived in chaos this was very welcome.

Kanban (although we still use iterations due to our sign board technology)  does seem to (or have the potential to) lead to a never ending cycle, coupled with - in our current spin on this - with fewer inspection points - the strain of this continuity can be felt within the team. 

Working within SCRUM didn't feel like this. At the end of each sprint - however insignificant the break is to some - I felt it keenly and the break allowed me to psychologically reset.  Also a new sprint is a great time to ask questions about why stories are not closed off or a sprint goal has not been met. Not with a view to persecuting the team, but with a view to making things more effective, inspecting and adapting to overcome problems and waste. 

Is it a load of faff?

At its simplest, basically getting some post it notes up on the board saying what you are doing now and next is all well and good, but the benefits of inspecting a process and impediments and issues must continue thoroughly as otherwise weariness can set in and the perception of not being able to perform correcting action for problems actually becomes  manifest and apathy ( I am guilty of this myself)  sets in.

I have reflected on Agile generally , SCRUM and Kanban and pondered, what's the point?  

Using SCRUM properly at the beginning of my current tenure, we had great focus and a sense of empowerment (bordering on pride) about our sprints.  

This has all but evaporated and it seems, we are now on one long slog with unclear goals and focus, and that is not to say we are not getting work done, we definitely are, but it feels like a grind.  

Kanban and a continuous workflow is not to blame for this entirely, working from home, Teams meetings, the Pandemic and long running features which have crept in scope are almost definitely major contributors here too. 

I have observed that the perception of some of the ceremonies and activities within SCRUM are seen as wasteful and not valuable (and, for me, some of this is a fair observation in OUR organisation, some of the ceremonies have definitely not been that effective (we have big long multi team reviews which, for me, are astronomically wasteful - we are talking £10k's of pounds worth of wasteful when you consider the number and time of the people involved)  , however I think if taken seriously and used as a guide there is value to having something to guide you, working out how to make various parts effective is something else again.   

I guess I am kind of thinking of a journey; going full circle from a pretty strict usage of the SCRUM framework to a very relaxed Kanban process  losing some clarity and then considering going back to SCRUM to get control. 

Back to SCRUM?

Writing this post today, I was wondering whether I would emerge with  some ideas about the current state of play and how to improve it.  Moving back to SCRUM and not being empirically  guided may still be a bit negligent.  As part of moving to Kanban I did actually create dashboards to capture key metrics (as mentioned above) I looked the other day at some, was shocked, and quickly closed the board (I am joking but regular  inspection of this has gone by the wayside too) 

Story sizes, whilst I am thinking about the current state of play, should really be pretty small and fast moving on a Kanban board,  we aren't there and our cycle time is atrocious for all sizes of stories.

Our work at the moment doesn't lend itself to a disciplined backlog of small similar sized items ready to be committed to, and being closer to operations than some teams we feel the brunt of lots of expedited stories, still classified as such, but nevertheless contributing to unclear focus at times.  

The answer to the sub-heading is no, probably not at the moment, but we might need to do something.

In Summary

So after all that rambling where was I going.  The key things I'd consider are:

• Can you get any more out of your current workflow framework, can you tweak some of the ceremonies, things you deem to have more value before changing tack
• If your lead time and cycle times are decent, and you can give confident landing zones for work coming your way, do you even need to consider changing. If you don't know the answer to the former then you cant possibly know the answer to the latter, some will say - "most definitely not"
• Are you moving framework to get away from some of the things you dislike. If there is a loss of inspection and adaptation as a result of the move, you may end up becoming less agile
• What type of work are you doing?  Although SCRUM is cited as being able to deal with projects of complexity and uncertainty (complex and adaptive), arguably a little less uncertainty may be more suitable for SCRUM in my opinion 
• Moving to Kanban -  to make it as effective as possible, apparently,  you want to get your stories as similar a size as possible. Is your backlog truly "dimensionable" like this.  If sizes vary, is SCRUM still more effective? (I don't know to be honest, I do know estimation is still a desirable attribute in both and after calibration story sizes should be relative in SCRUM) So if you move to Kanban and you have stories of different sizes how can WIP be worked out effectively (I think its harder) )
• Are you doing it just for a change? Might work out...Probably want a bit more to it than that...
• Are you running away from the things you don't like (I am guilty of this to an extent)  Can you truly get some of the things you don't like changed or improved  - have you asked or challenged the status Quo  (75 person reviews...anyone...yawn yawn yawn)

I started repeating myself at the end and had to stop for my sanity...I will refer to this as a reminder next time I am involved in a switcharoo somewhere it might make me think twice...