Tag Archives: agile culture

4 Ways To Make Your Meetings More Meaningful

If you’re reading this, and you work for a company that does …anything…chances are that you hate meetings. You find them wildly unproductive and time consuming. Janet forgot to mute her line again, Karen and Bill are never on time, Debbie always wins the award for loudest snacker, and Bob is clearly working on other things.

This is a vicious cycle that results in more meetings! Don’t believe me? Check out my highly technical graphic of a typical workplace meeting…

Here’s the good news! You can break this cycle. Need to call a meeting? I encourage you to try one of these collaboration techniques below. I think you’ll be pleasantly surprised with the level of engagement and outcomes from your meetings.


For the meetings that run too long.

Ok, so this first one isn’t as much of a collaboration technique…it’s really just logical. Let’s say you schedule your meeting from 2pm to 3pm. Have you ever actually gotten a full hour from that meeting? No. My guess is that you got 40 minutes at best.

Meetings are instantly less frustrating once you realize that it involves other humans, who have human brains. It is unrealistic to think that your coworkers are high-functioning robots and will show up right at 2pm and leave the second the clock hits 3pm.

Instead of getting mad at people for being people, schedule your meetings differently! If you know that your group usually runs 15 minutes over, schedule the meeting until 2:45, but book the room until 3. That way, when your group inevitably goes over the time limit, you’re getting the conversation you expected, but you’re not interfering with the group who has the meeting room next.

If your group tends to show up a little late, account for that time when deciding what you want to discuss. Then you’re not forcing an agenda that is too big for the actual time available.


For the meetings that have way too many people.

This is for those of you that have realized there are just way too many people in the room. This is usually because the person calling the meeting wants a lot of different opinions, or there are a lot of people that are insistent their presence is absolutely necessary. The good news is, this is typically out of good intent…everyone wants to be involved!

The concept is simple. It’s called Fishbowl Discussions and it’s taken directly from classrooms. So if it works with hyper and distracted children, it should be no problem for your co-workers. Basically, you have a group of anywhere from three to five people that are ‘in the fishbowl” In reality these people may be at a whiteboard, in front of a computer, or at a table. Throughout the meeting, they are the ones talking to one another and working out the ideas.

Everyone else is outside of the fishbowl. What can you do outside of the fishbowl? Show up late, leave the meeting altogether, check email, think of things to contribute to the meeting, daydream… anything nondisruptive really. What can’t you do outside of the fishbowl? Talk.


For the meetings that wander off in a million different directions.

It always starts with good intention… “Not to change the subject completely, but I think that it’s important to note…” Too late Jody! You just changed the subject! If this seems to be a common occurrence with your team, maybe it’s time you give LeanCoffee a try.

LeanCoffee is described as a “structured, but agenda-less meeting” and it really is effective. Actual coffee is optional. The core of this meeting style is very democratic in nature. Together, we decide what we want to talk about, and what’s most important to discuss first. It starts by setting up a very simple Kanban board. It is nothing more than 3 post-its that say: To Discuss, Discussing, & Discussed.

To kick things off, everyone attending the meeting silently brainstorms for about 2-3 minutes on topics they think are important. The etiquette is one idea per post-it. After that, everyone has the chance to pitch their ideas. Try to keep your pitch to 2-3 minutes, or else you’re kind of missing the point…

Once everyone gets a chance to pitch, we get to prioritize. Everyone gets 3 dot votes. Dot voting is a ~very complicated~ process. Ready for it? You draw dots on the posts its you want to discuss. You can even allocate all three of your dots to one idea if you feel it truly is the most important.

Finally, it’s time to actually start discussing your ideas. You start with the one that was voted most important and set a timer for seven minutes. After seven minutes, everyone silently gives a thumbs up or a thumbs down. Did most people give a thumbs up? Great that means the room feels good about the topic and we can move on. Did most people give a thumbs down? Set the timer for two more minutes and let the discussion continue. Re evaluate the thumbs up/down after the two minutes. Did someone try to put a neutral thumb? We will count that as a thumbs down.

The most important part here is after the meeting is complete. It’s the last sip of the coffee. Discuss your takeaways. After you’ve gotten through the topics, it is important to come back together to gain shared understanding.


For the meetings where someone’s idea always gets shot down.

