I’m stepping into a role right now, which I announced recently “Career Update: Back to Engineering!“. In that role I have a number of key topics and knowledge specific to the role that I need to attain. Most of this is centered around the current state of teams, members of those teams, work in progress, product, and service status. The following are some of the important steps I’ve taken to reconnoiter the current state of things. These steps I’ve taken to get up to speed as quickly as possible! Continue reading “How to Reconnoiter a New Role!”→
Over the last few years I’ve contributed to, organized, worked with, and been in the audience of hundreds of user groups throughout Portland, Seattle, San Francisco, and Vancouver BC. By far, this area of North America has the most active, resilient, and density of thought leaders in the technology world. There is something missing however and I’d like to start working toward filling this gap. What’s missing you ask?
Problem: People often get together and talk about tech, but rarely get together and do something about tech.
The vast majority of user meetups end up as presentations. I must sadly say, often boring presentations that don’t really teach or demo all that much. Attendees often just come to talk afterwards or otherwise socialize, which is hugely important to the community. However there has to be a way more could be done. A better outcome would be to create a two way conversation, instead of the one way presentation, and to involve ourselves in creating solutions, new technology, and idea. In a few rare situations I have found groups that do something about this void. What’s their solution?
Solution: They actually get together, implement code, pair, and work together on problems. Kind of like a Hackathon, but way more often.
That’s what I’d like to create. To start off with, I’d like a group that is technology agnostic, is fairly skilled yet willing to pair and bring others up to speed, and simply gets together at least once per month to implement a specific project or effort that is predetermined by group submission and conversation (i.e. we’ll use a google group, e-mail list, or such). I think, and feel like there is enough support to get something like this started in Seattle, Portland, San Francisco (especially here), and Vancouver BC. My question is though, would you be interested in helping out, coordinating with me, and otherwise uniting coders to do more, learn more, and better themselves?
If you are interested, please leave a comment and help me out by answering a few questions:
Is “Coders United” a good name for the group? What ideas do you have?
Do you have a project or three or four that may be of interest for a group to get together and work on?
This type of group would probably need to meet for more than an hour, would you be able to meet for 3-4 hours, maybe even on a weekend to implement a full project?
What’s your preferred method of contact (e-mail, twitter, facebook, text message?) and how should I get in touch with you?
Big enough title? Meh, that isn’t really related. 🙂 Please read on.
The latest little blurb back and forth in the ALT.NET Community on the ALT.NET Seattle Google Groups thread is about retrospectives and how to increase quality. I won’t post any direct messages but wanted to blog a bit about that.
My fellow coworker Eric Ridgeway mentioned, which I whole heartedly agree, one doesn’t wait until the end to make quality improvements. One focuses on quality at all times. This makes me wonder sometimes were the disconnect is for quality improvements. Even when asked sometimes, I’ll state something that is so simple as “always focus on quality” but then have follow up questions such as, “so when should we focus on quality?”
How did that not translate? I get lost when I get a statement made back as a question. I just stated the solution, the solution is to always focus on quality. When you write a test and watch it fail for lack of implementation and then implement it look to see if it is elegant. Look for the quality of logic and code usage. If it looks odd try to refactor it. If something is just being changed, check the quality. If you’re white boarding, ask yourself if you should be trying out some implementation instead of just white boarding. If you’re implementing but it doesn’t seem clear, ask yourself if maybe a white boarding session will work. If you find your daily process is hampering clear minded efforts to develop good software solutions, ask why the process is low quality and what would make it higher quality. If your team has low code coverage, or heaven forbid no code coverage, don’t wait, start doing something immediately. Stop non-quality development and start high quality development.
It really is that simple. There is no way that should not translate. Always focus on quality.
While reading this blurb on the ALT.NET Google Groups I got an alert for Rob Hirschfeld’s latest blog entry about Agile & Cloud Computing. In his latest blog post titled “Black Hat Feedback Essential For Cloud Success” he dives right into the process improvement and retrospective conversation. Rob points out a few reasons teams skip on improvement:
All that talking and listening and improving takes time and attention.
Post Mortem or “lessons learned” meetings that never make any difference because they happen after the work is done. (well, duh).
No one has a methodology that makes the meetings productive.
Lists with more than 3 items on them have too many items to be productive for improvement activities because of reader’s limited attention spans.
One of the quotes he pulls from Lean Agile advocates Mary Poppendieck and Eric Ries addresses this, “The secret to improving your performance is to regularly work to improve your performance.” This goes back to what Eric, many others, and I keep saying, “always work on quality, don’t wait until the end”. If you wait until the end, it’s already too late.
Communication is important. Communication is even more important in projects using lean, scrum, or other agile ideals than in other projects. Mainly because of the rapid, refactoring, and pairing nature of the project process style. This truism lead me to think, “hey, I ought to write up a short blog entry about some effective methods of communication within teams”.
These are just a few scenarios where an effective communication was introduced during a project with great success.
Public Realtime Chat Forum/Room
On one of the projects I worked on a very successful communication practice was to use a public realtime chat using Yahoo Messenger (of course one could substitute with whatever instant messenger client). Each 3-8 person team would log on and join the group chat. This group chat was used for a number of very specific communications that needed instant, but non-interruptive communication.
Road Blocks – If someone ran into an architectural, build, or other road block the entire group would quickly review and knock the road block down. This could usually happen in seconds to a few minutes. Rarely did a road block ever exist for more than 10-15 minutes.
Levity – Someone would throw a geek joke out every once in a while or toss a little tech news tidbit into the chat. Often around lunch time or such. This would lighten the mood if things were getting a little intense around deployment time.
Scheduling Notification – If a meeting was coming up, considering the speed and focused approach this enabled, developers would often not have Outlook up to be interrupted by so meetings may have been missed. Usually the lead or project manager would keep up with these scheduled meetings and pull the team into them with a simple chat mention. This helped by reducing the avenues of interruption while the team was focused on problem solving and coding.
Pairing Request – If a developer ran into a tricky business logic, or other section of code they were trying to put together, one could request a personal chat or in person pairing to get the logic figured out and have the double check of a pair. This really helped improve the quality of code and architecture and time to resolution around really tricky parts of code.
Sketchflow Workshops
I’ve dubbed this communication the sketchflow workshops, when in reality this process was an attempt to recreate paper prototyping as best as we could without onsite visits. I’ll mention before continuing, that absolutely NOTHING takes the place of in person communication when doing paper prototyping. So here’s my analysis, with that clause, of how these workshops worked out improving communication.
An online medium with video, white boarding, and sound was used to provide as much interaction as possible. The application prototype/mock up would then be shown and the team and client would white board, discuss, and point out UX & UI changes or additions that were needed.
The white boarding of the app provided a means to quickly sketch out ideas, somewhat similar to paper prototyping.
Note taking was done actively in a group chat while people discussed & drew on the white board or presented the prototype/mock up.
There are a few things I would have added, that are now possible with newer tools, that would have improved this process even more.
Using SketchFlow w/ Expression Blend to make actual changes to the prototype/mock up would have been very useful, and easy to do with this toolset.
Using the deploy static site with feedback tools that Expression Blend enables would have also been useful to act in addition or in lieu of the white boarding medium (it was slightly cumbersome vs. real white boarding).
Video of people & video of a real white board would help dramatically. These two additions could actually bring this type of communication almost on par with actual paper prototyping.
That’s it for this entry. If you have any other specific communication tools, mediums, practices, or otherwise I’d love to hear about them. Tweet, e-mail, or leave a comment for me if you would.
A few questions came up recently that I wanted to answer, but before I answered I wanted to post them to see what others might think.
What are the most basic concepts of the application story needed to get started?
What should be assumed to be complete based on that after 1 week?
After 2 weeks are up, what could or should be delivered for a MVP (Minimally Viable Product)?
Ideally speaking development wouldn’t start until one has done a few paper prototyping sessions and written up a number of user stories. Often though just a minimal amount of things actually need to be known. My immediate answer to, “what is the most basic concepts of the application story needed to get started?” would be,
A simple story around the core prospective user of the application.
An example would be a story along these lines. Since I’m the user in this case, I’ll use “I” instead of “the user”.
I would like to access the application from anywhere in the world. I would like to have secure storage of my writing. I would be able to add writings to this storage. I would be able to delete writings from this storage.
That seems to be enough to build an extremely basic thing to store writings. Should someone need more than that to start creating something? Should someone be able to create a full fledged application? Sure, but without more work sessions and further stories to expand on the idea, I wouldn’t expect it to be what I was envisioning. I would simply expect something to be scratched out that we could start to work with. Something that would create, expand, and provide a better base of ideas in which to work with.
That’s the basis for this blog entry, what would you expect after one week and two weeks? Think of the ideal circumstances, with continual involvement with the developer and the customer. The developer being very familiar with the tools they’re using and the customer being very familiar with their particular business domain.
Thoughts? One week and two weeks. I’d like to see others’ thoughts on the matter.
You must be logged in to post a comment.