Skip to content

Companies

Animate constraints with a simple UIView extension in Swift

Xebia Blog - Wed, 04/01/2015 - 23:01

iOS Developers that are getting started with Auto Layout for the first time often run in trouble once they try to animate their views. The solution is quite simple, but in this post I'll create a simple Swift extension that makes it even easier.

When you don't use Auto Layout, you need to make the changes to your UIView frames inside an animations block. Those changes will then be animated. So without knowing any better, you would do the same for your Auto Layout constraints, which means changing the constraint constants inside the animations block. This doesn't work however, and a quick google search on "how to animate constraints" shows that your need only need to call view.layoutIfNeeded within the animations block after you've made the changes to the constraints.

A simple example of this:

heightConstraint.constant = 100
UIView.animateWithDuration(0.5, animations: { [weak self] in
  self?.view.layoutIfNeeded() ?? ()
})

it's necessary to call it this wat since updating constants of constraints doesn't immediately change the frames of the views affected by those constraints. That's why we need to call layoutIfNeeded, to update all the frames of our views.

Since we just want to be always safe with memory management we'll use a weak reference of self within the closure, even though we know the closure is not retained after the animation runs and the view will not be deallocated before the animation finishes (it's good practice to use weak whenever you can to avoid memory related problems).

The above sample is not a lot of code, but each time you want to animate something with constraints you need to write the same thing. Wouldn't it be much easier to write the following instead?

heightConstraint.constant = 100
view.animateConstraintWithDuration()

We can achieve that by adding an extension to UIView:

extension UIView {
  func animateConstraintWithDuration(duration: NSTimeInterval = 0.5) {
    UIView.animateWithDuration(duration, animations: { [weak self] in
      self?.layoutIfNeeded() ?? ()
    })
  }
}

Default values for the method parameters makes this even nicer. Above we used 0.5 as default duration but of course you can fill in duration you want when calling the method. Also we can add parameters with default values for the other parameters that animateWithDuration has.

The final extension
extension UIView {
  func animateConstraintWithDuration(duration: NSTimeInterval = 0.5, delay: NSTimeInterval = 0.0, options: UIViewAnimationOptions = nil, completion: ((Bool) -> Void)? = nil) {
    UIView.animateWithDuration(duration, delay:delay, options:options, animations: { [weak self] in
      self?.layoutIfNeeded() ?? ()
    }, completion: completion)
  }
}

There we have it. An extremely simple extension method that not only saves us a little bit of code each time we need to animate constraints but is also makes the code a lot cleaner since the name of the method clearly indicates what it does, as apposed to the layoutIfNeeded method within an animations block.

Categories: Companies

Rally Customer Perspective: Q/A with Edgar van Zoelen of Philips

Rally Agile Blog - Wed, 04/01/2015 - 18:15

Edgar van Zoelen is leading a large-scale Agile transformation in Philips’ IT organization, which has already resulted in a 60% average improvement in project lead times and successful consolidation of projects that has led to millions of Euros in cost savings.

In just a few years the group has expanded from 7 Scrum teams to more than 120, with approximately 20 Agile release trains under the Scaled Agile Framework® (SAFe®.) Rally has supported Philips' efforts through transformation consulting, services, tool training, and the Rally platform.

Why start an Agile transformation at Philips?

At Philips, innovation is at the heart of what we do. And when you’re pushing forward at such a fast, relentless pace, it’s easy to see where there is drag in the organization. We needed to make improvements in IT delivery — that much was clear. As an organization, we were ready to change. We just didn’t know initially how to change and into what. From that point, it was simply a matter of connecting the dots from an unworkable situation — with more traditional development practices — to Agile, which gives us a more entrepreneurial and future-oriented stance.

How has Agile changed your environment?

Our hard work in the IT organization is paying off. We’re seeing all the textbook Agile improvements: employee engagement, better collaboration, a stronger link between business and IT, and more. When I look around, I see that people are having more fun, taking ownership, and gaining the confidence to challenge their managers. We also have more business stakeholders reaching out to us with positive feedback. For the first time, IT is adding direct value to the business. And we’ve done it at enormous scale, which is a huge achievement.

What’s the secret to a successful Agile transformation?

Consistency and persistence are critical in any Agile transformation. It’s not a one-off project with a defined end date. It requires ongoing, daily efforts to establish the right practices, make improvements, and show that it works. Because at the end of the day, it’s “show me the money.” That’s why I have a team of people who help me move the transformation forward, day in and day out. I call them fanatics because they have the passion and drive to push relentlessly toward business value. That attitude is the key to making a difference.

What was your biggest challenge?

In any transformation, there is always an element of resistance to change. Some people were wary of change in general. They viewed the Agile transformation as just another corporate initiative to endure. Others simply didn’t believe that Agile was the right methodology. We heard people say it was “too fluffy,” that it wasn’t concrete enough and didn’t provide enough security. Overcoming that resistance and building trust within the Philips community was a big challenge — and one of our top priorities as we rolled out Agile practices.

Looking back, is there anything you would have done differently?

True to the Agile philosophy, we’ve had many failures, and there were several things we could have done better. If I knew then what I know now, I would have spent more cycles on convincing people to buy into the transformation and optimizing our approach to coaching. However, every failure gave us an opportunity to learn, and that learning process brought us to where we are today. So in hindsight, I think we forged a very successful path and am proud of our approach.

How has the partnership with Rally helped your group achieve its goals?

On a platform level, Rally helps us standardize the way we measure team performance and align our work to business value. In the past, we struggled with a lack of transparency. Everyone was creating their own reports using custom tools, Excel, Scrum boards, and other methods, so our visibility was very scattered. The Rally solution enabled us to synchronize and start looking at trend lines — how we’re performing, what value we’re delivering, and where we can improve. On a partnership level, Rally brings a lot of insights and expertise from their work with other organizations. This culture of knowledge sharing helps us avoid common pitfalls and get to value sooner. It also means that our experiences at Philips can help other organizations roll out successful Agile transformations. It’s a good ecosystem, and we’re happy to be a part of it.

What philosophy drives your Agile transformation?

“Fail fast” is our mantra. It’s very important for us to make mistakes and keep learning, especially because innovation is at the heart of what we do as a company. However, it can be a difficult philosophy to accept. Most people are conditioned to believe that they should avoid mistakes at all costs. After all, they cost the business time and money. Changing that mindset has been the key to our success at Philips. The faster we fail, the faster we learn — and those insights allow us to move the needle with innovation.

What are the next steps in your journey?

Our next step in IT is to use scaled Agile as a way to organize ourselves. We’ve read the books, we’ve seen the slides, we’ve watched the videos, and we have pockets of excellence throughout the organization, particularly at the team level. We are also starting to work well at the program level, though we still have work to do there. At the same time, we are looking to extend our Agile practices to the level of the portfolio. That’s where senior management sits, so we have the opportunity to really get them on board and show them the value our teams are delivering to their business lines.

Watch the video interview to learn more.

Rally
Categories: Companies

Rally Customer Perspective: Q&A with Edgar van Zoelen of Philips

Rally Agile Blog - Wed, 04/01/2015 - 18:15

Edgar van Zoelen is leading a large-scale Agile transformation in Philips’ IT organization, which has already resulted in a 60% average improvement in project lead times and successful consolidation of projects that has led to millions of Euros in cost savings.

In just a few years the group has expanded from 7 Scrum teams to more than 120, with approximately 20 Agile release trains under the Scaled Agile Framework® (SAFe®.) Rally has supported Philips' efforts through transformation consulting, services, tool training, and the Rally platform.

Why start an Agile transformation at Philips?

At Philips, innovation is at the heart of what we do. And when you’re pushing forward at such a fast, relentless pace, it’s easy to see where there is drag in the organization. We needed to make improvements in IT delivery — that much was clear. As an organization, we were ready to change. We just didn’t know initially how to change and into what. From that point, it was simply a matter of connecting the dots from an unworkable situation — with more traditional development practices — to Agile, which gives us a more entrepreneurial and future-oriented stance.

How has Agile changed your environment?

Our hard work in the IT organization is paying off. We’re seeing all the textbook Agile improvements: employee engagement, better collaboration, a stronger link between business and IT, and more. When I look around, I see that people are having more fun, taking ownership, and gaining the confidence to challenge their managers. We also have more business stakeholders reaching out to us with positive feedback. For the first time, IT is adding direct value to the business. And we’ve done it at enormous scale, which is a huge achievement.

What’s the secret to a successful Agile transformation?

Consistency and persistence are critical in any Agile transformation. It’s not a one-off project with a defined end date. It requires ongoing, daily efforts to establish the right practices, make improvements, and show that it works. Because at the end of the day, it’s “show me the money.” That’s why I have a team of people who help me move the transformation forward, day in and day out. I call them fanatics because they have the passion and drive to push relentlessly toward business value. That attitude is the key to making a difference.

What was your biggest challenge?

In any transformation, there is always an element of resistance to change. Some people were wary of change in general. They viewed the Agile transformation as just another corporate initiative to endure. Others simply didn’t believe that Agile was the right methodology. We heard people say it was “too fluffy,” that it wasn’t concrete enough and didn’t provide enough security. Overcoming that resistance and building trust within the Philips community was a big challenge — and one of our top priorities as we rolled out Agile practices.

Looking back, is there anything you would have done differently?

True to the Agile philosophy, we’ve had many failures, and there were several things we could have done better. If I knew then what I know now, I would have spent more cycles on convincing people to buy into the transformation and optimizing our approach to coaching. However, every failure gave us an opportunity to learn, and that learning process brought us to where we are today. So in hindsight, I think we forged a very successful path and am proud of our approach.

How has the partnership with Rally helped your group achieve its goals?

On a platform level, Rally helps us standardize the way we measure team performance and align our work to business value. In the past, we struggled with a lack of transparency. Everyone was creating their own reports using custom tools, Excel, Scrum boards, and other methods, so our visibility was very scattered. The Rally solution enabled us to synchronize and start looking at trend lines — how we’re performing, what value we’re delivering, and where we can improve. On a partnership level, Rally brings a lot of insights and expertise from their work with other organizations. This culture of knowledge sharing helps us avoid common pitfalls and get to value sooner. It also means that our experiences at Philips can help other organizations roll out successful Agile transformations. It’s a good ecosystem, and we’re happy to be a part of it.

What philosophy drives your Agile transformation?

“Fail fast” is our mantra. It’s very important for us to make mistakes and keep learning, especially because innovation is at the heart of what we do as a company. However, it can be a difficult philosophy to accept. Most people are conditioned to believe that they should avoid mistakes at all costs. After all, they cost the business time and money. Changing that mindset has been the key to our success at Philips. The faster we fail, the faster we learn — and those insights allow us to move the needle with innovation.

What are the next steps in your journey?

Our next step in IT is to use scaled Agile as a way to organize ourselves. We’ve read the books, we’ve seen the slides, we’ve watched the videos, and we have pockets of excellence throughout the organization, particularly at the team level. We are also starting to work well at the program level, though we still have work to do there. At the same time, we are looking to extend our Agile practices to the level of the portfolio. That’s where senior management sits, so we have the opportunity to really get them on board and show them the value our teams are delivering to their business lines.

