The Agile Way

Denying facts you don't like - Seth Godin

Tue, 02 Oct 2012 22:03:39 +0200

Transformational leaders don’t start by denying the world around them. Instead, they describe a future they’d like to create instead.

Denying the truth about relative market share, imperial power or the scientific method helps no one.

Gandhi didn’t pretend the British weren’t dominating his country, and Feynman didn’t challenge Einstein’s theory of relativity or the laws of thermodynamics.

It’s okay to say, “this is going to be difficult.” And it’s productive to point out, “our product isn’t as good as it should be yet.”

The problem with Orwellian talking heads, agitprop, faux news and Ballmer-like posturing is that they take away a foundation for a genuine movement to occur, because once we start denying facts, it’s difficult to know when to stop. Tell us where we are, tell us where we’re going. But if you can’t be clear about one, it’s hard to buy into the other.

"You can’t build a differentiated product without building a differentiated culture."

Tue, 02 Oct 2012 00:09:20 +0200

“You can’t build a differentiated product without building a differentiated culture.”

- Aaron Levie

"Change takes place when we manage to transform the excitement into discipline."

Tue, 02 Oct 2012 00:07:16 +0200

“Change takes place when we manage to transform the excitement into discipline.”

The deal [too happy, too soon...]

Thu, 12 Jul 2012 00:46:28 +0300

The cool thing of reading this article from an agilist point of view is that you will be able to understand the reason why sometimes it’s awfully hard to have a development completed in time. There are just too many external influences involved in a project that it’s progress now depends not only on the developer, but in all the interfacing services you have. Let’s get to my issue;

After my previous topic, I was quite happy with the approach I tool regarding the Liant Relativty Data Client. Then, I woke up the next day to realize that all that I’ve done isn’t really 100% good news.

Here’s the issue:
I can easily connect and list the data set from iSQL, however, when I use odbc_connect() inside my PHP it all breaks… Yep, it breaks.

According to my research, this issue has to do with a version mismatch between PHP and the ODBC layer! :(

As soon as I find a solution for this issue I will post it here.

All the best!

Git Cheatsheet

Tue, 10 Jul 2012 14:06:37 +0300

gfader:

Git Cheatsheet by Andrew Peterson
http://www.ndpsoftware.com/git-cheatsheet.html

For an agile production environment, Git is one tool that I really really recommend. As a developer, there’s nothing worse than the lack of a Version Control.

Your team needs to view the cheatsheet below! :)

Agile Core Consulting: Where to invest your first marketing dollars?

Tue, 10 Jul 2012 14:03:43 +0300

Agile Core Consulting: Where to invest your first marketing dollars?:

agilecoreconsulting:

Assuming you have a basic website for your business and your business has customers to prove the point that it is a good idea. How do you take your business to next level? You need to of course gain more customers, offer more features or products and you need to identify a starting point to that….

Awesome read…

INSTALLING RELATIVITY DATA CLIENT ON UBUNTU 64-BIT

Tue, 10 Jul 2012 01:51:00 +0300

Here’s the deal: I have to interface with a COBOL application using Micro Focus (www.microfocus.com) Relativity Data Client to interact with the data. Yes, you heard it right – COBOL.

Most of you must not know, but here’s a quick definition of what Relativity does by Micro Focus:

Relativity provides access to data contained within files managed by COBOL applications that via ODBC interface presents data to a program in the form of tables to access the COBOL data in a proficient way.

