Tag Archives: agile

Searching for miracles

Posted on by

I never liked the words pilot nor proof of concept.   I have been through many pilot projects and proof of concept as projects or in projects.  Although the intention is well understood by everyone at the very beginning, by the time we reached the end, there almost always seems to be confusion about the purpose and next step.  Now I don’t even seem to know the differences and intentions anymore.  Even though everyone seems to know that they are different, they receive the same miracle software expectation.  It’s an execution confusion issue.
But I think the main reason for pilots and proof of concepts is to get feedback.  Spikes do the same thing too.  You know you’re seeking enlightenment when you start saying “I don’t know … enough…” or “It depends…” or “What if.” Whenever we work with a new domain or a tricky part of an application, we are searching for feedback, not miracles.  If you practice TDD and do exploratory testing of concepts that are not 100% clear in design and even understanding, then you know what I mean.  Perhaps we must just drop the grand classification labels and our response should be something like “Well, let’s explore this tiny bit and see what happens” or “Why don’t we try out this idea by doing …”.

So we do proof of concepts and pilots all the time.  It’s just that I hate searching for miracles but I like feedback which helps me change the probabilities of certain of things happening.  And I like it to be part of my workflow.  Exploration gives me feedback and increased understanding that leads to more exploration.  I hate it being a milestone on a Gantt chart and when that milestone is a common point in critical execution paths for the project, then I know, for sure, someone was actually looking for a miracle.

If you are somewhere on the agile adoption curve, then drop the Gantt chart.  Now you’ve just removed the shrine for miracle worship.  There are no shortcuts to enlightenment, just feedback with every step.  Success depends on how you absorb and react to that feedback.

Ambler, Hundermark and now my Two Cents

Posted on by

Peter Hundermark has a nice summary of the talk on Agility at Scale that Scott Ambler did in Cape Town a few weeks ago.  And Scott had the courtesy of straightening out some thoughts on Peter’s blog as well.

Padding End Dates. End dates exist because of our immense desire for closure.  We cannot tolerate the thought of not knowing when something comes to an end.  So we would rather stick in a fake end date than no end date.  Are you prepared to stick an end date on your life, just so that you can create a finite sense for someone else?

Optimizing the whole. For me “whole” means everything, your workflow, your thinking, your architecture, your code, your communication, … everything.  But just drop into the code bit for a moment.  The reason TDD works is because it gives you feedback quicker.  It is not about the red-green-refactor process alone.  You have to be agile in your code and design too.  And linear problem solving results in linear code styles and mindless red-green-refactor results is not agile unless you are 100% immersed in the moment of exploration and discovery.  Overall, I think optimizing the whole, getting rid of wastage, lean, etc is all about finding the right balance – at that point in time, in that context.

BDUF. How much of upfront design is big design up front?  It depends on the context and the principles on which your software development is based and also who is affected by the software that is produced.  I like the phrase “little too much design up front” and “little too little design up front” which I picked up in this post by Kent Beck. (Please don’t acronymize that!).  That particular post was simple and extremely profound view, for me at least.

Just when I thought that I am making progress, I feel like a noob again.

Zen and the Art of Deck Building

Posted on by

Amazing! I just read Scott Hanselman’s blog post on finding geek balance outside of the geek world.  I started commenting on his blog, but realised I was blogging on his blog.  Here’s my own lumber-yard, geek-balance experience.
Just before Christmas, Fiona and I decided to have a deck built in the back yard.  I tossed the contractor’s quote out and decided to build it myself.  Why?  Same reason as Scott and I also specifically wanted to try my own personal Zen and the Art of Deck Building.  Fiona was naturally skeptical but indulged my mid-life crisis moment.

An apprentice in a world craftsmen.

DIY shops are intimidating.  I was an apprentice in world of journeymen and craftsmen.  I eventually found a benevolent craftsman who was humble enough to help me without judging me.  His ideas helped me simplify my design considerably and, more importantly, gave me some confidence.

Really listening to feedback. My paper design was a BDUF :-).  The moment I placed the wood on the ground, Fiona suddenly changed the location of the deck.  Short tale:  I am still building – new requirements still emerge from my main user.  Early on, I resisted every change with enormous annoyance which resulted in huge arguments.  Then I realised that the needs were real and the new requirements came from seeing how the deck looked with each step of construction.  I had an abstract BDUF and Fiona was taking in real feedback –  being agile!  And I was being rigid!

Living in the moment. I tried hard to live in the moment.  When I was digging a hole, I dug the best hole ever, deep, straight and true, until I hit a concrete block in the way.  Then my beautiful hole was a mess and I was angry at this block and tried to get past the block and continue digging my hole.  Zen moment – the task had changed.  I focused on the concrete block. Chipped away one tiny piece at a time, eventually it fractured and I could continue digging my beautiful hole.  I was focusing on the future, not the present and that screwed up my productivity.