Watch the video interview to learn more.

Rally
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

We’ve got new (beta) Charts, and we need your feedback

Pivotal Tracker Blog - Wed, 03/25/2015 - 20:27

Tracker has just released its new (but still in beta) Charts to a limited number of customers. If you’re interested in checking out the new Charts for your projects, and are willing to send us feedback to help improve the design, please email our beta support.

1 - Charts location

The new Tracker Charts include:

Improved Velocity (now called “Overview”)

The Overview chart gives you iteration-by-iteration points accepted, along with the running velocity. What’s new is that it now includes an accompanying story type breakdown for each iteration. This gives you a bit more insight into why a particular iteration may have had more (or fewer) points accepted than previous iterations. You can also filter by a particular Epic or label to see how it impacted each iteration’s workload.

image05   image00

 

 

Burndown with integrated scope increase

Our Burndown charts now include historically accurate scope changes, including points added. This means that you can see exactly when scope was added to a particular release, and how it affected the overall timeline.

image02

 

Progress (Burnup) with scope line

Our Burnup charts, called “Progress”, now include an overall scope line to visualize how your accepted points match expectations. You can also view Progress charts for a specific iteration, or for the entire project.

image04

 

Cumulative Flow

Tracker now has a historically accurate Cumulative Flow diagram, which is a frequently requested, robust, and powerful tool. It shows how stories have changed state over time, when more stories were in one particular state relative to others, and when new stories were added.

For a detailed overview of what this chart can do, check out Pawel Brodzinski’s excellent introduction to Cumulative Flow and its uses.

image01

 

Story Type Breakdown

Last, but definitely not least, is our update to the Story Type Breakdown chart. This chart shows you what types of stories (e.g., features, bugs, or chores) were accepted (and added) from one iteration to the next. It helps provide context to iteration progress by showing how many stories of each type were added/accepted.

image06

 

Filter Epics and labels in any chart

Any of the above charts can be filtered by a specific Epic or label. This allows you to visualize how a feature, or a set a features, impacted your overall project cadence and progress.

label filter

 

Now that you have an idea of what the new Charts can offer, have fun with them, and please send us feedback on what you’d like to see (there’s a handy feedback link at the top of the beta Charts panel). Your input is instrumental in improving these charts and future reporting/analytics tools. If you don’t yet have beta access, please email our beta support.

The post We’ve got new (beta) Charts, and we need your feedback appeared first on Pivotal Tracker.

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

Assembla & HipChat Integration How-To

Assembla Blog - Tue, 07/15/2014 - 13:40

If you use Assembla and HipChat, we have added a pre-configured webhook making it easy to post Assembla events out to your HipChat chat room. 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 HipChat from the list of pre-configured post options:

HipChat Assembla Webhook

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

To obtain your HipChat auth token:

You will need to visit https://YourSubdomain.hipchat.com/admin/api and enter your password to access the “API Auth Tokens” page. Under “Create new token” select ‘Notification’ type, provide a label, and click ‘Create.’ Copy the token ID and replace the “HIPCHAT_AUTH_TOKEN” in the Webhook tool.

describe the image

To obtain your HipChat room ID:

Visit https://YourSubdomain.hipchat.com/admin/rooms and click on the desired room you would like to post Assembla events to. Copy the App ID and replace the “HIPCHAT_ROOM_ID” in the Webhook tool.

describe the image

Now configure what Assembla events you would like to post to your HipChat 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 HipChat room:

HipChat Assembla Example 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

[Webinar] "Fast IT": Concepts and Examples from Assembla and Attivio

Assembla Blog - Fri, 07/11/2014 - 17:41

Join us on July 23, 2014 from 11:00 AM - 11:45 AM EDT for a webinar “Fast IT”: Concepts and Examples from Assembla and Attivio.

describe the image

When we at Assembla heard about the 2-2-2 project structure used by Attivio, we knew we had a fun story and a big idea to share.  The fun story is the way that Attivio can spin-up major Business Intelligence apps with 2-day, 2-person prototyping sessions. The big idea is “Fast IT”: a way of managing fast and Agile projects, while working smoothly with your slower, more reliable core systems: "Core IT".

In this Webinar, Sid Probstein, CTO of Attivio, and Andy Singleton, founder of Assembla, will share their discoveries about ways that “Core” and “Fast” can work smoothly together.  We will show tools that help you wrap and index your Core IT so that you can easily use it in Fast IT projects.  And, we’ll show how to professionally launch and manage an expanding portfolio of Fast IT projects for analytics, Web, mobile and marketing applications and SaaS integration. 

This Webinar is designed to help IT professionals or project managers who are handling analytics, Web, mobile, cloud and marketing applications.

describe the image

Presented By:

assembla logo rectangle    Attivio logo

Categories: Companies

Success Story: GLG Boosts “Customer Equity” with Assembla

Assembla Blog - Tue, 06/24/2014 - 17:25
GLG Logo Challenge

Garrigan Lyman Group was worried about losing the loyalty of its own customers. The agency was expanding rapidly and tackling more complex e-commerce, mobile, social media and video projects. Clients had no visibility into when new requests would be delivered. Development managers were having trouble tracking releases and matching resources to requirements. Teams needed a solution to prevent missing deadlines and ensure the quality of delivery.

Objective

Chris “Whitey” Geiser, GLG’s CTO, knew that the agency could not afford to lose “customer equity,” the hard-won confidence that GLG could deliver innovative digital marketing solutions. So he and his team began looking for technologies that could help them centralize processes, manage development requests, and improve communications with clients.

Results

