Skip to content

Archive for

Is it the management team who makes the difference?

A colleague brought to my attention that for most corporate web sites, clicking on the “Our TEAM” hyperlink  only presents the members of the senior management team. The landing page presents the profile of the chairman, CEO and executive vice presidents. At Pyxis, individuals are central to the company and transparency is a strong value. Try this exercise and click on the hyperlink “Our Team” and you will see photos and profiles of all employees in alphabetical order – no title, no hierarchy, only employees and their expertise.

In consultancy, the services and the expertise of the consultants is what gets sold. So why do so many organizations continue to promote only the members of their management team? No photo, no information relevant to their most important resource, their employees. At Pyxis, we believe it is critical that our customers know the consultants with whom they will work on a daily basis. We also believe that we can not claim to be transparent in our relationships with our customers without demonstrating our transparency on our website.

Some will respond that it is too risky to disclose information about their employees. They wish to prevent competitors from recruiting their employees, to which point I would argue that when an organization treats its employees as true partners, the employees will respond with loyalty to their organization. In any case, failure to display information about your employees will not prevent competitors from trying to pick your best talent. Your competitors have many other ways to get to that information. So why limit the dissemination of this information? Why not provide your employees with the exposure they deserve?

Pyxis is currently recruiting for a Consultant – Agile Business Intelligence Developer

Pyxis helps software development companies to become places where results, quality of life, and fun coexist sustainably by being first and foremost an example of what it proposes to its clients and by coaching them.

Pyxis is currently recruiting for a Consultant – Agile-Business-Intelligence-Developer to work with our customers in the Montreal (Canada) area.

Your qualifications
 5 years experience in business intelligence development projects with tools from the Microsoft BI platform (SSIS, SQL Server 2005 / 2008, Analysis Services and Reporting Services).
 Knowledge of project management with Scrum and other Agile engineering practices such as XP, unit testing, Test Driven Development (TDD), continuous integration and code refactoring.
 Experience with data modeling and database design (cubes, star schema, etc.).
 Bachelor’s degree in management information systems or equivalent experience.
 Fully bilingual (English and French)
  • 5 years experience in business intelligence development projects with tools from the Microsoft BI platform (SSIS, SQL Server 2005 / 2008, Analysis Services and Reporting Services).
  • Knowledge of project management with Scrum and other Agile engineering practices such as XP, unit testing, Test Driven Development (TDD), continuous integration and code refactoring.
  • Experience with data modeling and database design (cubes, star schema, etc.).
  • Bachelor’s degree in management information systems or equivalent experience.
  • Fully bilingual (English and French)

Other interesting blog posts (May 26/2009)

A good post for those who don’t quite get test-driven-development and pair programing, Mike Hill provides counter arguments to demonstrate why TDD and PP both work well in a development environment.

If you are a WordPress user and live around Montreal (Canada), you may be interested in WordPress’ Word Camp Montreal.

I am often asked to suggest books and this is why I made my virtual bookshelf available. Mike Cottmeyer has listed the books he recommends often.

Agile Data Warehouse

A friend of mine (thank you Alfonso) sent me the presentation that was recently given at the Information Management Conference. The presentation given by Oliver Ratzesberger, Senior Director at eBay presents some interesting observations:

  • To know if the data is valuable to the business users, they need to experiment with it;
  • The best way to satisfy your end users is through early and continuous delivery of capabilities;
  • The traditional approach to DW development takes too long;
  • Prototyping and sample data can help determine the real ROI of additional information;
  • The Agile approach worked for eBay.

A copy of the Agile-Data-Warehouse presentation is available.

Other interesting blog posts (May 21/2009)

Is your organization getting good usage from your BI application? Apparently, just over 8 percent of employees are actually using BI tools.

The noise level around Kanban is increasing and Comparing Kanban to Scrum helps better understand the new buzzword.

Another frequently used comparison is between the Product Owner and the Project Manager and the Agile Product Manager in the Enterprise: A Contemporary Framework attemps to clarify the situation.

Warning Business Users! People are Wasting your Budget

Secret World of IT Development

Secret World of IT Development *

First of all, this blog post is directed toward everyone working outside the IT department who would like to know what is going on within that department.

I want to let you in on a well kept secret in IT departments around the country but before I do, I need to warn you about the consequences of being exposed to such information. Once you know the secret, you will feel compelled to do something about the situation you are about to uncover, so beware. If you read further you may start doing things you never did before.

Did you know that those geeky looking software development guys are spending your budget and deciding on your behalf? Yes, the same guys who wear pac-man t-shirts and have lego blocks and lava lamps on their desks are deciding what is good for you and your department. I can’t tell if this is part of an evil plan to take over your company but in all honesty, you can’t really blame them for what they are doing.

This is bad, you say.

As with many organizations, the IT development guys are under a lot of pressure to show value and this is typically accomplished by delivering software or reports, usually software artifact that gets deployed to business users. They need to show value and most importantly, they need to show it fast. Since business users haven’t spent much time and energy working with them to define what will make their job easier, they started to decide what is good for the business by themselves.

In this context,  if business users spend little time giving requirements to the development team, they will go away programming what they believe they understand of the business users’ needs and after a few weeks they bring back a piece of software. Game over, pass go and collect $200. They can then move on to the next project and show value.

Here’s the secret, this doesn’t work and you can easily understand why.

  • the business requirements may have changed;
  • the solution may not meet your expectations;
  • the solution delievered may not actually provide business value.

So in a nutshell, your precious budget is being wasted and although everybody complains their projects have been in the queue for a while, the IT department can walk in to the next management committee meeting show how many projects they have provided to the organization.

Here’s how you can disrupt this pattern.

  • Find out what the development team is working on. Do you know when your projects are scheduled to be delivered? Are they the highest priority for your department?
  • Is your project really important for your organization? If it isn’t, don’t waste the resources. Instead find someone who has a higher need for their project and strike a deal with them to bump up their project’s priority. You will ensure the resources are put to better use and will make friends within your organization along the way.

If the project is indeed important for you, treat it as such. Assign a knowledgeable and trusted person from you team to work in close collaboration with the development team. Even better, have your business ressource sit with the development team.

Despite the preconceived opinion, you will be surprised to see that most of the geeky looking development guys will be very happy that the business users are working with them on the project. Most of the development guys I’ve worked with over the year truly prefer to work with the business. They don’t always show their true feeling to the business community – it’s a secret code within their expertise – but here are the reasons why they appreciate the close collaboration:

  • They like to contribute value: Nobody likes to produce something that doesn’t get used, even worst, something that gets thrown away.
  • They like their expertise to be recognized: Technical people spend years developing their abilities and when they get to use it to solve a business issue, their expertise gets reconigned.
  • They get to understand the business: Contrary to popular beliefs, most technical resource like to understand the bigger picture and how a technical solution is applied in the business context.
  • They actually like to work with people: Flat screen, keyboards and mice are less emotional but development resources do prefer to work with people. 

So there it is. Now that you know the secret, you can no longer walk away from an IT project without getting involved. Asking questions is a good way to start. Showing interest in your project is even better.

Post a comment below with a question and I can give you some tricks to improve the situation.

 

* Picture by illustriousbean 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.

Scrum Artifact: Sprint Backlog

The sprint backlog is the list of tasks that the Scrum team is committing that they will complete in the current sprint. Items on the sprint backlog are drawn from the Product Backlog, by the team based on the priorities set by the Product Owner and the team’s perception of the time it will take to complete the various features.
It is critical that the team selects the items and size of the sprint backlog. Because they are the ones committing to completing the tasks they must be the ones to choose what they are committing to.
The sprint backlog is very commonly maintained as an Excel spreadsheet but it is also possible to use your defect tracking system or any of a number of software products designed specifically for Scrum or agile.
 During the Sprint the ScrumMaster maintains the sprint backlog by updating it to reflect which tasks are completed and how long the team thinks it will take to complete those that are not yet done.
The sprint backlog is a document containing information about how the team is going to implement the features for the upcoming sprint. Features are broken down into tasks; as a best practice tasks are normally estimated between four and 16 hours of work. With this level of detail the whole team understands exactly what to do, and anyone can potentially pick a task from the list. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills.
The sprint backlog is property of the Team. Estimations are set by the Team. Often an according Task Board is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done”.
The sprint backlog is a simple list of the tasks that must executed by the team in order to deliver an increment of functional software at the end of that sprint. Sprint backlog creation happens in the second part of the sprint planning meeting with the participation of every team member. Giving some real attention to this process is fundamental to a better understanding by the team about what should be done and to better planning during the sprint. Despite this, many teams still struggle with this activity. I hope these tips will help.

 

The Sprint Backlog

Definition

