10 April 2012

Pragmatic Agile - Remember the First Value!

Everyone, I'd like you to meet Al.  He's a real person, not a conglomeration of people or a fictional persona created for this post.  Al is a ScrumMaster at a recent client... a ScrumMaster with a secret.

I coached Al and his team quite a bit for the first few months I was engaged at that client, and then to a lesser extent for the next 18 months.  That team was very high performing, avoiding a lot dysfunctions that many teams encounter when they first move to any Agile process.  Their standups were reasonably effective, their defect rate was ridiculously low, they shipped meaningful work at the end of each sprint, and they sought constant improvement.  I started working with Al's team during their second sprint, and I was told that their first sprint was an "unmitigated disaster".  From my perspective as an objective observer, it really wasn't, but such was the attitude on that team that they believed they could do much better.  And they did!

This team had worked together as a group for years, many of them going back a decade or more together.  I often saw this team sitting together having lunch in the cafeteria, management included.  That's where Al's secret lies... he was the team's functional manager as well as their ScrumMaster.

I hear gasps in the audience...
You can't have a functional manager to whom the people on the team report as the ScrumMaster!  That's a conflict of interest!
Sure, in a good number of cases I'm sure it is.  Not with Al, though.  You see, although I hadn't met Al before he became the team's ScrumMaster, I could tell that he was a servant leader.  He comes from a  technical background, but doesn't meddle with the work of the team.  Indeed, he was originally appointed as the ScrumMaster so that the team members wouldn't be burdened with the role.  Al did whatever he could to remove obstacles and ensure that the team's flow of work would be as uninterrupted as possible.  Al was (and still is) a very effective ScrumMaster.

How could this be possible?  How could a functional manager possibly be an effective ScrumMaster?  After all, the functional manager has a position of authority over the team members.  He handles their annual reviews that affect their salaries and position within the company.  There's no possible what that such a relationship could work, right?

Yes, it can.  It has worked in many teams and many organizations long before the 17 good folks at Snowbird coined the term Agile.  Are there situations where the functional manager shouldn't be the ScrumMaster?  Absolutely!  In fact, I would suggest that in those situations, though, the functional manager probably should not be the functional manager either!

Many people have assumed that there is a rule stating that a functional manager can't be the ScrumMaster for a team.  Even Al and the Product Owner with whom he worked were somewhat sheepish when I arrived, apologizing for the fact that they weren't organized "properly".  There actually is no such rule in the Scrum Guide, and the list of "services" that the ScrumMaster provides to the Product Owner, Team and Organization sounds an awful lot like the things that an effective functional manager would have been doing prior to adopting Scrum.

It all comes down to the very first and most basic of the Agile values:
Individuals and Interactions over Processes and Tools.
When it comes to determine who should fill what roles in Scrum or any other process, it should be the individual people who are evaluated, not their job title.

In another business unit at this same client, a development group decided to remove the entire layer of first-level management, with all team members reporting to the director.  The former managers became the ScrumMasters for the teams, and there was no longer a reporting relationship.  That certainly dealt with the conflict of interest issue, but wouldn't the team members still view the ScrumMasters as their superiors?

Actually, no.  Those four ScrumMasters ranged from good to excellent in their role.  They were mindful of their "previous life" as a manager, and one told me that he had to actively suppress his project manager tendencies at times.  Another said that the transition from functional manager to ScrumMaster was easy for him, because facilitation and impediment removal was already a part of his job prior to the change.  So, again, people who are already servant leaders should not be discounted or disqualified from becoming a ScrumMaster simply because of their previous title.

I have seen organizations attempt to apply Agile - be it Scrum, XP or some other flavour - as a recipe without any understanding of the values and principles.  Those are situations that are ripe for failure because the values and principles form the basis for any and all things that are considered to be practices in Agile.  This sort of blind faith in practices is what causes problems.

Consider this TED talk by Barry Schwartz about our loss of wisdom:

So, if you find yourself in a situation where a decision about a practice makes you feel uncomfortable, reflect on what value or principle the practice represents.  Question if that .  Question when a practice is being omitted, what other practice or practices will be put in place to serve the value or principle.

Don't be afraid to question why the values and principles aren't being followed. After all, it's not the practices alone that will enable you to be agile - they are the means to an end. To be agile, you have to actually think about what the values and principles mean and how they apply to everything you do.

5 April 2012

Agile in its Second Decade

For quite some time I've been working on a post to commemorate the 10th anniversary of the Agile Manifesto.  I suppose that, as the 11th anniversary has now passed, it would be rather silly to continue to celebrate the 10th! :)

Part of my foot-dragging has been the feeling that I wasn't adding anything to the discussion about a decade of Agile.  Every now and then something would spark my interest and I might add a bit to the post I had started, but it just wasn't resonating with me.

In January, though, Dave Nicolette returned from a blogging hiatus with the post “Agile” considered harmful.  His thoughts about "post-chasm Agile" really shook loose a lot of feelings I've had for the past number of years.  More recently, I met up with a couple of friends in the Bay Area for dinner.  They too were disenchanted with what the Agile world has become.  They used the term "ashamed" to describe how they felt about being associated with Agile, and those conversations triggered my Occupy Agile blog post. In that post I also talked about yet another discussion in 2008 with Scott Ambler about the state of the Agile movement.

