Agile methods in product management

a.sarkozi@welcomemonday.de

PRODUCT MANAGEMENT & SOFTWARE DEVELOPMENT

AGILE METHODS Alexander Sarkozi Product enthusiast

Let’s make it work

CONTENT

Alexander Sarkozi

---}

TA B LE OF CON T E N T

CHAPTER ONE 4

CHAPTER SEVEN 31

Why are Agile Software Development

Which Tools you can use in agile

Methods so important

development projects

CHAPTER TWO 10

CHAPTER EIGHT 33

How to swap the traditional approach for agile

Be Honest!

development

Transparancy

CHAPTER THREE 12

CHAPTER NINE 36

The most important concepts of agile methods in

How development teams evolve by

software development

using agile methods

CHAPTER FOUR 19

CHAPTER TEN 40

How to use Scrum effectively in

Why you sometimes need to forget

agile development

everything and work on your flex agile game

CHAPTER FIVE 26

CHAPTER ELEVEN 42

Development iterations planned

Product Management vs.

right with agile

Technical Product Management

CHAPTER SIX 29 A cultural shift necessary to implement the right agile methods

Page 2 of 45

{---

product & agile

EDITOR IAL

W H Y T HOUGH ?

Well, my plan was to make this small book short and simple.

I almost made it.

I hope you can enjoy my tipps & tricks and hopefully you’ll give me a great feedback! Be honest and tell me what you think.

Until then I can only hope that you sit on the greatest new product possible and work your ass off.

Make it shiny and meaningfull.

Alexander Sarkozi Product Enthusiast

Page 3 of 45

Alexander Sarkozi

---}

CH A P T E R NUMB E R ONE

WHY AR E AGILE SOFTWAR E DEVELOPMENT METHODS SO IMPORTANT Developing software is a difficult and risky activity. According to statistics, the biggest risks are: • Expenses that exceed budget.

• Time consumption that exceeds the schedule.

• Features that do not solve the problems of the users.

• Low quality of the systems developed.

• Cancellation of the project for non-viability.

In the traditional concept, software development methodology is a set of associated activities and results, that end in the production of software. All development methodologies attempt, among other things, to reduce the high risk associated with software development.

A classic example of a traditional software development model is the cascade development, which for several decades was widely used in software development processes, and is still widely used today.

Even some non-cascade software development processes, such as the Rational Unified Process (RUP), are adopted in most projects, in a way that closely resembles the cascade model. In these projects, the process is used iteratively and incrementally, but there is still a strong developmental linearity, characterized by “smaller cascades” within each iteration.

Page 4 of 45

{---

product & agile

Because these methods are based on linear models of development, they are naturally less flexible. Development models based on rigid requirements, defined in the initial phases of analysis, are premised on the fact, that these requirements are not changed until the end of the project, otherwise all initial planning will affect subsequent phases.

In this way, it is easy to understand that the cost of a change, grows exponentially as the development process progresses. This basic premise of traditional software engineering was formulated by Boehm in Software Engineering Economics [BOEHM, 1981]. The acceptance of this premise has as a natural consequence, a search for deterministic processes, since these promise less changes and greater predictability.

Page 5 of 45

Alexander Sarkozi

---}

AGILE M ANIFSTO This principle also reflects and justifies to a certain extent the search for a linear, deterministic, specialized and focused execution. For this traditional model of development, it is necessary to assume premises that are not always easy to reach.

The traditional model assumes that the architecture is excellent, that the design is beautiful and correct and that the implementation can be corrected during the tests. Neither of these statements works well in practice, either in the traditional cascade model or in the iterative and incremental methodologies that use “smaller cascades� within each iteration.

Page 6 of 45

