Agile and the Knowledge and Skills : Level 1
Agile and the Knowledge and Skills : Level 1
The Knowledge and Skills at the Level 1 are :
– Active listening
– Agile Manifesto values and principles
– Assessing and incorporating community and stakeholder values
– Brainstorming techniques
– Building empowered teams
– Coaching and mentoring within teams
– Communications management
– Feedback techniques for product (e.g., prototyping, simulation, demonstrations, evaluations)
– Incremental delivery
– Knowledge sharing
– Leadership tools and techniques
– Prioritization
– Problem-solving strategies, tools, and techniques
– Project and quality standards for Agile projects
– Stakeholder management
– Team motivation
– Time, budget, and cost estimation
– Value-based decomposition and prioritization
Active listening
One communication technique to reduce misunderstanding and miscommunication is active listening. A well run agile project necessitates both good listeners and communicators, active listening helps work towards both of these necessities. The basics of active listening include: 1) Being present and focusing your attention on the speaker. 2) Taking notes instead of interrupting. 3) Paraphrasing to confirm and review what you have heard. 4) Summarizing the conversation once it has concluded for posterity. Using open ended questions, good body language, and silence can help improve listening skills. [Coaching Agile Teams. Lyssa Adkins.]
Basics :
1) Being present and focusing your attention on the speaker
2) Taking notes instead of interrupting
3) Paraphrasing to confirm and review what you have heard
4) Summarizing the conversation once it has concluded for posterity
Using open ended questions, good body language, and silence can help improve listening skills.
Agile Manifesto values and principles
– Agile manifesto
The authors of Agile Manifesto are the founding members of Agile Alliance. Ken Schwaber founded Agile Alliance in 2001 after the Agile Manifesto was published.
Agile Manifesto values customer collaboration more than contract negotiation. Agile Manifesto values include the following: Individuals and interaction over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
Values
– 4 values
The Agile Manifesto defines four values. The four values list primary values and secondary values, with primary values superseding secondary values. The values are 1) individuals and interactions over processes and tools, 2) working software over comprehensive documentation, 3) customer collaboration over contract negotiation, and 4) responding to change over following a plan. [Manifesto for Agile Software Development. Agile Alliance.]
– Individuals and interactions over process and tools
This talks about value of empowering the team that far outstrips the benefits derived from processes and tools. We must constantly be aware that it is our people who actually do all the value added work, and respect for people is a comforting and fundamental principle of Lean and Agile.
Agile projects are built around motivated individuals and the team organize themselves without the command and control structure. The rest of the options are not correct since agile teams are highly disciplined, there is more planning in agile projects than the traditional projects and also the teams are motivated and empowered which enables them to deliver at sustainable pace.
– Working software over comprehensive documentation
– Customer collaboration over contract negotiation
– Responding to change over following a plan
Responding to change over following a plan – Agile Manifesto. The principle doesn’t devalue planning—just sticking to the plan. Planning is valuable in itself, and because the plan helps us recognize when things have changed; it helps us understand the implications of change, how we need to adjust, and the likely cost. The important thing is that, as we make plans, we understand that the plan may have to change. Planning is an ongoing time-boxed activity.
Though Agile Manifesto states that it values responding to change over following a plan, it should not be constructed as there is no need for planning on agile projects. In fact, Agile projects do overall more planning than the traditional ones.
– Secondary values
The agile secondary values include: documentation of software, processes and tools, contract negotiation, and following project plans. [Manifesto for Agile Software Development. Agile Alliance.]
– If you don’t follow the four Agile Manifesto values “It Will Create Risks”.
Principles
The Agile Manifesto defines 12 supporting principles. Agile principles include :
1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2) Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3) Deliver working software frequently, from a couple of weeks to a couple of months, with preference to the shorter timescale.
4) Business people and developers must work together daily throughout the project.
5) Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6) The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7) Working software is the primary measure of progress.
8) Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9) Continuous attention to technical excellence and good design enhances agility.
10) Simplicity–the art of maximizing the amount of work not done–is essential.
11) The best architectures, requirements, and designs emerge from self-organizing teams.
12) At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
[Manifesto for Agile Software Development. Agile Alliance.]
12 principles :
– Customer satisfaction
Satisfy the customer by delivering software that provides value to the customer early, and often.
– Welcoming change
It is expected that requirements will change and these changes are welcomed.
– Frequent delivery
Get working software delivered to the customer as soon as possible.
– Colocated teams
Bring the project team and the customers together, preferably collocated in the same physical area.
– Motivated individuals
Build your team around motivated individuals and trust them to do the work.
– Face-to-face contacts
Face-to-Face communication is the most effective method for exchanging ideas.
– Working software
True customer value is realized by delivering results, which is represented in terms of working software.
– Constant pace
Sustain a constant development pace to minimize project team burnout and maximize optimal performance indefinitely.
– Continuous attention
Continuous Attention to technical excellence and good design will allow the project team to respond more quickly and easily to change.
– Simplicity
Maximize the amount of work not done.
In agile processes, there is a strong taste of minimalism. Include only what everybody needs rather than what anybody needs. There is a point in time when any additional effort put into work product will increase its cost without increasing its value. It’s easy to continue developing a product beyond some point. A Standish Group survey in 2009 stated that over 70% of functionality is never or rarely used. Not doing that work is a great opportunity to do more valuable work.
– Self-organization
The team decides how the tasks will be allocated, as opposed to being dictated to them.
The best architectures, requirements and designs emerge from self-organizing teams. The emergent properties for a complex project are best generated from self-organizing teams in which the interactions are high and processes are low.
– Regular reflections
Schedule Retrospectives to constantly reflect on the work that was completed and find ways to improve during the next iteration.
The Agile Manifesto Principles as Months :
– January
Just Sit Together (Collocated Teams)
– February
Face-to-Face Contact (Face-to-Face Contact)
– March
Motivated Individuals (Motivated Individuals)
– April
Attention (Continuous Attention)
– May
Maintain a Constant Pace (Constant Pace)
– June
Jump on Improvements (Regular Reflection)
– July
Juggle Changes (Welcomed Changes)
– August
Augment Customer Satisfaction (Customer Satisfaction)
– September
Simplicity (Simplicity)
– October
Organization (Self-Organization)
– November
New Changes (Welcomed Changes)
– December
Deliver Frequently (Frequent Delivery)
The principles behind Agile Manifesto states that “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Answer ‘a’ is incorrect since embracing change will not curb uncontrolled changes. Answer ‘b’ and ‘d’ are again not reasons why Agile insists on embracing changing requirements.
The agile principles state without ambiguity that business people and developers must work together daily throughout the project. Answer ‘b’ says ‘regularly’ which may not be ‘daily’. Agile developers adopt practices such as on-site customer and active stakeholder participation which enable stakeholders to be actively involved with software development.
Fixed scope is not in line with the agile principles. One of the core principle of agile is to welcome changing requirements even late in development cycle for customer’s competitive advantage. The rest of the options are in line with Agile principles.
Agile project management
We apply empirical process control where underlying mechanisms are not well defined.
Agile project management differs fundamentally from traditional project management in the following ways: High-level project scope, multiple iterations of product development, teams are self-organizing, extensive customer involvement. [Manifesto for Agile Software Development. Agile Alliance.]
Key characteristics of agile project management include: continuous improvement, cross-functional teams, short iterations, an incremental approach, and business priorities and customer value. [The Art of Agile Development. James Shore.]
Jim Highsmith’s agile project management model consists of the following sequential five phases: Envisioning, speculating, exploring, adapting, and closing. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
5 phases
– Envisioning
The focus in the envisioning phase is on project vision, scope (and requirements), project schedule, and assembling a project team. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
– Speculating
The focus in the speculation phase is on estimating iteration and release plans, defining feature breakdown, developing a rough project plan, considering project risk and risk mitigation strategies, and estimating project costs. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
– Exploring
In the exploring phase, the agile team focuses on designing, building, and testing product features. This occurs within useful increments to the customer. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
When conducting the exploring phase, project leaders assist developers by removing any obstacles or constraints that my impeded progress, and managing interaction with product owners, customers, and other stakeholders. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
– Adapting
In the adapting phase, the agile team encourages feedback of the latest deliverable of an iteration. From the feedback, the team adapts product features and plans for the subsequent iteration. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
In the adapting phase, the agile team leader may make adjustments to the team makeup, like problems raised by team members, if any team dynamic problems arise. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
– Closing
In the closing phase, the agile team completes all remaining project work. In a software project, remaining work can be such tasks as user training documentation and installation manuals. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
Showing dependencies of one task on others is not a characteristic of an agile plan. Since in agile we focus on creating a pull system rather than push system and we start with a top level plan first.
Principle of last responsible moment
In agile we do things at last responsible moment. The stories should have details and acceptance criteria attached before they get developed not before they get estimated.
– Traditional project management
Definition of business objectives occurs during the initiating phase in a traditional project management effort. [Manifesto for Agile Software Development. Agile Alliance.]
– Agile and traditional project management
The agile and traditional project management methods share closing as a phase name. Closing occurs as the last phase in both methods. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
– Value chain
Collaboration, responding to change, working software and individuals and interactions are on the higher side of the customer value chain. Processes and tools, comprehensive documentation, contract negotiation and following a plan are on the lower side of the customer value chain.
The highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Assessing and incorporating community and stakeholder values
The following are community values of the PMI agile community of practice community charter: Vision, Servant Leadership, Trust, Collaboration, Honesty, Learning, Courage, Openness, Adaptability, Leading Change, Transparency [PMI Agile Community of Practice Community Charter. Project Management Institute.]
Brainstorming techniques
A successful brainstorming event should strive to consider the following points – Host the meeting in a neutral and comfortable environment – Have an engaging and experienced facilitator lead the event – Send participants an overview, with goals, schedule, and what ground rules, beforehand – Have a multi-disciplinary/diverse team to get a broader perspective – Delay any criticism that may stifle idea generation. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]
Brainstorming is a group activity held for the purpose of generating new ideas. The idea is that through collaboration, a team can generate more potentially valuable ideas than an individual, while at the same time forming a positive bonding experience for the team. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]
Building empowered teams
– Empowered teams
A team that is self-organizing and knows how to solve problems with minimal need for oversight.
Empowered teams – ones that are self-organizing and know how to solve problems with minimal management involvement – are a cornerstone of the agile methodology. This is the antithesis to the classic viewpoint of the traditional project manager who is seen as someone that controls all decisions and delegates tasks to a team with little feedback. An agile team must include all members and stakeholders to make decisions, and make decisions expediently. Because it is essential that the user/customer be involved with development, it is encouraged that the user/customer is closely integrated with the agile team with collocation/on-site support being ideal. An agile team feels empowered when it collectively assumes responsibility for the delivery of the product (i.e., taking ownership). [Coaching Agile Teams. Lyssa Adkins.]
Empowered teams – ones that are self-organizing and know how to solve problems with minimal management involvement – are a cornerstone of the agile methodology. An agile team feels empowered when it collectively assumes responsibility for the delivery of the product (i.e., taking ownership). [Coaching Agile Teams. Lyssa Adkins.]
Empowered teams take responsibility of the product and thus have a strong focus on delivering value.
Empowered teams need minimal management involvement and thus can focus on leading and delivering value instead of being lead
– Motivated team
Having a motivated team is essential for any project, regardless of whether it is agile or not. Motivated teams work together better, have strong productivity, and exceed expectations.
Some simple steps to increase motivation are :
1) spending quality time together; where team members get to know one another on a personal level to build a sense of community,
2) providing feedback, mentoring and coaching; where team members are congratulated and thanked on jobs well done and also mentored or coached to improve in skill and capability, and
3) empowerment; where the team is empowered to make many key decisions which, along the way, builds trust and shows that leadership believes in the capabilities of the team.
[The Art of Agile Development. James Shore.]
The best architectures, requirements, and designs emerge from self-organization teams.
– Leading
A common misconception in agile is that an agile team does not need a leader. In fact, all agile teams need a leader, but the way in which the leader leads is fundamentally different than the typical traditional project manager/project leader method. Some have theorized that this misconception stems from the desired ‘self-organizing’ quality of the agile team. And although the ‘self-organizing’ agile team is empowered to take ownership and responsibility of the product and make some decisions itself, it nevertheless requires a leader to help provide guidance, mentoring, coaching, problem solving, and decision making. Some key aspects required of an agile leader include: empowering team members to decide what standard agile practices and methods it will use; allowing the team to be self-organized and self-disciplined; empowering the team members to make decisions collaboratively with the customer; inspire the team to be innovative and explore new ideas and technology capabilities; be a champion of and articulate the product vision to team members so it will be motivated to accomplish the overall objective; remove any obstacles and solve any problems the team may face in its effort; communicate and endorse the values and principles of agile project management to stakeholders that may be unfamiliar with agile; ensure that all stakeholders, including business managers and developers, are collaborating effectively; and, be able to adapt the leadership style to the working environment to ensure that the agile values and principles are effectively upheld. [The Art of Agile Development. James Shore.]
Coaching and mentoring within teams
Coaching and mentoring within teams can be helpful for nascent agile teams and even for more experienced agile teams. Coaching and mentoring is the act of helping a person or team improve performance and achieve realistic goals. Because agile has a value of continuous improvement, coaching and mentoring is not solely for new or immature teams, but experienced ones too where coaching can help achieve higher levels of performance. The amount of coaching and mentoring an agile team needs is variable. Some newer teams will need a coach guiding the team nearly all the time while others may need a coach only for particularly challenging situations. A not uncommon scenario is to have a coach help the team collectively during sprint/iteration planning and then during the iteration help mentor individual team members. [Coaching Agile Teams. Lyssa Adkins.]
Communications management
– Effective communication
Effective communication is a cornerstone of agile. Communication is the act of transferring information among various parties. Communications management is a knowledge and skill area of agile that highlights this importance. PMI has several definitions regarding communications management and agile builds on top of these to add its own perspective: 1) Communications Planning: Determining the information and communication needs of the projects stakeholders 2) Information Distribution: Making needed information available to project stakeholders in a timely manner, 3) Performance Reporting: Collecting and distributing performance information. This includes status reporting, progress measurement, and forecasting, and 4) Managing Stakeholders: Managing communications to satisfy the requirements and resolve issues with project stakeholders. From an agile perspective: communication among the team is built into the process and facilitated through collocation, information radiators, daily stand-up meetings, retrospectives etc.; Although it is hoped that the product owner, customer, and user can be heavily involved with the project and also use these communication techniques, a plan for conveying information to stakeholders may be needed if this is not the case. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
– Documentation
Agile values working software more than comprehensive documentation but this doesn’t mean no documentation at all. Documentation should be written just in time and just enough.
Delivering comprehensive documentation will not deliver business value without working software. Historically, in software development, it’s been a priority to exhaustively document everything: requirements, design, test suites, correct usage, and so on. But that’s expensive; so expensive that often the software itself suffers from the effort devoted to documentation. So we don’t write documentation just because; we write documentation rather we do it when it has value and is required.
Feedback techniques for product (e.g., prototyping, simulation, demonstrations, evaluations)
There are several feedback techniques – techniques that facilitate constructive criticism to improve product value and quality – built into the agile process. In the classic definition, feedback is a dynamic process where past information influences the behavior of the same process in the future. Agile feedback techniques include prototyping, simulation, demonstration, evaluations, pair programming, unit testing, continuous integration, daily stand-up meetings, sprint planning. Because agile prides itself on a transparent and collaborative environment, feedback is essentially ubiquitous. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]
Incremental delivery
A cornerstone of Agile development is ‘incremental delivery.’ Incremental delivery is the frequent delivery of working products, which are successively improved, to a customer for immediate feedback and acceptance. Typically, a product is delivered at the end of each sprint or iteration for demonstration and feedback. In this feedback technique, a customer can review the product and provide updated requirements. Changed/updated/refined requirements are welcomed in the agile process to ensure the customer receives a valuable and quality product. A sprint or iteration typically lasts from two to four weeks and at the end a new and improved product is delivered, incrementally. [The Art of Agile Development. James Shore.]
Knowledge sharing
In agile, effective ‘knowledge sharing’ is a critical factor for success. It involves the near real time communication of key information among all team members and stakeholders. To promote knowledge sharing, agile uses standard practices built into its process, such as using generalized specialists/cross functional teams, self-organizing and self-disciplined teams, collocation, daily stand-up meetings, iteration/sprint planning, release planning, pair programming and pair rotation, project retrospectives/reflection, and on-site customer support. And, of course, the sixth principle of Agile is » The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. » In this sense, Agile prefers and encourages collocation for all stakeholders and team members for the simple fact that face-to-face conversation is the best method of communication and, in turn, effective knowledge sharing. [Becoming Agile:… in an imperfect world. Greg Smith, Ahmed Sidky.]
Leadership tools and techniques
Team is responsible for creating and enforcing the ground rules, scrum master should ensure that team does it.
Prioritization
The relative ordering of user stories with respect to value and risk.
An agile team must always face the prioritization of product features in its product backlog. From release planning to iteration planning, an agile team must prioritize the user stories/features of its product to ensure that high-quality and high-value features are developed first to help facilitate an optimized and early return on investment (ROI). An agile team typically prioritizes requirements or user stories/features in terms of relative value and risk; value is defined by the customer (i.e., customer-value prioritization). Two common methods to prioritize product features are: MoSCoW and Kano. The MoSCoW method categorizes features into ‘Must have,’ ‘Should have,’ ‘Could have,’ and ‘Would have’ features. The Kano method categorizes features into ‘Must haves (threshold),’ ‘Dissatisfiers,’ ‘Satisfiers,’ and ‘Delighters.’ Must haves are features that are requisite. Dissatisfiers are features that adversely impact perceived value and should be eliminated. ‘Satisfiers’ are features that increase perceived value linearly, where the more you add the more the customer is pleased, but are not required, and ‘Delighters’ are features that increase perceived value exponentially to please the customer. To prioritize features based on risk, a risk-to-value matrix can be used. A risk-to-value matrix has four quadrants, with the horizontal axis having low and high value, and the vertical axis having low and high risk. User stories are assigned to one of the four categories/quadrants: low-value, low-risk; low-value, high-risk; high-value, low-risk; high-value, high-risk. A cost-to-value matrix can also be made in this manner. All prioritization in agile is ‘relative,’ meaning that the priority of one user story is relative to other user stories and not prioritized on a fixed scale. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
In iteration planning, an agile team, collaboratively with the customer, chooses user stories to include for development. Although the user stories are prioritized in the product backlog initially during release planning, an agile team and customer should review prioritization based on progressive elaboration (i.e., gained knowledge and perspective). Prioritization is often based on value and risk and can be performed using the MoSCoW or Kano method and through the use of risk-to-value and cost-to-value matrices. An agile team performs decomposition to subdivide user stories into more manageable tasks so that it may estimate task time. Tasks for an iteration may also be prioritized based on value, similar to how user stories are prioritized. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
The relative ordering of user stories with respect to value and risk :
– Cost-to-value matrix
To prioritize features based on cost, a cost-to-value matrix can be used. A cost-to-value matrix has four quadrants, with the horizontal axis having low and high value, and the vertical axis having low and high cost User stories are assigned to one of the four categories/quadrants: low-value, low-cost; low-value, high-cost; high-value, low-cost; high-value, high-cost. All prioritization in agile is ‘relative,’ meaning that the priority of one user story is relative to other user stories and not prioritized on a fixed scale. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
– Risk-to-value matrix
To prioritize features based on risk, a risk-to-value matrix can be used. A risk-to-value matrix has four quadrants, with the horizontal axis having low and high value, and the vertical axis having low and high risk. User stories are assigned to one of the four categories/quadrants: low-value, low-risk; low-value, high-risk; high-value, low-risk; high-value, high-risk. A cost-to-value matrix can also be made in this manner. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
– Kano
The Kano method categorizes features into ‘Must haves (threshold),’ ‘Dissatisfiers,’ ‘Satisfiers,’ and ‘Delighters.’ Must haves are features that are requisite. Dissatisfiers are features that adversely impact perceived value and should be eliminated. ‘Satisfiers’ are features that increase perceived value linearly, where the more you add the more the customer is pleased, but are not required, and ‘Delighters’ are features that increase perceived value exponentially to please the customer. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
– MoSCoW
The MoSCoW method categorizes features into ‘Must have,’ ‘Should have,’ ‘Could have,’ and ‘Would have’ features. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
Problem-solving strategies, tools, and techniques
Literally thousands of decisions are made in the course of a project. Many of these decisions are made in response to problems that inevitably arise and confront the agile team. Therefore it is essential that an agile team is properly versed in problem-solving strategies, tools, and techniques. Some common problem-solving techniques include: ask it loud; revisit the problem; 5Y; sunk cost fallacy; devil’s advocate; be kind, rewind; asking probing questions; and reflective/active listening. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]
– 5 Y
Five (5) Whys is an iterative question-asking technique used to explore the cause-and-effect relationships underlying a particular problem. The primary goal of the technique is to determine the root cause of a defect or problem
– Common problem-solving techniques
Ask it loud
Revisit the problem
5Y
Sunk cost fallacy
Devil’s advocate
Be kind
Rewind
Asking probing questions
Reflective/active listening
Project and quality standards for Agile projects
– Agile project management
Key characteristics of agile project management include: continuous improvement, cross-functional teams, short iterations, an incremental approach, and business priorities and customer value. [The Art of Agile Development. James Shore.]
– Agile triangle
The agile triangle includes value, quality, and constraints as its parameters. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
– Agile iron triangle
The agile iron triangle includes cost, scope, and schedule as its parameters. Constraints is a parameter included in the agile triangle, not
The agile iron triangle. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
– Agile project management model
Jim Highsmith’s agile project management model consists of the following five phases: Envisioning, speculating, exploring, adapting, and closing. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
– Agile project management phases
The agile project management phases, in sequence, are: Envisioning, speculating, exploring, adapting, closing. [Manifesto for Agile Software Development. Agile Alliance.]
– Envisionning
The focus in the envisioning phase is on project vision, scope (and requirements), project schedule, and assembling a project team. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
– Speculating
The focus in the speculation phase is on estimating iteration and release plans, defining feature breakdown, developing a rough project plan, considering project risk and risk mitigation strategies, and estimating project costs. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
– Exploring
When conducting the exploring phase, project leaders assist developers by removing any obstacles or constraints that my impeded progress, and managing interaction with product owners, customers, and other stakeholders. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
In the exploring phase, the agile team focuses on designing, building, and testing product features. This occurs within useful increments to the customer. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
– Adapting
In the adapting phase, the agile team encourages feedback of the latest deliverable of an iteration. From the feedback, the team adapts product features and plans for the subsequent iteration. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
– Closing
In the closing phase, the agile team completes all remaining project work. In a software project, remaining work can be such tasks as user training documentation and installation manuals. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
– Works
Completing remaining project work
Authoring user documentation
Authoring product release instructions
– Agile development process
The agile development process has multiple iterations that focus on specific product features, encourages heavy customer feedback, and is adaptive to changing customer requirements. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
– Iteration
A cornerstone of Agile development is ‘incremental delivery.’ Incremental delivery is the frequent delivery of working products, which are successively improved, to a customer for immediate feedback and acceptance. Typically, a product is delivered at the end of each sprint or iteration for demonstration and feedback. In this feedback technique, a customer can review the product and provide updated requirements. Changed/updated/refined requirements are welcomed in the agile process to ensure the customer receives a valuable and quality product. A sprint or iteration typically lasts from two to four weeks and at the end a new and improved product is delivered, incrementally. [The Art of Agile Development. James Shore.]
– Project and quality standards
Refined over time.
All agile efforts have project and quality standards that the team defines collaboratively at the beginning of an effort and refines collaboratively throughout the effort. Project and quality standards help an agile team with team cohesion and provide a structure, albeit one that can adapt as the project evolves, to promote a self-disciplined environment. There is no ‘one size fits all’ standards definition in agile; because every project is different, it has been shown that the team should define which project and quality standards it should hold itself against and strive to conform to those standards while also being open to adapting those standards throughout the project to optimize performance and delivered value. Project standards can range from where the daily stand-up meeting is located and how long each participant has to share his or her progress and challenges to highly specific software coding styles, methods for test-driven development, and what the team’s definition of ‘done-done’ means. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
– Traditional project management phases
The traditional project management phases are typically introduced in the following sequence: Initiating, planning, executing, monitoring and controlling, and closing. It is important to note that monitoring and controlling happen concurrently and throughout the project life-cycle with other phases. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
Stakeholder management
Stakeholder management is a growing topic area within strategic management that brings awareness to the importance of managing stakeholders (i.e., facilitating active participation of stakeholders and fostering a strong collaborative environment) for a project’s success.
Stakeholder management is typically defined in the context of guiding principles and values.
R. E. Freeman’s ‘Managing for Stakeholders’ includes 10 principles :
1) Stakeholder interests need to go together over time.
2) We need a philosophy of volunteerism – to engage stakeholders and manage relationships ourselves rather than leave it to government.
3) We need to find solutions to issues that satisfy multiple stakeholders simultaneously.
4) Everything that we do serves stakeholders. We never trade off the interests of one versus the other continuously over time.
5) We act with purpose that fulfills our commitment to stakeholders. We act with aspiration towards fulfilling our dreams and theirs.
6) We need intensive communication and dialogue with stakeholders – not just those who are friendly.
7)Stakeholders consist of real people with names and faces and children. They are complex.
8)We need to generalize the marketing approach.
9) We engage with both primary and secondary stakeholders. 1
0) We constantly monitor and redesign processes to make them better serve our stakeholders. Because stakeholder involvement is critical for the success of a project, where projects without active participation from stakeholders are prone to failure, stakeholder management should be a topic that every agile team knows well.
[The Art of Agile Development. James Shore.]
Team motivation
Having a motivated team is essential for any project, regardless of whether it is agile or not. Motivated teams work together better, have strong productivity, and exceed expectations. Some simple steps to increase motivation are 1) spending quality time together; where team members get to know one another on a personal level to build a sense of community, 2) providing feedback, mentoring and coaching; where team members are congratulated and thanked on jobs well done and also mentored or coached to improve in skill and capability, and 3) empowerment; where the team is empowered to make many key decisions which, along the way, builds trust and shows that leadership believes in the capabilities of the team. [The Art of Agile Development. James Shore.]
– Simple steps to increase motivation :
1) spending quality time together; where team members get to know one another on a personal level to build a sense of community
2) providing feedback, mentoring and coaching; where team members are congratulated and thanked on jobs well done and also mentored or coached to improve in skill and capability
3) empowerment; where the team is empowered to make many key decisions which, along the way, builds trust and shows that leadership believes in the capabilities of the team
Time, budget, and cost estimation
Time, budget, and cost estimation is an important knowledge and skill area of agile. According to Highsmith, the nature of the agile method, whereby it welcomes changing scope, means that it lends itself well to fixed budgets and a fixed schedule because changing scope makes it difficult to estimate a total cost. Generally speaking, the budget and schedule constraints are known but before a project will commence there needs to be an agreed upon set of base product functionality defined in an initiation phase; fixing scope reduces an agile team’s innovative tendency to provide improved value. For companies that are familiar with fixed-price contracts, where requirements are agreed upon before contract closing, adopting agile can be a weary initial venture. Instead, other contract vehicle types are recommended for agile efforts. These include: a general service contract for the initiation phase and separate fixed-price contracts for iterations or user stories; time-and-material contracts; not-to-exceed with fixed-fee contracts; and, incentive contracts (e.g., fixed price with incentive; cost-reimbursable with award fee). [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
Best contracts :
– A general service contract for the initiation phase
– And separate fixed-price contracts for iterations or user stories
– Time-and-material contracts
– Not-to-exceed with fixed-fee contracts
– Incentive contracts (Cost-reimbursable with award fee, Fixed-price with incentive)
Value-based decomposition and prioritization
In iteration planning, an agile team, collaboratively with the customer, chooses user stories to include for development. Although the user stories are prioritized in the product backlog initially during release planning, an agile team and customer should review prioritization based on progressive elaboration (i.e., gained knowledge and perspective). Prioritization is often based on value and risk and can be performed using the MoSCoW or Kano method and through the use of risk-to-value and cost-to-value matrices. An agile team performs decomposition to subdivide user stories into more manageable tasks so that it may estimate task time. Tasks for an iteration may also be prioritized based on value, similar to how user stories are prioritized. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
Leave a Reply
You must be logged in to post a comment.