I would like to share some insights I experienced during a recent project where the agile is a way of implementing and delivering our enterprise innovation management software, Accolade. The agile approach proves itself, by instead of waiting for months, the first pieces of “ready software” are available within weeks. These pieces are called sprints. Ideally the outcome of sprint should immediately contribute to the business needs. Nevertheless a sprint can also be addressed to prove that a required interface is working properly and it eliminates the technical risk for the project.
For this project the target delivery date is fixed and it contains about ten sprints (each two weeks) implementing a dozen of user stories. A user story describes a part of a business process where a user wants to achieve a certain goal within. More about the agile method can be found on the web. I would like to highlight the key learnings to take into consideration for delivering a successful project.
Focus on delivering business value, not just working software
The business manager funds this project to achieve these main strategic goals: improve the time to market, increase margins and decrease the amount of stock. One of the initiatives contributing to these goals is getting new product development, sales and marketing more efficient. Will this be solved by buying and implementing software? No, is the answer. It fundamentally starts by putting the right process architecture in place. The process architecture is a holistic description of processes, organization, information and technology contributing to the company strategic goals. It's the instruction framework to start implementing and from which to deliver the software. Without it, it is akin to sailing a ship without a compass.
Adoption of the software starts with early involvement of the end users
Early involvement and feedback from end-users is characteristic for the agile approach. Unfortunately, it is often forgotten who the real end-users are. Understand how they work and what kind of information is required for their day to day work and decision making within. During the process architecture definition, questionnaires, scoring cards, a mock-up of a process, template or even a dashboard really could contribute to get a clear understanding and set end-user expectations.
First clear instructions, the process architecture and then start sprinting
The process architecture must be defined first, the processes, decision making within (Rules of Governance) and information model must clear before start configuring, building, testing and delivering the software. If not, you will be directly confronted with these missing key fundamentals. The agile project team will start guessing and making assumptions what they think is the best solution for the business (their client!). After a sprint, presenting the results to the business will mostly turn into a disappointment. As a result of that you need to re-adjust your assumptions and a lot of rework needs to be done, which means delay of the project or less functionality can be delivered. Furthermore, the process architecture is a good fundamental for the sprint planning and required efforts to deliver.
Two different characters of the project
The best way is to apply a project approach with two different characters. We start first with the architecture & design phase with a blueprint (instructions for the software) as a result. This phase is to nail down the process architecture and all the while manage the expectations for the end-users and stakeholders. Early involvement from the business is to understand which user stories are most important and contributing to that.
Phase two of the project is focused on planning, execution and delivery of the sprints. Within a sprint you can cover one or more prioritized user stories for the full extent or partially. Please avoid too many fragmented user stories and too short of sprint cycles because these are difficult for the business to validate. Advice would be to implement one or a couple of full user stories within a three week time frame.
Prioritize the user stories according the business needs
Who are the end users? What are their needs? What are their concerns? What are their adoption criteria? The architecture & design phase of the project starts by interviewing a group of people. These interviews results in quotes made by the users. User quotes are important; it is what the company is saying and reflects its actual culture. Examples of user quotes:
- “We abandoned our innovation culture, focus is on cost saving!”
- “I want to have high quality product samples on time to get early feedback from consumers.”
- “I don't like the sales guys and their way of behaving”
- “I would like to have a nice and shiny blue interface”
Finding patterns and ranking these quotes will set the prioritization input for the sprints. Above written quotes number one and three are organizational issues and couldn't be solved by software. Quote number four is a nice to have. We consider quote number two as most important part for the process architecture which must be fulfilled by the software
Compose a democratic and capable project team
The agile method uses sprints of two to three weeks where a part of software is build and delivered. Keep in mind that delivering value for the business is NOT only building the software. That's reason why a multi-disciplinary project team is critical for success. End-users, business owners, stakeholders, programmers, business consultant(s), project manager and a solution architect must be part of that team. It is critical to set the right balance between all those individuals. Collaborate, be honest, transparent and challenge each other in a professional way.
The innovation process architecture must first be clear and understood; otherwise you could never achieve real business value!