Everyone has been in that meeting before. Someone has an idea with serious potential. If only you didn’t have Negative Nancy in the back corner giving 100 reasons why there’s no way it will ever, ever, … ever work. That negativity can spread pretty quickly. Next thing you know, a potentially great idea was shot down before it even had the chance to work.

This is where 6 Thinking Hats comes in handy. The concept is pretty simple. We all put on a “hat” of the same color at the same time. Different colors represent different mindsets. For example, when we all have the white hat on, we are only allowed to discuss factual things about the idea. This would include data, information, what we know, what we need to learn etc…

Now to do this, you need someone to make sure the process of 6 Thinking Hats is not being violated. If a team member starts to talk about their feelings when we are supposed to be discussing facts, the appointed “process person” is responsible for saying something along the lines of “that’s a great point, let’s save that for when we are all wearing the red hat.”

Each hat has a different, yet important purpose that allows conversation to flow more smoothly and allow for fully understanding an idea or problem.

When using 6 Thinking Hats, you’re allowing the conversation to flow in a manner that actually makes sense. No longer are you sitting in the room wondering what the hell is going on and how we got here. When everyone is thinking in the same mindset at the same time, it allows us to think in a more analytical manner collectively.

So, if you’ve made it this far, I assume you hate the way your meetings are currently run, and maybe you’ve gotten some improvement ideas. The challenge is to actually try something new in your next meeting. Remember… insanity is doing the same thing over and over again and expecting different results.

If you don’t actively work to make your meetings more productive, you can’t expect anything to change. But hey, at least you have Candy Crush on your phone when the meetings get too unbearable.


6 Tips To Designing Effective Information Radiators


Your team space should deliver a message

Recently I’ve been helping a new team setup their team space. Now, I’m a big fan of hanging stuff on walls. Big visible stuff. But there’s more to it than that. When deciding what you should put where you are actually crafting a message to anyone that walks into the space.

My personal metric for knowing when you’ve done this effectively is to answer the following question: Does it change someone’s mood?

In my opinion, when anyone walks into your team space, from the newest dev to the most senior executive, what’s hanging on the walls should make them feel differently within a matter of minutes. If that doesn’t happen, something’s off.

Now I’m not advocating that teams throw a bunch of crap up to simply appease people, especially those not usually in the space. In fact, the big visible stuff should be minimalistic; the least amount of information required to paint a deep, rich picture of what is going on, what value is being added, when things are happening, and anything else that is useful.

I’m not going to go into what specifically any of the stuff should be. There is tons of information out there on that such as information radiators, styles of team boards, card maps and lots more. Instead, I encourage you to think about the message you want your space to convey.

Here are a few things to consider in addition to the actuall stuff you choose to hang up:

1) If it’s hanging up, make sure it’s actually big and visible 

Sometime I wish plotters were never invented. Release burn-down charts and code coverage trends are examples of useful things to hang up. Too often though, I see people (usually PMs with whiz-bang tools) print them out. I assume they do this because they think it’s easier, but walk across to the opposite side of the team space and tell me if you can read it…all of it. It’s not enough to see the trend lines if you don’t know what the chart is trending or what the axes are. Instead, draw it out on some paper or a white board with a big fat marker. Now go walk across the room…yeah, betcha can read that!

2) If it’s hanging up, make sure it’s useful

like to think of this as pruning. Something that was once useful may have run its course. If so, tear it down. If you need it later, recreate it. However, before just tearing stuff down, make sure the whole team agrees that what ever it is is no longer useful. When in doubt leave it up, there are usually ways to make more room if you need it. It’s also important for the team to consider organizational usefulness. Not everything will be the most useful to the team itself, but sometimes to managers or other stake holders. PMs like release burn downs and cost burn-ups, CFOs like value stories etc… These should not dominate the space, but they are still useful, and it’s important for the team to understand their organizational usefulness as well 🙂

3) If you need something useful, make sure you hang it up 

The space is not a fixed thing. Obviously if we can tear stuff down we can put new stuff up. The process of software development is journey or learning and discovery. Visualizing different things along the way can help a team communicate, both with each other as well as those outside the team. If you think something might be useful, hang it up for a while, try it out. If it doesn’t add the value you thought, ask how it can be improved. If after a while it is still not providing value, see #2.

