Monthly Archive for: ‘April, 2009’

It's Sunday and I can't wait to go to work tomorrow 2

I decided to change my workout routine this morning and went for a 10 Km (6 miles) bike ride through the forest instead of training on the elliptical. As the cold wind was blowing on my hands (it was only 6° C or 43° F) and the ducks were swimming on the lake I was reminded of the discussion I had a few days ago.

A friend of mine shared with me a dilemna he was facing. Although he had been satisfied with his current responsibilities, he was hoping to get selected for a new position within his organization. It is a role he had helped with in the past but the thought of taking on full responsibility for an entire product line was making him nervous. In a nutshell, his thinking went like this:

I’ve given a lot of thought recently to what I want my career to be.
For the past years, I have been very comfortable in my role – I’m in my comfort zone.
I like what I’m doing but…
I feel very excited about this new opportunity.
I felt very high energy when I helped with the role in the past but…
I’m worried I might not succeed!

Did you ever get similar thoughts, similar feelings? How do you know if it’s the right thing to do? The latter question was his.

Here’s a summary of the questions I asked him:

Why do you want this new role? How does that fit with your personal aspiration?
Would you get more personal satisfaction by taking on this new challenge or by staying in your comfort zone?
How would you feel if you found out someone else got the job?
In the worst case, what would happen if you fail at your new role? How bad would it really be?

This conversation didn’t pop in my head this morning because of the dilemna my colleague was facing. As I was pedaling uphill, the conversation came back to me because these opportunities are so infrequent. People so rarely put themselves in a situation where they would have to make a difficult decision with regards to their career. For most people I know, the question of stepping outside the comfort zone never comes up.

I know, I know, the mortgage, the car payments, the tuition for the kids’ school, etc. I don’t question these facts and I certainly don’t imply these things don’t matter but what would you be willing to do to trade your current job for something that would make you say “It’s Sunday and I can’t wait to go to work tomorrow”?

Sometimes you need to settle for one or more of the following: less money, more commute, longer hours, a regular chair (and not a herman-miller) and in other circumstances it will simply be the willingness to take a risk.

What would you be willing to do?

Posted on: 04-30-2009
Posted in: Management, Management and leadership style

A Sense of Urgency by John Kotter 0

I have just finished reading A sense of urgency by John Kotter. A useful book when dealing with an agile transition.

John Kotter is author of Leading Change, published in 1996 and still a business book bestseller. In that book he presented eight steps in leading change in an organization – the first step presented was to develop a sense of urgency. Kotter believed that topic was so critical that he followed up with this new book specifically dedicated to developing a sense of urgency.

The book is useful to help make clear distinction between a real sense of urgency, a false sense of urgency, and complacency. After explaining at length the difference between these 3 situations and providing clear examples, Kotter provides tactics to deal with complacency and false sense of urgency in order to convert them into a real sense of urgency.

Although the book is dry – don’t read it just before going to bed – it is well written and fairly concise.

The first section of the book focuses on what is described as a “false sense of urgency.” Kotter characterizes people with this attitude as feeling that change must be made but whose actions aren’t very helpful. The single biggest error people make when they try to craft change is they do not “create a high enough sense of urgency among enough people to set the stage for making a challenging leap into some new direction“. ”A false sense of urgency is pervasive and insidious because people mistake activity for productivity“.

The biggest challenge facing people who try to create a sense of urgency within the organization is “complacency”. “We underestimate its power and its prevalence“.

To increase a “true sense of urgency”, “create action that is exceptionally alert, externally oriented, relentlessly aimed at winning, making some progress each and every day, and constantly purging low value-added activities–all by always focusing on the heart and not just the mind.”

To implement strategies to address these situations, the author he suggests the following tactics:

Bring the outside in with engaging information so that the outside is acknowledged, understood, and acted on.
Demonstrate urgency every day as a leader and expect everyone else to do the same.
Find appropriate opportunities to change and improve from crises that threaten the organization.
Wall off, neutralize, or eliminate those who oppose or slow down change for no good reason.

In summary, taken via Book Excerpt: A Sense of Urgency — HBS Working Knowledge.

Big Mistake Number 1: Assuming that crises inevitably will create the sense of urgency needed to perform better.

Big Mistake Number 2: Going over the line with a strategy that creates an angry backlash because people feel manipulated.

Big Mistake Number 3: Passively sitting and waiting for a crisis (which many never come).

It is a good book to help you transform your organization.

Big Mistake Number 4: Underestimating what the people who would avoid crises at all costs correctly appreciate: that crisis can bring disaster.

Posted on: 04-29-2009
Posted in: Leadership

More time does not create better decisions 0

Seth’s post was pretty short on Sunday but it raised 2 questions in my mind in the context of Agile Business Intelligence.

His statement sounds contrary to what is suggested by Mary and Tom Poppendieck in Lean Software Development: An Agile Toolkit where it is recommended “to delay those decisions as long as possible“.

The second question that came to mind was that with Business Intelligence, there are huge pressures to find “the single version of the truth” which means that money is invested to analyze and normalize the data in a BI project so that it is consistant throughout the organization – and becomes the “perfect” information.

After a while and after reading Seth’s post a few times, his last sentence allowed me to reconcile the various perspectives. Seth says “What happens if, starting today, you make every decision as soon as you have a reasonable amount of data?“.

Which I translated for the context of an Agile Business Intelligence project to: “delay your decision until you have a reasonable amount of data“. Striving for perfection is never a good use of time, resources and energy in my opinion.

Posted on: 04-28-2009
Posted in: Leadership

We have a huge budget and too much time to complete our business intelligence (BI) project 0

If you agree with the title of this post then you don’t need to read further, either your business intelligence (BI) project will be amongst the very few (less than 40%) that will not end in abandonment / failure or you do not have to worry that your project will drain your huge budget before slowly and gradually failing.

For everyone else, this article that presents the benefits of using an Agile approach to software development. This post is a follow up to my previous article called Nobody is interested in Agile where I wondered why so few articles explained the actual benefits (the WHY) behind Agile.

Why should organizations use an Agile approach for their Business (BI) Intelligence projects?

In clear business terms, using an Agile approach for the development of your BI solution will greatly increase your return on investment (ROI). Before reading further, you need to keep in mind that Agile will not address all of your software development issues but by empowering the people who are directly and indirectly part of your project team and by taking a pragmatic and realistic approach to the software development process, the implementation of Agile principles within your organization will address the most critical problems typically encountered by a software development project.

The following diagram summarizes the 7 key benefits of implementing an Agile approach for your business intelligence project. Each of the benefit is explained further below.

increased return on investment by using an agile approach

The intent of this post is not to describe the Agile principles nor to explain which practice should be applied in a specific context but to describe in clear business terms the benefits derived from these practices.

Increasing Productivity

The throughput of your development team will greatly increase once you implement agile methods. The associated benefits:

Streamlined and improved face-to-face communications;
Continuous performance improvement by retrospecting at the end of each short iteration;
Progress is not measure by looking at compliance to a project plan but by evaluating by the quality of the output;
Project management is shared by everyone on the team instead as the team self-manages and becomes fully accountable for the results and reporting mechanisms;
Use of proven and innovative software engineering practices greatly improves quality;
Increased ability to estimate efforts and time lines;
Team productivity can be assessed and monitored over time which provides a predictable rhythm.

Meeting Time Commitments

Project time lines are typically very critical and as such implementing an Agile approach help meet time commitments.

Reduce the overall scope into small manageable chunks and maintain focus on short term delivery instead of the final end date;
Make the team’s progress visible to everyone with the use of defined reporting (burn down chart);
Team has to demo working product at the end of each iteration;
Estimating and scheduling is a collaborative process shared between the customer and the project team;
Frequent delivery of software reduces the overhead of moving the application into production;
End users are involved in defining the time lines instead of leaving the activity to the development team.

Increasing Quality

Quality is never negotiable so implementing Agile is beneficial to the project team.

Team has to demo working product at the end of each iteration;
Early detection and fixing of faulty components;
Testing is not only done at the end of the project when the cost of fixing issues is much greater;
Tests may be written before the development cycle begins and must be continuously be run throughout the duration of the project instead of waiting until the end.

Delivering on Requirements

Many projects are delivered without meeting the expectations of the customer. Using an Agile approach helps the team deliver on the requirements.

Customer is part of the project team, defines the priorities and assesses the end results;
Obtain continuous feedback throughout the development cycle and not only at the end;
Team will deliver on the original requirements but if there are requirement changes, the team will provide opportunities for feedback and adapt to meet the changing requirements;
Analysis and design is done at the beginning of each iteration and not only at the beginning of the project;
Software should meet the current needs, not the needs that were defined months before.

Delivering Business Value

As opposed to emphasizing tools and processes, Agile focuses on delivering value to the organization.

Teams work on value added tasks (as opposed to paper work and attending meetings);
Teams delivers the highest value features first and avoid building components that will never be used by the customer;
Focus on results (as opposed to process oriented or project plan driven);
Time boxed to ensure compliance to defined time lines;
Costs and benefits can be associated directly with the pieces of software being delivered, if the estimated cost for a component is greater than the anticipated value the component may not be developed;
Reduces or eliminates non-critical activities;
Raising issues and impediments early in the process reduces the cost of fixing them later on.

Improving Knowledge Sharing

As Agile relies on the concept of the team as opposed to the individual, knowledge sharing is a direct benefit.

Prevents the fact that a single individual becomes the bottleneck for the project by emphasizing sharing of information and tasks amongst the team members.

Increasing Employee Satisfaction

Although not frequently mentioned, employee satisfaction is an important benefit of implementing Agile.

Relationship between the project team and the customer are improved by developing trust and sharing knowledge throughout the duration of the project;
Team self-organization and autonomy greatly improve team members’ morale;
By inspecting and adapting their work processes, the team members grow their skills and motivation;
Given the opportunity to play various roles on the development team, individuals increase their satisfaction by developing new skills.

As I mentioned in my previous post, there were very few articles that explained the benefits (the WHY) of implementing an Agile approach for software development project. Hopefully, this post will help you promote agility within your organization.

Posted on: 04-27-2009
Posted in: Agile Business Intelligence, ROI

How I failed as a Product Owner and the lessons I learnt in the process 0

I failed.

There it is, in writing for the world to see. You might think it is a bad idea to write about a project that failed – especially since I was the product owner. Fair point but I would have to disagree for the following reasons:

If we spend time reflecting on the reasons behind our failures, we can learn more than when we succeed. Success leads us to believe we know how to lead a project and that we are a key contributor to the success of the project. What can we learn from success? Failure is a humbling experience and spending time to analyze our decisions allows us to improve our abilities in the long run. So failure isn’t good but failure without retrospection is even worst – unless you are looking to repeat your mistakes.
If you want to grow as a person, you need to take some risks. The same logic applies to organizations that want to grow, they will also take some risks. As a consequence, if you want to take risks, you better tolerate failures. As Michael Dell once said, it’s OK to fail as long as you fail quickly and gracefully.
Someone else (I don’t remember who it was) said that you judge people’s character not by the number of time they failed but by how quickly to got back up on their feet and went on to tackle another challenge. The point here is not to run away from your failures but not to sob and feel sorry for yourself.

So here’s the short version of my failed project.

About six months ago, I presented to our executive committee the idea of launching a content based web community geared toward Agile software development. There area already some well known sources of information around agility and some more specific geared toward Scrum but there isn’t a single leading source of information in French (being located in Canada and serving Quebec and France, this is an important need for people we work with). I thought it would be a great way to contribute valuable content to individuals and organizations looking for help in their implementation of agility.

As a true innovator, my boss challenged me to think of the next generation of a web community. Let’s not use what exists today and let’s create a place where people will enjoy gathering – not just a blog or a wiki but something better! So the project began.

After a few weeks, a few of us had brainstormed the new concept, pitched the idea to a few colleagues and went on to do a Sprint 0 (see below for the definition of a Sprint 0). The new concept was a tool that would support collaborative text edition where the community would vote on the best content. Since it is unlikely that we will initiate the same project twice, I might write about some of the project details in an upcoming post. Stay tuned for that.

So a small development team and a Scrum Master were assigned and we started our first sprint of 2 weeks. Than the usual product demo took place followed by the sprint retro. Then another round of sprint planning, execution, demo, and retro. We repeated the process for a few weeks until we realized we weren’t making enough progress. Quality code was being written, must product demos were successful, the team retrospection were informative and the team was increasing its velocity. So why weren’t we getting closer to the goal?

The make a long story short, the concept turned out to be innovative and the development project turned into an R&D project where most of the efforts were spent on the research part. So after 4 months of iterative development, I killed the project!

What I learnt in the process is the following:

In an organization where there are many competing priorities, launching a new content based web community is a challenge in itself. Adding to the complexity of the original project by launching an innovative collaborative text editing plate form isn’t a smart idea. It would have been a thrill to hit a home run but getting to first base would have been a better strategy. It might not be as glamorous but it is a safer bet and there is always the opportunity to build incrementally after you get the first version out.
Execution is much more difficult than coming up with an idea. Since the idea seemed good and that people agreed with the concept it was easy to believe we could deliver an outstanding product.
Every organization is resistant to change, so when a new idea is launched internally it is critical to explain the vision and the benefits to as many people as possible to get their buy-in and identify potential pockets of resistance. It is naive to assume that everyone will see the value of the new concept and will immediately accept it. Once the idea is conceived, promote it as if it was already ready to launch.

It is great to work with an organization that supports entrepreneurship and that invests in its people. Next time around, I will get to first base…

Note: The purpose of a Sprint 0 is to draft a project charter that includes the following elements: vision for the project, objectives, assumptions, success factors, success criteria, roles and responsibilities, priority matrix (scope, time line, and budget), risks, and mitigation. In addition to a project charter, the planning stage allows the project team to start populating the product backlog.

Posted on: 04-22-2009
Posted in: Agile, Scrum

Nobody is interested in Agile 5

Would you buy a car because the manufacturer uses Lean Manufacturing process, Just-in-Time production or tools such as Value Stream Mapping, Kanban and Poka-Yoke? If you answered “yes” because you thought of Toyota, then I need to ask you to think again and answer the question as it is stated. Would you buy a car based on the “way” it is manufactured or would you purchase it for the benefits it provides?

Let me help you a little with the answer. Although many authors describe in great length the amazing methods used by Toyota to ensure quality of their vehicles, people started to buy Toyotas in the ’70s when the energy crisis hit the US hard. The manufacturing methods were the same but suddenly the benefits (reducing gas consumption) became very apparent. Even at that, it took Toyota over 40 years to become the number one car manufacturer in the world.

What does this have to do with selling Agile, Scrum or XP to organizations? A few things actually. Search Google for terms such as “why use agile” or “why use scrum” and what you will find are power point presentations and blog posts explaining WHAT Agile is, Scrum and XP are but very little information on the benefits, the WHY – which was the question in the first place.

This interesting situation may be linked to the fact that most of the people originally associated with Agile were engineers and technologists. The original intent behind the Agile principles (and the manifesto) were to address a perceived weakness with the software development process (WHAT) and, as such, put most of the focus on documenting an improved approach to software development. Many of the software engineering practices to come about are great ways of improving software development but traction is slow. Will it take 40 years for agile principles and innovative engineering practices to dethrone the traditional waterfall development process?

We need to use a better method of promoting agility. Notice how I didn’t say selling agility. Selling implies that someone is pushing for someone else to purchase. As such, if we want to increase the adoption of agility within organization, we need to show benefits. This is even truer since very few of the decision makers are engineers and don’t come from a highly technical background. Decision makers need to understand the benefits or the ROI before they would agree to move to a different approach so we need to show them the benefits, the WHY.

I’m stopping here for today but an upcoming post will present the benefits of applying agile principles to your software development project.

Posted on: 04-21-2009
Posted in: Agile

What Every Business Person Needs To Know About Agile Software Development 0

The Scrum Alliance has published an interesting guide: What Every Business Person Needs To Know About Agile Software Development. This short guide will help demystify Agile terms using plain language.

Posted on: 04-18-2009
Posted in: Leadership

Agile Principles Applied to Management 0

As I was driving back home after another exciting day at the office, I was wondering how much information I would find on “Agile Principles Applied to Management”. Google.ca returned 273,000 results most of them about Agile principles applied to workflow management or Agile project management (scrum) but nothing about applying those principles to management in a business setting. Interesting!

The Principles behind the Agile Manifesto were originally drafted in 2001 to promote a new approach for software development but with the growing success and pragmatic approach of Agile, I believe the principles can indeed by applied to management. Below is my first attempt at rewording the Agile principles so they can be applied to management. To avoid confusion, I am presenting my proposal in brackets [].

Our highest priority is to satisfy the customer through early and continuous delivery of [our goods / services].
Welcome changing requirements, even late in [the production / delivery process]. Agile processes harness change for the customer’s competitive advantage.
Deliver [innovations] frequently, with a preference to the shorter timescale.
[Externally focused employees] and [internally focused employees] must work together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a [] team is face-to-face conversation.
Working [products are] the primary measure of progress.
Agile processes promote sustainable development.
[The extended project team] should be able to maintain a constant pace indefinitely.
Continuous attention to [] excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best [work / products] emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Which I would summarize to the following Agile Principles Applied to Management:

Customer satisfaction is the highest priority – demonstrate it by constantly delivering on their expectations.
Focus on providing your customers a competitive advantage.
Improve your product / service frequently – even in small increments.
Assemble cross-functional teams and ensure they work together.
Assign motivated people to your critical projects.
Trust your motivated people to get the job done.
There is no better communication than face-to-face communication.
Progress can only be measured with working products – incomplete products are useless.
Maintain high focus on quality and simplicity.
Self-organized team produce better results.
Allow the team to inspect and adapt.

Posted on: 04-17-2009
Posted in: Management

What Would Google Do? by Jeff Jarvis 0

I just finished reading What Would Google Do? by Jeff Jarvis the man behind buzzmachine.com.

Like many people, I’m a big fan of Google and most of their products and when someone told me about this book I thought it would be interesting reading material both pleasure and business knowledge.

The title is catchy but I must warn you, this is not a business book. The book does not even provide insight into Google’s culture, management style or innovation process. On his blog, the author says the following about himself: “Jarvis was creator and founding editor of Entertainment Weekly; Sunday editor and associate publisher of the New York Daily News; TV critic for TV Guide and People; a columnist on the San Francisco Examiner; assistant city editor and reporter for the Chicago Tribune; reporter for Chicago Today” and as a consequence, the book reads much more like a long blog post than a structured book. Don’t get me wrong, Jarvis’ style is entertaining and the content of the book is interesting but you won’t find any major revelation that you can use to inject new ideas into your organization.

In summary, the whole book is based on the “Ten things Google has found to be true” and the book can pretty much be summarized by “Five Steps to a Googlier You” posted on the author’s blog.

The most interesting part of the book is that Jarvis shows what other business models might look like if they were run by Google. These companies include airlines, real estate, banks, hospitals, insurance, and universities. Big comparing to real life example, the author demonstrates how internet companies like Craigslist, Flickr, Wikipedia, Amazon and Digg have disrupted their market by applying Google’s philosophy.

Overall, I enjoyed this book eventhough it turned out to be more for leisure than business.

Posted on: 04-16-2009
Posted in: Leadership

You have the best BI application. Great! Do your users know? 0

Your organization has invested large sums in the development of a Business Intelligence (BI) program. The project team followed an innovative approach by combining SCRUM as their project management methodology with AGILE software development practices including some advanced software engineering techniques such as test-driven development (TDD), re factoring and continuous integration. The project was delivered on time and within schedule. The team is happy, the Scrum Master is delighted and the Product Owner (PO) invited the whole team for a memorable dinner. Everything went perfectly …

Actually, no. Probably not! Besides the PO are all the users aware of your project?

I would like to offer some communication strategies that could possibly help your project success rate.

Ask the users participating in the project to spread the good news by infecting other members of their department relative to the benefits of the new application.
Provide frequent demonstrations of your new BI application to a broad audience to demonstrate the usability of the application and the benefits of the new tool.
Run an internal advertising campaign with visual media (brochures, posters, mugs, etc.). The aim is to generate curiosity with relation to the new application.
Conduct formal and structured presentations to teams and individuals impacted by the new application to answer their questions.
Use the project sponsor or the PO to disseminate the information about the project and to demonstrate the value of the new application.

In summary, use the project team members to communicate frequently and to as many people as possible. Be enthusiastic and repeat the process.

I must admit, that the list of communication strategies is not exhaustive but this was not my goal. Communication strategies will vary depending on the organizational context. Strategies that have worked well in one organization may not be applicable to another. My objective was simply to remind the project team to plan and execute their communication strategy as soon as possible. The lack of communication may not only delay the adoption of the new BI application but in the worst cases this could lead to the potential rejection of the new solution.

A good communication strategy will increase the chances of success of your new business intelligence application.

Posted on: 04-10-2009
Posted in: Leadership

Page 1 of 212»