It doesn’t have anything to do with my like or dislike for Scrum itself.  Plenty of teams that aren’t following Scrum have Scrum meetings.  Plenty of teams that don’t even really follow any kind of Agile process have Scrum meetings.

The reason why I am not a big fan is because most of the time they are very ineffective.

The idea behind a Scrum meeting is simple

The idea is that you have a daily stand up meeting where you basically determine how the work is progressing and if divine intervention is required to keep things progressing.

The idea is to provide a transparency where anyone can see what exactly the team is up to.

The basic format of a scrum meeting is pretty simple.  Each person on the team says three things:

1. What did I do since our last meeting
2. What am I doing until our next meeting
3. What is impeding me

On the surface these seem like sensible and valuable things for each team member to talk about, but…

So often these three things end up being BSed

No offense to anyone I’ve ever worked with.  Heck, I know I have BSed them myself.  It’s just too easy to do it.

When I say BSed here, I don’t necessarily mean blatantly lying about what you did and are going to do.  (Although that happens plenty as well.)

What I am talking about is saying what you did or what you intend to do without really having a purpose of why you are saying it.

How many times has this happened to you?  You walk into your Scrum meeting and panic hits!

Oh crapola! It’s coming around to me!  What am I going to say?

I didn’t really get much done yesterday.  I was fooling with the build, then I kept getting interrupted.  Then I was answering a bunch of emails and I ended up helping Joe with that task he was working on.  Then we started talking about how we’d like to start using this framework.

I don’t even know what I am really planning on doing today.  I’m just going to keep working on the backlog I am working on.  I don’t want to say that though, I need to say something more important.

So what do you do?  You kinda make up something important sounding, and you mix in some of what you did do and try and make it relate to things happening in the sprint.  You prattle on about stuff that no one really cares about, because you need to say something.  You’ll look like an idiot if you don’t.

This kind of thinking is contagious

Pretty soon you end up with the whole team just prattling on about things that aren’t really important to anyone else or just saying something like:

I continued to work on backlog X, I’ll continue to work on backlog X today.

Waste of time, waste of breath.  A scrum report is only valuable if it is providing usable information about the progress of an iteration and helping to bring impediments that can be resolved, to light.

I really don’t mean to sound harsh here but I want to be truthful.  We don’t benefit anything if we can’t examine what we are doing with a impartial lens and tear it apart if needed.

My solution

I am a firm believer that pointing out problems without offering solutions is just whining.  It has no value.  I wish I could say I myself was never guilty of it, but the truth is, I do my fair share of it.

With that said, I am offering a solution to this problem…

Commitment!

By happenstance, I just finished reading Clean Coder by Bob Martin.  (I’ll post a review on that book when I get a chance, but excellent read.  It hurts to read it, because it will call you to a higher level of accountability, but read it.)

Anyway, that book has a great chapter on commitment, which coincides nicely with a technique I came up with awhile ago to help make Scrum meetings much more valuable and harder to BS.

The basic idea is pretty simple.  I replace the 3 topics in a Scrum report with my sub-classed version:

1. What did I commit to doing yesterday and did I or did I not meet that commitment.  If not, why not.
2. What will I commit to getting done today.
3. What is impeding me that can be improved by bringing it up in this meeting.

Commitment can be scary

But, it is something that carries with it accountability.  See the problem with your normal Scrum meeting is that it is far too easy to BS.  There is no accountability, so you can basically make up whatever you want.

I’m sorry if this offends some people, but I am not placing myself above BSing a Scrum report.  I would venture to guess that a majority of Scrum reports given on this planet are heavily weighted to the BS side of the scale.  Once again, not necessarily saying people are lying.  I am just saying that your Scrum reports contain the value of feces from a male bovine.  Just saying…

What I try to do with my solution is add some accountability by focusing on commitment.

The idea is that it makes you think about what you are actually reasonably going to get done in the day.  It forces you to think about priorities and schedule.  It requires you to break down your work and think ahead a bit so that you can come up with something that you can commit to.

It also tends to make sure that what gets worked on is what should be getting worked on.  You don’t get to say what you worked on yesterday, you only get to talk about what you committed to that you either did or did not get done.  This prevents team members from talking about all the other non iteration related stuff they did.

It really makes you think before you jump off down some rabbit trail if you really want to say in Scrum the next morning that you didn’t do anything you committed to.

It really makes you think first before implying you are going to get something done.  Instead of saying “I’m going to try and finish up backlog X today,” you are more likely to break down some component of backlog X and say “I will commit to getting done task A in backlog X.”

The difference here is critical, because in it lies the value.  The value is that someone listening to your report can actually get an idea of the true progress of the team and of the backlogs being worked on by the team.  If every day team member just report they are working on backlog X and backlog Y, we aren’t really learning anything about if backlog X and backlog Y are really progressing.  On the other hand, if team members are required to make a commitment about what they are going to get done on backlog X and backlog Y, we start to get a real picture of how that work is progressing.

Keeping it relevant

The other thing this Scrum meeting modification does is to keep everything talked about relevant.  By talking about what was committed to and what is going to be committed to, it doesn’t leave much room for talking about other unrelated issues that are best left to another meeting.

A Scrum meeting is effective because it is a short status meeting.  When other stuff bleeds in, people start tuning out and pretty soon we are all standing around talking to the mirror.

I make a point that no one should be talking about impediments that cannot be reasonably be expected to be helped by bringing them up in the Scrum meeting.  What is the point of talking about something that can’t be fixed?

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

Responding to change

Agile is all about responding to change.  Don’t get me wrong, I am not for one second suggesting that you should specify your requirements up front before working on the backlog item.

Agile is also about iterative development.  We take a thing, get a rough idea of what we want to build, build it and then iterate on it, making it better as we progress and figure out what we truly want.

The specific problem I am after today is about knowing when to allow change and at what resolution to iterate.

I think these are very important ideas that need to be understood to really be successful at Agile software development.

Change

To some people Agile means we allow change at any point in time.  I think this view is a little too far on the extreme.  There are certain points in an Agile process where change is welcomed and that depends on the process.

Scrum welcomes change up to the point the team has committed to the sprint.  After that point changes to the scope of what will be worked on during the sprint are detrimental.

Kanban and Kanban like methodologies embrace change all the way up to the point that the backlog is in progress.  At that point a significant change to the scope or focus of the backlog causes more harm than it provides business value.  (In general)

What kind of changes are also important to define.

The kinds of changes greatly affect whether or not they can cause harm or be good.  Changing the layout of a screen during the development of a backlog usually is not a big deal.  Changing the way the screen functions usually is.  Changes that add significant functionality also are harmful when the backlog is already in progress.

A little later on I’ll talk about some of the reasons for this.  For now let’s look at…

Iteration resolution

There is a prevailing misunderstanding of what iteration means and how it is valuable in Agile software development.

Many Agile practitioners think iteration applies only to the software package itself and to iterate means to add features.

This resolution is far too large.  If the smallest iteration of your software is a complete feature, you probably have fatlogs, and you are going to run into trouble.

You may not ship features to a customer until they are completely evolved, but if you try to complete the evolution of features all in one sprint or cycle, you are probably going to bite off too much and miss out on the true value of iteration.

Just as your software should be iterating by adding features, the features themselves should be iterating by adding functionality.

Think of your software as a tree and features as branches.  If you were to watch that tree grow, it would be pretty bizarre if whole complete branches just started popping up on the tree everywhere.

It is much more natural for the branches themselves to grow from little stubs into a large branch that might even have branches of its own.

Tying it back together

Given a backlog is already in progress and you have a good understanding of when change should be allowed in your process, and what resolution iteration should happen, it should start to become obvious why adding new requirements to that backlog is a bad idea.

If you take an existing backlog in progress and add new requirements to it, you’re introducing change at the wrong point, and possibly trying to “poof” branches onto your software tree, instead of truly iterating.

It is much better to add a new backlog that will serve as an iteration of the existing feature than it is to try and tack on new requirements to the work already in progress.

But why?

Well, hopefully our discussion of change and iteration resolution has given you some idea of why, but there is much more depth to the question than that.  Let’s discuss some of them.

Psychology

There is a huge psychological portion of software development.  We tend to be motivated by accomplishment and feelings of a “job well done.”  We tend to be demotivated by goals changing out from underneath us and feeling like a job won’t ever really be done.

Let me give you a simple example.  Imagine you tell your child that their chore for the day is to make their bed.

They go and do it, come back to you and tell you it is done, then ask for you to check it.  When you check, you see that the bed is made, but you say “the floor also needs to have everything picked up.”

So they go and do that, it takes a little longer this time, because they have lost some motivation, but they finish and come back to you again and you see the floor is now cleaned up, but this time you say “the floor needs to be vacuumed.”

In this situation although each request is reasonable, the building of the requests on top of the original task has the effect of demotivating the individual and deprives them of their sense of accomplishment.

