Home » Posts tagged "scrum"

8 Reasons Johnny Does Not Write Bug Free Code

There have been a number of things that have occurred over the last week that have prompted this particular post.  And for anyone I work with, this is not an indictment of our work place so much as it is an indictment of our industry.  PLEASE don’t take this personally.

Some of those reasons will show up in this article.  But the question we need to examine today is why is it so hard to write bug free code.  And I’m not even talking about perfection.  Why is it that we miss the simple stuff?  The stuff that once it is found, we think, “how could we have missed that?!”.  I’m perfectly aware that all code has bugs some just haven’t been found yet.  I’m also aware that no matter how hard I try, the stupid bugs always make their way past my desk.

8 Reasons Johnny Does Not Write Bug Free Code
Photo credit: ~Pawsitive~Candie_N via Visualhunt / CC BY

Continue reading “8 Reasons Johnny Does Not Write Bug Free Code”

3 Reasons Agile Will Not Succeed

I’ve written about Agile and Scrum before and most of my regular readers know that I am a huge fan.  But recently I am starting to believe the Agile movement is doomed.  In fact, the most common response to my enthusiasm for Agile and Scrum is, “Yeah, we tried that once and it was a complete failure.”  Which seems odd to me because in every instance where I’ve been able to implement it, it has worked beautifully.  So why would I say Agile Will Not Succeed?

The buzz around Agile has become so loud that Agile has moved from strictly a software development thing, to all corners of the business world.  And yet, as much as I believe Agile is the right way to develop software, as a movement, it is doomed for failure.  Why?

3 Reasons Agile Will Not Succeed
Photo credit: Tim Evanson via VisualHunt / CC BY-SA

Continue reading “3 Reasons Agile Will Not Succeed”

Code Comments & Agile Programming

PEOP0067A long time ago, in a galaxy far far away, we were forced to name variables and methods with very short names.  When I started my career, I was programming Clipper and C.  Clipper was a dBase compiler, so it only had 10 characters available for variable names.  You could write longer variable names if you wanted, but only the first 10 mattered.  I think at the time, C gave us 32 characters.  But now, we aren’t so limited.  And so the argument goes, if you use long variable names,  you shouldn’t need to comment your code.  I’ve argued as much.

Of course every time you bring this subject up, you will inevitably find someone who will say, “But don’t we need comments to at least explain what the code was supposed to do?  After all, code is generally hard to read.”  Well, yes I guess it is if you are new to the language.  But should every foreign movie have subtitles?  Would you want native language movies to have subtitles because other people in the room might not understand it?  Must we dumb everything down to the lowest common denominator?  If so, where will it stop?

Continue reading “Code Comments & Agile Programming”

Limiting Beliefs of Programmers

screamAt the risk of making half of my audience think I’ve gone off the deep end, I’m going to address a topic that I’ve only recently REALLY begun to understand, in part thanks to Soft Skills.

When I’ve heard the topic of “Limiting Beliefs” come up, it has almost always been in the context of something along the lines of “What the mind can conceive and believe, it can achieve.”  Which is easy to disprove.  At least it is out of context!  I mean really, if I can conceive and believe myself to be a butterfly, it just isn’t going to happen!

However, the opposite is pretty easy to both accept and believe.  And that’s what I want to talk about today.  But even then, it probably isn’t what you are expecting.

Typically, when people talk about Limiting Beliefs, they are talking about patterns and practices you picked up as a kid that are holding you back now.  And while those may be areas that you need to work on, what I want to talk about today is more micro than that, although they may have roots in our past for various reasons, the Limiting Beliefs I want to talk about today are common across nearly every programmer I talk to.

Continue reading “Limiting Beliefs of Programmers”

Being Agile Is About The Journey…

… Not The Destination

BeingAgileThis post first started as I was discussing my post “You Aren’t Doing Scrum If …” with a friend who had read the post and was worried that I might not fit in an organization that wasn’t doing all of Scrum.  I’ve since had other conversations and as I’ve reflected on the topic, I still stand by my original post, because there are some fundamental properties of Scrum that you have to implement in order to follow that methodology.  This is why I called the post “You Aren’t Doing Scrum If …” and not “You Aren’t Doing Agile If …”

Agile isn’t Scrum

But Agile is different.  Agile isn’t a process. Agile is a mindset.

So you can call yourself “Agile” without necessarily implementing any particular methodology because “Agile” isn’t about process.  Agile is about the collective state of mind of the team.  The organization as a whole.  Being Agile means that you are open to change.  That you embrace change.  Agile is about being flexible.  About knowing that you don’t know and that you don’t know what you don’t know.  Agile is about adapting.  Ultimately, it is about finding ways of being more productive.

In fact, you could implement scrum precisely, which I doubt anyone really does, and not be Agile.

Sacred Cows

In fact, my experience has been that as I try to move an organization along the sliding scale of  being more productive, I will, eventually, find a point of resistance.  The sacred cow of their process.  You can change whatever else you want, and yes, everything else you’ve suggested that we change has proven itself to be a better, more productive, less error prone way of doing what we do.  But, you can’t change our sacred cow. And so far every organization I’ve been in has some sacred cow that we either have to kill or we don’t progress further into being agile.

And so we end up hearing comments from people in the industry like, “I don’t think I’ve been in any organization that has been TOTALLY ‘Agile.’” because every organization eventually runs up against some sacred cow on their road toward being agile.

Leadership Needs To Be Agile

I know of another guy in the industry that postulates that the reason organizations fail as they try to implement agile is because agile is being forced on the organization.  That we need to create an environment where people have opted in to agile.  And to a certain extent, I think he’s right.  But, and I think this is a HUGE but, I think the larger problem is that the leadership has not embraced being agile and so you end up with developers trying to BE agile while the leadership is trying to be predictive.  Funny thing I’ve noticed about most employees, they’ll pretty much do whatever they think will keep the paychecks flowing.  So I don’t think we need opt-in at the worker bee level so much as we need opt-in at the leadership level.  Although I have seen resistance at both levels.

Individuals Need To Be Agile

Finally, while your organization may not be agile at all. It may not do Scrum, or Kanban.  It may resist all attempts to move in that direction.  This is not excuse for you to not be agile. You should ask yourself periodically, “What can I do that might be more productive than what I am currently doing?”  Because an organization can only be as agile as the people working in that organization and sometimes, all it really takes to move an organization closer to being agile is one individual who is willing to do what he or she does just a little more toward agile than they currently are.

What sacred cows have you run into?  What are you doing to be more agile as an individual?  Leave a comment below.

Links About Being Agile