You can read a book about agile development or Google any agile term, and the definition will most likely be in context of an engineering practice or reference to code. The basic concepts in marketing are very similar, but the ways they are implemented can be very different. Below are my translations.
 
Iteration/Sprint – A fixed period of time, usually 1-4 weeks, in which work is planned, managed and delivered. Agile teams commit to working on a set of prioritized stories and nothing else during this time period – nice in theory, not always possible in practice, especially in marketing.  In order to manage fire drills or other work, you can do one of two things – build time into your iteration, or get very disciplined at saying "We'll put it in the backlog".

Backlog – Prioritized list of work items (stories) not currently scheduled into the iteration. As you well know, marketing priorities are often changing (monthly, weekly, even daily) so backlog management can be challenging.

Story/Backlog Item /Feature – Most often in agile software development, it's code that delivers specific functionality and provides business value (What is a feature?). In marketing, the idea of business value still applies, but often times is thought of in terms of deliverables – collateral, online content, events, ads, etc.

User Story – A way to define a story from the perspective of the end user. The typical format is “As a (user) I want (requirement) so that (goal)”. This format works well to describe feature/functionality in software development practices, but we haven’t found it as useful on our marketing team. We structure our stories based on define, design or deploy phases (more to come on this later).

Estimation – The process teams use to determine the size of a story, usually through Story Points, ideal days or t-shirt sizes (small, medium, large, extra-large). The work associated with a story must be well defined/understood in order to accurately estimate. Keep in mind who outside of the marketing team is involved with a story -- even though you don’t include their time in the estimate, these stories usually take more time/effort.

Story Point – A unit of measurement used to estimate the work/effort/complexity of a story in order to give it a comparable size. Typically a 1 is twice as big as a 2 in terms of complexity. The challenge in marketing is that some stories might be “easy” but take a long time and others might be “hard” but not take very much time (more on this one too).

Task – The small, individual work items that comprise a story. Typical tasks in marketing include brainstorming, outlining, drafting, feedback loops, proofing, dry runs, pushing live, sending out.

Taskboard – A visual information radiator which is a fancy name for a whiteboard (physical or online), or wall chart with index cards, or sticky notes to track the status of tasks. Have fun creating a taskboard, but don’t over think it.

Defect – In agile software development, a defect or bug refers to an unexpected behavior in a feature often caused by a problem with the code. In marketing, defects are more likely to come in the form of typos, broken links, unclear messaging, etc.

Impediment – Anything that prevents agile teams from getting their work done. Common marketing impediments include too much feedback (often unsolicited), budget constraints, outside vendors and external dependencies.

Done – This deserves its own post (or even series of posts), but for now, done means that the tasks required to deliver the agreed upon value of a story are completed and the product owner has accepted the story. Life is much easier when done is defined at the time the story is planned and estimated.

These are only a few agile terms you’ll need to (re)define for a successful agile implementation in marketing. Have your own software-to-marketing agile translations? Please share.
 

I remember the first time I drove a car on a race track.  I was hooked, and to this day I am a motorsports fan and occassionally enjoy getting to autocross or driving on race tracks.
 
The basic knowledge of how to become a race car driver is not hard to learn from books and lecture.  I've been to several driving schools.  The hard part is applying all you learn to driving the car on the track with speed and smoothness.  The greatest improvements I've made in my driving have always come when I've had a coach in the car with me, either driving the car for me to observe or as a passenger providing feedback and instruction. There is a reason that professional race car drivers have undergone many hours of professional coaching long be fore they will ever be awarded a racing license.
 
Becoming a competitive race car driver is basically the same same learning model as becoming a doctor or a practitioner in an agile software development organization:

• Training and reading build knowledge
• Applying that knowledge so that the desired outcome can be repeatedly achieved is skill
• Repeated application of that skill in different circumstances forms experience

 This process, unfortunately, is lost on most sponsors who cause one of the biggest agile adoption anti-patterns: Coaching not necessary. This is the idea that one 2-day course or just reading some books will instantly create a set of agile practitioners. It takes time, dedication, experimentation, and most of all, coaching, from an experienced agile coach who is either in-house or external.

Would you trust a lifeguard who received her certification on the Internet based on an online exam and no practice? What about a surgeon who has never had any internships, residencies or hands-on experience? Would you trust him to operate on you? I understand that a newly trained agile developer isn’t going (usually) to kill anyone if they miss an iteration goal or their retrospective goes sour, but the concept is still the same – getting results from an agile transformation takes experienced practitioners. One cannot go directly from knowledge to experience, and one cannot build skills in the classroom. To achieve the desired results from agile teams, it takes time to nurture and grow them, and that includes coaching along the way.

Don’t get me wrong. I’m not out to say that agile practitioners aren’t bright and can’t apply what they have learned in the class or book within their own environment. But consider your unique environment – your corporate culture and the quirks that are yours alone, your current environment, infrastructure, leaders and their leadership style, organizational structure, incentives, and so on. There are so many parts to the makeup of an organization that sometimes it isn’t obvious how to apply what you have learned. A 2-day course (or even a 10-day course) cannot cover all possibilities. And what about scaling agile? The more teams there are (especially distributed teams), the more  challenges the newly trained agilists face. It gets overwhelming, especially for new practitioners.

In addition, please don’t misinterpret my views about classroom time. I have done my share of teaching. I love teaching and I will be the first to point out that classes and books are an essential start. They add the knowledge which is required to start the journey. However, it will never build skills. Application of new knowledge in your own environment will do that. And the more complex the environment, the harder it is to apply that knowledge. Coaching from someone who has done it before and seen many of the pitfalls the team may be headed for, who will work with them to navigate the rocky terrain, teaching them within their own context and arming them with the tools to apply that knowledge to make wise decisions. In essence, the coach’s job is to work themselves out of a job. Repeated application of that skill in different circumstances forms an experienced practitioner who, by the way, is your next agile coach.

Don’t try and save the cost of some coaching and try and get everyone trained instead, thinking this will bring about results. Instead, consider picking a smaller subset of the whole who can be trained AND coached in their own environments, who, because of the coaching, will come up to speed faster, avoid common mistakes and ultimately coach the next generation. Consider that what you may consider an expense may actually be an investment, which will pay dividends for years. 

Remember, nothing breeds acceptance of change in an agile transformation like success.  A well trained and coached agile core group with multiple successes is the best marketing for the effort and the best foundation fo scaling agile. 

I'd like to thank Darian Rashid of Agile Ethos, a VersionOne Partner, for collaborating on this post with me.

As I mentioned in my last post, one of our biggest challenges in transitioning our marketing team to agile was changing the idea of ownership. As with most agile processes, the concept isn’t difficult to understand, but making the behavioral changes it requires can be complicated.

It’s not my idea, my work, my deliverable. It’s not your typo, your missed deadline, your mistake. It’s our commitment, our failure, our success. It’s a little let’s hold hands and sing kumbaya but it’s the only way to become a successful agile team. 

Who are we?
We are the individual contributors that make up the team. If you have a larger marketing department (typical teams are between 5-9 people in size), you’ll probably have multiple agile teams -- and in that case, the "we" can include the entire marketing department. The Product Owner is not a member of the team (they don’t work on stories or commit to work on behalf of the team), but they do play the critical role of prioritizing and defining stories for the team(s).

What is ours?
The commitment, the quality and the timeliness of the work is ours. This is often where marketing teams struggle when transitioning to agile methods. The story owner doesn’t own the story. They own the responsibility of getting the story done (more to come on the definition of done).  Story owners, in most cases, shouldn’t own all of the tasks – it’s much better if they don’t. The only way we can achieve a genuine sense of shared ownership is to actually share the work.

