Once again we are going to Kiev for Agile Eastern Europe Conference which will run this Autumn (8-9th October). Last edition was a great event and we expect this year to be even better. It’s enough to look at the speakers lineup, to be sure that Agile Eastern Europe once again will become a really international event:

• Mary POPPENDIECK (USA)
• Henrik KNIBERG (Sweden)
• Danko KOVATCH (Israel)
• Marc LOFFLER (Germany)
• Paul KLIPP (Poland)
• Anda ABRAMOVICI & Sudhindra RAO (USA)
• Robert DEMPSEY (USA)
• Vasco DUARTE (Finland)
• J.B. (Joe) RAINSBERGER (Canada)
• Mack ADAMS (Canada/France)
• Robin DYMOND (Canada/USA)
• Yves HANOULLE (Belgium/France)
• Monika KONIECZNY (Poland)
• Andrea HECK & Tibor VIDA (Germany & Hungary)
• Allan KELLY (UK)
• Dr. Johannes MAINUSCH (Germany)
• Sergey DMITRIEV (Norway)
• Piotr ZOLNIEREK (Poland)
• Sergei ANDRZEEVSKI (Russian Federation)
• Andrea PROVAGLIO (Italy)
• Pawel LIPINSKI (Poland)
• Nikita FILLIPOV (Russian Federation)
• Pavel GABRIEL (Belarus)
• Artem SERDYUK (Ukraine)
• Mikalai ALIMENKAU (Ukraine)
• Timofey YEVGRASHYN (Ukraine)
• Michael NORTON (USA)
• Pawel BRODZINSKI (Poland)
• Francois BACHMANN (Switzerland)
• Jurgen APPELO (Netherlands)
• Zsolt ZSUFFA (Hungary)
• Gwyn MORFEY & Laurie YOUNG (UK)

We are proud to be once again to support the conference as a Bronze Sponsor, so if you use tinyPM, think about using it, want to talk about the tool, it’s capabilities and your need, then Kiev will definitely be a place where you can push us to the wall and ask all the hard questions.

If you haven’t decided yet to come, go on and REGISTER now!

• Tweet This!
• Post on Google Buzz
• Add this to DZone
• Share this on Facebook
• Share this on Reddit
• Digg this!
• Share this on LinkedIn
• Share this on Technorati
• Share this on del.icio.us
• Share this on FriendFeed
• Add this to Mister Wong
• Submit this to Netvibes
• Add this to Ning
• Stumble upon something good? Share it on StumbleUpon
• Add this to Wykop!

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.
 

How would you like to be able to SMS or tweet your Excel data-crunching code?

With Docjure, it is possible:

(->> (load-workbook "spreadsheet.xlsx")
     (select-sheet "Price List")
     (select-columns {:A :name, :B :price}))

This reads the A and B columns from the Price List sheet in the spreadsheet.xlsx file into a list of maps where the a column has key :name and the B column has key :price.

I believe that is pretty good for code small enough to fit in an SMS.

Exporting your business data to spreadsheets for further analysis is just as easy:

;; Create a spreadsheet and save it
(let [wb (create-workbook "Price List"
                          [["Name" "Price"]
                           ["Foo Widget" 100]
                           ["Bar Widget" 200]])
      sheet (select-sheet "Price List" wb)
      header-row (first (row-seq sheet))]
  (do
    (set-row-style! header-row (create-cell-style! wb {:background :yellow,
                                                       :font {:bold true}}))
    (save-workbook! "spreadsheet.xlsx" wb)))

In just a few lines of code and you have exported the price list to a worksheet, complete with a yellow-background bold header line for extra style points.

In our business applications, bridging to Excel has provided huge benefits:

• Users love it - having their data in Excel enables them to do much more than a static report that can only be changed by a software developer.
• Developers love it - It eliminates a lot of tedious code for generating bespoke reports as we can easily export data into an Excel report template.
• Project managers love it - using spreadsheets provides an easy to understand data exchange format and the flexibility to change reporting features quickly late in the project.
• Sponsors love it - the project saves a lot of time and reduces training cost by leveraging an application the users already know.

As an inspiration, here are some of the things we have used it for:

