A recommendation for Boston Scrum Training

I have rarely had the pleasure of dealing with a company as human and transparent as BigVisible here in Boston.

http://www.bigvisible.com/

If you require CSM, CSP, CSPO or other Scrum training, I can say that I have spoken to the vast majority of the big players and BigVisible is by far the coolest.

Short but sweet; I felt compelled while looking at my calendar for March.

I will let you know how the course goes. It will be interesting to see how they present Scrum after having the pleasure of attending a 2 day workshop by Agile Bob of www.agileforall.com and discussing it for what seems like eons, practicing it for a number of years. The more perspectives, the better… IMO. Bob had great visuals and exercises. I am a fan of learning through visual, auditory, tactical, and as many senses as possible.

Best,

Josh

Feature Analysis Spin

It used to be that you could identify the priority of a feature by using a few metrics such as user value, business value, and technical difficulty. Those are really the three biggies, and I think those days are really gone if we are going to be honest. In software development, people love things that help quantify the problems or illustrate what can be a black box of development. I do not aim to devalue the FFA, but only put it in context a little. Truthfully, I did not know that this was called an FFA until a small development shop let me know that of course, there was an acronym for that. The same development shop happened to assign a value to Business Value without Client input, so just goes to show: you can know the acronyms and sound good at the presales meeting, but when it comes to building software, all that fancy talk falls away and you better be able to deliver. Everything in context.

Anyhow, say we have two tasks, one super easy and one really difficult. For sake of illustration, we will assume the same UV and BV.

As a side note, you can apply multipliers if, for instance, there is a reason to favor BV over UV or vice versa. That is *usually* the way I do it, even if it is BV(1.2) or UV(1.1). This is often referred to as a flexibility matrix when discussed and shown as a standalone concept. It is just a way of weighting things. See a rather strange perversion of the Iron Triangle (Time, Scope, Cost) for a nice writeup on the flex matrix. That is what the cool kids call it. Flex matrix.

Hard Task (scale of 1-5 with 1 being low)

• Business Value 2
• User Value 2
• Technical Difficulty 5
  • Total of 9 (BV times UV times TD)

Easy Task (scale of 1-5 with 1 being low)

• Business Value 2
• User Value 2
• Technical Difficulty 1
  • Total of 5

So here we would have the Hard Task ranking higher in priority than the Easy Task.

Funny: what happens if we change “Difficulty” to “Ease”?

Hard Task (scale of 1-5 again, with 1 being low)

• Business Value 2
• User Value 2
• Technical Ease 1
  • Total of 5 (BV times UV times TD)

Easy Task (scale of 1-5 again, with 1 being low)

• Business Value 2
• User Value 2
• Technical Ease 5
  • Total of 9

It changes things completely. It makes our grid of values and features/tasks Agile.

What was changed was the value of effort. Low effort is valued higher with Technical Ease. You can start knocking things off your backlog quickly this way. That is, for all the tasks that exist independently and without dependencies of external factors of any sort. It also assumes that low effort means quicker execution, which is not always the case.

Constant re-evaluation during your iterations will change the values that each task has assigned. The numbers, and backlog priority, will change. Even if you are not doing Scrum, this can be used to track features or tasks within any methodology that I can think of right now aside from strict “The GANTT IS GOD” SDLCs. No offense. I once worshiped the WBS like nobody’s business and yeah, do still use them sometimes although largely in an informal setting.

That said, with the devaluing of difficult technical tasks, you do not get to pay less attention to them right away. Indeed, certain flags are thrown when something is going to be very hard technically. This is where some Agilistas (I think they like to be called that instead of Agilists) miss the boat. Discovery is important, and you know how much discovery you need when you do it. Not before. I can mention a time I had a Client who said we would need to interface with his MSSQL Server. No problem, right? Eh… this thing was not only on an old haggard machine, but was fed old data by a complex and convoluted Foxpro system. It wound up being a huge task and Foxpro was replaced. Or, a reversed scenario: I can think of a time that a Ruby on Rails front end was proposed for an Ektron CMS installation, and it looked perfectly straightforward on paper.

Thanks for your time,

Josh

Mikey the Agile Dog

Dogs over Process? He prefers to be called an Agilista instead of an Agile Dog, but he can write his own blog if he cares so much. I am tired of arguing semantics with him.

Agility is not a singular method nor set combination of methods. Some of it is instinctive and even, I would argue, unnatural to prevent.

In the interest of full disclosure, Mikey did pay his $1200 and sat through a ScrumMaster lecture, so he is a Certified Scrum Master but is having trouble getting his Certified Scrum Practitioner certification.

Yes, this is oversimplification, but there is a point here.

In the completion of a task, driven by a measure of success (a test, in this case verbal), some Agile principle are more visceral than discipline. I think that is as important to understand as how many items your Kanban board can hold or Peer Programming (for instance) when you take on an Agile SDLC.

It’s also a decent example of what a PM can do in an Agile environment, maybe. You have to reach a bit for that one, but the damn dog is so cute.

Best,

Josh

Agile Bob and Certifications and Me

People laughed at the idea that you could sit in a room for a day and become certified as a ScrumMaster. I was among them. It is the main reason why I did not go for the certificate: it did not mean nearly as much as experience and practical knowledge. I really thought it was positively absurd and a blatant pilfering of innocent pockets.

