Skip to content

Archive for

Why don’t you contribute to your company’s blog?

Working for a technology company where most people are younger than 35 years-old, I thought blogging would be a natural thing. For those of us who blog, we can certainly relate to the 10 Great Strategic Benefits of Blogging.

  1. Search Engine Marketing.
  2. Direct Communications.
  3. Brand Building.
  4. Competitive Differentiation.
  5. Relational Marketing.
  6. Exploit the Niches.
  7. Media & Public Relations.
  8. Position You as an Expert.
  9. Reputation Management.
  10. Low cost.

So when we calculated our ratio of blog post to employee, we were surprised and disappointed to see how low it was. To better understand the situation, we ran a short survey. For sake of sharing, I included the questions in this post with the results next to the questions (in brackets).

  • Do you read the corporate blog? Yes = 53%, No = 47%
  • Do you wish to contribute to the blog? Yes = 78%, No = 22%
  • Why don’t you contribute to the blog?
    • Lack of time
    • Low priority
    • I’m already writing on my personal blog
    • I’m already contributing to the corporate wiki
    • Not important for me
    • No reason
    • Don’t want my comments to reflect badly on the corporation
    • Too complicated
    • My content may not be of high enough quality
    • Don’t have a good topic

Does your company have better success with employee blogging? Want to share your secrets?

Advertisements

Other interesting blog posts (May 12/2009)

In a courageous post, my friend Tremeur highlights that The power of Pair Programming is neglected within his organization. I like people who call a spade a spade and Tremeur took it upon himself to raise a situation he is not comfortable with. Kudos to him.

A stumbled upon an older blog post (The Seven Pillars of BI Success) that presents how 1-800-contact was successful using an Agile approach for their BI project.

Less projects were reported to be successful in 2008

The Standish Group released the most recent version of the Chaos Summary Report 2009 on April 23rd and the results are worst than last year with only 32% of all projects surveyed were reported to be successful (down from 35% in 2006).In the context of this survey, a project is defined to be successful if it was delivered on time, on budget and with the required features.

Chaos Summary Report 2009

Chaos Summary Report 2009

Along the same lines, 44% of the projects were challenged (did not meat one or many of the success criteria) while 24% totally failed. The Standish Group highlights that costs overrun 54% (+7%) and time overrun 79% (+7%) both went up compared to the 2006 results.

The reports also explains that the probability of success greatly decreases as the size of the project increases where projects costing less than $750,000 have 61% success rate while projects costing over $10 million only have 2% success rate.

The second part of the report present the 10 Laws of Chaos and while the report doesn’t make any correlation between these laws and the Agile principles, it is easy to make some correlations.

  1. Law of the Two Faces: Successful projects include business-knowledgeable users with good communication skills.
  2. Cheetah’s Law: Swift decisions are typically better than long, drawn-out analysis.
  3. Law of the Roads: Clarity and focus are essential to a successful project.
  4. Law of the Five Deadly Sins: It is how you deal with each of these sins that will determine the success or failure of your project.
  5. Law of the Long-Tailed Monster: Over- and under-building applications represents the biggest form of software development waste.
  6. Law of the Edible Elephant: Software should be built in small, iterative steps with small, focused teams.
  7. Law of the Mad Hatter: Complexity causes confusion and cost.
  8. Law of the Empty Chair: Keep the project cycles short with continuous deliverable.
  9. Panda’s Law: Inaction is the purest form of failure.
  10. Law of the Fools: It is not just having the right tools but the skill to use them that make all the difference.

Can you draw the parallels with the Agile principles?

Other interesting blog posts

I came across this article What Decision Makers Want. If you can ignore the fact that the author is pushing to sell a BI tool, the content of the post is very valid and useful to keep in mind when developing BI solutions for your customers.

The other post I wanted to bring to your attention is Jurgen Appelo’s The Big Agile Practices Survey Report where he presents the results of his survey of Agile practices.

Why use Agile for your BI project (slideshare presentation)?

The presentation given yesterday during the Agile BI – Happy Hour is now available on slideshare. The presentation is currently only available in French but it should be translated shortly.

Join us on LinkedIn

We created an Agile Business Intelligence group on LinkedIn a few months ago for people who share interest in Agile and Business Intelligence.

Join us and share your thoughts and best practices.

Agile pratices and methods applied to BI

Agile Pratices and Methods

Agile Pratices and Methods *

This afternoon, as I was preparing a presentation documenting which Agile practices and methods could be used in the context of a BI project, I came across this post that presents some of the Agile development methodologies available.

