It's just an ordinary day at work for Lisa, the project leader. Already, at the parking place outside the office she meets Ted, the marketing manager. In his normal irritating way, he asks for the project status. Lisa answers with the normal "Fine" and doesn't give any more details. After three years of working with Ted, she knows that this is just his way to start a normal conversation, the request for changed requirements. That's exactly what happens today as well, as usual.
"We met some customers yesterday and they were very clear that some changes were absolutely needed", he started.
Lisa knows there was no point in arguing.
"OK", she said, "what kind of changes are we talking about?"
"Nothing big, just some adjustments. I will pass you later today. See you later, got to run."
Before he left her he fired away the phrase she hated:
"You know, we need to be Agile."
She hated that word, "agile". She didn't know what it meant. It was just used by everybody to excuse their bad behaviour.
Lisa felt that the energy from a good night's sleep was running out of her. A good night's sleep was maybe not the right description. She was no longer able to leave her work behind at the office. Instead it followed her home, spinning around in her head and didn't give her enough peace for a good night's sleep.
She knows this was just the beginning and she was right. Even before she reached her desk, the department manager Alice grabbed her.
"Don't forget to send me the report about the delays in the project. I need it by 2:00 p.m."
Lisa felt how her stress level was increasing. When they are delayed she has to spend her time on writing reports to managers about the delay, instead of spending her time with the developers and helping them speed up.
She went to the kitchen to get a cup of coffee. She had to calm down before entering the project area. She didn't want the developers to see how stressed she felt. She totally failed. And there was no help from the developers. The more stressed she felt the more silent and vague they were. No one was able to say when they thought they would be done. They were only complaining about unclear specifications, short deadlines, and scope creep. And she didn't even dare to mention that Ted would, during the day, introduce new changes.
The frustration increased inside of her. She felt torn between managers, business people, and developers.
Is it time for Lisa to give up and quit? No it isn't! It's just time for a process that can handle changes and at the same time is transparent especially when it comes to status and consequences of a late change.
Kanban is a method that can help Lisa create a process that will improve her working day. If you recognize Lisa's situation, this book, Kanban in 30 Days will guide you to a better situation. It will take you through the basics of Kanban, Agile, and Lean. It will also help you reach the advanced levels, not only on a theoretical level but also on a practical level. The format of the book is a 30-day calendar that day by day gives you tools for setting up a Kanban organization that is continuously optimizing your way of working. The book will be handy even if you prefer to implement Kanban principles and practices in a different way or in another timeframe as well.
There are also a lot of tips that will be helpful for the more advanced Kanban users, such as tips about where waste can be found and eliminated and also how to better understand your context and how to improve it.
Note
Make a note
Throughout the book, you will find that we have used different words to mean the same thing. They are as follows:
A team, development unit, and people involved in a system refers to the people who are working together or separately on features to improve the same product
A task, story, user story, feature, item, issue, work, or work task refers to the work the team is doing
Chapter 1, Days 1-2 – Understanding Kanban, Lean, and Agile, covers the principles and values for Kanban, Agile, and Lean.
Chapter 2, Days 3-5 – Getting to Know Your System, covers value stream mapping as a tool to better understand your system.
Chapter 3, Days 8-9 – Visualizing Your Process and Creating Your Initial Kanban Board, informs you how to visualize your process and create your initial Kanban board, and covers some tools to help you create your Kanban board.
Chapter 4, Days 10-11 – Setting the Limits, sets the limits and covers a game to play to get an understanding of how limits improve time to market.
Chapter 5, Day 12 – Choosing the Roles and Meetings You Need, covers examples of roles and meetings that are commonly used in organizations doing Kanban.
Chapter 6, Day 15 – First Day Running Kanban, covers an example of how the agenda for the first day could look, including planning and retrospective.
Chapter 7, Days 16-29 – Improving Your Process, covers the PDCA cycle, methods to find waste, and ways to improve your efficiency.
Chapter 8, Day 30 – Release Planning, covers how to get control over your Agile projects, how to follow up projects, and find delivery dates.
This book is for those of you who want to get started with Kanban. It's practical and many parts are simplified to easily get you started. It's also for those of you who have been practicing Kanban for some time and want to get help to switch to a higher gear.
In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply send an e-mail to <[email protected]>, and mention the book title via the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.impacktpub.com/authors.
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.impacktpub.com/support, selecting your book, clicking on the Errata submission form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded on our website, or added to any list of existing errata, under the Errata section of that title. Any existing errata can be viewed by selecting your title from http://www.impacktpub.com/support.
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors, and our ability to bring you valuable content.
You can contact us at <[email protected]> if you are having a problem with any aspect of the book, and we will do our best to address it.