- Rational Unified Process
- Agile Software Development
- Agile Software Development with Scrum
- Agile Software Development with Kanban
- Lean Software Development
As depicted in Figure 1.0, system-software development has also come a long way, but a long way to where?
Figure 1.0 – SDLC 3.0
Today, we have a multitude of variant agile software development approaches:
- Extreme Programming
- Agile with Scrum
- Agile with Kanban
- Agile/Lean with or without Scrum or Kanban
Additionally, we have thousands of books and articles, yes like this one, written on the subject.
“When it comes to the future, there are three kinds of people: those who let it happen, those who make it happen, and those who wonder what happened.” - John M. Richardson, Jr.
Looking to the future, ask yourself what is working best for you and take control of your adoption of agile/lean product (system-software) development through frequent introspection and continuously adapting to your reality, both iteratively and incrementally.
The what, why, and how of agile/lean product (system-software) development and delivery is not one persons vision alone; to become reality it needs to be a "shared" vision through negotiation and compromise between individuals, the team and the organization.
Next, adopt an agile/lean approach that collaboratively and adaptively promotes developing value-added system-software product increments in a continuous flow from requirements to deployment.
Then, establish a set of norms around your adoption. Here is an example sub-set of norms, when “being” agile using Scrum.
Attributes of the Product Backlog:
- Story Size (The unit of measure used for story size, at the Product Backlog level, needs to be consistent across all development teams in your organization)
Attributes of the Sprint Backlog
- Priority and dependency
- Level-of-effort (The unit of measure used for level-of-effort, at the Sprint Backlog level, is consistent across all development team in your organization)
- Definition of "done"
- Unit tested
- System (Functional and Regression) tested
- Integration (End-to-End) tested
- User Acceptance tested
A team’s velocity from Sprint to Sprint is used to highlight the trend of a team’s ability over time to deliver stories and the point-in-time commercial or operational value was delivered
- Velocity is not to be used to compare one teams rate of getting stories done over another team’s rate
It is worth noting that a set of norms, to the agile/lean product (system-software) development team, is like sheet music to a group of musicians. Recognizing, the more familiar the musicians are with the musical score and the more experience they have playing together, the less dependent the musicians are on the sheet music; except when introducing new musicians to the musical ensemble. This metaphor is applicable to an agile/lean product (system-software) development team and it’s set of norms.
Word to the wise - we are climbing a slippery slope when setting norms. We need to be keenly aware your norms should not be rigid or prescriptive and should evolve through collaboration between self-organizing and self-directing cross-functional teams based on reality.
Norm setting can only work if the team is truly able to arrive at consensus. Norms won’t stick if members have reservations about them. However, once consensus is reached, the team is equipped with a guide that can serve to strengthen positive practices. A set of norms can serve as a common reference if contrary behaviors arise. Finally, written norms are handy for potential members and newcomers who want to quickly get a sense of the team’s adoption of being agile.
Norms in hand, a team can move forward inspired and motivated to uphold the team’s approach and confident in the security such guidelines provide.