Conflicts in collaboration. So I tried to live in the moment with everything from that point onwards.  When I was cutting wood – I cut wood and tried to get the best cut ever – to find beauty in the cut.  The one day my son, Khaleel, helped out and I got annoyed that he was messing up – it was not as beautiful as I wanted it.  After calming down and living a moment of fatherly guilt, I let him help me dig another hole and I just let him … to live in his moment.  He loved the texture, smell, etc of the sand and dirt.  I imposed my own hang-ups of not wanting to get really dirty.  I realised that he was more into having fun and I was messing up his fun – until I decided to live in the moment with him – by his values.

Finding the balance. Building the deck has been one of the nicest non-geek experiences in recent times.  It made me think differently, behave differently, regard people differently and maybe, one day, it will quietly help me build software better.  I think the trick is to find a place where you will always be the traveler in a world of benevolent journeymen.  And when you can’t find that world, then just be a benevolent journeyman in world of travelers.

Correcting my Irresponsibility

Posted on by

I have received a lot of positive feedback from many new faces for the SPIN talk I did this week.  Thank you.
But I am worried.  In the 45 minute talk, I did 5 minutes with Ruby code and cucumber.  Now so many people want to use cucumber.  Good for cucumber.

I think I should have stressed my point a lot more.

Take-Home #1: Find a way to make the life cycle of requirements part of your workflow.  Should it be a hard dependency?  If the requirements change, then do you want the build to break?  When requirements have a life cycle independent of the code’s life cycle, then you are opening yourself to waterfall-ish problems.

Take-Home #2: Agile in name and process can only take you so far.  You have to live it in your head and in your life.  For me, agile has a very Zen-like characteristic.  You need to live in the moment, absorb the feedback in that moment and adjust your next action in response to all this stimuli.  We are just like an amoeba that reacts to changes in pH.  But the difference is that we are capable of controlling our re-action or subsequent action.  An amoeba is agile by process only.

Take-Home #3: BDD can help you to change your coding and architecture attitude for the better.  It is subtle in its intrusion, but profound in its impact.  The subtley makes it dangerous.  It is not about the clever use of words, it is about the way those words impacts on your code and your resulting architecture.  So find your own cucumber and that does not mean you should go looking for another gherkin.

Perhaps I was not responsible enough.  My actions and words have affected people in a way that I did not intend.

Enterprise Scrum and Killing the Stickman

Posted on by

At the 45th SPIN meeting in Cape Town tomorrow, I will be sharing the “stage” with Karen Greaves.  Karen will be talking about the lessons she has learned in rolling out Scrum to a large enterprise.  I have a feeling that it is about scaling Scrum out to more than 10 people.  Karen has done this for 80+ people and I am certain that her experiences will reach an audience outside of Scrum circles as well.
I will also be giving a talk about Agile Requirements.  It’s about behavior driven stories that go beyond traditional, fully dressed used cases.  However, I will focus a lot more about the process and thinking behind this approach as opposed to the code behind the stories.

I always meet very interesting people at SPIN.  Please take 2 hours from your evening and join us for some great geek chat at the Bandwidth Barnyard at 6.30pm on 15 April.

Update. You can get the presentation here.  The size is optimized for iPOD and is quite viewable on your desktop as well.  The tiny bit of ruby code is included in the zip as well.

Digging into Diversity

Posted on by

A few of nights ago I had chat with Scott Hanselman about diversity in teams.  This experience and the .NET Rocks experience were really important learning moments for me.  Although you have the opportunity to “rewind” and be edited, I decided not to do that and just let me be heard as I am – unedited.
As usual, we all tend to be our own worst critics and I know I have some bad habits.  These are the ones of which I am most aware.  (a) I ramble on a bit before getting to the point and I miss the point sometimes, (b) I tend to interrupt people when they speak, and (c) I unconsciously complete people’s sentences.  Have a listen to the Hanselminutes podcast and please give me your feedback, good and bad.

The show could have gone in any number of directions but Scott did an amazing job of keeping it on a particular path.  There were some things that I thought about after the show and just want to elaborate a little bit.

The code that you write affects people on your team. Although we glossed over this and it felt like a weird application of Ubuntu, I really believe that your code impacts other people on your team.  I always joke about not carrying code to your grave.  Seriously, your code will be visited by the “second” team because your project is never complete until the “second” team comes into play after your first production release.  So writing code that is a positive experience for someone else is important.  Anyway, your code is collectively owned, and read more than written, right?

Greetings and introductions should be meaningful. The words that Scott used to describe me are nothing more than tangled mess of words that are superficially meaningful.  From that description, all you can do is categorise me by your previous stereotypes associated with those words.  Knowing people and learning how they feel at that moment in time and making that meaningful is all about discovery focused conversations.  Most people know that I really look for simple solutions to everything.  Having a conversation is easy, but choosing the right words to say is tough, especially if you are protecting yourself with a personal space wall or probing through someone’s personal space wall.

Learning is more important than being the best. I now really believe that just learning to be better for yourself is the most important thing.  It is a personal thing only.  It is not about being the top dog.  Aiming for top dog is an ego trip and power positioning becomes a vehicle for the journey.  Power destroys lives and spirits.  I have been down that road, practiced it, hated myself and been a subject of it as well.  I call it power oriented architecture.