• Use Excel to calculate currency trading strategies - the traders calculate their currency trading strategies in Excel then import it into the trading system. They benefit from the flexibility of a powerful tool they already know and the trading system takes care of the technical details of the actual trades.
• Exporting to Excel for bespoke analysis - would you like to check your currency trading record? Export all the information to Excel and the traders can slice-and-dice it easily with little or no technical assitance. This is much easier than setting up a reporting database for them to link to.
• Using Excel sheets for content management to facilitate translation - translating an application to all the languages of an international enterprise was easy. Rather than using complex technical XML-files we made Excel sheets the data format for the application strings and had the subsidiaries add their translations to that. Then we put an adapter on the application to convert back and forth to XML-config files and RESX files used internally in the web and Silverlight parts of the application. The translators had a great experience, they had a familiar tool with spell checking and it reduced waste in the translation process by presenting a well-known easily accessible format.
• Exporting to Excel for reporting - set up a spreadsheet template with a data sheet and some reports based on that, then populate it with data from your application. This allows the users to easily change or add reports with no change to the software application itself, thus dramatically reducing the turn-around time for new reports. 

We believe this is so great that we just have to share it:

Therefore, Docjure is free and open-source.

It is written in Clojure for the JVM. Get it at our GitHub page here: http://github.com/ative/docjure and be sure to follow our updates on Twitter: @ativedk (http://twitter.com/ativedk)

It's fast, it's fun.  It powers your planning.  It tames your tickets.  It's the upgraded Agile Planner, our AJAX interface for adding tickets, building stories with tasks, and scheduling them into milestones, iterations, or releases.  For more details, please watch the video, or just select the “Agile Planner” link in the Tickets tool menu, and try it.

During the last year, many users have told me that they use the agile planner every week with their team.  So what is NEW in the Agile Planner this month? 

* It’s fast.  Drag and drop is smooth.  All tickets are loaded into local memory for instant access.  New layouts for “Milestone | Detail” and “Story | Detail” remove EVERY CLICK between mousover and seeing the detail edit form.

* Open tasks and subtasks to unlimited depth, in the Story/Feature column.  This “hierarchical ticket view” was one of our most requested features, with over 300 votes.

* Enter a list of tasks with the same attributes, using a new pop-up UI.

* In-place editing of estimates.  Just click on the number and edit.  The estimates add up correctly for complete features or milestones.

Incremental development is important

The Agile planner will help you with roadmapping, which I described in my article "Save the best for first".  It's a simple way to get what you want, fast, using incremental development.  We write down everything we want to do, and then we sort it by priority, and we try to find the minimum set of high-priority stuff that will get us a great release as soon as possible. 

A whole industry has grown up around incremental development, represented by Agile, minimum releasable product, lean startups, and even behemoths like Linux, which started as a student project. 

Sometimes, a planning view can be one of the biggest obstacles to this process.  If you write a view of your project that shows a feature listed under a milestone or release, and subtasks for that feature, it starts to force you into thinking that you need to finish everything before you can release.  You start to forget that you are in charge, and that you can release a simple version before you release the complete version.  In the Agile Planner, we separate the your grand plan in the Story/Feature view, from the schedule in the Milestones view.

How can you use the Agile Planner?

Use it with a client or business owner to launch a project.  It’s fun to see a plan take shape, which builds the relationship.  If you run a good roadmapping session, you get a big head start on the implementation, which is the biggest revenue earner. 

Use it with your team to plan iterations.  Many Assembla users sit down as a group with the agile planner each week or each month.  I have seen distributed teams do this with screen sharing tools.

Distribute planning.  I like to create a top-level story, and then ask the developer to fill in more detailed tasks.  It makes the developer feel more confident, and it makes the work more visible.

Many of our users like to sort their tasks into a very specific order.  Agile Planner gives you that control.

 

Here's a quick video of the Agile Planner, so you can see it in action.

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.

There appears to have been a data center outage early morning, affecting a number of applications including Pivotal Tracker. This has caused connectivity problems for users in some locations, and it appears to still be persisting for some.

We're working with our hosting provider to get this resolved as soon as possible, this is our top priority.

This is the second data center outage this week. At the moment, we do not have enough information to know whether the outages are related.

Also, we have received reports that Tracker has been unreachable from certain parts of the world (including China) since the migration to a new data center last week. We've filed a request with Engine Yard to investigate, and hope to have this resolved soon.

Our apologies for the inconvenience these outages have caused. We'll post more information here as we receive it. You can also follow @pivotaltracker on Twitter for updates.

By Steve Miller

