I'm frequently (weekly) asked by clients I visit, "Where doesn't an agile development approach work?"  Or, they tell me an agile approach won't work in their environment for numerous reasons.

In my experience, general agile development practices are superior when the problem domain is complex and/or dynamic, and solving the problem benefits from a more empirical approach.  This is true even with distributed teams. 

This is because in dealing with complex problems, the natural cognitive approach for human beings is to decompose the problem into smaller pieces, and work to understand the smaller pieces so that those pieces can enable an understanding of the whole problem domain.

The amusing thing to me is that this behavior happens within the phases of sequential, phase-based approaches to software development projects, yet the overall approach ignores this and tries to freeze the dynamic nature of the problem domain.  Agile project management expresses this idea up through its execution approach with the inspect and adapt cycle.
 
Does this require more communication/collaboration? Yes. Is this an issue with agile processes? No.  The same conversations need to occur to understand and allow requirements to evolve. It is a choice by the organization undertaking the problem whether they have the conversations or not.

If you have a problem domain that is simple, one where using the same sequential process results in getting the same outcome that is within your acceptable measure of quality, then use that approach.

I was just recently at a client that stated that agile wouldn't work for them because the high degree of complexity in their problem domain and because of their distributed team nature. They continued to explain that using waterfall enabled them to not have to communicate as much :-)

Waterfall software development methodologies allow people to sweep all types of process, organizational and interpersonal dysfunction under the proverbial rug and defer the problems this causes until the "death march" -- or in the worst case, after the so-called value has been delivered to the customer and they find dysfunction in terms of their needs not being met or poor quality.

So the next time you hear this question, consider whether the issue is the approach, or because of lack of discipline, lack of competence, organizational dysfunction or interpersonal dysfunction within your team; all of which, agile approaches are brutally blunt at pointing out.  Many just don't want to deal with the impediments and feel more comfortable "sweeping them under the rug".

When you’re starting your transition to agile project management (no matter what department you're in), don’t try to do everything at once – it just doesn’t work. When our marketing team decided to really start practicing agile we wanted to go all in. We failed miserably, even though we were set up for success in every way – we had buy-in at every level, the entire team had gone through ScrumMaster training. Hell, we were even marketing an agile software development tool. 

One of the first mistakes we made was trying to emulate our development team, who has practiced agile for years and had been working together as a team for a lot longer than we had. We figured that if it worked for them, it would work for us. As we’ve matured as a team, we have been able to incorporate a lot of their best practices, but it was just too much to bite off all at once. You need to build a solid agile foundation first.

Our next mistake (believe it or not) was trying to use our own tool to manage our projects. We had no problem messaging to prospects that a tool wouldn’t magically make them agile, but we weren’t following our own advice. We got hung up on all the bells and whistles of the tool before having a good handle on basic agile principles. We had to take a step back, and use whiteboards and sticky notes to manage our first few iterations.

We also made the mistake of trying to plan too much into our iterations. We were already behind on almost every project, and we assumed that agile methods would immediately make the team more productive. Even though we knew better, we didn’t take into account the drop in productivity that inevitably happens when you change the way you work. When we didn’t close out most of our stories in an iteration, it felt like we were falling further behind. Looking back, we were setting ourselves up for failure.

We finally realized we needed help with our agile adoption. Fortunately, we have access to in-house agile coaches. They helped us to slow down and transition iteratively. The team focused on a few important stories each iteration (we called them our big rocks), got into a standup rhythm and established team norms. Next we tackled tasking out stories and getting better at estimating. Now we’re working on fine-tuning our processes, but we’ll never really be done with our agile transition.

Just like most agile terms are defined in the context of agile software development, so is advice on how to overcome common agile challenges. Below is a list of a few agile marketing challenges we've dealt with, and some ideas on how to manage them.

Non-repeatable Work
Sometimes the work associated with a story can’t be used again – in software development projects, this might be considered technical debt. In marketing we tend to call them one-offs. The challenge is how to prioritize, plan and manage stories when the work is for one-time use. Obviously, eliminating (or limiting) one-offs is ideal, but not always practical. To address thes effectively, we first determine whether there is anything we could repurpose: The graphics are good but we need new content, or this was used in a partner campaign and with a few tweaks it could work for our direct sales team. Then we evaluate “bang for the buck” – if the project delivers enough value, it’s a go. Finally, we try to limit the scope of the project – just because we can, doesn’t mean we should.

Manual Processes
As in agile development projects, eliminating or limiting manual processes is ideal, but not always practical. Weekly campaign reporting was taking up a lot of time for some team members, because most reporting was manual. After doing a little digging, we realized that our product owner wasn’t really paying attention to weekly stats but found more value in monthly trends. We still look out for significant changes week-to-week, but don’t waste time with detailed analysis if everything is holding steady. We’ve also invested in tools (or upgraded existing tools) that have helped us automate reporting.

Outside Dependencies
These often come in the form of fixed dates (conferences/tradeshows, third party content or vendor deadlines) and outside feedback. Most fixed dates are known in advance and can be incorporated into upcoming iterations. For big projects such as product launches, or annual conferences, you might have entire iterations focused on creating the deliverables for that project. Last minute deadlines are trickier and often involve scope creep or adding new stories to an existing iteration – both involve the product owner changing priorities and moving things out of the iteration.

Have tips or tricks for overcoming your own agile marketing challenges? We’d love to hear them.
 

When I left my previous employer, one of my goals with my next gig was to have it expose me to other domains and environments.  I wanted to get different perspectives, see agile development at different scales, help spread successes as well as see the challenges, and assist where I could.

I've been doing this now for a bit and I can tell you a few things for certain -

• The answers are far easier than the implementations
• You are not alone in your struggles
• People are succeeding even though they might not be considered 'agile enough'

The answers are far easier than the implementations

'We have a large amount of dependencies in our software development projects.'
'Reorganize your work so you don't have dependencies anymore.'

'Our testing and regression takes too long.'
'Test sooner and automate as you go.'

'We have a large amount of dependencies across agile teams.'
'Create cross-functional teams that are customer focused to remove dependencies.'

'We have an international, cross-time zone development team so stand-up times are impossible.'
'Restructure your agile teams so everyone is together.  Oh, and get rid of all the walls between members, make sure everyone is pairing, and for bonus points make sure everyone is using a PowerBook and they sit on beanbags.'

My team and I are frequently asked for advice or pointers with some very common agile or organizational problems.  While I personally like the discussion, the reality is I hate the answers.  I hate the answers because it's the easy out.  Looking at problems and providing a solution is easy. Even helping create a plan to address the problem is easy.  Implementing the solution or plan is hard, rife with unforeseen problems, potentially painful, and most definitely will take a long time.  Providing an answer or a plan takes a few minutes to an hour.  To implement these solutions and actually have them stick will take a large amount of time and commitment.  Do you want to address quality issues?  You can't just train people in TDD and test automation and expect everything to fall in place.  Chances are you will have to look deeper - look at your hiring practices for example.  Are your interviews focused on obscure API calls or are they focused on quality?  How do you create an organization that actually cares about quality, and by doing so not create one that is scared of the ramifications of creating an unforeseen bug?

If you work in a traditional matrixed organization, trying to create cross-functional agile teams isn't as simple as creating a team and telling them go.  There will be headcount issues, territorial issues, domain knowledge and specialization concerns that have to be addressed.  You might actually be worse off for 6 months or a year - can you commit to that and see the light at the end of the tunnel?

An answer or a plan will take substantially longer to implement and you will need to adapt it as you go.

You are not alone in your struggles

There are many organizations, sick of late and over-budget projects, that are trying to adopt more agile practices.  They read of the benefits - transparency, responsibility, better quality, cost savings.  You can't just wave your hands and these things happen.  The larger and older the organization, the chances are there is a high number of existing items that will challenge change as well as agile project management.  People struggle with expressing work in stories and planning.  Going from large requirements documents to story writing with examples is challenging.  It requires focus on output instead of pixels.  Now take that a step further and try to lay those stories out into a plan, and it's enough to want to give up.  But don't; its hard for everyone and you will get there.

I see struggles with how to realign testing (a group that has been on the back-burner for far too long) with development and the core product.  I see consistent struggles with quality as well as supporting legacy applications.  If you fall into any of these boats, realize you are not alone.  There are far more struggling with these changes than there are who are wildly successful with minimal bumps in the road.  You will get there.
 

People are succeeding even though they might not be considered 'agile enough'

It's common for organizations to say, 'We are trying agile development practices, but aren't quite there yet.'  Steve Ropa wrote an excellent short post on this topic.  The reality is you don't have to be following 'prescriptive agile' to be successful.  I've seen organizations that still have 4-week iterations, but this still has allowed them to cut product delivery time in half.  There are teams succeeding without cross-functional teams or without millions of test cases.  It's a journey, and if it is working for you, keep doing it.  If something isn't working, try and address it.  Understand why you want to change something and work on it, but be realistic.  Some things are hard, don't be dismayed by that.

As you try to change your practices, celebrate your successes while acknowledging your challenges.  Far too many of us forget to celebrate our successes.

When practicing agile project management, defining “done” is critical. It’s often the product owner’s job to define done in the context of value delivered to the business. Defining done in software development projects can be fairly straightforward – there’s even a checklist. But is any project ever really done on an agile marketing team? Of course you can always be improving your website or tweaking your messaging, but there’s a point at which you have to call one project done so you can work on new ones. On our agile team we’ve come up with some standard terms we use in iteration planning to help us define done.

Define
When we have larger projects (Epics), the first story is often focused on defining the project – who, what, where, when. We also use define when we’re unsure of the amount of work involved – also known as a Spike. Typically, define stories involve brainstorming or research, identifying tasks for future stories and uncovering any impediments that would prevent or delay the project. Define stories are done when the results/findings are reviewed with and accepted by the product owner.

Draft/Design
If the scope of the project is well known (i.e. we’ve worked on a similar one before), we skip define and start with drafting (messaging, content outlines, ad copy, etc.) or designing (sketches, mock-ups, wire-frames). These stories usually have feedback or review tasks that the story owner manages. Be aware of how many draft/design stories you have in an iteration to avoid overloading team members (we tend to do that to our designers) or having team members stuck waiting for feedback. Draft/design stories are done when the content and/or images are approved by the product owner.

Deploy
Deploy is pretty straightforward – it’s deployed (live) or at least deployable (able to be pushed live at any time). Deploy stories often also include staging, testing, proofreading, and final buy-in from the product owner. Be aware of how many deploy stories you have in an iteration (especially if they involve outside deadlines) so you can better coordinate work across the team. It’s also important to know upfront if projects require ongoing work, so you can define done for this phase and plan for additional phases in later iterations.

Not every story we work on fits neatly into one of these buckets, but it’s been incredibly helpful to have the entire team being on the same page when defining done.

The initial training that our organization will focus on is agile values, principles and practices. This training should target a wide functional band of the organization, including senior management, middle management, and team leads as well as software dev, QA, Business Analysts, Project Managers, Program Managers, Product Managers, HR, and Production Ops. Training the different parts and functions of the organization is essential for all involved to understand their roles and responsibilities in the new agile project management approach. There will undoubtedly be fear of change and cynicism, but without training and the opportunity to hear and address fears during the assessment, this fear can become insurmountable. It is also essential to allocate adequate time and funds to execute the training in a quality manner. 

Following the education of the organization on agile values, principles and practices, we’ll need to assess the impacts that successfully adopting them will have on the organization.  It is only after folks are exposed to what agile is all about that it can sink in and allow them to better assess their attitudes towards the transformation to agile.  Can you see the mini-Deming Cycle going on here? :-)

This is an excellent time to engage an external agile coach to help facilitate discussions around fears and misunderstandings, and provide real-world examples of how others have faced the same challenges and succeeded.  The agile coach can work with each of the functional groups, at each level, to determine their concerns and explore possible solutions.  An agile coach can also help ensure that each functional group is prepared for the coming pilot projects – I suggest preparing a readiness checklist. Begin to plan for quick, simple, first-cut solutions to a wide range of concerns.  And once again, avoid big up-front planning, don’t go too deep yet.

In my opinion, building a group of internal agile coaches should be in the agile adoption plan of any reasonably large organization.  This allows the organization to develop its own 'agile mythology' that is passed down by word of mouth, not unlike tribal lore in more primitive cultures.  It embodies the organization's own unique context.

Having the assistance of external agile coaches during the planning and execution of the agile organization releases is essential. As the organization matures through their releases, the need for external agile coaching should diminish to the point of just having check-ins with the organization's own internally grown agile coaches.

As with a lot of agile project management concepts, understanding the value of feedback isn’t hard, it’s managing the process that can be challenging. In agile software development, gathering and managing feedback is traditionally handled by the product owner. In agile marketing, the product owner can quickly become a bottleneck (impediment), so on our team, story owners often take on this responsibility. Below are some Do's and Don’ts – these aren’t hard-and-fast rules but merely suggestions based on our team’s successes and the rat holes we wish we could have avoided.

Do's and Don’ts for Planning and Managing Feedback:

• Do add tasks in stories for feedback loops or review sessions to help track progress and identify potential impediments.
• Do try to keep the feedback rounds to a minimum (no more than 2-3) so you can actually get stories completed within the iteration.
• Do take into consideration who (inside or outside the department) may be providing feedback when planning stories so you can involve them early in the iteration.
• Do limit the number of people involved so that consolidating feedback is easier – we all know what can happen with too many cooks in the kitchen.

• Don’t plan too many stories in an iteration that require outside feedback – it’s easy to get stuck waiting around without much to do.
• Don’t wait until the last minute for feedback from outside stakeholders or the team - it’ll most likely just piss them off and you won’t get what you really need.
• Don’t incorporate feedback just because it came from someone “important” – if it’s a good idea, go for it but don’t forget to “put your marketing hat on”.
• Don’t just go through the motions of asking for feedback and then not follow up – no one likes to feel like their time was wasted.

Have your own feedback Do's and Don’ts? We’re always looking for ways to improve our agile processes.

In my experience and based on discussions with some of my peers in the agile development community, one of the most important criteria for success with agile is that it have a fertile environment to take root and grow.  In an organization this can be best characterized by executives that are willing to provide and support an environment for learning and adapting, which enables continuous improvement. Executive support for the pilot projects to serve as learning opportunities is essential, and as we know, we learn more from failure than success.  This requires the fertile environment that fosters learning and adapting that I mentioned above.

Once you can secure even a microcosm of the this type of environment, then you can look for projects that can meet the following criteria. 

Pilot Projects Should Be Visible & Meaningful
Don't be tempted to select pilot projects that are off the radar and of little importance. You are just inviting those fearful of change to sabotage your efforts because the cost is low to them and the organizations. Be sure to pick projects for your pilots that have visibility & meaningful impact to the business.

Early agilist and inventor of the Adaptive Software Development process, Jim Highsmith, probably put it best in Agile Software Development Ecosystems: “Don’t start with an initial ‘learning project’ that is of marginal importance. Start on a project that is absolutely critical to your company; otherwise it will be too difficult to implement all the hard things Scrum will ask of you.”

Of course if your efforts are more grass roots, the level of criticality will have to be balanced because it can be difficult to get stakeholders to take a risk when they aren't yet educated on the benefits of agile. In other words, they may be missing the reward data when they intuitively perform a risk/reward analysis.

Another important criteria for selecting candidate pilot projects is project length. Look for projects that have a relatively short release time line, preferably less than 90 days. This makes it easier to demonstrate the delivery of value and keep momentum and interest high. Nothing makes converts quicker than successful delivery of value; getting early and frequent ‘wins’ is important.

Once you've identified some candidate pilot projects, now you need to consider your ability to staff the key roles.  You don't want a critical project to be your pilot project if you can't put 'A' players on it that are dedicated and committed to its success. Let's take a look at the key roles.

Product Owner Role
It must be understood that the Product Owner is perhaps the key role to staff with strong players to help ensure your pilot project's success. This role must be committed to the project and empowered to decide on scope and schedule.

From my experience, not having a strong product owner role that is deeply involved with and available to the team, and who is empowered to make decisions about scope and schedule control, is usually one of the main impediments to success with agile.

I refer to the PO as a ‘role’ because it is unlikely to be one person in a successful scaled effort. Once we have secured the right player for the Product Owner role we need to ensure the availability of a dedicated and cross-functional team.

Dedicated Cross-Functional Team
To help demonstrate the true capabilities of an agile team, it is important that the team for our pilot project(s) be cross-functional, with representation from Dev, QA, UI, business analysts and if appropriate, tech writing.  Another advantage of starting out with a cross-functional team is that they will all get educated and indoctrinated into agile and will take the message back to their functional constituency to help get others at least curious about trying out agile.

Our cross-functional team needs to be dedicated to the pilot project effort. If the pilot team is split amongst multiple projects, this has a high probability of failure. It puts at risk the trust the team has with respect to the organization's commitment to the change, it will effect the commitment of the team and it can compromise the team’s velocity.



Scrum Master / Agile Project Manager
The final role that we must be sure to select wisely is the Scrum Master (if Scrum has been chosen as the agile project management framework) or the agile project manager. This individual needs to have a strong understanding of agile project management and the approach the team has selected.  They also must have strong facilitation skills. 

Additionally, it is highly useful for this individual to have experience with escalating issues in their organization and know the right people to get things done. This will be vital in their agile role on the pilot project, as they clear the impediments for the team to allow them to be as productive as possible.

Summary
With our candidate pilot projects identified and available staffing considered, we should now be able to select the specific pilot project(s) that will have the right visibility / important and the right staffing to maximize our chances for success. In part 5 of Using Agile to Scale Agile, we'll discuss agile assessment, education and coaching for our pilot project pilot team and the wider organization as part of our overall Agile Transformation efforts.  Stay tuned...

Pretty much everyone outside of marketing thinks they could be in marketing, and they often think every idea they have is the best ever. Sometimes the best ideas do come from outside of marketing – so do some of the worst. Embracing the agile project management concept of getting feedback early and often can be challenging in marketing but extremely valuable. The trick is asking the right people for the right type of feedback at the right time.

Who are the Right People?
In agile marketing, as with agile software development, getting feedback directly from your target audience (i.e. customer) is always ideal. If you don’t, it’s important to have someone represent the customer – especially when the team is working on a highly visible project (ad campaign, major website changes, new product messaging, etc.). Other stakeholders from sales, support and training can also provide unique perspectives and great insights. Don’t forget about your team members. Your team is a great resource for feedback – they should be sitting right next to you and often know the larger context of the project.

What is the Right Feedback?
Getting the right type of feedback relies heavily on asking the right questions. The more specific you can be, the more focused (and potentially valuable) the responses will be. Your target audience can help with things like determining key messages (what are the most important benefits) and how to present them (what’s the best way to deliver the content). Stakeholders often help determine requirements, so getting their ideas on what might be missing or overlooked can often be valuable. Team members are great for brainstorming, narrowing down ideas, consistency, and are especially helpful when you just get stuck.  

When is the Right Time?
Timing often relates directly to who is giving the feedback and what type of feedback you’re requesting. Brainstorming upfront with your target audience can help ensure you start in the right direction, and closing the loop before your deliverable is final makes sure you didn’t miss the mark. Including stakeholders in the process up front for requirements, and again once ideas are thought out (but before they’re final), can help gain buy-in. Getting feedback from your team along the way can help you continuously improve the end product.

Just because you ask for feedback doesn’t mean you always have to take it. Our product owner likes to tell us to “put on our marketing hats” when trying to determine what feedback to use. The next challenge is managing the process so you can actually get stuff done in the iteration.
 

I did a presentation last month at the Agile Denver user group.  It was a great time, and there were some great discussions around what it takes to transition to agile software development.  One key item that came up is the question of self organizing teams in agile.  I have seen this discussion many times, usually around why project managers and "line" managers are obsolete in the agile world.  I agree that self organization is a fantastic goal, and uniquely suited to the agile mentality. My question is, does every extreme programming  or scrum team really self organize?  Also, when is it maybe not a great idea to aim for complete self organization?

Let's look at a couple of times in history when self organizing teams were tried.  So we are going to step into our way-back machines to the heady days of the French Revolution.  The people storming the Bastille; The barricades in the streets of Paris, Jean Valjean singing "Bring him home"!  After the new government was formed, the entire European continent formed armies to crush these republicans before the scourge of democracy would spread.  The French Army had to be able to defend the new Republic.  Of course all of the officers were from the aristocracy, who were too busy losing their heads.  So the armies elected new officers.  Each unit voted for their favorite soldiers to become officers, no matter what their experience was.  And if the soldiers didn't like what the officer told them to do, they voted him out and elected a new one.  As one might imagine, this was not a terribly successful organization.  Eventually a young Corsican named Napoleon turned this around, but only after abandoning the principles of the Revolution and establishing himself as a dictator.  A very similar sequence of events happened in Russia in 1917, with a similar unsuccessful outcome.

Now, am I saying that not only do agile teams not need to self organize, but that they need a dictator with his hand in his vest?  No.  What I am saying is that the idea of self organization needs to meet with the reality of the world around us.  In many cases, a team can organize themselves.  Sometimes they need a little help.  Sometimes all they need is someone to act as the representative of the team to the rest of the business.  In most cases, this person is selected based on a set of skills that is not necessarily the same that makes the person a successful programmer or tester.  That does not mean that they would not be successful leaders.  It would be best if the agile team had a vote in who was selected, but by no means should the selection be limited to just the team.  The folks who will be interacting with the team need a vote too.

In the long run, most agile teams work within a larger corporate structure.  Having someone who can navigate such a structure is highly useful and desirable.  Having someone who can do the hard personnel-oriented things like hiring and firing, or the more enjoyable but time consuming things like nurturing and mentoring, is a Good Thing.  This person may be a Coach, or an Advisor, or in some cases even.....<gasp> a Manager!

I've said it before, and here I am saying it again - Change is hard.  The largest obstacle to any organization looking to adopt more agile development practices is that transition - we are creatures of habit and now we are being asked to do something else.  One of my favorite 'Agile Dudes', David Hussman (www.devjam.com) talks about Dude's Law - Value equals 'Why' divided by 'How' (V = W / H).  The point here being that the more we can focus on why we are doing something rather than how to do something, the more value we will get from it.  When we look at agile adoption, keeping Dude's Law in mind will help with the pain of change - explaining to our co-workers why we are looking to do something, instead of telling them the new way to work will be better accepted and ideally lead to an environment that promotes continual improvement.  With that being said, I wanted to put together a quick list of some items you might be interested in trying, and why you would want to do such practices.

Short, focused, development cycles
Why would you want to have short, focused development cycles (called sprints or iterations)?  For a few reasons.  If you are struggling with late discovery of defects or need your product development to be more open to change, you may want to consider shorter development cycles.  The later a defect is caught, the more costly it is to fix it. When we find a defect before much code is built on top of it, it can be fast to fix.  If we find the issue after it is in production, there might be a ripple affect as well as impact to our customers.  Additionally, the more frequently we can ask our customer 'Is this what you were thinking?' the easier it is to course-correct our product and end up with what the customer wants.  Finally, having product-focused development cycles allows us to take cross-cutting rips into the software to get real, deliverable progress happening.

• As a developer, short, focused cycles help me know if my code is delivering to expectations.
• As a tester, short, focused cycles help make sure I don't get overrun with testing 2 weeks prior to a product launch.
• As a product owner, short, focused cycles help me see the product emerge and course-correct with lower cost and impact.

Quick daily meetings to check the pulse of the team
You have enough meetings, why would you want to have an additional meeting every day to see how the team is doing (called daily standups)?  If your development teams spend more time 'waiting for help', whether it be answering a question or assistance from a peer, a daily check-in might help.  This daily meeting allows agile teams to get together to see if they have anything (questions, environment issues, etc) that is affecting their availability to complete the work they committed to delivering for this development cycle.  It also allows the team to see if anyone needs help, even if they aren't openly asking for it.  It is not meant to be micro-management, its intent is to focus on whether or not the team is going to be able to deliver on what they committed to.

• As a developer and a tester, daily meetings help me raise any issues I have and get them resolved as quickly as possible.
• As a product owner, daily meetings help make me aware of any questions holding up the team, and answer them immediately and in context.

Project an understanding of when something is 'done'
During the software development process, why would you want to talk about functionality, with examples that show intent and create an understanding of when something is done?  This approach gives us a very binary way of looking at work.  When work is either 'done' or 'not done', it's very easy to measure progress.  With this approach, a piece of functionality isn't 85% complete after 1 week and 86% complete after a month. Instead it is either done and accepted as working by a customer, or not working with examples of how to get it accepted.

• As a developer and a tester, a common understanding of done with examples helps provide me with context and helps me focus on the work to be delivered, instead of the possible permutations I can come up with.
• As a product owner, a common understanding of done with examples gives me confidence that what I am looking for is what I will receive. Combining this with short, focused development cycles lets me verify that the team is all on the same page.

Automated Testing
Why would you want to automate your testing?  Testers are far better at finding new and interesting ways to test your application beyond repeating common functionality repeatedly. If you find that your agile testing team is spending more time than they would like redoing the same work, you might want to consider automation.  But lets be honest - some testing cannot be automated, or is simply far too costly to automate for it to make financial sense.  For the rest of testing, we would want to have automated testing in place to tell us as soon as possible when something has either been completed successfully or has been broken by a change.  Automated testing is not 'automate everything and run it all the time' - it is automate what makes sense, and run it as frequently as it makes sense.  This might mean that some tests run with all builds, some run every night, and some run with every formal build and deploy.

• As a developer and a tester, automated testing helps me focus on quality, and notifies me as soon as possible if problems are arising.
• As a product owner, automated testing helps me visualize work complexity and effort.

Continuous Integration
Why would you want to have your code compiled and any automated tests that can be run against it executed, every time a piece of code is committed?  Similar to the reason for short development cycles, look at continuous integration as providing feedback into your short coding cycles.  The goal with continuous integration is to find out as soon as possible if our code is breaking anything else.

• As a developer and a tester, continuous integration helps me know how well the team is delivering code dependent upon each other.

Relative Estimation
Why would you want to estimate all of the work needed to complete a project relative to other work in the same project, instead of just committing to milestones?  Estimating software development projects is hard, and the further we go out in time and duration, the closer to impossible it becomes.  If we are having problems with the timeliness of our deliverable, we may want to look at estimating work relatively. This way, after some portion of the work is completed, we can extrapolate how much longer it might take to complete the whole project.  This allows our team to have more meaningful and real dialogue.  It should also lead to more realistic expectations.

• As a developer and a tester, relative estimating helps me provide visibility into the effort required to complete a project that actually takes into account work distractions - other projects, context switching, organizational meetings, support, etc.  As a developer and a tester, relative estimating can be my voice of reason.
• As a product owner, relative estimating helps me understand what pieces of functionality are most difficult and helps me balance the cost of functionality versus the benefit of having it in the product.

With the exception of automated testing and continuous integration, notice that these other items are valuable in the context of any work that needs to be delivered - whether it be creating a marketing campaign, recruiting, or doing housework.

Do any of the above items sound like a problem you would like to solve?  Then you might be interested in looking into some of the 'how' (practices) that assist with these 'whys'.

For more on Dude's Law and David Hussman, check out his website at www.devjam.com or follow him on twitter @davidhussman.

David has posted his thoughts on Dude's Law and other things here - http://devjam.com/dudesblog/dudes-law/

At first, agile project management can seem like numbers game. How many people on a team? How long is an iteration? How many points for a story? What should our velocity be? But it’s not the actual numbers that are important, it’s figuring out what works best for your team and getting into a rhythm.

Team Size Matters
Too big, and one of your main impediments will be just getting through iteration planning. Too small and you may not have enough resources on the team to get much done. But what is too big or too small? The rule of thumb in agile development is 7 plus or minus 2. I think it works well for agile marketing too – if you have less than five people on your team, don’t worry, just try not to split larger agile teams into very small groups. We’re getting to the point on our team where we’re starting to consider the pros and cons of splitting into multiple teams or staying as one. It would be easy if there was a natural split (front end UI versus back end database, or along product lines), but we tend to share all kinds of work across the team. Nor do we have the equal distribution of skill sets needed to split the team down the middle. One thing I would caution against is sharing members across teams – this has a tendency to create bottlenecks, and provides an easy scapegoat for when stories don’t get closed.

One Week, Two Weeks, Three Week, Four?
Determining how long to schedule your iterations can be tricky. One week is rarely enough time to take a marketing project from start to finish (at least for us), and four weeks can be overwhelming (and not always practical) from a planning perspective. We had the luxury of having in-house agile coaching to help us settle on a two-week fixed iteration. Two weeks allows us enough time to complete work and account for changing priorities, without feeling like we’re constantly starting and stopping. But don’t take my word for it – try different iteration lengths on your marketing team. The import thing is to find what works and stick with it.

1 Plus 1 Doesn’t Always Equal 2
Much has been written about estimating so I’m not going to get into the pros and cons of story points versus ideal days versus shirt sizes. What I will say is that marketing projects aren’t always repeatable – we tend to like to try new things – nor can they always be comparable. Something that is “easy” might take days to complete or involve multiple team members, while something that is “complex” might be done in a few hours by one person. One thing we’ve started to do in our planning meetings is to write down each story on a sticky note so we can visualize like-sized stories together. It helps us determine if a story is a 3 or a 5 by comparing the work involved – it relies partly on gut feeling, but has helped us a lot.

No one can tell you what your velocity should be. It’s an individual team thing and pretty much has to be trial and error. It usually takes multiple iterations to stabilize your team’s velocity so don’t freak out when you get very little done in one iteration and a lot the next. Again, it’s all about getting into a rhythm.

• Productivity
• System quality
• Flexibility
• Collaboration level

• Contract for a process that leads to a result instead of for a specific result. Targeting a specific result doesn’t allow for change / improvement. You have to have been right up front (rarely the case).
• Close customer collaboration is more important than contract negotiation, so the project can fulfill your business objectives instead of your lawyer's.
• Agile contracts should maximize the efficiency of software development and thus minimize the risk of a lawsuit occurring.
• Identify what to contract first. This should be done by those who understand agile processes and the value the customer is truly looking to have delivered. Once this is understood, then consult your lawyer to put it into legal-speak.

• Minimize dependencies
• Train everyone on common team practices & tools
• Integrate work on regular basis
• Consider integration teams
• Deliver value through vertical slices of architecture
• Include outsourced partner on customer feedback and continuous improvement

Physical changes can have a huge impact on behavioral changes. The opposite is also true – without physical changes, behavioral changes can often be more difficult. Shared workspace is a principle of agile software development, and it's just as important to agile marketing teams. In order to get your team working closer together, you need to get them in the same physical space (more to come on managing remote team members). Get people out of offices and take down cube walls - it's worth the time and effort. An open workspace helps force team members out of their silos, and is the first step in creating a collaborative environment.

Even though open space is shared, it’s important to encourage agile teams to make it feel like their own. In our team room, we have 2 ½ foot walls attached to our desks that we’ve each decorated in our own style. We’ve added decals to the walls and even have a mini disco ball hanging from the ceiling. Our dev team makes fun of us, but secretly I think they’re just jealous.

Marketers love to have meetings, so set up a place in the middle of your team room for meetings. It’s also important to have a designated space for daily standup. It allows other team members not in the meeting to overhear what’s being discussed, and provides space for impromptu brainstorming/collaborating sessions. This makes it easier to stay tuned in to what’s going on with other stories, and allows others to provide valuable information and feedback even if they aren’t technically in the meeting.

Another important element in an agile team room is a visual information radiator (a fancy name for a storyboard or taskboard). It can be as simple as a whiteboard or card wall, or a more elaborate electronic version. If you have a designer on staff or you have a little money in the budget, this can also be a great way to add some creativity into the team room. But having a visual way to track progress during an iteration can make all the difference. It’s also a great way to keep standup on track by focusing the team on what they worked on yesterday and what they’re going to work on today.

Creating a fun, open environment sets the tone for agile teams and helps reinforce collaboration, a key agile tenet. And who better to create a kick-ass team room than a marketing team?

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?