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.

Bringing Agile to the Organization

Almost all of the literature out there recommends the first step being finding a "pilot" project where you can use an agile methodology.  The project can't be too complex, too simple, too large, too small, too critical, or too unimportant. 

I'm starting to wonder if we're over-thinking this.  Why don't we decide what to use depending on the project?  If RUP fits REALLY well, then why don't we use that?  If Scrum fits REALLY well, then we should have the option of using that...right? 

In reality, the only thing that will ever hold back a true agile adoption on a project or an organization is the culture.  And, the other reality is that most organizations have a culture that does not support an agile framework.

But, how do we change the culture?  Do we change the process first and hope the culture changes with it?  Or, do we try to change the culture ahead of a process change?

At my current place of employment, agile methodologies are accepted, along with any methodology that makes sense.  There isn't a "corporate" methodology.  I really like that.  Imagine if a company was by-the-book Scrum.  No other options.  Imagine having to beg for permission to "pilot" Kanban...ugh.

My point is this...maybe we should stop the notion of "piloting" Scrum, or Extreme Programming with the intention of rolling it out and making it the "approved" delivery methodology.  Maybe we should instead focus on sound principles that we know are true, universal, and also happen to be highly valued in agile and lean.  Principles such as:

• The primary measure of progress is working software
• Business and IT working together daily
• Face to face communication
• Reducing waste
• Building quality in
• Delivering as fast as possible
• Delivering working software frequently
• Self-organizing teams
• Welcome change
• Sustainable development
• Technical excellence
• Keeping it simple
• Continuously improving the process

 As long as we let these principles drive our process, and people are empowered and allowed to make mistakes which will in turn promote learning, the process will work.

The Cross Functional Team vs. the Functional Community

An agile team consists of everyone it takes to deliver value to the customer.  The typical team consists of analysts, developers,  and testers. Of course the team is not limited to these roles.  The team could also include technical documenters, DBAs, or whoever else has a hand in creating value.

In traditional organizations, "team" is defined as a functional group.  The development "team", the "testing" team, the "analyst" team, etc.  This makes sense in a traditional, waterfall-ish environment.

In an agile, cross-functional environment, it is not helpful to define "teams" around functions.  Okay, "maybe" its okay in a production support capacity, but that's still pushing it as there will still need to be cross-functional work with production support.

Teams have a common, unified goal. Functional "teams" do not.  For example, a functional "team" that consists of a dozen Java programmers, with each programmer on a different project, can hardly be called a "team".  They have no common goal, other than to adhere to the (hopefully) high development standards that have been put in place.

I propose that instead of calling these functional groups "teams", we call them communities.  Here's a simple definition of community that I found on dictionary.com: "A group of people having common interests".  The Java "community" will work together to make sure that they have common standards of excellence, share knowledge and experiences, and provide each other guidance as needed.  However, these people will have different goals, depending on the project on which they have been assigned.

Up Front & Iterative Planning

You know the question..."what kind of projects are best suited for agile?".  To me, this is the same as asking "what kind of projects are best suited for empowered teams, technical excellence, servant leadership, reducing waste?".  Would there ever be a time when you would not want these things?  I know, that is a very smart-allec response, but I just can't help myself.

I then ask "what's the other option?".  This surprisingly stumps people when I ask this.  We all know there is no such thing as "true" waterfall in software.  So, to help them along, I clarify what I "think" they are asking which is "what kinds of projects are best suited for big, upfront planning and design vs. iterative & incremental delivery?".  People almost always agree with the restatement of the question.

I believe that everything can and must be done iteratively and incrementally in software.  However, the level of "up front" may change with the type of project.  Gutting out an old accounting system and replacing it with an Oracle or Great Plains solution will require more up-front planning and analysis than a green-field Web 2.0 social networking application.

So, fellow agilists, "up-front" is not a bad word, it has to be done.  We know this already with release planning, and even sprint planning, we just don't call it "up-front".  Just be careful...VERY careful.  You run the risk digressing into waterfall.  At times, there will need to be more "up-front" than other times.  Always be asking yourself, "what is the soonest we can deliver value to customer?".

Sweet Exercise to Teach Empowerment and Self-Organization

I taught a one day agile course to a group of IS leaders. I wanted to come up with an exercise that illustrated that to be efficient, you have to reduce hand-offs, allow teams to self-organize, and leaders must be servants.

So, with my wife, we came up with "Project Pinwheel". Below is how it works.

Supplies

• Straws
• Paper fasteners
• Paper copies of the pinwheel pattern to cut out
• Scissors
• Markers
• Paper punch
• Shoe-box size plastic containers (to hold the supplies at each table)

Process

This is the process that I used. Feel free to change it to suite your needs.

At each table, there were 5-6 students. Each plastic shoe-box contained enough supplies for 20 pinwheels (would need less most likely). Also, make sure that you make samples of what the pinwheels are supposed to look like for each group.

There are two rounds. Below are the slides I showed to the class for each round.

Round 1

[slide 1]

Your job is to create as many pinwheels as you can in 5 minutes. Take a minute, and assign the following roles at each table:

• Cutter - owns the scissors and completes the cutting
• Decorator/Designer - owns the markers and creates the design for the pinwheel
• Hole Puncher & Paper Fastener - owns the hole puncher and the paper fasteners
• Folder - does any necessary manipulation or folding of the paper during the creation of the pinwheel
• Tester - tests the pinwheel when it has been finished. Verify that it has been decorated and that it at least moves a little when someone blows.
• Manager - responsible for telling each team member what to do. The manager will communicate the tasks to the team members. The team members are not allowed to see the instructions.

[slide 2]

• At your table there is a box. Each box contains the instructions and the supplies.
• No one is allowed to step outside their role.
• The manager is the only one that can speak, by instructing the team members. Each team member is only allowed to speak to the manager.
• If the pinwheel fails testing, the tester must hand the pinwheel back to who they think caused the “bug”.

At this point, the teams DO NOT see the sample. They don't even know it exists.

Now, start the timer. After 5 minutes, they will likely create 0 pinwheels.

Round 2

[Slide for round 2]

• Manager, you are now a servant leader. Please do whatever it takes to help the team.
• Team members are allowed to help others out.
• You can cross role boundaries.
• Everyone can read the instructions. You can use the instructions as a guideline, but you can now be creative in how you create the pinwheels.
• First, take 2 minutes to discuss how you will work together to be more efficient. Then, you will have 5 minutes to create as many pinwheels as possible.

Here, the team goes through a time-boxed planning session of 2 minutes to figure out how to best make the pinwheels before the 5 minute pin-wheel making session. Oh, I also pull out the sample pinwheel, so the team can have a collective understanding of what the "vision" is.

During my first session, each team made between 5-10 pinwheels. The ones who made less had issues with the "servant leader" thing, which made for a great discussion afterwords.

This is a bit of a pain in the butt to set up, but in the end, it is WELL worth it, and now I have the supplies for many classes to come!

Below is the instruction sheet that each team used.

Project Pinwheel Instructions

1. Cut-out the pinwheel on the solid lines only.
2. Decorate both sides of the paper pinwheel.

3. Cut the dotted lines from the four corners to the center circle. Try not to cut into the center circle.
4. Use the hole punch to poke a hole through the four tiny dark circles. Use the hole punch to poke a hole through the straw about 1/2 inch from the top.

5. Hole punch the middle of the center circle on the paper pinwheel where the dotted lines converge.

6. Make the holes on the four points meet at the center circle.

7. Push the ends of the paper fastener through the holes on the pinwheel. Then push the fastener through the center circle.

8. Place the straw on the back side of your pinwheel and push the ends of the fastener through the hole in the straw. Open-up the fastener by flattening the ends in opposite directions.

9. Test the pinwheel to ensure it is functional. If the pinwheel is not functional, determine which step you need to send it back to in order to gain functionality. Repeat testing again until pinwheel is “complete”.

Only decorated, functional pinwheels that can at least minimally move when blown can be counted as “complete”.

Below is the image to cut-out to make the pin-wheel.  You can also find the image just by searching for "pinwheel pattern" on google.

The quest for the perfect agile tool

I've been searching off and on for the perfect agile tool for years. My "dream" tool would be a one stop shop for releases, stories, tasks, acceptance criteria, test cases, points, etc., etc. Oh, and by the way, it would be INTUITIVE.

When I enter a new team, I start the search over, and almost always end up back to stickies and/or spreadsheets. Currently I am using Acunote (http://www.acunote.com), and it seems to be doing the trick. It's missing a lot of things, but it's good enough for our purposes.

I've learned to not worry about tools until there is a solid foundation. The right team (technical lead, Product Owner, Scrum Master) and a product backlog must be in place first. Then, the core Scrum team can be formed because it is clear what needs to happen. Once the Scrum team is in place, ensure they are self-organizing. NOW, it's okay to start looking at tools ... as a team.

In the meantime, my quest will continue, and maybe someday that perfect agile tool will surface. But, if it doesn't, I'll just stick to stickies and spreadsheets and be happy!

What makes a successful waterfall project?

I recently posted a question on linked in wanting to hear from people who have either led or been a part of a successful waterfall project.

Here's the link. There a some awesome answers. What's interesting is that what is required for a successful waterfall project is clearly defined scope, engaged sponsors, and a great, empowered team. Sadly, I rarely see all of these occur in the wild. And, these are the primary elements of what's necessary for an agile project, explaining why there is a higher success rate with agile projects.

Scrum Documentation

If you are on an agile team, and you are telling your team that you don't need to document because your "agile", stop it. Stop it right now!! You're making my life difficult!

There is a strong stereotype out there, and its that with agile, you don't document. Arggghhh!!! I'm sure some of you have experienced it.

Here is what I tell people when they ask about the documentation requirements on an agile project..."If the team needs it, then they will create it". Now, I'm not talking about documents that are delivered to the customer, like help documents. I'm talking about documents such as architecture diagrams, "requirements" documents (eww), process flow diagrams, diagrams, and more diagrams.

IF these kinds of documents will make the team more productive, and produce higher quality software then document! Now, the next thing I tell people is to be LOW TECH. I mean, c'mon, do you really have to transfer that diagram on the whiteboard to visio? I've seen people take 2 weeks to do that, as the rest of the team is "waiting", i.e WASTE. Why not take a picture? It's going to change anyway, right? And, we "want" it to change, if we ever want to improve.

Remember, the end customer does not value these kinds of documents. So, DON'T SPEND A LOT OF TIME ON THEM. If your company "requires" them, then take the lowest road approach possible. Ask questions. Challenge the "process". Processes were meant to change and improve, you should not be a victim to them.

Okay, to review....

• Documentation can be good, if it makes the team more productive and the customer happier because of higher quality. But, BE CAREFUL
  
• Low tech = Good
  
• The customer DOESN'T CARE about those documents, so just take it easy there partner. Only do the bare minimum that you NEED.