Affinity: a similarity of characteristics suggesting a relationship, especially a resemblance in structure
Waterfall – 1970 – Winston Royce – “Managing the Development of Large Software Systems”
“Personal views about managing large software developments” mainly spacecraft mission planning, commanding, and post flight analysis
“Waterfall” coined by the DOD in their standards for developing military computer systems.
Clearly stated that this model fails without iteration
February 2001: 17 leaders in the software development industry seeking an alternative to documentation driven, heavyweight software development processes.
Highlight:
Iterative and Incremental - Evolutionary
Highly collaborative
Self-organizing teams
effective governance framework just enough ceremony – cultural discipline & best practices
High quality, cost effective, and timely – project triangle
Meeting changing needs of the stakeholder within the project triangle – value
Highlight:
Responding to change
Rooted in values
Bounded by principles
Enacted through practices
Many people may think that Agile is just another software development process. There is a lot more to Agile than just a process or just a set of practices. Agile (or agility) is a mindset—a cultural way of thinking about software development.
The agile methods are focused on different aspects of the Software development life cycle. Some focus on the practices (e.g. XP, Pragmatic Programming, Agile Modeling), while others focus on managing the software projects (e.g. Scrum). Yet, there are approaches providing full coverage over the development life cycle (e.g. DSDM, IBM RUP), while most of them are suitable from the requirements specification phase on (FDD, for example). Thus, there is a clear difference between the various agile methods in this regard.
DSDM = Iterative Waterfall
Embedded in those methodologies are practices such as…
Requirements Practices
Development Practices
Testing Practices
Release Management Practices
Configuration Management Practices
Iterating – Not intended to be perfect
Generates feedback
Takes a keen understanding of the purpose/solution what is being built
A true Scrum Team consists of a ScrumMaster, a Product Owner, and a Team. These three roles are collectively responsible for the delivery of the finished software. Each role also carries distinct responsibilities to optimize the Scrum Team’s flexibility and productivity.
ScrumMaster – Responsible for ensuring that the Scrum Team adheres to the values, practices, and rules of Scrum. The ScrumMaster role is that of facilitator, organizer, and coach. Most importantly, the ScrumMaster is responsible for removing impediments – anything that may be preventing the team from making progress towards delivery.
Product Owner –Solely responsible for managing the Product Backlog and ensuring it is visible to the Scrum Team. The prioritization of the backlog represents the voice of the customer, and illustrates the top business needs and their alignment with the overall vision of the project.
Scrum Team – Turns work from the backlog into increments of potentially shippable functionality every iteration. The true Scrum Team is cross-functional; meaning, the members of the Team have all the skills required to create an increment of working software. True Scrum Teams are also self-organizing. While the Product Owner defines what the Team will work on, the Team itself decides how the work will get done in an iteration. The optimal size for a Scrum Team is seven people, plus or minus two. For projects with larger teams, Scrum can be scaled up to support better coordination and productivity across multiple teams working from the same backlog.
PO Proxy can make things complicated and confusing
The Product Owner is:
the singular voice of the customer that a Scrum Team must satisfy
the central business point of contact for defining product requirements & direction
The Product Owner must have:
deep understanding of the business drivers for the organization/program
authority to make decisions/prioritize work
commitment to follow the Scrum framework
The Product Owner is responsible for:
Communicating the Product vision at all levels
To teams, stakeholders
Ensuring that Program stays aligned with Product Vision
Identifying the desired features/functionality and the value each should produce (Product Backlog)
Ordering the desired features/functionality
Providing Continual Guidance/Information to the Scrum Team
Requirements
Acceptance Criteria
Agreement on Design Approach
Be available to the Team
Establish proxies & an interaction model if needed
Managing Stakeholder expectations
Release Planning – level of confidence on estimates
Scope Management
Visibility
Participation at Sprint Reviews
Product Management – Strategy towards vision
*at least
Bill Shakelford’s ‘Design the box’ exercise
Front of the box
Product Name
Graphic/logo
3-4 key selling points
Back of box
Description of key features
Screens/mockups
Spine
System requirements
Bill Shakelford’s ‘Design the box’ exercise
Front of the box
Product Name
Graphic/logo
3-4 key selling points
Back of box
Description of key features
Screens/mockups
Spine
System requirements
1. What does success look like to each of the participants? The mission needs to identify what
the people who charter the team value. Consider too the goals of each of the contributors.
2. What is the product of the team expected to look like? What features? What are the
architectural constraints? What interactions will the system have with it’s environment?
3. What attributes will the project be constrained by? What are the resource and schedule
constraints? What issues are known to be significant?
A shared understanding of these dimensions is critical to enabling the team members to collaborate
effectively.
1998 and 2001
As a <stakeholder>, I would like to improve <some quality dimension> from <current level> to <desired level>, so that I can <achieve some goal>
One trick I learned to keep my user stories small is to only allow enough scope so that all of my acceptance stories can be written using a ball point pen on the backside of the user story index card. Another physical constraint!
If your user story has more than 3-4 acceptance tests, really analyze the story and see if it makes sense to break it down even further so you can fit all its acceptance tests on the back of the card. Doing so might help you break down those larger stories into more digestible pieces.
Typical attributes to help with order:
Value
Dependency
Complexity
Cost
Size
“Flat”
Visualize the story!
Product goals describe what outcome or benefit received by the organization after the product is in use
Ideal time vs actual time
No longer a question of Time when the schedule is fixed. Better question is how much, not how long.
Empirical process control
A COACH CAN:
support the successful introduction of Agile to your organization and team
improve teamwork and increase productivity
mentor and up-skill executives and managers.
GOOD COACHES ARE:
Knowledgeable: They have a deep understanding of Agile practices and processes.
Experienced: They have worked on Agile projects.
Communicators: They can listen and talk with people from across an organization.
Collaborators: They work with teams and organization to find answers.
Leaders: They can motivate and inspire teams.