Skip to content

Companies

How to improve Scrum team performance with Kanban

Xebia Blog - Mon, 05/11/2015 - 22:22
This blogpost has been a collaborative effort between Jeroen Willemsen and Jasper Sonnevelt

In this post we will take a look at a real life example of a Scrum team transitioning to Kanban. We will address a few pitfalls and discuss how to circumvent those. With this we provide additional insights to advance your agile way of working.

The example

At the time we joined this project, three Scrum-teams worked together to develop a large software product. The teams shared a Product Owner (PO) and backlog and just had their MVP released. Now, bug-reports started coming in and the Scrum-teams faced several problems:

  • The developers were making a lot of progress per sprint, so the PO had to put a lot of effort in the backlog to create a sufficiently sized work inventory.New bugs came to light as the product started to become adopted. Filing and fixing these bugs and monitoring the progress was taking a lot of effort from the PO. Solving each bug in the next sprint reduced the team's response time.
  • Prioritizing the bug-fixing and the newly requested features became hard as the PO had to many stakeholders to manage.
  • The Product Owner saw Kanban as a possible solution to these problems. He convinced the team to implement it in an effort to deal with these problems and to provide a better way of working.

The practices that were implemented included:

  • No more sprint replenishment rhythm (planning & backlog refinement);
  • A Work in Progress (WIP) limit.

As a result the backlog quality started to deprecate. Less information was written down about a story and developers did not take the time to ask the right questions towards the PO. The WIP limit maximised the amount of work the team could take on. This made them focus on the current, sometimes unclear and too complex stories. Because of this developers would keep working on their current tasks, making assumptions along the way. These assumptions could sometimes lead to conflicting insights as developers would collaborate on stories, while at the same time being influenced by different stakeholders. This resulted in misalignment.

All of these actions resulted in a lower burn down rate, less predictability and therefore nervous stakeholders. And after a few weeks, the PO decided to stop the migration to Kanban, and go back to Scrum.

However, the latter might not have been necessary for the team to be successful. After all, it is about how you implement Kanban. There were a few key elements missing for instance. In our experience, teams that are successful (would) have also implemented:

  • Forecasting based on historical data and simulations: Scrum teams use Planning Poker and Velocity to make predictions about the amount of work they will be able to do in a sprint. When sprint cadence is let go this will become more difficult. Practices in the Kanban Method tell us that by using historical data in simulations, the same and probably more predictability can be achieved.
  • Policies for prioritizing, WIP monitoring and handover criteria: Kanban demands a very high amount of discipline from all participants. Policies will help here. In the case of this team, it would have benefited greatly from having clear defined policies about priorities and prioritization. For instance: Who can (and is allowed to) prioritize? How can the team see what has most priority? Are there different classes of service we can identify? And how do we treat those? The same holds for WIP-limits and handover criteria. We always use a Definition of Ready and Definition of Done in Scrum teams. Keeping these in a Kanban team is a very good practice.
  • A feedback cycle to review data and process on a regular basis: Where Scrum demands a retrospective after every sprint, Kanban does not explicitly define such a thing. Kanban only dictates that you should implement feedback loops. When an organization starts implementing Kanban it is key that they do review the implementation, data and process at a regular basis. This is crucial during the first weeks: all participants will have to get used to the new way of working. Policies should be reviewed as well, as they might need adjustments to facilitate the team in having an optimized workflow.

The hard thing about Kanban

What most people think and see when talking about Kanban is introducing WIP limits to their board, adding columns (other than To do, In Progress, Done) and stop using sprints. And herein lies one of the problems. For organizations that are used to working with Scrum letting go of sprints is a very unnatural thing to do. It feels like letting go of predictability and regular feedback. And instead of making the organization a bit better people feel like they have just taken a step back.

The hard thing about Kanban is that it doesn't provide you with a clear cut solution to your problems like Scrum does. Kanban is a method that helps you fix the problems in your organization in a way that best fits your context. For instance: it tells you to visualize a lot of things but only provides examples of what you could visualize. Typically teams and organizations visualize their process and work(types).

To summarize:

  • Kanban uses the current process and doesn't enforce a process of it's own. Therefore it demands a higher degree of discipline, both from the team-members and the the rest of the organization. If you are not aware of this the introduction of Kanban will only lead to chaos.
  • Kanban doesn't say anything about (To Do column) replenishment frequency or demo frequency.

