If you’re using kanban in your environment, you probably use a cumulative-flow diagram. It’s a handy tool to track kanban metrics like cycle time and to quickly see bottlenecks. In addition to all the kanban goodness it gives you, it can also double as a timeline that you can use in your retrospectives.

Whether you use a physical version posted on your kanban board (like my current team does) or an electronic one, you can annotate dates with important events, such as when:

• A team member joins or leaves
• An unexpected technical problem surfaces, like a major refactoring or bug
• The team decides to change something about its kanban, like increase a WIP limit

It’s pretty easy to do, especially if you have a physical chart that you update during your standup meeting.

Then, when you have a retrospective, bring the diagram along to help you remember what happened during the period over which you’re retrospecting. If you’re anything like me, you have a hard time remembering what happened beyond yesterday, so it’s handy to have a reference. Having this time-based information will help you make more objective decisions about how to improve, since you won’t be guessing so much as to why your cycle time lengthened over the last week, or why you decided to decrease a WIP limit a month ago.

As a designer, one of the first things I notice is how everyday objects are created in terms of form and function, as my last post on urban design may have shown. This time, I would like to focus on something that I’m sure we have all seen: a common grocery store receipt.

While informational, I would like to take a moment and look at how to possibly redesign this receipt to increase both the usability and readability. Therefore, a challenge was proposed: redesign a standard grocery receipt using all of the same information and elements within two hours. Go.

Contact Information

One of the first things I noticed with our example is that the contact information (e.g., phone number, web address and store manager) is not located in a similar position. Solution? Put it together. Conceptually, this makes sense. If I’m looking for information on an organization, I’m going to look in the same place, regardless of medium.

Price Alignment

Next, I noticed that the alignment of our prices, totals and dollars needed some definition. I chose a left justification because that will allow our products to ‘rest’ directly next to our prices, allowing for a quick comparison and connection. Because products can be short or long in length, this will decrease the impact of the ragged edge created on the right. In addition, it also allows the customer to quickly scan the ‘narrative’ of the transaction.

Other Details

Finally, I grouped the cashier name and required receipt information in the same box because I felt that it was auxiliary to our transaction information. In addition, I also kept the date and time stamp at the bottom of the receipt because it seems that people are quick to look at either the top or bottom for this information.

Before and After

One of the most noticeable differences between the two receipts is simply the use of negative space- a crucial element to the composition of any design. The receipt redesign allows for the eyes to quickly find a focus on the elements of the transaction.

All and all, I used two *comparable* font-families at two font-sizes for each. Thus, there are four total variations for characters on the receipt. In addition, I specifically tried to not use any character not already being used on the receipt. Admittedly, part of the challenge and limitation of this exercise involves the point-of-sales device used to create this receipt. I understand that it may not be technically possible to style an actual receipt to my concept. However, I tried to be mindful of these limitations when considering my redesign.

If you’re interested in more on the design of everyday objects, check out Donald A. Norman’s book on the subject, The Design of Everyday Things.

Tutorial: Getting started with Google Maps on Android

If you’re looking to get started with Google Maps on Android, you’ve come to the right place.  The goal of this tutorial is to have a working Google Map on your emulator in 30 minutes or less.

Here’s what you will need for this tutorial:
1. Eclipse with Android SDK/AVD manager installed
2. Google APIs library downloaded using the SDK/AVD manager

These are the steps we will be covering:
1. creating a Google APIs Android project
2. setting permissions in the manifest
3. obtaining a Google Maps API key
4. using a MapView and a MapActivity
5. look at your Google Map

Step 1: creating a Google APIs Android project

First, if you haven’t done this already, download a Google APIs library using the SDK/AVD manager and create an AVD (an Android emulator instance) that uses this library.

If you are creating a new project, then select  File -> New -> Project -> Android -> Android Project.  Choose a Google APIs build target and finish creating your new project.  Run your new project as an Android Application and you should see the familiar “Hello World, <project name>” display on your emulator.

If you are adding the map to an existing project, click on the project and select
Properties -> Android -> then select a Google APIs as your build target

Step 2: setting permissions in the manifest

We are now ready to add two important settings to the project manifest: a usage setting for the Google APIs library and an internet access permission.

The first setting will allow your application to use the Google APIs library.  To edit the manifest, you can either use the built in GUI editor, or manually edit the raw xml.
To add this setting using the GUI editor, go to the Application tab, click add.., Uses Library, and select com.google.android.maps in the name drop down.
To add this setting manually, add
<uses-library android:name=”com.google.android.maps”/>
under the application tag.

The second setting will give your application permission to access the internet.
To add this setting using the GUI editor, go to the Permissions tab, click add.., Uses Permission, and select android.permission.INTERNET.
To add this setting manually, add
<uses-permission android:name=”android.permission.INTERNET” />
under the manifest tag.

Here is an illustration of how your manifest should look when you are done:

<manifest>
<application>
<some other stuff/>
<uses-library android:name=”com.google.android.maps”/>
</application>
<some other stuff/>
<uses-permission android:name=”android.permission.INTERNET” />
</manifest>

Step 3: obtaining a Google Maps API key

This is the most difficult step, and will take a little bit of time.  First, you should understand that when you compile an APK (Android package) and push it to an Android device (even your emulator) it is signed with a certificate.  You will need to retrieve the MD5 fingerprint from this certificate to sign up for an API key.  If you google for “android google maps api key sign up” you should be able to find the Google’s Map API Key sign up page without too much trouble. Their page will provide a brief explanation of this entire process.

To get started, you will need to find the certificate you are using to sign your application.  If you have not added your own keystore, you are likely using a debug keystore.  To see where this keystore is located, go to Eclipse -> Preferences -> Android -> Build -> and you will see the location under Default debug keystore.
Once you have this information, in Linux simply run

keytool -list -keystore <your keystore location>
any names and passwords it asks for will be: android

In Windows, you will probably want to use the keytool.exe provided with Java.  You may get an error if keytool is not in your Windows path. Either add it to your path or run keytool directly from the bin directory in your Java folder.

If done correctly, you should see something like:
Certificate fingerprint (MD5): 94:1E:43:49:87:73:BB:E6:A6:88:D7:20:F1:8E:B5:98

Now, copy 94:1E:43:49:87:73:BB:E6:A6:88:D7:20:F1:8E:B5:98 or whatever your MD5 fingerprint is (should be different) and paste it into google’s sign up box.  You will need a google account to get your key.  Google will give you a success screen with your key and a code snippet that look like this-

Your key is:
0AuNnVn-pYluVNgxpSs6ZD_Cy9KZXMA-qdhbTzA

Here is an example xml layout:
<com.google.android.maps.MapView
android:layout_width=”fill_parent”
android:layout_height=”fill_parent”
android:apiKey=”0AuNnVn-pYluVNgxpSs6ZD_Cy9KZXMA-qdhbTzA”
/>

Step 4: using a MapView and a MapActivity

Now, the final step.  If you created a new project for this tutorial, you can add the MapView code snippet above to the Linear Layout in your main.xml.  Make sure to replace the API Key in the above snippet with your own API Key.  It should look something like this:

<?xml version=”1.0″ encoding=”utf-8″?>
<LinearLayout xmlns:android=”http://schemas.android.com/apk/res/android”
android:orientation=”vertical”
android:layout_width=”fill_parent”
android:layout_height=”fill_parent”
>
<com.google.android.maps.MapView
android:layout_width=”fill_parent”
android:layout_height=”fill_parent”
android:apiKey=”YOUR API KEY GOES HERE”
/>
</LinearLayout>

Otherwise, simply add this MapView to any other layout like normal.

Last but not least, update the Activity displaying your MapView layout.  Instead of extending Activity, your class should now extend MapActivity. That’s it. You’re done.

Step 5: look at your Google Map

Launch your application.  You should see a map of the United States zoomed out really far.  If instead you get a force close error, make sure you correctly added the Google APIs library setting in Step 2.  If you only see a white grid it could be one of many things.  You could be having an internet outage, you incorrectly added the internet permissions from Step 2, you have an incorrect API Key, or you forgot to use your API Key.  A lot of things can go wrong here.  If things didn’t work out you aren’t the first. Keep trying and don’t give up.

If everything is working, then congratulations and have fun playing with your new Google Map on Android. There are a plethora of other tutorials online to help you take it from here!