{---

product & agile

Within this context of difficulty in achieving the success of development projects, agile methods have emerged.

Agile development is a result of the fact that many renowned professionals in the software engineering area, could only minimize the risks associated with software development, acting very differently from what is traditionally in books.

While each involved had his own preferred practices and theories, everyone agreed that in their previous experiences, successful projects had in common a small set of principles. Based on this, they created the Manifesto for Agile Software Development, often called the Agile Manifesto. The term Agile Development identifies development methodologies that adopt the agile manifesto principles. These principles are as follows (http://agilemanifesto.org/): • 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 great importance of developmental methods, within the current context where we operate in a highly predictable and highly volatile world in relation to business dynamics, is the flexibility to accept change and respond to these changes in a short time, since the development iterations in general are short.

In addition, the possibility of close customer interaction within the development cycle and deliveries in a short period of time, as well as bringing the customer closer to the project also makes the customer aware of the software and gives early feedback that will feed back the next iterations.

http://agilemanifesto.org/

Page 7 of 45

Alexander Sarkozi

---}

Waterfall Conception Initiation Analysis Design Construction Testing Deployment

Page 8 of 45

{---

product & agile

Agile Conception Initiation Analysis Design Construction Testing Deployment

Page 9 of 45

Alexander Sarkozi

---}

HOW TO SWAP THE TR ADITIONAL APPROACH FOR AGILE DEVELOPMENT

CH A P T E R NUMB E R T WO

Much has been said about the implementation of Agile Methods in corporate environments with the aim of streamlining and simplifying existing processes in the workplace organizational environment.

However, before deploying, it is necessary to reflect on some problems that will certainly be faced during this process, especially in those companies that wish to migrate from traditional to agile methods.

Traditional methodologies are focused on following an initial plan, building detailed documentation, giving more value to tools and processes, and negotiating contracts. Agile methods, on the other hand, seek fast adaptation to change, customer collaboration, as well as giving more value to individuals and interactions, as well as the progress of the product or service being developed.

In the face of this conflictive scenario, agile methods face several barriers to penetrating culturally traditional environments. Maybe that’s the biggest challenge, cultural change!

In other words, it is necessary to know the environment well , that must undergo changes and to know clearly what are the objectives of this cultural transformation. Change requires unlearning old values, premises, and behaviors before one can learn new ones.

Page 10 of 45

T

{---

product & agile

The most important elements of this cultural change are: executive support and training. Here is another major problem faced by agile methods during their deployment. It is difficult to obtain support from the highest levels of the organization, but it is fundamental. Executives must lead the transformation by changing their own behaviors and thus inspire other employees. Especially, when you’re dealing with successful people, because as we all know: Never change a running system. So the highest priority must be to educate and incorporate.

Team management, the subject of great study these days, is also seen as another barrier. It is the most arduous and complex work to accomplish in this process.

Given this scenario, the role of the aggregator and conciliator leader must be included, which motivates and inspires its leaders to form homogeneous teams with a well defined common objective. This is fundamental for the implementation of agile methods, since the teams will have much more freedom to propose solutions and to share errors and correctness than in traditional methods.

Interacting with other departments of the organization is another task that we must pay attention to in the migration to agile methods, since as we saw in the previous chapter, the agile model provides a much greater approximation of people, rather than following bureaucratic procedures. For this reason, the cultural change of the organization supported by the high summit of the company is fundamental. Creating a common language and attitudes that are understood by all facilitates the interactions between individuals of different natures. This helps create a climate of harmony and cooperation towards a common goal outlined in the company’s strategic planning.

CHALLENGES Another key point is the interaction with customers, because they are the ones who keep the company alive! Customers must actively participate in the process YOU MIGHT of building products, services or results, providing constant feedback. Just as in the relationship with the internal staff, the relationship must be of cooperation in FACE WHILE order to produce the desired results. Avoiding conflicts and seeking joint solutions DOING THE are relevant points of this relationship.

RIGHT THING...

It is worth mentioning that these are the main, but not the only, challenges that

must be faced to implement agile methods in traditional corporate environments.

Therefore, it is up to those who intend to apply these methods in their work environment to be prepared for the various conflicting situations that will arise during this transitory process and to be persistent and determined.

Page 11 of 45

Alexander Sarkozi

---}

CH A P T E R NUMB E R T HR E E

THE MOST IMPORTANT CONCEPTS OF AGILE ME IN SOFTWAR E DEVELOP A good definition of agile methods was

1. “Our highest priority is to satisfy the cus-

made by Pressman (Software Engineering A

tomer through early and continuous delivery of

Practitioner’s Approach):

valuable software.

“Agile software engineering combines a phi-

2. Welcome changing requirements, even

losophy and a set of development guidelines.

late in development. Agile processes harness

The philosophy encourages customer satisfac-

change for the customer’s competitive advan-

tion and early incremental delivery of software;

tage.

small, highly motivated project teams; informal methods; minimal software engineering work

3. Deliver working software frequently, from a

products; and overall development simplicity.

couple of weeks to a couple of months, with a

The development guidelines stress delivery over

preference to the shorter timescale.

analysis and design (although these activities are not discouraged), and active and continu-

4. Business people and developers must work

ous communication between developers and

together daily throughout the project.

customers.”

5. Build projects around motivated individuals.

It would be a great irresponsibility to write

Give them the environment and support they

about the main concepts of agile methods

need, and trust them to get the job done.

without quoting the principles of the agile manifesto, from “agilemanifesto.org”.

6. The most efficient and effective method of conveying information to and within a develop-

Following are the 12 principles that are ge-

ment team is face-to-face conversation.

neric to agile methods, regardless of which one is used.

7. Working software is the primary measure of progress.

Page 12 of 45

{---

ETHODS PMENT

product & agile

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from selforganizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

According to Pressman, regarding the 12 agile principles: “Not every agile process model applies these 12 principles with equal weight, and some models choose to ignore (or at least downplay) the importance of one or more of the principles. However, the principles define an agile spirit.”

With the definitions of Pressman, in addition to the 12 fundamental agile principles mentioned above, from “agilemanifesto.org”, we can complement with some concepts that are the core of agile methods.

A project involves people and change, especially when we talk about constant deliveries. In this way agile methodologies work with highly motivated teams and support for changes during the development process.

Agile development is incremental, that is, we do not make a complete plan with everything we must do to start development, let alone develop the product without contact with the customer, instead, we develop incrementally, that is, the product is done slowly and delivered constantly.

Early system increments can provide high-priority functionality, so customers will soon be able to get system value during their development.

The constant contact with the customer also generates knowledge, because the team will understand the business, to develop it, to do it with greater speed and precision.

Page 13 of 45

Alexander Sarkozi

---}

COMMUNICATION & DELIVERY In addition to the fundamental concepts, agile development needs agile practices, which as concepts are also fundamental for success: Use of TDD(Test-driven development): technique that allows continuous testing and not only the completion of the system, improving the technical quality of the product; Incremental Planning: Instead of planning software as a top, we can plan in a systemic way, that is, define the whole, but plan in stages, performing incremental planning. The increment requirements can be recorded in cards, which some methodologies call user stories, here we determine the priority that the client defines and also the time that the developers define as necessary for the development; Increases developed in reduced time: small releases, delivering functionalities in months or weeks, instead of years; Using Refactoring: Improving code and making it easier to maintain constantly; Continuous integration: when the increment is ready, it is integrated into the system as a whole, that is done daily.

Page 14 of 45

{---

product & agile

In this chapter, we have seen the basic concept of agile methodology, which aims to improve productivity. We have seen that the important of agile methodologies is the focus on continuous communication with the customer, on constant delivery and on the development team. Note that it changes the traditional concept, in which we first plan the whole product, with a complete analysis, functional and nonfunctional requirements of the entire product, and then start development, which can cause problems, since a bad requirement will only be noticed when the product is delivered months later.

In the agile methodology, we only plan what will be done in that increment, with details, so that we can develop and deliver to the client. If the requirement has been misinterpreted, it can be quickly corrected, as the incremental time is course and the correction is fast, different from when the product was delivered complete, and that many requirements errors appear, many things to be corrected and improved, leading team time and demotivation.

Page 15 of 45

Alexander Sarkozi

---}

Still a product manager!

UX

Product Manager

The nerd E SIN BU

TE

SS

CH

UX

The manager

Product Manager

TE

SS

CH

E SIN BU

UX

Product Manager

The designer SS

E SIN BU

Page 16 of 45

TE

CH

{---

product & agile

I believe that as a product manager you need to stretch your abilities constantly. Don’t just be the smart ass!

Show that you want to learn and be as helpfull as possible! At the end of the day, you are a team! Be the Point guard, quaterback and the midfielder !

A big part of the thrill being a product manager is not to be the specialist but really a generalist. The best technical employee doesnt necessarily have to be the best product manager for your tech product! This thought often leads to a misconception of the product manager position. The same is applied for designers or good managers. You really have to have the urge to understand the product and all responsibilities that evolve from that process. you might have some preferences but certainly shouldn’t be one dimensional.

Product Management Key activities User Experience This is the voice of your user inside of the business and you should have a passion for the user experience.

You will be out there in the field!

Testing, talking and constantly asking for feedback

Business You have to focus on maximizing the value from your product and be obsessed with the fact that you need to achieve business goals through optimizations and iterations.

Tech You need to understand the effort thats involved in making your decisions work! Therefore you need to spend major time with your development team and bond like glue!

You will always find different strengths in different Product mangers. It is a matter of experiences you carry in your toolbag. Utilize them to your best abilities and try to learn as much as possible. As a Product manager your major skill should be empathy. You need to understand your teammembers in order to make the right decisions! So dont worry if you lack skills in certain areas. Show that you want to learn and understand the painpoints!

Page 17 of 45

Alexander Sarkozi

CH A P T E R NUMB E R FOUR

Page 18 of 45

---}

{---

product & agile

HOW TO USE SCRUM EFFECTIVELY IN AGILE DEVELOPMENT What is Scrum?

The name was borrowed from rugby

mental planning in phases, called

According to “scrumguides.org”, the

and the inspiration comes from the

sprints. From the beginning, the list

definition of Scrum is:

union needed to win the game. Its

of functionalities to be developed,

greatest advantage is simplicity; in

the product backlog, is defined.

“Scrum: A framework within which

addition, it is extremely useful when

Each feature turns a sprint and

people can address complex adap-

it is difficult to predict future prob-

passes to the sprint backlog. From

tive problems, while productively and

lems.

there, the activities are distributed

creatively delivering products of the

and the team must develop them on

highest possible value.

In the development universe, there

time. At the end of the sprint, there is

Scrum is: Lightweight, simple to under-

are often changes in scope, unfore-

a review meeting and then planning

stand, Difficult to master”

seen, bugs and the like. To deliver a

the next phase begins. And so on,

quality end product you must have

until the finished product is ready.

Scrum is undoubtedly the most

rules for accommodating changes -

The team is multidisciplinary and

widely used agile method today. It

or this can become a systematic cycle

self-organized, that is, there is neither

can be integrated with other agile

of wasting time. Scrum strategies

hierarchy nor the figure of a leader.

methods with ease and applies not

help you win scenarios like this.

The group decides, together, what

only to software development but

is the best way to get the job done.

to any work environment. It is a set

How does it work?

There are three fixed roles to ensure

of guidelines and tools for problem

Scrum focuses on project manage-

the smooth running of work:

solving.

ment and uses iterative and incre-

Page 19 of 45

Alexander Sarkozi

---}

• Product Owner is who will guarantee the quality of the work. It represents the voice of the client and is responsible for translating users’ stories into a list of concrete tasks that clearly state which features should be developed and their priorities objectively. Within its responsibilities, the PO takes into account the risks and benefits, what is possible, what can be done, what arouses passion in the team and what the client needs.

• Scrum Master must guide professionals, facilitate the smooth running of jobs and ensure that everyone has the conditions to do their job (removing barriers, for example). Typically, it is the person who knows the Scrum rules best, and so can organize the work more effectively. The Scrum Master will guide the rest of the team in the Scrum process framework and help to eliminate any obstacles that are impeding the progress of activities. It is important that the Scrum Master be a leader server, this is a fundamental concept within the Scrum process and makes all the difference in practice.

• Development Team is the group that works together to meet the goals. Although there are different positions, they all have the same title: developer. These people are the key to success. Everyone depends on their performance. This team needs to have all the skills necessary to take the Product Owner’s Vision and make it a reality. The Scrum team must be a high-performance team that is comprised of 3 to 9 people and acts with the self-management feature.

Now that we have seen the main concepts and roles of Scrum, we must pay attention to the main events and tasks that will be of paramount importance for the success of using this agile method.

SIMPLICITY. Page 20 of 45

{---

product & agile

Create and prioritize a Product Backlog Product backlog is a detailed list of everything that needs to be done to turn product vision into reality.

This list evolves throughout the development of the product, it is the project map that leads to its main purpose.

The secret to fully meet customer need is a well-structured backlog.

In order to gain productivity, the most important is the performance of the Product Owner prioritizing their respective items.

Build Product Backlog Estimates It is imperative that the project team, who are responsible for completing each of the backlog items, can compile the estimates for each of the items on the list.

The team must enter the respective effort for each of the backlog items. This is essential for determining the productivity or speed of the project.

Another important aspect is to determine whether each item in the backlog is feasible, whether there is sufficient information to complete it, whether it is large enough to be estimated, and so on.

Definition of Done (DoD) must be clear and well defined DoD is a formal Scrum Team agreement that clearly defines the minimum steps for completing a potentially deliverable item.

It serves as a contract between Scrum Team and the Product Owner, ensuring that all product generated by the project will be within the quality standards established between them. It’s a way to pursue excellence, especially in a multiiterative setting.

To be effective, the DoD must be well defined and clear to all members of Scrum process, meeting the needs of each company.

Page 21 of 45

Alexander Sarkozi

---}

Sprint Planning This is the first of the Scrum meetings. Development Team, Scrum Master, and Product Owner get together to plan Sprint, which always has a recommended duration of less than a month. Most people define Sprints one or two weeks long.

For each Sprint a Sprint Backlog is defined, which is the primary target that must be accomplished within the time set for that Sprint.

Each role in Scrum has a clear responsibility during Sprint Planning: • Teams look at the tasks at the top of the Backlog and estimate how much they can do in that Sprint.

• The Scrum Master and team should try to increase the number of points each Sprint.

• The Product Owner must make sure everyone understands the design vision.

In addition, during this meeting everyone must agree to the Objective of Sprint.

Make Work Visible The best way to do this in Scrum is to create a Scrum Board or Kanban, with at least three columns: To Do, Doing, and Done This is very good for making progress (or delay) visible to everyone, eliminating anxieties and addressing one of the main pillars of Scrum which is Transparency.

Another way to make work visible is to use the Burndown chart. That is structured by a number of points axis that the team has set for Sprint, and the other is the number of days.

The positive side effect is to have everyone on the same page and still motivate the team to meet the Sprint goal.

SIMPLICITY. Page 22 of 45

{---

product & agile

Daily Scrum Every day, at the same time, in the same place, for NO MORE THAN 15 MINUTES, the team and the Scrum Master meet to answer 3 questions, only: • What did you DO ONLY to help the team complete the Sprint goal?

• What are you doing TODAY to help the team to complete the Sprint goal?

• Is there any IMPEDIMENTO for the team to complete the Sprint goal?

This meeting is for the whole team to know exactly where they are in Sprint.

Sprint Review It is the moment where the team presents the results of Sprint and what has managed to evolve.

Anyone can participate, not just the Product Owner, the Scrum Master and the team, but also stakeholders, managers, clients and anyone else interested.

The team should only present what is COMPLETELY in accordance with Definition of Done, that is, what is completely and completely completed and can be delivered without any additional work.

Sprint retrospective It is a great moment to an efficient feedback process.

After presenting the product in Sprint Review, the Scrum Master, team and Product Owner meet and describe what went well and what could have been better, focusing on what can be improved at the next Sprint.

To be effective, this meeting requires a certain amount of emotional maturity.

The most important thing is to always remember that you are not looking for guilty; is looking at the process and improvements for the next iterations.

Page 23 of 45

Alexander Sarkozi

---}

Product manager vs. Product owner

Executives

Product manager

Product owner

Development

Page 24 of 45

Product Product Management Manager

Product manager

Marketing & Sales Markets & Customers

{---

product & agile

Role

Executives

Tasks

BUDGET / STAFF / TARGETS / STRATEGY / FORECASTS / COMMITMENTS ROADMAPS/ COMPETITIVE INTELLIGENCE

FIELD INPUTS / MARKET FEEDBACK /

Marketing & Sales Markets & Customers

SEGMENTATION / MESSAGES / BENEFITS / FEATURES / PRICING / QUALIFICATIONS / DEMOS

MARKET INFORMATION / MRD /

Development

PRIORITIES / ROADMAPS / REQUIREMENTS / PERSONAS / USER STORIES

Page 25 of 45

Alexander Sarkozi

---}

CH A P T E R NUMB E R FI V E

The planning of development iterations in agile methods is a task of fundamental importance for the success of the projects, since it is through a good planning that we will define which tasks will be included into a certain iteration and the priority of them. In this topic, we’ll talk about how Sprint planning meetings (or development iterations) work so that they are not longer than they should (the methodology is agile, remember that), and everyone leaves satisfied and clear should produce next.

Although we use the term Sprint which is the name given in Scrum for development iteration, the concepts discussed in this chapter can be applied to other agile methods that also use the concept of development iterations.

Page 26 of 45

{---

product & agile

DEVELOPMENT ITER ATIONS PLANNED R IGHT WITH AGILE Pre-Planning One tip that serves for the entire meeting is a good preparation. The Product Owner must be in tune with the needs of the project and the team (as well as the Scrum Master) must have the real notion of the team’s production capacity. Once aligned it is time to go to the planning meeting for the sprints itself.

Planning Meeting The sprint planning meeting actually has two parts. In the first one, the demands for the team are defined and the presence of the Product Owner is essential because it will describe a set of desired product stories and priority among them for the team. The goal is to provide enough information for the team to outline the tasks needed to create the desired functionality.

It is worth remembering that only team is able to define what it is capable of performing in the next sprint. The Product Owner should not make any pressure to include any item and it is up to the Scrum Master, the team mentor and facilitator, to ensure that the team understands what it should be doing and to only accept tasks and deadlines that it can accomplish.

Page 27 of 45

Alexander Sarkozi

Already in the 2nd part of the meeting, the focus is how the team will perform the desired functionalities, how the tasks will be performed, here the presence of the Product Owner is optional, but it should be available to take any questions from the team. In this step is defined the sprint backlog, the list of stories and tasks to be completed during the sprint.

The incremental and iterative nature of the agile methodology reduces the planning failures, since it alia constant contact between the involved ones and planning with delimited time and clear goal as a result. However, several factors can appear to change the planning made for a given sprint or even cancel it!

Poor evaluation of the priority of the backlog items, the actual capacity of the team to meet certain demand and even the appearance of a functionality by the client that was not foreseen.

The easiest way to make the necessary corrections is to seek out the stories impacted by the problem and change them, so that you make the most of what was already agreed during the sprint planning meeting. Another alternative is to replace stories that had not yet been started by those created from the new needs of the project. The purpose here is to avoid delay in the previously stipulated timeframe.

In a corporate environment where changes are constant, and the predictability level of these changes is also low, it is better to plan shorter duration iterations, which are less likely to risk midshift changes. Remember that during the course of the iteration we should not change the iteration backlog previously planned. The iteration burndown chart (if used) should reflect the planned tasks as close as possible to the planned, during the execution of the iteration.

Page 28 of 45

---}

{---

product & agile

CH A P T E R NUMB E R S I X

A CULTUR AL SHIFT NECESSARY TO IMPLEMENT THE R IGHT AGILE METHODS

As we saw in the previous chapters regarding agile methods, we can affirm that the implantation of these methods in traditional environments find several barriers. Anyway, this is probably the biggest challenge: cultural change!

In traditional methodologies of project management, we have been directed to maintain control over absolutely everything. For this is the way to ensure that things work: the roles of controller and controlled, boss and employee are needed. It is for this reason that the belief that people need a master to closely monitor activities is propagated, without believing in any way that they would be performed satisfactorily without such supervision.

Therefore, the main difficulty in implementing agile methodologies is the natural resistance of people to change.

How to implement the methodology After that, it is worth discussing how the changes are put into practice. Imposed change is nothing more than a posture of “boss and employee.� When there is someone responsible for thinking about all the details, offering the solution ready, the relationship of dependence only increases, because those who are not comfortable to do the activities with autonomy: experiment, make mistakes, learn from these errors and improve continuous mode.

Page 29 of 45

Alexander Sarkozi

---}

There is also a kind of tendency to seek the perfect methodology, as if there were only one form, one miraculous structure, superior to all others.

If you are one of those who believes there is only one answer to every question, you need to work on that “truth” better.

Each individual interacts in a single complex space, endowed with a set of positive and negative points, which require analysis and adaptability. That is, there is no absolute truth, but adaptation.

The bigger the environment, the more complicated the adaptation. Therefore, it is fair to point out that it is no use to address the external customer and say that he is called “product owner”, who will need to write certain things that are called “user stories” and that he will have to devote more time interacting with the project . After all, the person on the other side deals with guidelines from their own culture.

Organizational Acculturation It is important to make it clear that organizational culture change is a key factor for successful adoption of agile methodologies. It does not make sense to conceptualize the resources of your project as “agile team” if they are micromanaged. The same goes for saying that your teams are “empowered” if they can barely experiment on their own or miss an acceptable minimum.

Agile methodologies are in vogue, being the newest in management. But that is not why it should be implemented immediately on the largest corporation project, the one for which all eyes are turned. Keep in mind what you are experiencing, so perhaps it is more appropriate to do so in something not so great. The size or even difficulty of the pilot project should be handled with care.

Organizational self-knowledge It is essential to know well the environment that will undergo changes and to know clearly what the intentions of this cultural transformation are. Change requires not only learning, but also unlearning values, premises, and old work postures, before new behaviors can be added. The key elements of this cultural change are: support from senior management and training.

Using Refactoring: Improving code and making it easier to maintain constantly; Continuous integration: when the increment is ready, it is integrated into the system as a whole, that is, it is done daily.

Page 30 of 45

{---

product & agile

WHICH TOOLS YOU CAN USE IN AGILE DEVELOPMENT PROJECTS CH A P T E R NUMB E R S E V E N

One of the pillars of agile development is efficient communication among all involved in the project. For this, the waiting time for the delivery of functional software should decrease, since constant customer feedback is essential, facilitates and directs the work of the development teams. Another feature of communication in agile processes is the dissemination of information about the progress of projects in open boards known as information radiators.

Through the information irradiators, the exposure of the team activities brings visual control of the iteration. The tasks of a development cycle is usually controlled by a Kanban Board, where team members are able to obtain all the necessary information about what is being done by the team, those responsible for the execution of the activities and the status of the team’s current work.

As a way of facilitating communication, Agile Project Management Tools are great facilitators and can increase team efficiencies when well used.

As examples of agile tools we can mention Jira, Microsoft Team Services, Targetprocess, Trello and others.

Below you can see some project planning features that are desirable in Agile Tools: •

Resource management

•

Time tracking

•

Scrum support

•

Kanban support

•

Agile Development support

•

Backlog planning

•

Sprint or Iteration planning

•

Release planning

•

Test planning

•

Dashboard customization

•

Estimation planning

•

Monitoring the Iterations evolution through the following features:

•

Burndown chart

•

Number of available hours versus allocated hours

•

Number of backlog items for development

•

Number of bugs

•

Number of impediments

Page 31 of 45

Alexander Sarkozi

---}

There are tools that allow to customize a complete Dashboard and make possible to all team members have a faster view of the current position of your project, it is a great advantage over tools that do not have this type of feature, and greatly facilitate the summary view of the status of the iterations.

In addition to the project management tools, the Continuous Integration and Automatic Deploy tools are also important to agile projects.

If we analyze, within the development process, we work with a cyclical process that starts from development, build, deploy, operation, improvements and returning to development. Within a project this cycle occurs only between releases, but thinking of a factory or operation scenario this cycle occurs countless times, making all sense to automate this process and the tools that automate this cycle are key to increase team productivity and eliminate repetitive manual work.

One of the tools that perform this work and one of the most famous is the Jenkis. It originated under the name Hudson, started by Sun teams. But with the purchase of Sun by Oracle, theirs creators decided to make it fully OpenSource, changing its logo and its name.

Another tool that supports this process is Octopus Deploy, responsible for managing and controlling the process of deploying packages in their respective environments and configurations. In addition to deploy to multiple machines at one time when we are working with distributed environments. Its configuration is based on the concept of server and agents, where the server is a portal where the deploy process is configured and the agents are executable installed on the machines that will receive the deploys.

There are several ways to integrate and automate the integration and deployment process. Following the practice of Kaizen, the focus should not be on automating all your processes at a single time, but rather look for automation, integrating your small processes and that can give a greater productivity gain in your day to day. It is very important to choose the best tools to improve the productivity in the agile methods.

Tools for agile: https://jira.atlassian.com/ https://www.targetprocess.com/ https://www.visualstudio.com/ https://trello.com/ https://jenkins.io/ https://octopus.com/

Page 32 of 45

{---

product & agile

BE HONEST! TR ANSPAR ANCY CH A P T E R NUMB E R E IGH T

According to Scrum Guide, the transparency is one of the pillars that support the process. Below you can see the definition for transparency: “Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.”

In addition, Scrum artifacts also provide transparency in the agile process.

“Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.”

Page 33 of 45

Alexander Sarkozi

In many aspects in agile software development, the importance of transparency becomes true and daily. Bringing the client into the project is an act of transparency, and also the best way to identify problems and bottlenecks in a project.

Ceremonies such as the daily and retrospective make everyone understand the work done, feel confident that the project is going in the right direction, and have the opportunity to expose their afflictions and ask for help.

The anticipated feedback from the customer that the agile methods provide also proves that transparency is critical to project success.

And how to ensure that employees feel they belong to the projects and the company, to the results, to success and failure? Transparency.

And how is this done? Below we can see some actions that can be used within an agile context, to give more transparency to the process.

Page 34 of 45

---}

{---

product & agile

•

Feedback 360: In this dynamic, who gives feedback is the team and

not the manager. In a follow-up worksheet, listed items are listed after research and discussions about what are the most important aspects in maintaining and growing peer relationships. Everyone gives feedback and everyone receives, without exception.

•

Ceremonies of agile methods: daily and retrospective should be pres-

ent on the day. These ceremonies generate transparency in the work that is being developed.

•

Visual management: through an efficient visual management, with

frames and tools, we increase the transparency.

•

Goals: when definition of goals are clear, this provides a greater

interaction between the team and a commitment of the team, again the key is transparency.

•

Definition of done: a clear definition of done is fundamental for agile

methods (for example Scrum) it is also a concept that prioritizes transparency in the process.

•

Tools for agile methods: the use of agile management tools helps in

the transparency process, as through these tools, the access to key information from development iterations can be easily accessed by the entire team. In addition it makes possible to disseminate information to more people simultaneously and helps establish the practice of sharing knowledge and transparency as part of the organizational culture.

Transparency is a building and something to work on a daily basis. It involves a lot, many issues like efficient communication, trust, understanding and so on. The most important thing is to understand that all this is a matter of simplicity and intelligence, always with the aim of increasing efficiency in the process.

Page 35 of 45

Alexander Sarkozi

---}

CH CH APT E R ENINE AEPRT ENUMB R NUMB R NINE

HOW DEVELOPMENT TEA MS EVOLVE BY USING AGILE METHODS

The agile methods, since they have as a characteristic to enable flexibility and empowerment of people, are facilitators for the maturation and evolution of the teams.

According to Scrum Guide (http://www.scrumguides.org/), in the definition of an agile development team, it is clear the application of the concept of empowerment and autonomy that the team must possess. See below this definition.

“Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.”

A real development team will emerge when individual members can overcome their differences.

Conflicts give rise to new ideas and the meeting of a foundation, a common basis. This common ground leads to shared goals, more transparency and focus on team. The constant feedback and retrospective meetings are important factors that help the teams to become more efficient.

Practices like Pair Programming, TDD and Continuous Integration take the practices from a personal stage to a team stage.

The retrospective meetings become a place where people not only complain but actually discuss improvements and new standards. The definition of ready is used regularly by each member of the team.

Page 36 of 45

{---

product & agile

As the team matures, performance indicators are not just

Motivated teams are generally happier in the environ-

numbers but they are really driven by team behavior.

ment in which they are working, this contributes to

Team members measure their own performance and

increased productivity and helps keep the costs down on

improve their metrics for greater control.

a project. The satisfaction that the agile methods provoke in a team is exciting, the pace stays sustainable in the

The concept of multidisciplinarity used in the formation of

work which makes the employees appreciate it more. In

agile teams causes some to take over the work of others,

addition, there are rare cases where an employee needs

as the team values achieving the goal of development

to perform overtime.

iterations, rather than working in their own disciplines. In addition the work in agile methods is based on commu-

The productivity of development teams in well-deployed

nication, simplicity, feedback, courage and respect. This

agile methods tends to be higher, since an agile team is

philosophy of autonomy and simplicity ensures that the

less likely to develop useless or ineffective functionality in

agile team can take care of the problems that are at hand

a project. Traditional methodologies generally have dif-

and touch the project without having to stop what they

ficulty delivering functionality that is really necessary for

are doing and ask them to do the right thing.

the customer, thus increasing the chances of failure. With a focus on delivering value to the customer, short devel-

And these teams offer much more value to the project

opment cycles and frequent communication, agile teams

just for that reason.

are more likely to deliver functionality effectively needed by the end user.

They pull the work out for themselves and take on the responsibilities. They tend to manage all their work as a group and thereby improve their individual skills in a continuous and healthy manner.

Page 37 of 45

Alexander Sarkozi

---}

Agile deployment

Daily Stand up Develop Functionality 2 Integrate + Test Develop Functionality 1

Product Backlog

Sprint Backlog improve

Page 38 of 45

{---

product & agile

Integrate + Test Develop Functionality 3 Integrate + Test

Yeahhh

Demo Release

Client Feedback

Lovely Product

ähh no

Page 39 of 45

Alexander Sarkozi

---}

WHY YOU SOMETIMES NEED TO FORGET EVERY THING AND WOR K ON YOUR FLEX AGILE GA ME CH A P T E R NUMB E R T E N

In many companies, either through the organizational structure or the cultural aspects highly rooted in top management, we will not be able at first to apply agile in its entirety, and some adaptations are necessary.

As we saw in previous chapters, agile methods have many ceremonies that are part of the development process, but it is important that these models be a guide to be adapted as needed, since we will often not be able to apply in practice all these ceremonies.

Since the agile methods are highly adaptable, it is normal for each team to make adjustments in the process in order to optimize the work and make the process more productive.

According to definition of Pressman (Software Engineering A Practitioner’s Approach), the agile methods must allow the adaptation of tasks within each process. “Agility can be applied to any software process. However, to accomplish this, it is essential that the process be designed in a way that allows the project team to adapt tasks and to streamline them, conduct planning in a way that understands the fluidity of an agile development approach, eliminate all but the most essential work products and keep them lean, and emphasize an incremental delivery strategy that gets working software to the customer as rapidly as feasible for the product type and operational environment.�

Do not forget that the implementation of a certain agile method must be done in a way that the real agility will be achieved, even if some adaptations are necessary and must be done in the original process proposed by these methods.

Page 40 of 45

{---

product & agile

In addition, shortly after the publication of the agile manifesto and the consolidation of the agile methodology, the boundaries of software development companies were exceeded. Today, the techniques and philosophies of this new school are applied in companies and organizations from several other areas. This popularization eventually created subtypes and adaptations for agile management.

Remember that by making agile methods more flexible, it is necessary to maintain some basic principles of agility: active participation of users, autonomy for project members, requirements capture at a high level, parts of the project (frequent delivery of packages), completion of each part before moving on to the next step, testing at all times and collaboration and cooperation between all parties involved.

However within this context and maintaining the basic principles, flexibility can occur in the concepts of tasks and ceremonies that each method proposes.

Agile is not only made by a set of ceremonies, it is much more and can be adapted to each business scenario, just pay attention to follow the philosophy of agile manifesto. In the end, the goal is always to increase productivity with quality and customer satisfaction, the process can be adapted to meet the goals maintaining the concepts of this philosophy.

Page 41 of 45

Alexander Sarkozi

---}

PRODUCT M ANAGEMENT VS. TECHNICAL PRODUCT M ANAGEMENT CH A P T E R NUMB E R E LE V E N

Product management is one of the hot-shot jobs at the moment. Breaking into this field has become in high demand due to this fact. However, there are various role and title specifications that could confuse people who are not versed in the subject.

As each new day dawns, there has been an increased demand for product managers especially on popular job listing sites like LinkedIn. These job listings for qualified technical product manager candidates run into hundreds and thousands from across the continent. Side by side with these postings are equally hundreds of job postings for digital product managers and principal product managers vis-a-vis upstream product managers. This is excluding a few thousand job listings for generically-labeled product manager.

While a layman may find these job specifications to mean the same thing, they are not. Using the example of a product manager and a technical product manager, these specifications are different with some form of specialty needed.

As is popularly advised, product managers are asked to invest in learning technical skills. This fact is made known in popular threads on product management forums. One who does not seek expert opinion may be led to believe that a technical product manager is a hybrid of product management and engineering. On the contrary, Technical product managers bring a deep technical expertise to their role but still focus on the core best practices of product management. Their roles are not quite different from the role and responsibilities of a regular product manager.

When addressing similarities of both job descriptions, here are some things you should know: •

Strategy: Both managers are responsible for setting a product vision and strategy

•

Ideation: They gather and promote the most relevant ideas into features

•

Road mapping: They plan and prioritize what (and when) the product teams will deliver

•

Features: Both managers define the “what” with user stories and requirements

•

Go-to-market: They work with cross-functional teams to deliver a complete customer experience

More often than not, these similarities are stretched and expanded to cover existing knowledge into new areas of product management. Ultimately, learning new tricks remains the fastest way to learn and grow.

Page 42 of 45

{---

product & agile

Although the difference exists as a thin line, a line exists nonetheless.

Here are some of the differences:

Degree

Product manager: More likely to have a degree in business Technical Product Manager: More likely to have a degree in computer science or engineering Focus Product Manager: Often customer-facing and involved in setting the overall product strategy Technical product Manager: More focused on how the product works on a technical scale Teams Product manager: Collaborates with many non-technical teams, including sales, marketing, support and works with outside partners and other third-parties Technical Product Manager: Works closely with technical internal teams, including engineering and development, to write user stories and requirements Research

Product manager: Studies the competitive landscape from a strategic business and go-to-market perspective Technical Product manager: Evaluates competitors and the market for capability-oriented and emerging development and technology trends Technical know-how is the essential ingredient that helps product managers communicate clearly and effectively with their engineering team. This technicality also sheds more light on new development approaches and technical capabilities that might yield better results for customers.

With the rise of new companies who have embraced both job specifications comes an understanding that for their companies to excel, there is the need for two product management roles — a business-minded project manager and a technical project manager. Others simply go with expedience. They determine if it is best to have one person leading a product who can answer the “why” and the “what” and who can also engage in the “how.”

Company rules vary and titles do not always reflect exactly what people do. Technical product managers who do not have strong technical skills and product managers who transitioned into their role from software development need to find a way to upgrade their skills. Regardless of semantics, all product managers need to demonstrate the same skillset skills necessary for executing product management’s best practices — including clear communication, leadership, diplomacy and compassion.

Page 43 of 45

Alexander Sarkozi

---}

THANKS A great Product is like a beautiful dance. You have to know what you‘re doing in order for it to look great, feel fabolous and make it look simple.

You have to put in the work, effort and show everybody on the team your gratitude.

Enjoy the ride and make great products!

Page 44 of 45

Roger S. Pressman, Software Engineering A Practitioner’s Approach The Agile Manifesto (http://agilemanifesto.org/) The Scrum Guide (http://www.scrumguides.org) https://danielettinger.com/2011/10/17/dificuldades-na-implantacao-de-metodos-ageis/ https://www.devmedia.com.br/uma-visao-geral-sobre-metodologia-agil/27944

a.sarkozi@welcomemonday.de

DANCING WITH THE PRODUCT Quotations and references