Agile

All the text and images were created from Casa do Código book

BEFORE ALL

Focusing on what Agile is here, on legal implementations is following the XP book, Scrum as it is a fact each Agile implementation taught the most detailed step-by-step (in love with XP).

Project is a marathon not a sprint, so it's best to run with cadence to reach the end of the marathon.

XP, Scrum, Lean Software Development, BDD, DDD, TDD, Automated Testing, Kanban, Planning Poker, Solving Technical Debts, Refactoring (to database), Clean Code, Continuous Delivery and DevOPS, Reading About Software Development, Craftsmanship of Software.

Not agile but cool: PMBOK, Traditional project management is based on the ten areas of PMBOK, which offer decades of experience in a framework that is practiced on a large scale by governments, large companies, and especially by other areas of knowledge where it is still the only and best way to manage projects

About TDD it's nice to read the book to understand best practices for each one and if it will apply to me

Preface

Here he gives all his motivation, as it was before and he was unmotivated until he discovered Agile. Then he ends up going into more detail on the motivations for agile and an introduction to the book such as:

But, after all, what is Agile? Is it a methodology? A process? A set of values? A manifesto? Tools? Practices? A move?

Introduction to Agile Methods

He starts by giving an example of how waterfall fucked up the life of the girl who threw 8 months of work away, then he said how agile came to solve this.

Here I can do something similar, explaining my case to myself

The Agile Manifesto

Here is telling where it came from, it's kind of cool to copy because it's history and take what's on the site itself to make your own interpretation

Agile methods

Here it basically talks about what they all have in common and gives examples like:

Scrum, Extreme Programming (XP), Crystal Clear and Feature Driven Development are examples of agile methods. Each of them brings a different approach that includes different values, practices and meetings.

Explaining the focus of each one, not that one replaces the other but that each one has a specific focus. Basically say the same, probably have to come back here later.

The cascade of traditional methods

Here talks about how it was before and compares with Agile in some points

Prescriptive and adaptive methods

Here explains with method Agile uses:

Agile methods are adaptive rather than prescriptive, so they encourage continuous improvement.

Always going deeper into the term and comparing, a quick comparison between some agile methods (number represents number of prescriptions):

Understanding agile values

Here comes that sweet talk that I'm finally understanding today, taking the team more homogeneously, not that members can be replaced. Each member has their strengths and weaknesses and that's it. The focus should be on those on the left of the board, not on the right, those on the right have already done their duty and now have to help those on the left. It is the boss and HR who congratulates or listens, not who is responsible for managing the project.

The first value, which says “individuals and the interaction between them more than processes and tools”,(...)

Also consider having the software always working, having a wiki and a README.MD there, with CHANGELOG.md to understand the project and that's it. Those who don't understand something of a technical concept should stick to the side, don't explain code, but always take care not to leave something too complex for the rest of the team, at the same time that the code quality must be maintained. The project leader must always help the little ones to grow through more complex activities, the tricky and simple ones he solves quickly and soon the others he is helping will also end up learning better.

The second value “working software over comprehensive documentation” is(...)

As every project obviously must have a client and it is obvious that there will be a contact with deliveries that you must commit to, don't make fun of letting the client keep changing this without cost, but if you give a touch of obvious things that were not thought of during project planning, I don't know, the date format should be Brazilian or have a cool drag and drop. Things that you pick up from the client little by little, with feedback.

“Collaboration with the customer is more valued than contractual negotiation”(...)

When we are in an environment of instability, you must adapt, as long as you are aware that the dollar is high and put a server in Brazil or that the energy is high and put a server in Brazil, that library will die and adapt.

Finally, “responding to change is more important than following a plan”(...)

Benefits of agile methods

Here basically talks about all those beautiful and beautiful reasons, what I can do is go item by item to explain it in my own words :)

Adding More Value with Scrum

Here it talks about the guidelines such as planning time, PO, Scrum Master and the rest of the team that must be multifunctional and etc…

It's nice to see the product backlog and the sprint backlog there. Not counting the 'potentially deliverable'

