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.

The Role of the Architect in Scrum

This question comes up over an over, so I thought I'd address it quickly.

Remember that in an ideal Scrum team, the team is completely self organizing.  There are no titles to worry about.  The team will discover the strengths and weaknesses of each member, and continuously evolve, i.e. inspect and adapt, to discover new ways of delivering high quality value to the business.

But, guess what.  In the real world, we have titles to deal with.  Now, I don't think that's such a bad thing.

As we all know, the title "Architect" in the context of software means very different things given the organization.  I've seen it range from really good coder to more of a project manager-y type of position.  I think this lack of clear role in the industry overall has lead the folks in this title to, at times, become "chickens" that like to cluck and flap their wings to distract the team.

So, what should the architect do?  Well, let's remember that in Scrum, team are self organizing.  They collectively come up with the technical solutions.  They also come up with development standards.  If the team is generally not high performing, or are missing some necessary skills, then the architect should be a mentor and a coach for that team until they can fly on their own.

What if the teams are high performing?  If there is an organizational need due to a highly complex business need, i.e. insurance, taxes, financial transactions, etc., then the architect should focus on the high level roadmap to ensure that the backbone of the technology is strong.  This is especially true in a SOA environment.

Creating the Sprint Backlog in New Scrum Teams

If you're new to Scrum, here is something you need to know about teams first trying it out...ready??

...drumroll...

The team doesn't know what they need to do

There, I said it. Whew, glad I got that off my chest.

In Scrum, we ask team members to break product backlog items (typically stories), into tasks that take 16 hours or less to complete. You will find that, most of the time, the team will have incredible difficulty in doing this, and they will likely come up with tasks such as "analyze, code, test". Bleh. Those are B.S. tasks that really don't mean anything. It's hard to define "DONE" for those types of tasks. You may have to accept those tasks in the beginning, but it is your responsibility as a Scrum Master to coach the team into creatively thinking through task definition.

Here are some reasons I think teams may have a hard time defining tasks.  It is best to look at all of these as impediments, and your job as a Scrum Master is to remove them.

• Lack of Empowerment
  Teams under the tyranny of "traditional" development are rarely empowered. They are used to being told what to do. While creating solutions, team members will actually do what needs to be done and then move on to the next thing. The problem is that they've never had to articulate the steps they take to complete what they need to complete.  And, to top it off, managers rarely understand what it "really" takes to deliver a solution.
  
  This will not be a quick fix.  You will have to work with leadership and come up with a strategic plan on how to empower people.  In the meantime, even though you tell the team "your empowered', if the rest of the organization does not support it, there will be constant struggle.  However, as a leader, it is your job to work both sides of the fence, i.e the team and the organization.

• Fear
  In an extreme command-and-control environment, people lose all common sense. They are not confident making any decisions, let alone actually thinking for themselves.
  
  Here, the team will need lots of praise and protection.  If they know that you have their back, they will, over time, come out of their shells.

• Lack of Knowledge or Skills
  
  If the team is new to that domain, or the team just does not have the skills, i.e. a Cobol programmer "trying out" Java development, there is no way they can effectively decompose stories into tasks.
  
  This is one of the toughest situations to deal with.  If the team is just the wrong team, the only thing that can be done is to escalate this impediment to leadership.  This one is particularly hard because I guarantee that there will be others who think some of those on the team DO have the knowledge and skills, likely because those folks are "well liked" or popular.  Just remember to be honest always, and over time, change will happen.

• "The Dominator"
  
  Sometimes there is one person on the team who holds the key. They know the domain, they know the technology. No one else does. THEY are the ones who define the tasks. If the tasks aren't good enough, who cares, as long as "The Dominator" is okay with them. This is a tricky one. It is your responsibility to either a) get them off the team or b) clearly set the expectations and time-box the needed change in behavior.
  

If you are a Scrum Master or coach on this team and you don't have "tribal" knowledge, it will be a true test of your patience.

But, hope is not lost! A while ago, I was in this situation. I was in a sprint planning session, and I saw the familiar signs emerging..."Ummm...yeah...we need to analyze". "Oh, I suppose we need to code too". UGH. I was helpless. Luckily, there was a strong technical lead attending that understood the domain and technology. He patiently walked the team through the decomposition of the stories into "real" tasks. It was a real humbling experience for me. I thought I could get ANY team to decompose stories into meaningful tasks. Boy, was I wrong.

So, if you're in this situation, determine the "root cause" of why the team can't decompose stories into meaningful tasks. If it's an impediment, handle the impediment. If it's because you are lacking the knowledge necessary to coach the team, find someone there who can.