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.

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.

The Curse of Traditional Software Development Methodologies

I've realized that very few teams follow the waterfall methodology by the book. However, I think that most shops try...really, really hard. Of course we WANT to define every requirement and scenario that could possibly happen. Once that's complete, THEN we can start building. And, if there is a new scenario, or "missed" requirement (heaven forbid), then the developers can point at the requirement gatherers and say "AH - HA!!! You screwed up, and now you must suffer the consequences!".

Well, this is just silly, we all know that change happens, but yet we try to fight it every step of the way. That's what requirements change management is, right? Its to prevent change, i.e. just say NO! To remain competitive in today's marketplace, we just can't think like this anymore.

Below is a list of beliefs that we (including myself) really wish was true. If they were true, our jobs would be so easy! Of course, it wouldn't be as fun :-)

• The customer knows exactly what they want.
  
• We understand what the customer wants.
  
• We understand who the customer is.
  
• We can define everything up front.
  
• The technical team knows how to build what the customer wants.
  
• We can accurately predict how long it will take to develop what the customer wants.
  
• There won't be any problems (or very few).
  
• Documentation is a true measure of progress.
  
• Nothing should change. If it does, it's [fill in the blank] fault.
  
• Hours worked is infinitely directly proportional to value delivered.
  

Okay, so none of these things are really true. Since we all like to pretend, we have failed over, and over, and over again. I believe that this failure in traditional projects has caused stereotypes to evolve, including:

• The technical team is arrogant and lazy.
  
• The technical team doesn't care about the customer.
  
• The technical team is lying. It can't be as hard as they say.
  
• The customer doesn't respect the amount of work necessary to deliver what they want.
  
• The customer is stupid.
  

This failure has also caused some pretty weird behaviors to spring up.

• A tendency to over-specialize and divide ourselves into silos.
  
• The desire to control and direct every move made by every team member.
• Forgetting that development is creative and innovative and can't be treated as a commodity (this causes some real bad implementation).
• A culture of command and control.
• The desire to create a process for EVERYTHING in an attempt to control.
• A fear of sharing "too much" information with other silos...I mean other teams. If we share "too much" information, then the other teams may want "change".
• A fear of sharing too much information with the customer. Again, for a fear of change.

Please, stop the madness. Let's stop pretending that traditional development works and start working together.

Hard Questions for Agile

I am seeing a lot of the same questions come up over and over again recently. Now that larger organizations are starting to see the benefits of agile, more and more questions are coming up.

Everyone (including myself) has a desire to have a prescribed method, process, checklist, etc. that they can use to make sure they are doing things the "right way". In Scrum, there is a pretty clear list of activities, artifacts, and roles. People struggle because these lists provide the "whats" but not the "hows". For example, when I tell teams that they need to have one product owner for that project, they are sometimes at a loss; "How do we find one product owner? Our organization won't support that!".

Below is a list of questions that I have seen come up over and over again. I'm going to address them over time (as I have more time).

1. How can agile work on large projects?
• I know this is being addressed slowly, but there are just not enough case studies out there. The standard "Scrum of Scrums" just doesn't cut it anymore, meaning that there are serious complexities that aren't addressed in the standard definition.
2. How do I work with a vendor that does not want to take and agile approach?
3. How does interaction design work in an agile environment?
   
• I have not met any interaction designers (HCI type people) who really buy into the concept of iterative, incremental development.
4. Our company is committed to PMBOK, how can agile fit in this environment?
5. Our company needs to make financial projections that are 5 years out. How can we do this using an agile approach without trying to plan everything up front?
   
• We in agile know that it is a myth that you can accurately plan everything up front.
6. Our company needs to be CMMI compliant to be able to work with government entities. How can we be CMMI level 1-5 compliant and still follow the agile values?
7. We have a project that's in crisis. How can agile rescue our project?
   

I'll add more as I hear them, but these are the biggies. Feel free to provide input or links that addresses any of these questions.

Agile won't work on [fill in the blank]

I have four kids ranging from 15 to 3. For some reason, people with no kids really like to give my wife and I advice on how to raise kids. Usually they will provide analogies using their favorite pet. Or, they will tell me about their second cousin twice removed who "just had a baby", and here's what they PLAN on doing. I just politely nod and say "thank you".

So, what's the point? Well, I tend to get a lot of advice, or "words of wisdom" regarding agile development and how it won't work on certain projects. I've heard it won't work on complex projects, big projects, geographically disperse projects, mission critical projects, non-software projects...you name it. Everyone who tells me this has either a) never worked on an agile project or b) worked with a poor implementation of agile.

Instead of politely nodding and saying "thank you for your advice" as when I'm given child-rearing advice, I've recently decided to challenge these ideas. Of course not in a confrontational way, but just in an inquisitive way. "What experiences have led you to that belief?". "Why can't an offshore project implement agile methodologies?".

Below is a post that I saw on LinkedIn:

"As with any project management tool, it is situational. If, like in many software development environments, there are one or two key people involved in each and every task, Agile tends to break down. In this case, there are better methodologies to employ. Like any concept, I think the rub is that no technique fits all situations."

This is clearly someone providing advice on agile development that clearly has never worked in an agile environment, or has suffered a poor implementation. I couldn't resist responding. Below is my post.

"There is a very broad spectrum of agile methodologies out there that will cover any situation. Being agile also means adapting the process to fit your needs as it's an empirical, "inspect & adapt" approach to managing projects. For instance, typically Scrum & XP are implemented together. Scrum only addresses project management issues, while XP addresses development issues.

The failed agile implementations I have seen were caused by one or more of the following:

1. The team is not empowered and self-organizing.
2. Team members are working on too many projects, resulting in excessive context switching.
3. Management is committed to command and control (related to #1)
4. The customer or customer representative is not involved.
5. Processes are not allowed to evolve.
6. There is no dedicated product owner, i.e. someone responsible for the ROI that the team can go to (getting rid of the multiple boss syndrome).
7. The ones leading the agile implementation have not been properly trained in agile.

So, agile breaks down when the organization is not ready to accept its principles. If the organization is not willing to change from command & control to servant leadership, empower the team, assign ONE product owner, and get the customer involved, then it will fail."

Hopefully I didn't come off as a jerk on this. I just couldn't resist.

If you feel that agile just won't work on _____, I encourage you to find out for yourself. There are plenty of cases where it has worked on huge, complex, mission critical projects.

Sprint Planning When Everyone's New

We were working on a legacy product written in PowerBuilder. There was one engineer that had been around for a while, about 6 years. Another had been around for a little less than a year, and the rest were brand new. The entire QA team was new. They weren't only new to that project, they were new to QA. There was also a team of business analysts. Most of them had been around for several years, but there were only 2, and this was a big project.

As to be expected on teams such as this, the process was very waterfall-ish and chaotic. The team waited for the BAs to create "the specs", and QA waited for engineering to do the coding. Lots of waiting.

It was my job to implement Scrum at this company. We finally had a product backlog that was prioritized, but that was about it. Even though that was such a small accomplishment, it made a very positive impact on the team. Before this, the team never new what to work on next, and usually worked on things that had to be abandoned later.

So, we have a product backlog. We still hadn't conducted a release planning or a sprint planning session. I decided to start with a sprint planning session.

Sprint Planning Session 0 = Miserable Failure

Our first sprint planning session was a disaster. First of all, the QA team did not show up. I almost just canceled right there, but I thought I'd continue this disaster.

We projected the product backlog (which was in excel) and started going down this list. The goal was to define "Done" for each item, and also to decompose it into smaller tasks, with each task less than 16 hours.

We got stuck on the first item. Everyone said "I'll have to go back and look at the spec" for every item we brought up. And if there wasn't a spec, it was just impossible. Everyone just stared at each other like deer in the headlights.

I also heard the engineers say things like "we'll have to go into the code, it will take a couple of days to break this down". Or "there is no way we can break down this 180 hour task" (yes, they had estimated the product backlog items in hours).

We canceled the meeting about 15 minutes into it. While I was very disappointed that it failed, I was excited to have a new challenge. In addition, it was great that I learned something about the inner-workings of the team. How do you conduct a sprint planning session when no one knows how to implement the features in the backlog?

Sprint Planning Session 1 = Moderate Success!

I was sure that the team just needed to do homework. But, after talking with the old timer, I realized that homework was not enough!

The code base was extremely unstructured. It had grown over the last 12 years into something really ugly and barely maintainable. Not even the engineer with the most experience would have been able to come up with sprint tasks that were 16 hours or less. I got some great advice from someone on the yahoo scrum group, about maybe using spiking to help decompose the backlog items. While I love the idea, there was no way we had time to do this on every item.

So, here's what we did. We encouraged team to do some research on the upcoming features.

Then, in the sprint planning session, the team self-organized into smaller teams, and dug in deep on the features. We printed specs out for them, and of course had the BAs there (which were ultimately playing the role of product owner).

The engineers had their laptops so they could look into the code if necessary, I suppose doing "mini-spikes".

This time QA showed up, but they were there in bodies and not in spirits. But, that's a subject for another post.

We still did NOT come up with a sprint backlog. I was a little disappointed in that. However, the team came out feeling like a true team, and with a clearer understanding of the sprint ahead of them. We also had a clear commitment (which the business broke, again, for another post).

It was a definite step in the right direction. While we weren't able to derive the sprint backlog, the team bonded during the exercise. The team also understood what they needed to deliver (they just weren't sure how at that point). In addition, we realized where our problems truly existed.