Pages

Monday, November 30, 2015

Break the walls for Agile Transformation

Several times I helped my clients to get away from traditional software development (Waterfall, RUP, etc.) into the Agile way.

One of the things that always brought me attention was the recurring behavior of line, mid and higher management to go... "do what we say but not what I do". I explain...

One of the basic things of Agile is removing barriers, creating an open and collaborative environment, flattening organizations.

Interestingly enough, most managers still want to keep their "trophy private room" and most likely would never go and sit with "the rest".

So how can you achieve plenitude of Agile if some kind of division is still on?

Making an organization Agile and flattening it is a challenge but if you want to go through a transformation, well, dive into it otherwise you'll be faking it.

Sunday, November 29, 2015

Principles to work in Agile (or any) Consulting - Ethics and Behaviour

During my career I worked in many different companies ranging from Banks, passing through Educational institutions, pure technology, aerospace and finally I landed into consulting.

The main reason I continue to be a consultant is because I like the variety of projects, clients, environments. It pushes me all the time, not letting me ever stay in a comfort zone.

Consulting in the Agile World is specially interesting since during the past years I’ve helped many companies to migrate from traditional way of working with software to a more modern and consistent way - the Agile way.

On this process I had to deal with many though situations, many of them involving clients and other vendors. Fortunately for the past years I worked in a top-notch consulting company with fantastic people and this helped me thrive during hard times.

Let’s talk about the tough situations on this post.

So for example, suppose I am working for a client where we have other vendors (consulting companies). We want to avoid stupid disputes between the vendors while trying to keep it honest and solving any difficult issue that appears - doesn’t really depend which side might have caused the problem or situation.

So how can you really keep things honest between the different vendors?

The secret lies on few principles that I adopt, all of them linked to highest standards of Ethics and Honesty:

1. The truth. Bring problems forward. If possible with a solution

You only know one’s personality for real when the person is under high stress. The tendency for many is to desperate and act in weird ways with lies, mistrust, trying to find someone to “throw others under the bus”.

Do not misact and keep control of the situation.

The first thing on a situation like this is to focus on the problem and find a solution. Or a partial solution. Talk to your peers and search for options.

But even if no solution emerges you still have to deal with the truth and not lie about it.

Be calm, communicate to your client the situation and be prepare to help on any way possible - and make your peers and specialists aware to be called for help

In many situations like this, while exposing the issue and working with the client we were able to find excellent solutions that not only solved problems but also opened new opportunities in addition to solidify the trust between our consulting company and the client

2. Be a partner

Listen to what your client needs to achieve, to his problems, not only to what he wants you to do.

The great solutions come from understanding the problems from many points of view. If someone comes to you with a to-do list, as a good partner, you should question and re-evaluate the solutions.

A good consultant must question (gently) and probe the efficiency of the solution. Of course, you have to practice this “procedure” without risking being arrogant and it is not something to be done every moment.

Being a partner means work with your client through the good and bad times finding business opportunities and solutions that will make the business better.

3. Use empirical data. Facts.

A good professional uses powerful tools and one of the best tools is Math. You need to be honest with yourself and know how to work with data. It can bring positive or negative information but good empirical data won’t lie.

Recently I’ve been involved in a project where we inherited the work from another consulting company. The client wasn’t comfortable with the old consulting and was suspicious about the quality of the tests done before.

We did an assessment and even though the performance tools were reporting a code coverage near to 100%, a simple test from one of our architects brought the reality up - in fact, the rest coverage of the code was near to 2%.

One needs to be very transparent with the information but any hard information like this must be carefully verified before being brought as a fact.

4. If your action (for example report, verbal communication) will put someone in a uncomfortable situation, share it before

So say in the example given on the topic "Use empirical data. Facts.” we were working with the another consulting company on the project on client at the same time.

My advise would be to communicate the “bad test coverage” to the other consulting company before communicating the client.

The facts won’t lie - and probably an uncomfortable situation will emerge - but it will at least give them a chance to prepare a strategy before talking to the client.