Assembla has helped Garrigan Lyman Group win new business from existing clients. The solution has helped GLG evolve from helping clients with flashy but self-contained marketing projects, to solutions that work with the core of their businesses. It allows the company to collaborate better with clients and improve control of their development processes.

To see how GLG learned to work more closely with its customers,
fill out the form below to download the full case study.

//

Categories: Companies

Episode #138 – Principles or Practices

Integrum - Agile Weekly Podcast - Thu, 06/05/2014 - 15:00

Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Roy van de Water discuss:

  • What is more important, principles or practices?
Email
Categories: Companies

Episode #137 – Central Control

Integrum - Agile Weekly Podcast - Thu, 05/08/2014 - 15:00

Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Roy van de Water discuss:

  • What happens when someone has central control

Transcript

Derek Neighbors:  Hello, and welcome to another episode of Agile Weekly Podcast. I’m Derek Neighbors.

Roy van de Water:  I’m Roy van de Water.

Jade Meskill:  I’m Jade Meskill

Clayton Lengel‑Zigich:  I’m Clayton Lengel‑Zigich

Derek:  We’ve got another fantastic, hypothetical situation.

[laughter]

Derek:  You may spot this in the wild, I don’t know. We’re talking about things that could potentially maybe happen, someday, to some teams.

Say you had a czar of a department, or a unit, or a job function.

Roy:  Like a real Russian Tsar?

Derek:  Yeah, like an architect…

[laughter]

Jade:  I’m a Marxist, sorry.

Derek:  In the hypothetical situation, we would probably see this as being an architect, or maybe be a designer of some kind. When I say designer, I mean the chief of the companies, the [inaudible 00:55] top guy.

Jade:  Or the head programmer?

Derek:  The head jock honcho.

Jade:  On the team, the technical lead or something?

Derek:  Not even that. Above the technical lead, the top of the food chain. They have this stance that says, “The only thing that can done can only go to production if I have approved it.”

Roy:  You’re saying everything has to go through this guy?

Derek:  Everything has to go through this gal. She is totally 100 percent, “The design, every pixel has to be done by me,” or “Every single method has to be approved by me if we’re writing code.”

This person works in a large organization, thousands of people per se, and lo and behold, they can’t go to every planning meeting.

The good news is they have some mini‑czars that they can send out to these planning meetings. They can go to these planning meetings, and help the developers and the designers do things.

Then what happens is all sorts of decisions happen in a planning meeting. When these mini‑czars come back to the big honcho, the big honcho says, “Nope, I don’t like it. It needs to be this way.” Now they go back to the team and have to tell the team, “Sorry.’”

[crosstalk]

Derek:  …What does that look like? What happens? How do you fix that? How do you rectify that situation? What are the downsides to that stuff?

Roy:  First off, is there anything wrong with that?

Clayton:  Yeah, I’ll take the devil’s advocate approach. The reason that all the design has to go through that one person is because if you want to maintain a consistent brand experience for the end‑user, you can’t just let people ‑‑ especially developers who don’t have any design sense ‑‑ to go off and do a bunch of crazy stuff.

Roy:  There’s a bunch of awesome examples where I’ve seen exactly that with Google. In fact, I’ve heard, Derek, you complained about this specifically that Google has all of these products out there of totally different experiences, that are totally not integrating because they’re all being developed in isolation.

Derek:  Ever since their designs are [inaudible 02:56] left…

[laughter]

Derek:  They have not been on‑brand.

Jade:  I’ve seen these on the development side, too, where you’ve got all these dumb programmers that we hired that are up there writing a bunch of crap. If they could just do it like me, everything would be so much better.

Derek:  Yeah, where do you think our tech‑level of that comes from?

Jade:  Yeah. [laughs]

Clayton:  I suppose we pay these people six figure to be morons.

Derek:  The dumbest, highest paid people, we have.

[laughter]

Roy:  I get that. The guy at the top, his neck is on the line if should go south, he wants to make sure that everything goes north. Right?

Derek:  Yeah, it’s pretty scalable, they are able to ship a lot of production software this way.

Clayton:  That’s a trade‑off. If you go through this bottleneck where one person has to approve everything, obviously everything goes very slowly, and you don’t ship very often.

Jade:  And you redo a lot.

Clayton:  Yeah, you probably use a lot of rework, as obviously the market’s going to change, and you’re going to have to go back and fix things and change your strategy. But theoretically, everything looks pretty good, and it’s pretty close to being “perfect” when it does ship.

Roy:  I guess that depends on their value system then. Do you value the ability to move fast, to make changes and respond to changing requirements in the changing world? Or do you prefer to have a perfect experience? Because I could see value in both of those.

Derek:  Yeah, if a lot of people really applaud Apple and Steve Jobs and what he did ‑‑ he certainly was not interested in shipping on a very tight schedule and going very fast. He was much more concerned about shipping perfect products than he was shipping bad products more frequently.

Roy:  Right. Another example is like Rolls‑Royce or something, where, I don’t care if it has the latest and greatest features, but…Hold on, let’s be clear here. I’m not buying a Rolls‑Royce.

[laughter]

Roy:  I could see people don’t really care about [inaudible 04:46] features, they care about every product being extremely high quality. I don’t know if they actually have this, but I could see them having a philosophy like the CEO hand‑checks every single car before it leaves the factory, because they insist on having that premium experience, and that everything is perfect.

Jade:  Apple’s an interesting case, because they’ve shipped a lot of great hardware. They shipped a lot of really poor software that is not consistent and not very good.

Derek:  You’ve obviously used their online store before.

Jade:  [laughs] Yeah.

Clayton:  I’ve always had a tough time with the Apple comparison. I think that’s the first one that people jump to, but no one ever really acknowledges the difference in hardware.

