What are First Draft Solutions and Why do we need to get rid of them?
The first draft of anything is shit.
This is a popular quote in writing. And I believe, this can be extended to many other work profiles and aspects of life, especially to the Software Development work.
If you are working on developing a software solution (in any capacity), you would know that most solutions are built based on first understanding, that are (at best) refined through a QA process before being released to the customers. I call them First Draft Solutions.
If you'll ask people, most would agree with the general wisdom that not trying enough possibilities and getting hands dirty at the initial stages can be rather draining for creative workers and could escalate to the point of delivering a solution that would (at best) deliver only functional value, but nothing else.
But when everyone is going Agile, releasing early and often, and talking of feedback and shifting the mindset, why are we still releasing first drafts?
Here are my observations:
1. Most teams do not prepare any prototypes/POCs.
Many don't even conduct any Brainstorming sessions. They just jump into the development and create whatever is best as per their initial understanding. And mostly, the responsibility to fill these understanding gaps lies on the PO.
I have been in calls where POs are asked about the 'exact, complete, final' requirement at the start of the development process (at times, in Sprint 0). By 'exact, complete, final' requirement they mean to the point of providing documented finalized UX design and UI components.
How is this even possible?
To take an analogy from the world of Theatre. A director can tell an actor what they want, how they see the process, what's their thought process, etc. A director cannot emote everything for the actor. If they do, then how is the actor contributing to the creative process?
An actor is supposed to take the input and try out a few possibilities. The director will then work with them to select and refine one of the possibilities.
Similarly, a PO can only tell you the what and why of a requirement, and maybe some inputs on the how. But 'how' is it going to be done is up to the developers. And to know that, creating POCs is a good way to start with.
(In teams where POs themselves do not advocate creating POCs are anyhow destined to be doomed.)
But then why are people shying away from creating POCs when it has such obvious advantages?
The primary reason for this leads to the second point.
2. People have moved to Agile, but they do not understand it.
Their mindset still operates as per the Waterfall method where the requirement used to be provided to the last detail before starting the development.
In Agile, we need POCs, we need prototypes, we need concept documents, design sheets, experience panels, feedback inclusion, etc because only with these trials can the client come closer to what they actually need.
And that is how a banal assumption based work is transformed into an interactive creative experience based work.
When a PO asks for a POC, it's not that they don't know the requirement. They are just asking what is needed for the job. They want the solution to move beyond the first draft. They wish the best and are providing the team with the scope of being creative. Teams must make use of such opportunities and create concepts that spoil the end-user for choice.
Becoming Agile begins with deciding to fail early and fail often.
3. Flawed understanding of Productivity.
One extremely common reason for the reluctance to design and redesign, work and rework, is the way people understand (or rather, misunderstand) productivity.
Productivity is not the amount of work you do today, it is the conscious effort you put to create value in the long run.
Most people understand rework as some sort of failure. As if, by reworking, they are losing time and customer's confidence. As if, without the rework, they believed that they are capable of gauging users' behaviour by themselves without actually trying out the solution with them.
Yes, rework can be exhausting and might feel like being stuck, but if approached the right way, and presented with a clear motive, it can be hugely rewarding.
It can become a way to do real study at work, rather than just doing what you already know how to do. It can become a way to understand your users' behaviour so that your future work is aligned with their expectations. It can be a way to get an insight into the scope of enhancements that can be achieved, if planned early and the right way.
But if it is constantly looked down upon as time wastage, all the scope of letting the creative juices flow would be wasted.
4. Not building a practice of taking and working with feedback.
There is no Agile without feedback.
There is no point in working in releasing early and often if you are not taking feedback and working on it.
But sadly, in my observation, most teams fail to work with feedback.
Why does this happen?
- There is no feedback plan. There is no decided process of taking feedback and including it in the backlog. There are no prototypes/POCs. There are no data flow/process flow diagrams. Habits are easier to inculcate at an early stage. And that can only be done with conscious effort and planning.
- Many fail to understand that releasing early doesn't mean releasing incomplete or defective. If you'll release with obvious gaps and defects, there will be no scope left for feedback.
- Most users do not understand what could be part of the feedback. They provide vague criticism and huge deviations from their early requirements.
- People take their work too personally. They take criticism of their work as criticism of their personality. They fail to differentiate between work and worker, and hence reject the former to save the latter.
- Teams believe they can collate and work on all the feedback in the end. That never happens. It leads to a huge technical debt and gaps that become impossible to be filled later.
There is no way you can better your first drafts without working with feedback. Take feedback, find ways to implement it, and actually implement it no matter how difficult it is.
5. Not providing the scope to fail and update.
Let's face it. Organizations have adopted Agile only in designations and ceremonies, not in spirit. Though they take pride in the accreditations they hold, the truth remains that for most teams Agile means Scrum ceremonies.
Most organizations do not provide any scope of experimentation. They make such tight timelines that from Week 1 itself, people have to deliver components of the final solution.
Leaders sitting at the top of hierarchy are more interested in the progress made, rather than the value created. PPTs presented to them contain more numbers and fewer observations and learning.
Such conduct from organizations' end means that they do not wish to create anything better than first drafts.
Conclusion
Since most solutions are built based on first understanding, without any POCs or Prototypes, and no planning with regards to taking and working with feedback, they are delivered as First Draft Solutions.
Along with these, cultural and organizational issues such as people's flawed understanding of productivity, lack of support from organizations' end, and inability to become truly agile add further to the problem.
If proper iterations of clarifications and feedback are not included from the initial stage itself, it can become almost impossible to recover. The solution can reach a stage at which including any worth feedback might demand the entire solution to be built from scratch.
The issues with First Draft Solutions become apparent at later stages. And usually, it leads to starting a 'feature bandage' rabbit hole, where unnecessary features are added to make the solution likeable and to provide a feeling of 'value for money' to the customer.
Better to experiment early, release and fail early and often, and include feedback as priority items in the backlog.