Pyxis

One of the neat tricks of dynamic languages like Python, Ruby, Javascript or even PHP is that you can try any snippet of code in your own little sandbox before you actually use it. This is great for exploring APIs, for learning purposes or for small proofs of concepts.

Let’s take a very simple example. Let’s say you come from a .NET background and are very found of LINQ. You would like to know how this expression would translate in your dynamic language of choice. Here’s a way to do it.

LINQ expression

from name in names
where name.Length > 3
orderby name
select name.ToUpper()

Python

Assuming you are runing on a Unix machine simply type python in a terminal. Once in the interactive interpreter, you are free to do pretty much anything you want with the language. You can import any eggs you have installed and anything that is in your PYTHONPATH. You can even add paths to your PYTHONPATH on the fly if you want to. At the prompt you would simply type the commands you want until you get the desired result.

Here’s a way to translate the above expression in the interactive interpreter :
>>> names = [ "guy","jean","bob","serge","jacques","yvon"]
>>> sorted(name.upper() for name in names if len(name) >3)
['JACQUES', 'JEAN', 'SERGE', 'YVON']

Pretty concise expression wouldn’t you say? The last line is python outputting you the result of you query. Neat huh ?

RUBY

Ruby had it’s own interpreter. It’s called IRB. On most UNIX machines, you will need to install it, unlike python. It pretty much works the same way as the Python interactive interpreter.

You start it by calling IRB. Then you have access to pretty much anything you’d like just like in Python.

The console looks like this:

irb>names = [ "guy","jean","bob","serge","jacques","yvon"]
irb> names.select {|name| name.length() >3}.each{ |name| name.upcase}.sort
=> ["JACQUES", "JEAN", "SERGE", "YVON"]

IRB also kindly print out the results.

By the way, all the examples above are built into the language without the need of anything like LINQ.

Javascript/jQuery

As far as Javascript in concerned, the way to have some fun is to use the FireFox add-on called FireBug.

One there, simply go into the console section and any Javascript library that is available in the page you are currently viewing will be accessible. For this example, we playing with the jQuery library by going directly on the jQuery.com site. Isn’t that sweet. Wanna resolve the above LINQ query using FireBug as your sandbox ? After some fiddling here is the solution I came up with :

var names = [ "guy","jean","bob","serge","jacques","yvon"];
jQuery.grep(names, function(name){return name.length > 3})
.map(function(name,i){return name.toUpperCase()})
.sort()

FireBug kindly prints out the result of my execution as this :

["JACQUES", "JEAN", "SERGE", "YVON"]

PHP

How bout some PHP ? PHP comes with it’s own interpreter.  Simply type php -a in a console. It’s not as cool as Python’s or Ruby’s but it does a decent enough job. So how does this expression translate in PHP ? Well, it’s definitely more verbose, but at least you got to try it out in a sandbox first to minimize any surprises from the quirks in the language.

php > function toUpper($name){return strtoupper($name);}
php > function longerThanThree($name){return strlen($name)>3;}
php > $names = array(“guy”,”jean”,”bob”,”serge”,”jacques”,”yvon”);
php > $filteredNames = array_map(“toUpper”,array_filter($names,”longerThanThree”));
php > sort($filteredNames);
php > print_r($filteredNames);
Array
(
[0] => JACQUES
[1] => JEAN
[2] => SERGE
[3] => YVON
)

Conclusion

There you go. Mission accomplished. Had you done the exercise yourself, you just would of quickly learned how to write a snippet of code in 5 different languages !

I think this is all pretty neat. As an added bonus, besides the PHP example, all solutions are very elegant and were discovered using trial and error as a learning tool. Something that is unfortunately not available in non-dynamic languages.

-Nicholas Lemay

After a few months of Agile coaching things were starting to look brighter over at FreeFall inc. The Agile process was slowly but surely setting itself into place. Problem was, even though the team was pumping out an all out effort, their capacity to deliver was shameful. Tim had managed to convince FreeFall to hire Andrew, an Agile developer to give more technical coaching to the team.