Jade:  It’s much harder to fix hardware once it’s gone up the book.

Clayton:  Yeah, so that’s different. That’s something that we should clarify.

Derek:  When I look at this hypothetical situation, the thing that I think is the biggest pain for me or the biggest thing that I see that people aren’t talking about, is what does it feel like being a team member who goes through a planning meeting with a group of people and comes up with a solution and an idea only to, an hour later or a day later or two days later, say, “Uhh, what you’re doing is really stupid and really dumb. This is the right way to do it. Throw away everything you’ve done and go do this other thing instead.”

What does that feel like as a team member, do you think?

Roy:  I can see two parts to that. First off, we talked a lot about autonomous teams. I would feel like, as a team member, a large part of your autonomy gets taken away if someone comes back and says, “You have to do it my way.”

If it’s taken from the standpoint of, “Hey, have you considered using other options”? And they are truly better ideas. If you follow the core commitments and you choose to always seek to better an idea and to accept any idea no matter where it comes from, then that sounds like it would only be a positive experience.

I think that how that interaction takes place, and the attitude of both parties, has a huge impact on how that’s going to go down.

Clayton:  I would feel pretty useless and like my time was being wasted. I would probably not even bother attending. Or if I did attend, it would just be for show. I would probably not even be paying attention because, really, what difference does it make?

Roy:  But there is a difference. Clayton, if I came to you. Let’s say you plan on a Monday and I come to you on a Wednesday. I say, “Hey, I saw what you guys planned out on Monday. Have you considered using other possibilities”? Would you have that same reaction?

Clayton:  If you said, “Had you considered these other possibilities”? We had some dialog, and I said, “OK, let’s talk about it next Monday.” I think that would be one thing. If you said, “Put the brakes on. Really think hard about these other choices, because you’re doing them no matter what.” Then I would feel like, “What’s the point. Why did I waste that time”?

Jade:  I can tell you what it’s like to be on the other side of that. I’ve been that person. It sucks. You can’t trust anybody. You are paranoid and you need to be…

Roy:  Just to be clear, what side are you talking about?

Jade:  The person who’s the bottleneck. Who…

Roy:  Oh, I see.

Jade:  …is changing things for everybody.

Roy:  And insisting that your rules be followed?

Jade:  Yeah. It’s a very crappy position to be in. You don’t sleep well. You’re not relaxed. You’re always stressed out because everything is going wrong around you all the time. You don’t trust anybody. I think that’s really where…that’s the core of the issue. You don’t trust anybody.

Derek:  In this particular hypothetical, there’s also a middle person. We’ve not talked about that middle person. Not only is the person that is doing the work probably leaving frustrated…

Roy:  So you’re talking about the Vice Czar in this, right?

Derek:  The Vice Czar goes into this thing thinking, “Oh, I totally represent the attitudes and the patterns and the thinking of my boss.” We go in and I walk out thinking, “Man, this is all going to be really good.” Then I go back and they say, “Why did you make this decision? You’re letting them do that? I can’t believe that”!

Now, not only do I have to feel like maybe my boss doesn’t trust me, but now I have to go deliver that news to a whole group of people to say, “Hey guys, even though I said that this was probably the right thing to do, as it turns out, the Grand Czar does not agree with me.”

What does that got to feel like?

Clayton:  You lose face with the other people. I know that I told you that it was good, or that we agreed that it was good, but it turns out that it’s not. So either I can play that off as, “The czar guy is a real jerk. Man, what an asshole! I hate that guy too.” Or you would have to just hope that people aren’t thinking, “This person is really stupid. They don’t understand what their boss wants. Man, I’m not going to bother asking their opinion anymore.”

Roy:  Right. Even the boss is probably getting frustrated with them. They’re coming back with ideas representing the team. It’s probably not what the boss wants in the first place. They’re never going to think the same way. So this person is probably just getting shit on from both sides.

Derek:  So we’ve got the hypothetical. We’ve got some of maybe how it feels to be all of the roles in the hypothetical. How would you go about fixing it?

Roy:  In my opinion, if you can figure out some way to have the team earn the Czar’s trust and rid the organization of the Czar, not rid of the person but rid of the role, I think that will go a long way. Somebody who is insistent on all of these best practices, good coding styles, good design, or whatever, they should be going out and championing all of those things and explaining why it’s so important and really convincing people and winning them over rather than telling them what to do.

Jade:  A lot of times they do have a lot of really great knowledge and sometimes even some special insight that other people don’t have, but you’re right.

They should be going out and helping those other people to gain that skill and also experience things from the other side of the fence.

The things that are changing during planning or the real complexities on the ground of dealing with this on the fly, those type of things so that there is some empathy for what the people are going through while they’re out dealing with these situations.

But again, it comes back to building trust with those people. You believe that they’re doing the best thing that they can.

Roy:  It gets tough though when you set up a system like that in which you’re like, “I’m the one who is going to decide on the design, so Clayton don’t even bother wasting time coming up with designs or whatever.”

“Don’t even bother coming up with the method definitions because I’m going to shoot it down and give my own implementation anyway.”

Now all of a sudden Clayton hates me, and it’s going to be really difficult for Clayton to earn my trust because he is going to be trying to get away as much as he can to please the people that are breathing down his neck without getting my ire.

He is going to be subverting me, which is going to cause me to trust him even less like that’s just going to be a feedback loop.

Clayton:  There are definitely cases where people get in this situation like what Jade described like no trust and I don’t think most people would want to be in that, but there are some people who do enjoy the aspect of controlling everything.

They want to be the hero and they want to be seen as the smartest guy in the room and all that stuff.