4) If it’s hanging up, make sure it’s in a good position 

Not all wall space is created equal. This could be due to many things such as lighting, vantage point, furniture arrangement etc… The best thing to do is plan a little bit before you hang something up. How often will it be updated? Is it a conversation centerpiece? Should it be visible to a passer-by? Once decided, go hang it up. If things change and it needs moved, move it…it’s only paper and tape right?

5) If it’s hanging up, take pride in making it

Remember, you are crafting a message. You want things to be visible, digestible and useful. Those traits can be hard to achieve if your big visible stuff looks messy, half-assed or cluttered. It doesn’t take that long to use a straight edge instead of free-hand drawing. Create a color scheme of post-its or stickers. Use different size index cards to mean different things. Create a legend. It doesn’t have to be a work of art, but it should be tidy (within reason) and professional looking to communicate your message effectively. If you think something has gotten too messy over time, clean it up or redo it…it usually doesn’t take very long.

6) If it’s hanging up, it’s a living document

Don’t be afraid to enhance anything that’s hanging up. Feel free to draw, stick stickers, add post-its or whatever else adds value. You can usually tell which documents (big visible charts) a team find the most useful by the amount of enhancements made to it!

Finally, don’t forget to test this stuff out when you think you are done. Stand back from your space and look at it. What does it say to you? Stand in the doorway or hallway and look in. What does it look like from there? Have people from other teams walk through. Is there anything that is unclear to them? Ask a manager, director or executive to walk by. What were they able to tell by just looking? Maybe do a few of these every now and then as your space evolves with different stuff.

Ultimately, don’t forget that original question from way up there: Does it change someone’s mood? Folks should feel better about what the team is doing, where the project is headed, and what they are getting for all the team’s effort. If this is the case, then you’ve successfully crafted both an effective team space as well as an effective message.

This post was originally published by the Matt Barcomb on odbox.co and was reposted with permission. 

Preaching To The Choir


Recently, I was giving a class and during a portion of the class I discuss some of the cultural changes usually required for organizational progressive elaboration of work. During the break that followed this particular discussion, one of the attendees came up to me and said:

“Seems you’re preaching to the choir here. We all agree with what you’re sayin’…but it wont do any good unless we get the managers in here.”

While I certainly understand this reaction, and unfortunately find that it’s not that uncommon, I still find it a bit disheartening…and a little frustrating.

This attitude of “I can’t change the things that influence me”, and “what I can control isn’t big enough to really change anything” is entirely the wrong attitude.

Changing the things that you can control, no matter how seemingly insignificant, should never be down-played. One can always take complete control of their own actions, behaviors, and reactions. Combined with a little learning and a bit of creativity this can become very powerful indeed. So, try changing the things you can; the things over which you have direct control. Share what you’ve tried, what you’ve learned, what worked well and what didn’t. Share up, share down, make it visible, let people ask about it and then share with them too. Eventually this can influence up, down, and across the network of an organization.

Sometimes it only take one person to make a significant change. Other times it spreads slowly before snowballing into a major organization shift. And many times making a “major” or “significant” change isn’t even needed. Sometimes it’s the little things that count.

So, the moral of the story is that even the choir can use the message, and even the choir is able to go out into the world and try to make it a better place through their own actions…and employees who think their organization could be better are just as much on the hook for trying to improve it as the managers and executives are.

This post was originally published by the Matt Barcomb on odbox.co and was reposted with permission. 

Professional Development Hack Days at LeanDog

There are a number of fields in which ongoing professional development is not simply a job requirement, it’s the only way to stay relevant in an industry that is perpetually evolving. The highly technical world of software development is no exception. Coders, designers, and engineers of all programming languages must continually update their skill sets just to keep pace in a field where technology evolves seemingly overnight and market trends are constantly shifting underfoot.

As essential as this constant professional improvement is for the individual developer, it is absolutely critical to the survival of a software studio. Design and delivery studios depend on competent, creative, T-shaped craftsmen to drive innovation and produce cutting-edge products. However, in busy shops like LeanDog, where developers are routinely tackling complex scenarios, it can be a challenge to find time to pick up a new skill or enhance an existing one.

