Johanna Rothman Part II Design and Manage an Agile and Lean Project Chapter 5 Start Your Agile Project Right. Copyright 2017

Transcription

1 Johanna Rothman Part II Design and Manage an Agile and Lean Project Chapter 5 Start Your Agile Project Right Copyright 2017

2 Start you Agile project right Projects need direction teams need to know where they are headed and how do know when they are done When teams use agile approaches value should be seen at the end of each iteration Agile approaches allow for release of observable interim value at the end of each sprint

3 Why Charter your project The Charter should provides the understanding of why a prescribed set of features are to be delivered and how to know when the project done the Release Criteria Start the project with the project Vision, the Release Criteria, and the Product Backlog Rothman I have a question I ask of all parts of an agile project: How little can we do to satisfy our needs?

4 How little thinking is needed The backlog, the feature set, and any up-front work How the product is to evolve is key not a pretense of a plan for how the product will evolve. The two parts: Project Vision and Release Criteria

5 Project Vision Short but specific one to three line statement What the Product Owner want the project to provide at the end of each release (assumes that there will be multiple release prior to the final release) Examples ( useful but not compelling ): Improvement of performance in three scenarios by a minimum of 10% Adds functionality Changes the UI across the product to our new standard

6 Project Vision Short but specific one to three line statement What the Product Owner want the project to provide at the end of each release (assumes that there will be multiple release prior to the final release) Examples ( useful but more compelling): Who is the main recipient of the project s outcome? What can the main recipient do with that outcome? What is the vale to the main recipient?

7 Develop the Release Criteria that is the definition of what DONE means! We can end when there is no more value in the Product Backlog but instead of focusing on having no more value in the Backlog The Product Owner (the customer representative) can receive more value when users can use the product and then provide feedback. Type of Scenario Example Description Performance For a given scenario (describe it in some way), the query returns results in minimum of two seconds Reliability The system maintains uptime under these conditions. Scalability The system is able to build up to 20,000 simultaneous connections and scale down to fewer the 1,000 connections. Table 4 - Possible Scenarios for Release Criteria

8 Defining Release Criteria Rothman instead of waiting for everything in the Product Backlog to be done When the team used an agile approach and demonstrated working product every two weeks he was willing to consider release criteria once he realized the team was able to deliver value on a regular bass. sprint after sprint

9 Charter the Project as a Team! The team needs to own the Project Charter or Plan and any experiments needed to understand the design and architecture The objective is to identify the value the team expects to create and not to omit and therefore leave any action items for the future.

10 Identify your Product type First, the reference to Product requires that the team focus on who will use the product the users! and how often the team could release the product identifies at the start what the end means. Two kinds of products those released continuously (as software as a service) and those released infrequently (as in hardware) The Continuum of Release Frequency

11 The Continuum of Release Frequency For any a number of reasons, it may be difficult and/or costly to release often hardware dependent development ( Our Customers Can t Take the Product Often, insert) However, the cost of digital Software as a service can be released continuously. Potential for Release Frequency Digital-only Product as Software Service Boxed Software Product with Firmware Software with Hardware or Mechanical Components Continuous Intermittent Less Frequently Continuous Deployment Often: Less Often: Infrequently As often as But the cost of The cost of Every release might be several times a day release is still high release is high a major release

12 Project Pyramid: Tradeoffs & Potential Risks for Projects Inside project risks and Outside project risks

13 Assess your Project s Risks Success is not a defined process There is no checklist Risk of how the team thinks about the domain and solves problems the technical risks Just as problematic Not understanding (that is, knowing with certainty) the more difficult risks the scope, cost, schedule and the people and their capabilities Avoid Management Mayhem (page 243)

14 Avoid Management Mayhem I had always worked in a culture of blame. I could swear all my managers came from the school of: You do it, you own it. I don t like it, I blame you I did the same thing with my managers and their teams. I wanted to use agile approaches. I needed the features done and released. I keep managing the same way I had always managed.

15 Start Architecture Thinking but not defining the architecture at the beginning of the project but do start thinking about the architecture Agile approach The architecture evolves as the Product proceeds The teem will add features, iterating over the feature set. The team builds, increments, ad refactors the code and tests as the work proceeds Rothman When I work with people who are accustomed to starting with architecture, I ask them to draw a low-fidelity picture of the architecture as the team progresses.

16 Recognize Project-Startup Traps Trap: Iteration Zero The waterfall bias the need to complete the architecture plan and estimation of the work to be done for the entire project. It is typical to adopt the defined (theoretical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood. but What you cannot know at the start When the process is too complicated for the defined approach, the empirical approach is the appropriate choice.

17 Instead of the Big Design Up Front trap Spend up to half a day creating a list of experiments so that the team knows what and where to explore Determine the hardware or other resources the team will need to start that effort determine if the team can start on anything without those resources Iterations/sprints require estimates of work associated with stories in the Product Backlog the team will need to master the process of estimating story points If the Product Backlog is filled with stories, each of which is too big to complete in a sprint the team will need to break the large stories into a smaller stories that can be completed in a sprint How little can the team do to get ready so they can start a sprint and begin delivering value

18 Empirical Process Control

19 Recognize Project-Startup Traps Trap: Your Organization wants detailed Project Plans.. but you cannot know what specifically needs to be done and how it needs to be done at the beginning. In Scrum, decisions are made based on observation and experimentation rather than on detailed upfront planning Instead development requires empirical process control a process that relies on the three main ideas of transparency, inspection, and adaptation. Transparency with the following Artifacts: Project Vision Statement Prioritized Product Backlog Release Planning Schedule Meetings Sprint Review Meetings Daily Standup Meetings Information Radiators Burndown Chart Scrumboard

20 Recognize Project-Startup Traps In Scrum, decisions are made based on observation and experimentation rather than on detailed upfront planning Empirical process control relies on the three main ideas of transparency, inspection, and adaptation. Inspection depicted through: Use of a common Scrumboard and other information radiators Collection of feedback from the customer and other stakeholders during the identification of features and stories Creation of a Prioritized Product Backlog, and Release Planning processes. Inspection and approval of the Deliverables by the Product Owner and the customer in the Demonstrate and Validate the Sprint.

21 Recognize Project-Startup Traps In Scrum, decisions are made based on observation and experimentation rather than on detailed upfront planning Empirical process control relies on the three main ideas of transparency, inspection, and adaptation. Adaptation The Scrum Team and Stakeholders learn through transparency and inspection and then adapt by making improvements in the work they are doing. Adaptation in Scrum is depicted through: Standup Meetings Constant Risk Identification Change Requests Scrum Guidance Body Retrospect Sprint Meeting Retrospect Project Meeting