From Idea to Production
-
Efficient Agile Software Development
and
Challenges in Modern Software Engineering
Benjamin Nothdurft
IT Trainer, Speaker & Lecturer
Branch Manager Erfurt & Leipzig
IT Conference & Meetup Organizer
Benjamin Nothdurft
HQ in Solingen
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
Scrum Values
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
Weather Report / Thermometer / ...
When?
– expectation setting
– gathering general mood/attitude of participants
How?
– prepare flipchart/whiteboard and explain it
– team members put a sticky note on the corresponding field
Benefit?
– getting an overview about the team's mood before starting the other phases (and take it in consideration)
– maybe also getting already some topics for later discussions
SET THE STAGE
Draw the Sprint
When?
– gathering general mood/attitude of participants AND some first impressions on what went well/what not
How?
– Ask team members the following questions (preferably displayed on flipchart/whiteboard): How did you feel during the last sprint? Where there any "Aha"-moments? Which ones? What was the biggest problem? Were you missing something?
– Team members get a sheet of papers and pens → draw!
– Presentation and discussion with whole team
Benefit?
– Refllection about what was happening during the sprint
– Get in the mood for e.g. start-stop-continue afterwards
GATHER DATA
GATHER DATA
GENERATE INSIGHTS
DECIDE
- Active Learning Cycle
- List of specific Action Items
- Kaizen Items
- Growth Method / Mindset
CLOSE
CLOSE
Sprint Burndown Chart
Team Health Monitor
Scaling Agile
Recommended Literature
- Scrum Guide by Ken Schwaber and Jeff Sutherland: http://www.scrumguides.org/scrum-guide.html
- Scrum - verstehen und erfolgreich einsetzen by Stefan Roock and Henning Wolf
- The Nature of Software Development by Ron Jeffries
- Essential Scrum: A Practical Guide to the Most Popular Agile Process by Kenneth Rubin
- User Stories Applied: For Agile Software Development by Mike Cohn
- Agile Retrospectives by Esther Derby & Diana Larsen
- Coaching Agile Teams by Lyssa Adkins
- Innovation Games by Luke Hohmann
- Game Storming by Dave Gray, Suuni Brown and James Macanufo
- Lean Enterprise: How High Performance Organizations Innovate at Scale by Jez Humble, Joanne Molesky & Barry O'Reilly
- The Lean Startup by Eric Ries
- More books: http://www.agilenutshell.com/agile_books
From Idea to Production
-
Efficient Agile Software Development
and
Challenges in Modern Software Engineering
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
Microservices
Docker
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.
Hackathons
Domain-Driven Design
Recommended Literature
- Extreme Programming Explained: Embrace Change by Kent Beck
- Building Microservices by Sam Newman
- Release It!: Design and Deploy Production-Ready Software by Michael Nygard
- Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation by Jez Humble
- Using Docker: Developing and Deploying Software with Containers by Adrian Mouat
- The Software Craftsman: Professionalism, Pragmatism, Pride by Sandro Mancuso
- Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans
- The Coding Dojo Handbook by Emily Bache
- Domain-Driven Design kompakt by Vaughn Vernon, Carola Lilienthal