So how do you help your development team diversify their skill sets when client demands dominate the majority of their time? One way is for leadership to actively create opportunities to learn something new in an environment free of the pressure to “get it done.”

So that’s what we did! Last Friday, the LeanDog Studio took a break from their many projects and joined forces to try something new: a Professional Development Hack Day.  This session had three overarching goals:

1) Learn something

2) Share Something

3) Have fun

Prior to Hack Day, the Studio came together and pitched nine project ideas. They then took a vote and ended up choosing four to pair on:

  • Unity as a rapid-prototyping tool
  • Indoor navigation with iBeacons
  • Deployment pipeline with Docker
  • Conference outline – UX Survival in Agile

After the monthly company meeting, studio members teamed up with co-workers they are not normally pairing with and spent the next four hours “nerding out” (a highly technical industry term) on their respective projects, the summaries of which are listed below. At the end of the day they regrouped for a Show and Tell and voted on which project took “Best in Show”.  Everyone had a blast and learned some pretty cool stuff in the compressed (but relaxed) format.

The Projects:

Unity as a Rapid-Protoyping Tool

Will Kesling pitched this idea to look for alternatives for prototyping game mechanics and solutions.  Our current tool for this is Gamesalad, which makes it easy to build quick prototypes, but limits our ability to modify the generated code for our purposes.  The goal of this session was to attempt to build a mini-game that would better suit our current prototypes.  Will Kesling, Bill Holmes, and Eric Hankinson teamed up and found that Unity was a very cool and powerful tool.  They built an interactive 3D world with converted 2D objects.  It was great to be able to write C# to handle some mechanics.  However, Unity is not well-suited for rapid prototyping.  The team suggested looking more into 3D Unity as a production-level framework and perhaps trying again with 2D Unity to see if it’s a better fit.  The team recommended starting with the asset store when you start a new Unity project. 

Indoor Navigation with iBeacons

Gary Johnson pitched the idea of mapping the boat (our office) and using locators on people and items.  Besides being cool, exploring this technology would help us understand installation type projects, like museums and trade shows.  Mike Kvintus, Nick Barendt, Paolo Appley, and Carl Shotwell ended up teaming up to map the boat using the estimote beacons we had on hand.  The team deployed the beacons, mapped the area, and started a swift app to display locations.  They found the estimote service and SDK to be difficult to use.  The software was buggy, slow and inconsistent.  Additionally you need at least 4 estimotes to map a room and they come in packs of 3.  The estimote mapping software was not a big fan of the irregular shape of the boat.  The team suggested getting more beacons to see if a larger area could be mapped and investigating alternative iBeacon technologies.

UX Survival in Agile

Nicole Capuana pitched working on a conference talk for Codemash that would describe how UX best fits into Agile Software Development.  The ultimate goal is to create a talk that would be reusable with multiple perspectives.  Steve Jackson and Charlotte Chang joined Nicole on brainstorming and talking through ideas that would make this a useful guide for UX practitioners in multiple uncomfortable situations.  The team also worked on a talk Charlotte is preparing on Software Development Lessons Learned from Industrial Failures in the 1980s.  The session was very productive and the team recommends that all speakers try to get differing perspectives for that post-abstract phase.  This collaboration helped raise the bar on what a really excellent audience experience could be.

Deployment Pipeline with Docker – “Best in Show”

Nathan Wallace suggested building multiple environments with Docker and testing each one with our continuous integration server.  If successful, this would apply to many of our current projects, allowing us to easily build and deploy new fully tested environments for all of our integration points (along with our tested code).  It also has the potential to reduce our need to configure and setup environments for our CI itself.  Nathan and Chris Nurre teamed up and were successful in building a Docker image for a vanilla rails install. With each pushed commit, a new environment was produced.  The team found that installing Docker on our heavily mac-based infrastructure was difficult, but was otherwise happy with the tool.  Their recommendation was that all of our web-based projects should default to using a Docker file for CI and that it would be useful to further investigate the Jenkins-Docker integration, as well as deploying the images using a Docker registry.

By taking a small break from “getting it done” and creating an environment focused solely on learning something new, we were able to provide everyone an opportunity to relax, expand their horizons, and bond with their co-workers. Overall, LeanDog’s first Professional Development Hack Day was a rousing success and the team is looking forward to coming together next month to do it again.