The previous Tuesday marked the end of three joyous months at Digital Product School (DPS) with a rollercoaster ride of productivity, stakeholder communication, emotions and learnings. The latter I've spent the past half-hour to condense into this short read, i.e. six essential Koans.
At this point I'd like to thank our team Radlings for being the raddest team I could be part of so far. I learned more about myself as a person than 7 combined years of studying and I could not imagine a better team to share joy, laughter and my experience with. Thank you to the core team for accepting me into this program, providing guidance as well as confusion in the darkest hours and for gifting me the T-shirt that I will have to explain every time I wear it in public. Lastly, thank you in advance for reading this post and for giving me feedback on it.
Here it goes.
Scrum sounds like a snack.
But for short-bursted sprints it can actually produce quite some organisation overhead. Ideally, there should be a designated Scrum Master who moderates the Scrum events and makes sure that the artefacts are used for the greater good.
Don't (mis)interpret the user's problems.
The more you interpret or assume about the users' pains, the more you might have to verify or fix. This could be a costly mistake since it is more time consuming to "undo" this interpretation later on when you're done implementing the first prototype and it is handed to the user for testing.
Ideation is like a camel.
Only after several brainstorming sessions can one overcome the first hump - the one with only necessary and problem-solving ideas - to produce more creative, innovative solutions and to therefore sit more comfortably.
Canned fish will still be fish at the end of its fermentation.
But only by opening it up and exposing it to air, will it be criticised, appreciated or even consumed. The same goes for digital products that are meant for real people to be used. Working on the same thing for an extended duration of time with the same people will lead to biased thinking and redundancies within the following iterations. Exposing it to outside users will result in - to some extent - valuable learnings from the feedback and in some churn in the minds of the makers to generate new ideas.
There is no point (or semi-colon) in rushing to code.
As a software engineer in the team, you may have this really cool idea that you're really convinced of and that you're eager to start building using this framework that essentially does everything for you, but the whole point of user-centric thinking is that the user owns their problem and you have to design-think your solution towards solving it. This could mean putting the product and the team first and the Rockstar / Ninja software engineer second, or even not into the team in the first place.
True value lies in a specific, well-discussed statement.
It's fairly easy to agree on a generic item, may it be a task on the Kanban Board or an item of the User Story Map, which boosts the teams morale, because "Hey, we went through so many items in such a short period of time! Such productivity, wow!" However, it might be the case that different team members will actually have varying interpretations of that item. This misalignment will most likely manifest itself later on when it turns out that the team hasn't been on the same page after all and things need to be discussed all over again. So it's best to initially take enough time to thoroughly discuss ideas and to finally formulate them in the most specific, concise way possible.
Success and pitfalls are best experienced in practice, ideally by using as many Post-Its as possible (which is what the "P" in DPS actually stands for). And what better opportunity to do it other than at DPS in the most gorgeous city of Germany with other like-minded international people? So go make up your mind and perhaps join the next batch!
