LeadingAgile Transformation Overview

Editor's Notes

1. 11. We start with high level requirements that become more detailed as we learn more about the product we are building.  We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product.  You might think of this as rolling wave planning or progressive elaboration.  The idea is that we plan based on what we know, and plan more as we learn more.  
2. The first component is teams – the people who build, test, and deliver the products we ship to customers. Agile frameworks assume that we have a team with everyone and everything needed to deliver working, tested, documented, and deployable products. The implications of this assumption are that organizations will have to evaluate whether they are providing their teams with the tools and skill sets required to fulfill the business’ needs. This evaluation may lead to organizations finding that they need to hire people with different skill sets, provide training to their teams, and/ or invest in tools and infrastructure that enables the delivery of working tested product.
3. The second component of what makes agile frameworks effective is backlogs that are: Appropriately sized Ordered Prioritized Capture all the work needed to deliver end-product Simply having a backlog is only the first step, however. Once a backlog exists, it’s critical to ensure that the backlog truly reflects a deep understanding of priority, customer need, value, risk, and technical feasibility. Good backlogs provide teams with the confidence that they can pull work from the top of the backlog and expect it to be appropriately prioritized, sized, and detailed enough to create a common understanding, and provide clear direction.
4. The final component of what makes agile frameworks effective is the frequent delivery of working, tested product. In some agile literature, you will see the term “potentially shippable”. The concept of delivering “potentially shippable” product at the end of a given timebox (ideally, at the end of each sprint), requires a shift in how we develop, test, and validate work. In order to be able to ship product at the end of each iteration, we need the following: Deliverables meet acceptance criteria. (Requires strong and continuous collaboration with product owner and stakeholders). Deliverables have been reviewed and approved by product owner/ stakeholders. (Requires having product increments that are demoable and can be experienced by stakeholders). Deliverables have been tested, and are shippable. (Requires having clearly defined practices and tools for testing, for considering work “done”, and for releasing into a production-like environment). One final note on working tested product: Delivering to a production-like environment can be a powerful tool in ensuring that teams are producing increments of value each sprint. It is also a great way to get as much validation done as possible, since there is more at stake than when work stays on teams’ local environment. It is even more powerful to deliver to production, whereby teams start to consider factors like security, load, environment, and other factors that may impact the product in the real world. The decision to release to production is ideally a business decision. This means that the increments of working product should be at a level of stability and “doneness”, and the release environment should be stable enough that there are minimal technical considerations when deciding to release to customers. Rather, the decision should be based on business goals, market positioning, and other factors that impact timing of releasing product.
5. So, based on the previous slides, the way the 3 things work is by providing a framework and structure for Clarity, Accountability, and Measurable Progress within an organization.
6. Would you typically go to Basecamp 3 if you weren’t trying to position to slice out Basecamp 4 teams?