On March 26th I attended the Cincinnati Day of Agile conference.  It was nine hours and three tracks of talks and discussions about using Agile practices to build software.  The first track focused on introducing Agile concepts and techniques while track two was more about “soft” skills and getting the most out of Agile.  Track three was mostly an open space type track.  Despite still being a relative n00b to Agile I spent my day bouncing between tracks two and three.  What follows are my notes and thoughts from the sessions I attended.

Keynote: Agile Looking Glass

Presented By: Joel Semeniuk

Joel’s keynote was a great way to start the day and was really one of the highlights of the event.  Along with his experience and insight Joel brought a ton of energy and excitement to the conference.  This session briefly looked at where Agile came from and why an increasing number of teams are adopting a variety of Agile practices.  After establishing that foundation Joel spent some time discussing some of the problems with Agile, both perceived and actual, and how we can address them.  Finally, he gave some predictions for how Agile will continue to evolve.

More than a few highlights:

In today’s world software is all around us and is constantly increasing in complexity.  Despite the prevalence of software in our lives there are very few standards for building it.  Ten years ago the Agile Manifesto was written in an attempt to bring order to the chaos.  Research has shown that adopting Agile practices, typically starting with Scrum, has had a positive impact on costs and organizational growth among other factors.  One of the main aspects of Agile is making teams work effectively but despite that goal some teams are still hesitant to abandon their traditional waterfall model.

One of the reasons some teams don’t adopt Agile practices is that the term “Agile” has been abused.  Many of the abuses are due to misunderstanding or misinterpretation of the principles.  For example, people have twisted the idea of waiting until the last responsible moment to do something (like documentation) into not doing it at all.  Even teams that are trying to adopt Agile practices though can run into roadblocks.

Adopting Agile properly isn’t simply a matter of stating “we’re Agile!”  Instead it requires thought, planning, and brings the thing people fear the most – change.  Just getting started can be one of the hardest parts for a team.  Beyond getting started though a team can encounter other issues such as:

• Communicating with stakeholders in this “new” Agile language
• Scaling
  • How does Agile scale for distributed teams?
  • How does Agile scale across teams or organizations?

One of the ways to overcome these problems that Joel discussed is to borrow and adapt a concept from the manufacturing world – lean manufacturing.  In many ways the goals of lean and Agile overlap.  It has even been said that Agile works because of lean.

…agile is an engineering method by which code is written, and lean is the process by which to do it, and they dovetail into each other.
Fred George, ThoughtWorks

Lean software development is built around seven principles:

1. Eliminating waste
2. Building quality in
3. Knowledge creation
4. Commitment deferral
5. Fast delivery
6. Respect
7. Optimizing the whole

One of the ways we can bring directly from lean manufacturing is kanban.  Kanban is all about getting things done and supports the seven principles by grouping work into swim lanes and giving status at a glance.  Joel’s example kanban board included five lanes:

1. Next
2. Analysis
3. Development
4. Acceptance
5. Production

In addition to using ideas from lean manufacturing Joel also recommends mixing methodologies in what he referred to as “buffet style,” where we pick and choose the pieces of two or more techniques.  For example, when Scrum doesn’t tell us how to do something XP may.  The key to this though is to start with one methodology and get good at it before “going back to the buffet” to get more.  Until you really know what you have (or don’t have) with your chosen methodology there’s no need to introduce waste with something you might not need.

One of the ways teams and, by extension, organizations can become more Agile is to implement an Application Lifecycle Management system.

Application Lifecycle Management (ALM) is a continuous process of managing the life of an application through governance, development and maintenance. ALM is the marriage of business management to software engineering made possible by tools that facilitate and integrate requirements management, architecture, coding, testing, tracking, and release management.
Wikipedia

As stated in the definition, a properly implemented (and used) ALM system can add visibility into a project by tying together the various aspects of a project from inception to completion.

Another trend in the Agile community is toward Behavior Driven Development (BDD).

BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.
Wikipedia

BDD expands upon unit testing by describing a series of behaviors that express preconditions, actions, and postconditions in a readable format.  One popular language used in BDD is Gherkin.  Gherkin follows a Given – When – Then syntax to describe the behaviors and tools such as Cucumber and SpecFlow parse it.

These points were brought back to a single concept: software craftsmanship.  Software craftsmanship (SC) compliments and expands upon Agile in a few key ways.  Where Agile values working software over comprehensive documentation, SC emphasises “well-crafted” software.  Where Agile values individuals and interactions, SC also values professionalism.  In all, SC is an important step forward for the software development community.

Finally, Joel wrapped up with some predictions for the future of Agile.  Given the topics he covered there weren’t really any surprises here.  Mainly he expects to see:

• More lean influence including kanban
• Scrum and XP continuing to take center stage
• An increase in BDD
• An evolution of software craftsmanship
• An increase in Agile testing

Missing Pieces: The Road from Agile Enthusiast to Agile Team Member

Presented By: Ryan Cromwell

Missing Pieces was the second session I attended.  This session was about some of the “ingredients” (as Ryan referred to them) for a successful team.  I found this session useful but as another attendee tweeted, most of the tips are applicable to virtually any type of relationship.

Respect

Team members must have respect for each other.  Without respect none of the other ingredients will recognize their full potential.

Courage

Team members must have the courage to ask and act.

Silence

I think this tip needs a new name.  The spirit of it isn’t so much environmental silence as it is to promote communication.

When part of the team is more vocal than another it’s likely that some ideas or problems aren’t being aired.  Silence involves quieting the more vocal team members to a level where the less vocal team members feel comfortable expressing their views.

Experimentation

Teams should have the freedom to try new things.  Done properly experimentation is an iterative process where experiments are inspected and adapted for more experimentation.  When teams are free to experiment they will often find new and better ways to solve problems and add value to the business.

Openness

Openness plays directly to one of Agile’s key concepts: transparency.  Openness (and experimentation) encourages us to find creative ways to tell people what we’re doing.

Seven Habits of Highly Effective Chickens

Presented By: Rob Keefer

Even though I was one of the many pigs in the room the Seven Habits session was easily one of my favorites for the day and was a good way to build upon the Missing Pieces session.  In this session Rob discussed a variety of ways in which chickens can not only effectively get the information they need but also enable their teams.  After presenting the seven habits Rob also gave a few tips for pigs to help their chickens.  One thing that really encouraged me after attending this session is how many things my chickens are already doing.

Attend Daily Scrum

Chickens (especially managers) should quietly attend the daily stand-up meetings.  While at the stand-up chickens should observe that team members are engaged and providing informative status updates including obstacles.  Should a chicken need clarification s/he should wait until the end of the meeting to ask questions and most important – avoid hijacking the meeting.

Note Story Flow

When developing user stories chickens should take care to make sure that no story takes longer than five days.  When assigning stories chickens should make sure that no developer has more than two stories at a time.  Perhaps even more important though is to make sure that everyone has a clear understanding of what “done” means.

Focus on a Specific Goal

One of the first things that chickens should do is write a concise release mission statement.  The mission statement will aid in getting everyone to work toward the same common goal.  To help keep everyone involved working toward that goal chickens (particularly managers) should resist the urge to pull team members off the project or have team members follow tangents.

Encourage a Constant Velocity

Velocity should be measured for each team on each project but chickens should be aware that teams need time (approximately three sprints) to calibrate and optimize.  Just as with focusing on a specific goal chickens should resist the urge to change the team because every change to the team structure will change the dynamics of the team and require recalibration.

Chickens can help with optimizing velocity though by considering some team dynamics.  Are the right people with the right skills on the team?  Does everyone on the team “play nicely” with each other?  Are there any environmental issues (interruptions, noise, etc…) that cause disruption?  The answers to these questions can greatly impact velocity so answering them and addressing any issues early and addressing any issues is critical to project success.

Win Early, Win Often

Team morale will play a big role in the project’s success.  An easy way to build morale early is to initially set low goals (during optimization is a great time) to build the team’s confidence as the goals are met.

Promote Continuous Learning

Keeping team members’ skills current is critical to staying competitive so chickens should encourage continuous learning.  Some easy ways to encourage continuous learning are to promote study groups, make continuous learning a performance objective, and ensure that retrospectives are taking place.

Support the Team

The amount of support for the team that chickens show can have a huge impact on the project.  Chickens should seek to understand as much as possible about the team’s concerns and help address issues as appropriate.  Supporting the team isn’t just about helping address issues though, it also involves promoting the project and the team by talking about both the progress of the project and the team’s accomplishments.

What Can Pigs Do?

This may sound like a lot of work for the chickens but there are a few things that the pigs can do to help them.  Like everything else in Agile, communication is key.  Pigs should be as transparent as possible by making it a point to provide informative updates in daily stand-up and weekly status meetings.  Pigs should also be communicating the results of retrospectives as appropriate.

Hands on Workshop

Facilitated By: Mark Windholtz

When I first read the abstract for this session I thought it would be perfect for me to get some good first hand experience with a simulated Agile project.  The workshop was mainly playing the XP Game.  Some of the things that the XP Game aims to teach are velocity, story estimation techniques, and iteration planning.  Generally speaking I think the experience was valuable but overall I thought the workshop was disorganized and drawn out.  After two iterations (and hours) I felt like I had a good high-level feel for the core concepts that the game was trying to instill so I moved on to another session.  In retrospect I really wish I had attended the “Agile is Just a Word” and “Make Distributed Teams Work (Effectively, Even!)” sessions instead.

A couple of interesting points that came out of the time I spent in this session were:

• Iteration Zero – a preliminary iteration used for setting up the project
• Yesterday’s Weather – What we did last time is a good predictor of what we’ll do this time

High Performance Workspaces

Presented By: Sean Heuer

The last session of the day was about making high performance workspaces.  I have to admit that my notes from this session aren’t very good because by this point I was dead tired and starting to think about my two hour drive home.  That, and a lot of the slides were really text-heavy.

A high performance workspace (HPW) is a physical or virtual environment designed to make workers as effective as possible.  Among other things HPWs:

• encourage free-flowing communication and collaboration through information radiators and the cocktail party effect
• are optimized for increased productivity by being adaptable while reducing distractions thereby increasing the quality of work

Some key components of a HPW are areas for impromptu meetings, pairing, availability of personal space, controlled environmental issues (lighting, temperature, etc…), and ergonomic equipment.

Despite the benefits that HPWs offer implementing them may not be easy.  Moving to HPWs requires change and some team members may be reluctant to leave their cubicles.  Furthermore, HPWs require space that may not be available or not permitted by facilities.  Even with the complications though teams can recognize some of the benefits by moving to a dedicated group of cubicles – if the walls can be replaced with half walls this will work even better.  If all else fails, simply buying (and using) more whiteboards can be a first step toward improving communication.