Process is Not a Four Letter Word

I grew up as an only child.  I had no brothers or sisters to "share" anything with.  It was all MINE.  When I became a teenager, I completely rebelled against all authority.  This probably had something to do with my only child-ness, but probably had more to do with me being a spoiled jerk.

I hated all authority...teachers, parents, pastors, police, you name it.  How dare they tell me what to do!  I felt that their only purpose was to make sure everyone followed arbitrary rules that MADE NO SENSE, and they were determined to make my life hell.

As the years went by, I calmed down, settled down and became a family man.  But, I don't think I've ever shaken off that old "to hell with authority" attitude.  I've just learned to live with it :-)

I think this is one of the reasons that I fell in love with Scrum, and agile in general.  It had that familiar aroma of my old days of rebellion.  Agile ideas came about really out of necessity and a spirit of rebellion.  There were arbitrary rules that were imposed on organizations about how to build software that MADE NO SENSE!  So, how about we rebel, and do things OUR way, i.e. the way that makes sense.

Now, let's consider the word "process".  Over the last several days I've realized the profound effect this word has on people.  People immediately cringe.  For some reason, the word "process" paints a picture of arbitrary rules that MAKE NO SENSE that we have to follow.  It implies bureaucracy and micro-management.

Now, let's set something straight.  "Process" is critical to the success of any endeavor.  If you let the process "evolve" without paying attention to it, it will cause chaos.  One thing that people don't understand is that a process always exists, whether it's documented or not.  It may feel like "free-style", but it's a process.

I've been involved in some conversations recently about role definition.  This is a classic problem that plagues every company...not having a clear definition of roles.  Here is the problem; without a clear understanding of a PROCESS, you will never be able to clearly define ROLES.  The first thing that should happen is to clearly define what the process is in how to deliver software (or anything).  I'm not talking about creating artifacts.  Documentation does not equal process.  It supports the process, and may be a by-product of the process, but documentation alone is not the process.  But be careful.  I've seen to many times a "process" created that people end up slavishly following without ever even attempting to improve it.  A process must evolve along with the changing culture, technology, and business needs.

To some extent, Scrum practitioners discourage defining processes.  It appears to me that maybe this whole "stick it to the man" gets a little too out of hand...even for me!

If you don't control the process, the process will control you, and it won't be a good thing.

Scrum Alone is Not Sufficient

There are some who believe that Scrum alone is sufficient to run complex, big, expensive, scary projects and/or programs.  Some people think that Scrum instructs us how to code. It does not.  It provides a framework and a set of principles (as does any sound agile methodology) on which to base our development and delivery practices and processes.  The only way that Scrum is sufficient alone is if the teams are completely self-organizing, highly skilled and efficient, the business has a clear, sound vision that is clearly understood and communicated, and the management fully supports the efforts put forth by the team.  I have never experienced nor have a heard of a company that attained this utopia.

Let's talk about the real world.  Most developers are average at best, there are politics, hidden agendas, attitudes, kingdoms, and lots of other "stuff" that prevents this paradise.  Since that's the case, you can't be done at Scrum.

The Scrum framework provides guidance regarding key roles (Scrum Master, Product Owner, Team), ceremonies (sprint planning, daily scrum, retrospective, sprint review) and artifacts (product backlog, sprint backlog).  It provides no other guidance.  In Scrum, "the team" decides how to handle things.  How do we manage requirements?  The team decides.  How do we handle vendor relationships?  Let the team decide.  How do we make sure we are compliant?  Let the team decide.  I think you get the picture.

Below are some things that Scrum does not address.

• How to code
• How to test
• How to manage code
• How to manage risks
• How to document and manage requirements
• How to manage the budget
• How to estimate
• How to decide whether to build or buy
• How to deploy into production
• How to operationalize the product
• How to train new users on the product
• and the list goes on and on and on

My point is this...if you are successfully doing Scrum alone, good job.  But it's not enough (unless you have achieved utopia).  The team likely will not have the knowledge or experience necessary to decide how to do EVERYTHING.  Now you need to take that next step.  Bring in CI and TDD.  Start measuring your productivity by bringing in some lean/six-sigma tools so you can better improve.  Heck, I think there's even some stuff in the PMBOK that is pretty useful!

How Many Scrum Projects Can a Developer Be On?

This post was inspired from a question that was asked on the scrumdevelopment yahoo user group.  The question was regarding several things.  First, how to handle a developer on multiple Scrum projects, second how to sync the sprints, and third what tools can be used to handle the multiple projects.  I'm addressing the first and second aspects, and not the third about the tools.

Having developers on multiple projects is a very common thing. It is the wrong thing.  If the project solutions have to integrate eventually, then it makes more sense...but in that case, the developers on multiple projects should be used in a different capacity. More leadership and guidance and less actual coding.

If developers are on multiple projects and the projects are unrelated, you'll have to stagger the sprints, i.e. they shouldn't start and end on the same day. Imagine developers having to attend 3 sprint planning sessions in one day, 3 retrospectives in one day, 3 standups in one day. I tried that once with 4 projects...yeah it sucked. Developers on the teams were doing nothing but attending meetings. Their first impression of Scrum was "meeting hell". Plus, you can only be in one place at once, so some of the projects suffered due to lack of attendance.

If the projects have to integrate, the sprints should sync up, as the goal is potentially shippable software...and you can't ship unless you integrate.

Either way, it is bad to have developers on more than one..."maybe" two projects. The cost of context switching is too high. I know it sounds impossible to have developers on only one project, but if you make it happen, you will not regret it. It's just scary because we've been trained that "multi-tasking is good". That is a big fat lie.