Recommendations:

  • Implement forecasting based on historical data and simulations, policies for prioritizing, WIP limits and handover criteria and a feedback cycle to review data and process on a regular basis.
  • Define clear policies about how to collaborate. This will help create transparency and predictability.
  • The Scrum ceremonies happen in a rhythm that is very easy to understand and learn for stakeholders. Keep that mind when designing Kanban policies.

 

Categories: Companies

An Experience That Sticks

Rally Agile Blog - Mon, 05/11/2015 - 15:30

Aha moments. Diverse conversations and insights. Engaging workshops. Extraordinary stories. And most important, action items to take back to your day job.

When people experience something truly unique at an event, it sticks with them.

Our annual RallyON!™ 2015 Agile conference is that kind of event, and it’s happening June 15–17 in Phoenix, Arizona. The full agenda is now live and features more than 60 sessions chock full of good stories, keen observations, best practices, and hands-on activities that align with our seven distinct tracks.

While you can’t possibly attend everything, you can filter the agenda by track to find sessions most relevant and interesting to you. Some suggestions:

Speaking of good stories, our inspiring keynote speakers, including Dan Pink, are sure to get you thinking, laughing, and learning about how to keep up with the new pace of change.

No matter your role, your RallyON 2015 experience will get you fired up to create positive change throughout your organization.

Morgan Campbell
Categories: Companies

Beat the Transformation Odds

If you’re currently considering or have already taken on an organizational transformation, new research from McKinsey provides useful insights to triple your odds of success. Substantial organizational change comes with a chasm of risk; however, McKinsey’s report suggests a repeatable formula to help you cross safely. Following their recommendations can increase your success rate up to 79%, based […]

The post Beat the Transformation Odds appeared first on Blog | LeanKit.

Categories: Companies

Welcome to the New Lean

If you’ve been to business school, or are at all familiar with business history, you’ll know that Lean was a big, big thing in the 1980s and ‘90s. Western manufacturing companies were being decimated by their Japanese rivals, especially Toyota, and they were trying everything they could to regain their competitive edge. Many flavors of […]

The post Welcome to the New Lean appeared first on Blog | LeanKit.

Categories: Companies

Business Flow: Watch the Baton, Not the Runner

Imagine you’re at the Olympic Games, watching the 4x400m relay race. While one runner carries the baton around the track, the other three runners stand around waiting. If we ran the relay race like most of us run our businesses, it would look very different. Each of the idle runners would be running three other […]

The post Business Flow: Watch the Baton, Not the Runner appeared first on Blog | LeanKit.

Categories: Companies

Understanding the 'sender' in segues and use it to pass on data to another view controller

Xebia Blog - Fri, 05/08/2015 - 23:59

One of the downsides of using segues in storyboards is that you often still need to write code to pass on data from the source view controller to the destination view controller. The prepareForSegue(_:sender:) method is the right place to do this. Sometimes you need to manually trigger a segue by calling performSegueWithIdentifier(_:sender:), and it's there you usually know what data you need to pass on. How can we avoid adding extra state variables in our source view controller just for passing on data? A simple trick is to use the sender parameter that both methods have.

The sender parameter is normally used by storyboards to indicate the UI element that triggered the segue, for example an UIButton when pressed or an UITableViewCell that triggers the segue by selecting it. This allows you to determine what triggered the segue in prepareForSegue:sender:, and based on that (and of course the segue identifier) take some actions and configure the destination view controller, or even determine that it shouldn't perform the segue at all by returning false in shouldPerformSegueWithIdentifier(_:sender:).

When it's not possible to trigger the segue from a UI element in the Storyboard, you need to use performSegueWithIdentifier(_:sender:) instead to manually trigger it. This might happen when no direct user interaction should trigger the action of some control that was created in code. Maybe you want to execute some additional logic when pressing a button and after that perform the segue. Whatever the situation is, you can use the sender argument to your benefit. You can pass in whatever you may need in prepareForSegue(_:sender:) or shouldPerformSegueWithIdentifier(_:sender:).

Let's have a look at some examples.

Screen Shot 2015-05-08 at 23.25.37

Here we have two very simple view controllers. The first has three buttons for different colors. When tapping on any of the buttons, the name of the selected color will be put on a label and it will push the second view controller. The pushed view controller will set its background color to the color represented by the tapped button. To do that, we need to pass on a UIColor object to the target view controller.

Even though this could be handled by creating 3 distinct segues from the buttons directly to the destination view controller, we chose to handle the button tap ourselves and the trigger the segue manually.

You might come up with something like the following code to accomplish this:

class ViewController: UIViewController {

    @IBOutlet weak var label: UILabel!

    var tappedColor: UIColor?

