Tag Archives: agile culture

6 Tips To Designing Effective Information Radiators

SWRREC0K3A

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

church-choir-408412_960_720

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.

tumblr_inline_nx7cuomCMg1tc23o0_540

tumblr_inline_nx7cuoxAdW1tc23o0_540