Similar to the Product Backlog, the Sprint Backlog is a list of tasks that the Scrum team is committing to deliver within the current Sprint. The Sprint Backlog is a simple list of the tasks that must executed by the team in order to deliver an increment of functional software at the end of the Sprint.

How the Sprint Backlog works

Based on the priorities set by the Product Owner, the Scrum team selects as many items from the Product Backlog as they believe they can complete within the current Sprint.

Sprint Backlog creation happens in the second part of the Sprint Planning meeting with the participation of every team member.  It is critical that the team selects the items and size of the Sprint Backlog since they will be the ones committing to completing the tasks.

During the Sprint the Scrum Master maintains the Sprint Backlog by updating it to reflect which tasks are completed and how long the team thinks it will take to complete those that are not yet done.

 

References:

Scrum Role: Product Owner

The Product Owner

There are three fundamental roles in Scrum: the Product Owner, the Scrum Master, and the team.

Definition

The Product Owner is the one person responsible for the project’s success. The Product Owner leads the development effort by conveying his or her vision to the team, outlining, and prioritizing it based on business value. As such, the Product Owner is responsible for representing the interests of everyone with a stake in the resulting project.

The Product Owner differs from that of the traditional Product Manager role in many ways.

What the Product Owner does

As the owner of the product vision, the Product owner shoulders all the responsibility for the project success and is ultimately responsible to the Team, stakeholders and to the company.  Here are some of the activities perform by the Product Owner:

  • Creates and maintains the Product Backlog;
  • Prioritizes and sequences the Product Backlog according to business value or ROI;
  • Assists with the elaboration of Epics, Themes and Features into user stories that are granular enough to be achieved in a single Sprint;
  • Conveys the Vision and Goals at the beginning of every Release and Sprint;
  • Represents the customer, interfaces and engages the customer;
  • Participates in the daily Scrums, Sprint Planning Meetings and Sprint Reviews and Retrospectives;
  • Inspects the product progress at the end of every Sprint and has complete authority to accept or reject the work done;
  • Can change the course of the project at the end of every Sprint;
  • Communicates status externally;
  • Terminates a Sprint if it is determined that a drastic change in direction is required;
  • Understanding and communicating the customer needs;
  • Meeting the project goal and financial targets such as return on investment (ROI);
  • Collaborates with the team and aligns with the stakeholders throughout the entire release.

References:

Scrum Artifact: Product Backlog

As I’m gathering information and slowly writing the content of my book, there is some information I need to refer to in the book but I don’t want to include as it distracts the reader. As such, I decided to start keeping that information and post it on this blog. It will be easy to know when a blog post is done in the context of the book as it will be tagged “the agile bi book“. Today’s post relates to the Product Backlog.

The Product Backlog

Definition

The Product Backlog is simply a list of customer requirements needed to complete the project and sorted by business value. It is initially prepared at the beginning of a project by the Product Owner and remains active throughout the duration of the project as completed items get removed while new items are added.

How the Product Backlog works

As time goes by, the highest priority items in the Product Backlog get broken down into smaller chunks as they become part of the Sprint Backlog.

The Product Backlog is property of the Product Owner while the business value is set by the Product Owner, the development effort is set by the team. 

Benefits of using a Product Backlog

1) It’s a simple list, discussed face-to-face
2) It provides the customer with control
3) The product backlog is allowed to change.
4) Inspection and adaptation
5) It resolves dependencies timely, and without fancy pansy dependency graphs.
6) It allows for some longer term planning
  • It’s a simple list, discussed face-to-face;
  • It provides the customer with control;
  • The product backlog is allowed to change;
  • Inspection and adaptation;
  • It resolves dependencies timely;
  • It allows for some longer term planning.

In Summary

The Product Backlog:

  • is simply a list of things needed to be done in the context of the project;
  • always lists items that add value for the customer;
  • may include functional requirements and non-functional requirements;
  • can also include items required by the team, but only the ones that will eventually bring value to the customer;
  • cannot include low level tasks. 

References:

Join us on Ning, a community to share thoughts and best practices in Agile BI

http://agile-business-intelligence.ning.com/ 

Many people have a blog in which they share great ideas to improve the success rate of BI projects. In order to aggregate all this useful information, I have created a community to share thoughts and best practices to improve the success rate of business intelligence projects using Agile methods. 

The objective is to build a community around this specific area of expertise and aggregate blogs.

Join us.

Follow

Get every new post delivered to your Inbox.