But then they went and created the Certified Scrum Practitioner. They supposedly (and I believe they do) look at your work history and make you demonstrate that you know what you are doing and have done it before. That is a certificate I would go after.

To become a Certified Scrum Practitioner, you need to first be a Certified Scrum Master. The courses are well over a grand, with most in the Boston area being arounde $1200-$1400. Before there was the Practitioner certification, classes were cheaper. I have the experience required to be a certified Practitioner – several times over – but I need to get the initial stamp of approval (ScrumMaster) first. It is a bit aggravating. You should be able to just jump in where you fit. Seems like waste to me. Then again, like most things of value, there is a cost associated.

Now, HR departments will have an actual technical certification to describe the Agile team leaders and Project Managers who have become SDLC champions, Agile evangelists. PMI is trying to be Agile-aware, but ehh…. kinda a whole lot of mess there (muda, yeah?) for my purposes. Plus, I have spent way too many hours studying PMI for the sake of going after a PMP to want to get back into it. It just did not help me as a Manager. It was busywork, overhead, non-applicable academic theory, in many ways.

A few weeks (months?) ago I got in a little Twitter battle with @agileforall. I felt he was branding Agile philosophies and misleading people into thinking that he could teach them THE WAY. Add to that the lack of tone in a 140 character tweet, and feathers can get ruffled. I am also, I have to admit, the kind of guy who always tries to tackle the guy with the ball. It is probably a character weakness, but I like to challenge. I stay completely professional, of course, but I am sure I am a giant PITA.

Bob came to Boston. I had my views and prejudiced towards him and his class. Long story short, the blame falls on my pernicious challenges and poor communication (a sin).

I sat through 2 days of Agile for Teams with Agile Bob at www.agileforall.com and he was great. I didn’t learn very much, but that was not the point. In Agile development, there are so many ways to spin things that I really wanted to see how Bob presented it. He was kind enough to invite me to audit one of his classes and it was pretty cool to see some of the visuals, hands-on exercises, and practical offerings in his coach toolbox. It was a great time, Bob is  agreat guy, and I look forward to seeing how he responds to some of my comments.

Let me say, I am available for this type of class as well. Bob can feel free to throw me some Clients.

Anyhow, that led me to discover that the Agile world was moving on and had heard the proclamations that being a certified ScrumMaster was like sending a check to some address in California to become a minister of the Church of Something Very Odd But Somehow Legit.

But yes, they have done it; they have made Agile certification meaningful.

Damn. Now I have to spend money. I hope the Scrum Alliance does not turn into a corporation like PMI. Let’s set the bar a lot higher and put the measure of quality on the ability to perform a task and add value, not the ability to memorize a billion factoids.

Please.

Best,

Josh

Book of Knowledge

“The Path” sounds pretty heavy, but it exists out there in the amorphous world of SDLC methodologies and more accurately, the PLC. It is that common abstraction and line that runs through each but might not be so easy to articulate. You might liken this Path to the common truths that religions share without being called ridiculous. You would be left with a wonderfully broad palette of tools and discoveries resultant from freedom. I was a philosopher so religion kind of slid aside for me and was trumped even theoretically by the proclamation that I cannot worship a God I do not know exists. Pascal’s Wager is a cop out, although it is still used in IT “Best Practices”. The whole idea of Best Practices is absurd unless you restrict it to a very definite activity, at which point it defines that activity and you have a tautology.  Every project methodology shares the same *fundamental* goals. Every project shares something.

Just like religion, once instantiated in a human being or group, it can become enlightening and serve as a source of strength or if you are a skeptic, an imperfect but workable guide. It can also rip a team apart faster than an army of Google Recruiters. Here is where something fairly subtle has created a problem; it is a problem that needs immediate remediation.

You have a project lifecycle (PLC) and it details your project from start to finish. You also have a software development lifecycle (SDLC), which details the way the “work” happens and the stuff gets done. The PLC is a kind of container for the SDLC.

I am not sure that this Path (PLC) is anything more than one of Ayer’s Universals, to be honest. Sure, to have an end you need a beginning, but is that a construct or acho fundamental truth? Or, is it the way we have chosen and come to understand the world? A PLC is a way to choose to understand the process of a project. It is something you might find in an employee handbook, or “The Book That Describes OUR Process”. Once you get into the SDLC, there is magic and other cool stuff that is not so easy to capture without doing. I really do not care if you have a Scrum or an XP or a Waterfall SDLC. Compare it to another instance of the same. There will be differences. They may be small, but they will be *important*.

A PLC and an SDLC are both methodologies, although quite different in the amount of science that can go into them as opposed to the amount of theory (in this case, science is objective work). The PMI insists that they do not teach a methodology. Still, they produce PMPs, which are people who have mastered their Book of Knowledge. Book of Knowledge?  If you did not know, yes, they really call it that. There is a PMBOK, or Project Management Book of Knowledge. You get it as part of a package with logos all over it. Apparently, some long-bearded geek came stumbling down a hill with it one day and fell down, proclaiming the way has been revealed. You just need to go buy some PDUs, spend a little money every so often, and you will also glow with the wisdom within the Book of Knowledge.

I didn’t say it sounds like Scientology. I didn’t.