inner-banner-about-us

Many organizations are transitioning to Agile as their preferred lifecycle model for software development.  Transitions were directed due to inability for former methods to lead to successful results.  After being brought in to help manage a portfolio of projects in several organizations, there were some disturbing trends when using Agile:

  • Software was delivered, but the users found the software to be unusable.
  • Consultants developed the software, then left. The organization staff had no idea how to maintain the software.
  • A number of application projects were completed. Each had a different architecture and set of tools required to build and maintain the application.
  • Projects were being reported to governance teams with scheduled dates, yet there were no apparent requirements, use cases, user stories, backlog or other lists that might indicate what is being built.
  • Management was completely at a loss about how to resource projects since many seemed to be ongoing forever without completion.

There were some exceptions; however, the preponderance of software development initiatives that succeeded were very small in scope and constituted a low percentage of overall projects required for customers.  There was some information available within the organizations that indicated a process was initiated to convert from a traditional (Waterfall) lifecycle to the Agile lifecycle.  Many of the benefits of Agile, however, were not being demonstrated by the activity taking place.  What happened?

Several disconnects were apparent.  The following list is in no specific order and the discussion of how to understand and act on these disconnects will come later.

  • Developers were communicating with the product lead (customer) through e-mail for the most part.
  • Tools were not prepared to enable appropriate methods such as documenting Epics, Features, User Stories and Tasks.
  • Management had expectations that were unrealistic since the products had little or no definition; so, a schedule was not possible.
  • Product leads did not really know yet what they wanted; and, were not sure how to express their need.
  • Project managers were assigned; but, had no time to spend on projects due to other management responsibilities.
  • A technical lead would commonly step in to assure everyone about “…all that had to be done to continue to implement to a successful result.”

In the end, these environments transitioned from one state that was apparently not very stable, to another that initially demonstrates a state of being less stable.  The one constant in this picture is that software development is difficult.  Since software is logical, it takes a logical process to allow acceptable results to be produced.  So which method is better – Waterfall or Agile?  My opinion is that it does not matter.  Either can succeed and either can fail.  In fact, Waterfall became very incremental and more agile as it aged, and Agile is also changing with age to adopt new methods to scale with control.  Since either method can fail, and in these cases, both did fail; the organizations decision to adopt any method needs to be much better planned.

Do you need more ideas to be more Agile and less Fragile?  Let’s talk about a few:

  • Let’s be sure to have key people in roles meet to gain an understanding of their mutual expectations:
    • Management needs to express what they need from projects to feel comfortable with progress and potential to succeed.
    • If the business cannot express the product need sufficiently, someone has to be available to help them do this.
    • User Stories are called by this name because they invoke a discussion to gain understanding of what is needed. An understanding is just not possible through e-mail; it requires face-to-face interaction.
    • Requirements of some sort are essential to begin so that a picture of a final outcome is possible to envision prior to trying to build each small piece.
    • Participation of those responsible to maintain any application is critical to learning. These folks also are the best source of standards to set for architecture since they have to deal with maintenance of all applications and standards will contribute to improvement in the level of effort required.
  • Clarity for users will be important:
    • The English language is vague. Expecting words to clarify everything is not realistic.  I find it best to draft how a user would interact with the application to get their work done.  Discussions on these mock-ups help to build clarity around the user stories.
    • Test scripts should be written to clarify the acceptable limits of how user stories need to be implemented. Some teams use test-driven development to ensure they develop to approved test documentation.
    • Product demonstrations are NOT as effective as users actually using the software in any form. They can provide immediate feedback from their use of any portion of a system and the sooner the better for this level of clarity.
  • Clarify management information needs:
    • If management is used to waterfall information, a discussion is required to understand their intent with the information. Schedule used to help measure performance in a waterfall world, but generally neglected to incorporate rework required for misunderstanding.
    • Discuss the need, not the reporting format and allow the team to devise a way to help meet the management need. The same information is not always available, but some information is.  The discussion will help to improve understanding and adoption by management.
    • An engaged project manager or scrum master should be able to manage team progress, guide client clarifications, and provide appropriate reporting.
  • Clarify what is required after transition to maintenance:
    • If the product is interim, then perhaps little documentation is required to maintain the application. If the product is to last a longer time, then documentation may be essential for the team assuming maintenance responsibility.  If changes are required, consistency in architecture and coding standards will also help.

The list, of course, could continue.  The point is that all parties need to be on the same page with any method or lifecycle employed; and, clarity in what is being built and what is acceptable is essential.  It is best to plan any method used and to ensure discipline with incremental implementation.