Category: Software Teams

Communication on Lean/Scrum/Pairing Within Software Projects

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.

Cutting Teeth, Software Projects, The First Two Weeks

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.

  1. What are the most basic concepts of the application story needed to get started?
  2. What should be assumed to be complete based on that after 1 week?
  3. 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.

Go to Sleep

This entry is from some notes I’ve taken while reading the book Rework.  Considering my recent write up “Don’t Give me Rework Refusal!” one may consider me a supporter of the ideas presented in the book.  Out of all the books I’ve read recently, this one is definitely on the top of the heap of “things to do to succeed”.  Great book; simple, to the point, great real world examples, and shows a keen understanding of the larger business world as well.

Go to Sleep

In the section titled Go to Sleep I thought of some additional stories and events that I’ve experienced in the past.  These experiences helped me to realize the difference between me on good sleep and me on bad sleep.

Push These Chairs

One of my team leads for a team I worked with years ago stated to me, “If you come in tired, you’re useless to me, except I could get you to push chairs around.”  We had a good working camaraderie so I just laughed it off, until I came in tired one day.  Eric P. saw me plugging along yet could tell I was kind of in a dirge.  He said, “Hey Adron, see those chairs?  Could you go move those chairs over to that part of the room?”  I looked at him quizzically thinking, “I’m a software developer, you want me to move chairs?”  Then I thought back to what he had said and I realized I was tired and it showed.

🙁  Not cool on my part, I was bummed.

I realized what he was making a point of and asked if I should just head out and get some sleep and come back nito the office?  He said that would probably be best, as the team really needed to be 100%.  We were all tired a little bit, but crunching and coming in the next day sloppy tired wasn’t helping project velocity at all.  So off I went to get some sleep.

In the book Rework the writers point out some key facts of the tired:

  • Stubbornness
  • Lack of Creativity
  • Diminished Morale
  • Irritability

I wanted to add a few myself:

  • Negatively Contagious
  • Misdirected
  • Oft Confused

A negatively contagious individual affects those around with a bad vibe.  Often making even those that aren’t tired, feel and act like it.  It makes the day of work more difficult and diminishes their morale as well as the tired individual’s.

A misdirected individual fits into the whole “useless” category.  Sure, they can move chairs around as my Team Lead Eric P. proved, but beyond that a tired programmer isn’t a programmer, they’re a chair mover.

A oft confused person comes to work tired, attends meetings or other high cost events during the day and adds to the confusion instead of adding clarity.  This affects these high cost events by making them even more high cost and less useful.

So if you heed the advice in the book, which Eric P. and I reiterate, GET SOME SLEEP!!!

It Brought a Tear to My Eye, Agile Ideals Rock!

I’ve been leading a software development project for a little over a month, one of my team members and I have been communicating back and forth steadily.  Via IM or verbally, e-mail or however we need to.  We’re having a good time figuring out things as they come and getting things done in a very Agile way.  To lay it out as the manifesto is written;

We keep ourselves and interactions over process and tools.  We make sure to have working software on almost every single build that could literally be deployed, while forgoing the currently unnecessary documentation.  We collaborate constantly with the customer representative and don’t worry every minute about the contract negotiation.  Response to change is almost instant, as it comes along almost every day.

As we’re hustling along getting a complete vertical implementation of a project together this coworker comes to me and states, “It is great to work on a project with someone that knows what they’re doing, and not sent off in a corner to read documentation books on what was done in the past!”  That statement made me so happy.  This is one of the major reasons I advocate Agile!

Agile helps team members get bought into the project.  The team gets involved in ways that other processes just don’t allow.  The team feels enabled, empowered, or whatever one may call it to actually get the job done!  Being Agile isn’t about process or tasks or work items, being Agile is a mindset, is about being interested and involved in what you’re doing for your project.

After a dirge of conversations and some frustrating efforts recently, this is the type of thing that leaves those negatives in the dust.  This is the type of statement and motivation, when I see it, that makes me love what I do and love to come into the office each day!