Many of us have experienced projects that drag on much longer than expected and cost more than planned. Companies looking to improve their software development processes are now exploring how Agile can help their Enterprise more reliably deliver software quickly, iteratively and with a feature set that hits that mark. While Agile has different "flavors", Scrum is one process for implementing Agile. This newsletter is one in a series of newsletters that will discuss the Agile Scrum process and will end with variants of Scrum that can be used to aid in improving your software releases.

Team Composition

Managing Scrum development requires a major change in how teams work together. In traditional Waterfall development, teams normally have a project sponsor, a project manager, analysts, designers, programmers, testers, and documentation specialists. Each team member has specific duties which normally do not normally overlap and they have a specific reporting structure (most team members report to the project manager).

With Scrum, you have just 3 team roles and is normally limited to 7 or less individuals (however, you can have multiple Scrum teams in sets of 7 or less):

• Product Owner - This is the person that identifies and prioritizes the features that will appear in a 30 day sprint. This is normally the Product Manager, CTO, in some cases the CEO, or some other high level stakeholder that ultimately is responsible for shaping the roadmap of their product. Before a sprint begins, the Product Owner communicates the goal of the sprint to the team and what features should be analyzed for the release. This does not mean that all the desired features will make it into the sprint, the team estimates and prioritizes items for the sprint (during the Sprint Planning sessions), and only the items that can fit in the sprint are done.
• ScrumMaster - The ScrumMaster is akin to the Project Manager in Waterfall environments, but does not manage the team deliverables at a micro level. Instead, this person is responsible for ensuring that the 30 day sprint stays on course, no new features are added to the sprint, code inspections happen, and ensuring everyone plays by the rules. The ScrumMaster coordinates and runs the daily sprint meetings. The ScrumMaster is not a task master, they are a leader that empowers the team members to deliver the assigned tasks and to help eliminate roadblocks that slow them down.
• The Team - With Waterfall, a team consists of analysts, designers, testers and documentation specialists. With Scrum, each team member is empowered and expected to self-manage themselves and to participate in all duties needed to deliver a feature. This includes analysis, design, coding, testing and documentation. The Team is responsible for staying focused on assigned tasks, soliciting help as they encounter road blocks, fully testing their code, refactoring code, logging their time daily (including estimated time remaining on each task), and for checking their code daily or more often if possible.

Our Experiences with Team Composition

In our experience, it is unrealistic to assume that The Team can handle quality assurance and documentation well. We have improved the team composition to include 2 additional roles:

• Software Quality Engineer - This individual is responsible for the quality of the sprint. In our experience, programmers do not test code with the same mentality as a Software Quality Engineer (SQE). Once specific requirements are defined, the SQE develops a set of test cases (manual or automated) to test each requirement fully. Before coding begins, the test cases are made available to the programmers on the team. The programmers are expected to run each test case before marking coding as being complete. Once a requirement is marked as being complete, the SQE is responsible for running the test cases again to ensure they all pass. The SQE also runs a weekly regression to ensure that legacy features are not compromised by the release. If the SQE has developed automated test cases for regression, those are run daily or more frequently, if needed. The SQE does not wait until the end of the sprint to begin testing, they test once a requirement is completed. By the end of the sprint, all testing has been done and regression has been run frequently.
• Documentation Specialist - The Documentation Specialist (DS) is responsible for creating User Guides, Administrator Guides and other training materials. In our experience, programmers do not always have the written communication skills to write documentation in a way that a laymen can interpret it, that is why it is important to have a separate resource for this function. Once a requirement has been fully tested by the SQE, the DS begins the documentation of that requirement. The DS does not wait until the end of the sprint to begin this, the end of the sprint includes all completed documentation.

Introduction

Ant may be unfashionable these days, but it still has its advantages. Key among these are familiarity and simplicity: most Java developers have worked with Ant, and with an Ant build what you get is what you see. A major disadvantage, though, is that Ant provides very little out-of-the-box. When you start a new project, you’ve got a lot of grunt work to endure just to get your code compiled, packaged, and tested. An all-too-common solution, in the grand tradition of make, is to copy a build file from an existing project as an easy starting point.

Over the years, though, Ant has gradually expanded support for creating reusable build file snippets. On top of this a few projects have emerged which aim to simplify and standardise your Ant builds, including:

• EasyAnt
• Ant Master Build Scripts
• Ant Script Library

Today I’ve taken my first proper look at the latter, and so far I like what I see.