Two of the biggest reasons this is so hard on marketing teams is because marketers tend to get emotionally attached to their work, and they are used to receiving individual praise - often outside of the department. It’s hard to let other people work on “your baby” and it’s even harder for other people to share the glory with others on highly visible projects. For team members who have a hard time letting go (I’m including myself in this one), the first step is to have them teach the team about their area of expertise. When they don’t own a story/work they might have owned in the past, encourage them to share ideas and give feedback. Even though agile methods focus on the team, it’s still important for the team and the Product Owner (who is often the "boss") to recognize individuals who go above and beyond.

In successful agile adoption, behavioral changes are the hardest, but they also have the biggest impact on creating a high functioning agile team. What behavioral changes are your marketing teams struggling with? What are you doing that’s working?
 

In my last post in this series, Using Agile to Scale Agile, we generated an initial Agile Transformation Backlog by doing a gap analysis of where our organization is today vs. where we envision it to be on the other side of our agile adoption. In this post we look at constructing our Agile Transformation Roadmap / Release Plan that will give us a high level plan of the execution of our agile transformation. 

It is important to remember that a critical factor to our success in using Agile to scale Agile is to always be mindful of the basic agile methods when we are making decisions.  Keep the Agile Manifesto in mind:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

The only adjustment I make is to substitute “Working software” with Working Agile Organization. In my opinion keeping things simple, attacking small slices of the organizations and having embedded in the culture the idea of continuous improvement will help to ensure success in your agile transformation efforts.  

Before we continue, let me say, there is no one right way to do this… as with most complex problems, context is very important for crafting your approach.
 

Here is an example of what a high level Agile Organization Release Plan might look like.  I've set it up using VersionOne's release planning capabilities.  Using a tool like VersionOne for planning and tracking an agile transformation gives the effort the visibility and transparency it requires.  It also enables those involved (just about everyone in a company eventually) the ability to contribute ideas and have them seen and considered in a common environment / tool.

Agile Organization Release 1

• Identify the right projects to pilot with
• Educate & assess – education is key, make sure adequate training is provided to all involved. If possible, no function for the scope of the pilot should go untrained 
• Enlisting an agile coach to help in planning transformation and then be present during the execution provides continuity and much-needed coaching to new agile teams on understanding agile principles and practices and reinforcing them.
• Select an initial agile development approach for pilot projects
• Establish 2 accountable teams – one for the leadership and one working team
• Execute initial pilot projects
• Design and institute first-cut agile project governance
• Retrospection

Agile Organization Release 2

• Adjust from learning from pilots and other Release 1 transformation efforts
• Begin broader organizational alignment 
• Launch and assess several more pilot projects - Seed new projects with experienced people – Expand training and coaching program
• Assess and modify the agile governance – map to existing systems as needed to keep people comfortable

Agile Organization Release 3

• Start to leverage more tools to help scale our agile efforts
• Expand our agility to encompass agile engineering practices, this includes: 
  • Daily build capability and continuous integration
  • Automated testing: including unit, system and acceptance testing
  • Test driven development 
  • Pair programming 
  • Design collaborative workspaces - This usually requires assistance from the leadership team to assist in changing policies to approve workspace reconfiguration… too often the cost of this is looked at without any regard for the benefit it delivers 
  • Consider a combined Lean Agile approach, applying WIP limits as well as defect queue thresholds.

Keep in mind that since we're dealing with changing processes, roles, and behaviors, this is complex stuff and we just can't plan too much in advance.  It's better to lay out the basic ground rules and then let the teams self-organize around the transformation problem with guidance from coaches.  Change that teams arrive at themselves is the kind of change that sticks.  If it is forced on them, its likelihood of success is greatly diminished, in my experience.

In my next post in this series we'll take a more in-depth look at Release 1 of our transforming agile organization.  Stay tuned...

It sounds extreme, but it’s important to break ties with the old and make way for the new when starting your agile adoption. Traditional marketing practices (hierarchy, working in silos, set in stone plans, perfectionism) have no place in agile. If you have team members that won’t get on board, they should be off the team. The energy used trying to get them on board is often wasted, and they most likely won’t be happy on agile teams anyway. “Rehire” team members who work well in a collaborative environment and are willing to give this agile thing a try.

Get Rid of Titles
The only place titles belong in agile are on business cards, not among team members. Agile methods give everyone on the team the opportunity to step up, and provide visibility into which members are contributing and which ones aren’t. Practicing agile also exposes the difference between people who rely on their titles to manage and those with real leadership skills. At the end of the day, stories are committed to and worked on by the entire team, regardless of pay scale.

Blur the Lines Between Functions or Break Them Down Completely
Functional areas or specializations are a little trickier. Not everybody on the team has the same skills and experience, but you’ll be surprised how many hidden talents you’ll find. Designers can have great campaign ideas and SEO experts can provide insight into social media programs. Team members that have experience in entrepreneurial environments or in agencies are used to wearing many hats and can contribute to stories outside of what they were hired to do. Create opportunities for the marketing equivalent to Pair Programming (i.e. cross training) and you’ll begin to create a true cross-functional agile team.

Sounds Good, Right?
But it’s not easy and it takes time. Breaking down the lines between functional areas was the hardest for me personally. Not because I didn’t want to work on stories outside of my area of expertise (I love doing that), but because I had a hard time letting other team members work on “my” stuff. Traditional concepts of ownership (mine, yours, ours) are hard to break, especially on marketing teams, but giving up the me in team is crucial to successful agile adoption.

We spun our wheels in a few areas we could have avoided when we were transitioning, but hindsight is 20/20. What have you learned in your agile transition that could help other marketers?

If your development team has been practicing agile for any significant amount of time (3 – 4 releases), then your marketing team should have jumped a while ago. You’re doing a disservice to your organization if you don’t. If your dev team is running a pilot agile development project or even thinking about “going agile,” jump now! Regardless of which department is transitioning to agile, it takes time. The sooner you jump the sooner can start realizing the benefits of iterative planning, managing and delivery. Even if there’ve been failed attempts at agile in the past, I would argue the benefits of successfully implementing agile in marketing far outweigh the crap you’re going to get for trying.

Having worked in software/technology companies for the last ten years, I know the frustration of missing release dates. It’s not fun putting marketing plans on hold or having nothing new to tell the market so you keep spinning the same lame story, and nobody likes the crazy hours marketing has to pull right before a release because there isn’t visibility into exactly what features are going to be released until the last minute.

The benefits of having both software delivery and marketing on a consistent rhythm aren’t hard to understand – the Agile Checklist is a great resource for learning to use agile rhythms. Using agile processes, new features are potentially ready to be released at any time and marketing has the collateral, website updates, customer communication, etc. already in progress or ready to go. Conceptually agile is easy – it’s the mind shift from only delivering a final end product to managing near term deliverables and the behavioral changes required to support the process that are challenging. 

I’m going to be sharing my thoughts on the impact of agile in marketing and the challenges I’ve encountered (and sometimes continue to struggle with) as a marketing ScrumMaster. I would love to hear about your own experiences with agile in marketing or other departments outside of development, questions you have and comments. 

I was discussing refactoring the other day with a friend of mine.  As is usually the case, the concept of code Smells came up.  Once again, I thought about how amazingly uncomfortable I am with that nomenclature.  I have had too many programmers come up to me and say that some other programmer's code "stinks" or has a lot of bad smells.  Its just too personal.  It also implies something that is inherently wrong, possibly with the person who wrote the code.  Rather than saying there is something here that feels just not quite right, we get something of a personal indictment of a person's programming.  Since agile development is all about valuing people, and fostering better communications and team work, it just feels wrong.  This is along the same lines as my earlier post on why I don't like the Scrum concept of Pigs and Chickens.

