Big Byte: Understanding the Fundamentals of Agile Part II

Last week I outlined some of the key elements of Agile. This week I would like to touch a bit on how to form Agile teams, plan an effective transition strategy and deal with roadblocks. I also make a direct comparison of Agile vs. Waterfall. Do you have anything to add? I invite you to share your feedback with me in the comments or connect with me on Twitter or LinkedIn.

Forming the Agile Teams

  • Team Roles and Responsibilities Including the Customer’s Role
  • Expectations
  • Self-Directed, Self-Organizing Teams
  • The Nature of Communication and Collaboration
  • Creating a shared understanding of software development
  • Understanding a project’s “triple constraints”
  • Defining the measure of a successful project
  • Customer involvement and collaboration
  • Investigating scope creep and the nature of scope management
  • Managing the development team, managing personalities and cultural differences
  • Organizational process requirements and constraints
  • Changing customer product expectations
  • Reviewing industry data for product development success and failure

Define Our Challenge

  • Creating a shared understanding of software development
  • Understanding a project’s “triple constraints”
  • Defining the measure of a successful project
  • Customer involvement and collaboration
  • Investigating scope creep and the nature of scope management
  • Managing the development team, managing personalities and cultural differences
  • Organizational process requirements and constraints
  • Changing customer product expectations
  • Reviewing industry data for product development success and failure

Planning an Effective Transition Strategy

Challenges of Transitioning from Waterfall to Agile

  • Defining our organizations’ project challenges
  • Architecting the problem rather than the solution
  • Cultural resistance to change
  • Organizational barriers to incremental delivery
  • Distributed teams

Transition Strategies

  • Mapping out Agile processes against current organizational constraints
  • Identifying appropriate candidates for first Agile project
  • Taking baby steps in adoption
  • Defining a ‘Hybrid Approach’ which encompasses current best practices with process improvements
  • Overcoming general resistance to change
  • Identifying leaders in the organization that can lead the transition

Transition Roadblocks and Myths and How to Navigate Around Them

  • MYTH: Agile is undisciplined, comprised of ‘cowboy coders’
  • MYTH: Agile is nothing but ‘galloping scope creep’
  • MYTH: Agile does not respect documentation requirements of my industry or organization
  • MYTH: My job is going to be eliminated
  • MYTH: Agile does not scale for larger projects
  • MYTH: Agile sounds great, but it can’t work for my company, we are unique
  • MYTH: My team would never be able to self-organize, they are too disorganized
  • Resources or management with no desire to expose ‘bad wiring’ and/or fix the broken processes
  • The WIIFM Syndrome (what’s in it for me?)

WATERFALL

AGILE

Project & Product Planning
  • The Project Manager
  • Front-loaded planning
  • Separation of requirements gathering, development, and testing teams
  • Documentation as the primary means of communication and collaboration
  • Planning reflects the contract requirements before customer needs
  • Plan is set and the development unit attempts to simply “work the plan”
  • The Agile Coach
  • Team based approach and responsibility for project planning and execution
  • Continuous collaboration and continuous planning
  • Face-to-face communication
  • Self-organizing and self-managed teams held accountable
  • Shortened feedback cycles to allow for increased incremental improvement
Product Requirements
  • Joint Application Design sessions
  • Never ending requirements meetings
  • Documentation primary means for requirements communication
  • Large amounts of effort expended to document detailed requirements for all requested product components
  • Changes to requirements after the requirements phase invokes heavy change management processes
  • Requirements are gathered at a high-level, in simple to understand language
  • The Agile team works directly with customer to properly understand the value of each requirement and its related acceptance criteria
  • The Customer (product owner) prioritizes each requirement so that the Agile team is able to deliver in order of priority
Scope Definition and Management
  • Changes from baseline must be assessed for timeline and dollar impacts
  • The change process must be documented in detail and executed diligently when change is requested mid-project
  • Customer sign-off is required for all scope documents so that change is appropriately managed
  • Extensive, heavy processes are put in place to address and vet change requests, where the true outcome of these processes serves to inhibit requests for change, even where change may benefit the product
  • Change is welcomed as an expected consequence of emergent requirements and product evolution
  • Changes are added to the backlog, resulting in a changed feature set prioritization
  • Adjustments to the schedule are made as the team adapts to the new elements. These changes are driven by the customer as they make trade-offs in the project’s triple constraints
  • The customer adjusts priorities as required by business needs, changes in the market, new regulations, etc.
  • The team utilizes a burn-down chart to effectively communicate the impact on budget and schedule of requested changes
Product Quality
  • Developers perform unit tests to ensure the component is functional
  • Upon completion of development, the code is ‘thrown over the wall’ for QA testing
  • QA maintains primary responsibility for product quality
  • Quality is specifically a component of functional adherence to original documented requirements
  • The development team is comprised of both developers and QA resources
  • Quality is a result of the entire team collaborating regularly with the customer to make adjustments
  • As product increments are completed, demonstrations are provided for the customer to allow for the product to emerge based on an evolving competitive landscape
  • With each completed iteration, code from earlier iterations is tested regressively and multiple times, creating a very robust code set
  • Quality is designed into the product/process and not inspected in with final test cycle
Managing People, Personalities and Process
  • The Project manager assigns work to the individual resources on the team, often in small increments
  • Feature component planning and development process is not collaborative, no team accountability is practiced or expected
  • The project plan is ‘etched in stone’ and is rarely re-baselined to reflect the current project reality
  • Assumes project execution is linear and need for effective collaboration is minimal
  • Resource assignments follow a ‘top-down’ management methodology
  • Variances are usually considered negative
  • Self-organizing team plans and selects its own work
  • Project manager is a facilitator and a coach, managing results and outcomes rather than tasks and assignments
  • Design evolves as more is understood about the project
  • Collaboration between the team and client results in higher productivity and ownership
  • Mistakes are tolerated as a necessary component of learning
Product Delivery
  • Project generally proceeds with sequential analysis, requirements, design, coding, and test phases
  • Customer does not see a working product until close to the end of the test cycle
  • The Processes Change Averse: Discovery or missed requirements can cause delays and add significant dollars to the project budget
  • The entire feature set is worked as a single top priority element
  • Risk is generally managed by exception and handled as it occurs
  • Highest priority features are developed first
  • Highest risk factors are addressed early in the project – concurrent engineering practices result in the best architectures and best overall design
  • Working elements of the product are delivered in measured increments: the customer sees and experiences the product growing before their eyes
  • Discovery and new requirements are merged with the existing product backlog. Rework and delays are relatively small or insignificant

Closing

Traditional planning approaches prescribe that all planning is complete before development begins, and all development is complete before testing begins. This sequenced approach to product development often is executed outside of customer involvement and regularly results in less than optimal results

Advertisements
  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: