Concept Management Quarter

Iterative Development Quarter (hereinafter, the Quarter) is a lecture introducing the learners to portfolio implementations primarily through key topics related to iterative development. The Quarter is the last of four lectures of Portfolio Quadrivium, which is the first of seven modules of Septem Artes Administrativi (hereinafter, the Course). The Course is designed to introduce the learners to general concepts in business administration, management, and organizational behavior.

Outline

Enterprise Architecture Quarter is the predecessor lecture. In the enterprise design series, the previous lecture is Organizational Structure Quarter.

Portfolio implementation is the enterprise implementation of the enterprise portfolio. This lecture concentrates on iterative development because this development is the main technique to do that.

Concepts

1. Iterative development. The process of breaking down projects into more manageable components known as iterations. Iterations are essential in Agile methodologies for producing a potentially shippable deliverable or product.
   • Iterate. The act of repeating a process with the aim of approaching a desired goal, target or result. Each repetition of the process is also called an iteration.
   • Enterprise effort. A determined attempt or a set of attempts undertaken in order to create outcomes of a task, activity, process, project or operations, and/or enterprise.
2. Enterprise goal. A desired outcome towards which the enterprise effort is directed.
   • Goal (objective). Desired outcome or target.
   • Real goal. A goal that an organization actually pursues, as defined by the actions of its members.
   • Means-end chain. An integrated network of goals in which the accomplishment of goals at one level serves as the means for achieving the goals, or ends, at the next level.
   • Stated goal. An official statement of what an organization says, and what it wants its various stakeholders to believe, its goals are.
3. Vision statement. A formal articulation of an organization's vision or mission.
   • Business goal. A state or condition the business must satisfy to reach its vision.
   • Business policy. A business policy is a non-actionable directive that supports a business goal.
   • Business rule(s). A business rule is a specific, actionable, testable directive that is under the control of the business and supports a business policy.
   • Business plan. A written document that interprets the strategic plan for enterprise stakeholders, for instance, financial or governmental institutions with regard to a business opportunity and articulation of how the identified opportunity is to be seized and exploited.
4. Enterprise administration. Practice and a set of concepts, based on that practice, that define culture of administering all enterprise efforts from identifying business opportunities and up to getting of all enterprise outcomes and/or achieving enterprise impacts.
   • Administration. The process or activity of running a business, organization, etc. or the officials who executive that process or activity.
   • Management. The process or activity of dealing with or controlling things or people.
5. Strategic management. What managers do to develop the enterprise's strategies, policies, and operative rules.
   • Enterprise objective. A measureable step taken in order to achieve the enterprise goal.
   • Objective. A target or metric that an individual, group, and/or enterprise seeks to meet in order to progress towards a goal.
   • Strategic management process. A six-step process that encompasses strategic planning, implementation, and evaluation.
6. Iteration. A phase of agile development in which a deliverable (or the solution overall) is progressively elaborated upon. Each iteration is a self-contained "mini-project" in which a set of activities are undertaken, resulting in the development of a subset of deliverables, a set of features, or potentially shippable deliverable. An iteration takes a fixed or timeboxed period of time, generally spanning two to four weeks. A typical Agile project consists of a series of iterations, along with a Sprint planning meeting prior to development and a Sprint retrospective at the end of each iteration. Each iteration generally contains activities such as analysis, design, development, and testing. For each iteration, the team plans its work, does the work, and checks it for quality and completeness. Iterations can occur within other iterations as well. For example, an iteration of requirements development would include elicitation, analysis, specification, and validation activities. Iterations are referred to as Sprints in Scrum.
7. Sprint. A fixed-length time period during which a milestone is expected to be reached. Usually, one user story or product backlog item (PBI) must be transformed into a potentially shippable deliverable and ready for review. Each sprint is assigned a set amount of time to be accomplished (sometimes referred to as timebox), which could be anywhere from one week to one month, but typically lasts two weeks. In the Agile methodology, Sprints are referred as iterations.
   • Sprint goal (aka Sprint theme). The key focus of the work for a single sprint.
8. Kaizen. In Japanese, the word means "improvement". This is the philosophy of continuous process improvement using analytical tools and methods.
   • Paradox theory. The theory that the key paradox in management is that there is no final status for an enterprise.

Roles

