General security

Marketing and Product Development in Agile

August 9, 2012 by Adrian Stolarski

After writing a recent article on the rapid introduction to Agile, I got an amazing response from readers, so the publisher and I decided to expand on the theme. Today we will examine how we can turn the idea into an efficient marketing strategy, as well as a set of best practices in product development.

How to change the idea of Agile methodologies in marketing

I love the challenge. And every article about Agile will always be provocative, because it will compel everyone to a comprehensive analysis of your organization. What is Agile? Why is the IT environment so enchanted by its approach? Is it really a revolution in the conduct of IT projects? And can I answer these questions?

Fortunately, I no longer have to prepare the whole methodology from scratch. This was done for me. In February 2001, in Snowbird, Utah, 17 managers and consultants gathered to discuss the innovative techniques of software development and issued what is commonly called the Agile manifesto. Here’s something especially interesting for us:

“Manifesto for Agile software development

Producing software and helping others in this regard, we find better ways to do this work. As a result of this experience, we present:

People and interactions over processes and tools.

Working software over comprehensive documentation.

Customer collaboration over the formal findings.

Responding to change over following the plan.

We appreciate what you have listed on the right, but we value more what is left.”

These rules are simple and each of them has their use. The term “Agile” has completely crossed the area of software development and proposes more new solutions in many other areas of managing multiple projects. Based on the SCRUM methodology, it produces many surges of joy, and few other people give you a heart vibration like that. SCRUM is a rescue from cold and rigid procedures, all the traditional methods. But do you really think traditional methodologies are so bad? Or maybe they teach us? Let’s examine a few assertions of Agile:

• People over processes and tools. This is a key premise of each project. Here a lot of energy is put into the project planning process, and not in the process of creating a schedule that theoretically could not even exist.

• Completion of the required functionality over documentation. Consider what the goal of the project is really: Make a nice product, or to meet a real need?

• The relationship over the contract. He did a lot of projects where there was a considerable deviation with the client from the initial plan. The project grew with the deepening of our relationship.

• Openness to change instead of the deadline. We must remember that for us, three things are certain: death, taxes and change. In every project there will be changes. Of course, the changes can be friends.

So before we finish this part of the article, let us each have two short questions. Have we all unconsciously worked at Agile? Or maybe you just have the same common sense telling us that Agile Project Management is the only way? I encourage you to discuss this topic, because I am really happy to get to know your opinion.

Collection of good practices of Agile

Below is a collection of all the good practices of Agile. All of these together ensure that the project carried out by us will succeed.

First: Customer Collaboration

Do you really have to explain? Agile should always inform the client of the progress and inform the team about what will be done in the sprint. Remember that through constant communication with the team, we can be sure that the customer will be provided all the functionality required by him.

Second: Product Backlog

Well, it gets interesting. We already have a project that we need to develop. Now it’s time to take scissors and cut the pieces to specification The full project can be selected to implement the cuts and big tasks are divided into several smaller ones. Then the team determines how much work is needed to take a piece of the application. The next step is to identify priorities based on business needs of the client. The main features are elements that are written in the first practice.

Third: Iterative Development, SprintsFor Agile-based teams, the amount of work possible to be done is selected on the basis of the available hour’s team. Simultaneously, the team itself can decide what it is able to do based on their capabilities and experience from the previous iteration.

Fourth: Time-Boxed.

The duration of the sprint is stiff and takes place within a specified timeframe, which ranges from two weeks to a month. SCRUM meetings, which last about 10-15 minutes each day, are also stiff.

Fifth: Value Stream Analysis

This is done again on two principles. First, we define the product based on user stories, which are based on his analysis of the business. Then we define dependencies between the business and technical functionality.

Sixth: User Stories

First, we begin by describing the functionality of communication with our beloved client and then describe the product’s position in a very specific way (as … I want to … because …). They contain mostly three main sections: description, acceptance criteria, and estimation of the time, based on complexity. If the User Stories are too complex, they are broken up into smaller pieces, so as a whole would be processed within a few sprints.

Seventh: Specified By User Stories Examples

Again we are dealing with User Stories from the previous point. Here they are enriched with examples showing all the options of the given function and how it affects others.

Eighth: SCRUM meetings

Here we speak of short morning meetings, lasting about 10 minutes. The whole team is present and led by the SCRUM Master. In general, during these meetings we talk about three main issues: to remember what was done yesterday, to define the goals for today, and check to see if there are any obstacles to peaceful work. Additionally, in the case when you program in pairs, we need to define who is who in the hand.

Ninth: Continuous Integration

Continuous integration of code allows you to keep the code up to date. All code was written which shall be verified before it is connected with the old code. This solution simplifies the testing of new user stories. After the junction of the new codes from the old, unit tests are performed to check for errors. The next day, a regression test is executed, whose task is to verify that new functionality does not adversely affect the rest of the code.

Tenth: Automated Tests

Each regression test is run automatically before starting work to ensure that the code changes are acceptable. This allows you to get quick information about which of the functionality is not working as planned.

11th: Programming in Pairs

This is a very interesting question because really any good computer scientist is an individualist. It involves the implementation of user stories in pairs (primary and secondary developer). Here, an expert is working with the novice, and most importantly, there is one owner of the user story, the other programmer only provides support and can rotate. Produces two programming sessions, because once one of the developers, the second time becomes the owner of user stories. Even the code reviews are carried out in pairs. In order to assess team performance, group performance and frequency work together to apply the matrix pairs. Logically applied programming in pairs yields results far superior to two developers working separately.

12th: Test-Driven Development

All sessions begin by writing programming adaptive tests that are preceded by unit tests. Only later write code specific to the user stories. This approach is updated daily at SCRUM meetings.

13th: Burndown charts

Firing charts show whether things really go according to plan and calendar of programming. They show precisely the work schedule and time. In addition, well-designed charts show the amount of user stories per unit of time, below or above our plan.

14th: Sprint Demo Meeting

We are ready with the functionality, and now it’s time for a short meeting carried out in the sprint, where we explain the functionality and how it works to the client. This way the customer can confirm that he accepts a feature and that it was made in accordance with his expectations.

15th: Retrospective Meeting

This concept describes a meeting of the finite iterative development. It should be compulsorily attended by all of our team, but the client may also participate. Let’s talk then about the possibility of improving the process, the quality of our work, tools used, lessons learned, training, etc. Let us apply the matrix with the division into sections: stop, start and continue.

16th: Shippable Code

Finally, we have a package code. We just make sure that it is definitely a working code. With the frequent release of the package with the code, our client is assured that in a short time he will get the expected business value.

17th: Release Planning

Calendar of releases must always give a clear message to all concerned, when you can expect new software functionality. Additionally, it helps to correct the code if each version supports automated testing, and integration with other components.

“We value:

Individuals and interactions over processes and tools

Working software over detailed documentation

Customer collaboration over contract negotiation

Response to change more than the fulfillment of the plan”

The Agile Manifesto

It is very important that each iteration is performed in close collaboration with the client, so to date, you can modify the assumptions and requirements of the project, correct errors caused by misunderstandings and control the course of the process. Adaptive management software is based on the number of rules and principles, and I hope that after this series you will know them all. One of the advantages of our approach to software development is to provide the customer on a continuous basis (after each iteration), the next product version. This allows you to constantly confront the intentions and expectations of the customer (often evolving) from the real product and modify it, even in late stages of product development. Agile allows you to quickly carry out such changes and reduces costs to a minimum. If you stop the project for various reasons, the customer is with the operating system with greater or lesser functionality to measure the amount invested.

Commonly used procedures in IT companies create situations where the client, after consultation with the functional scope of the software for months, loses control over its development. After examining the effects of the work of programmers, it often turns out that the functionality is different from the expectations of the client or his views on some issues have changed.

The methodology used in the Agile Customer assumes constant insight in the progress of work at each stage of application development. It does so first of all in regular meetings to gather as many comments and jointly solve problems as they occur. They respond quickly to save you valuable time, which can then be spent on testing applications. An increased number of tests give in turn more stability and higher product quality.


Do not be afraid to write and inquire. I’m here for you, although it may happen that the mail will be answered only in the weekend. In the next article of our series on Agile, you will learn why conventional business world so afraid of this methodology. And then I promise I will only get more interesting. You can also write to me or someone from InfoSec about which program you want to create at the end of our discussion on this methodology. I am fully open to your suggestions.

Posted: August 9, 2012
Adrian Stolarski
View Profile

Adrian Stolarski is a freelance security tech blogger, specializing in Java, PHP, and JQuery. In his own words, he does the hard work of training the unemployed. Currently, he handles Evaluation Visualization for real-time systems with XWT and Eclipse RAP. If he sees that something works, he asks how it works and why it works, then sets out to make it work better. A researcher for InfoSec Institute, he currently lives in Poland, but plans to move to London.