Skip to content

Feed aggregator

How Agile Experts Do Agile at Scale

Rally Agile Blog - Fri, 01/22/2016 - 19:00

It used to be that software was something you had in your business: you used it to manage work and control your hardware, or you sold it to customers to generate revenue. But in today’s digital world, software is your business.

Whether you’re a B2C or B2B organization, it’s likely that software underpins your business operating system—driving your sales, your brand, your manufacturing, your supply chain, your communications, your infrastructure, your relationship with your customers … probably even your thermostat and coffeemaker.

Many of you have discovered that an agile approach is the best way to build and deliver great software, faster. In a recent webinar with CA Agile VP of Product (and former agile coach) Ryan Polk and guest analyst Diego Lo Giudice of Forrester Research, Diego shared results from Forrester’s Q2 2015 Global Agile Software Application Development Online Survey, citing that a third of firms surveyed have been practicing agile for more than five years. Agile’s ubiquity in software development circles now is such that, as Diego explained,

No one I talk to now would say, ‘No, we're not doing agile at all.’”

Yet many companies with experienced agile teams still aren’t seeing the results they’d hoped for, in part because they haven’t been able to successfully scale their efforts. Forrester Research reports that only 54% of firms have successfully scaled their agile practices to more than half their teams. Why?

In our webinar, Ryan shared the stories of several notable companies: two had been practicing agile for more than a decade, while the third had been at it for just a couple years. Contrary to what you might think, it was the third company that was seeing the best results—improvements in velocity, quality, and delivery of valuable customer features—while the more experienced companies suffered from slacker agile practices, little visibility into their work, and resistance to management.

Agile principles may be simple, but agile at scale is hard. As Ryan put it,

Agile's not all roses and puppies."

Among the issues Ryan cited as common even in experienced agile companies are teams trying to practice agile in matrix organizations, with six different managers vying for control of the work; teams forgetting that they’re in service to the business, which is responsible for delivering value to the market; aggressive "resource management," where the business re-arranges agile teams and assigns them work rather than letting the teams decide what they can build and deliver; and a lack of commitment to delivering features (instead of a backlog of user stories.)

So what differentiates the companies that succeed in scaling agile from those that have tried and failed, or haven’t even tried? Here's what the experts do.

Focus on cultural change to drive behavioral change. Nearly twice as many of the agile “neophytes” (78%) as experts (42%) surveyed by Forrester struggle with behavioral change as their biggest obstacle to agile adoption. The best way to overcome this obstacle is with executive-level support and agile training, which send the signal that you’re all-in on agile.

Develop solid practices. Just like playing a musical instrument, agile improves with practice. Training and coaching are helpful in getting over the bumpy parts. If you slack off on your practices your agile won’t improve—much less deliver the results you were hoping for.

Connect upstream and downstream. To get the most out of agile, you need to connect your agile development both upstream (to your business’ highest priorities) and downstream (to DevOps and continuous delivery.) This builds a streamlined pipeline for building and delivering customer value, from “concept to cash.”

Organize for the work. No one wants to hear the words, "You need to change your whole organizational structure," but siloing agile in your development group prevents you from seeing bigger results. Cross-functional teams and coordinated, interdepartmental planning are key. As Diego questioned, "Why are you even doing agile if those decisionmakers from the business are not involved?"

Employ a framework. A framework for scaling agile—like SAFe®, LeSS, DAD, or Nexus—can provide guidance for organizing, planning and delivering across teams of teams. Frameworks don’t need to be prescriptive, but they help manage the complexity of synchronizing and coordinating the work and the people with an eye on delivering results.

Mix methodologies if you must. Many large organizations make “water-agile-fall” work, and this approach is certainly better than abandoning agile because you can’t achieve 100% adoption. Some companies even use mixed methodologies with an agile framework.

Use the right metrics. Finishing all your stories in an iteration is a nice achievement, but the right metrics (predictability, productivity, quality) can help you measure whether you're achieving business value and identify where you need to focus. The agile experts continuously improve their practices and measure results with value-based metrics.

Want to learn more? You can check out the webinar recording or download the slides.

Don’t Stop There

If scaling agile is on your roadmap but you need some guidance, you might want to add our next webinar to your agenda. Join us Tuesday, February 9, 2016 at 12:00 PM MST / 2:00 PM EST for a conversation with Dean Leffingwell (Founder of Scaled Agile Inc. and SAFe) about getting the results you want from agile at scale. Dean will introduce the new SAFe® 4.0 and how it integrates Lean, Kanban, large systems engineering and value stream principles to help you deliver more, faster. Register now.

Rally
Categories: Companies

The most essential agile practice

thekua.com@work - Fri, 01/22/2016 - 10:59

Since the declaration of the Agile Manifesto our industry has seen and continues to see many agile methodologies, some better than others. The large number of methods and practices can be confusing and overwhelming for newcomers although each offer their own advantages in different circumstances.

Methdology is made up of many practices

Methodologies offer a starting point for a set of practices, not an end point like many people think. I draw upon practices from a variety of methodologies almost all the time because I find value using them. Some examples include: Continuous Integration, Co-Located and Cross-Functional Teams, Test Driven Development, Refactoring, Daily Stand-Ups, Small Iterations and Retrospectives. Although I feel agile values and principles are important, I also believe that practices are just as important. Practices offer people something concrete to start with and a way to breath life into a principle or value.

After working for more than a decade in agile teams and enviornments, I truly believe there is one key agile practice that has the biggest impact. Organisations, teams and people who fail to use the most essential agile practice end up cargo-culting, or using a practice because others are using it and are unlikely to gain real value from the practice. Organisations, teams and people who use the most essential agile practice become the best at what they do because they understand why they are doing what they do.

Insanity: doing the same thing over and over again and expecting different results – Albert Einstein

The most essential agile practice is Reflection. In the upcoming follow on article, I will explain how I have seen organisations, teams and people use the practice of reflection.

Categories: Blogs

Removing the static API from AutoMapper

Jimmy Bogard - Thu, 01/21/2016 - 22:19

As I work towards the 4.2 release of AutoMapper, I got a little inspiration. Over the past year or so I’ve given some talks/podcasts about a long-lived open source codebase. One of my biggest regrets was that I made AutoMapper have a static API from literally the very beginning. The first tests/prototypes of AutoMapper all started out with “Mapper.CreateMap” and “Mapper.Map”. I showed my boss, Jeffrey Palermo, at the time and asked what he thought, and he said “looks great Jimmy, maybe you shouldn’t make it static” and I said “PFFFFFFFFFFFT NO WAY”.

Well, I’ve seen the problems with static and I’ve regretted it ever since. With the upcoming release, I’ve had a chance to prototype what it might look like without static – it worked great – and I’m ready to mark the entire static API as obsolete.

This is a huge shift in AutoMapper, not so much the API, but forcing everything to be static. Here’s the before:

Mapper.CreateMap<Source, Dest>();

var source = new Source();
var dest = Mapper.Map<Source, Dest>(source);

Or if you’re doing things the Right Way™ you used Initialize:

Mapper.Initialize(cfg => {
  cfg.CreateMap<Source, Dest>();
});

var source = new Source();
var dest = Mapper.Map<Source, Dest>(source);

There are a number of issues with this approach, most of which just result from having a static API. The static API was just a wrapper around instances, but the main API was all static.

With 4.2, you’ll be able to, and encouraged, to do this:

var config = new MapperConfiguration(cfg => {
  cfg.CreateMap<Source, Dest>();
});

IMapper mapper = config.CreateMapper();
var source = new Source();
var dest = mapper.Map<Source, Dest>(source);

The IMapper interface is a lot lighter, and the underlying type is now just concerned with executing maps, removing a lot of the threading problems I was having before.

I’m keeping the existing functionality and API there, just all obsoleted. The one difficult piece will be the LINQ extensions, since those as extensions methods are inherently static. You’d have to do something like this:

var config = new MapperConfiguration(cfg => {
  cfg.CreateMap<User, UserDto>();
});

var builder = config.CreateExpressionBuilder();
var users = dbContext.Users.ProjectTo<UserDto>(builder);

It’s not exactly ideal, so I’m playing with doing something like this:

var config = new MapperConfiguration(cfg => {
  cfg.CreateMap<User, UserDto>();
});
QueryableExtensions.Factories.Configuration = () => config;
// The above two can be done once at startup

var users = dbContext.Users.ProjectTo<UserDto>();

Expressions can’t depend on any runtime values, and can be more or less explicitly tied to the configuration.

The pre-release versions of AutoMapper on MyGet now have this API, so it’s not release yet as 4.2. Before I pushed 4.2 out the door, I wanted to get some feedback.

So do you like this idea? Let me know! I’ve got a GitHub issue to track the progress: https://github.com/AutoMapper/AutoMapper/issues/1031

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

5 Tips to Keep Getting Value from Agile Retrospectives

Ben Linders - Thu, 01/21/2016 - 14:20
People often ask me what to do to prevent that teams get bored when doing agile retrospectives for a longer period. The short answer is: Make sure that you are getting value from doing your retrospectives. Ok, but how can you do that? Here are 5 practical tips that will assure that you keep getting value from your agile retrospectives. Continue reading →
Categories: Blogs

The Death of Continuous Integration

TV Agile - Wed, 01/20/2016 - 20:06
This presentation describes how ever-better Feature Branching tooling has harmed Continuous Integration, compares the cost vs. value of Feature Branching and Trunk Based Development, and explains why Continuous Delivery without Continuous Integration is asking for trouble. As delivery teams mature and adopt Continuous Delivery they will explicitly discard practices that have become more costly over […]
Categories: Blogs

The Business Analyst in Agile

Scrum Expert - Wed, 01/20/2016 - 19:24
As Agile matures and learns from experience, it is clear that the Agile business analyst has a significant role to play. This interactive and musical session will explore the relationship between Product Owner and Business Analyst, their responsibilities and the skills needed. I’m an Alien … I’m a Business Analyst in an Agile world!” “As a Business Analyst, I have the skills to analyse processes and ...
Categories: Communities

Opening WatchMeCode’s Revenue, Churn And Other Metrics, For All To See

Derick Bailey - new ThoughtStream - Wed, 01/20/2016 - 18:44

If you’ve listened to The Entreprogrammers podcast at all, then you know I’m not shy about sharing metrics and stats for my business, including WatchMeCode.

To that end, I’m happy to say that I’ve taken yet another step to making my company and my stats open for everyone to see by joining the Baremetrics Open Startup program!

Baremetrics And The Open Startup Program

If you’e not familiar with Baremetrics, they take your Stripe.com payment processing events and other information and produce reports and graphs that can be critical to helping you understand your business. From monthly recurring revenue, to user and income churn, and so much more beyond that. If you’re running a business with Stripe as your payment processor, you need to be using Baremetrics.

One of the things Baremetrics has done, is provide a way for their customers to share their metrics with the world. This is done through the Open Startups program – a listing of companies that allow you to see their full metrics.

Here, for example, is a snapshot of my metrics as of writing this:

NewImage

An Incomplete Picture

In spite of showing everything that Baremetrics gives me, what you see here is still an incomplete picture.

I have about a hundred subscribers still on PayPal, for example. I also do screencast bundle and package sales, ebook sales and other things which often come through PayPal and other sources.

In the end, my Stripe payments account for about half of my actual sales. But the numbers I see in Baremetrics are still incredibly valuable to me.

Using the metrics shown here, I have begun to adjust some of the emails I send when someone signs up, cancels, has a failed payment, etc. I’m working to keep subscribers around longer and make sure they are happy – all of which will be reflected in the stats as time moves on.

And I want to share both my success and failure, as it happens! 

Why Show My Metrics To The World?

The Open Startup program is best described in Baremetrics’ own blog post

With Open Startups you get to follow along in real time and discover companies that want to run open and honest businesses. Customers get to peek in to the financials of the businesses they depend on and new startups get to learn from the people who’ve gone before them.

This simple paragraph gets to the heart of the issue, explaining why anyone would want to do this – and it’s not about vanity. If it was, I would be lying through my teeth to tell you how awesome my company is, and how I’m making way more money than I am.

But the reality of my income is now out there for everyone to see, which helps me with these things:

  • to be open and honest
  • to give others some insight into business they trust
  • to help those that follow, to understand and learn

These are the core reasons that I want to share my metrics with the world, and to let people know what’s going on with my business.

These are the same reasons I am part of the Entreprogrammers podcast – a recording of my mastermind group’s weekly meeting. We share everything about our business, because we believe it helps others to see and hear. It provides ideas, good and bad, success and failure, to help and inspire those that follow behind us.

Perhaps as much or more than these reasons – to help others, ultimately – I also want to work against what I see as a problem in our culture, regarding money and income.

A Culture Of Silence

Here in the U.S. (and probably in plenty of other countries) there is a culture of secrecy and almost shame about money. It’s a forbidden topic.

We are told by employers not to discuss it, to avoid “why do they make more than me?!” situations. And we as a society have largely listened to what these companies are saying, to the detriment of our coworkers.

By allowing companies to silence us when it comes to income levels, we perpetuate the problem of women, minorities, and other marginalized people making less than straight white men for the same work. When we are not allowed to talk about our income, this disparity is pay is hidden from the world. 

We can’t fix problems that we can’t see. 

But then, not everyone has the privilege of sharing like I am doing.

The Privilege To Share

I believe most of my audience has more privilege than they are willing to admit or recognize. Most of you that are reading this have the opportunity to be more open and honest about the levels of income you earn. However, not everyone has the level of privilege.

Some legitimately fear losing their job for being open and talking about money. Some fear the social backlash from a mob of hateful people. Still others have other reasons which prevent them from sharing. And chances are, those that are worried about these problems are the ones that are being negatively affected by our cultural silence, already.

I have the privilege of sharing these numbers, fortunately. I am not going to be attacked. I am not going to have belittling comments thrown at me. I will not be challenged on the validity of my income levels, and my job will not be in danger for sharing this. If any of these things do happen to me, I know I’ll survive.

And since I can share, I will share.

I Want To Share, To Be Open

I want to share with the world. I want other screencasters and technology minded entrepreneurs to see what can be done. I want to show the results of the efforts I put in, and share my success and failures in a way that helps other people learn. 

I have rarely shied away from talking about these numbers. Now, they are only easier for everyone to see.

So if you’re interested in seeing what kind of revenue WatchMeCode brings in… if you want to know how many subscribers I have… or whether they stick around for more than a few months – check out the WatchMeCode Open Metrics, and feel free to ask questions!

Categories: Blogs

Agile on the Beach Call for Speakers

Scrum Expert - Wed, 01/20/2016 - 16:13
The 2016 Agile on the Beach conference will be held at Falmouth University (Cornwall, UK) in on 1st and 2nd September 2016. The organizers would like to invite proposals for sessions. Since 2011, the Agile on the Beach conference has established itself as a world class event for Agile software development and Scrum project management. The conference has sold out in the last three years ...
Categories: Communities

Achieve The Unthinkable using Hyper-Sprints

Xebia Blog - Wed, 01/20/2016 - 14:17
 33177940

2015-06-25 AMSTERDAM - Wereldkampioen sprint Dafne Schippers poseert naast de Nuna 7S van het Nuon Solar Team. De atlete neemt het in Olympisch Stadion op tegen het Nuon Solar Team, de wereldkampioen zonneracen. Projecten zoals Nuna en Forze worden door Hardware Scrum coaches van Xebia begeleid.

In my opinion, the best indicator how "agile" teams actually are, is their sprint length.  The theory says 2-4 weeks. To be honest, as an agile coach, this doesn’t feel agile all the time.

Like I wrote in one of my previous posts, in my opinion the ultimate form of agility is nature. Nature’s sprint length seems to vary from billions of years how the universe is created to a fraction of a second how matter is formed.

Of course, it’s nonsense stating we could end up in sprints of just a few nano-seconds.  But on the other hand, we see our society is speeding up dramatically. Where a service or product could take years before it went to market a couple of years ago, now it can be a matter of days, even hours.  Think about the development of disruptive apps and technology like Uber and 3D-printing.

In these disruptive examples a sprint length of 2 weeks can be a light year.  Even in Scrum we can be trapped in our patterns here. Why don’t we experiment with shorter sprint lengths?  All agile rituals are relative in time; during build parties and hackathons I often use sprints of only 30 or 60 minutes; 5 mins for planning, 45 mins for the sprint, 5 mins for the review/demo, 5 mins for the retrospective.  Combined with a fun party atmosphere and competition, this creates a hyper-productive environment.

Try some hyper sprinting next to your regular sprints. You’ll be surprised how ultra-productive and fun they are. For example, it enables your team to build a car in just an afternoon. Enjoy!

Categories: Companies

New Feature: Continuous Team Workflows for teams collaborating in sequence

TargetProcess - Edge of Chaos Blog - Wed, 01/20/2016 - 08:10

At Targetprocess, we strongly believe that your project management tool should adapt and grow together with your company; it should be easy to adjust the tool’s configuration to fit your current process, and to update it later when your company process is changed. That is why we try hard to enable you to follow your target process.

Previously we introduced the Team Workflow feature which allows teams to create and use their custom workflows for all the entities in Targetprocess which do not affect other teams. However, there are many other possible scenarios for organizing the collaboration of multiple teams in your company. For example, several teams might need to work on the same entity. Until now, they used different workarounds for this purpose: they might have created duplicate entities or used relations to link several teams to one item.

We are proud to announce our new feature: Workflow Management for Functional Teams.

The new functionality will be interesting for companies who have teams working sequentially. Accounting, Marketing, Designers, Development are examples of such teams. They are often called functional teams.

From now on, several teams can work on the same item – e.g. a feature or a user story – one after another. So, the final state of the item in the workflow of one team is its first state in the workflow for another team.

For example, you might have Analysts, Development and Delivery teams working sequentially on a user story in a project:Functional Teams

The work is started by the Analysts. When the Analysts move a user story to the state which is final for their team, the Development team takes the responsibility for it.

The “Done” state of the Analyst team’s workflow is mapped to the initial state of the Development team workflow. This enables passing a work item from one team to another automatically. Below here is an example of the team workflows setup:

Team Workflow Sequential case

When we open a user story assigned to the Analyst, Development and DevOps teams we will see these teams’ states under the corresponding project states:

Team States Selector

Any team can create their own view by choosing the Team State for the vertical lanes in order to see this team’s part of work only.

When the Analytics team moves a user story to the “Done” team state, it automatically goes to the Development’s “Open” team state (as they are mapped to the same project state) and disappears from the Analysts’ Kanban board:

Functional done states

For more use cases and FAQ, please visit https://www.targetprocess.com/guide/settings/states-workflows/multiple-teams-use-cases/ or contact our Support team.

By default, the new functionality is enabled:

  • for all new Targetprocess accounts created after January 19, 2016
  • for all the existing accounts where at least one Team Workflow has already been set up

If you would like to check out this functionality for your teams, don’t hesitate to email support@targetprocess.com with a request to enable this feature for your account.

We’d love for you to try it and let us know what you think!

Categories: Companies

Using Guardrails to Guide Decision Making

Guardrails are designed to keep people from unintentionally straying into dangerous territory. They are usually placed in...

The post Using Guardrails to Guide Decision Making appeared first on Blog | LeanKit.

Categories: Companies

Automated deployment of Docker Universal Control Plane with Terraform and Ansible

Xebia Blog - Tue, 01/19/2016 - 21:06

You got into the Docker Universal Control Plane beta and you are ready to get going, and then you see a list of manual commands to set it up. As you don't want to do anything manually, this guide will help you setup DUCP in a few minutes by using just a couple of variables. If you don't know what DUCP is, you can read the post I made earlier. The setup is based on one controller, and a configurable amount of replicas which will automatically join the controller to form a cluster. There a few requirements we need to address to make this work, like setting the external (public) IP while running the installer and passing the controller's certificate fingerprint to the replicas during setup. We will use Terraform to spin up the instances, and Ansible to provision the instances and let them connect to each other.

Prerequisites

Updated 2016-01-25: v0.7 has been released, and no Docker Hub account is needed anymore because the images are moved to public namespace. This is updated in the 'master' branch on the Github repository. If you still want to try v0.6, you can checkout tag 'v0.6'!

Before you start cloning a repository and executing commands, let's go over the prerequisites. You will need:

  • Access to the DUCP beta (during installation you will need to login with a Docker Hub account which is added to the 'dockerorca' organization, tested with v0.5v0.6 and v0.7. Read update notice above for more information.)
  • An active Amazon Web Services and/or Google Cloud Platform account to create resources
  • Terraform (tested with v0.6.8 and v0.6.9)
  • Ansible (tested with 1.9.4 and 2.0.0.1)

Step 1: Clone the repository

CiscoCloud's terraform.py is used as Ansible dynamic discovery to find our Terraform provisioned instances, so --recursive is needed to also get the Git submodule.

git clone --recursive https://github.com/nautsio/ducp-terraform-ansible
cd ducp-terraform-ansible

Step 2.1: AWS specific instructions

These are the AWS specific instructions, if you want to use Google Cloud Platform, skip to step 2.2.

For the AWS based setup, you will be creating an aws_security_group with the rules in place for HTTPS (443) en SSH (22). With Terraform you can easily specify what we need by specifying ingress and egress configurations to your security group. By specifying 'self = true' the rule will be applied to the all resources in that to be created security group. In the single aws_instance for the ducp_controller we use the lookup function to get the right AMI from the list specified in vars.tf. Inside each aws_instance we can reference the created security group by using "${aws_security_group.ducp.name}". This is really easy and it keeps the file generic. To configure the amount of instances for ducp-replica we are using the count parameter. To identify each instance to our Ansible setup, we specify a name by using the tag parameter. Because we use the count parameter, we can generate a name by using a predefined string (ducp-replica) and add the index of the count to it. You can achieve this by using the concat function like so: "${concat("ducp-replica",count.index)}". The sshUser parameter in the tags block is used by Ansible to connect to the instances. The AMIs are configured inside vars.tf and by specifying a region, the correct AMI will be selected from the list.

variable "amis" {
    default = {
        ap-northeast-1 = "ami-46c4f128"
        ap-southeast-1 = "ami-e378bb80"
        ap-southeast-2 = "ami-67b8e304"
        eu-central-1   = "ami-46afb32a"
        eu-west-1      = "ami-2213b151"
        sa-east-1      = "ami-e0be398c"
        us-east-1      = "ami-4a085f20"
        us-west-1      = "ami-fdf09b9d"
        us-west-2      = "ami-244d5345"
    }
}

The list of AMIs

    ami = "${lookup(var.amis, var.region)}"

The lookup function

Let's configure the variables so you can use it to create the instances. Inside the repository you will find a terraform.tfvars.example file. You can copy or move this file to terraform.tfvars so that Terraform will pick it up during a plan or apply.

cd aws
cp terraform.tfvars.example terraform.tfvars

Open terraform.tfvars with your favorite text editor so you can set up all variables to get the instances up and running.

  • region can be selected from available regions
  • access_key and secret_key can be obtained through the console
  • key_name is the name of the key pair to use for the instances
  • replica_count defines the amount of replicas you want

The file could look like the following:

region = "eu-central-1"
access_key = "string_obtained_from_console"
secret_key = "string_obtained_from_console"
key_name = "my_secret_key"
replica_count = "2"

By executing terraform apply you can create the instances, let's do that now. Your command should finish with:

Apply complete! Resources: 4 added, 0 changed, 0 destroyed.

 Step 2.2: Google Cloud Platform specific instructions

In GCP, it's a bit easier to set everything up. Because there are no images/AMI's per region, we can use a disk image with a static name. And because the google_compute_instance has a name variable, you can use the same count trick as we did on AWS, but this time without the metadata. By classifying the nodes with the tag https-server, it will automatically open port 443 in the firewall. Because you can specify the user that should be created with your chosen key, setting the ssh_user is needed to connect with Ansible later on.

Let's setup our Google Cloud Platform variables.

cd gce
cp terraform.tfvars.example terraform.tfvars

Open terraform.tfvars with your favorite text editor so you can set up all variables to get the instances up and running.

The file could look like the following:

project = "my_gce_project"
credentials = "/path/to/file.json"
region = "europe-west1"
zone = "europe-west1-b"
ssh_user = "myawesomeusername"
replica_count = "2"

By executing terraform apply you can create the instances, let's do that now. Your command should finish with:

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

Step 3: Running Ansible

Instances should all be there, now let's install the controller and add a replica. This setup uses terraform.py to retrieve the created instances (and IP addresses) based on the terraform.tfstate file. To make this work you need to specify the location of the tfstate file by settings TERRAFORM_STATE_ROOT to the current directory. Then you specify the script to lookup the inventory (-i) and the site.yml where you can assign the roles to the hosts.

There are two roles that will be applied to all hosts, called common and extip. Inside common everything is set up to get Docker running on the hosts, so it configures the apt repo, installs the docker-engine package and finally installs the docker-py package because Ansible needs this to use Docker. Inside extip, there are two shell commands to lookup external IP addresses. Because if you want to access DUCP on the external IP, it should be present inside the certificate that DUCP generates. Because the external IP addresses are not found on GCP instances and I wanted a generic approach where you would only need one command to provision both AWS and GCP I chose to look them up, and eventually register the variable extip with the one that was correctly looked up on the instances. Second reason to use the external IP, is that all the replicas need the external IP of the controller to register themselves. By passing the --url parameter to the join command, you can specify to what controller it should register.

--url https://"{{ hostvars['ducp-controller']['extip'] }}"

The extip variable used by replica

This also counts for the certificates fingerprint, the replica should provide the fingerprint of the controllers certificate to register successfully. We can access that variable the same way: "{{ hostvars['ducp-controller']['ducp_controller_fingerprint'].stdout }}. It specifies .stdout to only use the stdout part of the command to get the fingerprint, because it also registers exitcode and so.

To supply external variables, you can inject vars.yml through --extra-vars. Let's setup the vars.yml by copying the example file to vars.yml and configure it.

cd ../ansible
cp vars.yml.example vars.yml

As stated before, the installer will login to the Docker Hub and download images that live under the dockerorca organization. Your account needs to be added to this organization to let it succeed. Fill in your Docker Hub account details in vars.yml, and choose an admin user and admin password for your installation. If you use ssh-agent to store your SSH private keys, you can proceed with the ansible-playbook command, else you can specify your private-key file by adding --private-key <priv_key_location> to the list of arguments.

Let's run Ansible to set up DUCP. You need to change to the directory where the terraform.tfstate file resides, or change TERRAFORM_STATE_ROOT accordingly.

cd ../{gce,aws}
TERRAFORM_STATE_ROOT=. ansible-playbook -i ../terraform.py/terraform.py \
                       ../ansible/site.yml \
                       --extra-vars "@../ansible/vars.yml"

If all went well, you should see something like:

PLAY RECAP *********************************************************************
ducp-controller            : ok=13   changed=9    unreachable=0    failed=0   
ducp-replica0              : ok=12   changed=8    unreachable=0    failed=0   
ducp-replica1              : ok=12   changed=8    unreachable=0    failed=0

To check out our brand new DUCP installation, run the following command to extract the IP addresses from the created instances:

TERRAFORM_STATE_ROOT=. ../terraform.py/terraform.py --hostfile

Copy the IP address listed in front of ducp-controller and open up a web browser. Prefix the address with https://<ip> and now you can login with your chosen username and password.

ducp login

Let me emphasise that this is not a production ready setup, but can definitely help if you want to try out DUCP and maybe build a production ready version from this setup. If you want support for other platforms, please file an issue on Github or submit a pull request. I'll be more than happy to look into it for you.

Categories: Companies

Agile Results for 2016

J.D. Meier's Blog - Tue, 01/19/2016 - 17:54

Agile Results is the personal productivity system for high-performance.

Agile Results is a “whole person” approach to personal productivity. It combines proven practices for mind, body, and emotions. It helps you realize your potential the agile way.  Best of all, it helps you make the most of what you’ve got to achieve higher levels of performance with less time, less effort, and more impact.

Agile Results helps you achieve rapid results by focusing on outcomes over activities, spending more time in your strengths, focusing on high-value activities, and using your best energy for your best results.

