Channels ▼


An Agilist In the Rough

Eric Gelinas is a software developer at Yahoo!. He also runs, a sandbox and blog highlighting ideas which are too crazy or raw for his day job. Eric is an active member in the YUI community which is part of the Yahoo! Developer Network.

Those of us who practice Agile can't always work on Agile projects. The idealists among us would say that one should hold out for the perfect workplace, where everybody is in the same location. In reality, this would rule out great opportunities. Not all great projects are at start-ups where everybody is in the same location. Some great opportunities are at large companies or have employees distributed globally. If you choose to follow an opportunity on a project with a team that does not practice Agile, there is still hope. Any process can be improved and the journey of making a process better can be an exciting learning experience. The skills that you have learned working with Agile in it's purest form, should not go to waste because they can be a model for where your new project would thrive. Continue learning about Agile as if you had the freedom to practice it as prescribed and apply them to your process in a balanced way. Your goal will be to one day replace all of the weaknesses in your existing process with the strength of the purest form of an agile process.

Agile In It's Purest Form

Honesty is important in an Agile team. We are not honest when we commit to take on more then we can complete. We are not honest when we fail to point out a co-contributors flawed judgment. Daily stand-up and retrospective meetings are there to get the team talking and air out anything that may be in the way of success; even if it is not easy to admit. Honesty is the first step in real shared responsibility. Once you don't feel the need to keep anything from your team, there is nowhere for problems to hide. A team needs to make decisions together. In Agile, we trust that the team unit will manage the workflow within a sprint instead of being dependent on one person to make decisions.

The rhythm of an Agile project could be it's most marketable attribute. Teams will get accustomed to cycles of sprints and over time, their throughput becomes more predictable. Massive project plans with Ghant charts are not suited to predicting the throughput of creative projects and have been letting businesses down for years. The business wants the development team to be more predictable which allows them to properly market and sell. The fact that each iteration will release on a date with or without lesser prioritized features is the best way to make a development project predictable. What is built is determined by what is most important for the business to get at the end of the two weeks. You can't control how much time it will take to create but you can control the order in which the creators take on tasks. Businesses who embrace this will love the results they get from Agile.

Since we software people are creators we need a creative environment. Some of us can't avoid working in a massive cube farm, but that does not have to keep teams from being creative. The flexibility of an Agile project goes a long way in reaching level of creativity needed for success. We all encounter things while developing that are unforeseen in planning. The realization that this can be an opportunity instead of a set back was the first step in me falling in love with Agile. I was working on a new feature. I talked to the designers and product owners and thought I had a pretty good idea of what everybody was expecting. I spent some of my free time prototyping in an attempt to flush out some of the unknowns and was confident that I would be going into my next sprint with every hour accounted. Towards the end of the sprint, I noticed that a component was not behaving as expected and started to worry that resolving this issue would require more hours to fix then I had time. I spent hours that night researching and spinning my wheels with solution after solution. Each attempt to fix the problem was worse then the last because I was tired and stressed. When I came into work the next day and talked to my manager about the issue developing my feature, he simply instructed me to bring up my issue at the stand-up meeting. In the meeting, and as a team, we decided that this feature was not critical to launch. We decided to move forward developing other features and the troubled feature was moved to our backlog as a spike, meaning that the feature required more research. If it had been an important feature, we would have removed other features from the sprint to make room for the time that this issue would take to fix. Suddenly, I went from an unsustainable situation where an indefinite amount of new work was being added to my already committed development sprint. I went from feeling like I was going to fail to feeling creative again. I don't think the project team ever ended up prioritizing this feature to be built, but the immediate release was delivered in high quality.

The freedom to change and reposition requirements is what makes a team agile and really freaks out the business at first. You will notice most hybrid processes that people come up with are intended to avoid allowing this flexibility. A lot of people think that a team will use up as much time as they have and never create any extra feature, only take more and more time until the project fails. Assuming a team is staffed well this should not be the case in an Agile team. Agile manages to remove a lot of the friction of software development and create an environment where developers can have fun. We gather around a scrum board in the morning and share stories about the day before and ask for help when we need some. This board shows, at a glance, our progress and it has been customized with little pithy quotes and funny drawings. When we commit to something on this board we don't want it to fail. The team feel a sense of ownership for this board and we want it to display a successful project. We see people from other areas stopping to glance at our board and read the quotes and giggle at the humor then scratch their heads trying to make sense of the cards and burn-down chart. We are proud of this project and this board and that is the only incentive we need to make it a success.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.