What’s the problem?
Having facilitated many agile planning workshops for clients who are new to agile, there’s often difficulties when it comes to breaking down features into user stories and planning them. The concept of defining prioritisable chunks of functionality and building solutions incrementally in this fashion allows you to detect and react to change early. What happens though when the first user story will take four months in a six-month project? How does this work for integration projects or data warehousing?
What’s the solution?
Every project is unique and will have a different set of risks and constraints. The delivery approach should be tailored each time to reflect the risks and constraints for the project. There’s no single recipe that’s going to prescribe how to plan a project but there are characteristics that will help you derive the most pragmatic approach. Here is where I usually start with a crazily over-simplied model I use to start the conversation during project planning.
Cost of incremental change refers to the ability to make a change and verify that it works, both from a technical and a business point of view.
It is often missed or not well understood and can be the source of tension during collaborative planning, especially to projects that are new to agile and wondering how it works for them.
Here’s some examples of projects I’ve worked on, their characteristics and the approach.
Example 1: Web Application
Overview – Web application to allow users to view their account information online.
Characteristics – Fairly standard Java technology stack. Heavy emphasis on security. New service offering and customer requirements fairly volatile. Good XP skills in team with infrastructure in place for continuous integration.
Approach – Typical agile approach of technical spikes for security and then small incremental user stories to gain rapid, iterative feedback from customers.
Example 2: Integration
Overview – Connecting a financial planning application to a mainframe that stored transaction information
Characteristics – Complex legacy systems with no automated testing and an extremely large code-base. Financial planning application provides a pre-defined interface so likelihood of requirement change was fairly low. Legacy system had not been integrated with another application. Initial connectivity was a high risk due to the complexity and size, expected to take the majority of the project.
Approach – Break the initial connectivity into smaller tasks that addressed the biggest risk first – hardcoding passed values initially then introducing the mapping of additional values iteratively for the rest of the project.
Example 3: Data Warehousing & Business Intelligence
Overview: Capability for a marketting department to understand the customer base, create offers and track their success.
Characteristics: Typical data warehousing stack with several data transformation steps and some reporting at the end of the data chain which made incremental change quite difficult. The customer feedback was critical but could only really be given on seeing the report visuals with realistic data.
Approach: The long chain of data conversion (some to provide abstraction, some for performance etc) added a big cycle time to any change which was a big blocker to getting the extremely valuable feedback from the customer. So with requirements change risk & cost of incremental change being very high, we ended up extracting data in a quick, non-performant way into a lightweight report. This allowed the customer very quickly to identify whether the report was needed at all. If it was then we then built it in the way that allowed it to be productionized.
So what?
As the three short examples have hopefully indicated, there’s no single way to approach how you break down and sequence the work but just characteristics that will help. Prescriptive methodologies might provide some value if you have an in-experienced team working in a particular project context – I’d argue that the particular project contexts are few. Also, that in-experienced team isn’t going to accelerate their learning if they don’t understand why they’re doing something, challenge it and be able to adapt it to their context. Adoption of tools always tends to be the easier route than the adoption of the backing principles.
Filed under: Uncategorized | 1 Comment
Search
-
Blogroll
