The day started with a mistake I’ve made. I didn’t check my mailbox accurately and missed the info that workshops aren’t held at the conference venue. I knew that there were some email but I thought it’s redundant and everything is on the homepage. It wasn’t. After all, I managed to track it down and get to the Prezi office in time when the workshop was held.
The workshop was about How to Make Big Impact with Software Products and Projects by Gojko Adzic. We had to form group which was very nice because most people didn’t know each other. We had to come up with an imaginary milestone plan for some kind of a software. It was interesting that the seven groups came up with quite different ideas and every group was able to defend his own viewpoint. One group defended the idea that they didn’t want to touch the legacy code of the system, other team came up with the idea to rewrite the legacy part. The conclusion was, that no ranking can be defined, it’s nearly impossible to judge, which will be the best solution. It was also extremely difficult to work with people who I didn’t know and not necessarily agree with them, but we have to came up with a solution in five minutes.
In other tasks we had to make mindmaps and implementation plans and after each task the presenter held a presentation about the conclusions of our results. Some takeaways:
- Make a victory condition for user stories, which is different than DoD which is a technical thing. Victory is, when the story really works in the practice as it was expected.
- A user story should be about changing a behaviour not creating one. In most cases the operation, which is described by the story, is already doable but maybe not enough effective.
- Raise the level of discussion. Challenge stories, they’re not given by god. In fact, users aren’t designers, they can’t design a software. Never rely blindly on their claims.
- Never say No to stakeholders just Now or Not Now.
- A story can be sliced in many different ways, for example by a group of users.
- Quality means many different things. It’s hard to come up with some success criteria but in most cases more aspects have to be investigated. If a high-quality code doesn’t fulfill the users’ functional requirements it’s still valueless.
- Reserve a learning budget. Implementing an easier variant of the functionality may give useful feedback about the correctness of the idea. Implementing doesn’t necessarily means writing code. An automatic behaviour can be mimicked by hand for some users (for example sending ‘automatic’ notifications).
- A Maslow pyramid can be defined for software, where the lowest level is the fact, that the software actually builds and runs. Next level up is to be performant and secure, then to be usable, then to be useful and the top is to be successful.
So, the message was basically injecting the lean process into the Scrum/Agile process which I very much like. I don’t think if all companies can apply this, especially the ones which still have some waterfall-ish way of thinking but it’s definitely a good direction for startup-like companies.
The presenter had another talk on the conference with somewhat similar content which can be seen here.
It was nice to form groups and the workshop itself was great. On further days of the conference I met some former team-mates and had some discussion with them. It was also interesting to see Prezi office basement and their magic words (boarding, prezilians, HP). We had a great dinner in Apacuka. After the workshop I had a glass of wine in Aquarium and one more near Epam office, then I went to one of the meetups but let it be the subject of another post.
Comments