When you do this in software development, a similar thing happens.  You also lose the trust of the team, because the team starts to think that when the business says X they are really going to want X + Y + Z.  The team starts to work much slower, because it doesn’t really matter anyway.  You do not want to operate in this mode! It is very bad!

Not letting evolution takes its place

If you try to cross a river by taking a huge leap across it, you are either going to get wet or you are going to make it.  If the river is big, you will mostly get wet.

It is much better to cross a river leaping from stone to stone until you are all the way across.

Adding a requirement to a backlog in progress can be like making a big leap.  By adding another backlog to bring you closer to the goal, you allow the current backlog to be a step, and the new backlog to be the next step.

It is a judgment call whether or not a change to an in progress backlog represents a new requirement which should be a new backlog or not.  I would err on the side of making new backlogs rather than adding requirements though.  I generally say if it will increase scope significantly it should be a new backlog.  Either way the work is going to be done, so why not have your…

Estimating more accurate

Nothing kills historical estimations like scope creep.  If you want accurate data, don’t add unaccounted for work.  Squeezing new requirements into in-progress backlogs adds work to your historical data that is not properly accounted for.

It is much better to catalog the work and account for it than to tack it onto a place where you will not have a way to extract it back out when you are trying to analyze your data.

Consider also the loss in quality as a developer assigned to the expanding backlog starts rushing the work in order to get it done, because they feel like they are going to be measured against the backlogs they completed, and work added to an existing backlog isn’t going to be counted in the metric.

Don’t forget prioritization here.  If you tack a requirement onto a backlog in progress, you can’t prioritize that work.  You may add that requirement at the expense of delaying other higher priority work in other backlogs.  Make the new requirement into a backlog and you can prioritize it correctly.

Parting words

If you are a product manager, product owner, or business person reading this, give it a try.  You will be amazed how much more happy and productive your team is if the next time you are working on a backlog with them and realize it needs to account for X and Y also, you announce that you will create two more backlogs instead of tacking it right on.

If you are a developer on an Agile team, you may not have even realized this problem might be sapping your motivation.  You might not be in a position to do much about it, but you can always suggest that the new requirement be a new backlog.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

Here is the thing about a dead horse.  Well, you just can’t really know it’s dead.  I mean, sure its eyes are closed.  Sure, it’s lying there in a bloody mess on the floor, but is it really dead?  The only sensible thing to do is beat it just one more time, just to make sure.  Let’s kill that horse good!

There is an underlying problem here… I call it

THE SCRUM BUBBLE

Remember the .com era.  Ah, wasn’t that great.

How about that whole stock market always rises decade…

Oh, and don’t forget the housing boom.  The housing boom was great!

But then… What happened?

Oh yes, we got nuked back to the stone age. 

The same thing is happening with Scrum.  Certification proliferation is fueling it.  What happens when everyone in the software development world is a Certified Scrum Master, and we are still building shitty software?  What then?

BOOM!

It implodes, just like a bubble.  That bubble will burst and when that happens it is going to take Agile right along with it.

A wise man once said

You can shear a sheep many times, but skin him only once.

When you arm people with useless certifications and send them into organizations to go and conquer the beast of software development, you are skinning that sheep.  All the consultants that are milking so much money out of Scrum will eventually find that tit dry.

Scrum is good

It is.  It is really a great tool for building software.  It makes sense, it is practical and if you apply it correctly you will get a good result.  The problem is applying it correctly.  The problem is it isn’t addressing the other things that need to change to really be able to do Agile development.  (Which is why I suggested a new process Kanbanand that does address those things.)

Training and consultants are good also.  Getting good hands on training from someone who really knows what they are doing can accelerate you on your learning curve like nothing else.  Consultants who have already been through a process and can look at things with a fresh eye can be invaluable in making positive changes in an organization.

The problem is Scrum is not the end-all-be-all to software development.  It is not the silver bullet that kills death march zombies.  It is a tool.  I really like Henrik Kniberg’s approach to Scrum and Kanban, where he talks about each being a tool to help you develop software.  In his book, (buy it this book is really good), he asks the question, which is better a fork or a knife?  A pretty silly question to ask, which illustrates the point well.

When we hype up Scrum to the point of rock star stardom, and then use it as a tool to extract large amounts of money out of the software development eco systems quickly, we are creating a bubble.  Just like any bubble, we should expect that to burst if we keep inflating it.

There are a lot of good people in Scrum