I’m proposing below Agile practices for some of the traditional data warehouse and business intelligence activities:
In upcoming posts, I will explain how each of these practices can be used by a development team to adhere to Agile principles in the context of a BI development project.

* Picture by bschmove used under the Creative Commons (CC) agreement. 
The view expressed in the blog post is the one of the author. 
The photographer does not endorse in any way the content of this blog post or the work of the author.

Agile Leadership Lessons

Agile Leadership Lessons *

Agile Leadership Lessons *

I came across an article that was published 6 months ago in CIO magazine. In the “7 Agile Leadership Lessons for the Suits”, the author makes interesting parallels known concepts and Agile leadership. Below are the 7 lessons and a brief summary of what each of them entails.

  1. Trust the Wisdom of Teams: Software is a result of a team effort, so a manager’s main concern should be nurturing the team.
  2. Even Self-Organized Teams Require Coaching: it would be naive and irresponsible to imagine that turning teams into self-organized machines means abdication from managerial duties. 
  3. Adapt or Get Out of the Way! The New Manager’s Role: collaborative environments, trust, transparency of information, and building productive and sustainable teams.
  4. Motivate, Don’t De-Motivate: Appraisals, Bonuses and Compensation: everything you are doing in your HR functions is wrong, because it is supported only by our illusions, not by facts.
  5. Write Value-Based Vendor Contracts: that clients are tired of vendors who promise low-ball prices and then make their money on change requests.
  6. Avoid Building Plank Roads: Waterfall was a plank road, said Poppendieck, aimed at solving the process problem by applying project management methods already used in other industries. But its applicability to software development was dramatically overestimated, and the ramifications of this strategic mistake haunt us to this day. 
  7. Who Do You Trust?: We are all guilty of stereotyping when we interact with others. We subconsciously label people.

If anybody gave you the impression that Agile was easy, think again. You may want to do some research and determine if the benefits will exceed the pains for your organization before jumping in.

 

 

* Picture by Jean- used under the Creative Commons (CC) agreement. The view expressed in the blog post is the one of the author. The photographer does not endorse in any way the content of this blog post or the work of the author.

I’m facing a big challenge. Can you help me?

I'm facing a big problem. Can you help me?

I'm facing a big problem. Can you help me? *

There are questions and challenges that keep coming up. No matter if you work on the business side or the technical side of your organization, you have certainly faced or might be dealing with some of these challenges and you aren’t quite sure what to do. If the statements below sound familiar to you, you may want to read on.

  • My project team constantly misses deadlines.
  • The project team keeps exceeding its budget.
  • My project team doesn’t deliver on the requirements.
  • The end users don’t know what they want.
  • The requirements keep changing and that constantly impact our project plan.
  • The project team develops software components that don’t seem to have any business value and they seem to produce more paper tha software.   
  • My team develops software that doesn’t satisfy my users.
  • The project team usually finds problems very late in the development process.
  • The project team does not have the right skills.
  • The project team is tired, nobody is having fun and we are losing good people.
  • I need to wait a long time before the project team gets me the information I need.
  • We know we have issues but we don’t know where to start.
  • We need to outsource our software development activities in order to cut costs.
  • The project team delivers poor quality software.
  • We have started using Agile for a small project and our management team wants us to scale it to the rest of the organization.

Agile principles can work for your Data Warehouse / Business Intelligence project but it is critical to determine which business problem you are trying to solve. Below, we are presenting a list of issues frequently encountered and we offer potential solutions to each of them.

 

What is your challenge?

My project team constantly misses deadlines.

How Agile can help

Implementing Scrum as your project management approach and the proper reporting tools (such as burn down charts) would help you anticipate potential delays and address your delays in a timely manner.

In addition, using frequent face-to-face communication instead of communicating through a project plan will increase your team’s productivity, performance and compliance to defined time lines.

 

What is your challenge?

The project team keeps exceeding its budget.

How Agile can help

The situation might be worse than you think because you may also be delivering the wrong functionality to your users.

Using long range planning often results in high variance in the actual budget being spent whereas delivering software in short iterations (up to 4 weeks) will allow you to better monitor your costs while ensuring you deliver the expected results.

 

What is your challenge?

My project team doesn’t deliver on the requirements.

How Agile can help

This could be two different issues – the requirements aren’t well defined by the end users or the requirements aren’t clearly understood by the development team.

In either case, enforcing close collaboration between the end users and the development team by co-locating the team and enforcing face-to-face communication will greatly increase the chances of delivering the right software.