Technical Excellence with XP

It explains the story where it came from and the four basic activities to be performed:

Listen

To draw

Code

Test

He goes from point to point and explains, I really liked that part. Trying to explain with something in practice

Continuous flow with Kanban

It's legal here, as mentioned in the first paragraph. Which here decouples planning, prioritization, development and delivery to adjust better according to reality.

Here he talks about time and they don't matter, in practice it's good to be interested in the comments to solve the item and time is weight, when explaining weight explain what weight is and ask if it makes sense.

What's the best method?

Here he quotes someone and explaining that comparing these three methods is like comparing a fork to a knife makes no sense. Each one has their goal to solve some problem. Then I can be speaking in my own words examples.

And now, what do I do tomorrow?

Here there is more talk about reflections on agile values, in your team, with you, etc… Here I will explain MY motivation. Do something to have more empathy, make the person think with what I thought there.

Agile fluency

Then create the example of the monkey to better explain how this is done, what happens there in the experiment. Then he talks about the 4 distinct stages that the team must go through to reach agile fluency, like there in the monkey, not understanding but practicing and thinking, getting out of waterfall thinking

1) Focus on Value (Acting in the Culture of the Team).

2) Value Delivery (Acting on Team Skills).

3) Value Optimization (Acting in the Organizational Structure).

4) Systemic Optimization (Acting in the Organizational Culture).

Evolution and Maturity of an agile team

Nice to try to use catchphrases, to give a better motivation while reading like:

Coming together is a good start, staying together is progress, and working together is victory.” – Henry Ford

It talks about the whole process to implement this, how it is for a human being to understand:

Agile maturity

Talking a lot based on the monkey there, not only is the team learning to work with agile methods but also maturing in the use of agile practices. From getting into the blood, like in monkeys, to later adapting, it's impossible to follow exactly what's in the book.

The three stages of this maturity are best explained (explain item by item):

Order, chaos and complexity

Basically, it says that every change process needs to have freedom, but not all of it because it creates chaos, so there must be order with rules but not putting in so much bureaucracy that it becomes a ô, that's where Agile comes in, trying to find the middle ground between the two.

“Every organization is a complex adaptive system, it's like a game in which the rules are changed over the course, and by the participants themselves.” – Jurgen Appelo

Nice of this chapter that goes deeper there explaining in my own words how I can do it myself, always trying to emphasize the same points if not adding more points based on things I learned in practice

And now, what do I do tomorrow?

Here basically is to reflect on your team, employee turnover inside and outside the company and how your team is doing based on what was said above, to find a meeting point to better understand the subject

Focus on business value

There he gives the whole sermon on value for the business, very nice to read it carefully and then explain it in his own words

Disseminating the project vision

Basically, he says that the idea comes from people and everything has to be written down on paper, to be clear about what will be done and in fact it is viable as it is viable.

So there are three questions that the visionary needs to communicate to the team (which are not inside his head):

1) What objective should the project achieve?

2) Why will this project add value?

3) How to measure if the project was successful?

Some teams maintain a Wiki answering these three questions above. However, whenever decisions are taken, the visionaries of the project must be present, also better explain the reason.

Something that should have a very clear answer and how to act after having it, is the question: Is everyone on the same page?

the elevator speech

That same startup idea, finding a short and clear way to explain your project idea, this speech should include the following items:

1) Who: What do you most want your listener to remember about your organization or product?

2) What: How will your product add value and bring results or impact your listener's business?

3) Why: What are the unique benefits, the differentials that your product offers?

4) Purpose: What do you expect the listener to do?

Iterative planning and development

Here it basically answers how to better deal with the planning and development of the project that will end up changing, it explains a little about XP (which I should go into a little deeper)

Planning an iteration

For each story I must have interaction and when one ends I start another, until I have a release delivered

nice that each iteration is weekly, but the times for iterations and releases can be defined according to the needs of each organization.

