Wednesday, February 25, 2009

A False Measure of Success …. Revisited

Today I received an unexpected email:

Hi Richard,

Not sure if you will remember me, but we spoke during the agile 2005 experience report selection process about your experience report. We ended up selecting your submission and you went on to write a paper ... and I am currently using the paper in a masters level course on agile methods at Oxford. The students are expected to analyse the case, and I know some of them might be keen to ask you some additional questions. Would you be open to that? I don't expect it will be too time-consuming, and it might be kind of interesting.

Anyway, I do hope that all is well in your world.

Cheers,

Angela Martin

Lecturer, Department of Computer Science The University of Waikato, New Zealand

I am quite honored to have Angela choose my paper as part of her master’s level course at Oxford (assuming the topic is not “Examples of poorly written articles”). I am also happy to hear that there is a master’s level course on agile methods at Oxford.

The article, titled A False Measure of Success, was something I wrote in 2005 for an experience report and was the basis for a presentation at the Agile 2005 Conference. In re-reading my article, the general message of the article is still pretty good. The heart of the article is really about a disconnect within a company in recognizing business needs and technology goals. Though technology goals were met, it came at a cost to the business needs. Instead of being partners in a solution, technology dictated the solution to business. Interesting stuff.

On the downside, also in re-reading the article, I realized that I might have gone into a bit of a tangent when I started addressing some Agile specific thoughts. I also realize that the longer development timeline does not quite look that bad compared to other projects I have worked since the article was written. But worst of all, who let all those grammatical errors through on a published paper (I blame my two editors .... myself and my wife). ARGHHHHH!!!!!!!

Friday, February 20, 2009

Certified Scrum Master .... the Big Lie!

At last night's APLN DC meeting, we were fortunate enough to have Scott Ambler present his talk on Scaling Agile Software Development: Reality over Rhetoric. Overall it was a good presentation with some nice takeaways. One thing that was noticeable was Scott's views on Scrum, CSM, Ken Schwaber. I will save most of these topics for future blogs, however I will address Scott's view on the 2 day Certified Scrum Master course.

Scott believes that the 2 day CSM course is a scam, a big lie, complete shenanigans. He believes that any professional should be ashamed if they put CSM in their email tags or business cards. And truth be told, I agree with him.

To take a 2 day course and, with no pre-qualifications, no exam, no peer review, no kind of validation or verification at all, become a Certified Scrum MASTER is deficient. Armed with only this 2 day course, one is most certainly NOT a master and is most likely NOT ready to implement Scrum without additional coaching/mentoring/help. We really should call the class what it is, a 2 day boot camp introducing Scrum.

The course itself is generally an excellent course, but one should understand what it does. The class helps the student understand the meaning of Agile and Scrum. It helps the student shift their mindset from a traditional/PMI/waterfall/EVM (EVM, one of the biggest LIES in he industry, definitely more on that in a future blog) base to an Agile/iterative/value/delivery mindset. It provides an overview of how to do Scrum and a general starting point on Scrum. For those already using Scrum or familiar with Scrum, it helps them walk through some of their thoughts, problems, and ideas. Hopefully by the end of the class, the student will be armed with some knowledge of how to implement Scrum, and more importantly, what it means to implement Scrum.

Scrum provides good process, artifacts, tools, foundation, and framework, but there are quite a few implementation details that need to be worked out and tailored to the environment. The actual implementation is quite tricky. It requires experience, expertise, and intelligence. Most people will need help if they hope to succeed just at the project level. To tackle it at an organizational level becomes an even greater challenge.

So really, understand that not all CSM's are created equal. There are some great ones out there and there are some who just had $1500 in their pockets and 2 free days to kill.

Sunday, February 15, 2009

Empowered Optimizing Evolving Value Delivery?!?!?!

In my last blog, I stated that a Scrum Master that truly understands Scrum attempts to create "...a process /atmosphere of empowered optimizing evolving value delivery". When you say it out loud, it does sound like a bunch of buzzwords strung together, like leveraged synergies or synergized leverages. However, honestly, it does mean something.

Empowered - The process should be empowering. The Scrum process is not one where the team is treated like a bunch of mushrooms (kept in the dark and fed, ummm, dung), but rather it should be an open transparent atmosphere. It's a atmosphere where the team is not ordered and micromanaged, but rather an atmosphere where goals are set forth for the team and the team is empowered to do what they do best in achieving these goals.

Optimizing - The team is constantly look at what they are doing and looking to improve and become more effective. Looking at velocity charts and burns down charts, identifying patterns and cause and effect relationships. These things the Scrum Master works with the team to identify and optimize.

Evolving - Similar to optimizing, but grander. Optimizing is tweaking and improving, evolving is deeper, it is questioning base concepts and accepted process and questioning the value and delivery. It is a team feeling optimized and hitting a plateau, then self reflecting and determining what can be done fundamentally different and better.

Value - Not only having a prioritized product backlog, but ensuring the priority is accurate. It is truly understanding what your company / team / project mission is, identifying where the value lies, and using your resources to work on the value. On my last team, we did something pretty interesting. Once our Scrum team had worked together for awhile and there was a sense of team maturity and safety, we tried having value estimation meetings. Similar to a backlog story points estimation meeting, however instead of effort for points, we started addressing value points. How much value would each feature request deliver relative to each other. Turned out to be a great exercise, but the key was that a sense of safety had to be there for the exercise to truly be of value.

Delivery - This is key. Without delivery, all of the above is just a bunch of co-worker sitting around signing Kumbaya. By delivery, I mean actual working software (assuming your team is ultimately producing software). For example, requirements in themselves have no business value (unless you are in the business of selling/producing requirements, and in that case I have a bone to pick with you as well), rather it is a tool/artifact/side effect of producing software. If that same software can be just as responsibly made without those requirements, then are the requirements truly needed? Now, one common misconception is that Agile states no requirements, which is not true. Often it is more the form and standards in which requirements must be made and applied with which Agile has conflict. Anyway, requirements aren't the point, the point is that delivery is key.

Ok, so I hope I have convinced you that I did not just string together a bunch of non-sense industry words when I said empowered optimizing evolving value delivery. Now, I'm off to synergize my leverages.....

Thursday, February 12, 2009

The Key Quality of a ScrumMaster

I recently met with an executive who is planning to pilot a Scrum team at his company. One of the questions that he asked was what where the qualities one should look for in a ScrumMaster. Most of the answers I gave him where consistent with an article Mike Cohn posted regarding this topic (btw, excellent article).

After giving it some thought, I think the one KEY quality of a good ScrumMaster is that they must get "it". What I mean by that is that they must really know the goals of what Scrum is trying to do and and achieve. Agile and Scrum is not about learning a set of rules and processes and then following some cookie cutter method of implementation, rather it is a set of ideas, principals, and goals that are to be achieved. And by achieved, I don't mean just achieved by the team delivering value, but also by the ScrumMaster working with the team and the company in forging a process /atmosphere of empowered optimizing evolving value delivery. To some people, those last five words may seem to be just a bunch of keywords strung together, but I think a ScrumMaster who gets it understands what I just wrote.

At my last client engagement, the ScrumMasters of the company pretty much got it. There were slight difference in implementation details, but everyone was working towards the same goals and optimizing their teams around a company culture and vision into delivery. They weren't following process for process sake or because some book told them to, but they were trying to identify where the values and efficiencies were and how to properly leverage them.

When a ScrumMaster does not get it, you have issues. Many middle managers tend to micro manage or task and order their teams. New ScrumMasters who came up as developers may have a hard time letting go of the tech side and may get too involved or prescriptive in dealing with their tech teams. ScrumMasters with a PMI/PMBOK background may try to implement Scrum with too much rigidity and process. These are signs that these ScrumMasters may not yet fully get it.

For all ScrumMasters out there, that a step back from your Scrum boards (assuming you are using Scrum boards) and think about this: Are your processes really following the heart of what Scrum and Agile should be bringing to you, your teams, and your company?

As a side note, once you get it, your team gets it, and everyone is firing on all cylinders, the job of the ScrumMaster becomes one of the easiest jobs in the world. Good luck getting to that point!

Friday, February 6, 2009

Can I be a Scrum Master and a Developer.....


Can I be a Scrum Master and a developer (or business owner or business analyst or whatever)? Sure, um... yes... um... maybe......



Years ago, I had taken a Certified Scrum Master training course that was that was given by Ken Schwaber (who taught the first 2 days and Mike Cohn taught on the third).

As Ken was defining the role of the Scrum Master as one who removes impediments, empowers the team, ensures process, enforces the Scrum rules, etc…, I started thinking “was that all they did?”. Starting out as a developer and at that time being a Project Manager who would still get hands on in the code and architecture, I asked Ken if a Scrum Master could also be an active team member. Ken’s answer was something along the lines of “no”. That did not seem to make sense to me and he and I ultimately disagreed over this point.

Sometime later, I found myself working on a small team (3 ~4 people) developing software. I was the Scrum Master as well as a pseudo architect and a key hands on developer. What I had come to realize is that I spent the vast majority of my time coding and everything I was doing was clouded from that perspective. In my role as Scrum Master, I found myself using the position to drive things from the perspective of a developer. Instead of helping the team focus on delivering value and working with the product owner from that standpoint, I noticed myself addressing the product owner as a developer focusing on meeting development deadlines and telling the product owner what features they could and could not have versus really allowing the product owner to really define the features they needed and valued. Once I started noticing this behavior, I was able to address it …. more or less. There was a constant struggle between the Scrum Master hat and the developer hat and it was at that point that I started really seeing what Ken was saying.

Since then, the vast majority of my engagements have been as a Scrum Master. In most cases, I did wear the Scrum Master hat and often used my experience and expertise in other areas to help the business teams, technical or operations teams in their respective areas. Most of the time it worked out pretty well. The times where it is more difficult is when I become heavily involved in details and implementation and started taking ownership of ideas or deliverables that the lines get a bit blurred. That’s not to say it’s always a bad thing, but in some cases it does have effect on being an effective and fair Scrum Master.

So can someone be a Scrum Master as well as something else? Ken said “no”. I say, in a textbook world it’s not ideal. However, real world situations may dictate differently, so keep an eye on your perspective. Are you being a fair and effective Scrum Master if you are doing something else? If not, what can you do to fix it? Remember, Scrum does not fix your problems but rather it exposes it and if being both a Scrum Master and something else becomes an unmanageable problem that should be listed as an impediment and dealt with.