I would say that probably is a pretty big component in a lot of these cases compared to the person who really doesn’t want it to be that way all the time, but it’s just like, “Oh, woe is me,” it just happened to be that way.

There is some aspect to that. I think unwinding some of that desire for control where they don’t feel like all of their self‑worth at their job is based on whether or not they got all the answers right all the time. I think that could go a long way.

Derek:  When I look at it, Steve Jobs might be a good example. I didn’t know Steve and I certainly didn’t see him work, but I would…

Roy:  Me and old buddy Steve, yeah.

Derek:  I think that if I were to…

Roy:  I call him Steve.

Derek:  …guess how he operated, he trusted his people. Because I don’t think he could get the results he got without trusting them. What he wanted to control was the essence of the spirit of the products that were put out.

Not necessarily how they were built and so to me the difference is you come back from a planning meeting and I say, “Oh my God, you’re doing all the stuff wrong and this is how you should have done it.” I don’t think that’s how Steve operated.

He probably operated in a “I’m going to let you do whatever and when you show it to me, if it’s crap, I’m going to say it’s crap, but I’m not going to ship that and fuck you go do it right, and when you get it right, we will ship it. Until then, leave me alone, don’t waste my time.”

“Why did you call me to this fucking demo that sucks this bad”? What I think is very, very different than saying, “I’m going to tell you exactly how to do every little thing.”

I might tell you at the demo to say like “I’m not doing that and I had expected this.” And I think that’s a subtle difference, but that’s very different than trying to control how everybody does their job.

Instead of saying here’s the bar of expectation and I’m going to make you live up to that, I’m not going to tell you how to live up to it.

Jade:  I think that’s right.

Derek:  How do you get somebody to get to the point where they’re allowed to let the essence of what their standard is hold but not have total mistrust.

Jade:  I think there are some systemic problems in that as well that that person is probably being held accountable for those decisions by their people.

Getting some understanding put in place there is a big help. To help their boss see that like they don’t need to be held to that.

They need to be held to the standard of they’re making everyone around them better and helping them achieve that essence and not being a control freak.

Because usually it’s people that don’t want to do that. They end up in that situation because of some externality.

Derek:  Right, fear usually, they’re afraid of something.

Roy:  I wonder if people that are successful at it and managed to climb their way to the top might not be the ones that enjoy it though.

Jade:  There are people that enjoy having that control like Clayton said, and those people might not be able to help them.

Derek:  All right. See you next month.

[music]

Announcer:  Is there’s something you’d like to hear in a future episode? Head over to integrumtech.com/podcast, where you can suggest a topic or a guest.

Looking for an easy way to stay up‑to‑date with the latest news, techniques, and events in the Agile community? Sign up today at AgileWeekley.com. It’s the best Agile content, delivered weekly for free.

The Agile Weekly Podcast is brought to you by Integrum Technologies, and recorded at Gangplank Studios in Chandler, Arizona. For old episodes, check out integrumtech.com, or subscribe on iTunes.

Need help with your Agile transition? Have a question and need to phone a friend? Try calling the Agile Hotline. It’s free. Call 866‑244‑8656.

Email
Categories: Companies

Episode #136 – Simple

Integrum - Agile Weekly Podcast - Thu, 05/01/2014 - 15:00

Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Roy van de Water discuss:

  • Simplicity

Transcript

[laughter]

Clayton Lengel‑Zigich:  It is hard doing that every week.

[laughter]

Derek Neighbors:  You don’t do it quite as good as Jade does.

Jade Meskill:  All right, go Roy.

Roy van de Water:  Hello and welcome to another episode of the Agile Weekly Monthly Podcast. I’m Roy van de Water.

Jade:  I’m Jade Meskill.

Clayton:  I’m Clayton Lengel‑Zigich.

Derek:  I’m Derek Neighbors and joining us today is the improv group.

Roy:  In the room next door.

[laughter]

Jade:  Yelling very loudly.

Roy:  Today we are talking about thinking simply, instead of thinking complexly. Jade, you and I have been…

Jade:  Accused of being simple?

Roy:  Accused of being simple.

[laughter]

Roy:  Can you tell me a little about what that idea means?

Jade:  Sure. We’ve been trying to…

[shouting in background]

Jade:  These guys are really… [laughs] yelling in there.

[laughter]

Roy:  I’d like to denote that they were entirely quite for the last 45 minutes before we walked into this studio.

Derek:  It’s like they’re Chicago trading for [indecipherable 1:10] .

[laughter]

Jade:  Buy! Buy! Sell! Sell! [laughs]

Derek:  You do the savings, I’ll do it.

[laughter]

Jade:  We’ve been working on some concepts of trying to write very, very small, simple applications, taking the UNIX philosophy and applying it to web applications to avoid the over‑complication that tends to arise in larger systems.

Roy:  What does an over‑complication look like?

Jade:  Usually a system where the responsibility is not very well delineated between either modules or different parts of the application. It tends to be very messy and sloppy, where it’s hard to tell where something…There’s no discrete functionality, I guess is the best way to say it.

Derek:  The way that I think about it is, if you had a web application where the code that displays the page where you enter in the details about a job is in the same place as the code that makes the…Say the job in a database in the same place in the code that schedules the job, in the same place in the code that runs the schedule of job, in the same place in the code that…They’re all in the same place.

Roy:  It sounds like everything is in the same place, it sounds pretty simple to me.

[laughter]

Derek:  Right, until you get everything in the same place, and then something goes wrong, or you want to change something. We have this problem with the Agile Weekly podcast or Agile Weekly website, where we had a bunch of things that were all clinched together.

If I took the approach of a normal, say, Rails application, like the standard Rails way of doing things. When certain pieces of the system got a little too big, or too unwieldy, it was hard to…it seemed like it was simple because it was all in the same place, but the real simplicity came when we broke those out into little pieces.