There are plenty of good people that have a sincere passion for the craft that are really investing into Scrum because they know it is a good way to deliver value to customers, and it is a simple framework that can be easily taught and implemented.  There are plenty of people like David Starr and Tobias Mayer that are honestly trying to do good in the world of software development and using Scrum to do it.  I honestly believe that.

But, there are plenty of other people that are riding on the success of Scrum and building careers out of being a certificate factory.  We have to take away the keys to the kingdom from those people if we want to avoid destroying the good that others are doing in the name of Scrum.

For this post I want to clearly define what I am calling “Kanbanand” with two primary goals in mind.

1. Allow someone who is interested in doing a Kanban like process to find enough information to be successful.
2. Create a common thread for people who are already basically doing what I am suggesting.

Three Pronged Fork

I want to present Kanbanand as a three pronged fork.  In my mind there are 3 distinct areas of a successful Agile process which must be addressed.

• Business and overall encompassing project process.
• Development practices, including standards and best practices.
• Infrastructure: build systems, deployment, source control.

We must know how to run our day to day process, how we physically construct our product, and how we actually build and deliver the product.

Process

Rules:

1. Project is broken into stories which are small vertical slices through the system which are prioritized.
2. A Kanban board is used to make the progress of a team visible and has limits to control the Work In Progress (WIP).
3. At least once a day team members meet around the Kanban board in a stand up meeting to talk about the progress of the board.
4. The team meets on a regular basis to have a retrospective to discuss how to better improve their process.
5. Teams always pull in work, work is never “pushed” in.
6. Once work has been approved as “done” it can never be “not done”.
7. Find something to measure and measure it.
8. The team is responsible for, and empowered to determine how the team accomplishes its goals.

Values:

• Roughly same sized stories over irregular sized stories.
• Stories specifying what, over stories specifying how.
• Stories that are one sentence over stories that are one page.
• Talking about how to move the board forward over talking about what I did or someone else did.
• Cross functional teams over specialized teams.

Development

Rules:

1. All code is unit tested.
2. Static code analysis tools are used to set code standards, all code must meet those standards.
3. Any code that is done, is completely done.  It is refactored, it is unit tested, it meets the quality standards.
4. Code is never commented out.  Anyone is allowed to delete any commented out code at any time.
5. Determining code is meeting the quality standards must be done in an automated way.
6. No one owns code, anyone can work on any code.
7. Documentation is ONLY created when it will serve a known purpose and has an immediate value.  (Code should document itself with good names and simple flow, unit tests document the low level requirements of the system.  Automated tests document the behavior of the system.)
8. Testing requirements come from the customer, not from the developer.

Values:

• Test driven development over writing unit tests after the code is done.
• Pair programming over working alone.
• Readable code over smaller sized code.
• Doing things right over doing things fast.
• Showing the customer over asking the customer.
• Impromptu discussions at white-boards over scheduled meetings.
• Building tools that will help make completing ten things faster, than completing one thing faster.
• Writing automated tests over manual testing

Infrastructure

Rules:

1. Code is continuously built and integrated as soon as it is checked in.
2. Builds build code, run unit tests, run quality checks, produce deployable bits.
3. Builds fail if any unit test fails, or any quality check fails.
4. Code is only deployed from the exact bits that were produced by the build machine.
5. Code can be deployed to any environment with the push of a button.
6. Production data never goes to any other environment.
7. Developers can always run a local build which is the same as what will be built on the build server.

Values:

• Moving forward to fix problems over rolling back.
• Integrating soon over merging later.
• Quick builds over slow builds.
• Deploying on demand over deploying on a schedule.

Feedback?

That is my first crack at it.  I have tried to keep the process as simple as possible, but still include as rules the things that I think are most important to be successful.  I tried to keep the things that involved judgment calls as values.  I believe this provides enough information to allow an organization to create a custom process that will work for them, but will still have enough controls to be consistent in the things that I feel make Agile practices valuable.

Let me know what you think, or if you have any suggestions.  I will update this post as this list evolves.  I am sure there is something I missed or could state in a better way.

Like I said before, if you are doing some form of Kanban, you probably are already doing Kanbanand.  If you are doing Scrum, your major change would be to drop the planning and instead try to get same sized stories while limiting your WIP.

What I chose was Kanban and most of the other “Agile” stuff that I consider good practices and find valuable.  There really isn’t a good name for this and when people say they are doing Kanban, it really doesn’t say much.  Hence, I am coining a new phrase (Kanbanand), which I hope will be much more specific than saying I am doing “Agile or Kanban development”, and not quite as specific as saying “I am doing Scrum”.

