Agile practices for product management

@edolopez

Outline

1. What is Agile?2. The procedure.3. Effective Meetings.4. Roles and the Agile Coach.5. Caring about quality.6. Prepare for feedback.7. Growing you.

What is Agile

What is Agile

Agile

● Agile is a time boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end.

● Agile is all about teams working together to produce great software products.

● Many modern teams are using a mixture of Extreme Programming (XP), Lean, and Scrum.

AGILE PRINCIPLES

1. Customer satisfaction by rapid delivery of useful software

2. Welcome changing requirements, even late in development

3. Working software is delivered frequently (weeks rather than months)

4. Close, daily cooperation between business people and developers

5. Projects are built around motivated individuals, who should be trusted

6. Face-to-face conversation is the best form of communication (co-location)

7. Working software is the principal measure of progress

8. Sustainable development, able to maintain a constant pace

9. Continuous attention to technical excellence and good design

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

11. Self-organizing teams

12. Regular adaptation to changing circumstances

Beck, Kent; et al. (2001). "Principles behind the Agile Manifesto". Agile Alliance. Archived from the original on 14 June 2010. Retrieved 6 June 2010.

Why from the software industry?

● Since 1957 software projects have been tracked.

● Many similar circumstances and problems have appeared with traditional methodologies as Waterfall.

● Broad investment of resources for long term planning projects with no relevant outcome.

● No alignation with users and customers expectations.

● Creative work and job that is reference to other industries in the same situation.

The procedure

Procedure

Procedure

Spikes

User Interface &Design Testing

* Every agile procedure needs to adapt to the context of the product, client and/or user.

Iterations

ProductBacklog

SprintBacklog

Procedure

Spikes

User Interface &Design Testing

* Every agile procedure needs to adapt to the context of the product, client and/or user.

ProductBacklog

(Sprints)Iterations

Releases

SprintBacklog

A team works in iterations to deliver software. Each iteration opens with planning based on

user stories and closes with a demo and retrospective. The team works in a shared workspace and starts their day with a daily

standup around their team board.

Software is created using Test-Driven Development and Continuous Integration.

Some teams work in short one-week iterations, while others work to a monthly cadence.

In the context of the Scrum Methodology

(Iteration)

Release 1Release 2Release N

Product design & development

The MVP

"The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." - Eric Ries

Agile working on Startups and MVPs

Estimates & Spikes

● The estimate is a practice to evaluate the human efforts needed to achieve a goal within a sprint, iteration, release or project.

● The best estimate is the one backed by experts.

● In an agile context, planning poker is a very common technique.

● Spikes are brief sessions to evaluate a conflict or anything that needs to be assessed among the team members.

Estimate points● Size:

○ Many Agile estimates rely on “Relative Sizing” rather than “Individual Sizing”.

○ Typically you will find fibonacci points. It doesn’t matter how exact you are per story, but the dependencies and complexity between the stories.

○ Other option is Ideal Days.● Effort:

○ Amount of hours for a story, epic, theme. ○ Translation of size and points to hours.

● Velocity:○ The amount of points/hours delivered per sprint or

iteration.

User Stories

As a (type of user) I want (some goal/desire)

so that (benefit).

Examples:1) As a Student 2) I want to purchase a parking pass 3) so that I can drive to school.

1) As a user2) I want to search for my customers by their first and last

names.

Ron Jeffries wrote about the Three C’s of the user story:

1. Card: stories are traditionally written on notecards, and these cards can be annotated with extra details.

2. Conversation: details behind the story come out through conversations with the Product Owner

3. Confirmation: acceptance tests confirm the story is finished and working as intended.

The Three C’s happen during the beginning of the an iteration or a sprint to clarify anything and be on the same page as the product owner.

Acceptance CriteriaAcceptance criteria define the boundaries of a user story, and are used to confirm when a story is completed and working as intended.

For a payment user story, this could be an example:1. A user cannot submit a form without completing all the mandatory fields.2. Information from the form is stored in the registrations database.3. Protection against spam is working.4. Payment can be made via credit card.5. An acknowledgment email is sent to the user after submitting the form.

Including acceptance criteria as part of your user stories has several benefits:● They get the team to think through how a feature or piece of functionality

will work from the user’s perspective.● They remove ambiguity from specs (requirements). ● They form the tests that will confirm that a feature or piece of functionality

is working and complete.

(Given) some context(When) some action is carried out

(Then) a particular set of observable consequences should obtain

An exemple:1) Given my bank account is in credit, and I made no

withdrawals recently,2) When I attempt to withdraw an amount less than my

card's limit,3) Then the withdrawal should complete without errors or

warnings

Tests passing means the finalization of certain user story.

“Teams who are not yet very experienced with these ideas often want to try use cases, spreadsheets showing

calculations, sketches of proposed window layouts, even multi-page documents looking much like

conventional specifications. These may be useful in rare cases, but looking back over the years I have almost never

found this kind of document to be ideal.”

- Ron Jeffries, XProgramming.com

Design

● Few information is available about agile procedures and design (Lean UX).

● Nowadays products need to consider both development and design elements in the entire building procedure.

● As with the code, design needs to be tested.● Design is one of the best ways to validate

products without investing lot of efforts.

Design in agile procedures

Artifacts

Backlog

● A list of user stories to be done. ● The priority is on the current sprint, then the

current iteration, then the current release. The less prioritized features are on the product backlog.

● A formal approach to prioritize the backlog - “Grooming the product backlog”.

Prioritization

● A very important variable while planning iterations and sprints.

● Take epics and themes as a reference to prioritize.

● Best teams invest “10% of their time to groom the product backlog” says Mike Cohn.

Prioritizing your backlog

● Kano Analysis: It’s more useful to make a little survey for 20 to 30 users.

● Theme Screening/Scoring: Select 5-9 features and assess the most important for the next release.

● Relative Weighting: ROI, NPV, IRR implementing new features.

● Expert Opinion: Delivery of new capabilities, development of new knowledge, mitigation of risk & changes in relative cost.

Effective Meetings

The Standup Meeting

● A common ritual building tech products.● Goals for a daily stand-up meeting:

1. To help start the day well2. To support improvement3. To reinforce focus on the right things4. To reinforce the sense of team5. To communicate what is going on

As a mnemonic device, think of GIFTS:Good Start, Improvement, Focus, Team, Status

http://martinfowler.com/articles/itsNotJustStandingUp.html

● The meeting is about “Yesterday today obstacles”1. Any impediments in your way?2. What are you working on today?3. What have you finished since yesterday?

● It is stand up to keep it short. No more than 15 minutes. Track the time.

● Use the workspace as the place to have the meeting.

● Have a backup with the team board. ● Used to start the planning of the entire day.

Retrospective meetings

● Start the retrospective by looking back to understand what happened and why.

● Spend the second half of the retrospective looking forward and deciding on a plan of action.

● Watch out for retrospective “smells” that are stopping your team’s retrospectives from being effective.

● Find out what problems the team wants to fix most. Use dot voting to focus on what the team has energy to work on.

● Don’t commit to more actions than can be completed before the next retrospective. Even two or three actions completed every iteration can have significant impact over several months.

● If the actions from last retrospective weren’t done, find out why before adding any more.

Retrospective format:

1. Review the goal of meeting, and remind the team of the ground rules (5 minutes).

2. Create a timeline (15 minutes).3. Mine the timeline for insights (15 minutes).4. Select the topics to focus on (10 minutes).5. Review the progress on previous actions (5

minutes).6. Generate ideas for improvements (15 minutes).7. Action planning (15 minutes).

Demo SessionThe team needs to get together with their customer and check the following items:● Has the product been tested adequately?● Are there any showstopper bugs?● Is this a good time for end users to get a new release?● Has the relevant documentation been done (such as release notes)?● Does the team need to nominate a team member to support the release?● Can the release be rolled back if problems are encountered?● Human intervention may be required to release software, but this can be a

source of mistakes. Encourage the team to automate their deployment process as much as they can.

Also:● Have a plan B.● The meeting is not always required.

Iteration & Release Planning Sessions

● These session are needed to groom the backlog and have a clear path to follow during the next days.

● After the retrospective, decided actions need to be considered when planning the next iteration.

Tips to make meetings effective

Choose a time: Establish a meeting time that works for the whole team, and give them plenty of notice about any preparation they need to do.

Set up the space: Consider what kind of space you want for the meeting. Avoid meeting rooms with very large tables because this spreads the team too far apart to see index cards on the table. You’ll also need something to capture notes on, such as a flip chart or whiteboard.

Focus the meeting: Start the meeting by clearly stating the purpose of the meeting and giving a quick overview of the agenda. Remind the team of any working agreements or ground rules for meetings.

Keep it flowing: Stay on your toes during the meeting, and ensure the conversations in the meeting stay on topic and are productive. When you act as a “facilitator,” your aim is to make the meeting easier for the people in it—like oil in an engine. You keep the meeting moving and focused on producing useful output. This is easier to do if you are not taking an active position in the discussion— step back to maintain a neutral position. If you need to offer an opinion, then explicitly step out of the facilitator role.

Encourage everyone to participate: Make sure everyone’s opinion is heard. This means only one person talking at a time. When someone is making broad generalizations, it can help to ask for examples and ask clarifying questions to draw out the details.

Summarize key points: Before you write up any points on the whiteboard, check to see you have really understood the point by repeating what you heard.

Close the meeting: When you bring the meeting to a close, make sure that outputs are recorded appropriately. Taking digital photographs is a quick way to capture whiteboard sketches and meeting notes.To improve next time, ask for feedback on your facilitation of the meeting. You can do this by asking everyone for suggestions at the end of the meeting or by asking someone to observe how you run the meeting and then discussing improvements with them after it finishes.

Questions to guide: Five whys, to resolve problems, Reflective questions, Thinking questions, Ask for help

A proposal for calendarization

Daily Standup

Daily Standup

Daily Standup

Daily Standup

Daily Standup

Daily Standup-DESIGN SPIKE

Daily Standup

Daily Standup

Daily Standup

Daily Standup

Daily Standup

Daily Standup

Daily Standup

Daily Standup

Daily Standup

Daily Standup

Daily Standup

Daily Standup

Daily Standup

Release- Iteration Planning

Retrospective- Iteration Planning

Demo Session

Retro spective

Retro spective

Beginning of project

Retrospective- Iteration Planning

Demo Session

2 week sprints

Sprints are iterations.

Not all iterations are sprints

Roles

Roles

1. Designers2. Developers3. Agile Coach / Scrum Master4. Product Owner.5. * The Client (Project stakeholders in XP)

This will be the TEAM.

* Can be excluded from meetings, the product owner will have the responsibility

(Product Owner)

A team needs to...

● Build trust.● Have its own team space. ● Celebrate success.● Be self motivated.● Be cross-functional.● Beware of incentives.● Communicate constantly.● Be co-located.

Coaching

● The art of Agile coaching is understanding the situation, the values underlying Agile software development, and how the two can combine.

● Your goal is to grow a productive Agile team that thinks for itself rather than relying on you to lay down the Agile law.

● Patience is one of the most important qualities of a coach. Don’t expect instant perfection from the team; change takes time.

Habits to develop as an Agile coach:1. Lead by example.2. Keep your balance.3. Set a realistic pace.4. Mind your language.5. Learn as you go.

-- Show that you are part of the team by talking from a team perspective using “our”/“we”/“us” rather than “I”/“you”/“they.”-- Avoid making sweeping generalizations. Don’t use words like “never,” “always,” “right,” and “wrong,” because doing so can discount the situation at hand. Try hard not to dismiss past practice by saying it was wrong or incorrect; this creates bad feeling, and people may feel they’ve lost face.-- Beware of putting people in boxes by using labels and talking about “the developers” or “management.” Try to use people’s names.

We’re the experts

Nonetheless, the relationship between customers and developers is crucial because they need to work together to create the best product.

Gold cards provide a way for the team to present new product ideas to their customer to make it a product they’re proud of.

Caring about quality

Practices

● Continuous Delivery● Continuous Deployment● Continuous Integration● Continuous Monitoring

Continuous Delivery

● A series of practices designed to ensure that code can be rapidly and safely deployed to production by delivering every change to a production-like environment and ensuring business applications and services function as expected through rigorous automated testing.

● PaaS: Heroku, Digital Ocean, Docker.

Continuous Deployment

● Continuous deployment is the next step of continuous delivery: Every change that passes the automated tests is deployed to production automatically. Continuous deployment should be the goal of most companies that are not constrained by regulatory or other requirements.

● Tools depend on Continuous Integration.

Continuous Delivery vs. Continuous Deployment

http://blog.crisp.se/2013/02/05/yassalsundman/continuous-delivery-vs-continuous-deployment

Continuous Integration

● A toolchain and a discipline.● CVS, Pull Requests. Everyone has a copy of

the repository. ● Continuous code integrations. ● Automation of new deploys, new features,

new acceptance tests. ● Tools: Travis, Jenkins, CircleCI.

Continuous Monitoring

● Uptime & Downtime: https://uptimerobot.com/

● New Relic: http://newrelic.com/● Every trustful provider has its status.*.com

Growing You

Growing you

Learning from others and teaching to others are the best sources of knowledge available.

Work out how you learn best, and set aside time to do it:● Commit to read one technical book per

month.● Start your own blog.● Contribute to an open source project.● Post once a day to a community mailing list.● Listen to a podcast on your way to work.● Spare one evening a month to attend an

interest group.

Additional Information

Methodologies

● Product owner from Scrum is very important. ● Pair programming for code review is coming

from extreme programming. ● Refactor when you can comes from extreme

programming.

Tools

1. Pivotal Tracker2. Basecamp3. Hangouts from Google.4. Skype5. Github/Gitlab6. ...

Books

● Agile Coaching● Lean UX● Lean Startup● Planning Extreme Programming● Don’t Make me think

References

● It is not just standing up: http://martinfowler.com/articles/itsNotJustStandingUp.html

● The agile manifesto: http://agilemanifesto.org/

● Agile for beginners: http://www.agilenutshell.com/

● Prioritizing your product backlog: http://www.infoq.com/presentations/prioritizing-your-product-backlog-mike-cohn

● Tips for prioritizing your backlog: http://productowner.net/2012/01/31/tips-prioritization-product-backlog/

● Artifacts in user stories: http://www.agilemodeling.com/artifacts/userStory.htm

● Essential XP: Card, conversation and confirmation http://xprogramming.com/articles/expcardconversationconfirmation/

● Acceptance criteria references: http://www.boost.co.nz/blog/2010/09/acceptance-criteria/

●

● http://guide.agilealliance.org/guide/gwt.html● http://epf.eclipse.org/wikis/openup/core.

mgmt.common.extend_supp/guidances/guidelines/agile_estimation_A4EF42B3.html

● http://blog.crisp.se/2013/02/05/yassalsundman/continuous-delivery-vs-continuous-deployment

● http://puppetlabs.com/blog/continuous-delivery-vs-continuous-deployment-whats-diff

●

Thanks :]Questions?

CEO - @edolopez edolopez@icalialabs.com