Agile Case Study - Software marketing

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

Sound familar? 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.

10 Steps to successful Marketing using Agile and Lean Practices:

In steps 1-5, Explain how marketing team conducts our version of release planning.
In step 6-10, Explain how we run our iterations to meet those commitments. Our planning processes continue to evolve, through this method has worked for a while now.

PART 1

STEP 1: We recognize that Marketing has challenges that are different from development.

• There is no unique product owner: for example if we chose Sales, when 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,w e give ourselves permission to do what we need to do, have patience and adjust anything that isn't working for us.

STEP 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.

STEP 3: Align ORID decision with company strategy:
We conduct quarterly (as per company strategy) 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.

STEP 4: Poll our stack holders:
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.

STEP 5: Conduct release planning to prioritize and agree on quarterly commitment:
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

STEP 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.
We break into smaller project teams that do share a backlog, we often use AgileZen to manage this work.

STEP 7: Hold Iteration planning every two week:
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

STEP 8: Conduct a daily Stand up meeting:
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.

STEP 9: Be patience 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.

STEP 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.

Software Development Methodology

"A Software Development Methodology is the concept / best practices or guidelines for managers to streamline the process, instructing them how to plan, control, estimate, involving team members and quickly delivers quality software by minimizing risks, cost and failures."

A software / system development methodology in software engineering has various meanings to various audiences.

• As a noun, a software development methodology is a framework that is used to structure, plan, and control the process of developing an information system.
• Rational Unified Process: - since 1998
• Agile Unified Process: since 2005
• Integrated Unified Process: since 2007

• As a verb, the software development methodology is an approach to be used by an organization or project team to apply the software development methodology framework
• Waterfall Approach (linear): Waterfall approach is a sequential development approach, in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirement analysis, design, implementation, testing (validation), integration and maintenance.
• Protyping Approach (iterative): Software prototyping is the development approach of activities during software development the creating of prototypes, i.e. incomplete versions of the software program being developed.
• Incremental Approach (combination of linear and iterative): Various methods are acceptable for combining linear and iterative systems development methodology approaches, with the primary objective of each being to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process.
• Spiral Approach (combination of linear and iterative): The spiral model approach is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts.
• Rapid Application Development (RAD) Approach (Iterative): Rapid Application Development (RAD) is a software development methodology approach, which involves iterative development and the construction of prototypes.
• Extreme Programming Approach:

• Waterfall Approach: Basic Principle of Waterfall approach is:
• Project is divided into sequential phases, with some overlap and spash back acceptable between phases.
• Emphasis is on planning, time schedules, target dates, budgets and implementation of an entire system at one time.
• Tight control is maintained over the life of the project through the use of extensive written documentation, as well as through formal reviews and approval/signoff by the user and information technology management occurring at the end of most phases before beginning the next phase.
• Protyping Approach: Basic principles of the Prototyping Approach are:
• Not a standalone, complete development methodology approach, but rather an approach to handling selected portions of a larger, more traditional development methodology (i.e. incremental, Spiral or Rapid Application Development (RAD)) approaches.
• Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process.
• User is involved throughout the development process, which increases the likelihood of user acceptance of the final implementation.
• Small-scale mock-ups of the system are developed following an iterative modification process until the prototype evolves to meet the user’s requirements.
• While most prototypes are developed with the expectation that they will be discarded, it is possible in some cases to evolve from prototype to working system.
• A basic understanding of the fundamental business problem is necessary to avoid solving the wrong problem.
• Mainframes have a lot to do with this sort of thing.
• Incremental Apprach: Basic principles of the incremental development approach are:
• A series of mini-Waterfalls are performed, where all phases of the Waterfall development approach are completed for a small part of the systems, before proceeding to the next incremental, or
• Overall requirements are defined before proceeding to evolutionary, mini-Waterfall development approaches of individual increments of the system, or
• The initial software concept, requirements analysis, and design of architecture and system core are defined using the Waterfall approach, followed by iterative Prototyping approach, which culminates in installation of the final prototype (i.e., working system).
• Spiral Approach - basic principles.
• Focus is on risk assessment and on minimizing project risk by breaking a project into smaller segments and providing more ease-of-change during the development process, as well as providing the opportunity to evaluate risks and weigh consideration of project continuation throughout the life cycle.
• Each cycle involves a progression through the same sequence of steps, for each portion of the product and for each of its levels of elaboration, from an overall concept-of-operation document down to the coding of each individual program.
• Each trip around the spiral approach traverses four basic quadrants: 
• determine objectives, 
• alternatives, and constraints of the iteration; 
• Evaluate alternatives; Identify and resolve risks; 
• develop and verify deliverables from the iteration; 
• Plan the next iteration.
• Begin each cycle with an identification of stakeholders and their win conditions, and end each cycle with review and commitment.
• Rapid Application Development (RAD) Approach – Basic Principles.
• Key objective is for fast development and delivery of a high quality system at a relatively low investment cost.
• Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process.
• Aims to produce high quality systems quickly, primarily through the use of iterative Prototyping (at any stage of development), active user involvement, and computerized development tools. These tools may include Graphical User Interface (GUI) builders, Computer Aided Software Engineering (CASE) tools, Database Management Systems (DBMS), fourth-generation programming languages, code generators, and object-oriented techniques.
• Key emphasis is on fulfilling the business need, while technological or engineering excellence is of lesser importance.
• Project control involves prioritizing development and defining delivery deadlines or “timeboxes”. If the project starts to slip, emphasis is on reducing requirements to fit the timebox, not in increasing the deadline.
• Generally includes Joint Application Development (JAD), where users are intensely involved in system design, either through consensus building in structured workshops, or through electronically facilitated interaction.
• Active user involvement is imperative.
• Iteratively produces production software, as opposed to a throwaway prototype.
• Produces documentation necessary to facilitate future development and maintenance.
• Standard systems analysis and design techniques can be fitted into this framework.
• Agile Unified Process (AUP): Agile describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP. The AUP applies agile techniques including test driven development (TDD), Agile Modelling, agile change management and database refactoring to improve productivity.

Agile SCRUM

• Unlike RUP, the AUP has only seven disciplines.
• Model. Understand the business of the organization, the problem domain being addressed by the project, and identify a viable solution to address the problem domain.
• Implementation. Transform model(s) into executable code and perform a basic level of testing, in particular unit testing.
• Test. Perform an objective evaluation to ensure quality. This includes finding defects, validating that the system works as designed, and verifying that the requirements are met.
  Deployment. Plan for the delivery of the system and to execute the plan to make the system available to end users.
• Configuration Management. Manage access to project artifacts. This includes not only tracking artifact versions over time but also controlling and managing changes to them.
• Project Management. Direct the activities that takes place within the project. This includes managing risks, directing people (assigning tasks, tracking progress, etc.), and coordinating with people and systems outside the scope of the project to be sure that it is delivered on time and within budget.
• Environment. Support the rest of the effort by ensuring that the proper process, guidance (standards and guidelines), and tools (hardware, software, etc.) are available for the team as needed.
• Agile Philosphies: The Agile UP is based on the following philosophies:
• Your staff knows what they're doing. People are not going to read detailed process documentation, but they will want some high-level guidance and/or training from time to time. The AUP product provides links to many of the details, if you are interested, but doesn't force them upon you.Simplicity. Everything is described concisely using a handful of pages, not thousands of them.
• Agility. The Agile UP conforms to the values and principles of the agile software development and the Agile Alliance.
• Focus on high-value activities. The focus is on the activities which actually count, not every possible thing that could happen to you on a project.
• Tool independence. You can use any toolset that you want with the Agile UP. The recommendation is that you use the tools which are best suited for the job, which are often simple tools.
• You'll want to tailor the AUP to meet your own needs.

Agile Software Development LifeCycle

• Releases: The Agile Unified Process distinguishes between two types of iterations. A Development Release Iteration results in a deployment to the Quality Assurance and/or Demo area. A Production Release Iteration results in a deployment to the Production area. This is a significant refinement to the Rational Unified Process.