Agile is pretty vague

There is a major problem in the Agile community today.  The problem is “Agile” is too broad and involves a large number of assumptions about what Agile involves.  There is not much that defines Agile even though many types of best practices are considered to be Agile.

Which of these best practices are clearly defined in the Agile manifesto or Agile principles?

• Test driven development
• Paired programming
• Daily stand up meetings
• Progress board with swimlanes
• Having a product owner
• Stories or backlog items
• Continuous integration
• Automated testing

The correct answer is none of them.  Don’t get me wrong here.  I am not attacking Agile.  I am just saying that when you are saying “I am doing Agile development”, what you’re saying means different things to different people, and most people don’t even realize what the Agile Manifesto actually says, or what the Principles Behind the Agile Manifesto says.  Instead they have this general idea of what Agile is and it may include one, all, or none of the items I listed above.  (Actually I would venture to wager that most people think Scrum and Agile are synonymous.)

Scrum, XP and Kanban

Scrum and XP don’t really suffer from the problem that Agile in general does.  They are not really vague at all.  Actually, to be more accurate, they are not really vague about process at all.  Scrum is a little vague about development practices.  Either way, both of these processes suffer from a different problem than Agile itself.  No one is actually doing them. Well, hardly anyone is.

Lots of people say they are doing Scrum.  But what they are actually doing is what is known as Scrumbut.  “We are doing Scrum, but… “.  And no one that I know of is actually brave enough to claim they are doing XP.

The problem is these processes are just a little too restrictive, a little too prescriptive.

Kanban is out there on the other end of the spectrum.  It is sitting closer to Agile.  It is the least descriptive.  Heck, Kanban doesn’t even have to be Agile at all!  I am sure most people that are doing Kanban are doing it in an “Agile” way, but there really is nothing about Kanban that says anything more than you have a Kanban board and you limit your Work In Progress (WIP).  If you have a whiteboard and you can put a number on that whiteboard, you are doing Kanban!

Enter Kanbanand

Kanbanand is good in the same way that Scrumbut is bad.

The goal of Kanbanand is to be a fully Agile process, adhearing to the Agile Manifesto and the Principles Behind the Agile Manifesto, as well as process that is not as specific as Scrum or XP, but specific enough to be distinct and recognizable.  The basic idea of Kanbanand is to take the simple non-prescriptive, open framework of Kanban and formally add some of the best practices that are considered “Agile” as requirement and others as guidelines.

In the spirit of the 80/20 rule.  I want someone saying they are doing Kanbanand to be able to convey with just those words, 80% of what their development process looks like.

In my next post I am going to attempt to define what I will call Kanbanand.  I will proceed with the goal of making Kanbanand be much of exactly what most Kanban teams are already doing, just formalized in a way that is specific enough that someone doesn’t have to know the undocumented features of Agile development to understand it.

If there is enough support around this idea of creating a more formalized version of Kanban that more specifically states the process, and is still Agile, I intend to create a website and community dedicated to this idea.  Contact me if you are interested in participating.  I think we are at the point where the only thing holding Kanban back is that there isn’t a formal enough definition of what exactly it is.  I believe once we have a real Kanban process that can be implemented and clearly identified many of the teams and organizations that intially thrived under Scrum, but are now held back by the strict time-boxing, will jump to our side of the fence and embrace the idea of limiting WIP.

In doing so, I had to really think about why exactly I think waterfall is bad. 

The feedback loop

It really came back to one central thing for me, which is the length of the feedback loop.  When we are using a waterfall process for software development, the customer doesn’t really have a chance for feedback until the end of the project.  Even the testing is done at the end of the project, so that feedback is coming very late.

The biggest strength Agile gives over Waterfall, is the tightening of that feedback loop.  The quicker you can get the feedback, the quicker you can respond to it and the less time you spend going in the wrong direction.

From a programmer’s perspective, think about how many of us used to write code, before the tools came along to help us, and before we knew any better.

Write a bunch of code for 2 hours

1. Run the compiler
2. Fix an error
3. Recompile
4. Repeat 2-3 until all errors are fixed

That wasted a large amount of time.  Especially when we had some syntax wrong that affected large portions of code.

Using a modern IDE, we are able to see syntax errors getting highlighted the second we type them.  We can start to type a method name and auto-complete can take over and offer us suggestions.  It it difficult to write bad syntax because we are getting constant and immediate feedback as we write out code.  The feedback loop is so tight that we don’t even consider compiling to be a separate step.  There are even some IDE plugins which will continuously run any unit tests which may be affected by your code change in the background as you are making the change.