1. Agile team. A work team that is responsible for committing to work, delivering and driving the product forward from a tactical perspective in terms of Agile methodology. Usually, an Agile team is a small, high-functioning group of five to nine people who collaboratively work together to complete an iteration or project. The team has the necessary skills and competencies to work on the project. Scrum teams are cross-functional; Kanban teams can either be cross-functional or specialists. Scrum teams lack any roles. Kanban teams usually have team leads.
   • Agile team member. A member of an Agile team. Often, Agile team include engineers, architects, developers, analysts, QA experts, testers, UX designers, etc.
   • Team lead. A team member who may or may not have authority over other team members, is appointed on permanent or rotating basis to serve one or more management functions such as (1) to represent the team to the next higher reporting level, (2) to make decisions or to make decisions in the absence of a consensus, (3) resolve conflicts between team members, and/or (4) coordinate team efforts. No team lead is appointed in Scrum.
2. Scrum role. One of the following: product owner, Scrum master, Agile team member.
   • Scrum master. A facilitator for the team and product owner. Rather than manage the team, the Scrum master works to assist both the team and product owner in the following ways: (1) Remove the barriers between the development and the product owner so that the product owner directly drives development. (2) Teach the product owner how to maximize return on investment (ROI), and meet his/her objectives through Scrum. (3) Improve the lives of the development team by facilitating creativity and empowerment. (4) Improve the productivity of the development team in any way possible. (5) Improve the engineering practices and tools so that each increment of functionality is potentially shippable. (6) Keep information about the team's progress up to date and visible to all parties. Scrum master is often viewed as the coach for the team.
   • Product owner. A person who holds the vision for the product and is responsible for maintaining, prioritizing and updating the product backlog. In Agile methodology, the product owner has final authority representing the customer's interest in backlog prioritization and requirements questions. This person must be available to the team at any time, but especially during the Sprint planning meeting and the Sprint review meeting. Challenges of being a product owner: (1) Resisting the temptation to "manage" the team. The team may not self-organize in the way you would expect it to. This is especially challenging if some team members request your intervention with issues the team should sort out for itself. (2) Resisting the temptation to add more important work after a Sprint is already in progress. (3) Being willing to make hard choices during the sprint planning meeting. (4) Balancing the interests of competing stakeholders.

Methods

1. Development methodology.
   • Methodology. A set of processes, rules, templates, and working methods that prescribe how business analysis, solution development and implementation is performed in a particular context.
   • Plan-driven methodology. Any methodology that emphasizes planning and formal documentation of the processes used to accomplish a project and of the results of the project. Plan-driven methodologies emphasize the reduction of risk and control over outcomes over the rapid delivery of a solution.
   • Change-driven methodology. A methodology that focuses on rapid delivery of solution capabilities in an incremental fashion and direct involvement of stakeholders to gather feedback on the solution's performance.
2. Agile methodology (or Agile development methodology). The project management approach of developing increments of prototypes and, eventually, the deliverable in frequent iterations based on evolving requirements. In other words, the Agile methodology is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of initial objectives. Instead of well-defined projects in the Waterfall model, the Agile one suggests a series of development sprints. This methodology emphasizes clearly-defined development rules with regard to both development and continuous feedback to refine the product scope rather than a predefined development process. This feature makes the methodology instrumental in those development that are inherently unpredictable. The Agile Manifesto was the initial public declaration for Agile methodology related to software. Its authors believed that they found "better ways of developing software by doing it and helping others do it."
   • Agile. (1) Able to move quickly and easily and/or (2) Agile methodology.
   • Scrum. The Agile methodology that features (a) a self-directed team with no specified project manager and no managers at all, (b) a high level of communication between team members especially through daily meetings called standups, and (c) a product owner who is responsible for continuous feeding tasks to the team. In Scrum, iterations are called sprints and are assigned a fixed length—sprints typically last one to two weeks, but can last as long a month.
   • Lean Agile methodology. An example of lightweight Agile methodology applied to project development. Lean Software Development combines the Lean manufacturing approach pioneered by Toyota in the 1950s (also known as just-in-time production) and Lean IT principles, and applies them to software. LSD places a strong emphasis on people and effective communication. LSD is defined by seven principles: (1) Eliminate waste, (2) Create knowledge, (3) Build quality in, (4) Defer commitment, (5) Optimize the whole, (6) Deliver fast, (7) Respect people
   • Lean UX. Inspired by Lean and Agile methodologies, Lean UX speeds up the UX process by putting less emphasis on deliverables and greater focus on the actual experience being designed.
   • Test-driven development (TDD). The practice of designing and building tests for functional, working code, and then building code that will pass those tests.
