An argument (using the agile principals as a base) for why software teams need to get closer to their end users / customers
Individuals and interactions over processes and tools
so…. you have built a few insurance applications in your time – but how many times have you actually seen the end users attempt to use this software. How many times have you sat down with the end customer, talked about the real world context in which they use this application, identified what problems they are having in using it and THEN iterated the design of the application in order to ensure they can actually extract the kind of value they need out of it. Is this kind of quality control (ensuring the end users find the application valuable) done EVERY iteration?
come on…. are you really having REAL individual interactions with the people your building software for on a regular basis (im not talking about your product manager)…. are you relying on processes and tools (like a dodgy persona done in one hour during inception, or saying you have got feedback from your customers in a one hour showcase that is not really structured to illicit feedback, but rather report on progress)
flame 1 – if you havent personally user tested your application with real users in the last iteration then your relying on processes and tools to shield you from the reality of end customer needs, motivations, fears and wants. dont blame the business – blame yourself.
Working software over comprehensive documentation
im going to preempt your response – your going to play the “Working software over comprehensive documentation” card, insist that the best way to service the end customer is to build the minium viable product and get it out there as quickly as posible, then get real feedback and iterate. Again i have to agree furiously in principal, but challenge your real world practice.
😄 is all about trying to understand the customer, and what the minimum viable product in fact is. 😄 is all about trying to get real feedback from customers and iterate by spiking the experience early, failing fast and failing cheaply in order to avoid late, massive and costly failure.
if you start a project (after inception) with a massive card wall, and have successfully cornered the business into prioritizing a set of feature stories BEFORE spiking the experience in a prototype – then your in fact relying on abstract documentation rather than working software to define a products vision.
flame 2 – if you havent spiked the experience using working software, tested then iterated in order to better understand the minimum viable product then your not really iterating – your just incrementing (thanks to jeff patton for that one:)
Customer collaboration over contract negotiation
ok… so this is where we get to argue about the definition of the word “customer”. 😄 suggests that you CAN’T rely on the product owner to act as a proxy for the end user. you may want to argue this “proxy” is just fine…. but i disagree.
Its difficult to find the balance between end customer and business needs when the product owner is the campion of both. Engaging with both real end users and business owners is a better way to understand these often competing needs. We should actively facilitate this exploration.
flame 3 – if your relying on a “proxy” for the end customers needs then go and read flame 1 again
Responding to change over following a plan
😄 takes this so seriously we in fact try and drive change. We attempt to challenge the business assumptions and hypothesis by testing them, iteration after iteration – so that we ensure delivering maximum value (not just maximum through put). If we discover that we are infact “building the wrong thing” then we attempt to drive change. Its not about blindly building what you descide within inception. its about getting feedback early, iterating and delivering real value.
flame 4 – if you have just blindly built what the product owner wanted, and the application is crap and you know it – then go and read flame 1 again.