Values and behavior compromises are contextual. We spoke a bit about clashing of value systems and I said that it is about compromise.  I think compromises only work in a context.  I have a  friend and it bothered me that he was, on occasion, a snob.  After a long time, I made peace with his snob-mode.  He was a snob in certain contexts and I acknowledged that and looked passed that and realised that the value systems and derived behavior we exhibit changes as we shift through contexts.  Ideally, it shouldn’t but we are humans and are fallible.  (Sure, we do have core values that are consistent across contexts.)  Knowing when people are applying altered values and behaving accordingly can help you create contextual compromises that can lessen the possibility of conflicts in teams.

Soft skills do not have hard recipes. Scott kept pushing me about techniques that we can use to work through these challenges in our teams.  I really did not have any.  After we stopped recording we both said that these are soft issues and there are no hard techniques.  Soft is soft. Period. It is really about becoming a better person – for yourself – and in so doing you become a better person for others.  I can’t coach this or teach this.  I can just share my experiences and thoughts on this.  And I am so very far away from not “being a jerk” as Scott politely put it.  The one thing I have seen consistently is that your “jerkness” is inversely proportional to your humbleness.

Voting for the first time in 1994 was significant. I opened the discussion about the important junction in time when apartheid was abolished and we voted freely for the first time.  This was significant because it divided our search for identity into two distinct eras.  It’s hard to manage diversity if we don’t have own identity.  Secondly, it was the most harmonious, collective experience of my life.  We stood in a queue from 8am to 6.30pm in Yeoville in Johannesburg.  In the queue we had old, young, black, white, Rastafarians, Muslims, Jews, almost every categorisation you could think.  But it was peaceful and celebratory.  It proved to me that human beings are capable of living together when we share a common ideal that we all believe in … even for one single moment.

If the real me is not Scott’s intro, then who am I? I am Aslam Khan.  I am a software developer.  I am a father, a husband, a brother and a son.  I am a neighbour, a friend and nice guy and a jerk. I am 40 and I am looking for balance.  I have two kids aged 8 and 5.  My thoughts are pre-occupied by the challenge of being a parent. I treasure my time with my family immensely but suffer serious guilts by not doing so.  My 5 year old child has a terminal disease and is classified as cerebral palsy which changed my view on many things.  My 8 year old child amazes me at his simplistic maturity and makes me realise that I am unnecessarily complicated.  I am a citizen of this world.  I wonder how many people will come to my funeral – it’s my measure of meaningful engagements.  I question whether writing software is a good way of becoming a better person.  I am hopeless at character assessments and my wife is my Deanna Troi.  I exist.

Measuring the Clarity of Requirements

Posted on by

The last two geeky conversations I had, stumbled upon the same thing – how do you measure the effectiveness of requirements in describing the business to the business and describing the specification to the developer?
So, I posed the question “How far away are you from executing your requirements?”. If you are going to go through various steps and stages to get to compilation and then execution, then every step is an opportunity for valuable information being lost in translation. If you can compile your requirements immediately then nothing will be lost.

Each additional step between requirements description and compilation and execution is an opportunity to confuse the user and the developer and everyone in between.  That’s why fully dressed use cases are not so effective as fully dressed behavior driven stories.  And that’s why BDD is very agile and a great asset in DDD and use cases just don’t cut it anymore.

Right now, my favorite tool is Cucumber.  I can execute the requirements and that raises the clarity ranking of my requirements super high.

Øredev Presentations

Posted on by

My presentations from Oredev are finally available.  After working through almost all the export options on Keynote, I have settled on QuickTime as the distro format.  The “flying code” in the aspects presentation worked out best with QuickTime.  Note that it’s not a continuous playback and you have to click-through each frame.

Øredev 2008

Posted on by

I’ve mentioned it in bits and pieces before but now that the nice folk at Oredev have more or less finalised their program, I can put the down the talks I will be giving in November 2008.

I certainly did not expect to be doing 4 sessions!  It’s going to be a busy conference but also immense fun.  I hope that I get the time to attend the other talks and learn from some amazing people.  I certainly will be catching up with old friends as well

Introduction to BDD

Posted on by
I will be giving a short introduction to behavior driven development (BDD) at the XP forum on 13 August 2008.  As usual, I’m using the opportunity to subtly throw in some other practices such as coding for readability and designing good messages.  I will also touch on mocking in tests as well.

I’ve been having immense fun putting together some code examples for this talk and I hope to demo BDD using JUnit, JBehave, RSpec (using the rbehave story runner on JRuby to test Java) and JTestR (which looks like a really exciting little project).

Come along and enjoy the fun.  Details and registration is on the JCSE web site.

Update 1: The Source Code for BDD Presentation is now available.

Update 2: The presentation is now available for download here.  It’s a 5MB Quicktime movie file. It’s not a continuous play movie, so you need to click through to the next slide.