VERY IMPORTANT TO TAKE CARE OF THIS PART, READ IT CAREFULLY, TO AVOID SHITS THAT WILL HAVE TO RUN LATER OR LEAVE EVERYTHING MESSED UP.

Daily meeting

That stop of everyone standing up, has the same practice in Scrum and XP.

In Scrum, for example, each team member responds:

1) What have I done since the last meeting (yesterday)?

2) What will I do until the next meeting (until tomorrow)?

3) What problems are preventing me from progressing?

Tim Ottiger, suggests 4 other questions that have a greater focus on delivery, learning and collaboration:

What stories have you helped finish since the last daily stand?

What story will you help finish today?

How the rest of the team can help push a story to “done”.

What did you learn again?

Which I found a little strange, but it makes a lot of sense to stop thinking about the group and focus on what's to the left and not what's to the right, really interesting

Finally, he talks more about the number of team members that the more, the worse it is for the management and so on, even to explain this more, he already separates it in the book in another chapter, so it's cool that we follow the same example

An example is also given within chicken and pig agile

Limiting work in progress

Here there is a lot to do with limiting one issue per person, the amount of work in progress at the same time to have more assertive deliveries and remember that it is more a group than individuals, so it is deliveries by all or none, the group must be seen as one.

Here it is even nice to learn how to apply it according to each project, some it is good to have just the whole, doing, done and closed for example, here is a bigger example (without the closed, sprint backlog, project backlog), even for the team not losing motivation is nice to have one from the PO with the product backlog and another from the sprint for the dev:

Writing user stories

Who is the best to write the story is the PO himself in his own words and then go through acceptance, to see if it makes sense for the client, for the team, for the business and for the technical part.

Some examples of stories for valid users in a social site development project could be:

A user can publish their photos in their profile;

Users can create and participate in communities;

Communities must have moderators.

Mike Cohn proposed an interesting format that is widely known and used in the market:

"I, as a (role) want (functionality) for what (business value)."

If we apply the model proposed in the stories mentioned above, they would look like this:

As a forumist I want to publish my photo on my profile so that other participants can identify me more easily.

I as a user would like to create a community so that I can bring together people with similar interests to mine.

I as a moderator would like to approve or reject replies to forum threads to prevent inappropriate posts.

Investing in good stories

Give a tutorials following what Mike Cohn author of the book “USer Stories Applied” comments with 6 items and then talks about INVEST:

I - Independent

N - Negotiable

V - Valuable

E - Estimable

S - Brief

T - Testable

Themes, epics, features and stories

They explain that it follows this structure:

**Themes >> Epics >> Features >> Stories**

Sharing stories

Talk about dividing user stories into interactions is too big, so it's necessary to break the stories, but it's important to keep the INVEST

Breaking stories into tasks

Stories (which should already be broken) should always be broken into tasks that can be completed in one day, to then deliver an interaction that completes a story, this story is part of a larger story.

Just see how it relates to epic, interaction and release because I get confused.

Mapping user stories

Basically I decompose high-level user activities into a workflow that can be further decomposed into a set of user stories

It's good to read this chapter carefully to be able to explain the arbitrariness in one's own words, not just say what's in the book and fuck it

Getting to know users through personas

Persona is more about understanding the customer, who must follow rules to understand the persona, for example:

Improving predictability with estimates

It will take more the part of explaining that in the beginning it will make mistakes, because the team is getting to know each other, learning the technology and the project. Something that will help to give weight is the plain poker proposed by the scrum, whatever will be used what matters is measuring speed based on the weights resolved in each sprint to provide predictability for those interested (stakeholders)

Defining deliverables with release planning

It basically talks about having small releases, how nice to do them every 2 weeks with all the project's stakeholders participating, to even help clarify what will need to be changed in the project.

Always keep a small backlog and focus on what is time-to-market, which is what matters to the customer, fuck if it's rest or graphql but delivery, then you can have the squad just to improve that but it will never be the focus at the beginning.

Product roadmap

It must be well defined what will be delivered in each Release or when each Milestone will happen

