On May 5^th 2014 I started my first day as an Ebicus Consultant specializing in Oracle Siebel CRM Projects. My experience over 4 decades in the industry has taught me that it is important to be creative and flexible when it comes to projects, including the estimation of the project, overcoming development challenges, nurturing user adoption, and the always challenging deployment process.

Figure 1: Huub van Rijswijck, Harvey Saks

It is my intention to share what I have learned and the challenges I see facing IT Organizations today. In upcoming articles I will try and balance the content between Project Management, Development, Analysis, Design, Documentation, Testing, and Deployment topics. Some articles will focus on Technology, while others may focus on Methodology. Those who know me will agree that I am opinionated and full of stories, and I hope to share both with you.

Most if not all of the Siebel Projects I have encountered over the last few years have been allocated to Implementation Partners using off-shore workers. Many if not all of these Projects exceed budgeted time or costs. Many of them also suffer from poor performance, maintainability challenges, or User Adoption issues.

This reality should be familiar to anyone in IT Management positions, who are now hoping Agile/Lean Methodologies will help them improve their project success rates. Truth is, if you use a Waterfall (Prince) or an Agile Methodology (Scrum), the skills and attitudes of the team as well as the Governance imposed on the project will do more to ensure success than a change in methodology.

Figure 2: SCRUM

Having said that, I also want to be on the record that though I joke and have been heard to say that Agile is Project Management for companies that can’t manage projects, I like the Agile Methodology conceptually, it is Business Focused, Flexible, and should be Fun for the Team. Unfortunately I have heard as many horror stories associated with Agile as I have with Waterfall.

For those unfamiliar with Agile, a quick explanation is that historic Requirements are organized into User Stories. Complex and large User Stories can be broken down and grouped together as an Epic. In classic Agile, these stories represent all the “I Want” requests from the User; we call it the Product Backlog. The Product Backlog must be Prioritized and allocated to a Development Stage called a Sprint.

Without the participation of someone familiar with both the business and the technology these Wants can be grouped in a fashion that could lead different teams to different solutions, or worse, creating a maintenance nightmare when an elegant solution could have satisfied many requirements. A Product Owner able to represent the business must be identified and most likely developed. I believe the development of a Technical Product Owner married to the traditional Product Owner is also needed to give the development team the ability to look further down the road and plan for the trip ahead. The Technical Product Owner is not an Agile concept that I have encountered but it can be very useful in this stage, mobilizing the staff needed to solve design and development challenges as well as set expectations for the business regarding costs, resources, and times needed for challenging objectives.

Once the Backlog is set and the stories grouped, a Sprint commences to satisfy the Users Wants. The Sprint is typically anywhere from 2 to 4 weeks in length and is made up of a dedicated team who stay together from one Sprint to another. The team selects from the Backlog of User Stories (associated with the Sprint) and as they complete each story they are required to demonstrate the result and provide whatever documentation is required by the Teams Definition of Done.   Before starting Agile Scrum it is necessary to define the Team’s definition of both “Ready” and “Done”. Supporting the Team is the Product Owner and Scrum Master. The Product Owner is the Business Liaison while the Scrum Master is an individual capable of resolving issues that block the ability of the Team to complete the assigned User Stories. Neither role participates in the actual development process.

The first Agile problems I heard about came from the United States as early adopters embraced Agile, after allocating User Stories to Sprints; Teams were told that they HAD TO complete all User Stories in the Sprint. This is not Agile, as the Team is supposed to complete as many items as they can and anything left undone, gets reprioritized and typically included in the next Sprint.   As a result not only were teams not having fun, in reality they were being pushed to the breaking point.   Illness entered into the picture as teams were unable to catch their breath before the next intensive push started. In Agile terminology we talk about the Velocity of the Team. When long hours and illness creeps in on a regular basis key staff members missing due to illness severely impacts the Velocity of the entire Team.

Figure 3: The Economist, Working hours, get a life—or face the consequences

While this problem is not unique to Agile as Waterfall projects also face extended hours in order to hit deadlines, other problems introduced into projects including those associated to products like the Oracle Siebel CRM platform are unique to Agile.

A key to Waterfall Methodologies is a Life Cycle that starts with Requirements Gathering and then a Design Stage, before starting a Development stage. I personally like this breakdown as Development goes faster if the Design of the solution is done well. With Agile, we go from Requirement (The User Story) directly into Development (The Sprint). Many Teams instead of using consistent Design Patterns pick a solution that works for that specific User Story only. This may result in work that has to be torn apart later or may need to be completely removed to accommodate future requirements.

I believe that this is a significant issue especially for Siebel CRM projects as it leads to a cacophony of solutions that become overly complex, difficult to debug, and leave Users experiencing slow response times. Having encountered this on a number of Agile Siebel projects, when given the opportunity, I adjusted the Agile Team structure adding a Technical Product Owner. While the Product Owner is responsible for ensuring that the solutions work for the User Community, the Technical Product Owner ensures the integrity of the Design.

I have seen some Teams accomplish this task with a Design Review Board who is responsible for governing the solutions picked by the Development Team. The problem is that this either happens after the work is done or it requires an approval process that slows the velocity of the team. With Vendors and non-technical Managers making up the Design Review Board, the conflicting interests and lack of technical understanding make this a difficult and politically charged way of working.

The inclusion of a Veteran taking up the role of Technical Product Owner provides a Technical Subject Matter Expert responsible for guiding the Sprint to recommended solutions and standards. This individual working closely with the Business Product Owner can look beyond the Sprint to ensure that there is Control over the development process and consistency between solutions. I indicate that the Technical Product Owner should be a Veteran of the technology used in the implementation, as a good Design needs someone who understands the Pro’s and Con’s of the available technical and business options.

Figure 4: Veteran Technical Product Owner

Since this post is getting a bit long I will end it here before going on to my next challenge for those considering an Agile Methodology, Documentation. Nothing I have seen gets a Scum Master upset like the topics of Documentation which is supposed to be very Lean for an Agile project. In my next post I will address Siebel Documentation requirements in an Agile environment.

Your responses are encouraged along with topics you would like to see addressed in future posts. For now have a great summer and success with your projects!