If the modern IDE experience is Agile, then Waterfall is punch cards.

Taking the best of all

So, here is my prezi presentation.  Please give feedback if you have some.  Remember this presentation is designed to be a very basic beginners guide to why someone should choose Agile over Waterfall.  It is not going to go into very detailed topics about Agile.

Also, at the end of the presentation you will notice that I suggest taking some of the process of Scrum, and the XP best practices, and running Kanban using those guiding principles.  I currently believe that is the best mix of what Agile has to offer.

I’m about to piss off a lot of people.

But, I am going to tell the truth.

Often a person has to make a choice between standing by their convictions and doing what they believe is right or doing the more profitable thing at the cost of integrity.  I don’t like to use this blog as an avenue to bash anyone, but I have held myself to the requirement of being honest.  Honest in the most tactful way that I can.

I am also not always 100% correct.  Sometimes I am plain wrong, but I have to call things as I see them until corrected and shown otherwise.  I am open to being corrected.  That is how to learn.  Learning is more important than being right.

One last disclaimer.  I don’t hate Scrum.  I think it is good.  I think it is really good, and if implemented correctly can provide enormous benefits.  I think most of the ideas are sound, even though I do believe it has some major flaws.  I think if 90% of software companies stopped doing their broken process and at least tried to adopt Scrum, the world would be a better place.  But… I also think Scrum is not the end.  It is just the beginning of an eye opening and awakening of problems in developing software.

If I attack Scrum, it is for two reasons.

1. To push us to build on the principles of Scrum and go beyond it to iteratively find an even better process.
2. To fight against the blood-thirsty vampire consultants, trainers and organizations preying on the uninformed and making Scrum a commercial enterprise which sacrifices its integrity.

Today I will talk about the latter

Perhaps this isn’t a smart move.  Perhaps this will remove opportunities from my path and make people angry with me.  So be it.  If I am wrong, teach me.

What sparked this whole post is the relaunch of scrum.org.  I listened to Pluralcast #12: The Future of Scrum with Ken Schwaber.  I truly listened to this with an open mind and was optimistic about the new programs being launched.  I bought into the story about the Scrum Alliance becoming a money making scheme and selling certifications.  I welcomed the fresh clean break to “free certifications” and altruistic motives.  I thought teaming up with Microsoft to bring in a .NET track, and later a Java track, was a great idea.  Until I visited the website and found the only difference between scrumalliance.org and scrum.org is who is taking your money.

But please, don’t take my word for it.  Lets look at the pages together.

This is the assessments page, let’s click Professional Scrum Master.

Hmm, there is also a Professional ScrumMaster II on the page below.  Let me register and add them both to my cart, so I can take this test and get certified.

WOW!  Umm, what is going on here?  Didn’t they just talk about how Scrum Alliance was ripping us off and turning Scrum into a money making venture?

Ok, how about Professional Scrum Developer, that one I am really interested in.

Okay, can’t take the test on here the first year.  Have to take a course first.  That sounds pretty reasonable.  Let’s check out the prices of the courses.

Umm.  $2000?  Then I can be a Certified Scrum Master?  How is this different than Scrum Alliance?  Okay, what about the Certified Scrum Developer?

Okay,  sorry, I’m not sipping that Kool-Aid anymore.

The ScrumAlliance.org courses are even cheaper.  (Although, they are still a rip off IMO)

It’s all about the Benjamins

My current assessment of the Scrum consulting world just got worse instead of better.  I really wanted to believe in what I heard on that podcast.  It seemed really good to me.  I even bet the classes will be really good.  I know one of the instructors and he is awesome!

The problem is, I can’t trust Scrum.org, and I can’t trust ScrumAlliance.org, not when they are about making money.  (That little .org domain on the end is kind of ridiculous).  It is pretty clear to me that this is what the whole Scrum movement has become.  When all the dust settles and the consultants have certified every Scrum Master in the world, will software development really be better?

If I am wrong, tell me.  I won’t filter the comments here.  Ken, if you want to, address this post.  Do so, you have a right to and I won’t filter your response.   Sorry if I am “hurting your guys business”, but my conscious does not allow me to stand by and say nothing.

Answer: Move the finish line.

Let me paint you a picture…  imagine you are in a race.  The 100 yard dash.  You’ve been training, practicing the starting blocks and getting ready for the big race.

You are in the blocks, ready to explode and start running at the sound of the gun.

