How it all started
Imagine you are in charge of setting up a project to build your company’s next generation business intelligence and analytics system (here after summarized as BI system). The executive committee have a high level vision for what they want to achieve in the upcoming five years and a few ideas what they don’t want – especially based on their experience with the current BI system. Even though you have an internal BI development team at hand, you will have to build a new team based on existing people in the company as well as externally contracted staff from a company like IT-Logix.
Your boss is awaiting your proposal on how to organize for this project and what you plan to deliver at which point in time. This looks like a big challenge for you…
An agile project approach
In a first step you try to learn more about the requirements for the new BI system. You are interviewing several stakeholders. It is hard for them to formulate their data and reporting requirements. Often you hear „we just need all the data“ and then we’ll think about how we want to have the data visualized. You recognize that in such a situation, a typical waterfall project approach won’t be a good fit. You simply cannot define all requirements upfront. Therefore you decide to follow up on an agile project method. That means you will be delivering results in little increments, usually in short iterations of one or two weeks.
You still have to hand-in a proposal for your boss… Even though an agile process seems to be a good fit for your „requirements situation“, your current challenge is to convince your boss and especially your procurement manager. Of course you need some financing for both, the interal as well as the external staff. As for now you don’t even have an idea how big your team should be not to speak about what the team should deliver when.
That’s the point where you reach out to IT-Logix as they are not only providing BI development services but also consulting on BI specific agile project delivery. I’m glad to be your agile coach in the above described situation for at least the duration of you reading this blog post.
Mutual trust
There are various things to consider in your situation. Today let’s start with a very basic element – trust. Working together in a company is built on mutual trust between employer and employees as well as amongst them. In order to define the mutual expectations you usually use written contracts and regulations as a foundation. Nevertheless, nobody can ever fully control if you as an employee adhere to these rules. Your boss has to trust you – and evaluate your results. Typically, good results (e.g. a well delivered presentation or simply being on time in most of your meetings) will lead to increased trust by your stakeholders. The more trust you earn, the more likely it is you’ll receive a higher responsbility. If you succeed with it, you’ll earn even more trust and so on.
Trust is not only relevant to individuals but also to groups, e.g. your new project team or an external service provider like IT-Logix. A certain level of trust will be granted to you as an advancement. For example, at IT-Logix you can find a lot of references to existing customers and projects. Nevertheless, most of the trust needs to be earned. Earning trust works best in an incremental, iterative way. Sounds familiar? Indeed! An agile delivery process supports you in building trust quickly, step by step.
Looking at this trust aspect, how should you proceed in the above situation? Before handing in a proposal for the whole new BI system probably consisting of multiple months or even years of work time, let’s put together a team for a first, little release. Have a look at low hanging fruits for your new BI system. What small increment could tremendously support a certain group of stakeholders, e.g. the business people in the marketing department?
Building trust
Well done, you have identified the goal of your first release in order to earn trust for the bigger thing coming afterwards. But should you already start developing right now? Nope. Even in an agile context we shouldn’t just jump into coding (and therefore spend money) without thinking. That’s why we are typically splitting – even a small – release into three phases. Inception – Construction – Transition. You can learn more here for now. During the inception phase you’ll work on some minimal (or „just enough“) upfront design re scope and solution architecture as well as project organisation goals. Have a look here for more details. Most of the inception goals can be worked on in workshops and therefore be strictly timeboxed. Therefore it is quite straight forward to define the needed capacity and financing for this first phase (of the first release). At the end of the inception phase we suggest running a first milestone meeting. We call it the „stakeholder vision“. During this event the team working on the inception goals present the results of this phase and with what insights you’ll want to proceed with the construction phase. The stakeholder vision event is also your first opportunity to earn trust in the new project setup. Your boss and other stakeholders get a concrete idea of what should be achieved in the first release. Hopefully they grant you and the team the trust to continue with the first release.
Next time, I’ll show you how to continously earning trust throughout the construction phase of your first release. cu soon!