The Ant Script Library

In the author Joe Schmetzer’s own words:

The Ant Script Library (ASL) is a collection of re-usable Ant scripts that can be imported into your own projects. The ASL provides a number of pre-defined targets that simplify setting up build scripts for a new project, bringing re-use and consistency to your own Ant scripts.

ASL consists of several Ant XML files, each of which provides a group of related functionality via predefined targets. For example, the asl-java-build.xml file defines targets for compiling and packaging Java code. The asl-java-test.xml file extends this with the ability to run JUnit tests, and so on. Essentially, ASL packages up all the grunt work, allowing you to concentrate on the small tweaks and extra targets unique to your project. The modular structure of ASL, combined with the fact that it is just Ant properties and targets, makes it easy to take what you like and leave the rest.

An Example

Allow me to illustrate with a simple project I have been playing with. This project has a straightforward directory structure:

• <project root>
  • asl/ – the Ant Script Library
  • build.xml – Ant build file
  • lib/ – Jar file depedencies
  • src/ – Java source files
  • test/ – JUnit-based test source files

To add ASL to my project, I simply downloaded it from the project download page and unpacked it in the asl/ subdirectory of my project1. Then I can start with a very simple build file that supports building my code and running the tests:

<?xml version="1.0" encoding="utf-8"?>
<project name="zutubi-android-ant" default="dist">
    <property name="java-build.src-dir" location="src"/>
    <property name="java-test.src-dir" location="test"/>
    <property name="java-build.lib-dir" location="libs"/>

    <property name="asl.dir" value="asl"/>

    <import file="${asl.dir}/asl-java-build.xml"/>
    <import file="${asl.dir}/asl-java-test.xml"/>
</project>

Notice that I am using non-standard source locations, but that is easily tweaked using properties which are fully documented. With this tiny build file, let’s see what targets ASL provides for me:

$ ant -p
Buildfile: build.xml

Main targets:

 clean                 Deletes files generated by the build
 compile               Compiles the java source
 copy-resources        Copies resources in preparation to be packaged in jar
 dist                  Create a distributable for this java project
 generate              Generates source code
 jar                   Create a jar for this java project
 test-all              Runs all tests
 test-integration      Runs integration tests
 test-run-integration  Runs the integration tests
 test-run-unit         Runs the unit tests
 test-unit             Runs unit tests
Default target: dist

It’s delightfully simple!

Adding Reports

It gets better: ASL also provides reporting with tools like Cobertura for coverage, FindBugs for static analysis and so on via its asl-java-report.xml module. The full range of supported reports can be seen in the report-all target:

<target name="report-all"
        depends="report-javadoc, report-tests, report-cobertura, report-jdepend, report-pmd, report-cpd, report-checkstyle, report-findbugs"
        description="Runs all reports"/>

Having support for several tools out-of-the-box is great. For my project, however, I’d like to keep my dependencies down and I don’t feel that I need all of the reporting. Although the choice of reports is not something that is parameterised by a property, it is still trivial to override by providing your own report-all target. This shows the advantage of everything being plain Ant targets:

<?xml version="1.0" encoding="utf-8"?>
<project name="zutubi-android-ant" default="dist">
    <property name="java-build.src-dir" location="src"/>
    <property name="java-test.src-dir" location="test"/>
    <property name="java-build.lib-dir" location="libs"/>

    <property name="asl.dir" value="asl"/>

    <import file="${asl.dir}/asl-java-build.xml"/>
    <import file="${asl.dir}/asl-java-test.xml"/>
    <import file="${asl.dir}/asl-java-report.xml"/>

    <target name="report-all"
            depends="report-javadoc, report-tests, report-cobertura, report-pmd, report-checkstyle"
            description="Runs all reports"/>
</project>

Here I’ve included the java-report module, but defined my own report-all target that depends on just the reports I want. This keeps things simple, and allows me to trim out a bunch of ASL dependencies I don’t need.

Conclusion

I’ve known of ASL and such projects for a while, but this is the first time I’ve actually given one a go. Getting started was pleasantly simple, as was applying the small tweaks I needed. So next time you’re tempted to copy an Ant build file, give ASL a shot: you won’t regret it!

–
1 In this case I downloaded the full tarball including dependencies, which seemed on the large side (21MB!) but in fact can be easily trimmed by removing the pieces you don’t need. Alternatively, you can start with the basic ASL install (sans dependencies) and it can pull down libraries for you. Sweet .

Southern Fried Agile was a GREAT success.  We had a great turn-out for a first annual event and the caliber of speakers was topnotch.  All of the presentations made during the conference are available for download on SlideShare.net (click link to visit).

My presentation can also be found there, titled “All You Need To Know Is That It’s Possible.”  My presentation addresses many of the excuses I have heard teams make over the years as to why Agile could not work for them.  Over time I came to find that most of these teams simply used this type of excuse to relieve themselves of the responsibility of having to try to make Agile work, a responsibility they would certain shoulder, but only if they allowed themselves to believe that the Agile approach might be able to offer the enormous gains that are touted.  These same teams spend great deals of energy in convincing themselves to believe that it is simply not possible for Agile (or seemingly any better approach) to work with their unique, product, team, culture, organization, etc.  They would tell me that they are just too different.  This presentation seeks to make the case that it is often the limiting beliefs held by people that keep them from being able to succeed with Agile.

Hopefully I will see some of you at Agile2010 in Orlando in a couple of weeks, I will be tweeting non-stop for those of you that cannot make it.  Follow me at @AgileAdvisor.

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?
 

The folks at AlertGrid posted an article with instructions for configuring Assembla to send SMS messages to your phone whenver something important happens. They asked "Can Assembla send me SMS message when new milestone is created?" Yes, it can.

The key ingredients are

• the Assembla Webhooks tool, which will send events from the activity stream to other applications.  You select the type of events that you want to send (for example, code commits, ticket comments, or new/edited milestones).  Then, you configure the URL to get or post the information.
• The AlertGrid service.  AlertGrid will not only send you an SMS, but it will compare the incoming messages to workflow rules, and send the correct message to the correct people.  So, this adds an extra layer of intelligence to the notification process that you can use to filter out noise and find the most important events.

This is the tenth post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The tenth principle we discuss is called "Architecture emerging from Projects". One of [...]

I facilitated a discussion on “Agile in the Indian context” at the AgileNCR conference a few weeks ago. The image below is a mindmap of the discussion.

If you look at the mindmap you’ll see that only a few of the challenges are specific to Indian contexts (specifically the bit on service companies). Most are universal across the world.

What challenges did you face when adopting agile? What did you do about them?

(Click the image to view the map in full size)

Ah, Marketing.  Enter a world of countless project requests, numerous stakeholders, limited resources and rapidly changing market conditions.

Sound familiar?  In fact, marketers face a lot of the same challenges as development teams, and Agile can be a powerful way to alleviate those common issues and intelligently plan our work.

In steps 1-5, I’ll explain how Rally’s marketing team conducts our version of Release Planning.  In steps 6-10, I’ll explain how we run our iterations to meet those commitments. Our planning processes continue to evolve, though this method has worked for awhile now.

10 Steps to Successful Marketing using Agile and Lean Practices

1. We recognize that Marketing has challenges that are different from Development.

• There is no unique product owner.  For example, if we chose Sales, then we would always rank lead generation over branding, customer programs or analyst relations, and that could ultimately hurt our company. Therefore we have to use some best-guessing to prioritize our backlog and determine what is most important.
• We face hard event deadlines set far into the future.  Sometimes we have no choice but to commit to an event or sign a contract months ahead of time.
• Each team member has unique expertise, i.e. writing, event planning, PHP development and so forth.  So one shared backlog is inefficient.

Now that we’ve reviewed the challenges, we give ourselves permission to do what we need to do, have patience and adjust anything that isn’t working for us.

2. Conduct an ORID to learn from the past

Before planning for the next quarter, we hold a retrospective in the form of an ORID, “a means to analyze facts and feelings, to ask about implications and to make decisions intelligently”, a process created by the Institute of Cultural Affairs.  We gather as a team to share:

• Observations (O) – What do we know?
• Reflections (R) – How do we feel about this?
• Interpretations (I) – What does it mean for the organization?
• Decisions (D) – What are we going to do?

This strategic overview helps set context for us to prioritize our focus for next quarter.

3. Align ORID decisions with company strategy

At Rally, we conduct quarterly and annual planning using the Plan Do Check Adjust methodology as explained in Getting the Right Things Done.   As we look at the overall company direction and goals, we keep these in mind as we hold planning at our own level.   Ideally, our major commitments support and align with company strategy. This also helps inform our “stop doing” list.

4. Poll our stakeholders

As part of determining quarterly commitments, we poll our major stakeholders for their top requests.  We use a Google survey to rank these requests by importance, size each request and bring these epics into our release planning meeting, to be included as part of our ranked backlog.

5. Conduct Release Planning to prioritize and agree on quarterly commitments

Now that we have all of our inputs, we hold our quarterly Release Planning session.  We write each epic on a sticky note and look at all of the possible work we could do this quarter.  Then, we evaluate epics based on importance taking company goals, stakeholder wishes, market realities like conferences and our own passions into consideration. We decide what we can realistically commit to, and agree as a team.  We keep in mind that making and meeting commitments is a huge deal, and we try really hard not to over-commit.

Part 2 – Meet our Marketing Commitments

6. Create a task board

Since our marketing team is mostly co-located, we pin up several large sheets of paper to use as a task board.  This is where we review our commitments on a daily basis as a sanity check that our stories are prioritized correctly and that we are tackling the right work as the quarter progresses.

As a team, we write our quarterly commitments on the task board with the definition of done assigned to each one.  We also include our “foundational” work – recurring work like website updates, online ad campaigns, field events, press releases and other important work that we need time to do.

Note: this is not a Kanban board because we do not have a shared backlog nor do we have a team-wide WIP limit.  As we break into smaller project teams that do share a backlog, we often use AgileZen to manage this work.

7. Hold iteration planning every 2 weeks

Every 2 weeks, we hold an Iteration Planning meeting.  Each team member has her own sticky note color, creates stories on those notes and manages her own prioritized backlog using T-shirt sizing to roughly estimate each story.  In this hour-long meeting, we begin by expressing appreciation for team members who gave exceptional assistance.  Then we hold a brief retrospective on what worked and what should change for the next iteration.  Finally, we each read out our prioritized stories for the iteration, putting them on the task board’s backlog.  This gives everyone visibility to what’s happening, identifies if someone is over-committed and lets the team swarm any epics with looming deadlines.

8. Conduct a daily stand-up

At the same time each day, we hold a stand-up meeting (with a consistent conference call #) that is at most 10-15 minutes long.  We form a semi-circle in front of our task board and share no more than 2 cross-cutting significant actions or take-aways from the day before, no more than 2 that we are planning to accomplish that day, and whether our work is blocked by any issues beyond our control.   As we start working on stories throughout the iteration, we move them from the backlog into their section of the task board to show what we are working on.  When the story is complete, then we move it to a place on the task board labeled “Done”.  Once the commitment’s Definition of Done is met, we check off that commitment and feel good about completing it.

9. Be patient as things change

It would be lovely if nothing changed during the iteration, but that just doesn’t happen.  The goal is ultimately to respond to change rather than cling to an outdated plan.  As new opportunities arise, new time-sensitive information appears and new requests are made, so our iteration work changes and that’s ok.  We try to just document what we’re working on and create new stories so that we can make intelligent prioritization decisions during the course of the iteration.

10. Retrospect, inspect and adapt

As we keep running our iterations and fulfilling our commitments, we are always looking for ways to improve them.   Ultimately, we’re using Agile to improve the quality of our work life by using objective, smart ways of planning how we spend our time. And we’re learning a lot from the journey.

by Martin Harris

I went along to the London Scrum User Group yesterday evening.  For a change it was a quiet night.  Christmas is around the corner so we had less attendees.  Nigel Baker of AgileBear kicked off and suggested putting together 15 tips for good scrum.  After some discussion, we came up with 6 good ones, and in true Agile style, we decided that if you did these 6 well, you would be in front of the pack.  So we stopped there and got on with eating the snacks and drinking the beer.  So here is what the group came up with, look at your team and ask yourself if your doing these, if not, perhaps its time for a scrum experiment? The London Scrum Groups 6 Good Scrum Tips

• Love your product owner. The group agreed that the product owner should be part of the team. Include them in the meetings and get them involved. Its possibly the most important thing you can do for success in scrum. A fully integrated product owner will spot early on if the stories do not match their expectations. They negotiate the definition of done for a story. They are on hand to answer questions during the iteration removing waste and improving understanding of the stories. The product owner decides if the team has finished stories at the demo. Working closely with the product owner can avoid going adrift and missing your goals, saves a lot of stress when things hit a rough patch as they get to see the problems first hand. We agreed that this point can not be understated, if you do nothing else do this.
• Run Retrospectives. Its very important to take actions away from a retrospective.  Be realistic though, your never going to solve them all, so ask the team to priorities them.  If your doing the retrospective right your product owner will be there to help with prioritization.  If you find something very big lands at the top, split it down into stories.  Otherwise pick one or two that the team feel strongly about and turn them into stories.  Make sure these stories are included in the next game planning sessions and make it into the iterations.  If you have adjustments to the process you can implement these straight away, but experiment with it, and try to measure the impact of changes, you might not get the process right first time.  Commit to doing them and then deliver.
• Ask your team to Pair Code. The XP technique of two programmers working on the same task.  It was agreed that there are different kinds of pair coding and that they all have a place, but the one we are talking about here is where two equal programmers work together to improve quality and throughput.  Don’t be dogmatic, let the team decide how much work should be pair coded.
• Setup Self Directed teams. Self directed teams have been proven to be more efficient.  We discussed the role of a scrum master in a self directed team.  Its very important that the scrum master does not tell the team how to work, or how to go about completing the tasks.  The scrum master does not plan or allocate tasks.  The empowered team needs to work out what the tasks are and find out how to finish the stories.  The scrum master should spend his efforts removing blocks for the team, checking quality.  Its important for the team and scrum master to spot if someone is not completing their work for whatever reason, but a strong team will sort out those kinds of issues if truly self directed.  We also decided that to be empowered you need to make the team multi discipline.  Include testers, user interface designers etc to remove hand off waste and increase team knowledge.  With role diversity comes better decision making.
• Deliver what you commit to. Another gem, it sounds obvious but is so often ignored.  Delivering builds trust in the team and the process.  Classic ways to miss delivery include: Failing to produce a strong definition of done.  The definition should include the programming, integration, testing and setup tasks.  In fact everything required to get that task ready for delivery.  Another way to miss delivers is to fail to demonstrate at the end of the iteration.  You may think your done, but when the product owner sees the work for the first time they may request refinement.  If you have kept your product owner close then the demo is likely to be painless.  No power-point slides please, only real working software in the demo!  So commit and then deliver what you commit to.
• Co-locate your team. The group defined co-location quite tightly.  Co-location is not putting everyone in the same office.  Its putting the team members next to each other in the same space.  Intra team communication does not happen with the team scattered around an office.  You should be able to turn around and join the stand up meeting.  This closeness, speeds up the myriad of tiny important messages that pass around the team.  Some of which is non verbal.

After this rich discussion we gave up on the 15 tips idea.  If your doing these, then your doing very well indeed, and are likely to get better over time.

So another excellent meeting, a few more beers and I headed home enlightened, well fed and slightly merry.  Why not come along to the next one, we could use your input.

Recently, Andrew Phillips, VP of Product Management at XebiaLabs, and I had the opportunity to speak with Mike Vizard, tech journalist for IT Business Edge. We had a great conversation about automating application deployments and Mike’s article provides a nice look into our discussion. In the last paragraph, he brings up an interesting point, saying “there [...]

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?

Below is an excerpt from an email response I sent someone asking me about Kanban and Scrum and what they should do to determine which is more appropriate for their teams. This is just my personal opinion on this subject and I’m sure our trainers have MUCH better perspective to add! Kanban for software is an [...]

One of the really nice things with physical cards is that you can easily annotate it with stickies and other things such that the story card conveys a huge amount of information right at a glance.

For instance, lets say that one feature requires having a conversation with Bill. This is not a formal task that you want to track, but its just a kind of ad-hoc reminder on something that needs to be done.

Doing this with physical cards is easy! Just take a small sticky, write “Talk to Bill” on it and slap it on the story card. Done!

You’ll never forget with the sticky right there on the card. When you’re done, take out the sticky, tear it up and throw it away.

This simple operation can become extremely complicated with an electronic tool.

That’s the kind of problem we always grapple with.

How can we make the board as simple, visible and flexible as a physical board, but retain all the functionality that electronic tools excel at?

Creating Ad-hoc notes in Silver Catalyst

So here is how you can create ad-hoc notes in Silver Catalyst and get them to display on the card in the board.

It’s very simple really.

Just go to the project settings and add a new custom field as shown below. Lets call this field ‘notes’. Set the type to text.

And…you’re done!

Now if you fill up this notes field, it will appear on the card on the board. Just like the image below.

Wasn’t that simple?