If you want to use Agile Results, it’s simple. I’ll show you how to get started, right, here, right now. If you already know Agile Results, then this will simply be a refresher.

Write Three Things Down

The way to get started with Agile Results is simple. Write three things down that you want to achieve today. Just ask yourself, “What are your Three Wins that you want to achieve today?”

For me, today, I want to achieve the following:

  1. I want to get agreement on a shared model across a few of our teams.
  2. I want to create a prototype for business model innovation.
  3. I want to create a distilled view of CEO concerns for a Mobile-First, Cloud-First world.

In my mind, I might just remember: shared model, business model innovation, and CEO. I’ll be focused on the outcomes, which are effectively agreement on a model, innovation in business models for a Mobile-First, Cloud-First world, and a clear representation of top CEO pains, needs, and desired outcomes.

Even if I throw away what I write down, or lose it, the value is in the brief moment I spent to prioritize and visualize the results that I want to achieve. 

This little vision will stick with me as a guide throughout my day.

Think in Three Wins

Writing these three items down, helps me focus. It helps me prioritize based on value. It also helps me create a simple vision for my day.

Plus, thinking in Three Wins adds the fun factor.

And, better yet, if somebody asks me tomorrow what my Three Wins were for yesterday, I should be able to tell a story that goes like this: I created rapport and a shared view with our partner teams, I created a working information model for business model innovation for a mobile-first cloud-first world, and I created a simplified view of the key priorities for CEOs in a Mobile-First, Cloud-First world.

When you can articulate the value you create, to yourself and others, it helps provide a sense of progress, and a story of impact.  Progress is actually one of the keys to workplace happiness, and even happiness in life.

In a very pragmatic way, by practicing your Three Wins, you are practicing how to identify and create value.  You are learning what is actually valued, by yourself and others, by the system that you are in.

And value is the ultimate short-cut.  Once you know what value is, you can shave off a lot of waste.

The big idea here is that it’s not your laundry list of To-Dos, activities, and reminders -- it’s your Three Wins or Three Outcomes or Three Results.

Use Your Best Energy for Your Best Results

Some people wonder why only Three Wins?  There is a lot of science behind the Rule of 3, but I find it better to look at how the Rule of 3 has stood the test of time.  The military uses it.  Marketing uses it.  You probably find yourself using it when you chunk things up into threes.

But don’t I have a bazillion things to do?

Yes. But can I do a bazillion things today? No. But what I can do is spend my best energy, on the best things, my best way.

That’s the best I can do.

But that’s actually a lot. When you focus on high-value outcomes and you really focus your time, attention, and energy on those high-value outcomes, you achieve a lot. And you learn a lot.

Will I get distracted? Sure. But I’ll use my Three Wins to get back on track.

Will I get randomized and will new things land on my plate? Of course, it’s the real-world. But I have Three Wins top of mind that I can prioritize against. I can see if I’m trading up for higher-value, higher-priorities, or if I’m simply getting randomized and focusing on lower-value distractions.

Will I still have a laundry list of To-Do items? I will. But, at the top of that list, I’ll have Three Wins that are my “tests for success” for the day, that I can keep going back to, and that will help me prioritize my list of actions, reminders, and To-Dos.

20-Minute Sprints

I’ll use 20-Minute Sprints to achieve most of my results. It will help me make meaningful progress on things, keep a fast pace, stay engaged with what I’m working on, and to use my best energy.

Whether it’s an ultradian rhythms, or just a natural breaking point, 20-Minute Sprints help with focus.

We aren’t very good at focusing if we need to focus “until we are done.” But we are a lot better at focusing if we have a finish line in site. Plus, with what I’m learning about vision, I wonder if spending more than 20-Minutes is where we start to fatigue our eye muscles, and don’t even know it.

Note that I primarily talk about 20-Minute Sprints as timeboxing, after all, that’s what it is, but I think it’s more helpful to use a specific number. I remember that 40-Hour Work Week was a good practice from Extreme Programming before it became Sustainable Pace. Once it became Sustainable Pace, then teams started doing the 70 or 80 hour work week, which is not only ineffective, it does more harm than good.

Net net – start with 20-Minute Sprints. If you find another timebox works better for you, than by all means use it, but there does seem to be something special about 20-Minute Sprints for paving your work through work.

If you’re wondering, what if you can’t complete your task in a 20-Minute Sprint? You do another sprint.

All the 20-Minute Sprint does is give you a simple timebox to focus and prioritize your time, attention, and energy, as well as to remind you to take brain breaks. And, the 20-Minute deadline also helps you sustain a faster pace (more like a “sprint” vs. a “job” or “walk”).

Just Start

I could say so much more, but I’d rather you just start doing Agile Results.

Go ahead and take a moment to think about your Three Wins for today, and go ahead and write them down.

Teach a friend, family member, or colleague Agile Results.  Spread the word.

Help more people bring out their best, even in their toughest situations.

A little clarity creates a lot of courage, and that goes a long when it comes to making big impact.

You Might Also Like

10 Big Ideas from Getting Results the Agile Way

10 Personal Productivity Tools from Agile Results

What Life is Like with Agile Results

Categories: Blogs

Four Tips to Writing Better and Faster

Johanna Rothman - Tue, 01/19/2016 - 15:52

A colleague asked me for some tips about writing. With hundreds of articles, blog posts, and 10 books, I know what works for me. I suspect some of these ideas will work for you, too.

Tip 1:  Write every day.

Write for 15 minutes every day. This practice exercises your writing muscles. For me, it’s a little different than all the email I write :-)

Tip 2: Think about the stories you want to tell in an article.

People love stories. If you include a story, they will identify with it and love your work. That’s because they can identify with the situation, regardless if they agree with you.

You might not like my story approach. Think about what you like to read. What pulls you in? Write like that (not the same words, the same approach).

