01 Feb 2013
Witnessed this again first hand last week, and although this is well known it’s been rare to see in practice.
Hold your meeting in a room just big enough to fit the required participants while standing.
There should be a white board on one wall (at least), projection on the front wall, and a narrow standing height table in the middle. The only person with a laptop should be the facilitator. Having a narrow table discourages everyone from bringing their own device, which in-turn puts the emphasis on whatever topic was important enough to bring 4 or 5 people together.
Mix up the focal points during the meeting, don’t just stand around in a circle naval gazing. Remember meetings suck, and most of the time, participants would rather be back at their desk doing “real” work.
By reducing square footage, you’re increasing the likelihood of physical (and I mean actual touching, drawing, etc.) interaction with both the projector screen and white board. Not to mention that meetings will often end earlier, you’ve reached diminishing returns when the interaction begins dying off, that’s when it’s time to vacate.
Have you tried something similar with your team, how did it work out?
27 Jan 2013
Think what you may about Heroku, they do offer a free tier and it’s trivially simple to use it as your own personal staging environment. In this post, I’m going to outline what it takes to take a simple Dropwizard service and get it running in Heroku. For anyone looking for a bit of depth, this example will also include database access (Heroku also gives you a free PostgreSQL database) and touch on using Dropwizard’s Liquibase integration for database migrations.
For the record, I am not particularly for nor against Heroku as a platform. I believe it’s a great service that makes it almost too easy to get off the ground and into the continuous deployment frame of mind. I simply lack the experience using it at scale, opting instead for AWS, to comment on it’s applicability across all stages of an application.
Maybe I’m cheap (Heroku’s a few more dollars than the equivalent in AWS) or maybe I just really really enjoy (the pain of?) managing Chef and setting up my own VPCs.
Getting Started
First off, let’s get a simple Dropwizard project up and running.
$ git clone git://github.com/ajordens/dropwizard-example-groovy.git
Make sure it compiles and runs locally.
$ mvn clean install
$ java -jar my-example-service/target/my-example-service-0.1-SNAPSHOT.jar server my-example-service/config.yml
Lastly, create a simple PostgreSQL database and test database migrations.
$ createdb myexampleDB
$ java -jar my-example-service/target/my-example-service-0.1-SNAPSHOT.jar db migrate my-example-service/config.yml
Assuming everything worked successfully, you’ll now have a service capable of serving html views and json data as well as a simple database.
Setting up Heroku
If you have not already signed up for a free Heroku account, do so now.
You will also need to install the appropriate Heroku Toolbelt release for your operating system.
$ heroku login
Enter your Heroku credentials.
Email: example-app@xyz
Password (typing will be hidden):
Authentication successful.
$ heroku create example-app
Creating example-app… done, stack is cedar
http://example-app.herokuapp.com/ | git@heroku.com:example-app.git
Git remote heroku added
Almost done, all that’s left now is to get the Heroku database connection properties.
Update config-heroku.yml with the values listed in the PostgreSQL add-on section of your application (login to heroku.com)
Pushing Code to Heroku
$ git push heroku master
$ heroku ps:scale web=1
After pushing code to Heroku, it’s completely normal to see your maven build occur immediately.
When the build finishes, the app will be accessible via http://app-name.herokuapp.com
$ heroku open
This works in part due to the magical Procfile that I snuck into the dropwizard-example-groovy project.
The Procfile simply tells Heroku how to start the web application and because Dropwizard is a completely self-contained jar, it runs in Heroku using the same java -jar syntax that you would use to run locally.
Almost magical.
Migrating Databases on Heroku
Managing your Heroku databases is almost as simple as if they were running locally.
$ java -jar my-example-service/target/my-example-service-0.1-SNAPSHOT.jar db migrate my-example-service/config-heroku.yml
Want to drop everything.
$ java -jar my-example-service/target/my-example-service-0.1-SNAPSHOT.jar db drop-all –confirm-delete-everything my-example-service/config-heroku.yml
Using Git Flow?
If you’re accustomed to using git-flow, you will frequently want to push feature branches to Heroku.
It’s simple.
$ git push heroku feature/BRANCH_NAME:master
This will allow you to test and deploy a non-master branch in your staging environment.
Have further questions? I’ve been running Dropwizard apps in Heroku for awhile now, ping me via Twitter.
19 Jan 2013
I’ve written previously on running better retrospectives in agile environments, in this post I’m going to pull back a level and share some thoughts on planning and executing the sprint itself.
Firstly, it’s important that each sprint is of a consistent duration (2 or 3 weeks has worked best in my experience, 1 week may work but require a very experienced team with often unrealistic focus — oftentimes this is not possible despite the best intentions of all involved) and has a steady resource allocation.
It’s well known that cohesive teams having spent time productively working together (meaning they’ve shipped software together) will almost always outperform a brand new team. This is why companies like Zappos and Google continue to invest significantly in the culture of their organizations, it’s not just lip service. Note, it’s certainly not just the big companies that place high importance on culture development.
The likelihood of a successful sprint increases dramatically when planning starts prior to Day 1. Personally, I’ve always preferred a 2 week sprint that starts on a Wednesday and completes on a Tuesday.
Important Dates
Day 1 .5-1h Sprint Kick-off
Day 6 1h Estimation Session (may be done in smaller groups)
Day 7 1h-2h Commitment Freeze + Test Day
Day 8 1h Sprint Planning for Next Sprint
Day 8-10 ?? Bug Fixing + Release Preparation + Next Sprint Design
Day 10 ?? Roll-in + Wrap-up + Retrospective
The reason to start/end mid-week is simple, it avoids the rush and panic that inevitably occurs when your sprint ends of a Friday. By targeting Tuesday, it gives the team a small break before coming back and putting 2 days of focused effort into getting software ready for a potential release.
In terms of meetings, they are unfortunately an inevitable consequence of team-based software development. Regardless of whether you’re doing scrum, lean, agile or some combination thereof, you need to spend time face-to-face ensuring that everyone’s on the same page and appropriate progress is being made.
The Sprint Kick-off is an opportunity for the team to get together first thing on Day 1 of a new sprint. The stories being pulled in to the sprint should not be a surprise to anyone and this session should be a final opportunity to weigh reality and commitments. Leave this meeting with a plan (identify the critical path, who’s on it, and what the milestones are).
The Estimation Session is an opportunity to meet and discuss up-coming stories in the backlog. It’s always a good sign if you have at least a rough estimate on all stories, at least a sprint ahead. Stories with large estimates warrant additional discussion, breakdown and re-estimation before even being considered appropriate for sprint commitment.
The Test Day (or what the hell is going to be ready to ship next week) is the target for developers to lock down their feature sets and changes. If your environment is conducive to test days (essentially getting the team focused on manually walkthrough changed aspects of the software for 1-2hr) then they’re worthwhile. The test day certainly does not replace automated unit, integration and even regression tests… they more address the almost certainty that not all aspects of an application can be adequately automated.
It’s worthwhile noting that the Test Day will almost always identify bugs or necessary enhancements. These must be prioritized, and often may result in lower priority tasks (that aren’t done) being moved to the next sprint. The reason why we do all-hands testing on Day 7, is that it provides 2 or 3 days of time to address issues prior to release.
The Sprint Planning session occurs on the Friday after Test Day and ideally a few days before the planned sprint completion date. By occurring after test / commitment day, you have an indication of how much effort is remaining and what may need to slide to the following sprint.
The final couple days in a sprint should be spent on polish and bug fixes. If there are large stories in the subsequent sprint, considering finding time to do more detailed design, breakdown and more granular estimation. At times, I’ve seen various rules around the maximum size of taskable work, say no tasks larger than 2 or 3 days are worked on. Every team is different, but I’ve seen this be successful.
However avoid falling into the trap of tasks that look like “Implement XYZ”, “Test XYZ”. They are one and the same, and I’m sorry, but an implementation task is not completed until it’s tested. Depending on system complexity, splitting out a small task targeted at regression testing may be allowable at times.
Lastly, the Sprint Retrospective is a critical opportunity for the team to reflect on their past two weeks of effort. See my previous post for some thoughts on effective retrospectives. TL;DR: Retrospectives must be focused, and action items must be written down and made front and center throughout subsequent sprints. Give them a spot on your white board and visually track progress against them.
IMO, you should be able to run productive sprints without feeling like you spent half of it in a meeting room. Aiming for < 2 or 3hrs of meetings a week would be spectacular.
What Happens Each Day
Daily stand ups. Nothing major just avoid just retelling what you did yesterday. Individually, we should know how close to completion we are and whether our milestones are on-track. If things aren’t on-track or you need help, bring it up and have a discussion about it after the stand-up.
If tasks aren’t moving across the board (not-started -> in-progress -> done / qa’d -> ready for release), discuss it. By keeping tasks to no more than 2 or 3 days, you should see tasks movement almost every day. This is critically important for the team lead or manager to stay on top of, it’s ultimately their responsibility to ensure that the teams commitments are being delivered.
Adaptations
There are many different ways to modify the timeline I’ve outlined above, with the most obvious being to extend it to 3 weeks.
With a longer sprint, you’ll need to invest a little more time in sprint planning and estimation. Simply to account for the increased amount of work being committed to in 3 vs. 2 weeks.
It’s also important to consider the time of day that meetings are held (including stand-ups). Involve your team and figure something out that isn’t going to adversely impact productivity or morale. Consider meeting free afternoons (or mornings) to eliminate unnecessary context switches.
That’s it for now.
Feel free to follow me on twitter, @ajordens. I’d love to hear feedback and what’s worked for you. Let’s continue the conversation.