The gun fires “BANG”.

You take off down the track.

90 yards

70 yards

40 yards

30 yards, you can see the finish line clearly now… almost there

20 yards, just keep sprinting and you will be there!

50 yards, wtf?  Did the finish line just move?

60 yards, eh?  Did it just move again?!

Do you keep running hard at this point, or do you start walking?  If you are like most people, you will start walking.  If you are like most Scrum teams, you will start walking.

Now, imagine if this happens every sprint.  Pretty soon training becomes less important.  You find yourself not even using the blocks because it is not going to matter.  After a few iterations of this the team is walking from the get-go, not even running at all.

Do not move the finish line.  Don’t do it.

I’ve previously talked about why I think Scrum will eventually die and I am still pretty much convinced of that point.  Scrum has become something you sell through training and consulting.  If you make your living off of doing this, sorry, but you may be part of the problem.

What this post is really about though is the problem of good architecture when implementing Scrum.  In my experience, it is very difficult to create or maintain a good architecture and do Scrum.  There is one very simple reason for this: mobs don’t build good architectures.

Why?

Let me give you an example that helps to illustrate my point.  Let us take a second to think about real physical engineering and architecture.  Let us say we are going to put together a team to design and build a custom home.

So we get together a plumber, an electrician, a couple of framers and an architect.  Now, let’s have them start building the house.  What do you think the architecture of the building will be like?  What if the plumber and electrician know a good amount about architecture, because they studied it in highschool?  They outvote the actual architect.  In general the team is going to benefit from the real architect’s experience and guidance, but when he understands a critical component which the other team members do not see, he is going to be overridden and that will spell trouble down the line.

Now, obviously this parallel does not completely apply.  I am just trying to take one aspect of it for the point of this illustration.  The idea that you don’t want a group of people, as intelligent as they are, to make a decision which could be better left in the hands of an expert. 

At this point you might be thinking “what an arrogant jerk!”  You think a so called “software architect” knows so much better than the average developer?  No, that is not exactly the point.  The point is that there is a difference in level of experience and ability in software people, roles and labels aside, and when you use a democracy of team based decision-making methods, you get an average of the skill level and experience of the whole team as a result.  It is a mouthful, but read that over a few times until you get my point.  I think it is pretty hard to argue against, but let me give one more illustration.

Let us say now that you are going into a hospital to get heart surgery done.  Now, this kind of procedure is not a one man operation.  You would typically have a surgeon, an anesthesiologist, several nurses, and other doctors involved.  But let’s say for this instance that we let this surgical team operate like a Scrum team.  Instead of the surgeon or chief medical officer ultimately calling the shots, the team will make a decision as a whole.  Would you be ok with that?  The nurse has the same vote as the surgeon?  Two nurses can override the surgeon’s decision?  I think I would be a little bit alarmed, especially if I sat in on their design session.

I’m not trying to pick on anyone here or devalue anyone.  I am also not trying to destroy the concept of team.  Teams and teamwork are very important in the development of software.  But I hope you can see the point that Scrum can tend to lean towards a mob built architecture for a system, and that architecture is only as good as the average of the abilities of the team members.  Although more often than not it’s really just as good as the most vocal and assertive member(s) of the team.

Where Scrum and Scrum-like processes fail

I don’t see how a resolution to this problem fits inside of the Scrum framework, and that is a problem.  The idea of a completely self-managing team is ok for making construction type decisions about building the software, but it has no solution for the overall architecture and general best practices for the development of the application.  As much as we can despise hierarchy, it really has a value that is completely missed by Scrum.  You really want to have the more senior highly skilled developers technical people with more power over decisions and direction than your less skilled.  This isn’t mean, it isn’t spiteful or power-mongering, it is common sense.  The problem with the self-managing- everyone-is-equal team is that it levels the field.

So what is the solution?

Would I offer up a problem without offering up a solution?  There are several ways of dealing with this problem.  It depends on how far you are willing to step outside of Scrum.

Solution 1: Scrumminess Factor: 9

Appoint a small team of technical and business architects that have the responsibility of:

• Overseeing the general architecture of the system
• Creating development best practices and guidelines
• Attending design sessions for other teams
• Stepping in when needed to steer a team back on the right course

 This solution works only if you have several Scrum teams on the project, where it would make sense to have a team dedicated to architecture.  This team is also a good one to be creating developer tools.  I have actually been part of a team doing this kind of role, and I think it worked out pretty well.  It doesn’t really violate Scrum, because that team is a separate Scrum team with a different kind of backlog.