So how do we refer to code that is a good target for refactoring?  I thought about other things that bring out the same ideas.  What is there that, while you are experiencing it, feels just not quite right?  Sometimes it is so out of whack that it is glaring, and sometimes it is more of a subliminal thing.  The metaphor that works for me is music.  The code doesn't smell, its just slightly out of tune somewhere. 

Now, I'm a musician.  Worse than that, I'm a trombonist.  This means I am intimately familiar with being out of tune!  One thing about tuning is that it can be very simple, say one member of the orchestra is slightly flat, to extraordinarily complex.  Say some members of the first violin section are sharp but others are flat, with the concertmaster the only one on pitch. 

I see code the same way.  You are in the code, and as you are working on it you find that something is not quite right.  The first thing you do is look for the more obvious areas that are out of tune.  Maybe an overly complex set of if..then..else statements.  You write your tests and fix the tuning of this one area.  Your tests become your "tuning note," a common note that all instruments play and adjust toward.  In orchestras that note is the concert "A".  You run your tests, and they all pass.  But something is still out of tune.  You go to the next section and find out who is out of tune.

Now there are all kinds of analogies we can use to totally abuse this metaphor, and I plan on exploring as many of them as I can in the future.  For instance, you may decide that you are "in tune enough".  I wouldn't choose to do this too often, but it can indeed happen.  If enough of the code is out of tune, you may describe the design as cacophonous, which is always fun to say.  Every musician gets out of tune.  Good musicians are continuously tuning, even while they are going about the business of making music.  It becomes a part of the fabric of her music making.  Note that when you go to a concert you will never see a separate section on the program for "tuning".  That doesn't mean it isn't done, it just means it isn't something special that is added to the list of works that will be played.

So let's be nice to each other.  Let's think of code refactoring, whether we are doing extreme programming, scrum development, or any other software development process, as a way to tune our code, thus making it that much more pleasing to the end recipient.

Growing up as the youngest child meant that my closest brother (6 years my elder) terrorized me with threats of the boogie man coming to get me.  It was a rather effective tactic - how to deal with the boogie man wasn't well known, and the internet was just a glimmer in Al Gore's eye.  I see and have been part of a similar tactic in agile software development.  I have terrorized product owners and business sponsors with the concept of technical debt.

'Ooh, that change is going to take a long time. That code that so-and-so wrote 3 years ago is real bad.'

'Well, yeah, we could do it that way, but it will fall apart.'

'The code is so bad we just need to start over and re-architect it.'

These three sample comments stem from the same situation - ugly, nasty, boogie man type code.  Fear not, I am not here to terrorize you with technical debt.  Lets start making technical debt something the whole team can use and discuss in a productive manner.

First off, what is technical debt? Simply put, technical debt is software that has been implemented in such a way that future progress is hindered.  Have you seen a project where a seemingly simple change or bug defect took weeks and introduced other problems along the way?  You saw technical debt in action. The decisions and shortcuts in system implementation that cause technical debt are usually made due to time constraints, but can also come from sheer laziness.  There are tons of articles on technical debt - I would recommend reading either this posting by Martin Fowler or this one by Uncle Bob Martin.

As Martin and Uncle Bob point out, technical debt isn't always bad for software product development.  If time is critical for a competitive advantage, we may want our product out as soon as possible.  Or we may be breaking new ground and need a prototype to see if a concept is achievable / if there is a market for an idea.  Both are logical reasons for taking initial shortcuts, as long as we go back and work on paying down that technical debt.  How can we start creating meaningful discussions around technical debt?  The same way you take care of the boogie man - you shine light on it.

I come from a Java background and am a big fan of the open source project Sonar.  Sonar is a code quality management tool, leveraging other open source code analytic packages.  It provides time sequencing of code quality as well - so we can see if our code is getting better or worse, and at what rate.  It also provides nice views into high risk areas as well as areas that can be quick wins for agile teams.

Can people get lost in the details of Sonar? Most definitely.  But at the very least, I hope this levels the playing field between the team creating the software and the person / group requesting the software.  Here is how Sonar (or any consolidated code quality tool) can be highly beneficial for a team and an organization delivering software:

Provide understandable visibility into code quality

Even without explaining how complexity is measured to non-technical people, it is easy for anyone to grasp certain things - this software development project has a lot of red while these others are green.  This project says there are lots of violations and there is a lot of risk. That can't be good.  Use these tools to level the playing field and start discussions.

In Sonar, we create code profiles.  We suppress violations that don't make sense to our organization, prioritize our code style, and set up visual flags around other metrics such as complexity and test coverage.  As someone paying for software, I want to know it is being created with care and of high quality.  As a developer, I want to promote my attention to detail and also want means to help me explain why I need some additional time to keep the cost of future maintenance low.  These metrics allow us to talk to the numbers.

Assist teams dealing with legacy code

Legacy code is here and it isn't going anywhere.  An easy cop out to not write unit tests is, 'it's old code and it doesn't have any tests.' The logic being that since the code doesn't have any tests, it would be so terribly difficult to get any tests written.  Leverage these code quality tools to show you where there is a high risk area and target your tests there.  Its like having a big ball of tangled yarn - let the tool give you one end and a big loop to help you start untangling it.

Provide context and depth to the cost of change and feature adds

Use code quality tools throughout the software development process to help provide more context to why a new feature is going to take as long as estimated.  When we are in our planning sessions, reference Sonar and explain why a story or feature request has a high estimate.  Similarly, we can compare to an easier change and see there is less risk.

Create a plan for addressing fragile code

Don't take a hack and slash approach to lowering your technical debt. All that will happen is all of the 'easy' changes will get done and none of the real valuable changes will be addressed.  Instead, use a surgical precision approach by using Sonar and similar tools to come up with a plan for addressing the weaknesses of the code by targeting areas and see the progress visually.

Like most quality tools, Sonar is not the decision maker; it is the conversation starter.

Interested?

• Look at some of your favorite open source projects in Sonar
• Download and configure Sonar
• Start looking for quick wins
• Witness your technical debt lowering

Read more by Joel Tosi @ http://communalosmosis.com

Constant focus on quality and code health is critical for the long term viability and maintainability of software.  This focus on quality is a trademark of agile teams but you don't have to be 'doing the Agile' to focus on quality. Regardless of how you develop software, testing and in particular unit testing are an important tool to have in your toolbox.  Given the importance of unit level testing, why do so many companies struggle with unit testing and its adoption? When unit level testing is non-existent or inconsistent, the reasons fall into two main categories:

• General misunderstanding on what a unit test provides
• Developers aren't good at / shy away from testing as it is out of their comfort zone

There is a third reason, more like a myth, that is very popular - the myth that 'we don't have time to test'.  This is false - nothing will slow you down more than writing as much code as you can without some way of constantly being able to verify you haven't broken your assumptions of the intent of the code.  We tend to hear this myth coming mostly from developers.  This comment is usually rooted in a blend of the two primary reasons with the majority of the cause coming from developers simply shying away from testing.

Lets look at the two main causes and how we can address them to build a solid focus on quality.

1. General Misunderstanding of what a Unit Test Provides

I've been involved with organizations where there is this strange belief that unit testing is complete bug prevention.  I've seen mandates from software development management that all project plans must include time for unit testing.  Along those lines, I've also seen 'acceptance' of bugs because a team did not write unit tests.  Lets be very clear here - You can have unit tests and still have bugs.  It's ok.  It will happen.  The important part is when it does happen, you create a test around the bug and then fix the bug; verifying that the fix didn't break any of your other tests.  This is also the simplest route to introducing tests into legacy (untested) code.

Unit tests provide:

• Validation that the developers' intent of the method, algorithm, etc. is met and not broken
• A solid framework / cushion that supports the ability to refactor and clean code
• A means of lowering the cost of code maintenance

Unit test do not:

• Guarantee there aren't bugs in your code
• Prove that the intent of the developer is right
• Ensure that the overall application will be successful

2. Developers aren't good at / shy away from testing as it is out of their comfort zone

When I first started developing software, if you had asked me if I tested my code I would have said 'Yeah, I run some mains through the app.  I don't test at a method level.  I'm a great developer, I know what I am doing.' And what I was doing was delivering buggy software.  In my defense, there weren't the great unit testing libraries then that there are today.  The point is still the same though - developers are very proud individuals.  It is hard for us to admit that this testing thing might be kind of difficult.  We know how to write code, surely we should know how to test the code we write.

Given these two main causes for unit testing not happening, what can we do to start growing a consistent approach to unit testing?

Set proper expectations. Everyone involved with the software development process needs to understand why there is a focus on unit testing as well as what the expected benefits are.  Agree that unit testing is not nearly enough to ensure quality, but it is a solid start.  Have answers for the following questions:

• How are we going to measure whether or not unit testing is helping?
• How can we help each other write better tests?
• How will we know if our tests are good tests?

Review the produced benefits of unit testing. If unit testing is new to developers, be sure to meet regularly to show how it is helping and continually answer questions.

Give people time to learn, experiment, and fail safely. When a developer is uncertain about testing, give them some freedom to learn either on their current project or on their own.  A 2-day training session won't be enough, developers will only get good at testing by testing.

I am a large believer in / practicer of test-driven development.  But the reality is there are a large set of organizations and developers out there where unit testing is still not happening.  Lets start raising that bar.
 

Interested in learning more about integrating the benefits of testing within an agile team? Request a free copy of the white paper: The Agile Tester

Many people don't see that there are many changes to the programmers' life when it comes to moving to agile software development.  I personally see quite a few changes.  Some of these changes are basic, like moving to test driven development, or getting into the habit of continuous refactoring.  Other changes are a little more subtle, and yet much more challenging.  These changes apply whether you are doing extreme programming, scrum, or any other agile process.

Lets start with the obvious ones.  We as programmers are going to be spending a lot less time planning and writing design documents.  This isn't to say that there won't be any design going on, just that it won't be in big paper diagrams that require an expensive plotter to be able to print them out.  So with all this free time, what will we spend our time doing?  Lets talk about a few of the basic agile programming concepts, briefly, and then look at what they add up to.  As with most things in agile, we will find that the whole is much greater than the sum of its parts.

Test Driven Development
There are volumes and volumes written on what TDD is and is not.  At its most basic, TDD is one of the fundamental practices that make agile software development succesful. We create a set of automated tests that must pass for the software to be "done".  These tests are run every time we check in code.  These tests provide a safety net, so that when we start changing things willy nilly on the whim of our customer, we will be able to know quickly if we have broken something.  This in turn reduces the set of suspects for the broken code.

Continuous Integration
Several times a day, whenever we have produced some small piece of code that does something, and all the tests still pass, we will check in our code.  We are not going to have a set of code checked out for weeks at a time until a large chunk of functionality is "ready".  Change will happen rapidly, and the system will evolve rather than just appear at the end of the development project, just in time for test.

Refactoring
Every chance we get, within code we are actually working on, we will make small changes that improve the design, but do not modify the behavior, of our software.  Great designs will emerge as the system grows.  We can safely make these changes because we are test driven.  We see something that could be improved, so we write a few unit tests, then write the code to make those tests pass, and our software is now slightly better than it was thirty minutes ago.  The cumulative effect will become rather extraordinary.

Teamwork
There is a long-enduring myth that programmers are anti-social people.  Just give us our assignment, and we will go off into our caves and produce something.  The more junk food you throw into the cave, the happier we are.  While this is a very fun image, it just isn't true.  It is, however, so prevalent that we need to put extra emphasis on this change.  We are going to be working in a close knit team.  Not just of programmers, but of members of the development team who don't program.  They might be testers, or documentation specialists.  They might...good heavens...be managers.  This is a Good Thing.  We need to embrace all of the components of a software development project, not just the folks who write the code.   This is probably the biggest and hardest part of moving to agile for programmers.  In my travels I periodically hear the question "What do we do about the fact that the story is done on the last day of the iteration, so there isn't time for testing?"  The answer is that the story isn't done until the testing is done.  The shift is subtle and strong.  We estimate as a team.  We develop as a team.  We celebrate our success as a team.

The Bottom Line
So what does this all add up to?  We have some technical things we need to do differently.  We have to step down from the exalted position of "Developer" and become programmers again.  I didn't talk about pair programming, but there is another opportunity to become more agile and will also require more social interaction.  These changes in how we do business add up to two "buzz words" that encapsulate what we are aiming for.  The first is Craftsmanship.  We are creating something.  In most cases, there is much more art than science to what we are creating.  Just as the masters of old did with wood and iron, we must approach our software with a passion for a great product.  Not just something that is brilliantly made, but something that is well made, sturdy, and pleasing to the consumer.  The other word that was drilled into my head as a young Midshipman, and I believe applies far more than we give credit, is Professionalism.  We are professional software developers.  Our particular skill is writing code, but we are part of a larger profession.  Software development, especially agile software development, requires professionals with many different skills.  A true professional learns how to work with all of those other people, and in many cases on their terms.

So how we write code is changing, mostly based on extreme programming practices.  How we treat our projects and planning is changing, mostly based on scrum practices.  All of these changes are giving us the freedom to create great software.  The price of this is that we now have to step up as craftsmen and professionals, members of a larger software development team. 

Agile development practices may seem easier for small, isolated teams, but what happens in the real world when applications go across teams and dependencies to rear their ugly heads?  The answer I hear too often is 'adjust in your planning sessions so that the dependencies go away.'  That's not a real, complete solution to me.  Here is why - that answer makes sense if we are creating an application and we have two stories - Add item to shopping cart and Remove item from shopping cart for example.  In this case it's logical to plan accordingly.  We wouldn't want to release the product without being able to add items, and this functionality seems in control by the team.

What about this more common example though - a front end team develops an application that depends on data from a data team.  On top of that, not only does the front end team depend on the data team, but so do 3 other teams, all with different priorities and needs.  And since it is the real world, we have a deadline to hit - the application needs to launch in 6 weeks and the data team won't be able to finalize the data for the front end team for 4 weeks.  It doesn't make sense for the front end team to not work, especially if the amount of time they need is greater than the remaining two weeks.  What do you do?

There isn't a simple answer to this.  You don't get to wave the magic Agile wand and voila - problems solved.  Yes, 'push the date' may be the easy out, but that isn't always possible or even recommendable.  TDD leveraging Mocks won't solve this problem, but it will allow teams to continue working, deferring those dependencies to as late in the game as responsible.

What are mocks? A mock is a fake representation of an object (in this case an object that might not exist or be implemented yet) that developers can use and manipulate in a controlled fashion to allow them to continue testing.  Using the example above, the front end team has a set of data they need.  Presumably there is an object that represents that data and a service around retrieving that data.  The front end team in this scenario would mock the data object. That data object would be volatile (still under development by the data team) but the front end team would want to be able to create their own tests which would be dependent upon it.  Enter mocks. This way the front-end team would be able to stress different interactions with the data without having the data layer delivered.

Mocks do not replace communication in the software development process.  If the front end team does not speak with the data team, it is very well possible that the data they get won't even be the data they need, even with great tests around it. Mocks are successful when dependent agile teams work together to understand their interactions and can agree on some interfaces or test contracts. This allows the teams to continue their work in parallel.

Ready to get your hands dirty? Here are some great links:

EasyMock - mocking framework for Java Great EasyMock example by Michael Minella Mockito - mocking framework for Java Great Mockito example by Brett Schuchert Rhino - mocking framework for C# Rhino example by Isiah Perumalla

Regardless of the agile methodology you practice, continually improving should be your goal.  We want the product to be better, we want better quality, we want to work more effectively.  Agile development practices, and retrospectives in particular, are effective in helping us improve because of the tight feedback loops and team ownership. How are we doing outside the team though?  Does your company have strange rituals that no one understands and no one can seem to change?  Do you have organizational OCD?  Say for example...

A team wants to deploy their software to another environment for testing...but they have to fill out a form and wait for a DBA to execute the SQL script to update the database.  That person executes the script and walks away, leaving the team to flail with questions. 'Did all of the data update? I don't know, I can't see it.'

Scrub scrub scrub

A young developer wants to try out an open source job scheduling library that would save him from writing his own.  But wait, that library isn't on the approved library list - so the options given are to either use the approved library (that isn't thread safe and doesn't support eventing) or come present why he should use his library to an approval board.

Scrub scrub scrub

Your deployment process is not automated, rife with handoffs, and full of opportunities for 'waiting for email response.'  Someone is willing to create a prototype showing how deployments could be automated.  Ok...but create a committee before you do any work.

Scrub scrub scrub

If any of these examples sound familiar, then maybe your organization has some form of organizational OCD.  You are not alone.  While I am no psychologist, I want to see you get better.

Teams working on adopting agile practices will uncover large organizational impediments, well beyond the responsibility of the team.  These impediments have been there for a while - Agile practices are just making the cost of them much more visible. For example, I have seen a team track 11 days to deployments over four two-week iterations.  Some of these problems are real - distributed agile teams are challenging and will require changes to the way we address projects.  Other impediments fall into a 'ritual' stack.  Rituals are more than just ceremony; ceremony is an elaborate, time-consuming means to achieve a valid goal. Rituals are progress distractions.  Rituals are sinkholes of time and money with little if any value.

Organizational rituals are often steeped in historical significance (8 years ago this one real bad thing happened).  More often than that, rituals come from a lack of trust.  Breaking a ritual that happened in response to an old event is far easier than breaking rituals based on a foundation of mistrust. While I would recommend the below steps in both situations, when there is mistrust the lack of solid leadership must also be addressed.  When there is smoke, there is fire; and when there are politics, silos, and dubiety there is weak leadership.  That is a topic for another time.  On to your recovery.

Steps to break your organizational OCD

1. Identify the ritual.  Don't think you have any rituals?  Just listen.  Wait for the question from the new team members - 'Why do we do this?'.  Large recurring meetings, committees, and the famous POST-MORTEMS are also nice places to start.
2. Identify the issue the ritual is trying to solve
3. Ask "Does the ritual really prevent the issue," or is it something else?
4. Imagine the worst case scenario that could happen if you stopped the ritual, and quantify its cost and its probability.
5. Commit to not doing the ritual once and see what happens.  Have measurable expectations to compare "with ritual" and "without ritual".
6. Realize that not doing the ritual wasn't the end of the world and may have just made our work more enjoyable / product more successful.

Let me give an example.

A sharp young tester joins our agile team. We have some stories complete and are ready for some cross-cutting testing to take place. The tester wants to pull the application into his environment for testing...but has to file a ticket for the deployment team to push the code to his testing environment.  He says "I've worked with the team, I understand how the application is put together and know how to get application up.  Why can't I deploy to this testing environment?"

1. That's the cue - someone has seen a potential ritual - inability for a team to control their own environments for testing.
2. What issue are we trying to prevent by not allowing a team to control their environment? Well, we share environments and we don't want someone to accidentally affect another team or break their environment.
3. Ask "How does restricting access stop a typo?" Isn't it still possible for someone on the environment team to make the same mistake?
4. Imagine the worst case scenario. What would be the impact, and what's the probability of it happening? In this example, the worst case scenario is that another team's environment would be affected. This would cost that team 2 hours to redeploy their latest build and reconfigure.  The probability of this happening is small as long as people pay attention to their directory.
5. Commit to allowing the team to control their environment once and measure results.  Was anyone else affected?  How much time was saved, both on the product team and on the environment team?
6. Was not doing the ritual that bad?  Could we address the original concern differently - in this scenario with separate accounts per project?

As more companies embrace an Agile development culture organizationally, they will not only need to ask themselves if there are rituals that need to be broken, but they will also need to create an environment that will challenge rituals from being formed.

One of the most common meta-themes in Agile adoption is about how many roles in a typical software development project change.  Some folks see this as a very large obstacle to agile adoption.  I'd like to spend a little time over the next few weeks exploring what roles are changing, and how they change.

It is my firmly held belief that these changes are good changes.  Not only for the development organization, but also for each member of the team.  While there is fear associated with any change, these changes, just like the subtitle of Extreme Programming Explained states, should be embraced.  After all, we are looking to become more effective in our development, and that will apply to every facet of the organization.

So what are some of the roles that are changing?

Programmers -  There is a slew of new activities that we will have to perform.  We have to identify our tasks in front of a whole group of people.  We will have to engage in more social activity around the product than we ever did before.  We have to lose traditional concepts around scope change and users. 

Analysts - There isn't even a role described for us.  Are we all to become scrum masters?  Should we go look for a job somewhere else?  We've put a lot of time and energy around how best to describe the software requirements and features in a consistent, clear manner.  Now you want us to just write a bunch of stories?  What's up with that?

Testers - So no more features thrown over the wall to be tested, with defects thrown back over the same wall.  We can't wait until a feature is "done" in a given sprint to do the testing.  There is never enough time to automate the tests, and yet automated testing is a cornerstone of any agile development process.  How do we reconcile this?

Project Managers - No, *we* are the scrum masters.  Or are we?  How do we reconcile the responsibility of representing the project and its progress to the senior managers?  And where are my Gantt charts?

Other roles to consider are Functional Managers, Executive Management, Recruiters, you name it.

What are some other roles we should explore here?

Lets see what else we can come up with. To paraphrase Pete Townsend:  "Come on the amazing journey, and learn all [we] should know.."

You are a responsible agile developer, practicing TDD and keeping your code clean through refactoring.  Your "bar" is always green, but are you living and developing in a world of "false green"?  Is your green bar continuous or is it only measured at points in time - when you run your tests, for example?  At the Lean Conference in April, Joshua Kerievsky gave an excellent presentation titled "The Limited Red Society." A summary of this presentation can be found on Joshua's site and the video can be found here. Synopsis: In application development, we need to be aware of the state of our code at all times, not just when we run our tests.  In the real world, things may break at non-ideal times, like during the middle of a refactoring, and we must fix them. Joshua's session really hit home about a month ago when I felt like I was refactoring with fire.

To set the stage, I was working solo on some custom code for a customer.  I developed it test-driven and had solid tests.  After I delivered the code to the customer, I saw a great spot for refactoring and simplifying the code, so I dove in.  Then the customer came back with a change...but I was in the middle of refactoring! The change would only take me about 10 minutes but the refactoring session would last another hour or two to get to the point where I wanted it.  Right then I felt like I was refactoring with fire.  This was only a 10 minute change, but a production emergency could go on quite a bit longer and I would be leaving my codebase unstable. I vowed to not let that happen again.

Fast forward to last week.  I am working on some more custom code for a customer.  Without getting into too much detail, the application was building relationships of work from VersionOne.  The application was originally implemented with one level of relation - parent to child.  After some discussion, we came up with a story where the relationship would need to be up to eight levels deep (parent to multiple children to multiple children and so on).  My tests are solid so I was comfortable making the change, but I knew it would impact quite a bit of the system.  If I was to make the relationship-building recursive, it would also impact how I query and report out data.  What to do...I said "Don't play with fire."

I used Parallel Change in this approach to make sure the codebase was available in the event of an emergency. In the software development process, Parallel change is creating and working on new functionality without connecting into the main process flow.  We have all used parallel change before.  I wasn't using it often enough.

Here is what I did ...  nothing groundbreaking mind you, but by employing this approach, I was able to deliver my code continually while the large change was worked out.

• Create new tests for my new recursive relationship builder (using mocks to simulate the result from the query)
• Implement enough code to make my test for the relationship builder to test (all older tests will be passing and remain passing as they haven't been modified)
• Add more new test cases around the relationship builder
• Add code to make these tests pass
• Rinse and repeat for the other new areas of functionality needed - the query for the data and the structuring of the data for reporting in this case
• Once I have completed the tests for the independent levels of functionality, write the integration tests around the cumulative effect - query, build relationship, structure data for reporting

Only after my tests pass in that last step do I cut over my app to use this new flow.  With this approach, my code could have been put on hold at any point and been stable for a production release.

Challenges with this approach:

As with any code, higher coupling and multiple responsibilities in objects and methods will make Parallel Change more difficult.  Think of a highway.  If it is a simple highway (2-way traffic, not multiple on and off ramps) then building a parallel highway is simple - you run a new straight stretch of road, and once it is done you cut over the entry and exit points for the new road. Just like your code - if it is a straight run, Parallel Change will be easy.

If the highway has multiple on-ramps, off-ramps, a railroad crossing, and a wandering herd of yaks in the middle - then building your parallel road to that is going to be very difficult.  With that scenario, you're obviously better off simplifying the highway before you try and create the new stretch of road.

Interested in learning more?  Check out Kent Beck's presentation on Responsive Design or Joshua Kerievsky's presentation The Limited Red Society.

In my first post in this series, I set the stage for using Agile to scale Agile development within an organization.  In this post we'll explore at a high level how we get started using Agile to scale Agile, and the steps and deliverables needed to take us to the point where we can make use of an Agile Organization Release Planning process for our organization.

First, let’s take a small step backward and ask the obvious question: “Why use Agile to scale Agile?”  Here are a few good reasons:

• Agile project management approaches shine when dealing with complex, highly dynamic problem spaces…and transforming an organization is just that!

• Use of Agile for scaling reinforces an organization’s commitment to Agile to its members.

• It can aid in embedding Agile into the culture of an organization at all levels.

• Having a continuous improvement cycle built in to change initiatives is very important and at its core, Agile provides this principle/practice.

So where do we start?  First, our organization should have a clear vision of itself on the other side of the transformation, including what it will look like and what it will be capable of doing.

As part of this exercise, the sponsors of the agile transformation must identify the clear business benefits linked directly to our organization’s strategic goals that will be served from adopting Agile methods. Getting alignment with these goals is important.

Next, we must identify misalignment to being Agile within and across the functional areas of our organization.  This will help us to build out our product backlog or, as I’ll refer to it, the  "Agile Transformation Backlog."

Also, we want to avoid big up-front planning for the scaling efforts.  We just don’t know enough and there isn’t a crystal ball!

Next we will want to Plan for "releases" of our Agile organization. Just as we use agile software development to plan releases and iterations to build a product, we can use it to plan for releases of an Agile organization.

We’ll need to execute our Agile scaling in an incremental and iterative fashion.  Doing so will enable our agile teams to continuously groom the Agile Transformation Backlog.  It is important to avoid having everyone go agile at once because you can greatly increase the likelihood of misunderstanding, confusion, and failure.

You will want to hand-pick the first Agile pilot projects.  Are they likely to succeed?  Do they have the necessary training and support?   Look for the opportunities to get wins and experience on smaller efforts, and then start to scale up to the bigger/harder projects.

As we progress through our Agile organization release plan, we’ll want pay particularly close attention to retrospection to gain continuous improvement.  Through regular review and retrospection, we can adjust the release plan as we learn from pilot projects' iterations.

The table shown above is what a high-level current vs. future state analysis might yield for an organization going from waterfall to agile.  This type of analysis provides a good initial framework for developing the Agile transformation backlog.  All of the misalignment items should have backlog items in the Agile Transformation Backlog covering how each functional area would get from the current state to the future state.  The organization will want to produce a deliverable, such as the one shown, and share it broadly to get feedback.  This is important because the perceptions of gaps between current state and future state can differ greatly between people.

So with an initial Agile Transformation Backlog in place, we can move on to planning our Agile Organization Releases.  I will pick up on the Agile Organization Release Planning topic in the next part of this series... stay tuned!

You're going Agile and you couldn't be more excited.  You've read about all of the benefits and want that for your organization, and you want it now.  Slow it down a little bit Buddy; realize that not only will Agile development change the way you work, it will possibly require organizational and cultural changes.  Your organization only has a certain amount of change it can consume successfully in any given period - you only have so much transitional velocity.

One of my partners in crime at VersionOne, Mike DePaoli, has started a series of posts regarding using Agile to scale Agile.  I couldn't agree more with the thread and chatted with Mike briefly about adding a topic I spoke about at Agilepalooza - the idea of transitional velocity.  We know what velocity is in terms of Agile - the rate at which a team is delivering value, usually measured in average points per sprint or iteration.  Transitional velocity is how much change we can successfully introduce and make sustainable in a given timeframe.

When rolling out Agile practices we simply cannot change everything right off the bat.  I have seen this a few times when Agile comes as a top-down movement or when it comes from over-excited developers.  Introducing large amounts of change all at once won't stick and will just end up confusing people.  Instead, we need to consider our transitional velocity - how much change we can successfully introduce and make sustainable in a given timeframe.  Just like planning a product, we need to roll out changes using knowledge of our transitional velocity.

How would you start doing this?

1. Understand the challenges facing delivery at your organization
2. Understand and embrace the strengths in delivery at your organization
3. Look at practices that can enhance these strengths or help with these challenges
4. Create 'acceptance criteria' for when you would feel that these practices have been accepted. Once these acceptance criteria have happened, you will feel like this challenge has been addressed / strength has been enhanced and is stable
5. Using your knowledge of your organization, sort out the changes in order of amount of change this will create to your team.  Similar to story-estimating, give these some sense of relative sizing.  Note any dependencies as well
6. Pick a subset of these changes that you think your team can handle in a timeframe (NOTE: Change is hard, I wouldn't recommend a 2 week timeframe for this, something larger along the size of a few months)
7. After your timeframe, look at the changes and calculate your transitional velocity by simply sizing the 'change estimates' you assigned to these practices
8. Rinse, wash, repeat

How about an example:

Say I am at an organization and I have concerns about our software delivery.  Our strengths lie in deep domain knowledge across our teams and highly skilled developers and testers.  Our challenges include high defect rates and large piles of documentation and change requests.  Looking at this and reading about Agile software development, I (somewhat arbitrarily) decide that our teams need to be co-located, we need automated testing, continuous integration, pair programming, TDD, short sprints along with sprint planning, requirements as stories, and daily standups.

Being responsible, I look at how much change each of these practices would bring to our organization.  TDD gets a higher estimate because our teams are still struggling with unit test consistency.  Pair programming also gets a higher estimate because it would require physical changes to the work environment.  Short sprints and sprint planning seem like a nice, easy way to start getting some change in place, as they will get our groups talking.  I decide to focus on those, along with daily standups to start building trust and common voice among the team, before I try anything else.

I define acceptance criteria for these changes (acceptance criteria being when I feel the change has taken hold) - short sprints are working when a team is comfortable with their defined sprint, it is less than 4 weeks, and there is minimal work not being completed in a sprint.  Sprint planning is accepted when a quick check with team members respond that they don't want sprint planning removed.  Daily standups have been accepted when teams are having quality meetings in less than 20 minutes and blocking items have been identified and removed by teams.  I give each of these changes an estimate of 3 compared to a 13 for pair programming, and the rest fall in between.  After 3 months, I check back and see if these changes are sustainable.  If so, I know that I could introduce about 9 changes in the next few months.  Pair programming seems too large to introduce all at once, so I would have to look at how I could get to the same end goal through multiple steps.

I continue efforts to improve the organization, always basing my amount of change against my measured transitional velocity. You will have some overachieving teams, and they can 'pull' practices to try from the transitional backlog or create their own.  Transitional velocity targets organizational rollouts.

Use transitional velocity along with using an agile or Scrum tool to visualize your transformation holistically.  I like storymapping a transition as it helps provide a long term view and binds it to 'why'. Just as Agile won't guarantee a successful project, this approach won't guarantee you a successful transition.  It will only raise your chance of success.

Read more by Joel Tosi @ http://communalosmosis.com

I like to get involved in the various agile development discussion groups.  These groups tend to provide a ton of insight into how to make extreme programming, scrum, or any other flavor of agile development that much more than "by the book".  Lately, there have been quite a few comments posted regarding metrics.  The questions are usually something along the lines of "how can I use Agile metrics to prove that agile is helping my software development project?"

I have a problem with metrics.  Metrics seem to be measuring something because you can measure it.  When I see or hear someone asking for a set of metrics that should be defined prior to the actual development project, I get worried.  Are we moving away from the agile manifesto value of working software?  Are we letting ourselves get dragged into the same trap that the waterfall crowd fell in?

Lets explore some of the reasons one might to want metrics.  The most commonly stated reason is to be able to measure progress, so that we might improve.  What exactly we are going to improve I don't know, but it sure is going to get better.  What can we measure in an agile environment that might help us improve?

1.  Velocity - So many teams see this as something they can improve on.  "We had a velocity over the last 4 iterations of 25 points worth of stories per iteration.  Surely if we just try a little harder, we can to 30."  Making this statement implies you don't believe we tried hard enough this time.  If a team member makes this statement, they are generally referring to someone else on the team.  If a product owner or team leader of some type makes this statement, they are directly accusing the team of sandbagging.  So measuring velocity is fraught at best.  I look at velocity as a way to get a feel for the capacity of an upcoming iteration.  I hope, over time, that i will start to see some predictability in my velocity.  I never ever ever look for a way to increase velocity.

2. Estimate Accuracy - I used to see this one a lot in the scrum software development discussions.  The desire to improve estimation accuracy just seems to be built into the project management psyche.  I see where the desire comes from, but it really only applies to a waterfall methodology.  We want to be able to estimate well so that our software project will stay on track.  If we are good at guessing how long something will take, we will be able to predict better how long the whole project will take. But in Agile, we are starting off by saying "we recognize that we can't estimate well."  We are going to accept that fact, and we are going to instead work on ways to create great software, and instill predictability, with that fact in mind.  Short iterations mean we don't have to try to predict so far into the future.  Small user stories mean we don't have to try to estimate something so complex as to be virtually incomprehensible. 

So I'm not crazy about metrics.  They tend to drive behavior that is around making the numbers look good, not making the software look good.  But maybe I'm being too "purist".  Are there metrics out there that *can* help us be better at being agile?  Are there metrics that folks have run across that I didn't mention that have gotten in the way of their agile implementations?

My last post in this series, The Elephant In The Room – Part II, discussed why this type of impediment is tolerated in many agile development organizations.  I also explored how understanding the context and motivation behind a team member’s poor performance can change other team members' perceptions of it.  I discussed the importance of not labeling someone as a low performer before making sure that the individual is in the right context to leverage their strengths. 

In this post I will be exploring some tools and tips for understanding what motivates people, how they operate when things are going well and when things are in conflict, and what types of positions work best fit a person.  Armed with this knowledge, teams can be assembled that have complementary motivations, strengths and interests.  Teams formed with this knowledge of each other are much better equipped to build understanding, more open communication and trust.  In my experience, assuming you hire intelligent and technically competent people, these are the key ingredients for achieving sustainably high performing agile teams.

There are three tools or instruments that I have seen used effectively in software development management to equip people with an understanding of their own motivations, values, strengths and communication style as well as those of their team members. The three are:

1. Strengths Deployment Inventory (SDI) - A suite of psychometric tests and a practical methodology for empowering people to improve relationships and manage conflict more effectively. SDI is rooted in the theory of Relationship Awareness®, a self-learning model for effectively and accurately understanding and inferring the motive behind the behavior.

2. StrengthsFinder 2.0 - This is a book and on-line instrument that enables people to understand and develop their strengths rather than trying to improve on their weaknesses.  When used in an agile team environment it allows team members to understand and leverage their other team members’ strengths, and not interact with them by targeting their weaknesses.

3. Belbin Team Roles - This tool looks at the team dynamic based on roles within the team.  It identifies nine different roles.  Based on an understanding of these roles, teams can be assembled with the best complement of team roles to help ensure success.

While I have exposure to each of these tools, I am most familiar and have the most experience applying SDI.  In fact I am a qualified facilitator for this tool. I prefer SDI because it is simple, has a strong visual component and instills people with a basic vocabulary and set of tools from which they can build their own set of tools.  SDI is based on Relationship Awareness® theory which has four simple tenets:

1. Behavior is driven by motivation to achieve self-worth.
2. Motivation changes in conflict.
3. Strengths, when overdone or misapplied, can be perceived as weaknesses.
4. Clarity and face validity enhance self-discovery.

This has always seemed very common-sense to me and can be seen while truly observing any team during its interplay. It gives organizations and individuals the awareness and skills they need to build more effective personal and professional relationships. It helps them to sustain those relationships through understanding the underlying Motivational Value Systems™ of themselves and others under two conditions:

1. When things are going well
2. During conflict

By using Relationship Awareness® theory through the SDI instrument, software development teams can evolve from choosing their behaviors to accommodate just their own underlying values, to also considering the underlying values of others. It is a dynamic and powerful way of looking at human relationships that aids in building communication, trust, empathy, and effective, productive relationships.

In the rest of this post I will explain how I have used SDI on the Agile teams I have led to help their members grow personally in their communication and collaboration skills as well as to help empower the teams to move to the next level of performance.

The first step is that I train everyone in SDI (I can do this since I am a facilitator).  Most organizations hire a certified SDI facilitator to deliver the training.  After everyone has been trained and it is known what each team member's Motivational Values System is, these are plotted on a poster-sized MVS diagram as shown below.

Once the team is thoroughly trained, I then have a separate meeting with the team to go over the results, help to reinforce the simple vocabulary based on the colors in this diagram, and review the interpretation of each person’s plot.  Each plot shows where a team member operates when things are going well and where they go when things are not going well (are in conflict).  Once you understand this diagram and Motivational Value Systems, these plots are very informative.  For instance, the longer the line connecting the dot and arrow head, the more you can expect someone to change in behavior from when things are going well to when they get in conflict. 

I recall a specific situation where one of my staff was a blue-green when things were ok, but traveled all the way into the red when things got into conflict.  This is an indicator of a very volatile personality, one that can absorb a lot of crap but then one day they "fly off the handle".  I coached this person to ensure that they communicated openly when things were done or said that rubbed them the wrong way.  They continued to avoid the issues and just swallowed it and went on with life.  Each time they did this, their tolerance for the behavior or treatment that they said was wrong would get reduced until one day the person blew up at their lead and almost got physically violent…luckily they didn't.  The person was gone for 3 days.  When he came back he came in my office and said, "Man!  You were right.  I should have let him know that the way he was treating me wasn't working for me.  I’m going to start now."  Funny thing is that when the genesis of this blow-up was explained to the Lead, he had no idea, because he was still operating and treating others based on his MVS.  Both these individuals learned a valuable lesson that sticks with them to this day.

Applying SDI as a servant leader, I reinforced it at each team meeting and at one-on-ones.  For instance, when someone would come to me and want to discuss a problem they were having in communicating effectively with someone else on or outside of their team, I would ask them to apply their SDI knowledge.  What did they know about their MVS?  Were they in conflict with the person, and if so, at what stage? (SDI has a 3 stage conflict model).  What do we know about their MVS when they’re in conflict, what do we know about yours?  Basically I’d have them work through the problem, just offering tips to help facilitate their thought process.

It doesn't take long when applying SDI on a regular day-to day-basis that the team integrates SDI’s terms into their regular vocabulary.  This is exemplified during meetings, when people joke with each other about someone strongly exhibiting a certain color, especially when it isn't conducive to the discussion at hand.  More than once I've heard, "Mike’s being red again." I am personally mostly red when things are going well and I move toward being blue when I get into conflict.  This helps to explain why I have much interest in the human side of things. 

Eventually you can see people applying Relationship Awareness® thinking when they are constructing e-mails, planning for difficult conversations and even when they are preparing presentations.  If you know what motivates someone, it is not hard to communicate with them so as to not de-motivate them.

If you’re dealing with the issue of “The Elephant In The Room,” I urge you to equip yourself and your teams with tools such as SDI or the others mentioned.  If you do, I believe it will make it much harder for such elements to creep in and also enable an agile team to understand and leverage each other’s strengths so no one on the team becomes the "Elephant".

In agile software development, finding the right amount of detail and decomposition with stories takes teams a few iterations, possibly releases, to get comfortable.  It is a tough balance - we want the stories to be large enough that our product owner(s) understands what the story is for and the team understands the story contextually, yet we need the work small enough so that we can have confidence in estimating and so that we can get the story flowing through our feedback loop soon.  I want to outline briefly how I like to approach this in the hope that it may help some others.

Jeff Patton is one of my favorite people, an overall awesome dude, and his storymapping is such a beautiful tool that I wish more tools would naturally support it.  When I am working with companies, I use storymapping as means of helping people not only visualize their product but also as means of helping groups understand where and when to break down work.  If you haven't heard or used storymapping before, please do check out Jeff's blog posting on it.  Its ok, I will wait.

Cool, thanks for coming back.

When we start planning a product, it is most important for us to 'go wide instead of deep' - we want to create a view containing as much functionality of the product as we know right now.  Ideally we are binding / validating this work against personas, but in reality that isn't always the case.  However, at this level it doesn't make the most sense to think of every possible permutation of the work that could be done.  If my product was an online retail store, at this level I may say that we need some inventory administration functionality, ways for customers to purchase goods, and maybe some learning of the products we are selling.  Those 3 items are large, large stories - call them whatever you want, but there is potentially so much work in them that it doesn't make sense to stop there, even at a product planning session.  I would want more detail to start driving my release planning. 

From those three large stories, we would break those down into the next level of detail - how would a user administer inventory?  Well, they might need to see current inventory, see rate of sale, look at expected time for more goods, automate the restock process...and so on.  Repeat this for the rest of the larger stories, keeping our detail levels pretty consistent.  After this, as a product owner, I might be able to pick a subset of these stories and say that subset makes up enough of a product for it to be viable, lets do that.  Now the agile development team does relative estimates to give a rough set of expectations (which we will constantly refine).

At this point in the software development process, we have a contextual view of where we are going, have an idea of potential other work coming up in future releases, and have the stories (be it large) for our first release.  We enter our first sprint planning session; let's say we have the following 2 stories are in the sprint: check current inventory for a product, and automate restock process.  We do relative estimating across these stories and see that the check current inventory story is a 2 and the automate restock process is a 21 (working in points).  Since we value feedback, we are comfortable that the 2 point story is small enough to be deliverable in a portion of an iteration, but the 21 point story is far too large.  We retain the original story, but break it down into more stories. To automate the restock process we need to be able to create baselines of when to restock, we need to set up communication channels with one (possibly many) vendors, we need to communicate with accounting for paying, and we need to update inventory when new inventory comes in. We then size these new stories relatively and see what makes sense for our sprint, perhaps pulling 2 of the 4 stories in.  The rest go into our backlog. Once we have the stories for our sprint ready, we can do any further task breakdown as needed.

I have a few goals with this approach:

• Never decompose earlier than I have to. That doesn't mean don't ask questions; it means don't get too far ahead of ourselves.  A backlog is difficult to manage at 40 items, let alone 400.
• I always want to make sure my work is completable in a subset of a sprint while maintaining the context of what is trying to be achieved.
• I want time-effective meetings.  Nothing gets people disengaged quicker than long planning meetings.

Interested and want some pointers on how to start?  Try these:

• At each level of planning, create some baseline ranges the size a story needs to fit into to be 'enough'.  At a product backlog level, that is going to be high, maybe no maximum.  To go to a release plan, a story cannot be any larger than 20.  For a sprint planning session, no story will be over a 5.
• Timebox your planning sessions - for example at sprint planning we will spend up to 10 minutes discussing a story.  If it is still confusing after that, is there a subset we can extract and leave the confusing part for further investigation?
• Review these constantly and adjust.  Remember one size does not fit all.

Read more by Joel Tosi @ communalosmosis.com

We all know the story, right?  A chicken and a pig decide to create a restaurant.  When they are trying to decide on a name, the chicken says "I know, lets call it Ham and Eggs!"  To which the pig replies "Sure, easier for you to say.  You will just be involved, where I will be committed!"

This story was originally applied to Agile development by way of Scrum.  The idea is that some members of the team, the ones who have their "ham" on the line are pigs, and anyone else with a less central role are the chickens.  Why do we care to make this distinction? 

In a Scrum development process, the meetings that are prescribed are the Release Planning, the Sprint planning, the Daily Standup and the Sprint Review.  In each of these meetings, the only attendants who are allowed to talk are the pigs.  Chickens are welcome to attend, but in a listen only mode.  This style is a reaction to the meetings that we have all run into in any traditional software development project.  The manager, or a visiting executive, spends all the allotted time explaining his vision of the universe, and the development team doesn't get any real value out of the actual meeting.

What are some of the more common pigs in an agile team?  There are of course the programmers and the testers who are committing the software.  There are the documentation specialists and the IT folks who will be deploying the software.  Who are the chickens on an agile team?  Well there is the functional manager.  There is the product manager.  Some folks will say that in the standup the Product Owner is a chicken.  Once again, the idea is that in Agile if you aren't one of the folks actively writing/testing or deploying the software, you are a chicken.

At the risk of bringing yet another barnyard animal into the conversation, I think this is bull.  Project managers have a lot of commitment to the success of a software development project.  Functional managers' careers live and die by the success percieved or otherwise of the application development.  Rather than spend time giving people labels and deciding who is allowed to speak or not, a truly agile team should spend the time maintaining mutual respect.  A manager will respect her teams' time and not just run off at the mouth.  A programmer will respect her manager enough to understand that some of the important parts of a development project may have little or nothing to do with technology.  And everyone will respect each other enough to make sure that the discussion stays on track.  If and when it starts to drift, respectfully help each other back on track.

So what's the Rest of the Story?  The pig is committing himself.  The chicken is committing her children.  In the words of Will Smith's "Just the Two of Us":  "From the first time the doctor placed you in my arms, I knew I'd meet death before I let you meet harm."

Happy Fathers Day.