• PostMortem

last modified December 19, 2008 by sonali

Lessons from listen WebUI improvement (round 1)


INTRODUCTION:

Who are we?
Team : Robert, Sonali, Nick, Jeff - implementers
           Sonali, Jeff - write-up


What are we doing?
Documenting and sharing lessons learned from the first round of listen web improvements:

  •   Central points that encapsulate good strategy for project process
  •   Good set of things to think about when constructing process
  •   Process should fit team needs
 

Why are we doing this?
To improve our understanding and implementation of processes of  software design and development.


How we did it - and how we would like it to be done.

  • We were improving the listen user experience through the web.
  • We had a bunch of ill-defined processes and tasks that we should have defined more concretely (bunch of directions with really no one to steer the ship).
  • Scope was not defined. Defining scope is a collective responsibility.  No one did it, so collectively we dropped the ball (or really, no one caught it) - retroactively, this can be done for listen.
  • Use cases were not investigated.
  • Scheduling was done ad hoc and therefore not at all (or as little as possible).
  • There was no unified documentation or any sense of where or how to document things.
  • Team members worked on issues without a sense of a roadmap or coherent strategy.

 

Things we could have worked with:

  •  Upfront goal
  •  Strategy or roadmap on how to meet that goal
  •  If there were changes made to that based on tech restrictions then noting them
  •  A planned release - and timelines



PROJECT PROCESS:


1. Commit a team to work on the project.

2. Construct a clear and precise mission statement.

3. Define project goals and tasks that will achieve these goals. The goals and tasks form a roadmap that makes actionable the mission statement.

4. Build a process and communication strategy suitable to the needs of the team and of the project.

5. Assess what came out of the project and what can be learned from the experience.


1. COMMIT A TEAM TO WORK ON THE PROJECT.  [WHO?]

The team is given the high level picture of what the project is supposed to do, enough information such that they may make informed  decisions regarding their MISSION and their GOALS.

The team is scheduled for at least a specific block of time.  While schedules may changed, this initial scheduling block gives them the  frame with which to define scope for the project.

  • Designer and developers should interplay to the extent mandated by the nature of the project.
  • The team should retain a core of knowledge (people can move in and out but the core group stays)
  • Team members should feel like its their project! (take ownership of the piece and enjoy it)


2. CONSTRUCT A CLEAR AND PRECISE MISSION STATEMENT. [WHY?]

  • The team interprets the project as communicated to them as its mission statement.
  • While the high level nature of the project is given by the organization, it is important that the team define the "why?" of a project in order that they are stakeholders and therefore have incentive to solve problems creatively.
     -   it must be noted that this can backfire;  Responsibility that does not mature into definition does not result in worthwhile projects.
  • If a new team member is brought on board, they should review the mission statement and goals+tasks and offer feedback and criticism if applicable.
  • A mission statement is not an archaic or contrived statement. It is statement that gives you direction to help keep everyone on the same page. This is important this is for collaboration.


3. DEFINE PROJECT GOALS AND TASKS THAT WILL ACHIEVE THESE GOALS.  THE GOALS AND TASKS FORM A ROADMAP THAT MAKES ACTIONABLE THE MISSION STATEMENT. [WHAT?]

  • Understand the problem.
  • Make the mission statement into actionable goals and their component tasks.
  • Project tasks are actionable items;  project goals are take-aways.
    Project goals should add up to a concrete realization of the project mission.
    A task might become a goal of more concrete tasks when iteratively broken down.  (A task does not necessarily correspond to a trac ticket).
  • Identify and work on the foundation first:  there are pieces that should be in place before other pieces. The first step to solving any problem is identifying blocking areas and commonalities and tackling these first.
  • Tasks are not delegated, they're accepted (this is important, as delegation effectively absolves responsibility).
  • The mission statement and the roadmap provide project scope. 
    Goals and tasks should be reassessed as the project progresses in an iterative process. This allows for scope creep but is also crucial to development.
  • The scope of the project (the roadmap) should be communicated back to the organization.


4. BUILD A PROCESS AND COMMUNICATION STRATEGY SUITABLE TO THE NEEDS OF THE TEAM AND OF THE PROJECT. [HOW?]

  • The team should decide up front (and continue evaluation going forward) what communications channels should be used and how.
  • There should be available communications solutions for common cases.  If you just want to grab an existing process for a new project, that should be an option.
  • You should actually do what you say you are going to do.  If the communication process isn't working, then revisit the process -- consciously!
  • Communication must be comfortable.  People should feel safe bringing up an issue without feeling threatened.
  • A work iteration is scheduled from the defined goals. Iterations should be kept tight.

Three types of communication are necessary for project success:

i. When new people come on to the project, there needs to be a knowledge transfer from the more experienced people.

ii. Regular communication encompassing the whole team needs to happen.
     - Meetings
     - Issue tracking
     - Testing strategy

 * Note technical and other blocking points.  Learn from the experience.

 ** Iterative methodologies are more flexible than the waterfall methodology.


iii. High-level information should be disseminated to the community.

Types of information to be disseminated:

        MISSION STATEMENT

        ROADMAP

        DOCUMENTATION: with focus on coherency rather than breadth

        SCHEDULES

        PROGRESS REPORTS

        DEMOS: a list of active demos should be maintained (Example:  http://demo.opengeo.org/)

        CONCLUSIONS
   

Sharing information lets people:

  •  know who is working on what?
  •  keep abreast of work throughout the whole organization.
  •  interact with the project and provide feedback. 

Disseminating information also leaves a paper trail that future workers can follow and make sense of.  A useful question to ask yourself about what information to share is what information would you like to be available to you before starting the project.


AN OUT OF THE BOX SOLUTION FOR PROCESS AND COMMUNICATION:

This example communication process is provided as a template for future use. Process can and should be customized to team and project needs ... but you need to have one!

A.

  • Pair new people with more experienced people. (how many days?)
  • Give the newcomer an overview of the mission statement and the developed goals and tasks.
  • Give the newcomer ample opportunity to ask questions and offer feedback.
  • Its better to avoid changing the team makeup if possible.

B.

Communications: 

  • daily checkins
  • blog
  • wiki
  • irc
  • trac: start a trac project or use an existing one

Issues:

  • too many meetings vs. not enough?  
      - Meetings don't have to be long.
      - The length and scope of meetings should be decided upon prior to their beginning.
  • Consider recording meeting minutes.
  • Decide a testing strategy.  Testing should help ensure that the mission statement is met.

C.

Things that should be shared:

  • Mission statement
  • Roadmap
  • Progress and schedule: status updates
  • Who is working on what?
  • Vehicles for communication:
  • Project homepage
  • Demos:  demo accounts should be kept in an as obvious place as possible so that people can log in with different privileges (standard user, admin, etc)
  • Lower-level information (e.g. trac tickets) should be intuitively accessible from these high-level communications, but low-level information need not to be explicitly communicated.


5. ASSESS WHAT CAME OUT OF THE PROJECT AND WHAT CAN BE LEARNED FROM THE EXPERIENCE.  [WHAT? part II]

  • Assess what came out of the project and what can be learned from the experience.
  • These lessons should be shared with the organization.
  • This experience should be a starting point for subsequent project iterations.
  •  Next steps and follow up for the project should be discussed and recorded.
  •  Assessment should be on-going, but a formal breakdown at the end is helpful.

 

PROCESS - SHORT FORM:

Short-handed form for the five points:

1. Team

2. Mission

3. Goals and Tasks

4. Process and Communication

5. Conclusion


WORKFLOW:

The first task is to spec out what should be done:


* team defines mission, goals, and tasks

* team discusses with manager on the objectives laid out

    - the extent of immediate work is decided

   - unscheduled work is noted for when the effort can be revisited

 

The immediate scope of work is undertaken:


* team sets the process for the implementation of the decided tasks 


* team moves into the development and design cycle for the allocated work

* WORK HAPPENS!


* on project end, team assesses success and failures and outlines next steps if applicable

 

When a previously existing project is continued:

  * the new team members review and assess the existing roadmap and process documents

 * if in light of the current state of the project and the organization changes should be made, make those changes


CONCLUSION:

* this (== everything we do!) is an iterative process

* this is a process to design a workflow

 * See how people use the software from usage data such that informed decisions can be made about WHAT to develop.


          -> this can't be used to drive development, but it is useful for evaluating development that has been done

* User experience:

     -> steer users towards what they want to do
     -> give users opportunity to "ask questions" to find what they're doing

 * Process is TOPP's product: how we overcome our own working challenges is a substantial part of what TOPP can and does offer the world.