Then you have these…you’re going back to [indecipherable 3:08] sampler, mentioning the UNIX philosophy, with these little teeny pieces that all did their one little thing really well. They all just worked together.

Roy:  So why wasn’t it obvious to be that way in the first place?

Jade:  Because in the beginning that would have actually been more complex.

Roy:  So how do you know when you are doing something complexly instead of simply?

Jade:  I think when it becomes hard to explain, it’s probably too complicated.

Roy:  Is that like the metaphor ideal, like you should be able to describe whatever you’re building as a metaphor, and as soon as your metaphor circuit is breaking down that means that you’re putting too much in there? Is that…

Jade:  I think that’s a good way of putting it. If it’s not something that you can explain in a simple, conceptual way, it’s probably gotten a little bit out of control.

Roy:  Is this idea of complexity versus simplicity something that is on the overall project, or is it something that you see replicating down to the individual components of a method, or a class, or something like that?

Jade:  It’s an important recursive idea that happens. If you are being simple with the very small parts of your system, it’s easier to be simple at the larger scale as well.

Derek:  I think developers in general…they find it easier to think in these terms when they’re maybe down in the class with the [indecipherable 4:31] methods. I think that’s where they live, and all that stuff. Then you go up a few levels and even talking about what features you’re delivering.

I think a lot of developers might understand that concept at that level, but then it gets in the features and it’s like, “Well, the product guy said just build this stuff, and like well, OK, whatever, I don’t care.” Where I think that’s the even more important part, that’s an equally important part to be having this discussion about simple…

The planning meetings that we’ve been involved in lately for sure. I think we’re constantly driving towards trying to find something that’s simple, but not too simple, or not too simplistic. That’s a really hard thing to do.

Jade:  Yeah, I think being simple is hard.

Roy:  So this is the type of thing that I might solve using design patterns, like, “Can I just throw those at this problem?”

[laughter]

Jade:  We have an observer. Let’s find out…

[crosstalk]

Clayton:  I think the interesting thing to me, it’s always easier to add complexity that it is to remove complexity. When you start to get that Zen peace, it’s way easier to say, “Let’s start super simple and we can add what we need to add,” which is a very hard discipline to build.

Even if you’re talking product. That struck it for me. Can’t say how many times you’re talking about a feature and you’re up there at a whiteboard drawing it out, and somebody’s like, “Well that’s just too simple.”

At the end of the day, if you give this to the developers, it might turn into a two‑week feature request even though it sounds so simple right now, on the surface. As human beings we like to overcomplicate everything all the time.

Roy:  What drives that, though? Why do we want to overcomplicate things?

Clayton:  Some of it is uncertainty, or, we have this need for completeness. If we only say we’re going to show X, it’s like, “Yeah, but Y and Z and A and B are all available to us, too. We have to show them.”

“Why? What if we just showed X? What if X is enough? That is all that feature needs, why do we need the…”

“Because those other things exist, so we have to show them.” There’s very much this, because we can, we should, mentality.

Derek:  Another thing we see in our work is that people have an aversion or misunderstanding of iterative development. It’s like, if we don’t do this now, we’re…

Jade:  You mean incremental development?

Derek:  Yeah. If we don’t do this now, we’re never going to do it. If you guys don’t plan every single thing that we think we know, then we’re totally screwed. You guys are going to forget it.

To be fair, I bet you there’s a lot of product people out there who have teams that maybe aren’t the most reliable and don’t deliver what they say they’re going to deliver, and all those things.

When someone were to come in and say, “Hey, we’re going to do some really simple thing and ship it real soon,” it’s like, “Yeah…I don’t believe you.” Like, I’m not going to take that risk.

Clayton:  To me, it sounds like there’s a little bit of the 85‑15 rule, where you can deliver 85 percent of the value with 15 percent of the effort. Then you spend the other 85 percent of your time delivering the last 15 percent of the value.

I have worked with different product people, designers and architects in the past, where they want to get all 100 percent, because they know that if you spend 15 percent of the effort now to deliver 85 percent of the value, you’re never going to spend the other 85 percent to deliver the last 15 percent.

Which may be a really awesome business decision, but you’ll never be 100 percent as good as it could be.

Roy:  Some of it is, building off Clayton’s response there, is, there are a lot of teams where if you say, “OK, fine, let’s just do X.”

You say, “OK, let’s do Y.” “OK, let’s do Z.” Then you say, “OK, let’s do A.”

Then they’re like, “We’re going to have to re‑evaluate the whole thing. If you would have told us up front that we had to do A, we would have totally built this in a different way. Now that you want A, we just have to throw away the last six months’ worth of work, and start all over, and if only you would’ve told us.”

Once they get trained for that it becomes, if I know anything I must disclose it now and tell you that you have to build it into the app, because if I disclose it later you may come back and tell me, “Oh man, we have to throw everything out and start again.”

Clayton:  By disclosing everything up front and insisting that it all gets done, the product owner is really trying to maximize his choice later on down the road. His ability to choose later on.

Roy:  They’re trying to mitigate their risk, I believe. If they disclose all that and say we need to do all of that, then they think they’re mitigating the risk of somebody coming back later and saying, “Oh, we can’t do that because you didn’t tell us.”

In reality, what they do is increase their risk exponentially, because they make it so it becomes almost impossible to deliver what they’re asking for.

Jade:  The cognitive load becomes much more to deal with and “grok” all of those additional features when they’re not needed.

Derek:  It sounds to me like then you’re going to try to build a system that’s overly architected just in case you have to build any of the number of features you’re told you have to support.