So anyway, I had to make this post.  Because today, even though I thought it would be a slightly miserable day.  That one statement redeemed it and my day is now rocking!

Waterfall vs. Agile

Before reading this you should know what the Agile Manifesto is and the Agile Principles are.

I’ve seen it on more than one project in my career and it always seems to happen.  Agile rarely gets credit in this scenario.  People rarely learn what was and was not effective on the project in this scenario.  Those that are Agile Practitioners that know what a truly fast paced, effective, high quality, and successful software project can be know.  What I’d like to know though, especially from those that have successfully dealt with the “Must have big design up front (BDUF) headaches” and transitioned those people to a more Agile style approach.

The scenario generally starts like this…

A project is green-lighted for whatever reason.  Often with some high level manager determining that a project will save or make $X amount of money.  The project is poorly defined or simply not defined at all.  The stakeholders, clients, or others that would prospectively use the software are nowhere to be found and unidentified by management.  There are at least a half dozen external dependencies the project must have completed.  (Take Note Upper Management & Executives:  Six Sigma/Lean Processes can help at this level dramatically)

Waterfall Approach

In a waterfall approach all of these things will have to be documented and nothing initially gets developed.  The people writing the documents, often some sort of business analyst, is forced to basically make up whatever they can come up with.  In addition to that and hypothesis is derived from thin air and someone starts to come up with a more functional, technical, or even concrete UML design documentation.  To summarize, in a waterfall approach a whole bunch of people start documenting all sorts of things about this theoretical application software.  A 6th grader would study this and say, “so they write a bunch of lies right?”

When the actual concrete ideas come to fruition, long hours of the famous death march approach usually start.  Sometimes more and more people are thrown at the application in hopes that somehow it will speed things up, but in reality as a seasoned software developer knows, it only slows them down.  Other issues very common with this approach are horrifying low code quality, a lack of tests, missing ability to regression test, no verification of what done truly means, and a whole host of known issues.

Agile Approach

An Agile approach on the other hand would start finding the clients and consumers of the theoretical software.  These people would be engaged and some paper prototypes or other initial sketches of what the software might do are created.  Maybe sketchflow or some other software is used to create some rapid prototypes to give the clients an idea of what the software would look like and what it might do.  The clients start giving feedback and a more concrete idea is formed around this theoretical software upper management has dictated.  Initial tests and code are written and put into a continuous integration process, with an end product being dropped every few days or weeks.  A 6th grader would study this and say, “you’re building software and having fun?”

What Happens in the End, IF the Waterfall Project is Successful

There seems to be two resolutions that I’ve found that allow Waterfall to actually be successful.  The first is that the project forgoes the charade of Waterfall and starts implementation of more Agile ideals and processes immediately.  This cleans up things and improves morale, all while getting the project back on track.  The second solution is that development/engineering determines they’ll do Agile anyway, and up manage the management.  Management thinks they have a successful Waterfall Project when in reality the proactive developers/programmers took it upon themselves to assure success, and thus moved to an Agile ideals, process, and practices among themselves.

In Summary

These two different models are HUGELY disparate, and yet the aforementioned waterfall model approach is still heavily used.  I suspect, unfortunately, that it is primarily used at a majority of businesses (and especially Government).  Even if the business or Government pretends they’re doing Agile and calls their Waterfall Model Agile something another.  This is something else I’ve seen far too often.  This is a complete misrepresentation of what Agile Ideals and processes are.

The Questions

I’d like to know, what methods do you use to attack and remove the barriers caused by waterfall at large organizations?  Do you subvert the existing management infrastructure and just do things in a more Agile way regardless in order to succeed?  Are there any specific practices, techniques, or otherwise that help you align so that one can keep a project moving along quickly, all while avoiding the damage waterfall models do to the actual underpinning project, code quality, and other such items?

Please leave a comment or three.  🙂