From Idea to Production

-

Efficient Agile Software Development

and

Challenges in Modern Software Engineering

Benjamin Nothdurft

benjamin.nothdurft@codecentric.de

blog.codecentric.de

 Benjamin Nothdurft

  IT Trainer, Speaker & Lecturer

Branch Manager Erfurt & Leipzig

  IT Conference & Meetup Organizer

 Benjamin Nothdurft

facebook.com/dataduke

xing.to/dataduke

linkedin.com/in/dataduke

@dataduke

HQ in Solingen

Benjamin Nothdurft

benjamin.nothdurft@codecentric.de

blog.codecentric.de

From Idea to Production

-

Efficient Agile Software Development

and

Challenges in Modern Software Engineering

Part 1:
Efficient Agile Software Development

Roadmap Planning

Scrum

Scrum Values

Roles

Meetings

Retrospectives

Team Health Monitor

Agile Fluency Model

Scaling Agile

Roadmap Planning

Roadmap

Scrum

The scrum process was founded in 1993 by Jeff Sutherland. He borrowed the term „scrum“ from an analogy from a Harvard study that compared high-performing, cross-functional teams

to the scrum formation used by Rugby

• one of the most popular frameworks for implementing agile
• a simple framework for effective team collaboration
• product is built in a series of fixed-length iterations
• focusses on building software that meets business needs

Official Scrum Guide: http://www.scrumguides.org/index.html

Common communication problems

in software development

Agile Manifesto

Individuals and interactions over Processes and tools

Working software over Comprehensive documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

http://agilemanifesto.org

Scrum Values

https://www.scrum.org/resources/blog/updates-scrum-guide-5-scrum-values-take-center-stage

Sprint

• Scrum projects make progress in a series of “sprints"
• Typical duration is 2 – 4 weeks
• Constant duration leads to a better rhythm
• Product is designed, coded, and tested during the sprint

Roles

 Product Owner

• Defines the features of the product
• Responsible for the profitability of the product (ROI)
• Maintains and prioritises the Product Backlog
• Adjusts features and priority every iteration, as needed
• Accepts or rejects work results

Roles

Scrum Master

• Responsible for enacting Scrum values and practices
• Removes impediments
• Ensures that the team is fully functional and productive
• Enables close co-operation across all roles and functions
• Shields the team from external interferences
• Facilitates meetings

Roles

Developer Team

• Typically 5 – 9 members
• Cross-functional (programmers, UI designers, testers etc.)
• Self-organised
• Decides how features will be implemented

Artifacts

Product Backlog

• A list of all desired work on the project

• Prioritised by the product owner

• Re-prioritised at the start of each sprint

Artifacts

Sprint Backlog

• Set of product backlog items selected for the sprint

• Highly visible, real-time picture of the work that the team plans to accomplish during the sprint

• Team members choose tasks themselves, work is never assigned

• Only team members can add, delete or change the sprint backlog

• Work remaining is updated daily

Scrum Board

Scrum Board

Meetings

Backlog Refinement

• Is held a couple of days before the end of a sprint

• Presentation & estimation of new stories in the sprint backlog

Additional workshops to fill the backlog

• Story Mapping: At kick-off of a complex long-term epic

• Event Storming: May include other business departments         to gather a common sense among all project stakeholders

Meetings

Sprint Planning I + Sprint Planning II

• Sprint planning II is held directly after sprint planning I
• Sprint planning I is used to build the sprint backlog and to commit to the sprint goal
• Sprint planning II is used to break each user story down into manageable tasks

• Participants: Developer Team, ScrumMaster and Product owner, sometimes stakeholders

• Duration: 1,5 - 16 hours

Meetings

Daily Scrum Meeting

• The daily scrum is not a status update for the ScrumMaster or product owner! They are commitments in front of peers.

• Goal: Team synchronises itself, Avoids other unnecessary

  meetings

• Participants: Everyone is invited, only team members, Scrum Master and product owner talk

• Duration: 15 min. max

• Typical Questions: What did I do yesterday? What will I do today? Is anything blocking me?

Meetings

Sprint Review

• Typically takes the form of a demo of new features or underlying architecture

• Working product is shown, avoid presentation slides

• Only finished things are shown

• Goal: Team presents what is accomplished during the sprint

• Participants: Everyone is invited. Developer Team, Scrum Master, Product Owner are mandatory

• Duration: between 15 min - max 1 hour

Meetings

Sprint Retrospective

• Periodically take a look at what is and what is not working

• Define action items (and complete them within the agreed timeframe)

• There are various ways to do sprint retrospectives

• Goal: Improving team performance

• Participants: Developer Team, Scrum Master, Product Owner (not mandatory), Others (if invited)

• Duration: At end of each sprint, 30 min - 90 min

• Also possible: cross-team retrospectives

Meetings

Sprint Retrospective

• Periodically take a look at what is and what is not working

• Define action items (and complete them within the agreed timeframe)

• There are various ways to do sprint retrospectives

• Goal: Improving team performance

• Participants: Developer Team, Scrum Master, Product Owner (not mandatory), Others (if invited)

• Duration: At end of each sprint, 30 min - 90 min

• Also possible: cross-team retrospectives

Retrospectives in Detail

  SET THE STAGE

3 Words

When?

– expectation setting

– gathering general mood/attitude of participants

How?

– prepare flipchart, where team members can put their "3 words"

– ask team members to describe the last sprint with 3 words, write them on a post-it, out them on flipchart

Benefit?

– getting an overview about the team's mood before starting the other phases (and take it in consideration)

  SET THE STAGE

  SET THE STAGE

  GATHER DATA

  GATHER DATA

  GENERATE INSIGHTS

  DECIDE

  CLOSE

  CLOSE

Sprint Burndown Chart

Team Health Monitor

https://www.atlassian.com/team-playbook/health-monitor/project-teams

https://www.meetup.com/Agile-Jena/photos/26939029/#449592451

Scaling Agile

Frameworks:

• LeSS
• SaFe
• DAD
• Nexus

From Idea to Production

-

Efficient Agile Software Development

and

Challenges in Modern Software Engineering

Benjamin Nothdurft

benjamin.nothdurft@codecentric.de

blog.codecentric.de

Part 2:

Challenges in Modern Software Engineering

Communities of Practice

Extreme Programming (XP)

Conway's Law

Microservices

Docker

Continuous Integration/Continuous Delivery

Software Craftsmanship

Hackathons

Domain-Driven Design (DDD)

Community of Practice

Extreme Programming Techniques

Conway's Law

"Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.”

– Melvin E. Conway

https://www.thoughtworks.com/insights/blog/demystifying-conways-law

Microservices

https://martinfowler.com/articles/microservices.html

Docker

https://de.slideshare.net/Docker/docker-birthday-3-intro-to-docker-slides

https://docs.docker.com/get-started

https://docs.docker.com/engine/reference/commandline/docker

http://manifesto.softwarecraftsmanship.org

Katas

What makes a good practice session? You need time without interruptions, and a simple thing you want to try. You need to try it as many times as it takes, and be comfortable making mistakes. You need to look for feedback each time so you can work to improve. There needs to be no pressure: this is why it is hard to practice in a project environment. it helps to keep it fun: make small steps forward when you can. Finally, you’ll recognize a good practice session because you’ll came out of it knowing more than when you went in.

Code Kata is an attempt to bring this element of practice to software development. A kata is an exercise in karate where you repeat a form many, many times, making little improvements in each. The intent behind code kata is similar. Each is a short exercise (perhaps 30 minutes to an hour long). Some involve programming, and can be coded in many different ways. Some are open ended, and involve thinking about the issues behind programming. These are unlikely to have a single correct answer. 

Remember that the point of the kata is not arriving at a correct answer. The point is the stuff you learn along the way. The goal is the practice, not the solution.

http://codekata.com

Hackathons

Domain-Driven Design