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.

Evangelizing Scrum, or Anything, is Hard

Ever since I discovered lean/agile, I've been very perplexed about something. Why do so many people feel passionate, and sometimes offended, when I introduce it? Seriously, offended. Like I just called their baby ugly. I was taken-aback at first, now I'm used to it. I think I've learned to dodge most of the stones that people throw over the years.

Lean/agile begins with principles, with practices emerging from these principles (see previous blog post about agile principles).

I think a lot of blame (yes, I'm pointing fingers) comes from people who don't understand agile, then implement it...POORLY. I've heard so many horror stories about failed Scrum or Extreme Programming implementations. I've taught quite a few classes about agile/lean methods, and in every course, I ask the students if they've been involved in some kind of agile implementation. For everyone that said they had been involved, they said that it sucked...100% of the time. As they expanded on the sucky-ness, I just cringed. The leaders of the implementation just didn't get it. They didn't understand that it's about principles, not about index cards and stand-ups.

Now, let me relate this religion. I've been a Christian for close to 20 years. Every time I get into any kind of conversation (which I rarely start), people immediately become offended. Why? Because like the poorly executed agile implementations, there are many poorly executed "Christian" implementations.

As humans, it is so much easier to just follow rules than to rely on our own judgement. That's why empowerment is rejected so many times at the lowest level. If someone is empowered, then they are also accountable. Who wants THAT??

Christianity is not about rules. If anyone tells you that, then they need to go to Christianity 101 class. Christianity is about a relationship, and principles. If you follow the principles, the "practices" will follow.

Let's look at the greatest principles (commandments) given by Jesus "Love God with all your heart, soul, and mind", then "Love your neighbor as yourself".

What's interesting, is that if you take these to heart, then the 10 commandments (don't lie, murder, steal, etc.) will follow...right? The greatest principles will naturally manifest themselves in the 10 commandments.

If a Christian truly loved their neighbors as themselves, I think you would see a lot more philanthropy and a welcoming attitude towards others.

Here's the intro into the song "What if I Stumble" by DC Talk that summarizes my point beautifully:

The greatest single cause of atheism in the world today is Christians who acknowledge Jesus with their lips then walk out the door and deny him by their lifestyle. That is what an unbelieving world simply finds unbelievable.

Since in general, the "implementation" of Christianity has ignored the primary principles, the understanding from the non-Christian population is that Christians are ignorant, stupid, hypocritical, judgmental, and hateful. Are Christians doing anything to change this image? Not really.

So, when "evangelizing" given this climate, people become hostile and have a desire to throw (verbal) stones.

Now, back to agile/lean. Generally speaking, many folks believe agile is nothing but cowboy coding, no documentation, speed not quality, and screw "the business". When "evangelizing" given this climate, people become hostile and have a desire to throw (verbal) stones.

Evangelizing anything that is based on principles stirs emotion and is fraught with mis-understandings. Typically our first instinct is to run from the conflict that arises and just become complacent and accepting of dysfunction and misunderstanding. We need to be brave, and stand by our principles. In doing so, we need to continue to come up with ways to communicate the truth.

Talent is More Important than Tenure

Honestly...these are two different things.  They are unrelated.  First, I suppose definitions are in order.  I'm "tweaking" the standard dictionary definitions, by the way.

Tenure - Status gained by someone in a particular profession or discipline purely by practicing that profession or discipline for an extended period of time.

Talent - The ability to consistently deliver high quality results, continuously improve, lead, and maintain strong, healthy relationships through open and honest communication.

Whew, that was tough!

Let me first start with my own experience.

In the mid 90's, I decided to go back to college for computer science. I was 30 and knew nothing about computers. My wife actually had to teach me how to use a mouse. Ahhh, I can still hear her dear, sweet words ... "Double Click!!  NO!! NOT THAT FAST!!!!!".

So here I am, in the computer science graduate program (I had an undergraduate psychology degree) with a bunch of fresh-out-of-high-school computer geeks...and I just learned how to double click. I remember my first computer lab where we were learning C++, and the instructor told us to "open this file on the desktop, select all, copy, and paste in the IDE". Yeah, I had no idea what the hell he was talking about...copy? paste? huh? Someone took pity on me and helped me out. Whew.

