Software-as-a-service is what the great majority of our users want, but we're getting a steady trickle of requests to run Screenful on customer premises, too. Some companies just prefer to keep their sensitive data behind a firewall and host their own tools.
Rapid innovation and being first to market is something we all strive for. However, measuring the performance of a development team is anything but easy. No single measure is enough. If you only track velocity it quickly leads to decreased quality. Although your customer would like you to deliver quality work fast but at low cost, the age old truth is that from those three, you can only pick two.
Scrum is one of the more popular frameworks for implementing agile. It’s also the flavour that teams tend to pick first when they want to get started with Agile methodologies.
With scrum, the product is built in a series of fixed-length iterations called sprints that give teams a goal of delivering new software capability every 2-4 weeks. And it's no longer just software teams that are using Scrum, as it had spread to other business functions such as marketing, which can also benefit from Scrum's ability to address complexity and ambiguity.
In the previous post I explained how understanding your cycle time helps you to become more agile, and better at predicting your delivery dates. In this post I want to introduce another, related, metric that is essential when predicting how much work can be completed in a given time period: velocity.
Great teams constantly improve the way they work in order to deliver high quality software. This series of blog posts will help you do just that. We'll introduce a set of Key Performance Indicators (KPI) that you can use as a baseline for your continuous improvement efforts. We think that a good indicator is easy to understand, and it should be leading rather than lagging i.e it should predict successful software development.
It is easy to get lost with all the feedback that you are exposed from different stakeholders. There's seems to be no bottom in the "wishing well" for new features. Filling up your backlog is easy, but it won't serve a purpose unless you are also actively refining it.
When it came to our product launch, we had two goals: build brand awareness and generate sales leads. We weren’t too optimistic about actually making a lot of sales at this stage, but we wanted to learn which channels would generate most qualified leads.
Three weeks ago we officially launched our Agile team dashboard on Product Huntafter two years in the making. We knew PH is an active community of early adopters but didn’t have any experience of it and therefore did not really know what to expect.
This post is to share our experiences for those who are in the same situation, with some practical tips on how to make most out of you PH submission.
Now that we’re getting closer to our launch date we’re busy with preparations. For us, that means coding, design work, documentation, and in just getting our processes in place. Of course, everyone wants to make their product launch a success. But how should one prepare for a product launch?
In the software world the term process has a picked up a distinctly negative connotation. So many tedious, bureaucratic and useless activities have been associated with software processes that it has almost become a four letter word.