Wednesday, November 18, 2015

Coaching people: Bringing people into Agile

Like in any professional area, people sometimes overrate certifications.

I really don't think that 2 days of training will give you enough insight to become an expert on anything.

Lots of certifications (Certified Scrum Master aka CSM, Certified Product Owner CSPO, etc.) will give you a very brief introduction to what the real Agile world is.

In my opinion the real "training" should be through personal coaching (or sponsoring). And it takes time.

So if you want to get into real agile, I'd recommend few things:

1. Find someone within your company who is expert on what you want to learn.
If you want to be a good Agile Business Analyst, find someone who is good on that.
If you want to become a project leader (Project Manager, Iteration Manager), look for someone to help you.
If you want to be a good agile developer, coming from a "traditional" way of development might be painful. You'll have to get used to pairing therefore find some people to pair up.

2. Complement your learning with books. Many books. Scrum, Kanban, DevOps, Lean Enterprise, XP, Pair Programming, TDD, etc.

3. Read blogs. Martin Fowler, Paulo Caroli, Jim Highsmith, Ken Schwaber are some references.

4.  Participate on conferences, meetups on your area and expand your network.

5. Find a project to get involved. If the project doesn't have a "role" open, ask to participate on meetings as a listener or help facilitate activities (run a retrospective, participate on an inception).

6. DO NOT GET STUCK ON SCRUM. While I agree that Scrum is a good point of entry to Agile (it gives you a boxed structure to follow), practical agile is far beyond that.

Sunday, November 15, 2015

Presenting to C-Level or Higher Management

A story...

A Project Manager (PM) is super motivated about his new yet-to-be project. In order to move things forward he needs to present the big idea to high management - C-Level or VP Level folks.

So the PM does his homework... lists the pros, potential risks, puts together a nice presentation with all the possible justifications for the project.

The big moment comes, the presentation day... ready to impress!

All the "big guns" are present, you smile, bring up the slide #1/28.

But... the guy sitting on the back - who apparently is the most senior - questions you before you even finish thanking them for coming.

- "Show me how much it will cost". Simple, straight, no fluffy stuff.

You prepared a big presentation. You practiced every single phrase. And the "big guy on the back" just wants to have one question answered?!

Well, yes.

So in short, while presenting something to higher - or even mid-management, on your first slide (or maybe also on the second), go straight to the point and give the answer everyone wants to know before you defend it.

So in a traditional/regular presentation the order of "slides" would be:

Intro + Objective-> Arguments (reasons, motivation) -> Justifications (numbers, potential ROI, etc) -> Conclusion

If you want to be more effective follow a different order:

Conclusion (The answer to the core question) -> Justifications -> Arguments

You'll need to understand your public. In your presentation, bring forward what they want to know. Maybe you'll get to the 3rd slide.

In general, the more senior people are, less patience they have. You don't know what they are looking for? Try to ask around and get a hint.

Some people are motivated by numbers/costs. Others by ROI. Others are looking for "soft arguments" (rare among senior management).

Just focus on what they want to know first.  

But be prepared also go to through any other point. You might be challenged on non-core items as well.

Coming back to Blogging

After a long time, I decided to go back to blogging ... many topics to come. Thanks to Paulo Caroli @paulocaroli for refreshing me on that idea...

Wednesday, July 27, 2011

Implementing Agile Projects: What's my ROI?

Last Tuesday (Jun 26th, 2011), Jim Highsmith, one of the Agile Manifesto authors and colleague at ThoughtWorks came to Dallas (DFW area) to talk at DFW Scrum.

It was a great evening (I guess around 100 people) with a good presentation and discussions - plus of course, since we are in Texas, BBQ!

I had a pleasure to talk to Jim before the meeting at our ThoughtWorks office here in Dallas discussing on various topics which was complemented by his talk later in the day.

After all the information collected and some thinking, here are some of the top points:

1. ROI

It is not simple to come with a simple way of measuring ROI when it comes to organization transformation moving from typical Waterfall (or other old techniques) project management/implementation to Agile.

I have seen numbers/stats that can justify it, but numbers is just a way of looking at the problem and they can be manipulated in the end.

There are arguments that can better support and justify an Agile transformation.

Jim gave 2 examples - which I think are excellent:

1.a. In a certain project (Agile), there was a list of 100 features to be implemented. A fictional conversation between the Agile Team (AT) and the Product Owner (PO) would go like this:

(AT) - Mr. Owner, can you give us a list of the 3 most important features?
(PO) - No, all my features are important. I want them all.
(AT) - We understand but let's begin with 3 for our first Sprint.
(PO) - Ok, let's pick features A, G, K.

During the planning of Sprint 2, the conversation continues:

(AT) - Ok Mr. 'O. First features almost there. Can you give us 3 more to implement?
(PO) - Well, now I think all of them are important.
(AT) - Right, but then again, we need the most wanted from the 97 remaining features.
(PO) - Let's do B, C and W.

After few iterations and around 25 top features implemented, the conversation would continue like this:

(AT) - Howdy Mr. Owner. Again, we need few more top features to be picked from the list.
(PO) - Oh well, I think we can stop here. The project has already the core functionalities. The remaining features are nice to have but we can live with as is for now. I have other projects that I can invest and that can bring me more return than implementing the remaining 75 features for this product.

Bang! That's your ROI. Now you can incrementally see your product and you'll stop once you reached the point where you want to stop. Plus, with Agile you'll be able to put your product in production much earlier than in a typical Waterfall (or RUP) project because at the end of each Sprint (typically 2 weeks) you'd have a working software, specially if you use Continuous Delivery (see Flickr exem ples) and you don't have to wait 6 months or a year before you have your entire book of 100 features implemented.

But maybe this still doesn't convince your CFO. Knocking the door of the finance team can be challenging if you don't have the right arguments. So...

1.b. Ask your finance team if they want 100% of the value for 100% of the cost or 80% of the value for 60% of the cost. Needless to say, the second option will be more palatable.

Also, negotiating incremental investment can be a better approach. Ask for a reserved budget but say you'll take it in parts. Then after some few Sprints, show the results and get the other part of the project financing and so on. Probably this will be much easier.

Financial responsibility is everybody's job so, collaborating and giving the right reasons to implement your project will help you and your organization.

2. Quality

One of the most interesting measurements collected from empirical data shows something very interesting while comparing typical project to the one executed using agile.

In a typical project, when adding more devs to the team the number of defects spikes - it can attributed to the chaotic code.

In an Agile project, the number of defects does not spike... it is kept under control. This gives more reasons to run projects using agile as if you need more velocity on features implementations, adding more team members properly will not crash your project.

3. Technical debt

This is a somewhat 'hidden' topic, which I don't see discussed very often but I lived it before.

As your software is developed, it needs refactoring, adjustments and bug corrections along the way.

Without Agile and Continuous Integration, one can be blind on the actual software state.

If I have a project that will run for a long time, I dedicate one Sprint after 'X' number of Sprints to deal with the Technical debt including old minor bugs, refactoring and general adjustments.

Using Waterfall or other similar approach, you won't be able to see through the implementation and the technical deficit will be accumulating until the end of the project and it is very likely that you'll have in your hands a typical "Software Monster"(I just defined this :-D ) that can be easily identified:

- Nobody wants to do maintenance on this beast.
- Needs major refactoring.
- Monolithic.
- Many features are useless, unwanted or outdated.
- If you are a dev and you're assigned to "re-factor" the Software Monster, you know it is a career sink.

So, avoid the Software Monster and technical deficit by implementing what will be useful and will bring value using Agile.

4. Features implementation and Outcome performance

Agile teams will deliver more value (working useful software) sooner. You can give the software to your customers to use as soon as you reach the minimum amount of features.

Delivering the value and the most wanted (working) features will give you the possibility to get users sooner, "test the water", get feedback and improve your product in a much more efficient way.

Perhaps you'll find that the next 'N' features to be implemented look very important to you but based on the current product usage, the main focus should be in another set of features or area that were not important to you.

5. Conclusions

Many organizations are still considering migrating their project teams to Agile and are stuck in slow, costly and old approaches.

The value of Agile is clear to me but I also recognize that there might be resistance to change because of many organizational reasons.

Overcoming this resistance and correctly implementing Agile will not come in a snap. It will take time and maybe the best way of getting beyond the chasm is taking a pilot project with proper guidance :-)

Tuesday, July 26, 2011

Installing Mingle on Ubuntu

This tutorial will guide you through the Mingle installation on Ubuntu. Also, I will assume that you have some familiarity with Ubuntu (Linux…); Java must be installed on Ubuntu prior to begin this tutorial.

1.     Downloading Mingle

Access the URL below and follow the instructions to download Mingle.

You should receive an email with download instructions. Follow the URL sent to you and download Mingle. We'll continue the installation after few previous steps.
Keep the email for later use. It contains the license information
During this tutorial we'll be installing Mingle on Ubuntu. Other platforms should follow a similar pattern.
Another easy option is to download the VMWare version. If you already have VMWare player installed, it would be a great option, as it will save you some time.
If you desire is to learn more about the details of the installation then let's continue our work.

2.     Downloading the database

Following the recommendation from the Mingle download page, we now should download one of the supported databases (Postgree or Oracle). Here we'll use Postgre 8.4 for the Ubuntu Linux Platform:

Following the link for the graphical installer, we select the desired platform:

3.     Installing the database

After the download is completed, verify if the file needs to have the permitions changed to be executed and change using chmod if necessary:

In order to run the application you'll need to use sudo, as shown below:

The installation will begin:

On the next screen, choose the location of your installation:

Here I chose to install it under my personal user folder. Observe that I created a CI folder where I want to keep all the software related to my continuous integration environment concentrated (just my personal preference).
Similarly, for the data storage, I picked my choice for the folder:

In the next step, enter the password (and don't forget it!).

Then, pick the port (here, I left the default). If you want to change it, go ahead but then again, remember it for later use!

In the next screen, I accept the default options for locale:

After capturing all the preferences, the installation will finally begin:

The installation will proceed…

Until it completes:

If you want to install other items (not necessary for this installation), keep the "Launch Stack Builder" checked, otherwise remove the checkbox selection and finish the installation.
Postgre installation usually already starts the server.

After the installation, if you're using Ubuntu, you'll find the Postgre menu from where you can start or stop the DB. Also you'll find a handy admin tool if you want to access the database directly.

We have to create a database for Mingle so, open the pgAdmin tool and login. Expand the three and on the Database node, right-click and select the "New Database" option.

Enter the database name and hit OK.

In the end, you'll find you'll find your newly created database.

4.     Installing Mingle

Now that the database is installed, let's continue with the Mingle installation.
Locate the downloaded file. It is probably a ".tar.gzip. Unzip and untar it:

At the end, you'll endup with this the mingle directory:

I'll move my Mingle directory to the same place where I have my Postgre:

Go to the Mingle directory, copy the sample properties file to the config directory. After, rename the file copied file to as below:

5.     Starting the server and configuring Mingle

We'll start the Mingle now and as pointed initially, Java will have to be installed. If Java is not installed, you'll get a message like:

To start the server, navigate to where the file "MingleServer" is and use the command line, as shown above and below:

./MingleServer --mingle.datatDir=/home/user/CI/mingle_3_3_1/data/ --mingle.configDir=home/user/CI/mingle_3_3_1/config/ start

The first parameter (--mingle.datatDir) points to the data directory.
The second parameter (--mingle.configDir) points to the config directory.

If they don't exist under your installation, create them if necessary.

After executing the command line, you'll find:

At this point, we're ready to start configuring Mingle.

6.     Configuring Mingle

With your server running, open a browser and go to the server's address (if you're running locally it should be http://localhost:8080 ). You should reach a page like the one below:

Check the box "The database is setup and ready to go" and hit Continue.

On the next page, fill up the form with the information used during the database setup:

Database host should be localhost (if you're running locally) or the URL (or IP number) of your database server.
The database port is default (unless you changed it before).
The database name is mingle.
The database username and password are the ones set previously.

Hit Continue.

On the next page (Step 2), it will ask to setup the database. Hit Continue again.

On Step 3, you'll have to enter the URL for the users of Mingle. If you have a network address for your server, enter it here. In our exercise here, we'll just have it set for myserver:

On step 4, you will be able to setup the SMTP for mail communication. In this example, we'll not configure this communication but you can fill up this form with the information required. Hit Continue once done.

On Step 5, you'll have the license form. Read it and if you agree, check the box and hit Continue:

The step 6 will allow you to configure the first user account. Fill up the form and hit Continue:

On step 7, hit Continue.
On the next step (8), copy the license received by email and paste on the License Key field:

After press finish and you're done!

You'll be redirected to the Mingle landing page where you can start creating your first project!

Happy Mingleing!!!

Wednesday, July 20, 2011

Continuous Integration and Delivery

The Continuous Integration (CI), one of the core practices within the Agile development process, has matured and became a fundamental tool for organizations aiming software development with quality, traceability and automation.

In the next paragraphs I'll be describing the components of a basic and of a complete CI system.

1.The basic system

In a minimal but complete agile environment, the CI should be integrated with other tools, including:

1.A. Story repository

This is where your story cards (or tasks) are, containing all the information about each story implemented. 
In a Agile project, one should be able to create the cards, with the necessary details (sometimes including images, documents). therefore the Story repository should be able to handle this. In addition, having states for each story card (new, in progress, etc) will enable to have the proper transition from the initial concept until the final delivery of the feature.
Good examples of story repository: 

- Mingle (by ThoughtWorks), is an excellent tool, very flexible and adapts to your Agile implementation.
- Jira (by Atlassian) is also a popular tool.
Bugzilla, is more a bug tracking tool but I've seen some people using it as a tool to track the stories, even though it doesn't flow well.

1.B. Source control

That's where the team will put (checkin...) the source code. Usually I prefer to have every checking tied to a story card so that we can have the traceability. 
Some popular source control tools are:

- Subversion (SVN) - Very popular these days, open source.
- CVS - Was already much more popular, also open source.
- Clear Case - IBM tool, used in big enterprise environments. Can become overwhelming for some people depending on the configuration management style used.

1.C. Continuous Integration Server

This is the central piece of CI. It orchestrates the process by taking the source code, combine with the stories, run unit tests, deploy on Test environment, run automated functional tests, and finally deploy it - if desired - to a production environment. In many occasions the last step will only happen if the organization is comfortable enough with the automated tests being the "gate".

More specific about integration of the different pieces, for example, if someone is working on a (story) card with ID #2345, at the "check in" time the developer would add to the comment field the card ID tag. Later on, the continuous integration server will merge this information with the story card added on the Story Repository.
This way, you will be able to see which source files were modified in order to have specific features implemented, including the time and who delivered the source code.

There are several Continuous Integration servers but I'll mention the three main ones:

Cruise Control (by ThoughtWorkers), which is basically the first popular server. 
Hudson (Open Source/Oracle), is also a good option.
Go (by ThoughtWorks), very much aligned with Agile.

These elements together become be the basic set of tools - which is the minimum set for CI.

2. Complete CI system

In addition to these three main pieces, other elements should also be part of the CI environment, to bring more value to the solution:

2.A. Unit test

These are tests usually written by the developer to guarantee that the basic functionality of the code will not be broken during development. It tests the code for consistency, to validate if new implementations didn't break old and already working code.

Common found tools:
JUnit - Probably the most famous unit test tool for Java
TestNG - An alternative to JUnit.

Here we described tools focused on Java but for different languages you will find different sets of unit test tools. And if you find that your language doesn't have any tool for unit test, well, that's an opportunity to create something new today!

2.A.1 Code coverage

One important aspect of Unit Test is to guarantee that your code has a good coverage. There are several code coverage tools available, including:

Cobertura - Probably the most popular.
EMMA - I particularly never used it but in any case, here is a reference.

A good code coverage tool will be able to report the stats about what is being covered by the unit tests - for example, in percentage, giving the total of code covered for the entire software and per class.

2.B. Functional automated test

Unit tests are great but Functional Automated Tests will bring a whole new (and better) level of testing. With recorded functional tests, the Agile team will be able to have a greater confidence that the software created is working in its full capacity, free of functional errors.

Typical tools are:

Selenium (by ThoughtWorkers) - Very good tool!
Twist (by ThoughtWorks) - A very modern and complete tool for automated functional test.

2.C. Deployment

For deployment, there are no specific tools and most usually you'd write your own set of scripts to perform this action. Some CI tools (like Go) have plugins or embedded functionality that help this step.

3. The flow

The picture below describes the pieces involved in the whole process and summarizes the flow. The steps are described below:

Step 1: First, at some scheduled time (or every time that someone checks in code), the CI will get the latests version of the source code, merge the information with the Story repository (or tasks). A build will be produced and a list of the content of the build will be created.

Step 2: With the build in hands (war or jar or exe), the unit test will be run and the results will be collected. 

Step 3: Having the build passed the unit tests (I usually have the acceptance at 100%), it is time for the Automated functional (full tests) to run. Maybe it will be necessary to deploy the build in a test server depending on the kind of application that is being run.

Step 4: When all the tests are completed, it is time for the deployment in production. This can be automated (assuming you are really comfortable having only the automated tests results) or otherwise the build will be stored on the CI server for use at later time.

This is the basic flow of a complete Continuous Integration system.

4. Summary 

I described above, in a high level, the usual flow for a CI system. There are different variations and combinations, but in general the described solution can be used as a framework where one can add or remove pieces according to their need.

In a minimum and functional system, the three main pieces should exist (Story repository, Source code repository, CI server) but it is alway recommended to include tests, code coverage and other features to improve the quality of your software.

5. Conclusion

CI is not a new practice but its use is not well disseminated yet.

As part of the core good practices, it supports the Agile teams to advance much quicker, introducing a continuous flow of builds, tests and deployments that naturally bring more quality to the final software, saves time and eliminates (in part) the repetitive manual test.

For managers and clients, when a complete CI system is used, it will give visibility of where the team is in terms of quality, production and individual's contribution to the software.

Friday, July 31, 2009

Distributed agile

In my recent experience I'm dealing with a very big client that passed through an also big change on their corporate culture.

Without getting into names, a Company B was acquired by A and all the B's employees had to comply with A's new rules resulting on everybody working remotely - mostly from home.

I believe that this is something that will happen more and more often as companies can save big $$ by not having to keep a big infrastructure to operate.

From this concept a question comes: What will happen to the Agile methodology? Agile relies a lot on having people colocated for better collaboration and it would become a challenge for a distributed team to collaborate in the same way.

Fortunatelly some people are already thinking about this... and I'm glad I know one of them.

To get more information and collaborate with ideas about distributed Agile software development, go to and see how the path is being paved.