Fast forward two years. During those two years, I rarely slept, read everything I could get my hands on, took on web programming side jobs that I was in no way qualified to handle, and ultimately caught up to (and surpassed some of) the fresh-out-of-high-school computer geeks. I loved this stuff. I actually ended up administering those same computer labs where I originally had to have help copying and pasting. I LOVED Linux. I LOVED open source. Heck, I even kinda liked windows stuff back then :-)

Here we are, at the height of the dot-com boom. I saw so many people graduate that I felt had average (at best) software engineering skills getting high paying jobs. I, on the other hand, was still attending classes, living in a two bedroom apartment with my three small kids, and riding my bicycle to campus. I was really, really tired of living on student loans and not being able to afford ANYTHING. So, I decided to see what I could find, even though I didn't have my Master's degree yet. I was a much better programmer and engineer than most people that I knew that graduated after all...this should be EASY!

My resume displayed about one and a half years of "real" work...which was actually a bit exaggerated...but dangit...I KNEW I could take on any programming job!

To my surprise, I couldn't even get my foot in the door. If I did get an interview, it always ended up with "yeah, you just don't have enough experience". ARGHH. I didn't have the tenure, but I knew I had the talent!!

Months went by, and I finally landed a cold fusion programming gig...my first introduction to Dilbert-land. It was a great experience.

Now, fast forward another year. The dot-com bust. I was laid off with about 50 others.

Back to the job hunt. Well, evidently that one additional year of "experience", i.e. "tenure" didn't mean anything. Again, I got the "yeah, you just don't have enough experience".

Finally, I interviewed with someone that for some reason, trusted me. He was looking for talent, and didn't care so much about tenure.

That was an amazing experience. He gave me a chance. It proved to be mutually beneficial for me personally and professionally, and for the company. We were eventually acquired by Intuit, which was another great experience. The funny thing is that Intuit would have NEVER hired me directly since I didn't have the tenure!

Fast forward to present day. I'm currently a manager, responsible for a project management group. One thing that I've found out is that hiring for talent is HARD. Hiring for tenure is EASY. I find myself looking over resumes thinking "wow, they have a bagillion years of experience, they must have talent!".

So, I understand now why those hiring appear to prefer tenure over talent. It's because it's so hard to determine if someone HAS talent before you hire them.

I'm not saying that tenure means "nothing". It does. With NO tenure, success is unlikely. However, focus on talent. A truly talented person will of course have some tenure.

Hiring for talent is hard. Take your time, be creative. Don't assume that just because someone has years and years of "experience" that they are automatically talented...you will regret it if you do.

Agile - It's All About the Principles

I've been talking with a lot of folks lately that claim to have been working with Agile for a long time.  When I talk with them, they boil agile down to a few things such as; delivering faster, iterations, and stand-ups.

What troubles me is that very few people talk about the principles.  I like focus on the principles first, and look at the practices (retrospectives, stand-ups, iterations, etc.) as "how" to bring those principles to the forefront of everyone's mind.

You aren't "doing agile" because you put index cards on a wall, or because you stand up for 15 minutes a day in a meeting, or even if you have iterations.  Practices without focus on the principles will get you nowhere.

As teams inspect and adapt, new practices will emerge.  As these new practices emerge, we need to do our best to make sure they don't impede the agile principles, which are honestly good principles no matter what approach is used.

Just in Time or Just in Case?

A huge form of waste that many people don't talk about are those things that are built "just in case" we might need them some day.

I think that those involved in building a product often times forget that everything that is built costs something.  Nothing is free.  Who's paying for it?  The customer is.  Everything we do must deliver some kind of business value, either by reducing risk, meeting compliance, cutting costs, increasing revenue, etc.

There are certain phrases that I listen for like "it would be cool if...", "someday we  might want to...", etc.  Some tend to want to build to accommodate edge cases that are (many times) so ridiculous that they would never happen.  Now what gets really tricky is when there is only one SME in the product group, and no one else really knows that domain.  In those cases, God help you!  That SME has the power to make you do things that you look back on and say "WHAT HAVE WE DONE?!?!?".  The only way to get around this is to fearlessly and relentlessly ask "why?".  In these situations, there is typically a touch of fear that compels the team to bow down and say "yes master, whatever you wish" instead of asking probing questions.

There are some Scrum Masters (and Project Managers) that typically stay out of those kinds of details.  Yes, the team is self-organizing.  Yes, the team has to learn by making mistakes.  However, the Scrum Master has to be involved enough to not allow the "just in case" methodology from taking hold.  If it's allowed to go on too long, you will have found out that what you have delivered in the end is not what is  valuable now.