All of us shared this common feeling that the Agile world as it is today in 2012 is not what we learned years ago.  Each year it seems that there are calls to rewrite the Agile Manifesto, a new certification scheme pops out of the ground, more automated tools are created and marketed to simplify collaboration, and we move further and further away from the values and principles that defined the movement in 2001.  The shame wasn't a reflection of the original purpose of Agile being wrong, but of how the people in the community have behaved.

I agree that the Agile Manifesto was a statement, a line in the sand, made in the context of the world of software development of the 1990's up to the dot-com implosion.  It specifically focused on the issues within software development, which is one of the key problems cited by people people who believe a new Manifesto is needed.

Many of those people feel that we have solved the software development problems and now the issues are elsewhere.  Scott Ambler wrote about this in Reworking the Agile Manifesto in 2010, Bob Marshall in Agile Coaching is Evil, and Adam Yuret in Working Software isn't Enough.

I agree with all of those posts that there is more to fix than just the software development process.  I also respectfully disagree, especially with Bob, that we needn't focus on just the software.  If I didn't see as much really crappy code as I do, I would be more open to the suggestion that we can declare victory in the software practices war.  Of course, I'm not hired to come in and look at how wonderful everything is, but I would like to be pleasantly surprised just once by clear, expressive code following Kent Beck's 4 Rules of Simple Design, integrated continuously with effective and efficient automated checks running constantly.

Actually, I wouldn't be surprised, I would be shocked.

I suppose, in deference to the opinions of people like Scott and Bob, I should stop looking at the software trees and view the whole organizational forest in order to address the bigger issues that lead to developers writing crappy code.  I wish, though, that I had confidence in the belief that making the silly organizational pressures disappear would magically solve the software problems.

I don't.

Yes, we need to solve the big problems around matrix management, siloed business units, focus on efficiency and utilization vs. effectiveness.  I try to do that in practically every engagement I have.  I also deal with developers who really, truly don't believe that they should be testing their work.  They don't believe that integrating more than once a month is important.  I deal with testers who only want the final product to test.  The don't believe that an investment in automated testing is important.  I deal with architects who believe their job is to design the hell out of everything so that the developers can't screw it up.

In other words, I have to deal with the very problems that the Agile Manifesto set out to solve in 2001.

Are there bigger problems to be solved?  Absolutely.  Should we focus on them?  Absolutely.  Have we truly solved the problems in software development?  In some cases, yes, but in what I would argue is a vast majority of cases, not by a long shot.

So, to me, over 11 years after it was created the Agile Manifesto's values and principles still apply.  In some situations they are less important than in 2001, but in many more situations very little has changed since then.  I will certainly work to improve the organizational environment in which teams exist.  I will certainly work to foster much higher levels of collaboration (and ideally integration) between the development teams and the business people for whom they are building systems.  I will certainly work to help organizations integrate Lean thinking into how they approach not just the software being built but the whole process from "concept to cash".

I will do so, however, while also working to ensure that the way they build software is as good as what I learned from XP (and later Industrial XP) over a decade ago.

4 April 2012

Occupy Agile

I understand that the "Occupy" meme and movement is "so 2011", but after some conversations with friends over the past few days I've begun to realize that I'm not the only person who thinks that the Agile world has been moving further and further away from its origins in the values and principles of the Agile Manifesto.

I've had multiple people now say that they were beginning to feel that they no longer want to be associated with the term Agile - they feel ashamed by the behaviour they see in others in the Agile world.  They feel that there were far too many people who were in it just for a buck and really had little or no qualification to be training or coaching teams, and indeed were doing as much or more harm than good.

While I know many very good people in this part of the software industry, I had to agree with my friends.

Back in 2008, I wrote in a post called Disillusionment about another dinner conversation with Scott Ambler in which we commiserated about the state of the Agile world at that time.  I concluded with the suggestion that, as it was currently progressing, Agile was "in danger of becoming the next RUP... or RAD... or (insert favourite acronym here), doomed to relegation to the scrap heap of software processes".  Unfortunately, I can't say that what I see now is any better than in early 2008.  I'd actually say that it's worse.

Where I feel we've been led astray is in the pursuit of money over the delivery of value.  Let's face it - the fact that the CSM program from the Scrum Alliance helped bring Agile to prominence was a side-effect of a scheme to make money.  The jury is out on whether ICAgile is just another group to peddle certifications, and the PMI now has the PMI-ACP program offering certifications in Agile Project Management.  I'm undecided about Lean Kanban University, but you can be sure that there's a business plan behind it.

I'm not at all averse to people making money - I'm as much of a capitalist as anyone else.  The key difference is that I believe that if you deliver value to customers, the money will follow.  If you simply chase money, you lose sight of the value you're trying to deliver because you have to compromise your own values and principles in order to "make the sale".

I don't want to do that anymore, and I'm encouraged that others feel that way.  I'd like to find out how many people feel the same, and perhaps we can Occupy Agile - bring it back to focusing on values and principles and in doing so delivering value.

If you haven't already seen the little poster I created on Twitter and Facebook, here it is:

If you weren't a fan of the X-Files back in the 90's, I apologize for the obscure reference.