Tip 3: Writing is not editing.

For me, writing is about 3 parts:

  • Gather the ideas. If you want to outline, this is a great time to do it. Just remember that an outline is a guide, not rules.
  • Write down. 
  • Edit. This is where you use the red squiggly lines and the spell/grammar checker. I excise passive voice in my non-fiction. I look for a lower grade level (about 6 is what I aim for) and a high readability score. 

When I write (down), I don’t edit. I spew words on the page. It’s almost a game: how fast can I write? I write about 750-1000 words an hour. That’s pretty darn close to an entire article. (1000 words) After I’m done with the writing-down, I can edit. 

Tip 4: People will disagree with you

When you write non-fiction, people will disagree with you. (Heck, they probably disagree with fiction, too!) That’s fine. It’s their loss if they disregard your ideas. Everyone has their own experience. If you tell stories/provide tips/write from your experience, you are authentic. You also build your self-confidence. The writing is easier over time.

If you would like to practice your writing, I have an online workshop starting in March. See http://www.jrothman.com/syllabus/2015/12/writing-workshop-1-write-non-fiction-to-enhance-your-business-and-reputation/. You will write at least one article during the workshop. 

Categories: Blogs

Handling Impediments: Deciding on the Actions

Ben Linders - Tue, 01/19/2016 - 15:06
After you've come up with several solutions to deal with an impediment, the next step is to decide which actions you will do with your team to solve it. Let's dive into who decides to take action and explore different approaches for how agile teams can decide. Continue reading →
Categories: Blogs

Workshops in Sydney on Increasing Agility and Agile Value

Ben Linders - Tue, 01/19/2016 - 11:32

Sydney Workshops AgileI will be doing two more workshops in Sydney during my Australian tour in February:

Next to Sydney I’m also visiting Melbourne on my Australian tour. I will give a keynote at 1stConf about The Need for Continuous Improvement in Agile and three workshops in Melbourne:

Categories: Blogs

Social Side of Code in Methods & Tools Winter 2015 issue

DevAgile.com - Tue, 01/19/2016 - 11:06
Methods & Tools – the free e-magazine for software developers, testers and project managers – has published its Winter 2015 issue that discusses the social side of code, database continuous intergration and testing REST API * Meet the Social Side of Your Codebase * Database Conti ...
Categories: Communities

BuildBoard – our tool for developer’s workflow automatization

TargetProcess - Edge of Chaos Blog - Tue, 01/19/2016 - 10:22

Hi minna-san!

It’s been awhile since the last post about our development process. Today I’d like to focus on some aspects of our developers’ workflow. Despite writing shiny new code which is the most interesting part, developer’s life consists of necessary, but not so interesting routine work. In this post I’ll describe our approach to minimise routine. It has helped us not only to devote more time to other activities, but also to enforce our practices. Let’s dive into it.

Here are some tools we use:

We have several teams each working on a separate feature. It’s the responsibility of a team to split each feature into user stories. Every user story is then elaborated by a feature owner and put into the ‘Planned’ state. A user story is implemented by 1-2 developers from the team. Let’s imagine that is my turn to do it. Before I start user story implementation, we arrange a kick-start meeting which is aimed to ensure all team members have shared understanding of the user story. It’s also a good time for constructive critics and suggestions. After the meeting I open Targetprocess and move the user story from the ‘Planned’ to ‘In Dev’ state. It’s time to code now!

0-plan-scaled

According to HubFlow, we create a new branch for each work item (a user story, or a bug). There is ‘develop’ branch which is an integration branch accumulating all the work that has been done lately. So, I start with creating a new branch from ‘develop’ for the user story. Then I open GitHub and create a pull request on the newly created branch.

As functionality is implemented, I run builds on Jenkins on my branch. Our builds have rather complex structure, so it’s quite difficult to see what’s going on in Jenkins. We have different types of builds: short, full and custom builds.

  • Short build includes only a subset of all tests and is the most commonly used one.
  • Full build includes all tests and performs some extra actions, i.e. building installation packages. It is usually triggered automatically every night on ‘develop’. Full builds are necessary for release process as well.
  • Custom build, as it comes from its name, is used when we want to run only particular test parts for some reason and don’t need to run others. Sometimes functional tests fail because of instability. In such case we re-launch failed parts to make sure that everything is OK.

After coding has been finished I have to make sure that the pull request can be merged and the last build is green (all tests passed). It’s a good idea to perform code review now. Another developer reviews all the changes made in the pull request. If everything is good, he leaves ‘LGTM’ comment in GitHub. Then I move the user story to the ‘Coded’ state and it becomes ready for testing. If bugs have been found by our QA, the user story goes to the ‘Reopen’ state and I fix these bugs. After the fixes are verified, the user story finally goes to the ‘Tested’ state.

Eventually, the user story is in the ‘Tested’ state, and it’s high time to merge! Before that, I have to wait for the green ‘develop’, ensure my pull request can still be merged and code has been reviewed.  Only then I can merge my branch into ‘develop’. Finally merged! I have to remember to move the card in the ‘Done’ state in Targetprocess. Phew… Actually not yet. After each push, a new build on ‘develop’ is started automatically. If it fails, I’ll have to fix it ASAP, or revert my commit which caused the failure, fix the build and merge again.

workflow-scaled

As you can see, there are some steps that are nothing but routine (although, useful) and can be automated.  Thankfully, we’ve created a tool for that. We called it BuildBoard. It looks like this:

1-my branches-scaled

I see all work items (user stories, bugs, etc.) assigned to me with the corresponding pull requests, statuses of the latest builds, as well as the states of these work items in Targetprocess. Here I can run a new build, open a pull request or, for example, change the state of a work item in Targetprocess. When all conditions are met, the grey ‘Merge’ button in the right column becomes enabled and I can eventually merge my branch into ‘develop’.

If any part of tests fails, BuildBoard automatically re-runs this part to determine whether it is due to instability, or the build fails for a valid reason and has to be fixed. I can also re-run particular part manually.

2-re-run-scaled

In BuildBoard, we can also view and manage special branches like ‘develop’, ‘master’, ‘release’ or ‘hotfix’.

3-special branches-scaled

The status of ‘develop’ and the status of Transifex integration (the tool we use for localization) are placed in the header, because we want this important information to be always visible.

4-header-scaled

After a build is complete, BuildBoard pushes a notification to Slack. So, I do not have to periodically check build progress in Jenkins. That means less context switching and, thus, better productivity.

5-slack integration-scaled

I can even deploy the current ‘develop’ to the staging server in two clicks.

6-deploy-scaled

In a nutshell, BuildBoard allows us to automate our workflow and enforce our practices, spend more time on actually important things, not routine work. Moreover, it helps us to visualise our development process with all its peculiarities.

Is there anything similar in your developer’s life? How do you automate your workflow? Please share in comments.

 

Categories: Companies

Unlock the Power of Self-Forming Teams


A collaboration by Chris LeBlanc and Mario Moreira
It is quite possible that many teams in your organization are going through the motions of Scrum.  Per the Tuckman model, they are in the Norming phase of team group development, but are hard-pressed to break into the Performing phase.  This may be due to the team feeling a lack of empowerment and what it means to be Agile beyond the mechanics.  We are going to share a technique that can help bring your Agile organization to the next level, increase employee engagement and help make your engineers high performing and happier. This technique is relevant when you have a squad of 14 or more people who need to form into 2 or more teams.  
The common scenario in team formation is where a manager (or those who do not do the work) decides the team structure.  Managers have external knowledge of who may work well together and what skills they possess.  This is an educated guess at best.  Might we consider another approach?
By embracing the concepts of self-organizing teams and bounded authority, we ask those who actually do the work, the team members, to use their team internal knowledge of who they work best with and how their skills are able to complement the members of their team.  The result can be happy, high performing cross-functional teams composed of engineers that that want to work with each other.  For those experienced with the process of self-organizing teams, might it best start with the ability to self-form?  May we introduce the Self-forming Teams starter kit!  This is a technique used to help engineers self-organize toward an engaged and effective team based on their current skill sets.  There are few steps that need to be completed by the leaders before you begin:
Create a vision of the work ahead.  This will give the engineers the information they need to understand who is best to work with based on their current skill set.
Set up bounded authority for the exercise.  The leaders can provide their bounded authority guidance on a few inputs to the exercise: mix of senior and junior team members and buy-in to this process.Everyone follows the bounded authority of the Scrum process as input: team size (7+/-), cross-functional skills (Dev+ QA)
An Agile Coach or facilitator to help guide the team toward their self-forming goals
Once the bounded authority and the vision are established, the Agile Coach or facilitator is ready to begin.  Here are steps to follow. Again, this is relevant when you have 14 or more people who need to form into multiple teams. 
  • Kickoff the session with sharing the self-forming goals with everyone. They include: Well-balanced teams who can successfully and efficiently complete any item in the backlog;  Long-term teams and can autonomously deliver value as fast as possible; Teams that understand skills needed on each squad and a learning path for the short term; Team members like the team they are on and the work they are doing
  • Conduct a connection Ice Breaker to lighten the mood of the session
  • Describe the definition of self-organization
  • Introduce the Product Owner and Architect to discuss the vision and any backlog input
  • Conduct a divergent conversation with everyone.  Ask “What skills will be needed to tackle the presented work from the backlog?”  Write down each skill given by the engineers.
  • Follow this with a convergent conversation that draws affinities between the skills to generate a list of Macros Skills each team would need (5-7 is a good number)
  • Ask each engineer to walk to the board and mark off each skill they currently have and each skill they want.
  • Now start the self-formation process.  Ask the engineers to self-form into teams, using bounded authority and the Macro Skills that were generated as guidance.  As the facilitator, move the conversation along when they become stuck.
  • Finally, nobody leaves the room unless everyone is happy with the team they are on.  Ask for a Thumbs Up / Thumbs Down vote from the group.  If there are any thumbs down, explore the reason and adjust the teams accordingly.

What we have seen to be true of self-forming teams is that knowledge workers who choose their own team structure are more invested in owning the health of the team.  When something is not working on the team, they are more likely to improve it. They are excited and happy to be on that team.  Healthy, happy people create high performing teams that build high quality products quicker.  Unlock the potential (and untapped power) of your teams and extend your ability to self-organize with self-forming teams.
To read more of Mario Moreira's articles, visit: http://cmforagile.blogspot.com/ To read more about Chris LeBlanc, visit: https://www.linkedin.com/in/chris-leblanc-47619a5 
Categories: Blogs

Books -> Digital -> Subscriptions

As a 10 year old I read 100 books in a single summer. I’d read on the bus, at lunch, and waiting for soccer games to start. Ended up with a healthy bookshelf. When I switched to programming in the 90s I swept the bookstores at least once a week picking up books on Perl, Javascript, CGI, HTML.

Eventually I filled up several bookshelves with my technical library. When I picked up a first generation iPad I decided it was time to go all digital. I had experimented with Safari online, but it was never a replacement for my library. I went cold turkey with buying paper books. At this point I was mostly purchasing a lot of pragprog titles and transferring them to iBooks. And beta books don’t ship in paper.

A few weeks ago I realized I had moved to a subscription model. Now I just download my books from pragprog when I need them. No need to keep a bunch of titles in my library when I can pull down the up to date versions. I can also read them on my laptop, iPad, or iPhone anytime I want with a nice retina screen.

Categories: Blogs

Knowledge Sharing


SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.