It's great to be short, because things will change according to how the project goes on, as the agile method itself proposes. However, the roadmap can often be useful for marketing and business teams to position themselves in relation to (more or less) when certain functionalities will be available for advertising purposes, training, etc.

Keep the options open

It goes back to what the agile method proposes to keep options open for change, it also goes a little deeper into this, explaining better

Feature injection

It talks about the care in having several functionalities from the beginning and gives rules of which ones must be from the beginning, in addition to how to know if one should enter or leave.

And now, what do I do tomorrow?

Now it reflects a lot to know if the project structure assembled so far makes sense, it shows reflections that you should have based on what was taught and saying each term should be used to answer such questions

Delivering value

This is the second level of agile fluency, where the predominant benefits are the

high productivity and improvement in the external quality of the product.

Teams at this level of fluency have the ability to keep their products always (or almost always) in a ready-to-deliver state, thus allowing the product to be updated with the speed and frequency that the market demands.

Once you've reached this level, when you're already delivering value, you start to see the code more fondly, improving the legacy and teaching less experienced people

Agile testing

Here we talk more about testing strategies for an agile project, tests that must always exist and be guaranteed

Unit tests

Doing that naughty TDD is explaining a few more things based on what we found in XP

Testing first with test-driven development (TDD)

That happy TDD thing, there are two strategies from the book where I make tests fail and then I make them pass during implementation:

1) Add a test quickly.

2) Run all the tests and watch the new test fail

3) Make a small change to make the test pass.

4) Run all tests and note that they were successful.

5) Refactor.

Another strategy is to run a test that solves an implementation and make the correct code, then test another implementation and make the correct code and in that time improve the code in a way that the previous tests do not break

Testing end-to-end (E2E) with acceptance testing

That stop, in addition to the unit, do these tests too 😃

Go beyond exploratory testing

It's that thing of taking the tester and creating other testing possibilities, very essential when you discover a failure is you create a test that catches the failure BEFORE correcting the failure. For it to happen again, you know that it happened and solve it

Dealing with legacy code without test coverage

One of the options to change this scenario is to improve test coverage.

little by little with each iteration. For this, Henrik Kniberg suggests the following process [35]:

1) List your test cases.

2) Sort each test by risk, cost of testing manually, and effort to

automate the test (see figure 4.3.

3) Sort by priority.

4) Automate a few tests each iteration, starting with the highest priority cases.

Once the list is ready and classified, it is possible to prioritize and start with the

tests whose absence presents a greater risk, and which have a higher cost of performance

manual and lower cost of automation. For heaven's sake, non-automated testing in 2018?

Simplifying code with refactoring

It gives some strategies, how to follow design patterns

Clean code

It also lists the motivation and the list of what defines a clean code.

Collective ownership of code

Code Collective Ownership is one of XP's practices and consists of the idea of

that the team is responsible for the entire code repository rather than individuals

only be responsible for the code they wrote themselves.

Then some examples and motivations are given.

Ubiquitous language

In his book Domain-driven design (DDD), Eric Evans coined the term

Ubiquitous that concerns the creation of a common language among experts in the

business and the software development team. In this way, the same language

of business is used in the source code of the software itself, when naming

to parameters, methods, variables, classes, tests, etc.

Agile design is iterative design

One of the biggest mistakes in waterfall development is thinking that knowledge

exists only in the form of requirements raised before implementation begins and

separate from development.

Then he gives the sermon on agility when subri requirements

Defining the meaning of Ready

Once approved, you must also follow a list of requirements, in addition to fulfilling the description of some common items:

Refactored code.

Code within coding standards.

Revised or pared code.

Code integrated into the version control system.

Updated architecture documentation.

Unit tests performed.

Acceptance tests performed.

Exploratory tests performed.

No outstanding known defects.

PO accepted in history.

Updated User Manual.

Continuous integration

Do it

Pair programming

All that nice talk, in addition to improving the group, it's great to go there when it's in-depth about it to also go in depth

Code review

It has to at least one other dev. evaluate the code, but there are some strategies that I know in practice and that are mentioned in the book

Technical debt

In practice I know how it happens, but it's nice to read the book so I could explain it with a better context

Explicit agility with practice wall

Gives a lecture on why it should be done, which is basically having a team practice framework that can be in the WIki, Readme.md or code of conduct in the project structure itself

And now, what do I do tomorrow?

Basically it's sitting down and seeing how this applies to your team, with everyone (PO)

Optimizing value

Third level of agile, now the team already understands well what the market wants and is optimizing its solutions, also some other things like ROI there

directing the team

Make that beautiful stop, for new members to listen to when they join the project, for example.

Define the vision, purposes, objectives and goals of the organization and the project in

what the team is working on is a great way to show everyone the direction to

which they must together take the organization through the work carried out on a day-to-day basis.

agile metrics

Having better metrics to better understand the team, as already said, to optimize. A good practice is the burndown chart that sees the expected delivery points during the sprint (in days) and how it was delivered:

Using the Burnup chart as an alternative:

For a more accumulative course, there is another one:

To measure speed:

Types of metrics

It tells the types of metrics that can be used and their explanations.

But who is responsible for the metrics?

Has the tracker in XP

Present the result in demo meetings

How it should be done, the compliance of the stop

Continuous improvement with retrospectives

Not to blame, but how to improve, there are perspectives (stuff that George said and there is in the CoBlue book)

Retrospective facilitator

It's the guy who guarantees the focus and what will be done, there he gives more instructions on how to do it

The 5 stages of retrospectives

1) Preparation

2) Data Presentation

3) Insights

4) Decide what to do

5) Closing

Opening the retrospective

Explaining how to do it

Presenting data

Explaining how to do it

Generating insights

After that, there is something to improve

Other than that, here's how to do it

Defining retrospective actions

Again, the conformants and addendums

Closing the retrospective

The compliant….

Eliminating Waste with Lean

That stop, cleaning what is not necessary and is wasteful

Waste with partially finished work

Does it give a point of view on that, to finish what was done or throw it away so as not to spend even more on it?

Waste of functionality that does not add value

Compliance and point of view

Waste of documentation

Conforming, tips on not giving tutorials or documenting each line with 1001 details

Waste due to lack of photo

Keep the team focused on one activity, not switching between activities

Waste due to delays

Keep the deadline to resolve something like impediment, approval, review short

Waste by unavailable resources or people

Always have some resource or person from plan B in case A is not available

waste due to defects

Whenever found, they must be resolved, to avoid expenses

And now, what do I do tomorrow?

It basically says to use those graphics over there and think about waste, especially during retrospectives

Optimizing the system

This is the fourth level of fluency, here you start wanting to change rest for graph and etc…

Can management be agile?

Gives that whole long story… I can interpret and write

Energize people

Now that you make everyone happy

Empower teams

Give power of choice, as they are mature enough to take it on their own

align constraints

Here's to the self-organization part when it comes to empowering teams, don't get out of hand

Develop skills

Borrow and train, move up in position, not hire more

Structure

Improve things that promote communication, for example

Improve everything

Follow some guidelines of what to do to know what to improve when improving yourself

Feedback

One of the values of XP is feedback

One-on-one meetings: Getting to know the team

Talk people to people one-on-one by asking a few questions:

How are things?

How is your project going?

What do you like most about your job?

What are the most frustrating aspects?

Could you tell me more about...?

Feedback 360

Give feedback with multiple points of view

Scaling agile with programs and portfolios

How to follow the rules

Team formation

That cross-functional team shit, we can get into the squad shit

Learning practices

Compliant

The environment makes a difference

Compliant

Commit to your career

Compliant

The basic

Conforms

coding dojo

Basically putting a few people in a room doing activities, there are several types and dojo like Randori Kata and Prepared Kat

Book discussion club

Basically everyone reads a book and then talks about it

Brown Bag Sessions

Talk something over lunch

Hackathons

I already know…

communities of practice

Sit down with other sectors to share practices

And now, what do I do tomorrow?

Take problems they have faced and try to solve them with what was said there