Increasing Business and Technology Throughput

I recently updated a template on my website that I frequently use when either leading iterative development projects or coaching project managers on effective iterative development techniques called the Iteration RouteMap.  The word 'routemap' comes from a South African colleague who used the 'king's english' and insisted that the term routemap was more appropriate than roadmap, the name's stuck ever since!

As far as templates go this one is really quite lightweight, however, there are several key concepts that are important when managing projects in general and iterative projects in particular.  The first is using a mechanism to determine how to size effort.  I typically look at this from the perspective of size and complexity (which is usually a good indication of risk).  Large and complex work items should be started early in the project lifecycle.  I also estimate using Perfect Engineering Days (PEDs), this illustrates how long something should take without interuptions, well defined requirements and all of the other components that can impact how long it actually takes.  A Load Factor is then used to convert PEDs into a realistic estimate.  The Load Factor reflects the productivity of the project and is typically between '2' and '5'.  A '5' reflects a programming language that is either new to the development team or difficult to work with (such as Visual Basic 4/5 within an object oriented development environment).  2 is usually only achieved when the development team has been working on a project for an extended period of time, usually near the latter iterations of the project (when development complexity should be lower). It should be noted that as you actually get some iterations completed you can start substituting the Velocity of your development for the Load Factor. 

The final item is to recognize that there are different Types of functionality/value that will be completed during an iteration.  The logical work items are user stories that represent tangible units of business value that stakeholders can identify and provide feedback on.  However, often these stories need to be supported by 'Infrastructure' stories which ensure a well designed system which can support its non-functional requirements.  In addition, the User Interface (UI) necessary for the story can also be decoupled from the story iteself and is often represented as a separate work item. 

Hopefully this template will be useful to both those just starting their agile/iterative development initiatives as well as those who have been doing this type of rowkr for awhile.  As usual, please feel free to email me with comments.

Posted by Bryan Campbell at 10:01 AM | Permalink | Comments (2) | TrackBacks (0)

I was recently invited to participate in a questionnaire regarding the Essential Unified Process (EssUP) and RUP which prompted me to look more deeeply into EssUP and reflect on the many variants of the Unified Process that exist. 

There are two dimensions of EssUP that look interesting.  The first is Jacobson's recognition that while people buy a lot of his books, most don't actually read them, so consequently he's based the methodology on playing cards that are easier to read and presumably follow. I think this is an important recognition in actually having a process 'used' by people and it seems like an idea that OpenUP and other broader methodologies should consider.  The other dimension is the focus on 'practices'.  RUP/OpenUP/EUP all have tightly coupled workflows/artifacts/roles and sprinked throughout are practice ideas like 'iterative development', 'component design', 'test driven development' etc.  It's these practices that actually make most methodologies effective and Jacobsen has identified these as the building blocks for EssUP. 

I'd be interested in hearing more from anyone that has used/explored EssUP in more detail.

Posted by Bryan Campbell at 10:59 AM | Permalink | TrackBacks (0)

One of things that I personally think is important is ensuring a safe and productive workplace for people in order to maximize their potential.  Part of this comes from ensuring a safe work environment and instituting a culture of tolerance and respect, however, another dimension that I think is also important is ensuring that the workplace is also 'fun'.  If you can have fun in your workplace my logical extension is that you must feel safe since its hard to have fun when you're feeling threatened or worried.  When I was the VP of Delivery Services at Valtech I ensured that each one of our Development Centers had some kind of 'activity center', Wii's and Guitar Hero, Ping Pong tables and electronic dartboards were all available for tournaments and just casual play.  We even had an official World of Warcraft guild for employees and spouses (and there were a lot of spouses!).  When I was at BMC one of the events I organized for my staff was a rather remarkable scavenger hunt/trivia pursuit/cranium game that was provisioned by a company called The Go Game.  It was probably the best team building event that I've ever been involved in and the company was creative enough to customize the game so that our India team could participate as well.  Of course, I come by this honestly having spent my early years running a small company that provided Doom network gaming tournaments.

By adding some 'fun' to the workplace it's opened up new communication channels amongst staff and it's allowed people to connect in ways beyond their work commitments.  It's a tricky area of course, one person's 'fun' is not always anothers.  When I took over at Valtech the only organizational fun was playing poker, however, not everyone enjoyed playing and felt excluded and even resentful that this was the only way to interact with their colleagues outside of work.

