Distraction in Parallel

• Posted by dan on June 10, 2013
• 0 comments

We recently had a retrospective and one of the things we wanted to continue was focusing on a small number of things. B24C9J3NU5UG

The Status Quo

At the moment our board has the usual columns todo, in progress, out and done.

There is no verify as it's not ready to go out if it doesn't have tests and we release the story as soon as possible after it goes into out. We have some rules around no Friday deploys and no deploying after 4pm but for the most part it works really well.

Deploying boils down to clicking a button in TeamCity and watching a progress bar and then critically the tests pass.

Don't Cross the Streams

My grudge is that we currently have 2 streams of work in play simultaneously.  These aren't just 2 stories  on the same theme they're from completely different projects.

I've been reading a few books on lean thinking, I even wrote a post about The Phoenix Project and The Goal. In both of those books early on chaos reigns, it's only later in the books that they start to focus on throughput.

What I noted was that they concentrated on delivering a single product right through the company (single piece flow). This makes me think we shouldn't have 2 distinct features going in parallel, when we switch pairs the context switch is dramatic. We often talk about an issue only to be told by a colleague that that's the other project. I think that observation on its own adequately portrays the pain of 2 simultaneous work streams.

Divide and Conquer

Where I become unsure is when you say OK split the team into 2 distinct teams of 2 people. I won't go below 2 people for qualities sake and my own sanity. In theory this should work but there's a problem. If we assume both features are each made up multiple tasks even stories, Would we be better off having both pairs work on different tasks but on the same project. There seems to be a natural aversion to this as it will be on the same codebase. I often get told we'll be treading in each others feet, but we all know Git is fairly good at sorting these issues out, the only thing it would encourage in my mind is more regular commits and pushes which doesn't sound like a bad thing.

Road maps and Milestones

I'm currently working with a different team and they have a similar position. They have 4 road maps that are essentially categories of work eg:user facing and technical. It does seem however aside from my pair the other 2 pairs are working on the same feature (here I am working against my own ideal).

It's not how many things you start, it's how many you finish

At the higher level this is 1 team with 4 road maps and if you assume they're not the only team like that it starts to get confusing. Imagine 6 teams each with 2 projects on the go at once, we'd have 12 projects running simultaneously. You might hope that if you start 12 things simultaneously that you might then finish them all in a similar time frame. Or maybe not, some things take longer than others but the more common thing is for something to be bottlenecked by an "external" (well external to the team) bottleneck. The Goal would say identify the bottleneck and subordinate everything else to it, or we might try and swarm around the bottleneck and remove it. The temptation I often have though and we regularly yield to is to just start something else because the bottleneck is out of our control. The problem is of course that we end up spinning even more plates and it all comes crashing down as we can't cope with that many things at once.

What do others think?

So this is my thinking but I'm really curious as to what other people think on this topic. Why are we affraid of treading on each others toes, is it better to give everyone a small increment of lots of things or complete one thing, please comment and share your thoughts.

The Phoenix Project, The Goal and the Theory Of Constraints

• Posted by dan on May 20, 2013
• 1 comments

I've recently been engrossed in reading The Phoenix Project and then subsequently The Goal. I've been learning through a novel medium all about the Theory of Constraints (TOC). About the 4 types of work. The Phoenix Project opens with the character Bill being thrust into a more senior position as the head of IT Ops, this is a promotion he neither expected nor wanted. He's tossed head first into the deep end of a raging inferno where immediately he has to start firefighting. The paralellels to some of my own experiences are scary. I can more-or-less look back on those times knowing we've progressed, but still the story is uncomfortably familiar. The Phoenix Project unveils the theory of contraints as does The Goal, with the now famous 5 framing questions:

1. Identify the system's constraint(s)
2. Decide how to exploit the system's constraint(s) (how to get the most out of the constraint)
3. Subordinate everything else to the above decision (align the whole system or organization to support the decision made above)
4. Elevate the system's constraint(s) (make other major changes needed to increase the constraint's capacity)
5. Warning! If in the previous steps a constraint has been broken, go back to step 1, but do not allow inertia to cause a system's constraint.

1. Business Projects
2. IT Operations Projects
3. Changes
4. Unplanned Work

I'd highly recommend reading both of these books, whilst reading them I started to just try and make some sort of sense out of the way my team deliver software. Of note was the notion of having a broader view of a whole systems (Systems Thinking I guess) and thinking in terms of The Goal (in that books case it was to make money, a goal shared by many companies I'm guessing). They talked about single piece flow through the system and that you can be as efficient as you like in any one area of a system but it's the bottleneck that ultimately decides your companies ability to deliver value. Towards the end of the Phoenix Project there's a nod to Continuous Delivery, we see our hereos utilise 'the cloud' the do some number crunching in an on-demand manner. You'll read this book and start questioning the way you work, the way your company generates projects and requirements. There's an additional nod to Eric Ries' Lean Startup with regard to validating ideas.

There's a very poignant bit for me at least, where the characters in the Phoenix Project actually talk to the CFO. The CFO has a slide that contains points along the following:

• Are we competitive
• Do we know what to build.
• Do we have the right products
• Can we build it effectively
• Can we ship it soon enough.
• etc

The thing for me was that the characters has actually broken outside of their IT bubble and started to talk to other areas of the busines and critically try to understand what the CFO's perspective. I've been interviewing people around my company, I even wrote a post about it in What The Customer Cares About and It made me think this somewhat justified my thinking.

A final point for thought

Right towards the end of the book there's a quote from the CEO where he describes who our protagonist has helped open his eyes so to speak the paraphrase is:

"You've helped me see that IT is not merely a department. Instead, it's a skill like being able to read or do math. Here at Parts Unlimited we don't have a centralized reading or math department--we expect everyone we hire to have some mastery of it. Understanding what technology can and can't do has become a core competency that every part of this business must have."

One thought that I keep coming back to of late is whether we would be better off re-organising companies so technology is baked into every part of the business. Every department from Marketing to Sales is probably trying to get some project prioritised by technology in order to help them achieve their goal. What would happen if we removed the constraint that is IT by building it directly into the various departments? It might be that departments are the wrong thing to center around prehaps every product we sell or service we offer should have a dedicated contingent, formed of Sales, Marketing and IT people a truly cross-functional team that can deliver real customer value. Maybe that's going to far, but I'd like to experiment and give it a go. 

Overall I can't recommend reading this enough, if you're trying to gain a better perspective on where you and your team and ulimately your company are, these books can certainly give you some perspective whilst also doubling as an entertaining read suitible for perusing on holiday by the pool, enoy and thanks.

Dan