Detailed Sprint Planning Agenda

No Sprint Planning meeting will be the same, but I have observed some very practical steps to help you power through your sprint planning and ensure the essentials are covered.

Some assumptions:

  • Iterations are 2 weeks in length. (adjust time boxes listed below if you do 1 week or 3-4 week sprints)
  • Teams have some level of cross-functionality
  • Product Owner is embedded in the team and in attendance

Sprint Planning Agenda:

  1. (15-30 min) Recap of current sprint
    1. What is done?
    2. What is left and why?
  2. (5-10 min) Prioritize any leftover items – The PO decides if left over stories should move to top of sprint backlog or sent back to the backlog. (Do not assume that because something was a high priority before that it for sure is a top priority again!)
  3. (5 min) Close previous sprint in ALM tool (Jira, VersionOne, Rally, etc)
  4. (15-30 min) Revisit estimates for carryover stories. (Look for TOTAL effort, not just remaining effort. This is key for establishing velocity)
  5. (5-10 min) Evaluate capacity of the team (check for PTO, training, etc)
  6. (90-130 min) Create the Sprint Backlog – Pull stories from the backlog to create the sprint backlog one story/task at a time.
    1. Break each story/task down to sub-tasks
    2. Estimate hours for each sub-task (optional)
    3. Quickly Re-visit the estimates for the stories after tasks are created.  Still seem good? (Your estimate was first created in backlog grooming, now you’ve gotten more specific and need to make sure it still is accurate)
    4. Note: if the team is not yet highly cross-functional you will need to take a look and who these tasks might be assigned to. If you only have 1-2 people, a team with a specific skill set you do not want to create a situation where the rest of the team is blocked because they have too much work. If the team is cross-functional you do not need to assign anything to anyone other than the first task an individual will work on after sprint planning.
  7. (10 min) Fist of Five – Ask the team about their confidence level for the upcoming sprint items. Specifically, this is trying to gauge if they feel their commitments are realistic, and there is nothing blocking them out of the gates. If there are outliers take the time to discuss and adjust sprint forecast as appropriate. Remember, you can always pull additional items from the backlog should the team finish all items in the sprint backlog.
    1. 5 fingers: I am 100% sure we will complete everything this sprint.
    2. 4 fingers: I think it’s probable we will complete everything this sprint.
    3. 3 fingers: There’s a 50/50 chance we will complete everything this sprint.
    4. 2 fingers: I think it’s unlikely we will complete everything this sprint.
    5. 1 finger: I am 100% sure we won’t get everything done this sprint.
  8. (10 min) Create sprint theme/goals – This could be action items from Retro, or focus on collaboration, or some vision from the PO about a feature.

Start With Scrum?

“Start with Scrum.”  Have you ever heard someone say this?  I’ve heard this statement multiple times over the years when folks are talking about agile transformation, and it rubbed me the wrong way.  The problem is, I couldn’t quite put my finger on why. In many ways, it makes sense right? Scrum can help someone wrap their mind around work decomposition, shorter feedback loops, retrospection, and being connected to the customer more through user personas. But why are so many teams struggling to find agility with scrum? I think I finally can explain why I think this approach isn’t the right thing to do if your end goal is agility.

1 – Scrum is a framework and agile is a mindset.

sahota

Source: Michael Sahota

Last year when I was presenting at the Global Scrum Gathering, we borrowed from Michael Sahota who said something to the tune of “If you adopt agile practices you could see a 20% benefit. If you adopt an agile mindset you could see 300% benefit!” So many people I meet that are interested in agile for their organization just want the benefits but without the mindset shifts needed to get there.  I don’t fault them for that because when you look at the Agile Manifesto it reads out very well and sounds like positive things for most rational people. What is sorely missing is the “counting the cost”. If becoming agile as an organization was as simple as doing some training and doing the Scrum Events, there wouldn’t be agile coaches.

2 – Scrum is so 1990’s.  (just like these awesome “hackers” in 1995)

hackers

Look…I love scrum.  I really do!  It’s something that opened up a doorway for me to be exposed to agile manifesto which has changed my life and career aspirations.  But, while I was working on a blog post entitled “The History of Agile” it dawned on me that Scrum was a response to waterfall. And it was a tremendous leap in the right direction away from fixed cost/scope/timeline type projects.  Then came along the agile manifesto which was a response to scrum and the various flavors of agility frameworks sprouting up. But we need to look ahead and allow the agile mindset to lead us into the great unknown.  Ron Jeffries, one of the great original thought leaders in agile even said “I may have invented points.  If I did, I’m sorry now.”  The point is, we need to inspect and adapt as technology changes, culture changes, and people change.

