De Scrum uitbreidingsset voor Agile Zelfevaluaties is een set agile coaching kaarten speciaal voor teams en organisaties die Scrum gebruiken. Met deze coaching kaarten kunnen ze ontdekken hoe agile ze zijn en wat ze kunnen doen om hun agility te vergroten om meer waarde te leveren aan hun klanten en stakeholders.
De Scrum uitbreidingsset bevat 39 coaching kaarten met teksten waarin de Scrum principes en praktijken worden behandeld. De Scrum kaarten zijn gebaseerd op de officiële Scrum Gids 2017. De set is ontwikkeld door Ben Linders.
Deze kaarten worden door teams en organisaties om hun Scrum cultuur en practices zelf te beoordelen en te verbeteren. Agile coaches gebruiken ze in agile transformaties om teams te begeleiden en hen te helpen om meer van agile te leren en agile toe te passen.
Bestel de Agile Zelfevaluatie Kaarten en de Scrum Uitbreidingsset in mijn webshop.
De Agile Zelfevaluatie Kaarten kunnen door teams en organisaties worden gebruikt om zelf hun agility te beoordelen. Het basisspel bestaat uit 52 kaarten met uitspraken over het toepassen van agile practices en principes. Deze uitbreidingsset bevat 39 kaarten. Enkel beschikbaar als PDF download.
I’m a partner of Instant Agenda, a tool that supports meetings of agile teams, including Agile Retrospectives.
Instant Agenda is “meeting software that helps anyone run more productive meetings”. One type of the meetings supported by this tool are agile retrospectives:
Instant Agenda is more than an agile retrospective board. It helps you craft and facilitate a productive, focused retrospective that takes you from ideation to insight to action. Each team room can be used on a recurring basis – with a different approach each time.
In this guest blog post, Ravindra Savaram explores the characteristics and habits of successful agile teams and shares tips and ideas on building teams.
In this digital transformation era, every company is striving hard to produce teams that yield predictable outcomes and provide software that satisfies the timelines and demands of the user. Today, following agile practices and methodologies has become the norm for such teams to meet the requirements of businesses. Agile is an iterative approach to software development and project management that enables teams to provide value to their customers faster and with fewer headaches.
You cannot rate your team as successful just by following the agile methodology. They have to overcome various challenges in order to transform into highly productive teams. While coaching enables teams to get on the right path, it is the responsibility of the team to embrace agile principles and sustain the effectiveness in their outcome and efficiency in the activities.
Agile software development isn’t just a series of procedures or principles but a mindset that every member of the team must cultivate in their own way. Having a great agile team in place is integral for any project’s success. This article outlines few characteristics that go beyond the agile basics to facilitate and promotes the habits which lead to high performance in the agile software development teams.
In a successful agile team, the team members work together on features. In a non-agile team, it’s common for people to take requirements or features and work alone on them, but, on a well-running agile team, that’s uncommon. In a successful agile team, a tester or two and several developers work together to ensure they, as a team, have finished a story. Here, you can observe testers and developers working together to build a test automation framework for the project team and several testers working together to build tests.
The agile team members work together to start, define, and complete the features. As the successful agile teams collaborate to finish features, they avoid the problem of having many features started but none getting finished at the end of the iteration.
Obtaining feedback is a major factor that contributes to the success of an agile team. The members of a successful agile team use iterations so they can do something and obtain some feedback. They build in increments so their customers will have a chance to offer feedback on their work to date. One of the behaviors of the members of a successful agile team is the capability to take small steps and obtain feedback on whatever work they have finished.
Similar to every other project, conditions are not always favorable in agile projects. The agile team may not have acceptance criteria for every feature, a team room may not be present, and they may not remove obstacles. Despite all these things, the team has to get the work done. So, the members of a productive agile team are adaptable to any kind of situation(be it the ideal or the worst situation).
The agile team must be willing to work outside the area of their expertise but not very far from it. This doesn’t mean they must work in other areas about which they don’t have any idea. Take, for example, a marketer should not turn into a developer(unless he or she wants to). This means that if someone is quite comfortable with the database, then they should try to work on the GUI. We often see these instances happening when people collaborate to swarm around a feature.
Being intrepid is one of the major characteristics of a successful agile team. Its indications include the members of the team challenging each other, and very less filtering of communication(communicating it like it is). A larger part of this is to exhibit a sense of vulnerability or the willingness to say “I don’t know.” It also includes the ability to ask for help promptly when you need it. The team should always be self-directed and exhibit high performance to engage in its continuous improvement and overall dynamics efforts.
The members of a successful agile team will have an insatiable hunger for knowledge. They always try to find ways to share their knowledge, learn various new things, and enhance their skills. They invest money and time in employee development. Also, all team members must be able to see where workloads stand at all times, and individuals must be ready to share their theories on the status of their projects.
For example, the agile team incorporates frequent daily stand-up meetings. These are short, highly focused meetings designed to keep team members on task. Standups help provide daily transparency into the development process, so all team members, whether they are onsite or working remotely, have a good sense of their project’s status. Standups help keep team members honest and the discussion they facilitate can identify obstacles that may be impeding development. Each of these points is important in achieving the right mix of team members, which is particularly critical for agile success.
An example of a company which successfully uses agile methodology is Spotify. Going Agile has allowed Spotify to be faster, better, and cheaper than industry Goliaths like Google, Amazon, and Apple. Spotify ensures its Scrum masters are also experienced Agile coaches. By employing “squads” and “tribes,” Spotify makes sure its teams are continuously deploying software and sprinting. Knowing when to cut off slow teams is crucial to elegant Agile in Spotify.
The most popular Agile methodologies used by practitioners(including me) today consists of the following: Scrum, XP (eXtreme Programming), DSDM (Dynamic Systems Development Method), FDD (Feature-Driven Development), ASD (Adaptive Software Development), Crystal, and LSD (Lean Software Development). Also, while Kanban is not considered an Agile development method, it is commonly used in conjunction with Agile methods as a means for increasing efficiency.
If you decide to work on an agile method, you have to choose which method is best for your team based on the characteristics such as project size, team size, iteration length, roles and responsibilities, virtual team support, and risk mitigation level. According to me, the most popular Agile methods are Scrum and XP, and they are very much aligned in their practices.
Lean software development (LSD), more commonly referred to as “Lean,” is based on the principles of lean manufacturing which originated from the Toyota Production System. Lean is based on a set of principles aimed at achieving quality, speed, and customer alignment. This method is commonly adopted by startups.
Improving how teams innovate is a continuous journey, and new methodologies will certainly emerge over time, as well as best practices for software development. Teams will find that different approaches are available and work better for them. But the impact of Agile on product development cannot be understated, with its focus on the customer and the art of collaboration.
Nowadays, it is obvious that all people fully agree with Agile Methodology for software development. So, do I. But we need to know that Agile methodology is not a new thing or a unique experience. It has been used by software development teams for many years before the announcement of Agile manifesto.
As far as I have seen, regardless of which methodology is selected, the most important thing is the commitment of team members. Each team member should become committed to the project instead of involving it.
The other important thing is the daily meetings. It updates people and makes them ready for that day. According to my experience, everything of the agile methodology can be modified except for the daily meeting. It drives the team, so it always should stay in the methodology.
The software development is a process that must be agile and collaborative above everything else. So, the agile team should maintain a culture of open knowledge sharing and cooperation throughout. The above characteristics of an agile team will make it successful and productive reflecting in a successful end product.
Thank you Ravindra Savaram for sharing your thoughts on and experiences with successful agile teams. Collaboration and feedback are key aspects of team working, they are essential to working as a team. Being adaptable and intrepid increases the agility of teams, and engages people to the level where they will be continuous looking for improvements.
I’m updating and expanding my successful second book What Drives Quality. Intermediate versions are released through Leanpub: What Drives Quality.
In my book What Drives Quality, I take a Deep Dive into Software Quality with Practical Solutions for Delivering High-Quality Products. It’s intended for software developers and testers, architects, product owners and managers, agile coaches, Scrum masters, project managers, and operational and senior managers.
After publishing the first edition as an eBook in September 2017 much has happened. People downloaded the eBook and shared their experiences on delivering high-quality software with me. There were emails, tweets, LinkedIn comments, praise, and other feedback that I received from my readers.
The second edition contains additions throughout the book. I have added many practices and experience stories to the existing chapters. I also added a new chapter, Driving Quality, where I explore how to measure and analyze quality, describe the Project Defect Model, and show how you can steer quality in agile. This edition also contains a second foreword by Jan van Moll, Senior Forensic Investigator and Head of Quality & Regulatory at Philips Healthcare.
What more is new in the second edition:
Using use cases for specifying requirements.
How personas can be used to understand the users.
The “dark side” of commitment.
How burnout impacts quality.
Lean startup, using feedback to learn and develop the right products.
The book has grown already from 117 to 172 pages, almost a 50% increase. More will be added in the coming weeks.
If you buy the book now on Leanpub you will automatically get all updates toward the second edition for free. So don’t wait too long, get your copy now!
Gamification is an approach where principles and practices of gaming are used in a non-game context. In this article, I’ll explore how you can increase agility with gamification.
In my work, I apply gamification in a business and team working context. I use practices from gaming to support professionals that are working together increasing their agility to deliver more business value. Adding game aspects to their daily work enables change and fosters continuous sustainable improvement.
Gamification is a great way to engage and involve people. Which is an essential ingredient if you want your organization to adapt to change and improve. Gamification strengthens agility and can give a boost to your agile transformation.
Games vs. gamification
Both games and gamification have value, but when it comes to self-assessments and organizational change I prefer to use gamification as it get’s people involved to create their own agile journey.
There are significant differences between games and gamification:
Games are often used to learn new things and to practice, where gamification intents to inspire and encourage behavior change.
Gamification focuses on the intended outcome and the results, where games give attention to the rules and the process.
When it comes to enabling change and improvement, I use gamification because it matches with the agile mindset to encourage self-organization, experimentation, and continuous improvement.
Gamification in agile self-assessments
The Agile Self-assessment Game is a gamified approach for reflection. It’s a behavioral game that helps to initiate and reinforce positive behavioral change in organizations.
Where often games have winners and losers, I prefer to play games in such a way that people don’t feel like they have “lost the game”. For me winning is not the main objective to have people play games, it’s sharing and initiating change that I aim at.
The Agile Self-assessment Game is not a game in the strict sense of the word where people play “by the rules” and where there are winners and losers. Actually, with most of playing suggestions included in this game, everyone wins the game if they share and collaborate. There are no losers :-).
I decided to use the term “game” for the assessment approach described in The Agile Self-assessment Game – The Map for Your Agile Journey, although I’m applying gamification in it and using it as a gamification tool in my workshops and when coaching organizations. I’m expecting that by calling it a game it will appeal to people and that it becomes something they are willing to try out.
The benefits that I have seen from using gamification in Agile Self-assessments are:
People like to play games, it brings out their natural desires to socialize, self-express, and collaborate
Gamification provides a different perspective and culture, which leads to new valuable insights
Playing games with teams stimulates collaboration and helps to build relationships
Gamification is a way to visualize what’s happening which helps people to align and decide
You can create an environment with gamification where people feel safe to speak up and be open and honest
Assessing your agility
With the Agile Self-Assessment Game teams can discover how agile they are and what they can do to increase their agility to deliver more value to their customers and stakeholders. Playing the game enables teams to reflect on their own team interworking and agree upon the next steps for their agile journey.
The Agile cards and Expansion packs for Scrum, Kanban, DevOps, and Business Agility can be downloaded in my webshop, They are PDF downloads with card images and playing instructions that can be used by teams and organizations to self-assess their agility. The card texts are based on the manifesto for agile software development and generally accepted agile principles and practices. This makes the game useful for all agile teams, whether using Scrum, Kanban, XP, Lean, DevOps, SAFe, LeSS or any other agile framework.
This game is also available in book format. In February 2018 I published The Agile Self-Assessment Game on Leanpub. The book bundles all information about the game into a handy ebook, it contains everything you need to do agile self-assessments. Packages are available consisting of the book and the cards (Agile, Scrum, Kanban, DevOps, and Business Agility) in English, Spanish, Czech, and Dutch.
The book and the cards in my webshop co-exist, they are different formats with similar information. They both include playing instructions and experiences stories which help you to create your own playing format.
The State of Testing survey investigates how the testing profession develops. Last week the State of Testing 2018 report has been published. I’m a blog collaborator for this survey, so I highly recommend reading it!
The State of Testing is the largest testing survey worldwide. With about 1,500 participants from more than 80 countries, the survey aims to provide the most accurate information of the testing profession and the global testing community. Held yearly, the survey also captures current and future trends. In collaboration with leading testing bloggers and thought leaders helping us make this survey a reality (…), this survey is all about giving you, as a tester, the ability to better understand your professional status compared to other testers and companies worldwide, and to be better prepared based on current and future trends.
One of the questions that I asked was about the adoption of Agile Retrospectives:
InfoQ: The report mentions a significant increase in retrospective meetings. What causes this and what can be the result?
Bhamare: This is what I partly meant by multi-faceted role of testers and their contribution to project teams.
By nature of their job-role and the abilities they posses thereby, I feel that testers are endowed with great observation skills that can benefit project teams to improve things that eventually add to product quality. These observations can be at the system level, application level, people level and what not, but the point is, there better be someone who “observes” things, analyses them and presents them in a form that enables team members to see things from a different perspective.
Skilled testers, with their sharp observation skills can make retrospectives far more effective. As Jerry Weinberg explains in his ideas of System Collapse/Explosions and feedback loops to control them, “act early, act small” is the key and testers are naturally best candidates to make the feedback loop optimum for the controller. That’s how I look at this whole retrospective thing.
Montvelisky: Again here we see another indication that testers are joining Scrum and agile teams, taking part in the different activities these teams do.
And in parallel it also indicates that the teams, and the testers among them, are becoming more aware of the value of retrospectives, counting them as “static testing” activities where we have a chance to look not only at the bugs we are finding, but also at the incorrect processes generating these issues, in order to fix the process and not only the bug.
Testers have been striving to work in the quality of the process for ages, and in many ways agile practices such as retrospectives can give us a chance to finally achieve this goal.
The result of this type of processes will hopefully be a more integrated quality culture, where we celebrate and learn from our mistakes in order to improve our working methods and culture.
I will be giving workshops on agile in Prague, Athens, and Berlin. Ticket sales are ongoing, book your seat now.
The following agile workshops are planned in the Autumn of 2018:
Workshop Valuable Agile Retrospectives in Prague, September 11
Learn new exercises for your agile retrospectives, find out how to create a safe environment, and improve your facilitation skills in the workshop Valuable Agile Retrospectives in Prague on September 11!
What will you get out of the workshop Valuable Agile Retrospectives
Understanding of the why and how of continuous improvement and how retrospectives can contribute.
Know how to establish the pre-requirements for retrospectives and create safe environments to run retrospectives.
Exercises for doing effective and efficient retrospectives.
Approaches to deploy retrospectives and to improve their usage and results.
Workshop Getting more out of Agile and Lean in Prague, September 12
Are you interested in learning practices for teams and their stakeholders to develop the right products, deliver faster, increase quality, and create happy high performing teams? Come to my workshop Getting more out of Agile and Lean in Prague on September 12!
What will you get out of this workshop?
Effective practices for planning, daily stand-ups, product reviews and retrospectives
Ideas for improving collaboration in teams and between teams and stakeholders
Tips and tricks to improve your agile way of working
Advice on selecting and applying agile and lean practices effectively
A couple of weeks ago I started a new series of posts on Retrospective Smells. I plunged in by exploring two smells, passiveness and blaming. For each smell, I described how to recognize it and how to deal with it. In this post, I’ll explore why facilitators need to know about retrospective smells.
What’s a retrospective smell
A retrospective smell is a signal that something might be going wrong in your retrospective. It’s a warning that problems might happen that will impact the retrospective result.
As it’s a signal, the first step to take is to explore what is going on. My suggestion is to use your senses to get more information. What works for me is to observe, listen, and ask questions.
Once you have a better insight, then you can act. Either you can do something to solve the problem or to mitigate the impact.
What makes it important to recognize smells
An agile retrospective is a delicate meeting. It can be hard to facilitate it, many things can go wrong. As a facilitator, you have the responsibility to deliver valuable results: actions that help the team to solve problems and improve.
If the meeting fails to deliver, that is a waste of time and energy. Retrospective smells are early warning signals. If you recognize them and act promptly, it can make the difference between a failed and a successful retrospective.
If retrospectives fail often, that’s even worse. People will resist doing retrospectives, they will skip them. Teams will miss out on opportunities to learn and adapt and problems might go unsolved.
Asking people to invest time to reflect and learn is ok, provided that their investment will pay back to them. Sensing and acting on retrospective smells helps you to keep your agile retrospectives valuable.
Is it a real smell?
How can you distinguish a signal from noise, how can you know for sure that something will go wrong if you don’t intervene?
The short answer is: You can’t.
The question, however, is if you want to take the risk.
Getting teams to attend retrospectives, setting the stage for reflection, and establishing a culture where people can be open about what is happening and willing to take action often isn’t easy. You don’t want to see that go to waste because you didn’t recognize a smell of didn’t act properly.
The long answer is that you can cultivate your skills for recognizing smells and filtering out a noise. It takes practice, the benefit will be that you will become a better facilitator who is able to help teams and organizations to really improve.
When you’re in doubt, my suggestion is to investigate the signal and find out if there is a problem.
Some of the ways that you can do this are:
Observe how people react. If you see “negative” behavior by multiple attendees like people acting disengaged, annoyed, angry, violent, or worried, then there’s probably a problem.
Reflect the signal to the participants, tell them what you observe and ask them if they see the same.
Ask the participants if there is a problem, and if there’s anything you as a facilitator can do.
If there’s productive interaction, people looking for solutions and supporting each other, a good balance of listening and talking, then things are probably OK.
Open Space on Retrospective Smells
At the 2018 Retrospective Facilitators Gathering Jasmine Zahno and I came up with two related topics. I wanted to talk about retrospective smells where Jasmine raised “retrospective 101s”, things you want to know before doing retrospectives.
We decided to team up together and co-facilitated an open space session on retrospective smells and 101s. Together with the attendees we identified smells and discussed how to recognize them.
Jasmine created the below graphic which shows the smells that were mentioned in the session.
A big thank you to the session attendees who brought up many smells and to Jasmine for drawing the graph!
Share your experience
In my series on Retrospective Smells, I will write posts on the smells mentioned in the above picture and on many others. In these posts, I’ll provide tips for recognizing smells and suggestions for dealing with them.
This website is all about sharing experiences. So I’d like to hear from you.
Which retrospective smells have you seen and how did you deal with them?
The cards for playing the Agile Self-assessment Game have been translated into many languages. Packages are available that contain my book about the game with cards in Czech, Polish, Spanish, or French.
My book The Agile Self-Assessment Game on Leanpub contains everything you need to do agile self-assessments and play the Agile Self-assessment Game. It comes with playing cards for agile and supports methods like Scrum, Kanban, DevOps, and Business Agility.
Play the game in your own language
The book is in English, but the cards are available in multiple languages. Currently, the following packages are available:
Agile Self-assessment Game – English edition: The book (in English) with 52 basic Agile cards and expansions packs for Scum (39 cards), Kanban (52 cards), DevOps (26 cards) and Business Agility (26 cards). Total of 195 English cards!
Juego Autoevaluación Ágil – Spanish edition: The book (in English) with 52 basic Agile cards in Spanish and expansions packs in Spanish for Scum (39 cards), Kanban (52 cards), DevOps (26 cards) and Business Agility (26 cards). Total of 195 Spanish cards!
Agilní sebehodnotící hra – Czech edition: The book (in English) with 52 basic Agile cards in Czech and expansions packs in Czech for Scum (39 cards), Kanban (52 cards), DevOps (26 cards) and Business Agility (26 cards). Total of 195 Czech cards!
Gra Agile Self-Assessment – Polish edition: The book (in English) with 52 basic Agile cards in Polish and expansions packs in Polish for Scum (39 cards), DevOps (26 cards) and Business Agility (26 cards). Total of 143 Polish cards!
This is the first book specifically about Agile Self-assessments. It’s a practical book with many techniques and ideas that you can apply in your specific situation, intended for Scrum masters, agile coaches, consultants leading agile transformations, developers and testers, project managers, line managers, and CxOs; basically for anyone who is looking for an effective way to help their agile teams improve and increase the agility of their organization.
It will remain possible to download the Agile cards and Expansion packs for Scrum, Kanban, DevOps, and Business Agility in my webshop. This new book bundles all information about the game into a handy ebook. It also includes playing instructions and experiences stories which help you to create your own playing format.
If you are interested in receiving a review copy of the book with cards in your local language, please contact me.