3. Kanban. (1) A highly visual framework that falls under the Agile umbrella. The Kanban process uses continuous work flow rather than fixed iterations to produce shippable deliverables. When applied over an existing process, Kanban encourages small, incremental changes to the current process and does not require a specific set up or procedure. Kanban focuses on completing entire projects rather than sprints; (2) A communication system that controls the flow of the shop, and synchronizes the level of production to customer demand, and normally uses standardized quantities and movement tickets which travel with the production pieces from operation station to operation station.

Instruments

1. Scrum meeting. One of the following: story time, Sprint planning meeting, Sprint review meeting, Sprint retrospective, daily standup.
   • Sprint planning meeting. A working session held before the start of each sprint to reach a mutual consensus between the product owner's acceptance criteria and the amount of work the development team can realistically accomplish by the end of the sprint. The length of the sprint determines the length of the Sprint planning meeting, with two hours being equivalent to one week of the sprint. Using this formula, the Sprint planning meeting for a two-week sprint would last about four hours, although this can vary.
   • Daily standup. A brief communication and status-check session facilitated by the Scrum Master where Scrum teams share progress, report impediments, and make commitments for the current iteration or sprint. The Daily Scrum consists of a tightly focused conversation kept to a strict timeframe; the meeting is held at the same time, every day (ideally, in the morning), and in the same location. The Scrum task board serves as the focal point of the meeting. During the Daily scrum each team member answers three questions: (1) "What have I done since the last Scrum meeting? (i.e. yesterday)" (2) "What will I do before the next Scrum meeting? (i.e. today)" (3) "What prevents me from performing my work as efficiently as possible?"
   • Story time. A regular work session where items on the backlog are discussed, refined and estimated and the backlog is trimmed and prioritized.
   • Scrum of scrums. A meeting that is a scaling mechanism used to manage large projects involving Scrum multiple teams. A Scrum of Scrums is held to facilitate communication between teams that may have dependencies on one another. One member from each team attends the Scrum of Scrums to speak for the team—this could be the Scrum Master but may be any team member who can effectively relay information and handle questions or concerns for the team.
   • Sprint review meeting. A meeting that a Scrum team holds immediately following the completion of a sprint to review and demonstrate what the team has accomplished during the sprint. This meeting is attended by the product owner or customer, Scrum Master, Scrum team, and stakeholders. The Sprint review meeting is an informal meeting (no Powerpoint slides allowed). The length of the sprint determines the length of the Sprint review meeting, with one hour being equivalent to one week of the sprint. Using this formula, the Sprint planning meeting for a two-week sprint would last two hours, although this can vary.
   • Sprint retrospective. A Scrum meeting held following the completion of a sprint to discuss whether the sprint was successful and to identify improvements to be incorporated into the next sprint.
2. DADI (or DADI pattern). The enterprise development pattern that divides enterprise administration in four batches: Discovery (D), Analysis (A), Design (D), and Implementation (I). Although the batches tend to be both consecutive and complete, this statement is rarely true. Most frequently, Discovery can occur at any time and the newly discovered data re-starts the process.

Results

1. Strategic plan. A plan that applies to the entire enterprise, formalizes its enterprise portfolio, and establishes the enterprise's overall goals. This plan also defines its business models and may or may not include related competitive strategies.
   • Strategy. The plan for how the organization will do what it's in business to do, how it will compete successfully, and how it will attract and satisfy its customers in order to achieve its goals.
   • Commitment concept. Plans should extend for enough to meet those commitments made when the plans were developed.
   • Roadmap. A strategic plan to create a product or complete a project. A roadmap describes the individual steps required to meet a set of goals or objectives.

Practices

• Some practitioners believe that business plans have no value for the business itself.

  No business plan survives first contact with customers -- Steve Blank, entrepreneur

  Indeed, it is impossible or almost impossible to predict revenues with no historical data. Furthermore, every bank asks about a business plan, but no real bank provides a business with external funding based on a business plan alone. Taking into consideration these observations, business plans may be considered as documents that banks need in order to report to the government and to use in their public relations that the banks support business.

Validated Learning Quarter is the successor lecture. In the enterprise implementation series, the next lecture is Project Management Quarter.