Software projects very rarely both come in on time and on budget and satisfy their end users. It’s much easier to satisfy one of the above conditions, either working according to your original plan or adapting to the changing needs of your users. Satisfying both requires a certain amount of prescience. Demarco and Lister list Schedule Flaws as one of their 5 Risks of Software Project Management. In this article, we’ll discuss several symptoms and causes of schedule flaws, present metrics and diagrams that can be used to track your team’s progress against its schedule, and describe Agile ways to address this risk.

Read More of This Post

Whole-team approach — the agile practice in which the entire team works as a unit of generalizing specialists to share responsibility for producing high-quality software — can yield powerful benefits like lowering risk to delivery, improving velocity/cycle time, producing better ideas and reducing defects and other waste. Like other agile practices, though, whole-team approach requires discipline and diligence. So here are a few “smells” that might indicate that you’re not optimally practicing whole-team approach, along with some possible remedies.

Read more of this post

After ten years of self-analysis and continuous improvement, Asynchrony’s software development practices have been validated through the awarding of the Capability Maturity Model Integration (CMMI) Maturity Level 2 earlier this year; we are now embarking on the CMMI Level 3 assessment.

At Asynchrony, we have been using Agile methodologies for over ten years.  The maturity of our Agile processes reflects incorporation of industry best practices, continuous introspection by our development teams, and a commitment of our company’s leadership to identifying and integrating standard agile processes across our development teams.  From the start of our company, we have always understood the importance of effective development processes in ensuring the quality and reducing risk associated with the commitments we make to our customers.  The very bright software developers in our organization (which we view as a prerequisite to delivering great software) are able to consistently deliver game-changing solutions by wrapping themselves within our agile/lean methodology.

As agile was emerging as a best practice at the turn of the century, Asynchrony was an early adopter. Our CTO, Nate McKie, was the primary architect who figured out how to apply the basic tenets of agile to our growing company.  Initially, we had many challenges, including convincing our own developers that things like pair programming, test driven development and continuous integration could enable operational capabilities to be delivered every few weeks.  Likewise, we had to convince our customers that Agile was not risky and that, in fact, it was significantly more dependable and effective than the traditional waterfall development methodologies that were so much in vogue at the time.

Public sentiment has really come around on this one.  Today, Agile is the preferred approach to delivering software for the Department of Defense, according to multiple recent studies and publications – even to the extent that the 2010 Defense Authorization Budget included the following language:  The Secretary of Defense shall develop and implement a new acquisition process for information technology systems. The acquisition process developed and implemented pursuant to this subsection shall, to the extent determined appropriate by the Secretary—

be designed to include—

(A) early and continual involvement of the user;

(B) multiple, rapidly executed increments or releases of capability;

(C) early, successive prototyping to support an evolutionary approach; and

(D) a modular, open-systems approach.

Sounds a lot like Agile!

As we tried to improve our basic development processes, we started sending all of our developers to training in Agile and Test Driven Development.  In 2006, after we sent most of our people through Brian Button’s agile training classes, Brian joined Asynchrony, bringing us one of the leading agile trainers and gurus in the St. Louis area.  With Brian and Nate leading the way, we continued to refine our approach to agile, working to standardize certain agile practices (e.g. retrospectives, SCRUM, refactoring) within all of our teams.  Over time, we moved to weekly iterations, daily (and multi-day) swapping of programming pairs, and incorporation of certain standard metrics into our vocabulary (it still is heartening when a customer will explain to me what an XPU – extreme programming unit – means).  And over the last year or two, almost all of our larger teams began adopting the use of kanban boards and lean concepts with continuous iterations and throughput of a story becoming standard metrics.

This year, Asynchrony was evaluated for CMMI Level 2 by Hillel Glazer, the founder, Principal and CEO of Entinex, Inc.  (http://www.entinex.com/). Hillel is a certified appraiser by the Software Engineering Institute (SEI) and evaluated Asynchrony under the SEI guidelines.  Our assessment at CMMI Level 2 was the first time Hillel had heard of using kanban to achieve CMMI Maturity Level 2.

We achieved this rating very quickly.  When we started the process in January 2010, we just wanted to gauge how our software development compared to CMMI. As it turned out, we didn’t have to make many improvements or changes.  We were already close to the CMMI Maturity Level 2 rating from the outset based on ten years of practicing the agile principles of self-analysis and iterative improvement.

At Asynchrony, the ease of adapting our existing processes to CMMI’s model rested on the identification of patterns that, for the most part, we already had in existence, which aligned with the CMMI areas.  The critical thing the CMMI process added to our way of doing business is the conscious assessment of how these key patterns apply to each project and the documentation of such assessments.  The resulting artifacts help our customers understand the operational decisions we make, and also each new team member that joins the team during a project has access to this shared understanding of the teams’ standard processes.

See http://www.agilecmmi.com/index.php/2010/05/truly-agile-cmmi/ for Hillel’s post and video of our path to certification.

Achieving CMMI Maturity Level 2 is a testament to Asynchrony’s innovation, expertise, and leadership in software development  and acknowledges our ability to meet the standards put forth by the Department of Defense, federal government agencies, and U.S. military.  Government procurements increasingly look to CMMI as a discriminator among companies as they assess competitive bids.  Government and DOD procurements are starting to require Agile methodologies as a preferred approach for delivering software.  I am hopeful that the Government will recognize the increased relevance of CMMI Mature processes on Agile development projects if the Maturity assessment is actually based on the agile software methodologies that will be utilized on the projects.

We are now getting our arms around CMMI Level 3 processes, and I am confident we will both be successfully appraised, and also continue to learn about how we can do things better by going through the process.  Stay tuned!

In a recent retrospective, our team identified a lack of satisfaction in our standup meetings. Some days they provided too much information; other days, not enough. Our meetings lacked a certain energy. Brian Button suggested a way for each of us measure our satisfaction with the standup meeting.

To do this, we posted a big visible chart in the war room where team members could mark down how they felt about the standup on a particular day. At the conclusion of each standup, everyone attending was asked to make a tic mark on the spectrum (see picture below) to rate their satisfaction with the standup. We stacked a couple of weeks worth of lines onto a single chart, so we could easily see trends between meetings. The chart served as a way to encourage conversation about the standup. A few days each week, we looked at the chart collectively, encouraging one another to explain why certain standups were better or worse than others. We continued to track the satisfaction level until we felt we regained the energy we desired.

A highlight of 2010 at Asynchrony Solutions for me was hosting the state FFA officer teams from Kansas and Nebraska. The teams are composed of college students elected by their peers to serve a one-year leadership term. The purpose of their visit was to teach them about retrospectives by creating a workshop filled with retrospective activities they participated in as a team.

After the visit, I received a pile of mail from our guests, thanking Asynchrony for the experience. Below are highlights from the notes that really stood out to me, as they encapsulate what I love about Asynchrony:

“I really enjoyed learning about your company and taking a tour. Your work environment was very casual and interesting. I understand how beneficial it really is.”

“I found it intriguing how employees at Asynchrony work together similar to a team. It made me think how useful the skills I am learning will help me in the future.”

“It was a great time for growth and honesty for our team.”

“Thank you so much for taking us on a tour through your software company. It was such a different atmosphere than anything I have ever seen! It looks so much more fun and productive.”

“Thank you for challenging our teamwork and for having us look at different situations from different angles.”

Asynchrony was honored to be a Platinum Sponsor for the DoD Agile Development conference held in Alexandria, VA on December 14th. Our CTO, Nate McKie, participated on the Ask the Experts panel, and several Asynchrony team members also attended.

Nearly 200 participants from government and industry spent the day examining the Agile model, who is using it, why it is being adopted, and how to incorporate it into DoD programs. Agile software development is key to helping the DoD achieve state of the art information capabilities, but DoD acquisition process must be transformed in order to acquire and deliver the best IT capabilities.

New approaches require new principles, such as:

* Speed and Agility
* Incremental Development and Testing
* Rationalized Requirements
* Flexible/Tailored Acquisitions

Agile methods embrace these principles and are gaining momentum in DoD, both in infrastructure and application development. Agility provides increased opportunity for innovation, and innovation results in better capabilities with quicker delivery and lower cost.

Stay tuned for more information regarding the next Agile conference.