Lean Coffee is an agenda-less and structure meeting wherein participants are tasked to gather and build an agenda. They will also have to start talking to each other. As per the conversations, these are entirely productive and directed due to the reason that the agenda is mainly and democratically generated. In fact, a lot of Lean Coffees are now happening around the world including Stockholm, San Francisco, Seattle, New York City, Boulder and a whole lot more.

History

In regard with the history of Lean Coffee, it actually started in the year of 2009, in Seattle. Jeremy Lightsmith and Jim Benson initiated of starting a group that will focus on the discussion of Lean techniques. In this organization, it is to be started without speakers, steering committees and such. They only desire for a group that only relies on people who show up and who want to create and learn.

In terms of how to exactly do it, the format followed is usually simple. It is intentional and it is designed to be necessary for productive and coherent meeting. Setting up a Personal Kanban, Citing the things that need to be discussed and voting and talking are among those steps to be followed.

There must be a list of topics that need to be presented in order for them to get motivated and interested in it. For those people who are interested to begin with a Lean Coffee could just do it the simple way.

Especially if you have started one, they would be happy to help you set up a subdomain on the site. They will also find ways to work with you in the future for the best and most interactive map.

Application

As per the application or the management of Lean Coffee with a distributed team, it is highly emphasized that a tool is needed. You may make use of an online whiteboard. But, it is better to make use of a tool that is built for Lean Coffee.

One of the valuable tools to use consists of Retrium which is a set of facilitation techniques. This is specifically designed for all agile retrospectives. They have their template called Lean Coffee which proved to be incredible and easy to use. This can also be effectively utilized for more applications and not only for retrospectives. This is a lot better to use by enterprises and companies. The good thing about it is that it is free for you to try. But, later on, it will demand for a paid subscription.

Lean Coffee Table is also another simple website designed for the application or distribution of Lean Coffee. This is impressive because it can be used for free. In addition, it is best for casual use and for meetups.

— Slimane Zouggari

An unconference is known for its other term “open space conference”. This is actually considered as a participant oriented-meeting. In the complete understanding of its term, it is usually applied to a lot of gatherings that avoid 1 or more aspects that relate to conventional conference like sponsored presentations, top-down organization and fees.

History

Dating back in the history, unconferences were believed to utilize variations on the Open Space Technology method or format. This format was created and introduced by none other than Harrison Owen in the year of 1985.

In the book entitled “Open Space Technology: A User’s Guide” published by Owen in 1993, it simply discussed a lot of techniques usually linked with unconferences. However, in this book, it does not entirely make use of the term.

As per the first appearance of the term, it was witnessed in an announcement for the annual conference of XML developers. This was noted in the year of 1998. Lenn Pryor also used the term in the discussion of BloggerCon. Later on, it was then popularized by the organizer named Dave Winer. He was the reputable and trusted organizer of BloggerCon during a write-up event in April 2004. In regard with the first BloggerCon, it was held in 4^th to 5^th day of October 2003 at the Berkman Center for Internet and Society in Harvard.

As per the organizer of Foo Camp, Sarah Winge had drawn her experience of conversations and had opened space with Harrison Owen to further develop its format. It was in the 10^th to 12^th day of October 2003 that the first Foo Camp happened in California.

In the year of 2005, the attendees from the past produced their so-called “Bar Camp”. The three events; Foo Camp, BarCamp and BloggerCon helped in the popularization “unconference” as a term. Bar Camp and Foo Camp have popularized the form wherein there will be no agenda until all attendees have made one up.

Application

In regard with the application, the attendees usually start with the agenda at the very start of the meeting. For those who want to insist a discussion on a particular topic may choose to claim a space and a time. Actually, unconferences feature an open discussion instead of a single speaker placed in the front of the room for reputed individuals to give a talk.

This conference is found to be specifically useful especially when attendees have a high level of knowledge and expertise in the conference convenes. Nevertheless, it can be conducted and applied through the use of facilitation styles like:

• Fishbowl
• Ignite
• Dotmocracy
• Lightning Talks
• Open Space Technology
• Knowledge Café
• World Café
• Speed Geeking
• PechaKucha

This has been found to be useful when applied to gatherings or conventional conferences established by organizations.

 — Slimane Zouggari

There are many people out there who think that a Minimum Viable Product, also known as MVP, is a beta product, but that is not the case at all. The MVP is actually a version of a product that has been simplified as much as possible in order to be used for testing with minimal efforts in regards to how it will perform.
The one thing that is important to understand is that the MVP is more of a test that it is a product. This means that it’s meant to be used for experimenting and it should never be labeled as the official product. Let’s say for example that a company creates software that allows people to share files, but instead of releasing the software, they create an explainer video that shows the features of the software in order to see what kind of feedback they get from the community.
This is a representation of the product and it allows for a very safe way to test the riskiest assumptions of that particular product. That is basically what an MVP is and it allows companies to gather all kinds of data without having to make expensive and very risky investments.
Anything that allows you to test the riskiest assumptions is going to be categorized as MVP. The key here is that the MVP allows for a very good representation of the product. Some companies have used landing pages, power point presentations and explainer videos as their MVP and it has allowed them to collect the kind of data that validates their investment.
Those are great examples of what MVP is and how you can apply this to your own products or services before you decide to launch them. It’s an extremely powerful way to test a product without having to take any risky chances in the process.

— Slimane Zouggari

An agile workflow allows groups to estimate new work effectively. A group that has been working together for some time can estimate new user stories much better. Groups that have experienced failures and successes in the past can compare their speed against point estimates that all members can accept and thus, they can predict with rational accuracy how hard it will be for them to complete new stories.
Groups that are new to agile workflow, however, may find it hard to determine how to estimate user stories effectively. Some teams find that the soft relationship between actual time allotted working on stories and point value can be disrupting. Others find the team-specific and abstract concept of points hard to understand. Attempts to get precise point estimates for new user stories may feel loose and obstructive. There are agile estimation techniques that can be used to make the process easier for groups. One of these is TFB / NFC / 1 (Sprint). This technique can get every member of the group involved in productive point estimation from the beginning, no matter their level of experience or skill with agile techniques might be.
How Does TFB / NFC / 1 (Sprint) Work?
TFB / NFC / 1 (Sprint) is an agile estimation technique similar to Big/Uncertain/Small, another agile estimation technique that places items in one of the 3 categories – Big, Uncertain and Small. With TFB / NFC / 1 (Sprint), on the other hand, there’s a specific size in the mix and that is 1 Sprint. The categories include No F-ing Clue, “1” Sprint and Too F-ing Big.
Why Use TFB / NFC / 1 (Sprint)?
TFB / NFC / 1 (Sprint) is fast. A large number of items can be estimated within a short period of time. It is also collaborative, so each member of the team can participate roughly equally. The right people participate in the estimation process. Tracing who estimated what is impossible, so group accountability is promoted. If someone makes an incorrect estimate, there’s no way to know this person. The whole group is responsible for everything, so no one can blame any member of the team.
This agile estimation method also gives relative results. You’re not really trying to learn to foresee the future. Agile estimation techniques like TFB / NFC / 1 (Sprint) help you realize that the estimation process is a non-value added activity and reduce it as much as possible. Most agile estimation methods also use relative units. This means that teams don’t have to estimate days or dollars directly. Qualitative labels or points are instead used and items to be estimated are simply compared to one another. This uses a person’s ability to compare things to one another and prevents difficulty in comparing items to an intangible matter such as days or dollars. It is important that teams learn how to approach new user stories and determine the amount of effort each story will take to complete. With TFB / NFC / 1 (Sprint), estimation is made much simpler.

— Slimane Zouggari

Adopting an Agile workflow allows teams to estimate work more effectively. New user stories will come and team members should develop a progressively precise sense of how they are going to approach these stories and how much effort the user stories will take to complete. Everyone on the team should participate in the estimating process to arrive at a precise estimate that reflects the team’s true investment and understanding. The team’s ability as a whole to estimate new user stories will develop slowly if members don’t participate actively. Divide until Maximum Size or Less is an agile estimation technique that teams can use when estimating new user stories.
How Divide until Maximum Size or Less Works
The team chooses a maximum size for all the items. Every item is discussed by the team to decide if it’s already that size or less. In case the item is bigger than the maximum size, the team divides the team into sub-items. They then repeat the process with each sub-item. This will continue until each item is in the acceptable size range.
Benefits of Divide until Maximum Size or Less
Divide until Maximum Size or Less is a collaborative technique. All members of the team are included in the estimation process, so blaming someone is impossible as there’s no way to trace the member who made an estimate. As such, the group is responsible as a whole. Since everyone is liable, every member of the team will be more encouraged to participate in discussions and give an estimate.
Since Divide until Maximum Size or Less is an agile estimation technique, it is faster than traditional techniques. Members don’t need to spend all their time estimating user stories using time-consuming methods and they can focus more on their work. Team members don’t try to estimate days or dollars directly. Points or qualitative labels are instead used and the items the group is estimating are compared to each other. With this, members of the team don’t need to compare something to an intangible concept.
There are other agile estimation techniques that teams can use aside from Divide until Maximum Size or Less. One of these is Planning Poker where team members vote for an item estimate using individually-numbered playing cards. Voting is done repeatedly until the votes are the same. The Bucket System is another agile estimation technique. It uses the same order as Planning Poker. Items are estimated by putting them in buckets. Compared to Planning Poker, The Bucket System is faster since there’s a divide-and-conquer step. It can be used with bigger groups as well. The Bucket System can be used to estimate large numbers of items.
By using these agile estimation techniques, a group that has no previous idea of point values can understand the relative value of the stories they encounter. The sooner the team begins estimating points and monitoring their efforts, the more effective their point valuations will become. Every member of the team will eventually become more proficient at estimating new user stories.

— Slimane Zouggari

While Planning Poker can help you bring up the conversation for user stories, it’s not really the most effective way of estimating those. In Planning Poker, participants vote for an item estimate using specially-numbered playing cards. Voting is done again and again until all votes are the same. This process is certainly time-consuming, but there’s a better way to arrive at an estimate of an item. Challenge, Estimate or Override or the CEO game is a more effective estimation method and is suitable for agile environments. You can use the CEO game to lessen the amount of time spent on estimation of user story and focus more on collaboration. Here’s how to do the CEO game.
• Print out user stories as cards.
• Gather everyone around a long table.
• The top of the table should show stories that are estimated the biggest and the bottom of the table should display stories that are projected the smallest.
• Every participant should read a card and estimate it by putting it on the table. The lower the cards are placed, the smaller they are. This step is called Estimate. Get a card that’s already placed on the table and move it on the same table. This stage is referred to as Override. Take a card and challenge the participant who placed it on the table on their estimate. This step is called Challenge. It is the participant’s responsibility to argue on his estimate and then correct it.
• Participants should take turn following the rules stated above until there’s no card to put on the table.
• When there’s no longer any card to place on the table, participants can get one last chance to play the CEO game if they want.
What to Remember When Playing the CEO Game
The Challenge option can only be used once every 2 turns. This option is most beneficial when a participant doesn’t agree with the estimate and he doesn’t know who made the estimation. You can also ask the members of the group to stand during the entire process. If you don’t do this, they may lean and be inactive when placing the cards.
Once the exercise is completed, Fibonacci numbers can be assigned to the user stories if desired. Fibonacci numbers can start with 1 and 2 and followed by the sum of the 2 previous numbers. For instance, it can go like this – 1, 2, 3, 5 and so on. 2+1 is equal to 3 and 5 + 3 is equal to 8.
Participants can also choose to only Override or Challenge two times, so they don’t get overwhelmed and they can choose their battles. You now have a list of user stories estimated within a shorter period of time. If you’re using an electronic board, try to use a projector if some participants don’t agree with the terms of user stories and you’d like to see them. Any concerns or questions about a user story can be explained by discussing it more carefully.

— Slimane Zouggari

The Bucket System is all about estimating large amounts of items with small and medium sized groups and doing it fast. It is ideal for agile environments because it is collaborative, fast and gives relative results. You can estimate hundreds of items within an hour and everyone in the group can participate roughly equally. Since the results cannot be traced to any individual, this system promotes group accountability. You can work with stakeholders to predict value or collaborate with teams to estimate effort.
How the Bucket System Works
1. Use the diagram below to create the physical environment and make sure that all the items you need to estimate are written on cards.
2. Pick an item randomly from the collection and read it to your group. Put it in the 8 bucket. It will be the first reference item.
3. Select another item randomly from the collection and read it. The item’s relative place on the scale will be discussed by the group. The item will be placed in the right bucket once consensus is achieved.
4. Pick a third item randomly. Again, the group will discuss it and the item will be placed in the right bucket once consensus is attained.
5. The items can be re-scaled in case they have tilted the scale to one end.
6. Assign the remaining items equally to all members of the group. Every member puts items on the scale without discussing with other members. If a member has an item that he doesn’t understand, that item can be given to another person.
7. Every member must quietly evaluate the items placed on the scale. If someone finds an item that he thinks should not be there, he can discuss it with the group. The group will discuss it until they reach a consensus and the item is placed in the right bucket.
8. Record the estimates by writing the bucket numbers on your cards.
Things to Consider when Using the Bucket System
There are some things that you should consider when using the Bucket System. One of these is that you can place several items in the same bucket. Placing items between buckets is prohibited. If the item distribution is titled to one side of the scale or the other, the group should discuss during the “sanity check” if the items should and can be distributed more consistently along the scale. If it is possible, the group can do it together.
The facilitator should also observe to ensure that nobody moves any item that has already been placed until the sanity check is done. The distribution of items among group members doesn’t need to be precisely equal. You can distribute the items roughly.
If one or two members are working sluggishly through their items, they can share the remaining items with those who are already done. It’s not acceptable for any member to completely withdraw from the process. Someone who wants to abstain from the process should be counselled. This means he won’t have any say in the estimates in the future. Absolute silence should be maintained during the divide and conquer step. There should be no mutual discussions of items to protect the privacy of members placing items.

— Slimane Zouggari

Big/Uncertain/Small is an agile estimation method where the items to be estimated are placed by the group in any of these categories – big, uncertain and small. Teams discuss a few items together and then uses divide-and-conquer to estimate the remaining items. Big/Uncertain/Small is just like the Bucket System. In the divide-and-conquer step, you allocate the remaining items to all members of the team. Every member puts items on the scale without discussing it with other team members. If someone has an item that he doesn’t really understand, that item can be given to someone else.
Benefits of Big/Uncertain/Small
Big/Uncertain/Small is designed to be collaborative. This means that everyone in the team contributes roughly equally. The results cannot be traced to one person, so this agile estimation method promotes group accountability. Even if someone makes the wrong estimate, that person cannot be determined. No one will know what his estimation was. Blaming someone in the team when something goes wrong is avoided. Since the method is collaborative, all the right people participate in the estimation process. No team member can give any excuse and escape from the responsibility of taking part in the process of estimation. Everyone in the team needs to work together.
This agile estimation method also takes advantage of people’s ability to compare things and helps teams avoid comparing items to abstract concepts. As such, the estimation process is simpler and can be completed much faster. Teams don’t need to use old-fashioned techniques that will take so much of their time. With Big/Uncertain/Small, they can save time and focus more on collaboration.
Big/Uncertain/Small is similar to TFB / NFC / 1 (Sprint). However, TFB / NFC / 1 (Sprint) includes a specific size and that’s 1 Sprint. The categories in TFB / NFC / 1 (Sprint) are “1” Sprint, Too F-ing Big and No F-ing Clue.
There are other agile estimation methods that teams can use aside from Big/Uncertain/Small. One of these is Affinity Mapping where items are assembled by similarity. This similarity is usually a physical activity and needs a small number of items. The groups are linked to numerical estimates if preferred.
Another agile estimation method is T-Shirt Sizes. Items are grouped into t-shirt sizes – S, XS, M, L and XL. If required, the sizes can be given numerical values once the estimation is completed. This method can be used with a large number of items. The decision about the size is usually based on open, collective discussion. By using an agile workflow, the team can estimate new work more effectively.
As they face new stories, they will have a more precise sense of how they should treat each user story. They will also know the amount of effort they need to spend on each story to complete it. A group that has been working together for some time can estimate new stories much better. Agile estimation methods can get all members of the team involved in productive estimation regardless of their experience level with agile methods.

— Slimane Zouggari

Affinity mapping is used to group and understand information. It is a good way of identifying and analysing issues. Affinity mapping can be used in agile or workshop environment where participants need to work together to identify, discuss and group issues.
How is Affinity Mapping Done?
Affinity diagramming involves putting related items together. Small sets of data can be placed together electronically, but it’s still better to do it on paper. Using paper is advised in group situations. Items are gathered by similarity and this similarity has to be estimated. It’s usually a physical activity and needs a small number of items. The groupings are linked to a numerical estimate if preferred.
If there’s a pre-existing set of data, you can print these on cards or labels or paper and cut them to the right size. In group situations, post-it notes can be given to members. You can ask your group members to write one issue on every note. Give members some time to do this, but you should ask them to stop when most of the participants have stopped.
Call all participants and assemble at a vertical surface appropriate for post-it notes. Encourage everyone to put their notes on the surface one at a time. As every note is placed, other members may add related notes nearby. Depending on group dynamics, data being examined and amount of time, spending some extra time considering and reorganising the groups may be necessary. Once all notes have been gathered, you can name every group. This step is optional.
If the number of participants is more than eight, it may not be very convenient to gather around a common area. You can place all the notes on your own and get one note from every participant in turn. All of them can then give you any related notes. This may not be as suitable as getting the group to work together. This is because keeping everyone focused on the activity can be difficult. Affinity mapping is certainly a great tool if the result of the activity can be followed up fast. For instance, with affinity mapping, the group can discuss methods to address and solve various issues.
Things to Keep In Mind
If you’re managing the activity, you should always pay attention or you may not know what’s happening and it will be hard for you to understand the data structure. All group members should also be allowed to contribute. There may be a person who wants to control the positioning and move the notes. Don’t let this happen. Never move anybody’s note without their consent or agreement. Discussion with group members will often mean that someone wanted to bring up a different matter. You should encourage all members to put one note at a time and read them aloud.
Affinity mapping can also be exhausting. Don’t let the activity go beyond the point of boredom or exhaustion. There should be no more than two successive affinity mapping assemblies during a workshop. Since the resultant groupings are random, you should be flexible in the way you use information.

— Slimane Zouggari