Current Articles | RSS Feed RSS Feed

Join the Continuous Revolution

Posted by Andy Singleton on Wed, Aug 21, 2013
  
  

We launched Assembla to work with distributed teams, and this required a new kind of agile dev process. Scrum with its stuffy meetings clearly did not fit the teams we work with. Cloud-based teams need to work differently.  We want to:

  • Release more frequently
  • Respond faster to users and customers
  • Scale to larger projects and teams
  • Manage distributed teams and tap global sources of talent
  • Compete better, especially with fast-cycle SaaS, Web, mobile, and big data projects
  • Reduce or eliminate the stress surrounding fixes and releases

The winner in this voyage of discovery is continuous planning and continuous delivery. The pace of competition on the Internet is so fast that all of the winners will eventually need to go continuous. In recent months we have talked to many companies that want to release more frequently, or continuously.

Continuous Agile combines traditional Kanban and Lean task management with recent innovations in Continuous Delivery.  It is is compatible with existing Scrum teams, but also works for modern, cloud-based teams and leading edge online services.

Our Continuous Agile initiative gathers together ideas, tools, and services to help you (and us) release more frequently and innovate faster. 

Ideas: Unblock! A Guide to the New Continuous Agile

Please check out an early draft of the ebook. We use this material to answer real questions from teams that are trying to release more frequently. We update it as we find new questions and ideas. You will find a VARIETY of approaches that you can use. We started building a guide that would cover basic task management, code contribution, and testing, so you would have a practical guide to the previously mysterious art of releasing every change. As we got into it, we found that some of the most interesting discoveries were around product management, which is the true route to success.

Co-authors contributed valuable knowledge. Michael Chletsos, Assembla CTO, contributed the big idea of “distributed” versus “centralized” flavors of CD.  He also put together the detailed workflows that allow us to release 250 times per month. Luca Milanesio sends us his innovations for building mobile apps. Damon Poole, now Chief Agilist at Eliassen and formerly the founder of Accurev, introduced me to Kanban and continuous release ideas three years ago, and is now figuring out how to apply them in large enterprises.

We’re moving some Continuous Agile ideas to AndySingleton.com. We will expand our coverage of the big picture with more contributors and partners. Blog.assembla.com will be more focused on the product with “what’s new” and “how to get more out of it” for users. So, add your bookmarks.

Tools: The Assembla Renzoku Release

The Renzoku package helps you plan, code, and release changes with one-piece-flow. It includes planning, Kanban view, code contribution, code review, and reporting. All of these activities are linked together on a ticket with a complete discussion and activity stream. Here’s an expanding list of relevant blog articles that describe the features. Please write in if you have questions about how to set up a continuous process.

Services: Hands-on Help

We’re expanding our “Release More Frequently” workshops, where we introduce your team to Continuous Agile, and help them figure out how to release more frequently.

Learn more at ContinuousAgile.com, and check back soon on this blog for announcements of public workshops online and in Boston.

0 Comments Click here to read comments

"No Scrum" T-shirts for our visit to Agile 2013

Posted by Andy Singleton on Wed, Jul 31, 2013
  
  
Tags: ,

We printed up some "No Scrum" T-shirts for the Agile 2013 Conference.  The conference is mostly attended by Scrum coaches, so this should be a good conversation starter.  The back side promotes "Continuous Agile and Beyond Scrum Roadmap."  See you there.

IMG 1812 resized 600

1 Comments Click here to read comments

Post-it Notes Are an Instrument of Oppression

Posted by Andy Singleton on Mon, Jul 08, 2013
  
  

Post-it notes have a glamorous role in the world of agile Scrum and Kanban teams.  They represent the power and intimacy of small team.  Using post-it notes, you throw out ideas with a satisfying squelch.  You rearrange and reorganize your task board on a whim.

However, post-it notes also cause problems.  They are bad for distributed team members, or even for someone who happens to be home with a sick kid.  If someone is not in the room, handling the paper, they aren't included at all.  There is only one version of posted truth, and alternative organizations are not considered.  Worst of all, you throw them away at the end of an iteration.

