You are on page 1of 35

Agile Planet

A Travelguide to the Agile Universe

Fabian Schiller

This book is for sale at http://leanpub.com/agileplanet

This version was published on 2014-01-13

Agile Planet A Travelguide to the Agile Universe Fabian Schiller This book is for sale athttp://leanpub.com/agileplanet This version was published on 2014-01-13 This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do. ©2014 Fabian Schiller " id="pdf-obj-1-13" src="pdf-obj-1-13.jpg">

This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do.

©2014 Fabian Schiller

Contents

Before Traveling .

. Why should I read this book?

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

1

1

The concept of the book

.

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

1

I am missing a topic .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

2

Thanks!

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

2

Agile Sights

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

4

Agile Manifesto

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

5

eXtreme Programming

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

7

Scrum

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

9

Kanban .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

11

Lean

. Lean Startup .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

13

15

Impact Mapping

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

17

Story Mapping .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

19

Real Options

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

21

Test Driven Development

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

23

Open Space

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

25

Lean Coffee

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

27

Tours for Roles . Tour for Developers

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

29

29

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

29

. Tour for Product Owners

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

30

Tour for Managers .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

30

Timed Tours

. A Ten Minute Tour

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

31

31

A One Hour Tour

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

31

Bibliography

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

32

Before Traveling

Why should I read this book?

You are Developer, Product Owner, ScrumMaster, Manager or whatever and somehow

involved with Agile. Agile consultants and coaches are bombing you with buzz words you may never have heard of before. This book is designed for you! Grasp these words, have a look into this book and fastly know what this guy is talking about, essentially. You will additionally be provided with valuable references allowing you to dive into the topic as deep as you need elsewhere.

You are Agile Coach or consultant and using all those words all the time? Even for you this book may be a valuable resource for two reasons: You can refresh your knowledge on a topic by shortly looking at the visuals and recap the core concepts. Or you can take this book and its visuals to your customer and explain the concept to them using the short introductions here.

There are many more resources to get an overview and explanation of Agile topics, including

Agile Atlas¹ by Ron Jeffries • Guide to Agile Practices² by Laurent Bossavit • The AgileBOK³ Wall-Skillsby Corinna Baldauf

which might be helpful for you. Have a look over there if a topic is not yet included in this book, or you like an alternative view and often much more detailed explanation.

The concept of the book

The idea of this book is - as the title says - to be a travelguide to various Agile topics. There are four important concepts, this book is built around:

• Incremental: This book is designed to be a leanly published book. Most sections are independent and therefore the book can be published in short iterations by adding more and more topics.

Before Traveling

2

• Spaceboxed: This book is not an exhaustive guide to the various topics mentioned. It is meant to become a book providing a leightweight and entertaining but still serious overview about the countless Agile topics. Every topic should be presented shortly and with its most important principles. I use the concept of spaceboxing (in immitation of timeboxing) to support this constraint. There are three basic space boxes used: a 140 character box for an extremely short summary, a 200 word box for a quick overview of history and core concepts and a one page box for the visual. This means that every topic is limited to two pages. • Subjective routes: If you are traveling you are likely to have certain interests, which determine your route and lead you to different routes as other people. The same is true for travelling on the Agile Planet. This book will provide different tours for different people. There is a section, which helps people in certain roles to find nice routes over the planet and another section with timed tours. • Open for contributions: This book is meant to be open for contributions. Should you miss a topic or have the urgent feeling, that you could write a much better description of a certain topic in the given spacebox, you are invited to do so. Just drop me an e-mail:

fabian.schiller@agileplanet.de

The format of this book is consciously chosen to be A4, so that you can easily print either the whole book or single sections as reminder or handout.

I am missing a topic

You are missing a topic desparately? No problem! As mentioned, this book is designed to be written and drawn incrementally. Staring out with a smaller set of topics and growing over time.

So if you like a topic to be included proceed as follows:

  • 1. Check the Trello boardof the book to see if your topic is already there.

  • 2. If your topic is not there, just drop me an e-mail and I will include it.

  • 3. If it is already there, you can still send me an e-mail expressing your wishes to help me find a good prioritization.

  • 4. Motivate and push me to act and finish that topic or -

  • 5. offer to contribute yourself!

Send e-mails suggesting topics and offers to contribute to: fabian.schiller@agileplanet.de.

Thanks!

A book is (almost) never written by a single person. As for this book, I hope it will be written by many persons in the future. But even now I had the help of many people to get as far as I am.

First and foremost kudos go to Jurgen Appelofor encouraging me to draw, Toni Tassanifor an

Before Traveling

3

inspiring talk about comics and Ángel Medinilla⁸ for teaching me some drawing basics. All of that happened at the awesome ALE 2013 Conference. Without their help, I would never have started to write and draw this book.

But there are more people that helped me with useful discussions and ideas to take a step forward. A former colleague, Thomas Gäberlein coached me finding the title and some concepts of this book. Corinna Baldauf’s¹⁰ Wall-Skills¹¹ helped me to stick with the idea of spaceboxing and Yves Hanoulle¹² pushed me hardly to publish early.

Last but not least, I have to thank my wonderful wife Heike and my two little children Nieke and Jonathan for being very patient with me while writing and drawing for this book!

Agile Sights

Over the last decades, Agile has become a wide variety of topics. In this chapter you will find one topic after another. All nicely aligned on two pages. You can either poke around here for a while and see which treasures you will find. Or you can take one of the guided tours, which you will find in chapters Tours for Roles or Timed Tours.

Agile Sights

5

Agile Manifesto

In 140 Characters

The Agile Manifesto sums up the core principles of many agile methodologies and is the fundament of the Agile software development movement.

In 200 Words

The Manifesto for Agile Software Development - published in February 2001 - is probably the most fundamental document of the Agile software developement movement. Its values and principles inspired and united many people in software development, sharing a vision of a highly collaborative way of developing software.

Over the course of several years it infected not only more and more companies in the software development business. Companies in the hardware or creative business are increasingly embracing the Agile values, too.

The core values of the Agile Manifesto are:

• Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan

As the manifesto states it is important to notice, that items on the right have value but items on the left are more valuable.

The Agile Manifesto is backed by twelve principles for Agile software development, which despite their importance, are often not mentioned alongside the core values.

Unlimited Knowledge

Agile Sights

6

Agile Sights 6

Agile Sights

7

eXtreme Programming

In 140 Characters

Deliver the highest value for your business iteratively by listening carefully and coding professionally. Embrace change!

In 200 Words

eXtreme Programming (XP) is a software development process, which was dicussed highly controversial when it was published in the late 1990s. This was caused by the simplicity of the process, which is based on the believe that fast and reliable communication between developers and business is more valuable than a sophisticated software development process. Advocates of more complex processes like e.g. the Rational Unified Process (RUP) often felt offended and accused XP of oversimplification.

It is probably only fair to say that XP, propagated and developed by famous software engineers like Kent Beck, Ward Cunningham, Ron Jeffries and many more, was the first widely recognized Agile software development methodology and layed down the fundaments for others to come.

XP is a highly iterative approach to software development. At the heart of this process are developers and business people, playing a “Planning Game” in short iterations to deliver valuable software earliest possible. XP prescribes several software development methods like pair programming, test driven development but also an eight hour work day. It is designed to cope with changing business requirements very effectively.

Unlimited Knowledge

“eXtreme Programming Explained: Embrace Change” by Kent Beck and Cynthia Andres

(Beck04)

Agile Sights

8

Agile Sights 8

Agile Sights

9

Scrum

In 140 Characters

Scrum is an agile, team based framework for incremental software development. Focus, Respect, Openness, Courage and Commitment are key.

In 200 Words

At this time, Scrum is probably the worlds most famous Agile framework. It was developed in the early 1990s and published by Ken Schwaber and Jeff Sutherland in 1995. On the first gaze it has a lot of similarities with eXtreme Programming but it is much less focused on actual development practices and more on project management topics.

Scrum is a team focused process framework, that defines three roles:

• The Development Team consists of all people, needed to manufacture and deliver the product specified by the Product Owner. • The Product Owner is responsible for maximizing the business value delivered by the team. He prioritizes the Product Backlog (i.e. the list of requirements). • The ScrumMaster is responsible for teaching the Scrum process and coaching the team to inspect and become more productive over time.

Four meetings are conducted every Iteration (called Sprint) that lasts from one to four weeks:

• In the Sprint Planning meeting Product Owner and team select the work for the next Sprint. • During the Sprint the Team keeps track of its work with a Daily Standup meeting. • When the Sprint is finnished, the result is presented to stakeholders in a Sprint Review. • Before starting a new Sprint, the team reflects on opportunities for improvement in a Retrospective.

Unlimited Knowledge

The official Scrum Guide¹⁷ “Agile Project Management with Scrum” by Ken Schwaber (Schwab04) The Agile Atlas on Scrum¹⁸ Jeff Sutherland’s blog¹⁹

Agile Sights

10

Agile Sights 10

Agile Sights

11

Kanban

In 140 Characters

Limit work in progress. Focus on managing flow. Improve everything on your system relentlessly and incrementally. Manage change with Kanban.

In 200 Words

Kanban in software development is a technique adapted from the factory floors of Toyota. It is one of the more prominent components of the Toyota Production System (TPS) and was invented in the 1940s. Supporting the development of a continuous improvement culture (Kaizen), it is a change management tool that generates more and more interest in the industry of information technology.

The biggest shift for IT people with Kanban is to physically visualize the work to be done. This is one of the core concepts and enables you to focus on controlling work in progress (WIP) and diverse queues in your system that would otherwise be invisible.

By controlling and adapting queue sizes and WIP and focussing on quality and lead time (the time a piece of work needs to flow through your whole production system) you will be able to deliver faster and with higher predictability.

The great advantage of Kanban as change management tool is, that you start where you are and respect the current system including process, roles and titles in the first place. This generates a lot less friction than other, more disruptive change methods.

Unlimited Knowledge

“Kanban: Successful Evolutionary Change for your Technology Business” by David J. Anderson (Ander10) Arne Roock’s blog on Kanban topics²⁰ Wikipedia on Kanban²¹

Agile Sights

12

Agile Sights 12

Agile Sights

13

Lean

In 140 Characters

Optimize your value streams by pulling quality work quickly. Respect people and focus on the whole. Waste not!

In 200 Words

Lean methods are a growing topic in information technology. They are derived from lean manufacturing which has its roots in the early 20th century. Lean manufacturing methods are well known and widely spread on the factory floors all over the world. Their fame comes greatly from the fact that they are an integral part of the hugely successful Toyota Production System (TPS). According to Toyota the core of lean is not the tools but essentially the culture, which focuses on avoiding three kinds of waste:

• Muri: Overloading the system will lead to stagnation. • Mura: Work that is not adding value to the product wastes time. • Muda: High variability in the work will decrease flow.

The main principles in IT applying lean methods are the focus on value streams, flow and reducing non-visible inventory (e.g. requirements that are never implemented). This focus is typically enforced by implementing a pull system and optimizing all stations of the software production process for on-demand delivery. The consequence should be a dramatic drop of work in progress and queued work, which again leads to much more efficient delivery and short lead times.

Unlimited Knowledge

“Implementing Lean Software Development” by Mary and Tom Poppendieck (Pop06) “Leading Lean Software Development” by Mary and Tom Poppendieck (Pop09) Presentation on Lean Software Development Principles by John P. Vajda²² Lean on Wikipedia²³

Agile Sights

14

Agile Sights 14

Agile Sights

15

Lean Startup

In 140 Characters

Startup business is not voodoo. Know your hypothesis. Build minimum viable products fast. Get valid feedback. Measure. Adapt or Pivot.

In 200 Words

Lean Startup is a framework for entrepreneurs to grow their business. It is a structured approach for validating your product idea immediatley at the market place. Central to the Lean Startup approach is the minimum viable product (MVP), which is the minimal effort needed to validate a hypothesis about the market of your product.

The Lean Startup process framework works as follows:

• Leap: Make hypotheses about the impact of the product to be developed explicit. Develop the smalles possible thing that could either verify or falsify your assumptions. • Test: Define measures to validate your hypothesis. Bring the MVP to the market as soon as possible. • Measure: Collect numbers and observe how the market reacts on your MVP. If your hypothesis is valid do the next step and leap again. Otherwise pivot. • Pivot: Should your hypothesis have fatal flaws and there seems to be no market for your product, change your strategy. Use the data you collected to form fundamentally new hypotheses and leap again.

Unlimited Knowledge

The Lean Startup Website²⁴ “The Lean Startup” by Eric Ries (Ries11)

Agile Sights

16

Agile Sights 16

Agile Sights

17

Impact Mapping

In 140 Characters

This technique will help you to focus on the relevant stuff and build your strategy visually and collaboratively to achieve your goal.

In 200 Words

Impact Mapping is a strategical planning technique developed by Gojko Adzic. It was published in 2012 and generated a lot of interest since then.

Impact Mapping uses mind maps to build strategies collaboratively and visualize them. Impact maps have four hierarchically arragned levels.

• Why: At the heart of an impact map stands the purpose of your undertaking. Why do you think, your vision will generate value of any kind to somebody? • Who: The second level states who should value your project. All stakeholders are listed here. The question is: “Who will behave differently, if we have done what we are planning to do?” • How: The question at the third level is “How will the behaviour of the stakeholders change?”. Identify how stakeholders can support or disprove your undertaking. • What: On the last level of the impact map stands what your concrete deliverable will be to help evoce the change in behaviour of your stakeholders.

Impact Mapping also encourages you, to work in short iterations. In this hindsight it suggests to define clear measures for your goals, find alternatives using impact maps and evaluate the success rigorous at the market, early.

Unlimited Knowledge

“Impact Mapping” by Gojko Adzic (Adzic12) The Impact Mapping website²⁵

Agile Sights

18

Agile Sights 18

Agile Sights

19

Story Mapping

In 140 Characters

Story Mapping enhances your stakeholder communication by focusing on the whole story of your product and creating a nice visual structure.

In 200 Words

Story Mapping is a concept largely attributed to Jeff Patton. The concept was first published in his article “It’s All in How You Slice It” in 2005.

Story maps address an old issue with classical product backlogs. Since they are meant to be ordered unambigously, they are mostly administrated as flat lists of user stories or requirements. This makes it difficult to see the whole context and the story of a product fastly and intuitively. Story maps help out here.

Story maps essentially consist of two types of tickets.

Activities represent the high level actions, users can take in your system. Activities should be written and ordered on your story map in a way, that you can tell the coarse story of your system by walking throught them from left to right. • Tasks further specify activities. They are arranged under the respective activity in order of priority and should have about the size of classical user stories.

Story Mapping does not only help you to communicate easier with your stakeholders, it is also a very helpful tool to plan small incremental releases by finding the most important tasks for every activity and bundeling them.

Unlimited Knowledge

Agile Sights

20

Agile Sights 20

Agile Sights

21

Real Options

In 140 Characters

Open up viable options at any time. Choosing no option may be an option, too. Do not commit or close an option unless you know why!

In 200 Words

Real Options is a topic propagated prominently by Olav Maassen and Chris Matts since 2007.

Although the concept of Real Options stems from the concept of Real Options Analysis in the financial sector, it should not be related directly. While the financial concept provides an allegedly optimal decision process for trading, the only deductions drawn for Real Options are:

  • 1. Options have value

  • 2. Options expire

  • 3. Never commit early unless you know why

Real Options emphasizes, that there are often not only two decissions that can be made (namely “yes” and “no”) but also a third one: to not decide now. This of course means admiting and actively embracing uncertainty, which is more easily formulated than done. Therefore actively using Real Options requires a lot of practice and learning.

Real Options as formulated above are at the heart of many Agile tools, techniques and values. You’ll find them in lean software development, Scrum, Kanban and many more. But again this is no wonder, since agile methods stem from the need of rapid change and embrace uncertainty.

Unlimited Knowledge

“Commitment” by Olaf Maasen, Christ Matts and Chris Geary (Maas13) “Real Options” Underlie Agile Practices²⁸

Agile Sights

22

Agile Sights 22

Agile Sights

23

Test Driven Development

In 140 Characters

Writing tests before coding helps you to build maintainable, modular and flexible systems productively. Rapid feedback is key to success!

In 200 Words

Test Driven Development (TDD), which is highly related to unit testing and test automation traces back to the early 1990s. At this time, early frameworks for automated unit testing were developed. A huge step forward was taken when Kent Beck created a unit testing framework in 1994 and consequently introduced the test driven approach to eXtreme Programming.

The steps of TDD are as simple as effective:

  • 1. Add test: Before adding new functionality to your system, you implement a test specifying the desired behaviour.

  • 2. Let test fail: Before writing the code, you should assure that the test fails to be sure you are really testing new functionality.

  • 3. Write code: Implement the functionality specified in your requirement.

  • 4. Run test: After implementation re-run the test to see if it succeeds now. If it does go on to refactoring otherwise return to writing to make the test pass.

  • 5. Refactor: When the functionality is added the last thing you should do is to take care that you leave the code clean. Always leave the code in equal or better condition than when you first entered it.

TDD is nowadays considered to be an integral part of truly professional software development.

Unlimited Knowledge

“Test Driven Development by Example” by Kent Beck (Beck02) “The Pragmatics of TDD” a blog post by Robert C. Martin²⁹ Wikipedia on Test Driven Development³⁰

Agile Sights

24

Agile Sights 24

Agile Sights

25

Open Space

In 140 Characters

A highly collaborative way to create room for people to design their own conference: “Whatever happens is the only thing that could have”.

In 200 Words

Open Space Technology traces back to the early 1980s when Harrison Owen organized his fourth conference on organizational transformation in a similar manner. During his first three conferences on the topic he observed, that participants gave the feedback that the coffee breaks were the most valuable part of the event. The essential idea is to have no formal agenda and let participants build their own during the event.

The format was picked up by the Agile community soon, since it aligns with the values of self- organization, which is a central part of Agile approaches.

The execution of Open Spaces is simply explained

  • 1. Facilitate a open invitation do articulate the purpose of the event

  • 2. Have participants arrange chairs in a big circle

  • 3. Provide an issue board

  • 4. Provide a market place - a board with available rooms and timeslots

  • 5. Let the people create their event

One should not underestimate the role of facilitation of such events. Setting the right tone and constraints is crucial for this format to become valuable.

Examples for conferences based on Open Space Technology in the Agile community include Agile Coach Camps, the annual ALE conference, Play4Agile, Scrum Gatherings and many more.

Unlimited Knowledge

Agile Sights

26

Agile Sights 26

Agile Sights

27

Lean Coffee

In 140 Characters

In need to meet - but no agenda? Try Lean Coffee to facilitate agenda-less meetings in a still structured and effective way.

In 200 Words

Lean Coffee is a technique developed by Jim Benson and Jeremy Lightsmith in 2009. They intended to provide room for participants to discuss several Lean techniques without having the burden of a classical conference organization.

Similar to Open Space, Lean Coffee is designed to open up a room for people to exchange on topics not known in advance. Lean Coffee supports this with a structure that helps people to stay on track and keep an effective discussion.

A Lean Coffee is easy to set up:

  • 1. Set up a Kanban board with columns “To Discuss”, “In Discussion” and “Discussed”

  • 2. Every participant writes down his topic suggestions on post-its

  • 3. Everybody presents his topic to the whole group in a few seconds and posts it to the “To Discuss” column of a Kanban board

  • 4. Topics are dot-voted and prioritized by all participants

  • 5. Every topic is discussed for a certain timebox (typically 10-15 minutes)

  • 6. The progress of the discussion is visualized on the Kanban board.

The technique is very well fitted for small conferences or workshops on a certain topic. But you can also use it nicely for facilitating meetings of Communities of Practice or other regular exchanges.

Unlimited Knowledge

Agile Sights

28

Agile Sights 28

Tours for Roles

On your journey to the Agile Planet you can - of course - take arbitrary routes. But for those not very experienced with many of the topics addressed here, I want to offer some tours over the planet. Since everybody has different interests according to the role he currently holds, I will propose different tours for different roles.

Tour for Developers

Welcome to the Agile Planet! As soon as you have discovered the manyfold beauties of this place, you will eventually never want to leave again. But let’s start small, firstly. So you are a developer?

It were passionate software developers who crafted the Agile Manifesto in 2001. You might be interested in having at least a short look at the visuals over there, since they beautifully introduce you to the core concepts of Agile.

On the Agile Planet we are keenly interested in high quality work. Thus, your next trip takes you to the city of Test Driven Development. You should stay here for a while and dig a little deeper to find the various treasures burried.

Test Driven Development is an integral part of eXtreme Programming, which was one of the major breakthroughs of the Agile software development movement. If you have a close look at this topic you will probably realize a tight connection to the Scrum framework, which might give you a different perspective on project management.

Finally, have a short stroll through Real Options which may be a great thing to have in mind, if you are thinking about architectural decissions. In facilitating such an architectural discussion with your team Lean Coffee might help you to keep productive.

Tour for ScrumMasters

Welcome dear ScrumMaster! Since you are obviously in this role, we assume that Agile is not completely new to you. Never the less your agile journey should start with the Agile Manifesto. Be sure, that you stay long enough to know not only the four central sentences, but also the twelve principles of Agile software development, since they are often neglected.

As soon as you recovered from this philosophical trip, you should take a close look at the Scrum framework and spend some time there. You should probably go even further than the references given here and actively participate in the Agile community and visit conferences to stay up-to- date. It is your job to be the expert in this topic!

Digging deep enough into these will probably automatically bring you to most of the other topics. The most severe issue for you might be facilitation now. Therefore Lean Coffee and Open Space might help out with valuable ideas.

Tours for Roles

30

You should now be equipped with the most urgent tools needed for a ScrumMaster. For the remainder of the topics, there is no particular order I would suggest. The best would be you take up your travel guide every evening and stroll through one chapter until you covered everything you want to know. Afterwards start at the beginning :-)

Tour for Product Owners

Hello my beloved Product Owners! Even if you are very much on the business side of the game, I would strongly recommend you to have a look at the Agile Manifesto to understand the core values of Agile. Only then will you understand, why your ScrumMaster is talking so strangely from time to time.

The most important topics for you will be those, which are related to decision making. This is your role! Making decisions to maximize the business value for your organization. Therefore, Real Options may be a good place for you to start.

Once you understand the value of delaying decisions to the latest responsible moment, Agile planning techniques will be of interest for you. You can start with Impact Mapping here, which might help you to visualize your business goals and to focus on the really important stuff first.

To validate your ideas fastly at the market, the ideas and concepts of Lean Startup will be of great value to you. Especially the idea to build minimum viable products and the way of thinking behind this framework will inspire you to learn more.

If you know what experiments to start first, Story Mapping will give you the necessary tools to build a nicely structured backlog for your team, plan your first releases and communicate effectively with your stakeholders.

Tour for Managers

Dear manager! Welcome to Planet Agile. Even if you are not so much interested in projects but more in your organization you should have a look into the Agile Manifesto to understand what those Agile guys and girls are having in mind.

You will surely be interested in whatever Agile framework your boys and girls are working with currently or in the future. Be it eXtreme Programming, Scrum or Kanban, you should know what they are doing, essentially.

After you understand that, a place where you - as a decision maker - might be willing to dig a little deeper is Real Options where you might discover that taking desicions fastly is not always the best way to cope with things.

Timed Tours

A Ten Minute Tour

Hey! Only ten minutes? Let’s go:

• Have a look at the visual of the Agile Manifesto. • Drop by at Lean Software Development and read through the principles shortly. • Read the description of the process, you are currently interested in: Scrum, Kanban or eXtreme Programming.

See you tomorrow for a longer tour?

A One Hour Tour

If you do have one hour to discover the Agile Planet, I would suggest you to try getting an overview over several topics. You can do this easily by strolling through the whole chapter Agile Sights and reading the 140 character box on every page and have a closer look to the visuals.

After you took the whole roundtrip dig deeper into three to four topics that grasped your attention the most by reading the 200 word boxes. One hour ist not very much time to discover the Agile Planet. So think about returning at an occasion with more time and learn about the magic of this place.

Bibliography

[Adzic12] Gojko Adzic; 2010; “Impact Mapping: Making a Big Impact with Software Products and Projects”; Neuri Limited

[Ander10] David J. Anderson; 2010; “Kanban: Successful Evolutionary Change for Your Technol- ogy Business”; Blue Hole Press

[Beck04] Kent Beck, Cynthia Andres; 2004; “eXtreme Programming Explained - Embrace Change”; Second Edition; Addison-Wesley Longman, Amsterdam

[Beck02] Kent Beck; 2002; “Test Driven Development. By Example”; Second Edition; Addison- Wesley Longman, Amsterdam

[Maas13] Olav Maassen, Chris Matts; 2013; “Commitment: Novel about Managing Project Risk”; Hathaway Te Brake Publications

[Pop06] Mary Poppendieck, Tom Poppendieck; 2010; “Implementing Lean Software Develop- ment: From Concept to Cash”; Addison-Wesley Longman, Amsterdam

[Pop09] Mary Poppendieck, Tom Poppendieck; 2010; “Leading Lean Software Development:

Results are Not the Point”; Addison-Wesley Longman, Amsterdam

[Ries11] Eric Ries; 2011; “The Lean Startup: How Constant Innovation Creates Radically Successful Businesses”; Portfolio Penguin

[Schwab04] Ken Schwaber; 2004; “Agile Project Management with Scrum”; Microsoft Press