However, it seems that you can take the whole of idea of fun in the workplace to a whole new level.  I read an interesting article in the Utne Reader about the "infantilization of corporate America" which describes companies pushing the boundaries of this idea of fun to the point that employees feel like children in school.  Clearly there are some 'dos and don'ts' when pursuing these ideas!

Posted by Bryan Campbell at 05:10 PM | Permalink | TrackBacks (0)

Recently I've been involved in some discussions on effective tools for teams collaborating and communicating.  The questions revolved around the use of Twitter as an effective tool for collaboration.  One of the great premises of the Web 2.0 paradigm is that it introduces a more interactive model for communicating sharing information.  Nowhere could this be better leveraged than in teams particularly those that are geographically dispersed.  Twitter is an interesting product of the Web 2.0 paradigm as it provides short (140 character) comments on what a person is doing. 

Initially, I was skeptical about a social-networking tool like this as it emphasized activities not outcomes.  However, upon reflection and reading an interesting article from on my old alumni-BMC blog, I now think this would be a very powerful tool particularly for geographically dispersed teams. Although Twitter emphasizes activities, its these activities that connect people in a community and a software development team represents a focused community.  Having a tool that allows team members to understand the activities that others are engaged in provides visibility that can only be accomplished when working in the same general area.  In larger companies and in globally distributed projects it's not practical/possible to have teams working together.  Twitter and some of the other micro-blogging services like Pownce (which allows you to blast out links to events and even files... which would be useful when a document had been updated) fill a void that other tools like Wikis (Atlassian Confluence), Version Control solutions (Subversion), IM solutions (Jabber), Communication tools (Skype) and Application Lifecycle products (Rally) don't address.  At some point all of this seems likely to converge but until then it will be necessary to stitch together these solutions to really ensure effective collaboration of your teams.

If you're using any of these Web 2.0 tools in your environment I'd be interested in hearing about their benefits and what effective practices you've discovered.

Posted by Bryan Campbell at 11:13 AM | Permalink | TrackBacks (0)

I've been involved in using, editing and creating IT methodologies in one way or another for more than 15 years.  In my early experiences I even went through the process of creating my own IT Enterprise Architecture framework complete with its own graphical navigation system and a lightweight content management system (I created it to point to documents stored in the file directory system we were using which I believe was Novell based).  I keep a reference on my website primarily out of nostalgia but also because early on I saw the importance of aligning business goals with IT strategy and architecture.

My knowledge of process, methodologies and value chains has increased substantially since those days but I'm still surprised at the lack of consistency and even awareness of these topics across the IT industry.  It's no wonder most companies struggle with managing their IT functions let alone positioning them for competitive advantage.  However, there are an increasing number of robust methodologies and processes available that take the ideas and concepts I mentioned above and can help an organization rapidly mature its IT function with a standardized but custom set of processes.

Recently I've been spending time with a web based, hosted methodology authoring tool from Osellus which is very interesting.  It's methodology agnostic (so you don't contend with whether you should start with RUP or Microsoft Solution Framework or other base methodologies) and you can mix and match with a straightforward user interface.  It's a hosted solution which means you pay a monthly subscription fee which entitles you to updates and support of the solution.  The product comes with a number of base processes and you can add your own libraries or import others such as RUP.  It's a very interesting solution and takes a very different approach from Rational Method Composer  which is a thick client and starts with the Classic RUP as framework.  Ossellus still has a few weak points such as lack of a 'Discipline' package for related roles but its price is quite competitive and relatively low risk for anyone interested in exploring some alternative product solutions.

Of course the big splash in the IT methodology pond has been the effort behind the Eclipse Process Framework (EPF).  Initiated through a donation from IBM the EPF aims 'aims at producing a customizable software process enginering framework, with exemplary process content and tools, supporting a broad variety of project types and development styles".  I think one of the most interesting outputs from the EPF is OpenUP, a lean version of the Unified Process emphasizing agile philosophies and collaborative development techniques.  Implementing an EPF based framework has the benefit of being free but provides a metamodel that has benefited from literally hundreds of thousands of development effort.

Posted by Bryan Campbell at 10:29 AM | Permalink | TrackBacks (0)

Recently I was coaching some people on dealing with organizational changes, as part of the discussion I shared an old management joke that has so much truth threaded through it that at times it doesn't really feel like a joke!

A new manager comes into his office and sits down in his chair.  As he settles himself into his new surroundings he opens one of the desk drawers and discovers three envelopes numbered 1, 2 and 3, a small note is attached to them:

"Good luck, in your new job, although I can't meet you directly I understand the challenges you'll face and hope that these 3 envelopes will help you manage through any major problems you run into." 

- signed the previous manager.

The new manager doesn't think much about this until a few months later when he is facing considerable pressure to turn things around and show improvements to his superiors.  He reaches into the drawer and decides to open the first envelope.  Inside is a note that says "Blame Your Predecessor!".  Of course, he exclaims and then proceeds to explain why none of the problems are his fault and that they all stem from the previous management. 

Things settle down for the next six months until once again he starts feeling increasing heat to show improvements and results.  He opens the second envelope and this one says "Reorganize!".  Of course, he exclaims and proceeds to create a new org chart changing roles, responsibilities and shifting people. 

Once again things settle down for a few months but soon the political pressures mount and the manager has run out of ideas on what to improve or change.  He reaches into the desk drawer and pulls out the third and final envelope.  He opens it up and reads the next note..... "Prepare three envelopes and leave them in the drawer"...

Posted by Bryan Campbell at 10:54 AM | Permalink | Comments (1) | TrackBacks (0)

Posted by Bryan Campbell at 02:00 PM | Permalink | TrackBacks (0)

One of the most important aspects of the Unified Process and what I emphasize when managing complex software development projects is to focus on an 'architecture-centric' approach to building a system.  The best way to accomplish this from my perspective is to ensure a prioritization of user stories/use cases based on not only business value but architectural significance.  It's also important to remember that building architecturally significant components can still demonstrate business value at the completion of an iteration.  A simple UI showing how data can be entered, stored and retrieved (even if it's not editable) shows a business stakeholder that the 'tiers' and 'layers' that exist behind the scenes are adding value.  One way to ensure a balance between business needs and architectural requirements is to establish a troika of the Product Owner, Architect and Project Manager to review and assess the Release Plan and its prioritization.

The Design Discipline

• Balancing the amount of effort applied to formal Design:  Agile Modeling (AM)

• Designing for Future Change: Service-oriented Architectures (SOA)

A Service-oriented Architecture is one in which all functions, or services, are defined using a description language and have invokable interfaces that are called to perform steps in business processes.  Each such service must have unambiguous semantics (see Design By Contract), and should preferably be idempotent (repeatable without side effects).  Larman’s expedited UP leads smoothly to the definition of such architectures since it promotes the definition of system or component-level operations with well-defined semantics (contracts). Although this requires a degree of maturity within a development organization its benefits are significant.

• Realizing the Full Benefits of Reuse:  Product Line Architectures  

Adopting some form of Product Line Process is indispensable to the achievement of true asset reuse across a range of projects and products.  The earlier model of “if we build a component repository, they will come” simply does not work.  To realize reuse benefits the enterprise must combine an application engineering process with a domain engineering process.  A standard recommendation is to adopt this two-level approach wherever and whenever feasible.  Using commonality/variability analysis together with a full repertoire of variation point management techniques (model management and refactoring, model-driven architecture, management of variable configurations, design patterns, framework development, polymorphism and AOSD) in order to achieve this well-defined relationship between the domain engineering and application engineering processes.  (Of course, one of the reasons software development has moved towards OO technologies is that they contribute importantly to this repertoire.).

• Design by Contract (DBC)

  Design by Contract is a simple but powerful discipline for writing specifications of use cases, services, system operations, component operations and class methods.  It uses the concepts of pre conditions, post conditions and invariants to achieve a full separation of “what” from “how”. The benefits of so doing are enormous, and include:

  • Precision,
  • Lack of ambiguity,
  • Testability, and
  • The ability to write short specifications even for complex implementations.
    

Posted by Bryan Campbell at 10:39 AM | Permalink | TrackBacks (0)

Posted by Bryan Campbell at 09:50 AM | Permalink | TrackBacks (0)