    @IBAction func tappedRed(sender: AnyObject) {
        label.text = "Tapped Red"
        tappedColor = UIColor.redColor()
        performSegueWithIdentifier("ShowColor", sender: sender)
    }

    @IBAction func tappedGreen(sender: AnyObject) {
        label.text = "Tapped Green"
        tappedColor = UIColor.greenColor()
        performSegueWithIdentifier("ShowColor", sender: sender)
    }

    @IBAction func tappedBlue(sender: AnyObject) {
        label.text = "Tapped Blue"
        tappedColor = UIColor.blueColor()
        performSegueWithIdentifier("ShowColor", sender: sender)
    }

    override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
        if segue.identifier == "ShowColor" {
            if let colorViewController = segue.destinationViewController as? ColorViewController {
                colorViewController.color = tappedColor
            }
        }
    }

}

class ColorViewController: UIViewController {

    var color: UIColor?

    override func viewDidLoad() {
        super.viewDidLoad()

        view.backgroundColor = color
    }

}

We created a state variable called tappedColor to keep track of the color that needs to be passed on. It is set in each of the action methods before calling performSegueWithIdentifier("ShowColor", sender: sender) and then read again in prepareForSegue(_:sender:) so we can pass it on to the destination view controller.

The action methods will have the tapped UIButtons set as the sender argument, and since that's the actual element that initiated the action, it makes sense to set that as the sender when performing the segue. So that's what we do in the above code. But since we don't actually use the sender when preparing the segue, we might as well pass on the color directly instead. Here is a new version of the ViewController that does exactly that:

class ViewController: UIViewController {

    @IBOutlet weak var label: UILabel!

    @IBAction func tappedRed(sender: AnyObject) {
        label.text = "Tapped Red"
        performSegueWithIdentifier("ShowColor", sender: UIColor.redColor())
    }

    @IBAction func tappedGreen(sender: AnyObject) {
        label.text = "Tapped Green"
        performSegueWithIdentifier("ShowColor", sender: UIColor.greenColor())
    }

    @IBAction func tappedBlue(sender: AnyObject) {
        label.text = "Tapped Blue"
        performSegueWithIdentifier("ShowColor", sender: UIColor.blueColor())
    }

    override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
        if segue.identifier == "ShowColor" {
            if let colorViewController = segue.destinationViewController as? ColorViewController {
                colorViewController.color = sender as? UIColor
            }
        }
    }

}

This allows us to get rid of our extra tappedColor variable.

It might seem to (and perhaps it does) abuse the sender parameter though, so use it with care and only where appropriate. Be aware of the consequences; if some other code or some element in a Storyboard triggers the same segue (i.e. with the same identifier), then the sender might just be an UI element instead of the object you expected, which will lead to unexpected results and perhaps even crashes when you force cast the sender to something it's not.

You can find the sample code in the form of an Xcode project on https://github.com/lammertw/SegueColorSample.

Categories: Companies

CEO Chris Hefley Explains New Logo and Brand

I’m excited to announce LeanKit’s new logo and brand. This marks a significant milestone in our journey, providing an opportunity to reflect on everything that the original LeanKit brand stood for and everything that we aspire to become. Our Journey So Far Since our founding in 2009, LeanKit has experienced tremendous growth. We’ve become a […]

The post CEO Chris Hefley Explains New Logo and Brand appeared first on Blog | LeanKit.

Categories: Companies

Minimal Viable UX

Xebia Blog - Wed, 05/06/2015 - 21:38

An approach to incorporate UX into the LEAN principle.

User Experience is often interpreted as a process where the ‘UX guru’ holds the ultimate truth in designing for an experience. The guru likes to keep control of his design and doesn’t want to feel less valuable when adopting advice from non-designers, where his concern is becoming a pixel pusher.

Adopting UX in a LEAN way, the feedback from team members minimizes the team going down the wrong path. This prevents the guru from perfecting a design where constraints over time will become clearer and less aligned with the customer needs. Interaction with the team speeds up development time by giving early insight.

Design for User Experience

UX has many different definitions, in the end it enables the user to perform a task with the help of an interface. All disciplines in a software development team should be aware of the user they are designing or developing for, starting in Sprint Zero. UX is not about setting up mockups, wireframes, prototypes and providing designs, it has to be part of the team culture where every team member can attribute to. We are trying to solve problems and problems are not being solved with design documentation but solved with efficient, elegant and sophisticated software.

How to get there

Create user awareness

Being aware of the user helps reduce waste and keeps you focused on things you should care about, functionality that adds value in the perception of the customer.

First, use a set of personas, put them on a wall and let your team members align those users with the functionality they are building. Developers can reflect functionality, interaction designers can optimize interface elements and visual designers can align styling with the user.

Second, use a customer journey map. This is a powerful tool. It helps in creating context, gives an overview of the user experience and helps to find gaps.

Prototype quickly

Prototyping becomes easier by the day, thanks to the amount and quality of tools out there. Prototyping can be performed by using paper, mockups (Balsamiq) or a web framework, such as FramerJS. Pick the type you prefer and which is suitable for the situation and has the appropriate depth.

Diagram of the iterative design and critique process. Warfel, Todd Zaki. 2009. Prototyping: A Practitioner’s Guide. New York: Rosenfeld Media.

Use small portions of prototypes and validate those with a minimal set of users. This helps you to deliver faster, therefore again eliminate waste and improves built-in quality. Iterative design helps you to amplify learning. KISS!

Communicate

Involved parties need to be convinced that what you are saying is based on business needs, the product and the people. You need to befriend and understand all involved parties in order to make it work across the board. Besides that, don’t forget your best friends, the users.

If you don't talk to your customers, how will you know how to talk to your customers? - Will Evans

Categories: Companies

Cycle Time report—an example script using Tracker’s API

Pivotal Tracker Blog - Mon, 04/27/2015 - 19:36

Tracker’s API can provide information that’s not currently available through the Tracker web application. Read on to learn how to use the API to compute cycle time.

Cycle time defined for Tracker

Lean software development has given us some useful metrics to help identify problem areas in our development flow. Lead time is the time from when a story is first created to its final acceptance. Mary and Tom Poppendieck call this “Concept to Cash” in their book, Implementing Lean Software Development.

Cycle time measures only the part of lead time from when work actually begins on the story to the final acceptance. Since Tracker’s workflow allows story state to be changed at any time to any state, a story might be rejected and restarted, unstarted and put back in the Icebox, or even changed from accepted to unstarted. Therefore, for Tracker stories, cycle time begins the very first time a story was started, and ends at the last time it was accepted.

IMG_4099

Cycle Time

 

 

 

 

 

 

 

 

It’s helpful to identify stories with a cycle time significantly longer than what’s usual in the project. For example, if a story was delivered and rejected multiple times, it might be a sign that the delivery team and product stakeholders didn’t share the same understanding of how the feature should work at the time the developers started it. If that happens often, the team might try experimenting with techniques to improve shared understanding, such as story mapping.

Another reason for a long cycle time could be that the team was using brand-new technology with a steep learning curve, so it took a long time to finish one or more stories. Once they’ve mastered it, that probably won’t happen again, so there may be no need to try anything different.

Computing cycle time for your project’s stories

Because of Tracker’s built-in flexibility to cycle through different story states multiple times if needed, calculating cycle time for Tracker stories is not straightforward. We’re planning new reports that will show these types of metrics. Until then, you can calculate cycle times for stories in your project using Tracker’s API.

You can check out our example Ruby script from our repository of API examples. The script uses the activity endpoint to retrieve all the activity for the specified project. (Note that only the most recent six months of activity are available, and it’s returned in reverse order, with the most recent activity first.) The response to this endpoint is paginated, so our example shows how to page through all the entries, 100 items at a time. The script loops through all the activity events, looking for story state changes. It stores the earliest started date and latest accepted-at date for each accepted story, using the information returned in the activity resource.

Next, the script uses the API to look up the story name and type of each active story, drops the release-type stories, and then drops all stories that didn’t have at least one started-at and accepted-at time in the last six months. The remaining stories are sorted by cycle time in ascending order, and a report is printed out with the story ID, cycle time, and story name (since story names can be long, we’ve ellipsified anything over 40 characters).

To run the script, set environment variables for your Tracker API TOKEN and PROJECT_ID. Depending on the size of your project, it can take a few minutes to run.

Here are a few pointers to help you use this example:

  • If any stories that were accepted in your project were subsequently deleted or moved to another project, the report will show “deleted” instead of the story name.
  • Since you can currently only retrieve around the last six months of activity, the script can’t calculate cycle time for stories that were started more than six months ago.
  • It is possible in Tracker to put a story directly into a different active state than started (e.g., a story could go directly from the unstarted to the finished state). This script won’t compute cycle times for those, but of course you can write your own script to accommodate those differences.
  • Release-type stories and stories that are not (yet) in the accepted state will not appear on the report.
  • If a story was started more than once, and the first time was before the available activity for the project, the resulting cycle time would be incorrect.