“Man, I can’t believe this. The build machine is dying on me again !” Shouted Andrew
“Again!? What did you do ? ”
“I’m running the analyzer on our code. The code is so bad that ALL the code analyzers are dying on me”
“You’re running this on a 486 with floppies or what?” Asked Tim.
“If only I was. This machine is state of the art. Cost them a fortune. Man, it really looks like we have a serious case of skunk code here.” said Andrew

“Skunk code ? What’s that?” asked Tim
“Well you know some animals have defense mechanisms more evolved than others. The skunk for one, well, it just plain stinks. Most of it’s defense comes from just plain stinking so bad you won’t dare approach it.”

“I see. How does it relate to code ? ”
“Well you see, code usually starts with the best intentions. Then people introduce small flaws here and there.”
“Ever heard of the broken window principle ?”
“Can’t say I have.” said Tim perplex
“Well it’s a pretty simple theory. You break the window of a building and don’t fix it. For some reason, people who come next will notice it and take less care of the rest of the building. Within a year the place might actually start to fall apart.”

“Interesting, looks like what we have here. How does that relate to my skunk smelling code though ? ”
“Well you see, at some point the code base will contain so many code smells, people will be so repressed by it that nobody will dare touch it to fix it.”
“It thus becomes protected from ever being touched. Just like a skunk.”

“I see. What should we recommend to the client ?”
“Well for one they could stop adding more smells to this mess.”
“Any new code has very little reason to be messy.”
“How could they prevent that ?” – Asked Tim
“Behaviour Driven development or Test Driven Development properly applied should help a lot.”
“Take Cucumber, GreenPepper, xUnit, Rspec or whatever else you can think of and learn how to use it and why.”
“Pair programming should also be mandatory on most if not all coding activities. Try it out. Most people can’t go back to their old ways once they try it”
“Running the analyzers on the code can also give a hand, although it cannot replace the above two practices. Give a look at Sonar and the likes and find out what can help you or not.”

“That’s nice. How about the existing code ?”
“Well that’s gonna have to wait till I get my build machine running properly.”

Nicholas Lemay

In the same thread of the very entertaining series from Eric “An Agile coach’s journey into PMI country”, I stumbled upon an excellent paper from Charles G. Cobb that summarizes the most popular misconceptions about Agile and makes a pretty clear comparison with the PMI PMBOK. The paper ends with a list of the major challenges an organisation would face in its transition to a “more Agile” development process.

It’s so clear …and true; I wish I wrote it…

Nice work Mr. Cobb!

Becoming More Agile, A Project Management Perspective By Charles G. Cobb, PMP

Casey viator@Colorado Experiment - photo credit to oldtime strongman

”If you find a man in the desert who has been digging a hole with his bare hands for months and you show him a shovel, he will probably try to kill you with your own tool. If you dare come back later, he will still be digging the hole with his bare hands, even though he still has your shovel with him.” — Unknown

The muscle memory theory

In 1973, the Colorado experiment was conducted in order to test the effectiveness of brief and extremely intense exercise. The pictured subject, Casey Viator was  a de-trained bodybuilder coming off a year long layoff. The experiment lasted exactly 4 weeks. By the end of the 28th day, he had gained 63 pounds of muscle and lost over 17 pounds of fat. To the author’s knowledge, such results had never been produced prior to this experiment and have not been replicated since. The results have often been attributed to “muscle memory”.

The theory behind muscle memory is that the body always tries to maintain a certain balance. In order to grow, it has to be overloaded in order to give the body the signal it needs to adapt. Over a period of time, once the body grows accustomed to a certain level of muscle size/strength it then becomes the the new balance the body tries to maintain.

When someone is under stimulated, the body will regress somewhat rapidly until it falls back to it’s “balance level”. Once there,  it will try to hold on to the balance it was accustomed to. Eventually, since it is under stimulated, it can actually regress back to previous levels of size/strength since higher levels are no longer required. But with proper stimulation, it can grow back to the previous maximum levels in less time than it first took to reach those levels because of the so-called muscle memory.