Solution 2: Scrumminess Factor: 6

Appoint a technical architect to the project.  This person is in charge of the technical people on all of the teams for technical direction, but not HR duties.  This role would have the ultimate authority on any kind of development and architecture decisions for the project.  They would be a floating resource that could help teams at times where needed.  This person would be thinking about the bigger architecture picture that is being created by each of the teams.

Solution 3: Scrumminess Factor: 3

Appoint technical leads on the teams which are responsible for the architecture and ultimate technical direction of the team they are on.  If you have multiple teams, the technical leads should have a technical lead for the technical leads.  This allows for a unified vision when there is dissent among the technical team leads.  It has a low Scrum factor, because it puts a direct leadership role on the Scrum team, but it allows for the solution to the mob architecture problem, while still keeping the architecture within the team.

One final word here.  If you are still thinking that a central authority is not important to a business, consider this:  every company I know of has either a CEO or a president.  I have never seen a company with a Chief Executive Committee.  Sure, there is a board of directors, whom the CEO ultimately is accountable to, but you have one person setting the vision and business direction of the company.

Just make it work…

I first introduced the concept of a Fatlog a couple of months ago.

Basically, a fatlog is a Scrum backlog, or any Agile user story, that is too big and can be sliced vertically into thinner functions of the system.

I talked about the kinds of symptoms which might indicate a backlog is indeed a fatlog, but today I want to hone in on a special kind of fatlog that really only exists in maintenance mode.

I like to call this kind of fatlog the “just make it work” fatlog.  It is kind of hard to describe what this fatlog looks like, but perhaps easier to describe one of the ways it comes to be.

Let’s say you have a major feature for your application.  Some feature that you built over several backlogs, perhaps over several sprints.  Some users start reporting a few bugs for that feature.  This doesn’t work, it doesn’t work when I do this, etc.  The business doesn’t really understand what the user is saying or doesn’t want to take the time to fully understand what is broken, they just know some of the parts of this feature are broken.  So what do they do?  Create a user story which describes all of the requirements of the entire feature and make it one single backlog.

What you end up with is a large backlog that really should be 10 or more backlogs, but is excused as one backlog, because “most of the stuff is working anyway.”  The idea here is not so far fetched.  The idea is that if most of it is working, the team should be able to identify which things are not working according to the requirements and fix just those things, and in the end the whole thing needs to work anyway, so they should make sure the complete feature works.

What is wrong with this?

It may seem like not that big of a deal, you can just estimate the backlog based on the parts you know are broken and the testing for the entire feature.  There are a few problems with this line of thinking.

• What if one or more of the things you thought were working are not working?  What if they are horribly broken?
• How will you know how to test the entire feature without the entire detailed requirements?  If you think you’re just going to pull up the tests from back when you first implemented the feature, you had better check with your business first.  Chances are their idea of the correctness of the feature has changed.
• How do you know where to start working?  You will have to access what is broken first.  This will mean that you must run all the regression tests to see what is broken.  The only problem is if your original tests would have failed for the failures in the first place, you would have already known about it and fixed it the first time.  You will have to write new tests to exploit the bugs that you don’t know about.
• If the business cannot tell you what is broken, how will they know when it is fixed?  Your success criteria will be very interpretable.  That is a recipe for failure.

Have you ever played one of those games where you try to figure out what is different between two almost identical pictures?  Some of those pictures can be very difficult to spot the differences.  It is a good thing they tell you how many wrong things you need to find.  When you have a “just make it work” fatlog you have exactly that.  Except you don’t have the count of how many things are wrong.  You have to keep guessing and hope you got them all.

Here is the key point: a user story sizing should not be based on the size of the work, but rather the scope of the work. The difference may not seem like much, but it is huge.

Consider the difference between these two statements:

1. Find the one 1 needle in all of the haystacks on the entire farm.
2. Find 50 needles in the one haystack by the side of the barn.

The first statement is not much work, (just finding one needle), but the scope is huge.  The second statement is much more work, (finding 50 needles), but the scope is much smaller.

Which statement do you think is likely to have more success?

One key thing each Scrum or Agile team should ask about each maintenance story they are going to take into an iteration is: can you tell me what is broken? If the business cannot tell you what is broken, but only lists a set of requirements of how something should work, you are going to be searching for a needle in an unknown number of haystacks.  Instead, the backlog should be changed to either reflect exactly what is known to be broken, or be broken up into many smaller stories with smaller scopes.