We hope this example will help you use Tracker’s API for your own reports of metrics such as cycle time. For bonus points, update the script to also display the number of times each story was rejected. There’s an example of that in the repository, too.

Please see our API help to learn more about the API.

The post Cycle Time report—an example script using Tracker’s API appeared first on Pivotal Tracker.

Categories: Companies

How to Build a Community of Evangelists for Your Software Product

Pivotal Tracker Blog - Wed, 04/22/2015 - 17:06

We all want customers to crave the products we build. Next, we want them to spread the word, because word-of-mouth (WOM) marketing is the strongest and most authentic for your product.

WOM is a testimonial delivered from one customer to another. The customer spreading the word cares about helping the other person out and is willing to vouch for the product based on benefits they’ve personally experienced.

These days, most customer-to-customer testimonials live on the internet through social media, forums, forwarded emails, and other online communities.

They also live on Product Hunt, TechCrunch’s Best New Startup of 2014.

Product Hunt is an online community where members submit and vote up the best new tech products. A simple upvote arrow is the site’s distilled version of word of mouth, and highly recommended products float to the top of the site and get an influx of visitors. According to TechCrunch, Product Hunt is “taking the industry by storm as founders, investors, early adopters and other tech enthusiasts now check the site on a daily basis.”

Recommendation-driven user acquisitions aren’t the only benefit for products that succeed on Product Hunt; they might also nab press coverage, investor interest, or high-quality feedback from the tech enthusiasts.

When Product Hunt was just getting started, it faced a classic chicken-and-egg problem that typically burdens community-based products. You need users on your home turf to attract other users, but how do you go from zero initial users to 10 or 100?

Product Hunt did a phenomenal job building up a following. The founder, Ryan Hoover, started with a simple email list that grew into a strong community of evangelists eager to use the product every day.

In today’s episode of Femgineer TV, we’ll cover how he did it. Any new startup—even if it’s not social or community based—can use these strategies to drive word-of-mouth recommendations for their product.

I’ve invited Ryan Hoover and his founding team member Erik Torenberg to candidly share how they used evangelists to accelerate Product Hunt’s growth in the early days. They’ll also explain how they continue to build fervor for the product through an engaged and growing community.

Watch the episode to learn:

  • what they did to create a positive first impression of their company on prospective users and influencers
  • how they attracted early adopters even before Product Hunt was built
  • how they mobilized their early adopters to evangelize the product and bring in more users
  • strategies that did and didn’t work to increase community engagement
  • how they keep users hooked and coming back

If you’re struggling to get traction for your software product, watch the episode. You’ll definitely walk away with some valuable insights to apply to your business right away!

Viewer’s Challenge

After you’ve watched the episode, take our challenge. Let us know the following in the comments below:

  • How do you think about your customers’ first-time experience and how do you know whether it’s contributing to customer acquisition and retention?
  • How do you pull your customers back into your product and keep them engaged?
  • If your product has a community, what were some of the key steps you took to build it, and how has it changed over time?

The three best responses will receive a special giveaway from our sponsor Pivotal Tracker and will be showcased in Femgineer’s weekly newsletter!

Submit your responses in the blog comments below by April 22nd at 11:59pm PST.

The next episode of Femgineer TV airs in May. I’ll be hosting Indi Young, the founder of Adapative Path, a user experience consultant, and author of two books: Mental Models and, most recently, Practical Empathy. Subscribe to our YouTube channel to know when it’s out!

The post How to Build a Community of Evangelists for Your Software Product appeared first on Pivotal Tracker.

Categories: Companies

Pulse Roadmap Update

A little madness - Thu, 03/26/2015 - 05:30

Long time users of our Pulse Continuous Integration Server would know that we don’t believe in posting long-term roadmaps. They just never reflect a changing reality! But we have always been happy to discuss features with customers, including keeping our issue tracker (creaky old version of Jira that it is) completely open for all to see and contribute. In that spirit I’d like to talk a little about where we’re heading with Pulse in the near term, the bit that can be predicted, in a format more digestible than disparate issues.

