Pretty cool article I found yesterday: The 12 Principles of UX in Motion
Attending a Google Analytics and Google Tag Manager training today – offered by Google itself and best of all, free! I can only recommend it, here is an overview of all currently available Google trainings (e.g. Analytics, AdWords, Tag Manager, UX for Mobile, etc.) in Austria: Google Trainings in Austria
Some mobile apps have a poor user experience, some have a really great one. Time for positive feedback: I think car2go has a pretty awesome mobile app! I signed up for an account about two years ago but until now, did not use the service as a) I own a car and b) public transport in Vienna works absolutely fine and is cheap. However, visiting Burda Hackday 2016 in Munich this weekend, I had bad weather and was in a hurry, which is why I tried car2go. My conclusion: Getting the cars displayed in the app, reserving a car, giving feedback about the condition, ending the ride, etc. – everything worked fine and was absolutely intuitive. Great job! :)
This post isn’t really news – the agile manifesto and agile principles have been put down on paper in 2001. However I wanted to post this here, so I can look it up anytime! :)
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
- Customer satisfaction by early and continuous delivery of valuable software
- Welcome changing requirements, even in late development
- Working software is delivered frequently (weeks rather than months)
- Close, daily cooperation between business people and developers
- Projects are built around motivated individuals, who should be trusted
- Face-to-face conversation is the best form of communication (co-location)
- Working software is the principal measure of progress
- Sustainable development, able to maintain a constant pace
- Continuous attention to technical excellence and good design
- Simplicity—the art of maximising the amount of work not done—is essential
- Best architectures, requirements, and designs emerge from self-organising teams
- Regularly, the team reflects on how to become more effective, and adjusts accordingly
The definition of ready and definition of done can potentially be a matter of discussion between product owners, developers, quality engineers, designers and stakeholders – to have a guideline, I think the following suggestions can be quite helpful for this topic:
Definition of ready
- User story
- Description of GUI with mockups & designs added
- Description of story is consistent and clear
- Acceptance criteria completed
- Dependencies with third-party applications clarified (e.g. CRM or finance systems, DWH, etc.)
Definition of done
- Acceptance criteria fulfilled
- Deployed and tested on test environment
- Test cases documented & executed
- Handover to server engineers done
Great blog post which a colleague of mine found and forwarded to me: The 5 Golden Rules of Customer Support.
#1: All users are customers
#2: Your customer took the time
#3: Your customer is abrasive and demanding
#4: Your customer doesn’t understand your product
#5: Your customer doesn’t care about your workflows
“Anyone who stops learning is old, whether at twenty or eighty. Anyone who keeps learning stays young.” (Henry Ford)
After over eight years of software product management in different industries (web portals, banking, payment, etc.), I worked with different software development methodologies – from waterfall approaches to agile models such as Scrum or Kanban. In my opinion, every approach has its right to exist and might be the best possible solution in a given situation, depending on the type of project, culture, requirements, degree of maturity of all involved people, etc. I really love working with Scrum or Kanban and recently wanted to come up with a summary of all differences between these two methodologies, since lines seem a bit blurred here in my opinion. Here’s what I come up with:
- Artifacts: Scrum board, backlog, different types of requirement hierarchies (e.g. theme, epic, story, task), burn-down chart, velocity, etc. in Scrum vs. only a board in Kanban.
- Iterations: Yes (sprints) for Scrum vs. no (a continuous flow) for Kanban.
- Estimations: Yes for Scrum vs. no (items of similar sizes) for Kanban.
- Changes: To be defined, groomed and estimated for the next sprint in Scrum vs. added to the board as needed in Kanban.
- Roles: Product Owner, Scrum Master and Team in Scrum vs. Team and other needed roles in Kanban.
- Teams: Cross-functional in Scrum against teams which can be specialized in Kanban.
- Ceremonies: Sprint planning, daily stand-up, sprint review and sprint retrospective in Scrum vs. daily stand-up, regular reviews and retrospectives on set dates and continuous planning in Kanban.
According to derStandard.at, the first Bitcoin ATM has been launched recently on Mariahilfer Straße – http://derstandard.at/2000017564255/Bitcoin-Bankomat-auf-derMariahilfer-Strasse