Topic 3 : The Agile Model
As Agile is a philosophy and toolset it now encompasses many sub-methods that embrace various agile principles. Whilst they may all be called Agile in nature they still differ in many significant ways. Just as each project or team is different, so too each variation of Agile has its strengths and weaknesses. Understanding these is the key to deciding which method might suit which situation.
For large scale enterprise projects it is possible for more than one method to be operating for different teams at different times. Blending these together into a cohesive result is not as simple as it might seem for methods that all support the same philosophy.
Explore some of the more popular Agile sub-methods, their strengths and weaknesses, as well as considering how they can work together. The integration of any Agile method into other organisational concepts is also examined. We will look at how these methods are similar as well as their differences.
Consider the following questions as a guide to understanding this topic. Ask yourself how well you understand these principles and how satisfied you are that you can explain them.
* Why is SCRUM the most common or popular Agile method?
* Why have different sub-methods of Agile come into being?
* Why are non-project elements of an organisation sometimes suspicious of Agile thinking?
* What is envision – speculate – explore – adapt – close?
* How is the Agile “lifecycle” different from the agile processes?
As we explore the methods of Agile take these considerations into account when forming your own opinions.
* Sometimes Agile can become too prescriptive to be considered agile.
* Governance is often handled differently in an Agile project.
* Stakeholder buy-in and management can be very different in Agile.
* Certain Agile methods do not translate as well between industries.
* A higher set of principles can be translated and found expressed in different sub-methods
Lecture 3A Agile Mindset
How do we handle the flow of decisions and the information that flows into those decisions. Unlike empirical projects the information comes in as we good, which makes it more important than conforming to a plan. The context needs to be stronger to make good decisions and deliver the value. The customer determines the value. Relies on empowered teams that capable and motivated. Not just about the tasks, but about the team.
We need a feedback loop with a quick cycle to incorporate the feedback, and long enough to implement - a timebox. Scrum is a widely used submethod of Agile thinking. Following a scrum there is a sprint, followed by another scrum. The timebox is the sprint - the distance that is covered. The scrum represents the feedback meeting.
Roles include the Scrum Master; the team champion and resource manager for the period of the sprint. The Product Owner effectively interprets the customer's desires within the team. They also handle the product backlog. It is important at the end of each sprint that what is produced is deliverable, definable, assessable, and gives value to the customer. The sprint planning meeting prioritises, estimates, and resources required. End of each sprint has a sprint review meeting which has feedback from the customer, as opposed to a sprint planning meeting. There are also daily meetings - a few minutes - which engage the Scrum Master in immediate concerns and exceptions.
The product backlog is a list of desirables, typically consisting of "user stories". Defined in such a way that is interpretative, is not a specification. Described in terms that are limited to the understanding of the user and interpreted from a technical perspective. First conceptualisation followed by the planning.
Kanban systems is about the sequence and flow of work in activity with the objective of reducing the amount of work in progress to manage efficiency. Avoiding bottlenecks in workflow and overcapacity. Most effective when things have to move through a sequence of activities, coming from a manufacturing origin. Implementing into a software project approach it's about providing activities "just in time". We need to respond things in a timely manner, we need a timebox.
The principle of lean is that deal only with what is needed. It is a bit of kaban (pay attention to flow) and scrum (pay attention to value). There is an emphasis on quantity and speed of learning, especially for the feedback loop to prevent wastage. Work-in-progress represents waste; completed work can be evaluated - this lines up with the concept of the sprint.
Extreme programming (XP) is a little like scrum for software developers and is a little more flexible in what can be done within a time period. Significant difference is software development issues e.g., testing, pair programming (one coder, one reviewer). Refactoring code to do the same job but in a better way.
Lecture 3B Enterprise Framework
An enterprise framework describes how Agile fits in a portfolio of projects in an organisation, rather than just an output and project level. The enterprise framework is operating at the business logic level. To do this the Agile framework is divided into layers which allows for different types of decisions in each layer, with different methods.
The layers include (a) governance layer, at the top, high-level executive decisions, the strategy, the investment, what resources, portfolios, etc., usually the less flexible of all the layers (b) the project management layer, the overall progress as a deliverable (c) the iteration layer, individual components including time-boxes and sprints, user stories (d) technical level, dealing with the direct implementation of tasks. Risk is handled differently in governance because money can only be spent once; it can't be iterated. How tightly do we couple investment decisions to delivery decisions?
Executives like to track risk, investment, architecture, and output. They seek to reduce risk, investment to align without output, and architecture - the leveraging effect (processes, skills, systems etc) - to grow so in the future lower investment can produce greater output.
The Project Manager layer is best understood by the layer below it. Closely aligned by the Product Owner. The higher levels of stakeholder engagement and management. Shield the production team from political and organisational issues; let the team deal with delivering value.
The Iteration layer is the layer of productivity, the production of value. Managing this is a detailed process working closely with the team, engaging in sprint planning and review, where leadership and mentoring occurs.
At the Technical layer how this is implemented is carried out.
Lecture 3C Delivery Framework
"Framework" is preferred to alternatives like "lifecycle", which is more linear and sequential. "Framework" is more like an eco-system with interpretative feedback. Initiation and closure is based on business principles and parameters. In the middle of the framework where agile activities (iterative, feedback) occurs. The steps in agile are more conceptual than being a proscribed process.
A simple definition: Evision-Speculate-Explore-Adapt-Close.
Envision phase replaces the more prescription-based Project Initiation phase. Puts focus on a clear vision, which is still separable and is not ambiguous. More general and interpretative as it will be shaped by the exploration and discovery that's about to come.
The Speculate phase is a replacement for the Planning face. Planning is about certainty, whereas speculation is about informed estimation. Speculation is about making the most sense you can from the information available at the time. Planning can create an artificial sense of certainty. Speculate phase looks at scale and nature of resources and expertise needed (and therefore cost), and the success criteria, and risk for mitigation strategies; all of which lends towards preparedness.
The user stories enter into the picture with the Explore phase with customer interaction. Look at desire and expectation from the customer and possibility and capacity from delivery team; what they want to what we can do. This is a transition to the iteration layer which breaks up the task into the components that can be produced and delivered.
Adapt is the concept of review and revision, enhancing the value of what is being delivered through management of feedback, gaining control with closer steps towards towards the outcome. Adhering in plan-based project avoids adapting. Adapting is responding to change in a positive and enhancing way, rather than a deviation in a plan from that perspective. Adapting is not considered a failure. After the Adapt phase the cycle returns to Speculate.
It is better to end a project in a controlled manner. Need to recognise the need for closure and the opportunity - and also for renewal. Project closure gives an opportunity to review of the satisfaction to the business objectives.
Slides and Lecture
Agile: Empirical, Iterative, Value, People, and Innovations
If you remove waste all you have left is value
Agile must interact with the organisation. The project is adaptable but the business usually is not
Methods include: Scrum, Lean, Kanban, Extreme Programming
Lean: Removal of waste, efficiency of action, opportunity cost, reduce delay, improve clarity, testing / auditing, leverage communication.
Kanban: The tracking of the flow, visualisation of the pipeline, change is more focused on how than what, change is gradual, respecting the existing. Suited more to maintenance than design
Srum: Product Backlog - Srum Sprint Planning - Sprint - Scrum Sprint Review - Product Backlog - Scrum Sprint Planning - Sprint
Agile must interact with the organisation. Its not just about the empirical; The project is adaptable but the business usually is not.
Governance: Concept - Expansion, Extension - Delivery.
Delivery: Envision - [Speculate - Adapt - Explore] - Close
Effective practice, not best practice
Reading : Chapter 5: An Agile Project Management Model
"One of the tenets of agile development is adapting to different situations... It is therefore difficult to make a compelling argument for standardization on a single agile method across a multinational organization." (p77)
[Project Governance [Project Management [Iteration Management [Technical Practices]]]]
"The overall Agile Enterprise Framework... The Portfolio Governance layer can offer some common checkpoints, and the Project Management layer can offer guidance to managing a variety of projects. The differentation between the Project Management and Iteration Management layers can offer insight differences between running a project and creating a release plan versus the day-to-day management of a short iteration... This structure facilitates organizations in building hybrid agile methods to suit their specific needs." (p78)
The Project Governance layer "... is a common framework for evaluating all .. projects ... that addresses the major executive concerns - investment and risk." (p79)
"[T]he Project Management layer focuses on overall project/release activities, assisting coordination among multiple feature teams, and managing project externals" (p79)
The APM Delivery Framework (p81)
Envision -> Vision -> Speculate Story Backlog
Speculate -> Release Plan -> Explore -> Complete Story -> Adapt -> Speculate ->
Adapt -> Final Product -> Close
"The departure from traditional phase names - such as Initiate, Plan, Define, Design, Build, Test - is significant. We have to learn to speculate and adapt rather than plan and build." (p82)
"The Envision phase creates a vision for the product teams that covers what, who, and how.. envision what to deliver... who will be involved... how they intend to work together" (p83)
Instead of a "plan", the speculate phase "consists more envisioning and exploring than planning and doing - it forces us to confront the reaity of today's precarious business and highly volatile product development environments" (p84)
"The Explore stage delivers product stories" (p84)
"After the Envision phase, the loop will generally be Speculate-Explore-Adapt, which each iteration successively refining the product" (p85).
Within the Explore Phase of 1-n iterations
[Iterative Delivery, 1-4 weeks [Preparation and Plan, story development] [Development, programming, testing, requirements conversions] [QA and Acceptance Testing] [Review and Adapt, customer focus group, technical review] ]
Reading : Chapter 12: Governing Agile Projects
"How do we move from agile projects to agile organisations? ... The concepts and practises are not limited to development teams, so executives need to understand how agile development impacts their organizations, project portfolios, and overall project governance." p307
"In terms of project governance, executive are interested in two things - investment and risk. ROI includes three components - value produced (inflows of money), costs expended (outflows of money), and time (timing of inflows and outflows)" (c.f., opportunity costs), p308
"The critical issues for organisations, then, is bridging this seeming gap between linear investment decisions and iterative/agile product development. The solution is separating governance from operations and then loosely coupling them - abandoning the tight coupling that led to the trouble in the first place." p308
"For exploration projects, specifying detailed requirements won't reduce serious risks. Only exploration into the problem space reduces these risks. Exploration may take the form of simulations, models, prototypes, engineering breadboards, feature builds (for software), or in some cases scientific or engineering investigations. For these types of risks, months of planning and product specifying contribute mightily to cost, but little to reducing risk" p309
"Gate reviews aren't about deliverable check-offs; they're are about providing executives and managers with relevant information about continued funding and acceptable risk" (p311)
".. in reality, every project has incremental funding. Even in a waterfall project, executives retain the ability to cancel the project at the end of any phase. The difference in the agile project approach is that it produces incremental product, not just documents from activities .. The focus of agile development is on systematically delivering high-value product features and reducing risks." (p313)
"A waterfall approach assumes (implicitly) that completing the requirements phase reduces the most risk - an unlikely scenario for most projects" (p314)
"Phase-gate funding models can promote the idea that investment and risk can be managed best by a linear model, while at the same time promoting an iterative model for operational delivery. Agile projects, which consist of an iterative Evasion and Explore cycles, produce exactly what executives are looking for to make funding decisions. By separating, but linking, linear funding model with an agile development model, the needs of engineers for an innovative development process and executives for critical information to make investment and risk decisions are both fulfilled" (p316).
An Enterprise-Level Governance Model
"No projects, even agiles ones, should start instantly, but they should start quickly. The Concept phase has two overriding objectives - to create and confirm the vision for the product and to identify and mitigate risk... The Concept phase can be considered a proof-of-concept endeavour, not just a feasibility study or risk identification activity.. The goal of the Concept phase is to identify - AND mitigate - enough high-risk and uncertain items to make it possible to realistically plan the rest of the project" (p316-317)
Concept phase is followed by Expansion phase; "Expansion means just that - expanding on the work done in the Concept phase, specifically expanding to areas of lesser risk than those covered in the first phase" (p319) Nota bene: This is ridiculous. If it's not qualitatively different, it's not a phase, rather it's a detailed subphase.
Expansion followed by Extension: "The objective of the Extension phase should be to do more of what we already know what to do." (p319)
Extension followed by Deployment: "the Deployment phase is where the product is deployed into actual use". (p319)
"Most organization far too much time defining phases and processes when the time would be much better spend thinking about decision gates and the information needed to pass those gates" (p319)
"Managing increasing uncertainty is best accomplished by agile, flexible practises, whereas managing complexity requires additional structure. The most difficult projects are those that have high uncertainty, requiring greater agility, and high complexity that requires additional structure. Finding project leaders who can handle both agility and structure is a challenge" (p324).
Readings are from Agile Project Management 2nd edition (Jim Highsmith, Addison-Wesley, 2010)