The next version of Pulse (as yet unnamed), will have updates focused on a few areas:

  1. Upgrades of underlying libraries including Equinox, Spring, Spring Security, Hibernate, Jetty, Quartz, EhCache and more. If you haven’t seen a lot of visible changes reported recently this is why: these upgrades have occupied the first part of this development cycle. These are truly the most boring of all changes, which we hope you won’t notice directly at all! What you will notice, though, is a payoff of this strong foundation over time.
  2. Major updates to the administration interface. The interface works well enough at the moment but could be improved in a couple of key areas: discoverability and efficiency. Key goals for these updates include:

    • Improving the visibility of the most commonly-used configuration via overview pages.
    • Making it easier to discover what is overridden (via templating) and where.
    • More efficient navigation, especially through the template hierarchy.
    • Modernisation to take advantage of HTML 5 (which the current interface predates).

    These changes are big enough to warrant a dedicated blog post at a future point.

  3. Improved visibility of the build environment. When builds fail in curious ways the culprit is often a small difference in the environment. Pulse currently publishes environment information via implicit env.txt artifacts, but these haven’t kept up to date with the variety of options Pulse now gives for specifying build properties.
  4. Improvements to the Windows experience. In 2.7 work was done to improve Windows service support, but more could be done to streamline the setup process in particular.

As always we will also be working on dozens of smaller improvements and suggestions from our user base, most of which fall under one of:

  • UI polish, especially in the reporting interface.
  • Increased flexibility of project and build configuration.
  • Updated support for modern versions of build tooling.

Customers are more than welcome to connect with us via our support email, support forum, or issue tracker to discuss these and other changes you’d like to see in Pulse!

Categories: Companies

Android: JUnit XML Reports with Gradle

A little madness - Wed, 03/18/2015 - 08:32

The Android development tools project has seen big changes over the last year. The original Eclipse ADT development environment was superseded late last year by Android Studio — a new IDE based on Intellij. Under the hood Android Studio also uses a new command line build system based on Gradle, replacing the previous Ant-based system. I’ve been keen to find out how these changes impact the integration of Android test reports with continuous integration servers like Pulse.