(source: http://www.microfocus.com/downloads/relativity-152334.aspx)

I like the way they do business, their documentation is up to scratch and all the files supplied are great!

But… I’m not very lucky, so it happens that our server – of course – is 64-bit and Relativity DOES NOT PRODUCE 64-BIT Relativity Data Client for Linux.

Bingo! Here I find myself again “googling” around to see what I could do to get it to work.

I got some help from Google and from Micro Focus, here’s how to install Relativity Data Client on a Ubuntu 64-Bits (I promise you this is all you will need to do!)

Even though I assume you have already suffered for at least 2 days before finding this article, I will assume you haven’t done anything yet. So I will take you from the bottom up.

0 – Installing ODBC 32-bits on your Ubuntu 64-bits

Here’s what I’ve done:

> sudo aptitude install ia32-libs
> sudo apt-get install g++-multilib
> mkdir ~/src
> cd ~/src
> wget ftp://ftp.unixodbc.org/pub/unixODBC/unixODBC-2.3.0.tar.gz
> tar -xzvf unixODBC-2.3.0.tar.gz
> cd unixODBC-2.3.0/
> CFLAGS=-m32 LDFLAGS=-m32 CXXFLAGS=-m32 ./configure
> make
> sudo make install

That has installed the 32-bit unixodbc libraries into /usr/local/lib, you can confirm that by running the following:

> file /usr/local/lib/libodbcinst.so.1.0.0

should say

/usr/local/lib/libodbcinst.so.1.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

This response tells you that you now have a 32-bit installation of the UnixODBC library. You can now carry on!

1 – Get all the files you received from Micro Focus and upload that to the server you want to install the data client on.

The file structure should look something like that:

· Dclient

· Docs

· Udrvman

· Autorun.inf

· Cpyright.txt

· Install.sh

· LiantInstall.exe

· License.txt

· Readme.txt

This is the main structure that you should receive from them. Most of those files we won’t use – you know how they work…

Inside the folder dclient, we must have a folder called 070. Each folder is destined to a different OS distro. And even though 070 isn’t the one for Linux 64-bits, we will make use of that to get us going.

They have a very nice documentation that describes the step by step of getting the driver installed (if you haven’t received it, give me a shout and I can supply it to you).

Now, here’s one important information: the TERM used during your install must be ansi! So, on your xShell or putty, input the following:

> TERM=ansi ; export TERM

Now, your term must be defined to ansi – by default, your TERM should be vanilla.

This step is done!

2 – Remember the files you received from Micro Focus and uploaded on to your server, go to that folder.

You will see a shell scrip called install.sh

COMMENT:
According to the Micro Focus documentation, it’s suggested to created a folder called RelStage to host all the files that are created with the installation – but because you have the option to remove all the files once installation is completed, I didn’t bother with that. So I went there straight and input the following on xShell:

> sh install.sh

That got the installation going.

3 – The installation script ask about the source files for the installation, put the following:

dclient/

That should get you doing.

4 – A bunch of questions gets asked. You just need to hit enter and be happy with all the default values. You can also input – when asked – your server name and the default port used for the connection. That will save you time later on.

5 – The installation should be completed! If you get an error saying that two files couldn’t be found, that means that you don’t have the ODBC 32bits installed. Go back to step 0 and do it all again. Sorry mate!

Now, all is installed. So in theory you all ready to go. Not for me. My connection wasn’t working.

Here’s what I did:

6 - Confirmed the driver was installed, mine wasn’t

> /usr/local/liant/bin/reldriveradmin —list-drivers

The driver wasn’t there – so…

7 – Install the driver (if your driver is installed – you can skip this step – you are a very lucky man)

> /usr/local/liant/bin/reldriveradmin —install-driver “Relativity Client” —directory /usr/local/liant/lib/

That should install the driver

8 – Added a server – initially my didn’t work:

I checked if the server was installed properly. If it’s not, below is the line to have it added.

> /usr/local/liant/bin/relclientadmin –-add-server ServerName

By the way, to check if the server is right, you can do the following:

> /usr/local/liant/bin/relclientadmin —list-server

9 – Added a data source:

/usr/local/liant/bin/relclientadmin —add-data-source ‘yourdatasource’—server-data-source-name ‘yourdatasource’

This should get your data source added! J Things are getting cool now.

In order to verify whether what you did is correct, run the following:

> /usr/local/liant/bin/relclientadmin —show-data-source yourdatasource

If you got an error – it could be due to the default server being messed up, if so – try adding the parameter “—server-name” like the sample below:

/usr/local/liant/bin/relclientadmin —add-data-source ‘yourdatasource’ —server-name 127.0.0.1.1583 —server-data-source-name ‘yourdatasource’

10 – Give it a big smile, you are nearly done!

That’s awesome that the number 10 is the cool one. This item, we will only really rest and feel good about ourselves.

11 – Test our connection

To test the connection, the best fastest/best/easiest way to do it is via isql.

Do the following:

> isq –v DSN user password

That will log you in. Now you can run your SQL statements!

I hope you have enjoyed this solution – I’m exactly like you, a developer trying to understand why people build things so differently from each other.

Thanks!

I was researching on mobile development and I came across a...

Tue, 24 Apr 2012 22:08:56 +0300

I was researching on mobile development and I came across a company called Kutir, they define their process in this image. Pretty sharp…

How Google Searches the Entire Web in Half a Second [Video]

Mon, 23 Apr 2012 23:01:38 +0300

How Google Searches the Entire Web in Half a Second [Video]:

It only takes half a second for Google to return a search based on keywords you type in, but there’s a whole lot more happening behind the scenes to give you the results you need. Google on Monday launched a video that explains the science behind how the massive search engine actually works.

How to Measure Velocity?

Mon, 23 Apr 2012 22:48:00 +0300

I must say, I’m enjoying learning the Agile Way of running projects, sometimes I even wondered how on earth I spent so much time doing waterfall modelling rather than this beautiful agile way.

I asked one of South African’s most famous “tech” guy what he thinks of the Agile modelling. He replied saying that this is not his field of expertise but what he knows about Agile is that it’s far better to use when developing something, because of the FLEXIBILITY it gives you. And then, he completes it by saying: Growing something organically in my view is far better than delivering a finished product and then start sorting out issues. THAT SAYS EVERYTHING.

Anyways, here’s what I’m going to share with you guys:

In on the linkedIn Agile Groups, the following question showed up:

How to measure velocity in Scrum?

That’s a very good question…

Here’s the reply I’ve given:

In order to find this out with an reasonable level of accuracy (if I can use this word), you must define your Unit of Measurement (Story Points) and also the length of your iteration. Those two elements will play a big role in defining your velocity.

There are many ways of defining a Unit of Measurement; some use the Level of Difficulty of a story. I use Ideal Work Day* as my unit of measurement.

* An ideal work day, logically, is the day where you can work without being bothered by emails, phone calls and emergencies

By assigning a Unit of Measurement, it means that when a story is estimated, it will be estimated in Ideal Work Day unit.

There are three ways to “discover” the velocity:

1 - use historical values (this is the best option, however it’s only viable if we have an existing team that is rolling off a project similar to the the new project and if the team was intact, which is quite hard.)

2 - run an initial iteration and use the velocity of that iteration (it’s a great way of getting the initial velocity, but often it’s not viable as an estimation must be defined)

3 - take a guess (unfortunately, in most case scenarios, when you have to supply with a fast estimation, you will start from here :( )

Here is a nice little formula to calculate the Initial Velocity that I got by readying one of Mike Cohn’s book:

Firstly, we all know that an ideal work day is far from an actual day, so we have to estimate the value of an ideal day.
In the beginning, people are still getting used to work with each other and with the project, so let’s estimate that an ideal day equals 50% of a actual day (just an example).

Then:
Velocity = (number of team members * iteration length) / 2

If we have a team of 5 people and our iteration length is of 2 weeks…
Velocity = (5*10)/2
Velocity = 25.

So you can run 25 units per iteration.

Once the first iteration runs, and the team interacts with each other, you can assess the process and define a more accurate velocity/rhythm/calibration.

"When writing User Stories, keep the User Interface out of the stories for as long as possible"

Mon, 23 Apr 2012 03:32:30 +0300

“When writing User Stories, keep the User Interface out of the stories for as long as possible”

- Mike Cohn

User Stories - Template

Mon, 23 Apr 2012 03:23:58 +0300

Connextra, one of the early adopters of Extreme Programming (XP), incorporated roles into their stories by using a short template. Each story was written in the following format:

I as a (role) want (function) so that (business value)

A template like this can help distinguish important from frivolous stories.

Extracted from: User Stories Applied by Mike Cohn.

User Stories - Acceptance Testing

Mon, 23 Apr 2012 02:19:56 +0300

Acceptance Testing plays a very important role in the User Story - they provide a basic criteria that can be used to determine if the story was fully implemented.

In order to understand and capture the behavior of a story, instead of having a large specification document (like we normally see in the waterfall model), we have criteria.

While reading Mike Cohn’s book “User Stories Applied”, he proposed something very valuable.

Mike says that ideally, as the customer and developers discuss a story they reflect its DETAILS as tests. However, at the start of an iteration the customer should go through the stories and write any additional tests she can think of. A good way to do this is to look at each story and ask questions similar to the following:

1 - What else do the programmers need to know about this story?

2 - What am I assuming about how this story will be implemented?

3 - Are there circumstances when this story may behave differently?

4 - What can go wrong during the story?

"If you want your software to be used, you have to talk to those who will use it."

Sun, 22 Apr 2012 19:01:49 +0300

“If you want your software to be used, you have to talk to those who will use it.”

- Mike Cohn

Unclogging the arteries of innovation

Fri, 20 Apr 2012 23:20:58 +0300

Unclogging the arteries of innovation:

With the death of Steve Jobs last year, there has been an uprush of interest in what made this great business genius tick. What are the secrets of his success?

"It takes a lot of hard work to make something simple, to truly understand the underlying challenges..."

Fri, 20 Apr 2012 22:46:10 +0300

“It takes a lot of hard work to make something simple, to truly understand the underlying challenges and come up with elegant solutions.”

- Steve Jobs

State of Agile Development Survey Results

Fri, 20 Apr 2012 18:59:53 +0300

State of Agile Development Survey Results:

The sixth annual “State of Agile Development” survey was conducted between July 22nd and November 1st, 2011. Sponsored by VersionOne, the survey polled individuals from a variety of channels within the software development industry. The data was analyzed and prepared into a summary report by Analysis.Net Research. A total of 6,042 responses were received.

User Stories - Prioritizing [Discussion 1]

Fri, 20 Apr 2012 11:53:52 +0300

This post is a follow up of the previous post [User Stories - Prioritizing].

After posting my response on LinkedIn, I got the following reply from a different user:

I am not sure I agree with comments above
1. If all stories of a version are already known - that is a smell. Sounds like someone is doing waterfall in name of agile.
2. I would never put the most unclear stories at bottom of the stack

My story prioritization will depend on following factors

1. Stories that constitute MVP.
2. Next level of prioritization should be based on business value and risk. High Risk, High Business value stories should be the top priority stories. Remember in agile risk should bubble up and not be pushed down
3. Any spikes which are likely to have huge impact on estimates as well as on cost should be top priority
4. Prioritization should be a continuous process.

This was my response to the above thread:

Allow me to expose my train of thought, the numbers 1 and 2 are related to your 1 and 2 reasons why you don’t agree with the comments above:

1. After the User Story Workshop, a Release Planning must be made. To be quite honest, I don’t understand why this would sound like the Waterfall method - the fact that the stories are known doesn’t mean that they are all defined and technically specified. The stories do change along with SDLC (either reprioritize, grow, shrink, or broken into multiple stories) and so, the prioritization will be a continuous process throughout the SDLC.

1 2 3 4 5
STRATEGY -> RELEASE -> ITERATION -> DAILY -> CONTINUOUS

From my point of view, the fact that the Release Planning was made, it doesn’t really “smell or sounds” like someone is “doing” waterfall.

1. By putting at the bottom of the stack, I meant assigning low-priority. It all depends of the approach taken, on my reply I said how I would do, I take the Lean approach which defines the stack/backlog in the following classes:

(THE LIST IN A PRIORITY ORDER)
I - STANDARD - Prioritization based on the business value

II - FIXED DELIVERY DATE - Some stories have a fixed delivery date, this is common for requirements resulting from government legislation or contract signed with external customers.

III - EXPEDITE - Your critical fixes for production problems or high-priority customer requirements (hopefully you won’t have much of those)

IV - INTANGIBLE - low-priority work items that you know you will need to address at some point in the future.

The categories above aren’t carved in stones, but that’s the approach I take.

Read More on http://www.agilemodeling.com/essays/prioritizedRequirements.htm

I also agree that if any spikes that are likely to have a huge impact on planning should be top priority.

"People see messes in life as bad, but they can also be viewed as opportunities."

Fri, 20 Apr 2012 01:57:50 +0300

“People see messes in life as bad, but they can also be viewed as opportunities.”

- Robert Kiyosaki

The Agile Delivery Diagram via Agilocity

Thu, 19 Apr 2012 22:49:18 +0300

The Agile Delivery Diagram

via Agilocity