Agile - High Bandwidth Communication

As you can tell, I have focused lately on Agile project methodology.  It is one of those things that is currently in vogue.  Will it last?  Will it be the panacea?  In some enterprises it has been successful and will remain so.  Others have had mixed results.  It will persist in some form for some time. 

One of the big promises that Agile advocates is the premise of 'high bandwidth' communication.  Adherents push for in-person, face-to-face communication amongst team members and stakeholders.  This is often done by putting everyone into a room and turning the team loose.  They are supposed to self-organize with a scrummaster guiding the way.  Under some circumstances this is a very powerful and productive way to build systems.  In others,  the jury is still out.  An interesting thing to watch will be how SOA and Agile work together in the future.

From a management perspective, putting everyone into a room to foster team spirit, communication, etc. may be a panacea or a minefield.  Two issues arise that I have seen in such situations.  One,  rarely do the stakeholders have time to devote 100% of their effort to a project.  Often you are fortunate to get 5 or 10% of their time.  The reality is that they have a job to do in addition to helping out with the new project.  Their business lives do not stop for IT.  Putting them into a room with the developers and everyone else, whilst potentially beneficial, is not realistic.  In fact, it may seriously hinder their ability to keep the business going.  These rooms where the magic happens are often noisy, disruptive environments.  There is a lot of talking, lots of side conversation, sometimes horseplay (you do not see what happens behind closed doors).  Stakeholders may need to meet with clients or chat with them over the phone.  Having a constant commotion in the background whilst you chat with a client does not sound professional. 

Second,  for the non-stakeholders, adapting to the noise and commotion may significantly impact their productivity.  If you are in the middle of some intense task and get distracted, for one reason or another, it may take 10-15 minutes to regain your train of thought.  If that happens 3 or 4 times a day you’ve lost a lot of time.  

These two points bring up a lot of issues - some of which I will deal with today.  First, team composition is very important.  Some personalities mix like water and oil.  Some are loud and gregarious and want to be the centre of attention - always.  Some are pranksters and jokers.  Others are focused or introspective.  There are all types.  If you build a team that looks, works and operates like a fraternity house, and not everyone subscribes to that philosophy, you will have issues.  They may be serious enough to jeopardize your project.  Agile teams will self-organize and they will develop a personality.  As a manager, you will not be able to control that, nor should you.  However, you can control who goes on the team and the general tone and demeanor.  As a manager you should set the tone and demeanor of your organization. 

Second,  having business stakeholders in with everyone may not be feasible.  It may not even be desirable because the free flow of ideas may be constrained.  Maybe they can be in part of the time, part of the week.  Yes, they can run off to meeting rooms to meet with clients or chat over the phone with them.  Ideal?  No.  Functional, maybe? Or perhaps there is another way to slightly bend Agile methodology and make this work.  Purists will likely disagree with this as it breaks the tenant of face-to-face communication.  However,  as a pragmatist I opt for some communication over no communication .

One tool I have recently used with excellent success is Groove.  I gave it a full run-through on a recent project with a client in Vancouver who had a team member on-site in China.  If you do not know Groove,  it is a peer-to-peer communication and collaboration software that allows team members to form workspaces and share documents, messages, etc.  It was developed by Lotus Notes creator Ray Ozzie, who is now with Microsoft.  We used it for threaded discussions, calendaring and document sharing.  Each time we logged on it synced up all the versions of the documents we were working on and alerted us to new messages in the various discussion threads.  And it kept this up as long as you were logged on - in real-time. 

While we did not use SharePoint, you could use it to archive and make searchable what was accomplished on a project in Groove.  The potential for synergy is great.  Using it, and thinking of the above issues, made me think that it would be a great way to keep a stakeholder, or other team members, connected and informed while not being disrupted to the point of being unable to do their jobs.  The realist in me tells me that I still get the benefit of high-bandwidth, multi-mode communication, just not face-to-face.   I still get instant answers and less miscommunication, which is what Agile is supposed to do.  It would work for stakeholders.  It would also work in those situations where you had personality issues that could potentially tank a project but you have no option but to have team members work together.