Summary
  • Android JUnit Report is redundant.
  • Run on-device Android tests with: ./gradlew connectedAndroidTest
  • Collect reports from: app/build/outputs/androidTest-results/connected/*.xml

 

Details

The original Ant-based build system for Android didn’t produce XML test reports for instrumentation tests (i.e. those that run on-device), prompting me to create the Android JUnit Report project. Android JUnit Report produced XML output similar to the Ant JUnit task, making it compatible with most continuous integration servers. The good news is: Android JUnit Report is now redundant. The new Gradle-based build system produces sane XML test reports out of the box. In fact, they’re even more complete than those produced by Android JUnit Report, so should work with even more continuous integration servers.

The only downside is the documentation, which is a little confusing (while there are still documents for the old system about) and not very detailed. With a bit of experimentation and poking around I found how to run on-device (or emulator) tests and where the XML reports were stored. With a default project layout as created by Android Studio:

ASDemo.iml
app/
  app.iml
  build.gradle
  libs/
  proguard-rules.pro
  src/
    androidTest/
    main/
build.gradle
gradle
gradle.properties
gradlew
gradlew.bat
local.properties
settings.gradle

You get a built-in version of Gradle to use for building your project, launched via gradlew. To see available tasks, run:

$ ./gradlew tasks

(This will download a bunch of dependencies when first run.) Amongst plenty of output, take a look at the Verification Tasks section:

Verification tasks
------------------
check - Runs all checks.
connectedAndroidTest - Installs and runs the tests for Debug build on connected devices.
connectedCheck - Runs all device checks on currently connected devices.
deviceCheck - Runs all device checks using Device Providers and Test Servers.
lint - Runs lint on all variants.
lintDebug - Runs lint on the Debug build.
lintRelease - Runs lint on the Release build.
test - Run all unit tests.
testDebug - Run unit tests for the Debug build.
testRelease - Run unit tests for the Release build.

The main testing target test does not run on-device tests, only unit tests that run locally. For on-device tests you use the connectedAndroidTest task. Try it:

$ ./gradlew connectedAndroidTest
...
:app:compileDebugAndroidTestJava
:app:preDexDebugAndroidTest
:app:dexDebugAndroidTest
:app:processDebugAndroidTestJavaRes UP-TO-DATE
:app:packageDebugAndroidTest
:app:assembleDebugAndroidTest
:app:connectedAndroidTest
:app:connectedCheck

BUILD SUCCESSFUL

Total time: 33.372 secs

It’s not obvious, but this produces compatible XML reports under:

app/build/outputs/androidTest-results/connected

with names based on the application module and device. In your continuous integration setup you can just collect all *.xml files in this directory for reporting.

Although the new build system has killed the need for my little Android JUnit Report project, this is a welcome development. Now all Android developers get better test reporting without an external dependency. Perhaps it will even encourage a few more people to use continuous integration servers like Pulse to keep close tabs on their tests!

Categories: Companies

Pulse Pricing Updates

A little madness - Wed, 03/11/2015 - 05:45

To all Pulse customers, existing and potential, a bit of news: we’ve applied some long-overdue changes to pricing. Well, not changes so much as clarification! Since the initial release of Pulse we’ve always favoured an up-front pricing policy. We loathe hidden pricing designed to lure you into a lengthy, pushy sales process. So our sales front page has always included pricing information.

However, the pricing on the page didn’t show the full reality. We had three tiers of pricing for 1, 5 and 15 agents, then the option of license 10 packs on top. In practice customers often asked a few questions:

  1. Can we get a more specific number of agents, e.g. 10?
  2. Can Pulse handle large numbers of agents, well beyond 15?
  3. Do discounts apply as the number of agents continues to grow?

In all cases the answer has been yes. We aim for flexibility, and have allowed anyone that asked to purchase a smaller number of agents at a time. Pulse can certainly handle many more than 15 agents: some customers have hundreds in production and we’ve always offered discounts for high numbers.

Thus it is about time we reflected reality in our published prices. From now on there are no defined agent pack sizes: you start with a single agent license for US$900, then add as many additional agents as you need. Agents are priced on a sliding scale so they become progressively cheaper as your installation grows. You can see this clearly on our updated sales page.

What does this mean for existing customers? As a matter of policy: no existing customer will lose out. If you have a deal better than the new published pricing, that deal remains. This may mean you can get more agents free, or a discounted renewal price next time around. For reference: the original single agent license is now US$50 cheaper, and this will translate to a US$25 discount for our existing Pulse Standard License holders. The pricing for 5, 15 and 25 agents remains identical, so many customers will see no change. Larger licenses will be dealt with individually as they come up for renewal.

We think this new pricing better reflects our aim to be both up front and flexible. If you have any questions, please contact sales.

Categories: Companies

All the small things

Agile Zen - Wed, 12/17/2014 - 20:19

Over the past couple of weeks, we’ve released a few small changes:

1) Links no longer open in the same window.

2) The backlog can now be pinned open. If you click the thumbtack in the backlog, it will stay open until you unpin it for that project.

thumbtack

3) You can now have cards default to the top of a phase instead of the bottom. Your setting will be persisted by project.

add-to-top

Thanks!

Categories: Companies

[Recap] Fast IT: Concepts and Examples from Assembla and Attivio

Assembla Blog - Thu, 07/31/2014 - 22:51

Last week, Sid Probstein, CTO of Attivio, and Andy Singleton, founder of Assembla presented a webinar about “Fast IT,” a new way of managing rapidly changing and Agile projects in areas like mobile, Web, analytics and marketing applications, while working smoothly with reliable core systems ("Core IT"). Andy discussed the dynamics of Fast IT, and Sid presented a case study of how Attivio spun up a major Business Intelligence app in two weeks with two people.

If you missed the webinar, view and download the slides

Want an overview of Fast IT in 60 seconds? Watch the video below:

Get notified about new and exciting content around Fast IT by completing the form below:

//

Categories: Companies

Assembla now allows automatic payments with PayPal

Assembla Blog - Fri, 07/25/2014 - 20:17

Paying for your Assembla subscription with PayPal has never been easier. We recently added the ability to set up recurring payments with PayPal that will automatically pay for your Assembla subscription every billing period, whether that be monthly or annually. Previously, it was a manual process that required logging in and paying every time an invoice was created.

To set up automatic payments with PayPal, visit your billing page > select the PayPal option > and follow the steps.

assembla paypal option1

If you have any questions or issues, please contact Assembla support at support@assembla.com.

Categories: Companies

Post Assembla events to your favorite chat apps: Slack, HipChat, Flowdock & more

Assembla Blog - Wed, 07/16/2014 - 02:26

If your team uses Slack, HipChat, Flowdock, or Bigplans for communication, we have added preconfigured webhooks to make setting up these integrations painless. Once configured, you can selectively manage the Assembla events that are posted out to these apps, such as ticket activity, commits, deploys, etc., to monitor project activity in real-time, inline with other team communication.

To get started, click on the desired integration below: slack logo HipChat Logo flowdock logo Bigplans logo
Categories: Companies

Interested in cryptocurrencies? Get started with 1000 free Ripple XRP

Assembla Blog - Tue, 07/15/2014 - 20:55

ripple logo

Ripple is a protocol for value exchange that makes it easy to transfer and trade fiat currencies, Bitcoin, or XRP - the native asset of the Ripple network.

Assembla is giving away 1000 free XRP (the Ripple native cyptocurrency) to any person with software development skills who is interested in learning about Ripple development. Get it here: https://www.assembla.com/ripple

I called Ripple Labs a few months ago to find out more about ways that their "gateway" can help us pay developers in many different countries. Essentially, we do banking for the developers on our global team. We pay internal accounts, hold the money until they ask for it, and then transfer money to them by bank wire, ATM/Payoneer, or other mechanisms. We have found that the bank wire system is embarrassingly slow and unreliable. This is the problem that Ripple is trying to fix. Their gateway is like a bank in an open-source box. It keeps accounts in any currency, including USD, other currencies, XRP, and Bitcoin. It can transfer those accounts instantly and reliably on the shared "ledger." It is also gaining exciting new features such as "multi-signature" which enables outsourcing and crowdsourcing customers to post a budget amount, and then transfer it to their hard-working suppliers through an arbitrator.

Now I am working more closely with Ripple to help them scale up their development process. I decided to make this free XRP offer for two reasons:

  • Users need 20 XRP to activate a Ripple wallet. We want to remove the hassle from acquiring the XRP so new developers can get started.
  • We want to build an email list of developers that might be interested in working on internal development, bounties, or bank integration projects.
ripple blog CTA
Categories: Companies

Assembla Bigplans Integration How-To

Assembla Blog - Tue, 07/15/2014 - 18:26

If you use Assembla and Bigplans, we have added a pre-configured webhook making it easy to post Assembla events out to your Bigplans chat room. Check out below for configuration instructions.

Bigplans is a simple, integrated way to manage a distributed team.  It includes a "lean" task board, real-time chat, and a unique "advisor" (a real person) that helps you get on-demand resources if you need them.  For programming teams, it includes a tight integration with Assembla login and Assembla tickets. 

You can use the Webhooks tool to feed Assembla events into any of your team chats.  To get started, you will need the Webhook tool installed in the Assembla project you want to configure. If you do not have the Webhook tool installed, visit the Admin tab > Tools section > and click ‘Add’ next to the Webhook tool.

Once installed, click on the Webhook tool in your main navigation and select Bigplans from the list of pre-configured post options:

Bigplans Assembla Webhook

You will need to obtain and update the auth token in the “Content” section.

To obtain your Bigplans auth token:

Visit Bigplans and navigate to the plan you want to post Assembla events to. Click on the ‘Connect’ option in the top bar. Under the “Message API” section, there is a section called “API Token” that will display your token. If no token is set, click on the ‘Reset’ button. Copy the token ID and replace the “BIGPLANS_AUTH_TOKEN” in the Webhook tool.

Bigplans Assembla Webhook Token

Now configure what Assembla events you would like to post to your Bigplans chat room and click ‘Add and Authenticate.” Don’t forget to enable the configuration under the “Title” field.

Your Assembla events will now be posted to the configured Bigplans chat room:

Bigplans Assembla Webhook Chat

If you have any questions or problems during setup, please contact support@assembla.com. If you do not have an Assembla project and would like to test out this integration, try Assembla out for free.

Categories: Companies

Assembla & Slack Integration How-To

Assembla Blog - Tue, 07/15/2014 - 14:23

If you use Assembla and Slack, we have added a pre-configured webhook making it easy to post Assembla events out to your Slack chat room/channel. Check out below for configuration instructions.

To get started, you will need the Webhook tool installed in the Assembla project you want to configure. If you do not have the Webhook tool installed, visit the Admin tab > Tools section > and click ‘Add’ next to the Webhook tool.

Once installed, click on the Webhook tool in your main navigation and select Slack from the list of pre-configured post options:

Slack Assembla Webhook

You will need to setup an incoming webhook service integration within Slack to obtain your token. To do this, visit https://YourSubdomain.slack.com/services/new/incoming-webhook, select the desired channel to post to, and click ‘Add Incoming Webhook.’

describe the image

Once created, copy the provided Webhook URL and update the External URL in Assembla’s Webhook tool.

Now configure what Assembla events you would like to post to your Slack room/channel and click ‘Add and Authenticate.' Don’t forget to enable the configuration under the “Title” field.

Tip: Within the Slack “Incoming Webhook” page that you set up for this integration, you can scroll to the bottom of the page and expand the “Integration Settings” where you can add a label, change the post-to channel, and change the icon and name for your webhook bot.

Your Assembla events will now be posted to the configured Slack room/channel:

describe the image

If you have any questions or problems during setup, please contact support@assembla.com. If you do not have an Assembla project and would like to test out this integration, try Assembla out for free.

Categories: Companies