When it comes to human behaviour, the same phenomenon is visible. Just like with with muscular balance, the body seems to try and maintain it’s comfort zone as some sort of defence mechanism. Once taken out of the comfort zone, it often triggers the reflex of going back to the old ways of doing things, no matter if it the previous behavior has a positive effect on the person or not.

An Agile transition as an example

When putting forth a transition in an enterprise such behavioral patterns must be understood and dealt with. Let’s take an Agile transition that takes employees who are used to a very hierarchical environment and are moving into self-organized teams as our example.

Applied to teams

For starters, let’s take a look at something as simple as task assignment. This shouldn’t be rocket surgery right ? Well, it depends on you standpoint.  Many people have become so accustomed to having tasks assigned to themselves they have a hard time dealing with the relatively simple responsibility of self task assignment. Actually, many people will look around for somebody to assign something to them or pretend they are committing to something while in fact they let everybody else decide and take what’s left.

Just dealing with the Product Owner on the appropriate scope of a sprint is something a lot of team members might find hard at first. Telling no to somebody who is asking you to do more stuff is not the usual behaviour most of us are accustomed to. Not convinced. Here are some examples. When we were young, we were expected to do what our parents asked us to do. In school, we were supposed to act the way the teacher asked and to do all our homework. At work, we are supposed to accomplish whatever work we are asked to do. See a behavioural pattern there ?

On the technical side, it is quite the challenge to ask developers with 20 years of experience who have never written a single test in their lives to do all their programming test-first. By TDD we don’t just mean writing test. What we mean is that while developing software, not a single line of code is written without a test written to test it first. None.

Funny thing is, once most people get the hang of TDD, they will have a hard time going back to your old ways. Unfortunately, you will often find programmers skipping tests altogether, even though they are at least aware of the benefits. In extreme dissonant cases, some will be sabotaging their own work on purpose for no apparent logical reason other than to maintain their previous ways of working.

Applied to managers

It also works the other way around. Having power over people is something that is seemingly very hard to let go of. In Agile teams, management is often seem as an umbrella protecting the team or as a coaches. Either way, they are helping the team attain it’s goal while supporting it when it needs to and protecting it from distractions. Other responsibilities might be helping team members get the proper training and also by keeping them on track regarding delivery objectives.

It requires a lot more soft skills to be a successful Agile manager than to simply be someone who’s main attribute is to dispatches work. It also involves the humbling task of letting go some of the grasp managers often have over every doing of their employees. It is only too common to hear about managers embracing Scrum, only to find them minutes later behaving exactly as they were before. This is done in spite of them being entirely aware that their previous behavior is unproductive and is what conducted the requirement for change in the first place.

Just like with weight training, it takes a long period of stimulus for the body to recognize the current state as the state the body needs to maintain. It is the same with change, the longer you keep at it, the more and more it will feel natural and it will just become the new habit. Remember, some things you think of as an habit now might have once looked to you as insane too.

-Nicholas Lemay

My journey is actually the PMI bootcamp – A five day course to prepare for the PMP certification, completed with fellow Agile coach – and it has allowed us to see some great stuff.

To the left, we had beautiful Rolling Waves and to the right, Progressive Elaboration. Most days were warm and sunny in PMI country – running through the green fields of cost, risk, and talent, oops! HR management. But these dark clouds kept showing up once in a while and without warning, a bolt of lightning would reveal this official process: “Create Work Breakdown Structure” a.k.a. the WBS.

What we’ve got here is process number 3.4.4 in the PMBoK and this, I believe, is where the PMI got cocky. WBS is so central to the PMI that our trainers would actually say that if you don’t have the answer to a certification question and WBS is one of the options – choose it!

Throughout the PMI-PMP bootcamp training I kept asking myself the same question – If these PMI trainers recognize the distinctive nature of project management within software development, why am I getting so much resistance in the field?

My last blog generated some parallel discussions in the Scrum Practionners Group on LinkedIn, and some of the replies did shed some light.

Doug Shimp stated:

“The difference [between a WBS and the Product Backlog ] is big and forms a paradigm shift in thinking equivalent in magnitude as going from procedural code to object code. This is not easy and takes most people months to understand by doing an applied practice.”

He continued to say:

“This is one area I see messed up so often, it is painful. Our training community must get much better at understanding and teaching this stuff. For PMs coming from an long history of using an activity based WBS the change to an agile/scrum format can be quite head rattling.”

This is exactly why my colleague and I attended the PMI training. We need to understand where PMs are coming from. What are those things that prevent PMs from making the shift? The WBS seems to be one of the culprits. I’m not saying a WBS is not practical or even essential in some cases. Maybe upper management demands this type of breakdown and is not quite ready to deal with a simple and naive release burnup chart based on tested and working software, available on a pre-production server. Ok, I’m being a bit facetious. I do see value in a high level WBS that identifies product AND project requirements. I’d just assume use a mindmap but that might be too “fluffy” for some. There I go again. A WBS can provide some great value by:

• Defining deliverables
• Helping to define what DONE means
• Establishing a common language
• Setting up Organizational Breakdown Structure (OBS)
• Managing change

I might even encourage a team to create a WBS and link it up to their Product Backlog if I thought it would add value to the project. But for the most part, the Scrum teams I work with start with a Product Vision broken down into clear business objectives. We then identify the Epics required to achieve those objectives and wrap up with just enough User Stories to get started.

One thing, new agility seeking organizations can be certain of, is that WE WILL set aside the WBS, just like we would any other “traditional” tools and methodologies. I might recognize the immense potential value of their WBS, but as an experiment, we’ll leave all that aside, start anew, and see what happens. Every 2 to 4 weeks, we’ll inspect, adapt and start yet another experiment.

Of course there are those PMs who resist and feel the need to create a WBS and break it down as quickly as possible to the task level. You can imagine their reaction when I tell them that the team will do this at “the latest most responsible moment”. Some PMs almost pee their pants when I add the fact that “the latest most responsible moment” is actually one day before we start coding. I must admit – I do enjoy that one. (Yes, I do practice “Situational Coaching”, and in some cases, “TELLING” offers the highest return on investment)

At issue here is not the potential value of a WBS, but the obligatory use of one. Actually, I wonder if OPM3 would consider our Agile teams “immature” for not having this. Would it recognize the fact that we compensate or even exceed the value of a WBS with Agile related artefacts and ceremonies? CMMi Level 3 does!

But who am I to criticize the fact that the WBS is a required process and not just an optional tool? Scrum does require the use a Product and Sprint Backlog. They’re not optional tools but nonnegotiable artefacts. But there is one difference; Scrum is all about software development. It’s not interested in building sky scrapers or highways. PMI boasts that their processes apply to “all of the above” projects, and I’m fine with that. But if it wants to remain credible, it needs to abstract this WBS process. I’d call it the…Work Refinement through Execution Process. The WRX…I like the sound of that! It might include various tools and techniques such as a WBS, Product and Work (not to say Sprint) Backlog, and some activities to get these to evolve throughout a project.

I think the sun is coming out again. Time to go play with Project Communications Management…

It feels good to have a common enemy, someone or something to hate or discredit. What this usually does is create a sense of unity between individuals who share a common view. We do this with programming languages (Java vs. .Net), philosophies (Waterfall vs. Agile) and even within those philosophies (Scrum vs. DSDM vs. Crystal vs. …).

One of my preferred antagonists was the all mighty monolithic Project Management Institute (PMI) and its PMP disciples. In an attempt to keep my friends close and my PERCEIVED enemies closer, a colleague and I decided to attend the PMI bootcamp – a five day course to prepare for the PMP certification.

As an Agile coach, helping medium to large organizations transition away from traditional methodologies, I am continuously confronted and challenged by Project Managers armed with a PMP certification. Don’t get me wrong, I like being challenged! It actually makes my job easier and greatly increases the chances of a successful transition. That said, I’d like to understand where he or she is coming from. What is the driving force behind a PMP certified Project Manager? Do they have their own manifesto and maybe Project Management Charter? And who knows…Maybe this five day course would offer some additional tools to work with within an agile context.

