Agile methodologies such as SCRUM and KANBAN are the most used frameworks within small and independent software development teams. In theory SCRUM and KANBAN are really easy to establish in teams and companies. However, the majority of software development and product companies have more than one development team working on the same product at the same time. Does that mean companies with more than one development team can’t establish agile methodologies?
Of course not, but companies need to have the right environment and the right mindset inside the company to scale agile software development across all disciplines.
Scaling Agile Development The Right Way
The first piece of puzzle every company has to find is the north star. With the help of this product metric, the company can define its vision and mission. This will help the software development teams in terms of guidance, stability and focus.
The next part of the puzzle is the development infrastructure. It must be modern built up on the latest technologies and patterns to build a microservice architecture to provide agile teams the possibility to release whenever they want independent from other teams inside the organization.
Last but not least, it’s important to keep the agile development teams small and as independent as possible. With the help of agile coaches, the right agile mindset can be established inside the team. Once all of this is in place, it’s time to scale across the organization.
Read more about this topic in my lastest blog post I wrote for Applause here:
Maybe you have seen it already on YouTube or twitter. Currently, I am recording an online testing course for Ministry of Testing about mobile testing. In this course I will teach you the fundamentals of mobile testing.
The course will include the following topics:
- History of mobile devices
- Hardware of mobile devices
- Mobile Device Fragmentation
- Mobile Data Networks
- Comparison between iOS and Android
- The different mobile app types
- Mobile app stores
- Mobile app business models
In each lesson I will talk about the testing impact and will provide usefule resource for you to kickstart your mobile testing activities.
Take a look at the course teaser.
The complete course will be online soon in the dojo at https://www.ministryoftesting.com/dojo/courses.
I am looking forward to your feedback and the discussions about mobile testing in the club as well on the ministry of testing community page.
Every product owner, designer or development team has ideas for a potential new mobile product or feature. Some ideas are worth following, some are not. But how does one know, which idea to follow and which one to drop?
The answer is simple, a team has to try it out. A team has to innovate on mobile product ideas to find out if the product idea is something the customers have waited for and want to use. If a team has lots of new ideas and don’t know which one to innovate first with, it’s recommended to bring all the ideas to a meeting or workshop and to check if e.g. the ideas fit either to the target customers, the needs or solving a specific problem. At the end of the meeting or workshop a prioritized list must be the result.
In order to bring the idea to the app store there are multiple stages a product team must go through. The first phase is the fake it first phase. In this phase the team is drawing rough sketches of the potential new mobile product. The drawings can be done on real paper or with the help of wireframing tools.
The drawings will be connected to a first user flow and later on tested with real customers.
But what comes next? Find this out in my lastest blog post for Applause, I wrote more about this process of innovating on product ideas, which tools to use to create a wireframe and what a mobile innovation lab has to do with mobile product development.
Read the complete article here:
And soon we are heading into 2019 and as a tradition of my blog, I always take the opportunity to look back what happened in the last year. The year 2018 was different for me. In terms of blogging and working. I shifted my focus from writing on my own blog to other blogs to support them with hopefully valuable content.
Also as a tradition I like to share numbers about my readers, where there are coming from how many of you visited my blog and so on. However, I can’t deliver this information to you anymore. The reason is simple, thanks to new GDPR law in Europe, I removed ALL the tracking from the blog. I have no idea where you are coming from and how often you are here.
But that is totally OK for me and I think for you as well 😉.
My testing highlights for this year where the 3 conferences I attended as a speaker. One of my favorite testing conferences on this planet are the Nordic Testing Days in Tallinn.
Releasing an app is not an easy process. Once an app is rolled out to the customers there is no way of rolling it back like on web platforms. Imagine a native mobile app as a good old burned CD that was shipped as a part of a magazine or hardware parts containing the drivers. Once it’s burned and shipped you can’t fix it. The same applies for native mobile apps. Therefore, a solid mobile app launch strategy is key to success for every company.
Before an app can be released it’s important to know all the technical information about the software development cycle. How many developers, testers (internal or external) are involved in the app development. How often will the app be released, what is the sprint cadence. Is there an internal or external beta testing community in place that can be used before rolling out the app to the customers? As a foundation for the release strategy this kind of information is important.
When the development cycle comes to an end it’s important to gather all the required release information from the product team. Every release should have meaningful release notes informing the user about the new release. The store descriptions must be updated as well images.
Before building the release candidate of the new app version, every team must execute the automated checks and see if they pass. Additionally, it’s recommended to perform a last exploratory testing session to see if all the critical parts and the new features are working as expected.
The last thing before going live is to check the release checklist. A checklist for a release must be in place to double check that nothing was missed out. Find out in my lastest blog post for applause what the release checklist is all about and what needs to be done in the post release monitoring.
Read the complete article here:
LINK APPLAUSE BLOG