Posted at 04:12PM 07 Oct, 2008 by jhenzel in General  |  Comments[0]

Red Flag Series - The Architect and Agile Methodology

To initiate the 'Red Flag' series, I want to focus on technical architects and how they document and present their vision to 'C-Level' executives and business experts and some warning signs that should cause you great alarm.

Let me paint the setting before we launch into the 'Red Flag'.  You have a technical architect on staff working on a complex major project for you.  You are using Agile project management methodology.  That means different things to different people, but you are at least doing daily scrums, have someone that sort of resembles a scrummaster, have your staff in a common work area where 'high-bandwidth' communication is the order of the day, are focused on sprints and doing and not on reams and reams of documentation, etc.  If you have done Agile before this is familiar. 

Red Flag  An architect who uses Agile methodology's focus on less documentation as an excuse not to do their professional due diligence.

This particular architect feels that since Agile methodology means very simple and light documentation he does not need to document his vision and explain it to people, or for that matter, think through the issues. When pressed, the excuse is always "we are using Agile methodology. We don't need to do that." After all, the focus is on doing the core 80% and then refactoring to fill out the gaps in the final 20%.  Sounds good.

·         Except when your architect has not thought through all the parts and pieces and is doing UML diagrams and flow charts of key pieces after the fact.  

·         Except when he is cursing the developers for being slow and dense because they are not doing what he wants -- because no one knows what he wants.  

·         Except when he asks a developer to make multiple major course changes in architecture – within the timespan of an hour.

·         Except when the technical writers, QA team and user training team need an overview so they can do their jobs -- but nothing exists. 

·         Except when key components like security are ignored -- then hastily plugged with hacks at the end.

Any of this sound familiar?  When you sit down with your business experts, technical staff and decision makers, the architect should be able to articulate the system and how it will work.  This does not mean that he needs UML class diagrams of every single part of the system.  In fact, when using Agile that is something I always leave at the discretion of the developers.  However, the architect should articulate what technologies he is using and what is going to be used to do what.   

Your architect should show that he has done the level of due diligence that is appropriate for your business and the legal and regulatory requirements it faces.  He needs to demonstrate that he has thought through the issues you face and has a realistic strategy of how to solve them – especially technically.  This does not mean a chart with a couple of boxes on it where he explains 'magic happens here'.  Use common sense.

If you are the main stakeholder and your architect cannot do this, be worried.   How are you going to plan this thing out?  How are the developers going to know what to do?  Are they going to meet the use cases?  How are you going to budget?  Don’t wait until the financial department raises the hue and cry when they realize that the project is hemorrhaging money.  Agile methodology is not an excuse for technical incompetence, laziness, or arrogance.  

I usually play the role of data architect or technical architect in most of my projects, sometimes both.  The purpose of a technical architect is to put together a data or technical vision for the system being created.  But a good architect is an evangelist; he must see the vision AND be able to articulate it.  One of the first things I do after having gone through the requirements phase, gotten my use cases, activity diagrams, etc. is to draw out a basic diagram with all the moving parts of the system: what they are, where they live, who owns what, what they do and how it all fits together.  For the last of these I use a Zachman-like approach where I have different layers representing everything from hardware, to ETL packages, to web front ends and reports.  I have seen something similar done in David Hays work, Data Model Patterns A Metadata Map.

This diagram is an excellent tool for communicating with executive and business experts.  I usually print it out on a plotter and make a wall chart then go through it with all my stakeholders.  No matter what level the stakeholder is at, i.e. a subject matter expert, system administrator, etc. they can focus on their view of the world and see how it fits into the bigger picture of where we are going. 

Posted at 11:12AM 13 Jul, 2008 by jhenzel in Governance  |  Comments[0]