Three Must-Have Traits for Agile Team Members

During our most recent Agile Orlando Lean Lunch meetup, one interesting topic we discussed was what ideal traits a recruiter should be looking for to vet whether candidates are good fits in an Agile environment and culture. This naturally evolved into a discussion of common characteristics we’d observed in successful team members on Agile projects. Beyond the obvious technical or professional skills required for a particular project, there are some key character traits and behaviors that can mean the difference between adding (or yourself being) a rock star or just another run-of-the-mill team member.

  • Ownership of your deliverables
    One difficult transition for team members jumping from traditional development teams (or not-actually-Agile teams) to the Agile mindset is the need for all team members to be owners. Each team member should feel responsible for the success of the work product being delivered. The deliverable is a result of every team member’s effort. Team members who learn to embrace that ownership and become invested in the product begin to naturally look for ways to improve the product, the process of developing the product, and how to get the best out of their fellow team members. Those who remain stuck in the grind of simply working and closing tasks tend to remain stuck in their silos and disengaged from the team.
  • Engagement within the team
    A team member must be willing to engage with the team on a regular, consistent basis. Many team members new to Agile mistakenly assume the common Daily Standup is the limit of team engagement they need to worry about. The Daily Standup is seen as nothing more than a replacement for the traditional Status Report, albeit shorter and more frequent. The focus becomes “What status do I need to give?” rather than “What is everyone else working on and are there any problems I can help resolve?” A team member who is able to engage with the rest of the team is better able to build trust, know when their help might be beneficial to someone stuck, and feel that they can depend on their fellow team to help when needed.
  • Resilience and the willingness to fail
    Agile is an iterative process, built on the idea of trying things out, discarding the things that don’t work, and keeping what does. Whether it’s a new way of approaching a business process, a new technology stack, or a team ceremony to try, something will inevitably not work the way you or your team hoped. A rock star team member learns what they can from this failure and moves on to their next experiment, which could mean scrapping an idea completely and or a simple modification to the previous experiment. Failure is not something to celebrate, but neither is it something to shy away from. When team members meet with failure of one sort or another, they should reflect on how they can avoid such a failure in the future rather than dwelling on why and how it failed in the first place.

What other traits have you noticed in the members who seem to excel in Agile environments?

Event Store on Azure VM Quick Start Guide

We recently started work on an event-sourced application that will run in Azure and we needed to get a quick Event Store instance up for development. We had a hard time finding information about the details of standing up Event Store in Azure, so this post will walk through the various steps required to go from nothing to a working dev instance.

Note that this post does not cover best practices for an instance of Event Store, simply getting Event Store going for development and testing. As such, considerations such as authentication and performance are not covered.

Create and configure Azure VM

Creating the VMAs a first step, we’ll create a new Windows Server 2012 R2 Datacenter VM that uses the Resource Manager deployment model. Since this is for development use, we don’t need much in the way of performance or scalability. We’ll sized the VM as a small Basic A1 instance. I do want to be able to easily reach my Event Store repo from my development boxes, so we’ll also change the Public IP address to static. The rest of the options will be left at their defaults. Once the VM is created, the server blade will open. We’ll take note of the Public IP assigned to the VM for later use.

While still in the portal, let’s configure the network to allow Event Store traffic. Connections to the Event Store repo take place over TCP port 1113. The Event Store administration website is hosted on port 2113. We need to be able to read and write to the Event Store repo from external boxes, so let’s open TCP port 1113 to my new VM.

Inbound port ruleWe’ll click on All resources from the main menu blade. When the esdemo VM was created, it automatically created an esdemo network security group. We’ll select that from the resources list, click on Inbound security rules, and click Add to create the new rule. The Protocol should be set to TCP and the Destination port range to 1113.

If we wanted to be able to remotely administer the Event Store instance via the web interface, we would add a second rule for TCP port 2113 as well. Since I plan to only administer the instance locally by remoting into the VM, we will only apply the first rule and continue on.

Note that since we are not covering security and authentication for Event Store, you may wish to limit which IP addresses can access Event Store through the network configuration. This can be done using the CIDR block or Tag options of the Source setting when creating the inbound security rule.

Installing and Configuring Event Store on our VM

Now that the VM and network configuration is ready, let’s RDP in and install Event Store as a service. Before installing, we’ll need to create a local, non-admin user to run the service under (heretofore referred to as “service user account”). Since the user needs no special rights yet, let’s create a standard account and make sure to uncheck the User must change password option so the account doesn’t have any issues starting the service.

>Next, we will create a C:\EventStore directory to hold the Event Store installation and repository. Download the latest release of Event Store and unzip it into the directory. Event Store does not have any built-in support for running as a service, so we’ll also download the latest release of NSSM to run Event Store as a service and unzip it into the same Event Store directory. We’ll need to grant the service user account we just created Full Control access to this new C:\EventStore directory.

Installing the serviceTo install Event Store as a service, let’s open a command prompt and change to the C:\EventStore directory where NSSM has been unzipped. Running nssm install EventStore allows me to specify the executable to run as a new service.

For Path, we’ll browse to the EventStore_ClusterNode executable where we unzipped Event Store. Startup directory will be the directory where the executable is located. By default, Event Store will only listen for connections on the local interfaces (localhost and 127.0.0.1). Since we want Event Store to be externally accessible, we will tell it to listen on all interfaces by specifying –ext-ip “0.0.0.0” in the Arguments field.

Lastly, switch to the Log on tab and have the service log in as the service user account we previously created. Click Install service and we’re almost ready to start up Event Store.

When Event Store starts up, it will attempt to register with HTTP.SYS to listen on port 2113 for the administration website. We need to grant our service user account permissions to register that port. To do so, we’ll run netsh http add urlacl url=http://*:2113/ user=esuser from the Command Prompt.

Windows Firewall ruleAnd finally, we need to make sure port 1113 is open in the Windows Firewall by creating a new TCP port rule to allow 1113 inbound. We would also create a rule for 2113 if we wanted the administration website to be remotely accessible.

Testing our service

Event Store admin siteAt this point, the service is ready to go! We can start it up using net start EventStore from the command prompt or using the Services control panel. Once started, we’ll open a browser on the VM and attempt to locally browse the web administration website. We go to http://localhost:2113/ and are greeted by the Event Store administration page.

The default admin username is admin and the default password is changeit. The first order of business will be to change that password, especially if you’ve opened port 2113 for external access.

Browsing the web administration site shows that the Event Store service is running and accessible internally, but we need to confirm that Event Store is available externally as well. For this, we’ll open IE on our local desktop and browse to our public IP address, port 1113.
Remotely accessing Event Store with a browser

We’re sending a simple GET request and not a proper Event Store request, so we will receive back an Invalid TCP frame received error, but this is confirmation that we’re able to reach the Event Store service externally. Note that if trying this test with Chrome, the error does not show up in the browser window, but instead triggers a download of a text file that contains the error text. Just save yourself the trouble and test in IE.

That’s it! At this point, Event Store is ready to be a repository for your event-sourced dev applications. I’ll cover some best practices for production deployments and configuration in a future post.