I wanted to share some of the learning I have had on the Agile delivery model that we follow in our company. These learning are based on what are some of the good characteristics of an agile team, agile team roles and the agile model that has worked reasonably well for us.
Characteristics of Good Agile Teams
The majority of team members should be “generalizing specialists”. Team members should be:
– Self-disciplined, in that they commit only to the work which they can accomplish and then perform that work as eﬀectively as possible.
– Self-organizing, in that they will estimate and plan their own work and then proceed to collaborate iteratively to do so.
– Self-aware, in that they strive to identify what works well for them, what doesn’t, and then learn and adjust accordingly.
Agile Team Roles
- End Users, Decision Makers, Development & Support Team, Partners.
- Typically a developer committed to delivery of work for the iteration.
- Goes to the product owner for domain information and decisions.
- Works with the architecture owner to evolve the architecture.
- Responsible for the eﬀectiveness and continuous improvement of the team’s process.
- Facilitates close collaboration between team members and keeps the team focused on the project vision and goals.
- Removes impediments for the team and escalates organizational impediments.
- Protects the team from interruptions and external interference.
- Maintains honest communication between everyone on the project.
- Coaches others in the use of agile practices.
- Prompts the team to discuss and think through issues when they are identified.
- Facilitates decision making (but does not make decisions or mandate internal team activity).
- Guides the creation and evolution of the solution’s architecture.
- Mentors and coaches team members in architecture practices and issues.
- Understands the architectural direction and standards of your organization and ensures that the team adheres to them.
- Ensures the system will be easy to support by encouraging appropriate design and refactoring.
- Ensures that the system is integrated and tested frequently.
- Has the final decision regarding technical decisions, but doesn’t dictate them.
- Leads the initial architecture envisioning eﬀort.
The Inception Phase
Also known as project initiation, startup phase, iteration zero. The goals of this phase include:
– Clarify business problem
– Identify viable technical solution
– Plan the approach, release plan
– Setup the work environment and team
– Gain stakeholder concurrence that it makes sense to proceed with chosen strategy
–The average agile team invests about four weeks performing these activities to arrive at artifacts as shown below.
Identifying the Initial Technical Strategy
At the beginning of a project you should invest some time to identify how the solution be built
Why do this?
– Improved productivity during Construction
– Reduces technical risk
– Avoids potential technical debt
– Improves enterprise awareness within the team
– Improves understanding of the operations environment
– Reduces development time
– Addresses the non-functionalities early
– Improves communication
– Enables scaling
Initial Release Planning
The vast majority of agile teams invest some initial time in planning their release
– Work allocations
– How many releases and timing of each ?
– Length of iterations: typically, 2 weeks
The Construction Phase
The goals for this phase are:
- Eliminate technical risk early by proving the architecture with proof-of-concepts or working code.
- Every iteration results in a potentially consumable solution.
Use Case Slicing
- Slice the use case into user stories
- Upfront work required is very little — just need to know the structure of the use-case story as per example shown below.
Use Case Content
Life Cycle of a Use Case
Life Cycle of a Use Case Slice
- Scoped: when it has been scoped and the extent of the stories covered has been clarified.
- Prepared: when the slice has been prepared by enhancing the narrative and test cases to clearly define what it means to successfully implement the slice.
- Analyzed: when the slice has been analyzed so its impact on the components of the system is understood and the pieces affected are ready for coding and developer testing.
- Implemented: when the software system has been enhanced to implement the slice and the slice is ready for testing.
- Verified: and finally when the slice has been verified as done and is ready for inclusion in a release.
A Basic Backlog
Work in Progress Limits
The Transition Phase
- Short and suﬃcient.
- Short iterations are a sign of good preparation during Construction.
- Multiple iterations of Transition may make sense for large roll-outs.
- Proven deployment/installation.
- Good continuous integration and deployment practices streamline Transition.
- Disciplined Agile Delivery
- Use Cases 2.0