One of my preconceived notions was that the PMI trainer’s underlying message would have been: “You must plan software projects exactly the same way as you would a high rise project” You must plan the living daylights out of the project, execute that plan and all we be fine in lala land. With my past experiences with PMPs, can you blame me?

I was very disappointed!

What we saw and heard as not an evil empire headed by an evildoer with acute asthma, but an open minded, experienced project manager coupled with a great deal of common sense. Mind you that this refers only to our first day and we get a different trainer every day (BTW, I like the “different trainer every day” concept and thinking we could do this with our Certified ScrumMaster Training – Food for thought and maybe a future post)

What we saw is a slide similar to this one…

…and the trainer actually said: “In I.T., we don’t even know what we are doing next week so don’t start planning to much ahead”.

I almost got teary eyed!

On the other hand, there is also the strong notion that the project manager is fully responsible for the success of the project. As an Agile coach continuously working to establish shared responsibility between the ScrumMaster, Product Owner and development team members, this notion rubs me the wrong way.

Some of the things I did like were:

• Project versus Product Life Cycle
• The Rolling Wave
• Progressive Elaboration: “Continuously improving and detailing a plan… ”
• The 9 knowledge areas
• Process assets (Lessons learned)
• Including “Expert judgment” in most processes

So I guess Project Managers who keep telling me that their sound PMI practices does not allow them to adopt an “Agile” way of doing things are just pulling my leg – some kind of bad joke. Next time it happens I’ll be ready with a full hearted laugh and a high five. Hopefully he/she doesn’t leave me hanging

I’ll be elaborating on the Knowledge Areas and Process Groups in future posts, but for now, suffice to say that I’m prudently putting aside my perceived dichotomy between PMI and Agile.

Stay tuned…

Top 10 Agile events of the decade

1- Creation of the Manifesto for Agile Software Development in 2001

2- Kent Beck re-exposes Test Driven Development in 2003

3- First Agile Conference in 2003, held in Salt Lake City

4- Ken Schwaber releases Agile Project Management with Scrum in 2004

5- Mike Cohn releases Agile Estimating and Planning in 2005

6- Esther Derby and Diana Larsen release Agile Retrospectives in 2006

7- In 2007, some of the highly regulated avionics companies start adopting Scrum