You could turn the situation around by implementing the right processes which would allow you to welcome changes during the development phase and adapt to your changing business challenges.

 

What is your challenge?

The end users don’t know what they want.

How Agile can help

This is not unusual but it is not necessarily an issue with your end users. With most projects using a traditional software development methodology, end users are asked at the beginning of the project for their requirements and will eventually see the results months or years later once the software has been delivered.

With an Agile approach, end users are asked to define their short term requirements (for the next 4 weeks) instead of defining the entire scope of the project which will help the project team to deliver on the requirements.

 

What is your challenge?

The requirements keep changing and that constantly impact our project plan.

How Agile can help

Indeed, if you are using a traditional software development methodology you are likely to run into changes as the market dynamics evolve frequently. With an Agile approach, your team will not only learn to deal with changes in requirements but will even learn to embrace those changes and adapt accordingly.

 

What is your challenge?

The project team develops software components that don’t seem to have any business value and they seem to produce more paper than software.   

How Agile can help

Why are you? The focus of your development team should be to deliver value – working software. If for some reasons, a lot of your development team’s time, efforts and energy are spent working on documents (project plans, requirements, architecture, models, etc.) instead of working on software you probably need to reconsider the software development approach you are using.

Using a pragmatic and realistic approach like agile for your software development process will address the most critical problems typically encountered by a software development team and will greatly increase your return on investment.

 

What is your challenge?

My team develops software that doesn’t satisfy my users. Satisfying the requirements of your users is critical for a software development team and applying agile practices will greatly help.

How Agile can help

The integration of the business users as part of the development team is a great way to user their requirements are properly addressed. In addition, using techniques such as user stories that describe the features from an end-user perspective makes it easier for the development team to meet the requirements once it is clearly documented.

 

What is your challenge?

The project team usually finds problems very late in the development process.

How Agile can help

It is frequently recognized that the later you find problems in the process, the more expensive it becomes to fix them. Based on that conclusion, the implementation of an Agile software development approach forces the team to present the outcome of their labor to their users in order to demonstrate and test the software frequently which bring to the surface the issue.

 

What is your challenge?

The project team does not have the right skills.

How Agile can help

Although it may be possible that your team lacks some skills, it is unlikely that your people aren’t qualified for your project.

Your team might need some help and coaching around some specific software engineering practices and with the right coaching, they can improve their development skills.

 

What is your challenge?

The project team is tired, nobody is having fun and we are losing good people.

How Agile can help

It has frequently been proven that motivated employees deliver better results so if you want your project and your team to succeed,creating an environment where people can learn, work on challenging project and feel they are contributing to the success of the organisation will greatly help.

 

What is your challenge?

I need to wait a long time before the project team gets me the information I need.

How Agile can help

The business user and the development team may not be working closely together and you are probably using a traditional waterfall approach where the development team asks for requirements, goes off to develop and test the queries and reports and once they feel comfortable with the results will present them to the business users.

By including the business users within the project team and using an incremental development cycle, you would see the progress being made on your original request and could influence the amount of details required. Keeping small iterations and short feedback loops would allow you to quickly see how the development team is doing and quickly get access to the information you need.

 

What is your challenge?

We know we have issues but we don’t know where to start.

How Agile can help

An agile approach helps improve communications within the development team and with the business users. Having frequent demonstration of the system’s capabilities will quickly bring to the surface the issues and will allow the team to address them.

 

What is your challenge?

We need to outsource our software development activities in order to cut costs.

How Agile can help

Not necessarily, a better approach might help you reduce your costs. The Standish Group Study (Reported at XP2002 by Jim Johnson) showed that as much as 64% of system functionality was never used. Using an Agile approach to build the right software will immediately reduce the overall cost of developing software within your organization.

 

What is your challenge?

The project team delivers poor quality software.

How Agile can help

You may want to consider implementing test-driven development (TDD) where developers need to start by writing their test before developing new code or you may want to leverage pair programming.

In addition to changing the way you develop software, it would be beneficial to use short development cycle and demo the resulting products frequently in order to gain visibility to the software and address the issues in a timely fashion.

 

What is your challenge?

We have started using Agile for a small project and our management team wants us to scale it to the rest of the organization.

How Agile can help

Absolutely. Now that you have seen first hand the tremendous benefits of using Agile practices, you may want to coaching and guidance to help you roll out the new approach to the rest of your development organization and take full benefits at a larger scale.

 

 

* Picture by Mikey G Ottawa used under the Creative Commons (CC) agreement. The view expressed in the blog post is the one of the author. The photographer does not endorse in any way the content of this blog post or the work of the author.