Channels ▼


An Agilist In the Rough

Leading By Example

Influencing your team towards agile requires practicing agile as much as possible in your own process. When teammates realize that there is something different about the way that you work they will take notice. Your co-workers may be shocked by a team member that only put in 8 hours work a day. They may think that spending time on unit-testing is taking away from hours that can be spent coding. These actions have a direct and positive effect on the quality of your code and the level of creativity you put into your decisions but results are far from immediate. Your co-workers may feel that if they don't burn the midnight oil every night the project will fail. This is unsustainable because as they work later they make fewer good decisions and extend the time it will take to write code that is free of bugs and ready to be used by customers. Ideally, this will give you an opportunity to show the difference in your results and the results of your teammates that have been coding on a treadmill set at top speed for two weeks straight. Priorities can change throughout the sprint so make sure your priorities are reassessed by your product owner or project manager before taking on your next task.

Leave room for failure and be ready to take responsibility when you make a mistake. If the idea is to get peoples attention with your success, you have to be prepared to get more attention with your failures. If you make a mistake it is important to immediately take responsibility for it and work as quickly as possible to resolve it. Yes, failing gracefully can be as much a selling point as winning. A story comes to mind where a team was asked to deliver a demo which was scheduled for a Friday. They worked all week to add features and polish the interface elements that would get the most visibility. Some members were under so much stress to perform that they worked all night for most of the week adding features while others stayed true to the sustainable pace that Agile prescribes. When Friday arrived, the app failed to run on the demo server. Those who had worked together and were rested were able to get issues resolved quickly and quietly. While the other part of the team failed to get on the same page and resolve their issues in the time available. There is no avoiding mistakes during a project but having the intellectual bandwidth to respond quickly with a resolution is a positive benefit on working at a sustainable pace.

Your co-workers and you will most likely have made the same amount of progress in the same amount of time but the difference in quality will be evident. It is important at each step to be open about your process. People need to see that your successes are not luck but calculated moves. Respectfully discuss how to incorporate your changes of process into the team. If your success is noticed by the team and especially the business, people will want to be involved. You need to consistently be ready to hear other peoples opinions and be ready to use their input to evolve your process into something that everybody will use. Make sure that you are humble because nobody wants to work with a process that has no use for their experience.

Just Keep At It

Progress will take time and it is difficult to know exactly what success will be and when it will happen. Sometimes you will fall into bad habits and get discouraged with the organization. Maybe the business just does not want to stop expecting more in less time. It is inevitable to become discouraged. In my experience discouragement comes before some of by greatest moments of progress. Just keep executing against the most important of your goals so that your successes can have the impact you need to stay motivated. An agile process may never be in the cards for your team but that is not the point. What you want it to enjoy what you do and produce the best results possible. Staying focused on the most appropriate tenets of agile are a great way to make sure your project and you personally develop in the right way.

This work is licensed under the Creative Commons Attribution-Share Alike 3.0 United States License. To view a copy of this license, visit or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.

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.