Post-it notes are an instrument of oppression and control.  You use them to control access to the task board.  You use them to oppress anyone who is not in the room with you. You use them to erase institutional memory and rewrite the past.

In a world with lots of good online ticketing and issue management systems, there's no excuse for the tyranny of post-it notes.  You should put your notes and task boards online where everyone can comment, and you don't lose the information.

 

In Assembla's ticket system, we try to include everyone in an online conversation:

  • We contact the correct people with "follower" email alerts, and a real time activity feed showing comments
  • @mentions in tickets and comments draw users right to the point where they can reply
  • Tickets show a complete history of the discussion and work
  • A cardwall provides a shared team view (Renzoku package), and can be set as the default view for your team.

plan overview resized 600

2 Comments Click here to read comments

Can Agile Work with Geographically Dispersed Teams?

Posted by Andy Singleton on Mon, Jun 24, 2013
  
  

I started following a LinkedIn discussion on the ever-popular topic "Can Agile work with geographically dispersed teams?"

Since 80% of all software teams are dispersed or "distributed," working with geographically dispersed teams is not an option.  You have to make it work, and we will help you.  We’ve been working for years to make distributed teams more agile, and collecting tips and tricks. Last night I pulled together this material and added it to the draft of our upcoming eBook, Unblock: A Guide to the New Continuous Agile.

Sections include:

Three ways to organize, Co-located, Outsourced, Distributed

Communications: A good online ticketing/issue system (like Assembla's) is required.  We also  recommend chat, online standup report forms, daily or continuous builds, and code review.  We do NOT recommend conference calls and other synchronous communication.  What do you think?

Do and Do Not: These core recommendations are simple and will save you a lot of time.

High performing teams, in which we explain how teams will become high performing after they succeed in working together, even if the team members have never met each other.  This position is supported by research, as well as by our own experience.

I would appreciate it if you check out this draft material and write your comments on the LinkedIn discussion group that we set up for Continuous Agile.

Here are some representative comments in the LinkedIn thread:

Allen Holub writes:  "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."  "Distributing the team is always a mistake. Have different teams in different locations can work, but you *never* want to split the team up." 

Andy's response: A lot of people made the argument that projects can be distributed, but you want to put complete teams in one place.  To me, this doesn't match reality, and it uses people poorly, essentially discriminating against people in some locations.

Carleson counters with "The teams must be equal".  That's right.  You want everyone to participate equally regardless of location.  However, he also says "Invest heavily in video equipment", which is wrong.  Most teams are just annoyed by video.

However, there were also a lot of people who say they are getting good results with their distributed teams.  These people didn't give up.  They kept trying things until they found good ways to communicate and collaborate.

We run a distributed team working in 15 countries, with multiple releases per day. This is a common architecture for modern startups. People who say they can't be agile with truly distributed haven't taken the time to learn how to do it.  They bring in a lot of assumptions about how teams communicate, and they haven't opened their minds to real behavior in a distributed workplace.

0 Comments Click here to read comments

How to Manage Agile with Assembla: Tutorials

Posted by Jon Friedman on Wed, May 29, 2013
  
  

How do you plan, manage and close Scrum sprints with Assembla?

Stabilize a Scrumban iteration? (And what is "Scrumban"?)

Manage the tasks in a Kanban or lean Continuous Delivery process?

Assembla has very flexible tools for managing Agile (and non-Agile) development processes. So flexible, that it's not always obvious how to manage tasks for a specific Agile methodology.

That's why we have created three online tutorials that walk you through how to manage Scrum, Scrumban and Kanban processes using Assembla's new Renzoku feature set.

Tutorial screen

You can find the tutorials here:

How to Manage Scrum with Assembla

How to Manage Scrumban with Assembla

How to Manage Kanban/Continuous with Assembla

By the way, Scrumban uses periodic releases, like Scrum, but adopts some lean practices from Kanban. Read about it here.

3 Comments Click here to read comments

A Developer Dashboard for All Your Tools

Posted by Michael Chletsos on Wed, May 22, 2013
  
  

The custom tab tool is one of my favorite tools in the stack, since I can use it to extend Assembla functionality and tools without doing anything.  

Our team used to have a bunch of tools all over the place, New Relic for monitoring our application, Nagios for monitoring our servers, Jenkins for our CI, Kibana for log aggregation, and even a custom application for showing off our Developer stats.  We had documentation to let everyone know where each tool was.  It was tedious and annoying to keep up to date and inform everyone where to go next.

Instead, I put them in Custom Tabs:

custom tab screen

Now, when we add a new tool to our stack, its immediately available and visible for all our developers to use from within the Assembla project.

Ideally you are able to use authentication integration so that being logged into Assembla also has you logged into the other service or tool removing the need to double login, but typically this is not an issue as you would have to login again for another browser tab.

We also just added the favicon as default to Custom Tab tabs, I hope you enjoy this feature as much as me. To try this out yourself, visit the Admin tab of your project > click on Tools > and Add the Custom Tab Tool. 

To Check Out More Cool Features and Tools - www.assembla.com

0 Comments Click here to read comments

Using Estimates? Cumulative Flow Chart is for You

Posted by Maxi Perez Coto on Tue, Apr 23, 2013
  
  

Yesterday, this report showed only a daily cumulative quantity of tickets, we have improved upon it.

Do you use estimates on your daily work? - Good news, today you can choose "Ticket Estimate" from the “Type” select box.

 Screen Shot 2013 04 23 at 14.29.18 resized 600

You will be able to see the same Cumulative Flow chart, but this time you will see the sum estimation of your tickets (per status).

Which type of Estimating do you use?

  • Do not use estimates: Default estimate value is 1.0, so you will get the same graph as Ticket Count.
  • Show estimated total time: Estimate value is saved as a float value representing the total time, you will see a cumulative report of tickets total time.
  • Show estimated points: In this case you can manually set points to each ticket, the result will be a summation over time of points in tickets.
  • Estimate as T-Shirt sizes: (Small / Medium / Large): Same as estimated points but with predefined values.
    • Small => 1.0 points.
    • Medium => 3.0 points.
    • Large => 7.0 points

We have been collecting this data for a week so far - full month Cumulative Flow Chart will be available in three weeks. If you use estimates on tickets, then this upgrade is for you. Enjoy!

Read more about how Assembla can help You.

2 Comments Click here to read comments

Develop Faster: Set Up Your Git Fork and Merge Network

Posted by Michael Chletsos on Mon, Mar 25, 2013
  
  

A Complete Guide to Setting Up and Working with a Git Forked Network

fork merge smI have spoken often about the Assembla process that we have been working in and how well it works for us, but how can you get the same benefits for your project? Well, there is no secret, its just a matter of setting up a development fork and merge network. The basic idea is to isolate development work from stable work. By isolating, all development work from stable work you have a clear path from developer to production. Although this process is not specific to Assembla, lets see how this will would work utilizing Assembla. One could tailor this process to work in any system, and it would be just as powerful, though not as convenient as with the tools Assembla provides.


  • Setup Development Space

First we need to setup a new space. You can do this from your Assembla start page by clicking the 'Create New Space' button. Depending on your account and plan, you might want to setup a public or private space. It does not matter which type of space you setup.

Create Space

 

  • Setup Origin Git Tool

Great, we now have a place to work within. We need to have a Git Tool, if your space configuration did not have a Git Tool, please add it from Admin tab and then the Tools Heading.

git description

Whether you just created a tool, or it came pre-configured, I highly suggest renaming the Git Tool by going to the Setting subtab. Here you can rename the repository to “origin” and set an extension if you like, for the origin repo, I do not like adding an extension – I like the origin named “project.git”. I like calling it “origin” since this is standard git terminology for the original point of the code.

rename

 

  • Initial Commit to Origin

Now we have a Git Tool renamed to “origin” but no code in it. At this point, we can push code up to this remote repository and utilize it like we would normally utilize a git repo. Just to ensure everything is working, let's make sure we can read and write to the repo. Before you proceed ensure that you have added your public ssh key to your profile (found in the upper-right dropdown menu->Edit Profile->SSH Keys). Once your key is added, follow these instructions (replacing project.git with you appropriate project name) on your localhost to create a local repository that you will sync to the remote repository:


 $ git clone git@git.assembla.com:project.git # will complain that you cloned 
an empty repo
$ cd project
$ echo “Project Readme File” > Readme
$ git add Readme # add Readme file to git tracking
$ git commit -m “Initial commit of Readme file” Readme
$ git push origin master # create a master branch in “origin” repo

 

We have just made our first commit to origin/master. If you prefer you could use the http(s) method to interact with your git repo. Https is particularly useful behind a firewall that does not have port 22 open for ssh (many corporate firewalls are setup this way), while still encrypting your data. Http(s) will have more overhead and therefore slower than the ssh protocol. It does not update your localhost with information as often as the ssh protocol (sometimes it looks like it is hanging when it is working) because it waits between actions before responding to your client.

first commit

You can view this file that was just created in your code browser by navigating back to your Git Tool in Assembla and using the Browse Code subtab. To see the actual commit, take a look at the Commits subtab.

Hint: When committing add status updates such as fixed #123 or re #123 to reference the ticket in your commit message and to post a link and commit message on the ticket.

 

  • Our First Developer Fork

Theory: One could just work in the origin repository. You can branch and commit to origin like you would any other repository, however, this can cause bottlenecks and problems for your development process. Say that developerA commits bad code to origin/master – they discover this through QA, UAT or CI, and developerB needs to perform a critical hotfix to Production. If all are committing to origin/master and deploying this to Production, then we have a bottleneck caused by developerA's bad commit. This commit must be reverted or possibly you could branch before the commit add developerB's commit to this branch, then deploy out to Production this branch. Ugh, that is dirty.

Another model may use release branches to help solve this. Release branches rely on the fact that no-one alters them between releases but takes overhead to cut them, coordinate developers and manage them. This becomes very hard to maintain across many, many developers and does not allow a free-flow of code from developer to Production, instead you must commit to several branches to ensure that you keep your Development branches and Release branches in sync. Often release branches become divergent from Development branches and you cannot patch them easily as there are different codebases and the merge results in conflicts or there is logic missing that is expected.

Instead, we introduce the Developer Fork. The Developer Fork is a repository that is based on origin, but allows the developer to maintain their own repository including branches, tags and commits. It also has one other nice advantage that is a little hard to see at first, but if managed properly, you will not run into strange merge problems with new work – all new work is applied on top of branches that are consistent with your current work. In other words, you will not get any of those annoying, you must merge before you can push errors.

To create the developer fork, go to your origin's Git Tool and then the Fork Network subtab, from here you can choose to fork your project. It does not matter if you do it to another space or within the same space. The considerations made to whether you will fork in the same space or to another space have to do with whether this is a new project being branched, if the developers will work off the same list of tickets, and if you have creation permissions in the space to create this fork amongst many other considerations. For our purposes and the purposes of most teams working on the same list of tickets, it is best to keep this fork in the same space – so that you can reference the tickets in the commits easily.

fork subtab

Once you have forked the repository go to the new Git Tool and rename it and give it an extension that matches the name in the Settings subtab. This will make it easier to talk about and remember where you are pushing code or merging to/from. For our purposes we will call it “fork”.

Advanced: Anytime you clone a repo, you are in fact creating a fork. You can then push this cloned repository to any remote repository. You may also connect any existing repository to any remote allowing you to maintain several remote repositories in a forked network in one local repo, you do not need to create a new tool or new space. If you already have two Git Tools in your Assembla space, you can add a “fork” from one repository to the other repository. Branches in git do not have to have a common ancestor nor do they even have to be related to each other; you can store completely different information in the same repository in different branches for git. So taking our origin/master setup in our space and a new Git Tool called “fork” and with the “fork” extension, we can clone this repository and then push a fork from origin back up to it. There are at least two ways to do it, each with different advantages:


 # Using “origin” repository as your remote origin for your local repository – 
typical for people who have read/write to origin/master
$ git clone git@git.assembla.com:project.git # should have Readme file from before
$ cd project
$ git remote add project_fork git@git.assembla.com:project.fork.git # add remote
for “fork”
$ git push project_fork master # create a master branch in the “fork” repo

# Using your “fork” repository as your remote origin for your local repository –
typical for developer setup
$ git clone git@git.assembla.com:project.fork.git # will complain of cloning
an empty repo
$ cd project.fork
$ git remote add project_origin git@git.assembla.com:project.git # add remote for
“origin”
$ git checkout -b orig_master –track project_origin/master # switch to local
branch “orig_master” and track the origin/master remote repo
$ git push origin master # push the orig_master branch to the “fork” remote
(origin of this repo)

  • Other Developer Forks

You can repeat the process above as many times as you like. I prefer to do this on a per developer basis. But you can easily setup a team that works in branches and has a common fork/master. This is the fork per team methodology. The advantage here is you have a single point of control for batching releases per team. However this same advantage is also a disadvantage where you have a bottleneck if a developer has committed code that is not clean or is waiting on other code.

Theory: The advantage of the fork per developer is that each developer is responsible for their own fork/master, and if they commit bad code or are waiting on other code, they do not block any other developer. This allows releases to occur more often on a per developer basis. If you are not in an environment that can sustain many releases very often, then you would arrange the fork network a little differently. Instead of developers working in the fork of origin, they will work in a fork of the fork – yes a fork of the fork. Just make the fork from the fork of origin, and you will have a repository that can merge easily back to the first level fork (use the fork network for this and just fork from the team fork to create a developers fork that will merge back into the team fork).

 

  • Branching in Forks

Theory: In general it is good to create a new branch for all isolated work, i.e. each ticket that you work on should be in its own branch. This allows a developer to start and stop work, or wait while work is reviewed or QA'ed, but still moving forward with other work.

When working on ticket branches, which I like to call ticket_X where X is the ticket number, are disposable branches. Assembla has created a convenient way of maintaining disposable branches, in your Git Tool Settings subtab, you will see a section that allows you to denote the pattern for naming disposable branches.

disposable

Then when you Merge or Ignore a Merge Request that is based on this branch, the branch is automatically deleted from the repository – truly helps with keeping a clean Development Fork. It is important to understand that even if a branch is deleted, no code is lost, that is the beauty of git, all commits are still present and the branch can be recovered if necessary. Typically, the developer will also have these branches locally still and can push them back up.

delete disposable

 

  • Merging

Theory: The general rule of merging is that you only want to merge from where you branched or to where you branched. If you jump across branches, the merging will work, but it might have seemingly strange results or may affect files that you did not mean to affect. So merge from your fork/branch to your fork/master and from your fork/master to your origin/master but not from your fork/branch to origin/master. That is a simplistic view – I am assuming that fork/branch is always coming from fork/master – but this does not have to be true. And moreover, it will not be true when hotfixes are done.

When merging from a fork upstream to your origin or from a 2nd level fork upstream to the 1st level fork (fork per team), you can create a Merge Request from the Submit Code tab, choosing your fork/branch as the Source (“From”) and the fork/master as your Target (“To”).

merge create

 

  • Code Review

Theory: All code going into your fork/master should be Production-ready code. To ensure this, most teams will need a code review process. The Code Review process in Assembla can be accomplished in the Changeset view, which you can find from the Commits subtab where a reviewer can add comments directly in-line with the code, but more appropriate it can be done from the Merge Request subtab where you will submit a Merge Request from your branch to your master. You will choose your fork/ticket_X branch as the source and fork/master as your target. Then you will set a title and description and have the opportunity to review the new code that is potentially being merged to your fork/master. This is a good time to review that the code is as you expect it, this will prevent any gotchas later.

Hint: Add ticket status updates in your description with the same format that you can use when committing to your repo, i.e. fixed #123 or fixed #tickets to affect all associated tickets, to apply this status update once your Merge Request is Merged. 

Once the Merge Request is created from your fork/branch to your fork/master you will have an interface where the team can have a discussion, including the ability to leave @mentions to alert others to help with code review, a list of the changesets that will be merged, diffs on the files that are changed, and a list of tickets (based on commit messages that include #ticket_num) that are being affected by this Merge Request, in-line code commenting, and of course a place to vote on the Merge Request. If you give it a -1 vote, the system does require you to submit a comment, this is because it is typically not beneficial to just leave a -1 without any comment – whereas a +1 speaks for itself (I highly suggest leaving comments on what is proper in the code with a +1).   

merge request

Hint: Setup your CI server to automatically submit votes to your merge requests utilizing the API and/or JAMRb to run Jenkins builds off of your Merge Request. Authenticate with the Assembla Jenkins Auth Plugin.

If the Merge Request is merged via the “Merge and Close” button, the system will automatically merge to the target repository and the disposable branch will be deleted (if applicable). If Ignored, the disposable branch will be deleted and the Merge Request will be archived.

 

  • Deploying

Deploys should always run from origin/master unless you are doing some creative deploying where you want to test out branches in Production before merging them into origin/master (this is a highly advanced workflow and typically needs a level of coordination and architecture that most projects do not have nor can sustain as they grow). This means that origin/master should always be deployable and developers can trust that if they fork/branch or merge from origin/master it has good, Production-ready code.

 

  • Hotfixes

I mentioned that hotfixes are a bit different from regular merging workflow, well it can be true if you need to make a critical patch immediately. In this case its best to work from a branch of origin/master, even if you only have read access from origin/master this can be accomplished, since it is guaranteed to be in sync with your current Production if you always deploy origin/master. Once you have your fix in your local branch, you can push it up to your fork as a branch and create a Merge Request from fork/hotfix_X to origin/master; since you branched from origin/master you should merge directly back to it. To see how this would work in a developer fork with a remote of origin/master called orig_project and a local branch of orig_master tracking origin/master:


 $ git checkout orig_master # checkout the origin/master tracking branch on a 
remote called orig_project (not the origin of the local repository)
$ git pull # make sure it is up to date
$ git branch hotfix_ticketNum # create new branch locally
$ git push origin hotfix_ticketNum # push hotfix_ticketNum branch up to fork
remote (called origin locally)

 

Now you can create a Merge Request from fork/hotfix_ticketNum to origin/master and have Code Review before merging and then deploy to Production.

 

  • Conclusion

So that is basically how you set up a fork network in git for developers to be able to isolate their work and merge back to origin/master and from origin/master to their development fork.

To Learn more about other workflows, click here.

2 Comments Click here to read comments

Story Functionality Enhancement - Now you can drag tickets out of Stories

Posted by Hank Lander on Fri, Mar 22, 2013
  
  
Tags: ,

As many of you know, Assembla is on a journey of self-improvement and one of our priorities is to increase the responsiveness to our customers.

So, with no further ado, I am happy to announce that users will now be able to drag subtasks out of stories. Many thanks go out to André Mendonça for working on the feature and to all our customer who voted on this request in our feedback site.

Please check out our other Agile features if you haven't done so yet. We appreciate your feedback so keep the posts and upvotes coming. 

2 Comments Click here to read comments

Your Personal Source of Information

Posted by Michael Chletsos on Mon, Mar 18, 2013
  
  

Finding Focus for Your Priorities

Why are none of your priorities being worked on? You have told everyone on the team over and over again what they are. You ask everyone if they are working on the priorities, they assure its their number one task. And that's all you hear over and over again.

Insanity: doing the same thing over and over again and expecting different results. --Albert Einstein (attributed)

Stop the insanity, enter the Cardwall. The Cardwall is a Kanban board, but its so much more. When your team works with a Cardwall and keeps tickets up to date, the Cardwall is your personal source of information for the current status of work in progress or not in progress.


cardwall design

  • There is no reason to track down each person to interview them on the status of a ticket.

  • You can see if your priorities are in progress and if so, you can open up the ticket to view progress of that specific task.

  • Code commits, developer and product manager comments, QA results, merge requests, file attachments and many other parts of the discussion are found in the details of the ticket.

  • The ticket is the most accurate form of information that one can view.

Learn more about other collaboration features at Assembla, click here.  



2 Comments Click here to read comments

All Posts | Next Page

Follow Assembla

twitter facebook youtube linkedin googleplus

Get Started

blog CTA button

Subscribe by Email

Your email: