Share it

Tuesday, July 29, 2014

More Agile smells


"Agile" means many things - there are Agile processes, Agile values, Agile ways of working together as a team.  Becoming truly Agile requires a lot of education, willingness to keep an open mind, and lots of trust within the organization. 

When things are less than perfect, as they usually are, many teams get to experience "an Agile smell". Agile smell, similarly to code smell, is not necessarily a problem by itself, but rather a likely indicator of a serious problem with the team’s implementation of Agile.  

Learn to identify Agile smells, and the problems that may lead to them. Then get busy fixing the problems.

Smells "Our KPIs measure the wrong thing"
  • Team talks about velocity points, rather than discuss stories and value created
  • Members worry about being busy and putting in hours, rather than about producing valuable results
  • The team strives to meet arbitrary deadlines, rather than focus on delivering quality working software
It is tempting to measure the team's success by velocity points archived, hours worked, or hitting deadlines. But velocity points are imaginary and unequal units, that differ from team to team, and even for the same team over time. They are too easy to game.  Same with deadlines - deadlines are derived from imperfect estimates, and hitting those deadlines causes loss of quality and team spirit. Hours worked is straight-forward to measure, but has little correlation with value delivered. 

Smells "We are not using our tools well"
  • The information in the tool is treated as the source of higher truth, rather than a starting point for a conversation
  • Fill out the fields by the letter of the rules, rather than store useful information in an easy-to-understand format
  • Use the tool insofar as the process requires it, but are uncurious about better ways a tool can help us improve
Tools are there to serve the team. They help to compile information over time, store details, and offer a choice of presentation layouts. Tools are not there to drive the team's value, do the work of coordinating and facilitating communication, resolve issues. It is OK to tweak the rules imposed over a tool usage, if it helps the team to work smarter. It is not OK to be a servant to the tool, rather than its master. 

Smells "We are not being awesome"
  • Compile excuses why we are not doing a good job, rather than look for a better way to work
  • Look for ways to make Agile process entertaining, rather than focus on the excitement of delivering great software
  • Build Chinese walls between specialties, Agile team members and their responsibilities, rather than work together 
IT and software development is complex and complicated work. Every team that works hard and strives for success is going to make mistakes sometimes - and that's OK. In fact, it is good, because the only way to not make mistakes is to play it safe, aspire to little, and settle for less.
But it is important to admit and examine problems, take responsibility, and prepare to do better in the future. And have fun while doing it.  

This is a second post in the series on Agile smells.  Read the first part here


Wednesday, July 23, 2014

Empowering Agile teams: culture clash

"The test of a first-rate intelligence is the ability 
to hold two opposing ideas in mind at the same
 time and still retain the ability to function." 
- F. Scott Fitzgerald

Agile frameworks empathize empowered teams, flat structures, and meritocracy. Team members and those in supporting roles are expected to earn trust and respect, rather than get authority based on org chart.

Organizations in general do not work this way. A modern organization is all about hierarchy, where authority comes from one’s position and place on the chart. Responsibility and decisions each travel in exactly one direction in the hierarchy: decisions come down, responsibility goes up.  This kind of structure is easy to manage from the top. But it does not lead to best decisions.

An Agile team is encouraged to take control of, and responsibility for, their own work, but it comes in direct conflict with the not-so-Agile organizational structure. Entire corporate cultures are built around deferring to someone with a higher title. Those cultures do not disappear when an authority figure up the hierarchy decides that some projects should try Agile.

People on an Agile team are taught to care about producing value, make their own decisions, and take responsibility – but for employees with years of experience in traditional organizations it is not easy to accept this kind of message at face value.  It is even harder if Agile has a narrow mandate, for example, when transformation is happening only in a small part of organization.

This cultural shift is the hardest and the most painful part of a large-company Agile transformation.  It is also the most valuable change a business can make to improve its culture.


Thursday, July 17, 2014

Everybody wants a pony


In a recent conversation, a colleague mentioned that a project his team worked on was considered a failure. That surprised me. I heard that this team delivered a high-quality product; the software quickly went into production, and has been delighting users for some time now. 
Turns out, when the team first got started on a project, it came with a specification document and a deadline. As the work proceeded, the team was learning more about the project. A number of features were added based on conversations with stakeholders and organizational knowledge, other features described in the specification document were cut. Technical complexity was uncovered, and eventually conquered.  The team iteratively delivered the system for stakeholder review, each time presenting more functionality, and at some point it was decided that the software is ready to go into production. 

Well, as it happened, for this particular project the production release date was after the original deadline set on the project, back when the project consisted only of a specification document and that deadline. Therefore, the deadline was declared missed, and the project was declared a failure. 

I find this mind-boggling.  Before anything was known about a project except that there is software to be built, there was this random date.  Now, that the world moved forward, the project came into existence as a working, helpful system that delights users and produces real, tangible value for the organization. Yet, somehow, that original date is still the deciding factor whether the project succeeded.  Conforming to this picked-before-we-knew-anything-important date is more important than whether the project was delivered at all, whether it useful, or valuable, or makes users happy and productive.

It's understandable that people and businesses want a pony – projects that are predictable enough to be able to forecast completion date, scope, and user satisfaction ahead of time.  In practice, most of software development work happens on complex projects, with a lot of unknowns, where information is uncovered gradually as more work is done.  There is a very little chance that any given project is a pony. More likely it is a zebra, with a variety of stripes, and lots of unpredictability.