Here’s another awesome 90s picture just because I found so many great ones to use for this article.

fresh

 

 

 

 

 

 

 

3 – Training wheels can create improper habits.

training

 

 

 

 

 

 

 

 

I was listening to a presentation by Joshua Kerievsky last week and he told a story about teaching his daughter how to ride a bike. He said that many people talk to him about how Scrum is like training wheels for their organization to adopt agile.  He pointed out though that training wheels don’t actually teach you balance, they just teach you how to steer and peddle.  He took his daughter to the park one day and had her learn how to ride a bike by keeping her feet of the peddles and just pushing herself and lifting her feet to learn the balance.  She quickly got comfortable with keeping balanced which is typically the hardest part of learning how to ride a bike.  And in no time she was ripping around on the bike!  What’s the lesson here?  You don’t always need training wheels to begin your journey towards agility.

In conclusion, starting with Scrum may not be the right strategy for your team(s).  My personal guidance as an agile coach is to only start with Scrum if you envision something close to Scrum being your destination. And even in that is your situation, always start with trying to adopt an agile mindset before trying to implement a framework. By doing this, you are allowing your organization to tap into their creative potential, untethered to just one framework.

The History of Agile

history-of-agile-timeline

The timeline above contains some key moments in the history of agile, and some other interesting events taking place at that same time for reference.

  • 1970 – Waterfall Model was created (by Winston W Royce.) Interestingly enough some of the risks he called out have been realized and are much of the reason we saw agile come into existence.
    • “I believe in this concept, but the implementation described is risky”.
    • “The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything…. are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.”
  • 1970 – Also, Gas is 36 cents per gallon. Wut?!
  • 1990 – Jeff Sutherland and Ken Schwaber conceived the Scrum process in the early 90’s.
  • 1991 – Also, the release of Nirvana’s Nevermind signified the start of the Grunge era that would dominate the music scene up to the mid-90’s.
  • 1995 – Scrum is codified in 1995 in order to present it at a conference in Austin, Texas (US) and published the paper “SCRUM Software Development Process”.
    • Scrum was first tried and refined at Individual, Inc., Fidelity Investments, and IDX (now GE Medical). These weren’t simply startups with greenfield development efforts.
  • 1995 – Also,  OJ Simpson was found NOT GUILTY!
  • 2001 – In February 2001, Jeff and Ken were amongst 17 software development leaders creating the Manifesto for Agile Software Development. – Their goal was to take all the good things they’ve learned and create a “charter” for others to use. By this time there had been many variations of agility that evolved.  The manifesto was taking the best of the best and boiling it down to principles rather than a framework or methodology.
  • 2001 – Also, Lord of the Rings comes out in Theaters

Key Takeaway: Agile is not a flash in the pan, and is something that has been evolving for 20+ years. I believe we are even starting to see Agile become more of the “norm” in Software development. Agile as a mindset opens up the door for so much more than just SW Development.  What do you think will be the key points in time for agile 20 years from now?

A Guide To Backlog Grooming

Photo Credit: Leanpub.com
Photo Credit: Leanpub.com

Backlog grooming is a highly recommended maintenance activity a scrum team should execute each sprint. This is the process of adding detail, estimates, and order of priority to items in the Backlog. This is an ongoing process in which the Product Owner and the Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised.  The Product owner is responsible accountable for having stories ready for grooming, and the Scrum Master is responsible for making sure the stories are groomed before sprint planning.

Grooming will allow for:

  • A better understanding of user stories
  • Identification of dependencies and potential gaps for stories
  • User Story estimation for upcoming and future sprints

Product Owner’s Role

The Product Owner’s role in backlog grooming should start before the actual meeting. The PO will need to make sure that the stories are already prioritized. This is vital to making sure the team’s time is used to groom the most important items first. The PO should also add acceptance criteria or user acceptance test cases to stories as appropriate, depending on how soon each story will be pulled into a sprint. Backlog grooming should not be done without the PO.

Scrum Master’s Role

For this project The Scrum Master will schedule the meeting and take care of any other logistics.  The Scrum Master should also be in contact with the PO before the grooming session to make sure the stories are ready to be groomed.  Backlog grooming can be done without the SM.

The Team’s Role

Having the team involved with grooming is imperative.  While the PO has a great deal of the requirements identified up front, the team can help round out the technical aspects, dependencies, and other considerations.  With the team’s help, the acceptance criteria can be modified and expounded upon.  If the team has the ability to even briefly review the top upcoming items, its ideal.

What’s the potential impact of not having backlog grooming?

  • Your stories will not be prepared for sprint planning.
  • The connection of work items to big picture vision will grow stale.
  • A dev may be looking or hearing about a story for the first time as they are having it assigned during sprint planning. This typically can increase ramp up time.

Who Should Attend Grooming Session(s)

  • Level 1: Discipline Leads (UX/Component), Product Owner, Scrum Master (OPTIONAL)
  • Level 2: Same audience as above and including all Dev members and the QA teams.

Just Getting Started?

For the initial 1-2 sprints it’s suggested that both Level 1 and 2 sessions take place.  Cadence and details for L1 & L2 grooming is below:

L1 Backlog Grooming

(Optional but highly recommended): More focused/collaborative group review to fully prepare stories for the L2 Full Team grooming sessions. Goals:

  • Review story scope
  • Estimate stories at a high level (estimates may change in L2 Grooming)
  • Identify blockers and agree on an plan of action to unblock items

Pre-Requisite: Product Owner has reviewed stories for L1 Grooming and they are ready for review.

Timebox: Try to have 2 hours planned each sprint for L1 grooming (may be two sessions).

L2 Backlog Grooming

A collaborative discussion and elaboration of user story details and estimates.  All stories on the agenda won’t always be estimated as some will require additional discussion / decisions. Goals:

  • Stories should be understood by all members of the team
  • Blockers should be closed or workable
  • Stories should be ready for sprint placement

Pre-Requisite: Product owner has reviewed stories for L2 Grooming and they are ready for review.

Timebox: Try to have 2 hours planned each sprint for L1 grooming (may be two 1 hour if needed sessions).

Back To Basics

After your backlog begins to take on a level of refinement, you may find that it’s no longer necessary to have two separate backlog grooming meetings.  A great indicator for determining this would be to ask the following question: “Are all of the stories for the next two sprints containing enough detail that the entire team attend grooming without wasting time?”

Questions?

If you made it this far, you’ve consumed a lot of information.  And there wouldn’t be agile coaches our there if all you had to do is read a guide and be able to master the backlog grooming event.  Feel free to comment with questions or some suggestions you might have.

Agile Open NW 2016

I had the privilege of going to my 2nd Agile Open NW conference.  I’m a huge fan of this conference and the format it’s in.

What is it?  From the Agile Open NW Website “Agile Open Northwest is an annual conference about agile practices and techniques. Using Open Space, the participants themselves make the conference they want to attend.” Have you ever heard of “unconferences”?  The main idea of this conference is that it utilizes some of the key agile principles and allows individuals to self organize around topics they are interested in. I never would have expected it to work, but I’m pleasantly surprised!  on the first morning people start grabbing time slots on topics they want to discuss, content they want to create, or questions they want answered. You get 30 seconds to give your pitch to the group, and then people come to the sessions they are interested in.  You may have 2 people show up, or 30+! Even if no one else shows up it’s encouraged that you spend the time on your topic.  Why? who wouldn’t love 60 minutes to focus on a topic they are passionate about?

Who was there? There is typically a wide array of attendees. I’ve met developers, agile coaches, video game producers, and newbies to the agile world.  Some are there to be a sponge and absorb from others, but I think everyone ends up contributing to some degree.

What were the takeaways? This year’s theme was “Agile: How will you know it when you see it?”  While the sessions don’t have to directly align to the theme, somehow they tend support it tie back to it.  For me, I was surprised that my greatest takeaway was a session that I had not originally planned to attend.   I started at a session about enterprise agile transformations, and just wasn’t feeling it. Since we are encouraged to utilize the law of two feet, I moved on.  I stumbled across a session called “Agile Family”.   It was about how to apply some Agile/Scrum principles into your family.  It was fascinating to hear what others are doing in their families like stand ups, scrum boards, and dot voting to set priorities for the day. Not only did it inspire me to put to test more of the principles of agile in my personal life (Our family now has a scrum board and votes on what we do Sat/Sun!), it also helped me reflect back towards how I can use them better in my professional life. I also attended a few sessions where people presented ideas for new agile methods by taking rituals/practices from other frameworks and melding them into one. It was quite valuable to talk to others in the industry and be reminded of what’s most important.

This is a picture of the “Schedule Wall” that was used for showing when/where each session was.

AgileOpenWall

Across the conference center you will find flip charts with tons of brainstorming notes from sessions.  Even if you missed a session you can just want around during a break and snap pictures of what people created.

Evernote Camera Roll 20160204 122144File Feb 15, 3 58 06 PM

File Feb 15, 4 00 23 PM.jpeg

File Feb 15, 4 02 35 PM

I want to use agile, but my organization doesn’t want to

tumblr_n4ef3ynCZP1st5lhmo1_1280

Fear not agile warrior, you are not alone and help is on the way.  They are many situations where someone just knows that agile could help or even change the face of the entire company if utilized…yet someone or many people within an organization are opposed to the idea.  So what should you do?  First off what are some reasons someone would be against agile?

  1. The’ve been on a team where agile was used, and failed.
  2. They don’t know enough about agile or have misconceptions.
  3. They don’t believe agile is right for their organization/product.
  4. They’ve worked with an Agile Coach/Scrum Master/Consultant that was not very good at their role.  Yes, not everyone does their job well…even in the wonderful agile community.
  5. They are from the past (I kid…I kid! That was an IT Crowd reference)

Now for the part you really came to this blog post for: What are ways I can help my organization adopt and/or support agile?

  1. Start emphasizing agile principles in whatever work you are doing. As a consultant that works on a wide array of projects with a variety of methodologies, I’m often tested with how to apply principles on a personal level. Getting out of the theoretical and nitty gritty practical application is a great exercise towards see if/how agile could work at your organization. If this is something you feel is “out of your league” or you just don’t have the time to do, it’s OK.  There’s other ways to makes strides towards becoming more agile.
  2. Propose solutions to problems from an agile perspective but without using agile lingo. Some people are just turned off to agile terms and immediately roll their eyes when you say “backlog grooming” or “daily scrum”. But if you are able to problem solve using agile principles you could begin to win over even the harshest of critics.
  3. Create a mini scrum board for tracking your own work. I heard a story of a person who was trying to advocate for their company to adopt agile, and started doing a scrum wall in a shared space.  Pretty soon scrum boards were up all over the company.  Some were labeled “Inspiration wall” or “Wall of vision”.  Everyone from IT to Sales was using them. Baby steps can be better than no steps, right?
  4. Contact consulting companies. See if they would be willing to share about agile within your organization.  Some consulting companies will do this for free because it’s a great way for them to help your cause, as well as demonstrate their expertise in this area should you need their services down the road. Or see if they are willing to just share free resources with you.
  5. Join user groups and contribute to the agile community. There have been times where my primary daily function was far from an agile focus, but I was able to stay energized by attending local groups or writing blog posts in my personal time.  Also, sometimes effective reflection comes when you are looking in from the outside.
  6. Find a new opportunity.  (Please take this with a grain of salt as it’s just my opinion.) This for many reasons isn’t the first option anyone would like, but it may be the right solution. As the industry seems to be moving more and more towards adopting agile, it’s less likely that a company is just flat out rejecting agile. It could be that they proclaim to use agile but it’s very broken or dysfunctional. These kinds of situations can cause stress if you are a firm believer in the agile principles. But is the disappointment or stress consistently outweighing the rewards or satisfaction experienced? If yes, it may be time to look for new opportunities.   Robbie Bach wrote a relevant article you may find useful called “Knowing When To Walk Away

What about you? What advice would you have for someone in this scenario?  I’d love to hear what other people have done or are doing.

Planning tool: Pointing Poker (website)

What is it?

Someone developed this handy website for online Planning Poker sessions. Their website says it best “Online, virtual and co-located agile teams use this application during their planning/pointing sessions to effectively communicate points for stories.”

https://www.pointingpoker.com/

Pros:

  • It’s FREE!  It’s hard to be overly critical of a free tool right?
  • You can set custom point values.  this is useful if you want to simplify your backlog grooming discussions.
  • It’s fast to setup a session and requires no authentication.  In my opinion you want to spend as little time focused on getting into the tool as possible.  No credentials or software = a breeze.
  • Enables remote team members or distributed teams to work together.
  • The timer is super useful for keeping on track.  Until you press “Clear Votes” the timer keeps going.

Cons:

  • The interface is a bit outdated.
  • If you are concerned about security, this may not be the tool for you. While it’s not required to put sensitive or specific information on the site, all one needs is a session ID to see the contents of a session.
  • You can make your name whatever you want when you join the session.  Follow me on this one.  Depending on your team’s sarcasam-o-meter you could see some interesting names join your session. 🙂  If you are trying to run a smooth session with multiple people it could be a little clunky until you figure out who’s who.

Conclusion:

I love the tool, and have yet to find anything that works as well as this.  Well done!

Screenshots:

Do You Lean Coffee?

Have you ever used the Lean Coffee format for a meeting?   It’s a tool I’ve been so pleased to use in a variety of formats in recent years.  I’ve used it for governance meetings, team retrospectives, and open agenda meetings where there is no pre-existing agenda other than to do Lean Coffee.

What is the Lean Coffee format?

The following content is copied from http://leancoffee.org/  “Lean Coffee is a structured, but agenda-less meeting. Participants gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated.”

1. Set up a Personal Kanban

Simple Personal Kanban for Lean Coffee

In this Personal Kanban we have the items to discuss, what we are currently discussing, and the discussed columns.

This provides a structure for the conversation. Next we populate it

2. What to Discuss

A Populated Backlog for the Personal Kanban

People all get pads of post-it notes and a pen. They then start to add their topics for conversation into the “to discuss” column. These can be literally whatever people want to discuss or follow a theme. Right now, we want to encourage as many unique ideas as we can.

When the ideas start reach a certain point (an you’ll be the best judge of when that is), each topic gets a 1 to 2 sentence introduction. This way people know what to vote for.

3. Vote and Talk

Stockholm Late Night Lean Coffee

Each participant gets two votes. You can vote twice for the same thing or for two different topics. Simple put a dot on the sticky you are interested in. Tally the dots. Then you are ready to have a conversation.

The power here is that you now have a list of topics everyone at the table is interested in and is motivated to discuss for real.

End of content from leancoffee.org website.

Some benefits of using the Lean Coffee format:

  1. It’s highly collaborative!
  2. It supports the discipline of being a self organizing team.
  3. It helps to crowd-source the agenda. People have skin in the game because they got to vote about what is being discussed
  4. Time boxing helps to keep the meeting from getting stale and boring.
  5. The proof is in the pudding. Some of the best conversations I’ve every been a part of have been while using the Lean Coffee format.

Examples of when Lean Coffee may not be the best idea:

  1. You have a very specific agenda that needs to be adhered too.
  2. There’s only 2-3 participants in the meeting.
  3. You are talking with customers or the participants may have never heard of lean coffee.
  4. Your participants are knowingly “anti agile”.
  5. If you know the majority of the participants of the meeting are not typically not inclined to talk in a group. Dominating personalities will control the conversation and others could become bored and find it a waste of time. (with the right coaching this risk could be avoided)

Need more info still?  Here’s a great video showing a sample lean coffee meeting.

How to measure success in an Agile organization

**Re-posted from https://www.slalom.com/thinking/how-to-measure-success-in-an-agile-organization where this article was originally published.

Any organization adopting Agile faces the challenge of figuring out how to measure success. “How will we report to executives?” and “How can we standardize reporting across multiple teams?” are some of the first—and most important—questions that pop up. Answering these questions without compromising the spirit of an Agile transformation is critical to adoption.

Why? Because every metric you put in place will generate some type of behavior, be it positive or negative. That’s why it’s imperative to exercise a vast amount of diligence when working to define your metrics.

In the world of Agile, success can look very different than it does in a traditional Waterfall, fixed-scope environment. One of the cornerstones of Agile is to work on what’s most important to the business and deliver value as soon as possible. Here’s an example: the team goes into a sprint or release and commits to completing five items. But after work begins, the team learns that the number-one priority will require much more work than expected due to new requirements or bugs discovered during development. Poor planning isn’t to blame; the team just has to make adjustments based on new information. Everyone agrees to focus on the number-one item to complete by the end of the sprint, leaving items 2-5 unfinished. They refocus, successfully complete item number one, and deliver it on time. But the team only delivers 20% of its expected scope at the end of the sprint.

To many Agile teams, this could be considered a complete success, because ultimately the percentage of original scope isn’t as critical as delivering on what’s most important. So in this scenario, the traditional measure of committed vs. completed can be a poor measuring stick.

Let’s look at what could happen if the success of this team was measured by what it completed. The team learns that good numbers are more important than delivering on the top priority. They then start padding their estimates to ensure that they have plenty of time to finish without any risk of backlash. Now you have valuable energy being wasted on navigating a process rather than getting things done. You’ve invited some of the more negative aspects of the Hawthorne Effect to come and run rampant on your project and team.

For an Agile organization to be successful, there has to be a general assumption that people are working hard and want to do their best. The role of a good leader is to enable teams to work smarter, not harder.

Here are seven traditional and not-so-traditional ways to measure the success of your Agile team.

1. Measure teams rather than individuals. A study conducted by Team Builders Plus found that “individual performance data are of less value (judging from the ratings and number of organizations tracking it) while team data reinforces collaboration and problem solving.” Collaboration is a key part of any Agile team that focuses efforts on the outcome of a project rather than a single person’s output.

2. Keep track of the percentage of the highest priority items being delivered. If your team’s focus is on delivering what is most important first, you can keep track of this trend over time. If the team is always delivering on priority two and three, but missing number one, you can use it as a coaching opportunity to help increase collaboration.

3. Measure the team’s satisfaction. You can be leading a team that is delivering at a high level, but if they’re miserable, you’re in a dangerous place. Part of a team’s success is the overall satisfaction of its members.

4. Evaluate your software. There isn’t a universal solution for determining if you have “working software.” Some of this relates back to customer satisfaction, but you could also measure if the work being done is truly solving problems—or if, in fact, it’s creating more.

5. Show the business value delivered. This may require more work up front, but if you have an idea of the value for a particular story or project, you can tell the story of the value that was delivered.

6. Provide a narrative, not just data. Why spend time collecting, packaging, and sharing data that really has no bearing on a team’s success? Sometimes even providing 3-4 sentences can give much more useful information than a pie chart. Visualization of data is definitely a good thing, but think carefully before defaulting to visualizations.

7. Measure anything the business says is important. Easier said than done, but as a guiding principal, focus on what the customer is saying is important. If they only care about 2-3 things, why give them 15?

Now you’ve got the metrics, but what do you do when ground forces at the executive level are resistant to Agile? First off, don’t react when people are critical or have a different perspective about what should be measured. You’ll be more successful showing people how Agile can enable the metrics they want.

Of course, there’s still a chance you won’t be able to reconcile the expanse between the pro-Agile and anti-Agile parties. In VersionOne’s annual Agile survey, 53% of people said an organization’s inability to change its culture was a barrier to adoption. There’s no silver bullet here. Another revealing statistic from that same survey was that 35% said trying to fit Agile into a non-Agile framework was a barrier to adoption. The research speaks for itself:you can’t always expect the metrics that work for a Waterfall project to apply to an Agile project.

The workplace is full of spreadsheets and databases, amassing ever-increasing amounts of information. With that, the definition of success—specifically in information technology-centric groups—has changed dramatically over the last 10 years. I’m a firm believer that success in its purest form can be measured by how happy your customer base is with the product or service you provide for them. That’s why the Agile Manifesto emphasizes “individuals and interactions over processes and tools.”

Brainstorming, Story Boarding, and Retrospective Tool – IdeaBoardz

This week I was talking with some fellow colleagues about starting a Lean Coffee for our organization.  We have a national (soon to be international) footprint and a ton of knowledge out there, but how to bring it together?  So I thought the lean coffee meetings would be a great way to bring people together to inspire, encourage, equip, and empower each other. It could also create a consistent venue where we can work together to solve challenges for our clients.

I had a few different people suggest using a tool called IdeaBoardz.  I want to share this tool not only because think it will be great for Lean Coffee but it has value for things like brainstorming, story boarding, and retrospectives.  Especially if you have co-located teams.

It’s simple to use and has just enough functionality to make it useful. And best of all…it’s Free!

You can take it for a test drive without having to sign in or create an account.

IdeaBoardz

Please Note I am in no way affiliated with IdeaBoardz and receive no compensation for writing this article.