Roy:  One thing recently that clarified this a bit more for me was that we had a situation where we wanted to deliver some features that would have been nice to have a database.

Having a database was a non‑trivial thing, so we used the file‑system. We had a table with a row and a column in it. That’s all there was.

Derek:  A folder with files in it?

Roy:  Yeah. We had a folder with files. That was sufficiently complex for what we wanted to do. I think some people hear that, and they think, “What are you, f‑ing crazy? You can’t use the file‑system…”

[laughter]

Roy:  “…Use a database, that’s crazy.” What we understood was, right now, for what we’re trying to do, for this little slice, that’s what we need right now. We acknowledged that that is not a long‑term solution, but it’s going to be as long‑term as it needs to be for what we want to do with it.

Jade:  It was very simple to replace.

Roy:  Exactly.

Derek:  I think where this started to come and play for me was when we started to cross the chasm, so to speak, in doing a lot more mobile development.

So things that we thought were pretty trick and pretty sleek and pretty simple and pretty small started to fall down really quick when a customer would say, “hey by the way, I need an android version or an iPhone version of this.” and I was like, “oh shit, like dude like how in the, man!”

And so when it got to the point like “OK, let’s make everything like API and we’ll have the front end consumed of the web version consume that API and hey now we can have the iPhone version.”

Jade:  Anything can use this API

Derek:  API right like it started to like I think click a little bit more just even in that that you could kind of separate this concerns a little bit better.

Then you can start to say “OK how about make perhaps even smaller and smaller,” and keep slicing those so that they are easier and easier to replace, so when you do find something new you might not have to rewrite the whole system to do something. You might be able to rewrite a little piece of the system to do something which is a lot less risk and a lot easier to do.

Jade:  That’s kind of where [indecipherable 11:27] and I got into writing these micro‑applications that had very discreet functionality.

We were having trouble, even with that simplified view of things of just having an API and a web service that was still wasn’t good enough. There was still too much co‑mingling of functionality between different classes and you know, the abstractions were good enough.

We took a crazy stance and tried to work on like how can we build the smallest possible thing to do this one job, and then chain all of those things together as needed?

Roy:  I felt like that worked for those instances I am curious to try more places and see how well it runs across the board.

In that case it was a project that only ended up being a collection of five or six of these smaller apps, but when you start to build a more complex user experience where you have a whole store form or something where the user [indecipherable 12:24] component you try to keep all of those pieces separate. I wonder how well that’s going to play together.

Clayton:  I feel pretty confident in it from the next example like; pick any five UNIX commands. It could probably do a bunch of stuff. If you chose wisely.

Derek:  Yeah, It does fall down at certain point though. What I mean by that is, there’s a whole lot of things people do, they don’t do with Unix commands any more. You could use “set OK” and “grip” to do a whole lot of things.

Jade:  Everything

Derrck:  But you probably open up “vi” or “sublime” to do it instead because the interface is easier even though its [indecipherable 13:00] all mashed into an application than a whole lot more than those simple things.

I think there are this kind of. It is nice to assemble them small‑ly. Into small little apps that interact but when you have to chain too many interactions together, the complexity of remembering what and how to chain things starts to become cumbersome.

Clayton:  That and when there’s like a whole bunch of apps that you don’t even know existed.

Roy:  Yeah

Clayton:  So you start rewriting them yourself

Derek:  Yeah. What tends to happen is when you have things that have common things you start to see those assembled into other apps.

I would say that OK and grip get used within most editors the developers use today. Because they make sense to kind of bundle natively into an editor rather than a drop out to a shell and do them. I think the work that those things did and put in place are straight up stolen and re‑used inside of those editors.

Jade:  It’s like when we talked about, we built a simple app but at some point it became too complicated. It was simpler to take a different approach of writing smaller, more complicated apps. Think this is the contrary example of at some point that becomes absurd. The interactions are too complicated.

Derek:  Right.

Jade:  Now you find a simpler way to merge those things together.

Derek:  It goes back to; it’s always easier to get more complex.

If we’ve got the set the OK, the grip, and we need to put them all together like we know those things really well now and so we know how to assemble them into an interface or into certain things a lot better than if we would have tried to build those things as part of the bigger complicated thing to start with.

Jade:  I think that’s where some of the ideas around, like hexagonal design can come into play. Where you’re composing complex systems out of simpler modules and simpler pieces.

Clayton:  We’ve been talking a lot about in terms of software, but this same stuff applies to process things.

You can take the components and do them very well and you can build some sort of process that works and maybe it gets too big sometimes or maybe you decompose or whatever, but it’s not just whole scale, you know.

From a coding example, jumping straight into some massive java architecture thing and that’s the same thing as like what you’re going to get on the juror train and see if this mother app…

[laughter]

Clayton:  …Or it’s like trying to get a good user story. I am like “let’s try and get good at talking to each other as a team first.”

Derek:  Let’s get good at working together.

Jade:  Yeah, let’s try those things first and then you know, you can juror me to death.

Roy:  Hey I will see you next month

[music]

Presenter 1:  Is there something you would like to hear in the future episodes, head over to inagram.com/podcasts or you can suggest a topic or guest.

Presenter 2:  Looking for an easy way to stay up to date with the latest news, techniques and events in the agile community? Sign up today at agileweekly.com. It’s the best agile‑content delivered weekly for free.

The agile weekly podcast is brought to you by inagram technologies and recorded in gangplank studios in Chandler, Arizona.

For old episodes check out inagramtech.com or subscribe on iTunes.

Presenter 3:  Need help with your agile transition? Have a question and need to phone a friend? Try calling the agile hotline. It’s free, call 866‑2448656.

Email
Categories: Companies