5. Seek incremental progress while still focused on the long term goal

In the good Agile spirit, plan for incremental progress to show constant advance. Betting on a “one bit shot grand finale” isn’t compelling.

Remember… projects have budgets, are prioritised among others, constantly analysed. If you can’t show progress you can’t justify investments these days. Plus, focusing on the right things might help you reach the 80% value sooner than you expected and in case your client runs out of budget you still added value.

I guess this should be any project’s objective - maximize the investment - and preventing frustration due to near-to-zero achievement when bad times come.

6. Cross check with your own partners

A good consulting team should be able to work as one unit, constantly communicating and sharing information with each other, tracing and changing plans together for the best interest of the client.

Anybody working or acting alone will have a very short life in consulting. The more senior a consultant is, better he knows that teamwork is the way to go. There is no room for backstabbing or lack of ethics.

I personally drive my personal and professional life based on the simple principle that nature always seeks balance therefore any bad action that you do will eventually fire back. It might take time but it will surely do.

In other words, keep straight on your believes - assuming they are on the good side.

7. Focus on the work, never on the politics

While working in the consulting world you’ll eventually be working with big corporations where big politics exist.

You should know who you’re working for and what they really want to achieve and focus on get that mission accomplished.

It is not hard to get caught on the day-to-day politics and if you do it can easily put you in jeopardy. Focus on the what needs to be done, work with everyone with transparency making clear what you’re trying to achieve, without trying to cause harm to people neither to your competitors.

I remember a case where we were working for a client and in the same project we had 2 people from another consulting company.

There were several projects and teams with different consultant mixes and fortunately our teams were performing well - except one.

We investigated why the project had a lower performance and through some social interactions we discovered that the partner of another consulting firm told to one of the analyst (who was working on the team) to intentionally slow down work so that the other consulting company wouldn’t look so bad. It required some social skills from our consultants to discover but sadly the truth wasn’t palatable.

This of course would never be accepted and on that situation triggered a big issue.

So, focus on what needs to be done and you’ll be doing the right thing.

8. Celebrate, interact

Though I have to communicate a lot during the day and like it I also need my quiet time at the end of the day - but I also need to spend some time with my colleagues after work to celebrate small and big achievements.

This is not in your job description but going out after work is part of it.

You’ll learn more from your colleagues and from your client, create a new level of connection, learn and share common things like hobbies, opinions, thoughts, objects. And yes, this will create new opportunities and might make things easier in your day-to-day tasks.

Once in a client I really need to get credentials to access the systems but I was depending on someone to do it for me. The person was very busy and granting the access to what I needed would take him a good amount of time. This situation lasted for few weeks.

One day I went out to celebrate someone’s birthday and the person who could grant me the access was there. I invested some time understanding his work, giving him some possible tips to make things better and I identified a common interest - fishing. The conversation was very pleasant.

The next day I open my email and the first think on the list was my new credentials followed by another email from that gentleman thanking me for the tips on his work and for the list on good spots to go fishing.

9. Be Patient

Losing your temper or trying to cut corners usually is a shortcut to failure. We all want to move fast, accomplish our missions but it just takes time.

We depend on people who have different priorities, different rhythm and focus so exercise your interaction and be recognised for the good things will buy you some goodwill to be used.

And remember, screaming, mistreating others will only guarantee you some of the more commons bad adjectives. Be patient but keep pushing.

10. Share opportunities and grow

Business is all about opportunities. Opportunities to save. Opportunities to grow, expand…

Sharing ideas and opportunities can open doors to your client (person) to grow and shine.

While working for clients you don’t need to be the “shiny” person from the eyes of the client's organisation. You need to help your partner (client) to achieve their objectives within their organisation. As a consequence you’ll also grow and expand your horizons.

It is the same principle for a boss-employee relationship - help your boss to grow and you’ll grow too.

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.

http://www.thoughtworks-studios.com/user/register&destination=forms/form/mingle/download



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:

http://www.postgresql.org/download/linux

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 mingle.properties 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!!!