8- The Software Engineering Institute, creators of CMMI, recognizes Agile and Scrum in 2008 (http://www.sei.cmu.edu/reports/08tn003.pdf)

9- The Project Management Institute (PMI) actively participates at Agile 2009 in Chicago and formally launches the PMI Agile community

10- In 2009, some ISO 13485 compliant medical device companies start adopting Scrum

But I must cheat just a bit and add: Kent Beck’s Extreme Programming Explained published in 1999.

As far as he could remember Marc always dreamed of being a pilot. At age fifteen, while most of his friends were chasing girls, he was working 5 days a week to gather money for flying lessons. By age 18, he was already certified as a flight instructor. After a few years of service as a bush pilot in the northern most par of the country, he finally got a break working for a regional transporter. In April that year, his engine was due for it’s 3500 hour overhaul. Pat, the senior technician at Aviair Regional Airlines performed the overhaul, a routine job for him by then.

As the FAA later found out, Pat got pressure from management to do the overhauls faster than usual as they really needed to get those planes off the ground during the harsh financial times of the enterprise. This caused him to leave a pressure hose on that was requiring change but that would also have required ordering a new piece and further delays. Unfortunately for Marc, the part hose up mid-flight three weeks later while flying above mountains. He now had to decide whether he would crash in a farmer field or in a country road nearby. Marc made a quick decision and decided to head towards the fields.

He managed to pull off a text book belly landing in a field that was way rougher than anticipated. When the emergency crew got on the site of the crash they found Marc unconscious and half-disfigured. Had he been a lesser pilot, all 13 of his passengers would have died that day.

Later that year, Marc got decorated for his heroic actions, as he saluted his former coworkers in the assistance for a last time. He saw this as his farewell, the accident having impaired his eye sight beyond possible repair, leaving him unable to get medical clearance and thus revoking his pilot’s license.

As the news of his heroic act got around, Marc started to be asked to give speeches about it across the country. Marc was not seeking publicity although he appreciated all the warm feedback he got, he always politely turned the offers down.

One day, he got a call from Peter, a friend of his that was now a project manager at FreeFall inc. After the usual salutations, Peter got around asking Marc for a motivational speech. In his mind he thought, if people met Marc there was no way they would not be positively influenced by him.

“It might even bring out a hero or two out of my employees you know, the project really is in disarray.” Said Peter
“Well I don’t know much about software development actually.  But why do you need heroes ?”
“Well everything is wrong. I really need someone to take the lead and fix our major issues. We have quality issues like you wouldn’t believe.” Said Peter, with his voice getting more desperate.
“OK. Why do you need heroes? ”
“Because we have quality issues…I already told you that.”
“Ok so you wouldn’t need heroes if you had no quality issues right?”
“What do you mean?”
“Well the only reason I’m unfortunately perceived as a hero is that I managed to do my job properly when someone was forced to slack the quality of his work ”
“I was doing my job properly for years prior to my accident, but you never heard of me in the news did you?”
“Of course not but…”
“Now, if their was no quality problem, your staff would only have to do their job and everything would be business as usual right ?”
“Well yeah.”
“Anything you could do to help the quality of the software your guys are building right now ?”
“Well the guys were talking about getting more time to do more unit testing and automated builds the other day, maybe I should give these guys a talk.”
“Who knows, might save you from having to deal with super heroes. Grown men wearing tights usually don’t go over well in office meetings ”
“Point taken, thanks Marc.”

- Nicholas Lemay

A man’s life is primarly interesting when he has failed.
For it’s a sign that he tried to surpass himself.

– George Clemenceau

Tim was an Agile coach. One morning, he bumped into Andrew, a senior manager over at FreeFall inc, a fortune 500 company.

“Hey Tim! How about that Agile thing? Do you guys still have a daily Scrum in the morning?
“How’s that coming along?”
“I don’t know how to put this Andrew, but we don’t ‘do the Scrum thing’ in the morning.
Being Agile is way more than doing daily meetings.”
“Oh really? What else is there to be Agile?”
“You might wanna grab a doughnut with that coffee, I’ve got a few things to show you.”

Tim went on explaining the different aspects of scrum, the roles and the different ceremonies. But he knew the selling point to the manager was the continuous improvement brought by the frequent inspection and adaptation the team puts itself through.

You see, with Scrum all you problems will become apparent. Think of the problems as cream being poured into a coffee. If you just keep on pouring and stirring all the time everything stays in a confused mess. But if you take time to stop stirring your mess, the cream will rise to the top and you’ll get a clearer view of what’s going on.

To achieve this here are some important steps:

Courage:
You can call yourself Agile if you want to. For that matter, you can call a cat a dog if you want to. But you are not Agile without frequent introspection and a true and deep desire to be better tomorrow than you are today.

This all start with courage. Courage to admit that you can be wrong. Courage to tell someone else that he/she was wrong. Courage to truly listen when someone is criticizing you. Courage to take what is on the table and make yourself a better you. A better team starts with a better you.

Desire:
Why do you desire to become better today than you were yesterday? What is your source of motivation? Are you so disgusted by your current situation that you wish not to have to experience it in the future? Have you seen better and want to recreate it? Do you see change as a desirable thing? As a source of motivation?

Failure must be an option:
If you are now allowed to fail, you cannot become better. You must be allowed to fail in order to be able to freely admit your failure in order to get feedback to help yourself get better. You should never seek failure, but you should not fear it.

Awareness of consequences:

Once you start into this continuous self-introspection game you will be cursed. Cursed for life. You see, most people have exactly the same problems as you and might still go through for the rest of their life. But you WILL see them. Just like Neo in the Matrix can see the code of the Matrix, you will see the problems when people within the mess have no idea how deep they’re in.

So you have two choices. To quote Morpheus talking to Neo:

“You take the blue pill, the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill, you stay in Wonderland, and I show you how deep the rabbit hole goes.”

So what’s it gonna be? The red pill or the blue pill? Because once you take the red pill, there is no turning back.

- Nicholas Lemay