The Eight Principles of DSDM

There are eight principles of DSDM, and you’ll find that they are very much like Scrum and XP. The eight principles also reflect aspects of the Agile Manifesto. These eight principles of DSDM are represented graphically in Figure 3.1.

Focus on the Business Need: You’re probably starting to see a pattern between frameworks and methodologies like Scrum, XP, and now DSDM, because many are about focusing on the business needs and understanding the priorities necessary to meet requirements. For many projects, a valid business case must come before any official kickoff or planning of the project/iteration can begin.

Part of maintaining that business need is to ensure that there is continuous business sponsorship and commitment. Another aspect of this is guaranteeing delivery of a minimal usable subset or aspect of the whole that can be used and tested. Basically, like XP and Scrum, DSDM is a piece/part that is usable but not the finished product. To do that, the team must determine the most notable features and make sure that they are in the ultimate solution no matter what.

Deliver on Time: Timeboxing the work is a theme in Agile projects as is focusing on business priorities, always working to hit your deadlines, and building confidence through predictable delivery of usable increments. Therefore, all iterations in all methodologies are timeboxed in some way, shape, or form.

Collaborate: Another universal theme is stakeholder engagement, collaborative environments, and involving the right stakeholders at the right time throughout the project life cycle. The collaboration efforts are proactive across the board, and business representatives are not protected from the potential of being included in those collaborations. All teams are empowered to make decisions in order to best represent customer needs and to maintain a “one team” culture. This cultural philosophy creates buy-in. If everyone is on the same team, from business representatives to developers, then everyone owns the result.

Never Compromise Quality: No matter what types of project management methodologies you subscribe to, quality management is always important. Many notice a distinct overlap between Scope and Quality, and I’m often asked about the difference Scope is building the right thing, and Quality is building it right.

Never compromising on quality focuses on agreements on the level of quality that is necessary before any development begins. What are the tolerance levels that are acceptable if quality results fluctuate? How can you build quality into the plan so that you build quality into the increment? The focus here is to ensure that quality is not a variable that can come and go but rather that everyone agrees never to compromise on quality.

Quality is a pay me now or pay me later situation. If you pay now to build quality into the design, it costs less than fixing defects after the fact, not to mention an organization’s reputation can be damaged exponentially, which in most cases isn’t a quantifiable loss but one that is felt the most. Quality can be managed effectively by testing early, often, and appropriately with frequent reviews.

Build Incrementally from Firm Foundations: Much as you wouldn’t want your home built on a foundation that wasn’t solid, the DSDM framework is about building incrementally from firm foundations. What this really means is making sure that appropriate analysis is done and there’s “enough design up front,” or EDUF, to create as strong a foundation as possible. We do know that priorities change, and with that foundations change as well. Thus, you will need to reassess priorities formally and determine whether the project is still viable after the delivery of each increment.

Develop Iteratively: What makes Agile methodologies so different from Waterfall is the understanding that iterative developments and change are a fact of life in the Agile world. Not to say that Waterfall projects don’t experience progressive elaboration, changes, and even the dreaded scope creep! However, because Waterfall is more focused on a front-loaded plan with formal change control, making substantial change decisions on a regular basis is less likely to occur.

Waterfall methodologies plan first rather than going headfirst into a project knowing that most details will emerge later rather than sooner. Agile projects, on the other hand, focus on finding the right solution and proceed with the knowledge that the solution will not occur without embracing adaptability and change.

Part of iterative development is making room for business feedback and building it into each iteration while at the same time encouraging creativity, experimentation, learning, and even mistakes. Part of making mistakes is learning from them to help create the right solution.

Anyone who has never made a mistake has never tried anything new.

Albert Einstein

Communicate Continuously and Clearly: Communication is very important in all project methodologies and frameworks. Most project managers (Agile or not) spend about 90 percent of their time communicating. But what about the rest of the team?

One of the coolest things about Agile methodologies is that there’s total encouragement of informal face-to-face communication at all levels on a regular basis. There is also encouragement for many different forms of timeboxed communication, including daily stand-up meetings, facilitated workshops, modeling, and prototyping, all designed to help manage the expectations of stakeholders at all levels throughout the project.

Part of the importance of communicating continuously and clearly is that everyone understands the evolving solution, and it is demonstrated early and often enough to maintain that understanding. Notice that I didn’t say heavy documentation and massive amounts of status reports, because in this case, documentation is expected to be lean and timely. Face-to-face communication is the preferred method. The overarching philosophy of continuous and clear communication is making sure that we always aim to be honest and transparent in all communication.

Demonstrate Control: You can demonstrate control effectively by using DSDM by utilizing low-tech, high-touch information radiators that are visible to all. All Agile frameworks promote visual information radiators.

Demonstrating control is also a philosophy of proactive management and continuous reassessment and evaluation of the project viability based on the current objectives of the business. Finally, control is demonstrated by understanding what level and format is considered appropriate for formal tracking and reporting.

Kanban Board

The Kanban board is not only a visual representation of work that needs to be done, is being done, and is done, but it is one of the most popular ways to radiate information to multiple stakeholders at one time. The Kanban board is considered to be low-tech and high-touch, meaning no technology is used and everyone has a hands-on way of moving work through the process flow Figure 3.2 shows an example of a Kanban board.

What is so cool about the visual process that Kanban uses is that it represents a pull system. Work is pulled into the iteration when other work is completed. You know that a backlog is dynamic and ever changing. You also know that value changes based on the needs and wants of the customer. By using a pull system, the product owner can determine what backlog items should be done next. The team will select the work that they can accomplish in the sprint or iteration. Once the work is accomplished, it moves to acceptance and other work is pulled into progress. Once the work is considered done, it can be deployed. Many people who use this process use large white boards and Post-it notes to display backlog items, selected work, work in progress (WIP), and what’s been done and deployed.

The Six Principles of Kanban

The six principles of Kanban are as follows:

1. Visualize the workflow
2. Limit work in progress (WIP)
3. Manage flow
4. Make policies explicit
5. Implement feedback loops
6. Improve collaboratively, evolve experimentally

The Six Principles of Kanban Simplified

The six principles of Kanban review the cycle of understanding the workflow intellectually and allowing for consistent feedback and improvement as work progresses.

1. Visualize the Workflow: See the work and the policies that determine how the workflow is currently and will be executed. This does several things: It improves the overall process iteratively, helps to embrace necessary changes, and allows for learning from ineffective changes. This is why the Kanban boards are so useful, because they keep the workflow front and center, and they show a map of where you begin and where you end. Once workflow is understood then change for the better and optimized workflow can occur.

   The Kanban board is always within eyesight, leaving very little question as to the work that needs to be done or what work has been completed or deployed. This low-tech, high-touch way of radiating information is more effective than status reports because it is so visual. The brain processes visual images 60,000 times faster than it processes text, and therefore Kanban/Scrum boards are highly valuable in a fast-paced Agile environment.

2. Limit Work in Progress (WIP): Limiting work-in-progress is the crux of Kanban. Nobody takes on too much or too little work. If WIP is limited via the pull system and implemented on parts or all of the workflow, then each step in the workflow is limited. New work is only “pulled” into the next step when there is available capacity. Limiting WIP is a large part of many Agile methodologies and frameworks. You’ll review WIP in the chapters based on adaptive planning and continuous improvement.

3. Manage Flow: Even though change is necessary to improve process or products, sometimes too much change can wreak havoc on process flow. A key aspect of managing the flow effectively is to only create changes in the process once the change is understood. This can be done by assessing all impacts on other areas of the project that could be a result of the change.

   If you have ever attempted to make a change in one area of a project and then witnessed the domino effect after the change was implemented, you know why this is so important. For example, let’s say that you change the scope of work without consideration for time and money and now you are over budget and behind schedule. This is all due to not assessing the impact of the change and how it was implemented. Managing the flow and only implementing changes that are really necessary keep the things moving efficiently and remove waste from the process.

4. Make Policies Explicit: Having rules and policies that are well known by everyone takes the guesswork out of the equation. Having a rule that all policies are explicit seems odd, but if everyone understands the policy and procedures, or the definition of done, there is a better chance that rational changes in process when and if needed will be better implemented and more effective.

5. Implement Feedback Loops: Better understanding through feedback improves the process and the result. In a continuing trend of effective communication and colocated teams, it’s easy to see that everything under the Agile umbrella follows a similar theme. Visual workflow and self-directed and self-managed teams that are colocated are all considered important aspects of effective feedback loops.

6. Improve Collaboratively, Evolve Experimentally: For sure, this is easier said than done, and there are a variety of methods, both scientific and not, that can be used to evolve as an organization.

Many of the Agile and quality management methodologies came from collaborations between Japan and the United States as organizations moved from the industrial age and entered the technical age. The knowledge transfer of Kanban still applies whether you are mass producing bicycles or creating cutting-edge software. Kanban is a deep concept with very simple ideals. Improve your process, use only what you need at the time until you pull more work in, organize around the work, and utilize visual workflow.

The Seven Principles of Lean

The seven principles of Lean are as follows:

1. Eliminate Waste: Maximize value.
2. Amplify Learning: Via Frequent Communication and Feedback
3. Decide as Late as Possible: Early Planning, Late Decision Making
4. Deliver as Fast as Possible: Maximize ROI.
5. Empower Team: Self-Managed and Trusted
6. Build Quality In: Quality Assurance Rather than Quality Control
7. See the Whole: See the system not the parts of a system.

How Lean Complements Agile

Lean complements Agile in four very distinctive ways, and it works to optimize flow efficiency across the entire value stream. The four ways are easily understood and necessary to keep the process flowing in the right direction.

• Build the right thing: Understand and deliver real value to real customers.
• Build it fast: Dramatically reduce the lead time from customer need to delivered solution.
• Build the thing right: Guarantee quality and speed with automated testing, integration, and deployment.
• Learn through feedback: Evolve the product design based on early and frequent end-to-end feedback.

Implementing Lean Software Development: From Concept to Cash (Poppendieck, 2006)

The Seven Wastes of Lean Manufacturing

The goal in manufacturing is to keep things Lean, which is impossible if you’re producing the opposite of value. In any Lean project, waste is the opposite of value. The term waste started in the late 1940s at Toyota when they were looking to reduce manufacturing costs to keep the budget, you guessed it, lean. Because Toyota was mass-producing vehicles, the concepts of Lean manufacturing came well before Lean in Agile software development. While there is overlap in some concepts, there was a need to adapt it specifically to software development.

First, it’s important to understand where and how the original Lean framework began before jumping directly to software.

The original seven wastes of Lean manufacturing were identified in A Study of the Toyota Production System by Shigeo Shingo (Productivity Press, 1989):

1. Overproduction
2. Extra processing
3. Transportation
4. Waiting
5. Motion
6. Defects
7. Inventory

The Seven Wastes of Lean Manufacturing Simplified

To remove waste from the manufacturing process, it was important to identify what the causes were. After the wastes were identified effectively the organization could determine how to remove them from their value stream.

1. Overproduction: Producing more than the demand requires Overproduction costs organizations every single year, not just in money but in labor, parts, and leftover inventory, which potentially will not be sold due to lowered demands. It’s a gamble for organizations who mass produce to forecast how many/how much they should produce in a market that is typically fickle. Better forecasting methods are necessary not to overproduce, and this is typically why a Kanban pull system approach works well in this environment.

2. Extra processing: Additional steps in the process that aren’t really needed Extra processing is like the continuous integration practice in XP’s software development. If things get complicated or you are spending too much time on the process steps, it is necessary to implement process improvement and simplify the value stream.

3. Transportation: Shipping the increment from one place to the other Many manufacturing organizations produce one part or piece of an increment and then transport it to another location that makes a different part or piece. This slows the progress from concept to delivery. Even though this can’t be helped in many cases, it is better to have many locations that are all set up to produce one full increment themselves to reduce handoffs.
4. Waiting: Lag between process steps If you have ever had to wait for someone else to finish their work before beginning yours, and then you find yourself with limited time to do your piece, you know what this feels like. I would imagine that you would be engaged in much arm crossing, foot tapping, and passive-aggressive sighing. Waiting is time wasted.

5. Motion: Moving around within the process What is the shortest distance between two points? A straight line, of course. Too much motion or extra steps produce defects and wastes time.

6. Defects: Flaws in the deliverables that impact their features/functionality Defect repair is very expensive, and a lot of quality management methodologies incorporate a pay-me-now or pay-me-later situation. Organizations spend money upfront to make sure that the process produces quality deliverables through quality assurance and quality control procedures. I’m sure that you have heard on the news recently of many companies that have to do recalls on defective parts, equipment, and products. It’s expensive and bad for the organization and its reputation.
7. Inventory: Unfinished goods Keeping items in inventory that will not be sold, used, or finished takes up precious square footage that could be used for other things. It’s what I refer to as organizational hoarding.

The Seven Wastes of Lean Software Development

The goal of Lean software development is to apply a framework around reducing the day-to-day items that create noise in the process. The goal is to determine relatively quickly what that noise is and continuously answer the questions of where are the time wasters, the extra steps, or the general problems in our process and our product. Figure 3.3 illustrates the seven wastes of Lean software development.

The Seven Wastes of Lean Software Development Simplified

Since Lean software best practices were derived from Lean manufacturing, the framework involves a similar thought process. Remove waste from the system of software development and focus on continuous improvement.

1. Partially Done Work: Remember when your parents told you to eat all of your vegetables? Of course, you would take a small bite and hide the rest under your mashed potatoes or feed it to the family dog. Afterward, you would triumphantly announce that you were done and hope that nobody noticed. When your parents did notice, they reminded you that you only partially ate your vegetables and were in fact not done. Even worse, you were wasting food.

   The same thing applies to partially done work. It does not meet the definition of done, it can’t be released or used in a demo, and the code is nowhere near deployable. What may have caused this is that you didn’t realize how complex the technology needed to be prior to the plan and have now wasted time and resources. Believe me when I say that it’s a similar feeling to getting busted by your parents when hiding your vegetables. Except in this case, it is your customer instead of your parents.

2. Extra Features: Goldplating in any project is considered a big no-no! Goldplating is, in its simplest form, giving the customer extra features or added functionality that they did not request. This shows that you did not understand the vision or understand the target end user and/or have incorrectly prioritized the value and produced to an incorrect spec. In a lot of organizations, this will result in mediocre quality and scope creep, which will in turn be a waste of time or money.

3. Relearning: You might be thinking, “What is wrong with learning?” Learning provides value, and it’s important to learn as much as possible. You are correct, but relearning something you already knew at some point is wasted time.

   Think about a time when someone on your team asked you to do something again that you hadn’t done in years. You have a vague recollection of how to do it, but you still need to Google it on the sly. Yep, that’s relearning. Lack of documentation, poor coding practices, and consistent task switching between team members all create chaos as each one attempts to relearn something they moved on from in the past.

4. Handoffs: In many organizations, there is a hierarchical set of processes in place and many hands and eyes will be involved in projects. This is the equivalent of “too many cooks in the kitchen.” If you have too many dispersed team members, and the information is not well communicated or visible, then handoffs will create chaos. Every cook adds salt to the soup, and before you know it the soup is ruined.

   This can be managed effectively by using cross-functional teams, which is a major theme in all Agile projects. This means that one team contains all of the knowledge it needs to be effective across all functionalities.

5. Delays: Delays in any form are always a nightmare. Think about sitting in an airport; you’re ready to leave on vacation, and then you hear that dreadful announcement that your flight is delayed (or worse still, canceled)! You’re vacation has gotten off to a poor start, indeed.

   In this scenario, you are a customer and the delay is keeping you from doing what you want to do. This form of waste is usually due to not having enough people to do the work, or overestimators and overachievers who select too much work than can be accomplished in an iteration. Oftentimes, delays can’t be helped because external dependencies get in the way, or there is a significant lack of estimation experience or simply generic estimating, which can result in major delays as well. Delays are the opposite of Lean.

6. Task Switching: How many of you are currently working on more than one project at a time? I’m sure that many of you virtually raised your hand or just nodded your head and sighed. This is certainly not uncommon in the project management industry, and in most cases we have more work than we can handle. If that is the case, then you are jumping from one thing to another and going in 800 different directions at the same time.

   The myth of multitasking is the perception that you are being super productive when in fact it is quite difficult. Task switching really muddies the waters and makes it impossible to have a shared vision when you’re expected to have visions about multiple projects. Task switching creates waste, and it does so because there are too many projects going on, which leads to poor estimation, poor analysis, and a lack of a shared vision. Having a cross-functional team will prevent many of the handoffs that create waste in the system due to switching tasks on a regular basis.

7. Defects: Nothing creates more waste than defects in the increment. Even in Waterfall projects, there are specific quality assurance and quality control processes of audits and inspections to make sure that the process flow is working and that defects are minimized. Is it possible to be 100 percent perfect all of the time? Not at all, but there are steps that you can take to narrow the gap. By refactoring on a regular basis, having a shared vision and true understanding of what the customer is looking for can help exponentially. By following a comprehensive quality assurance process, you can continually audit whether the process is working, and you are continuously improving by reducing defects iteration to iteration. This is the key to removing the waste of defects.

Continuous Improvement

Several methods of continuous improvement can be found in Kanban, Lean, or other Agile environments. The main goal is to figure out (using the entire organization dynamic to do so) what is causing the waste or lack of improvement in the process and the results. Many times, as you saw in Lean, waste can happen in the process, the inventory, the team, and the product. To avoid that, you can look to philosophies that guide us in the right direction.

There are three very common philosophies that resonate with Agile frameworks.

1. The Theory of Constraints (TOC): The TOC study of bottlenecks in the process flow happens by identifying constraints and focusing on how to alleviate them by restructuring around them. Otherwise, organizations will be affected by a significant lack of meeting or achieving their goals. One bad apple can spoil the bunch, and because of that it is important to focus your efforts on ongoing process improvement to exploit the constraint(s) and remove them.

2. The System of Profound Knowledge: This is the title of a study by W. Edwards Deming of variation and how it affects processes. Deming’s significant contributions to organizations in Japan and the United States are well-modeled theories found in many project management methodologies and quality philosophies. Deming utilized the adaptation of the Shewhart cycle of Plan-Do-Check-Act for continuous improvement of best practices in quality management. The cycle can also be translated to follow a Waterfall approach of planning, execution, monitoring, and controlling. The System of Profound Knowledge uses four specific ways (or “lenses”) to view the world all at once:
   1. Appreciate a system by understanding the processes used.
   2. Understand variation, why defects occur, and why there is a range of variation. Statistical sampling in mass production allows for the review of one result that will represent a part of the population. Inspect that and see if there is a range that meets tolerance levels. If not, then the process is out of control.
   3. Understand psychology and theories of the mind and human behavior. This allows for a better understanding of the people doing the work.
   4. Understand the Theory of Knowledge (Epistemology), a philosophical approach to knowledge and justifiable belief systems.
3. Lean Economic Model: This model is based on the concepts of “waste.” It was first implemented by Toyota in order to improve its production systems by eliminating the three major constraints to effective production, which are interconnected and work together to wreak havoc in a production system and in process flow:
   1. Muda, or Waste: The seven wastes of lean, which Kanban helps to solve.
   2. Muri, or Overburden: Overworked employees or poorly functioning machines will create overburden. It is necessary to remove overburdening from the process flow.
   3. Mura, or Unevenness: Variations in the process can create waste (muda) and overburdened employees (muri). Mura contributes to a vicious cycle if not managed appropriately.

Much of what you just read is easier said than done, as are most philosophical approaches to project management. I call it “perfect world project management.” As organizations recognize the waste in their process flow, identify too many defects in their products, and recognize a faulty process system in general, the more necessary it is to attempt to attain a semblance of order. Lean and Kanban philosophies apply to both industrial and knowledge work, and they have been proven to work time and again in multiple industries and are flexible enough to converge with other frameworks. The theory of Kaizen, or continuous improvement, may be a moving target, but it is a target that all organizations should aim for. Being Agile is the goal.

The Five Processes of FDD

There are five processes attributed to FDD, of which the first three could be identified as part of Iteration Zero, or in FDD, initial project-wide activities. When you have a much larger team, it is important to get your ducks in a row and figure out how you are going to produce the expected result. Much like Initiation in a Waterfall project, Iteration Zero, or initial project-wide activities, helps to create a plan in advance and develop ways to prove the direction in which the project is headed. It also helps answer the question: Will the direction we want to head in work well before we actually begin heading in that direction?

1. Develop an Overall Model: The first step of Iteration Zero is to develop a model for the tasks and determine how quality checks will occur in execution as well as the problems that will need to be solved.
2. Build a Features Lists: A feature is a small, client-valued function that needs to be developed and is usually written out and broken down by three aspects: <action> <result> <object>. This allows the team to zero focus in on what exactly they are attempting to build and gain consensus on the main features that provide value.
3. Plan by Feature: This is the last step in planning, or of Iteration Zero. Initial schedules and assignments are created. The planning team will initially sequence the features based on current business value and determine how to achieve them.
4. Design by feature: In this step, a design is created for each feature. A chief programmer selects a small group of features that are to be developed within two weeks but leaves some time and room for inspection to occur.
5. Build by Feature: Any activity designed to produce a completed client-valued function (feature) is planned with the idea that it will be built during the iteration. In this case, work is executed in order to produce the feature selected for development.

Because tailoring is becoming so popular in project management, it might be relevant for your team to have an Iteration Zero on a large project, with multiple team members working on something totally unique and new. It’s a chance to plot your strategy and map out your way through the project before too much time and money is spent doing the wrong things.

Best Practices of FDD

The best practices of FDD are as follows:

1. Domain object modeling
2. Developing by feature
3. Individual class (Code) ownership
4. Feature teams
5. Inspections
6. Configuration management
7. Regular builds
8. Visibility of progress and results

Best Practices of FDD Simplified

Even though FDD isn’t the most talked about or popular Agile framework, I find it resonates with many of the Waterfall projects I have worked on in the IT sector. Knowing and determining what the features were in advance was commonplace, and then working to determine how to achieve those features involved owning the processes and achieving the goal. To me, FDD is really a simplified way of running a waterfall project in an Agile or software development environment that you can’t expect to be successful with the use a heavier framework.

1. Domain Object Modeling: Exploring and explaining the domain of the problems to be solved can provide an overall framework and approach. This is very much like the Initiation best practices found in the PMBOK^® Guide and Project Management Institute, A Guide to the Project Management Body of Knowledge, (PMBOK® Guide)—Sixth Edition, Project Management Institute, Inc., 2017 other Waterfall types of methodologies.
2. Developing by Feature: Any function that is too complex to be implemented within two weeks is further decomposed into smaller functions. This is a lot like taking a bigger deliverable to the task level or decomposing a work breakdown structure (WBS) used in Waterfall projects to the activity level.
3. Individual Class (Code) Ownership: The programmer/developer is responsible for the consistency, performance, and conceptual integrity of the code, as opposed to collective code ownership found in other methodologies.
4. Feature Teams: These are small, dynamically formed teams that develop a small activity and work on a feature while the rest of the team does the same. They allow pockets of cross-functional team members to work together on the same outcome rather than one large team working in a swarm.
5. Inspections: These are carried out to ensure excellent quality, design, and code, primarily by detection of defects if any.
6. Configuration Management: This is the process of identifying features completed to date and maintaining a history of changes. Configuration management is a type of formal change control system that is specific to product changes not seen in many Agile types of projects.
7. Regular Builds: Up-to-date systems can be demonstrated to the client and help highlight integration errors early. The more regular the build, the more feedback that can be obtained.
8. Visibility of Progress and Results: Frequent progress reports help managers focus a project correctly. Visual progress or transparent placement of progress and results keeps everyone on track and focused on the goal.

Crystal Family Color Codes

Crystal methods are a family of methodologies color-coded and customized by team size and the criticality of the project. Once that is determined, the project is placed based on the scale, and a method is chosen from a range of scalable models. The family of color codes is a lot like when you see a high terrorism alert from the government. They say it is code red, and everyone is on high alert.

In Crystal, it is a similar thought process. If I have a very heavy project with a lot of critical needs, then I need to scale my model to a weight that can work effectively for the outcome. The heavier the project, the heavier the need to scale up in process. The less critical the project, the greater the need to scale down. Crystal is a flexible model, and deciding which to use is based on the criticality of the project and what scale is needed to complete the work appropriately. The family of Crystal begins with Crystal Clear and ends with Crystal Sapphire:

1. Crystal Clear: Smaller projects
2. Crystal Yellow
3. Crystal Orange
4. Crystal Orange Web
5. Crystal Red
6. Crystal Maroon
7. Crystal Diamond
8. Crystal Sapphire: Mission Critical

The Crystal Family

The Crystal family uses “criticality” to determine what project goes in what color, from low to high, by using a point system based on categories like life, essential/discretionary money, and comfort. Based on the score, a determination can be made of how critical the project is. Then the selected family and their best practices will be utilized. A scalable model like Crystal is something of a one-stop shop for best practices in Agile. It is the most lightweight and adaptable Agile methodology.

The big focus outside of determining the color code are the core tenants of teamwork, communication, and simplicity. Reflection is used frequently to adjust and improve the process. Crystal also promotes early, frequent delivery of working software, high user involvement, adaptability, and the removal of bureaucracy or distractions.

This sounds like many of the frameworks and best practices you have read about already. The resounding themes across multiple Agile methods and frameworks are the focus on communication, delivery early and often, and adapting to changes as needed but keeping things as simple as possible.

Adaptive Software Development Cycle

Rapidly changing conditions mandate the need to be adaptive and flexible. The adaptive software development (ASD) cycle very simply represents the continuous sequence of adaptation in software development. Figure 3.4 is a graphic depiction of the adaptive software development cycle.

Adaptive Software Development (ASD) Cycle Simplified

The name adaptive software development cycle really describes its focus. Develop software, but be prepared to adapt by speculating, collaborating, and learning as you go. Even though the cycle sounds a bit vague, it is a good reminder to all of us working in Agile environments to be constantly checking ourselves, collaborating, communicating, and finally, learning from both our success and mistakes, using what we have learned in an effective and adaptive way.

1. Speculate: The project is launched and adaptive cycle planning is conducted using what was learned from project initiation information. For example, the customer creates a mission statement depicting what they want from the results. Typical project constraints like time, cost, scope, and quality are reviewed. The basic requirements are documented to define the set of release cycles or software increments that will be required for the project.

   As the title suggests, this is all speculation at this point because nothing specific has been proven, and you know that customers always change their minds. Today’s mission statement could be tomorrow’s trash, but the act of speculation allows for a direction to be chosen and the ability to move forward while knowing that changes will occur and embracing them.

2. Collaborate: Collaboration is crucial to any Agile type of project, as is adapting to uncertainty. Open dialogue is necessary to combat the wrench throwers of technology, requirements, scope changes, risks, stakeholders, and vendors/suppliers.
3. Learn: What you will see in a lot of these methodologies is the ability to make mistakes and learn from them. How do you learn? You challenge the status quo and even stakeholders if necessary.You will also run in short iterations of design, build, and test. During these iterations, knowledge is gathered by making small mistakes based on false assumptions and correcting those mistakes as you go. This practice leads to a better experience, better assessment, and eventual mastery in the area where the problem lies.

Three Main Aspects of Leading an Agile Project Effectively

The main aspects of leading an effective Agile team are to practice leadership and continuously aspire to learn innovative ways of leading. Servant leadership is a key mindset for Agile, and practicing the tasks of servant leadership is the icing on the cake of a highly effective Agile project manager.

Three Main Aspects of Leading an Agile Project Effectively Simplified

The three aspects, or trifecta, of Agile Project success, is to be an Agile project manager who practices the three principles illustrated in Figure 3.5: leadership, servant leadership, and leadership tasks.

1. Leadership: This is the practice of emotional intelligence and being able to adapt and adjust to the needs of your team. A certain amount of extroversion is also a good practice, because without engaging with your team members, you won’t know what is going on with them day-to-day. Active listening, being open to new points of view, diversity of thought, and consistent learning are all active traits of good leaders.

   I used to call project managers that stayed in their office all day, hovering over spreadsheets, “pod squatters,” because they just wouldn’t leave their offices to hang out with their team. I thought then (and still do) that they aren’t leaders at all—they are simply managers.

2. Servant Leadership: The servant leader is servant first and leader second. This may seem counterproductive, or as if their authority is somehow rapidly disappearing. I wouldn’t be surprised if this type of Agile project manager is foreign to a lot of managers today—maybe even your own manager!

   Servant leadership is for sure, the key to effective Agile project management. To get into the mindset of a servant leader, you first should know what that entails. The servant leader should provide what the team needs. It’s as simple as that. Easier said than done you say? You would be correct! The only way to know what your team needs is to ask them. This requires the emotional intelligence to identify and understand an undercurrent not expressed yet; you’ll need to apply your active listening skills to truly understand what you are hearing without thinking about what you are going to say next.

   Active listening is probably the biggest aspect of communication. My mother always said, “You have two ears and one mouth, use them accordingly.” I wasn’t listening at the time. It was only until I ran my first team that I understood what she meant. It’s not about me, it’s about them. Listening is the best way to know what the team needs and wants. If you are distracted by your own thoughts or words, you’ll never understand where the team is coming from.

   It is also your job to remove any roadblocks the team is facing, including pesky stakeholders who are interrupting their work and meetings. Perhaps the biggest aspect of this that makes project managers everywhere scratch their heads in disbelief is helping maximize productivity by taking on administrative work if the team starts falling behind schedule. Me take on administrative work? Yep, you read correctly. I hear collective groans everywhere! Think of it this way: the more you help your team to be successful, the more successful they will be. This isn’t just fortune cookie rhetoric; it is part of carrying the food and water of servant leadership. Jump in there and get your hands dirty with your team. Also, keep in mind that excessive documentation is considered wasteful, so it won’t be that bad to take on administrative work in an Agile environment.

3. Leadership Tasks: The ability to communicate the project vision as many times as needed for success is a large part of your day-to-day job. Doing so keeps the team focused on the why behind the work that they are performing. Keeping the team from being distracted by interruptions, whether from an outside source or by their own creation, helps promote their focus on the work. Remember, you are working in short iterations, so focus is necessary for successful completion. Remove roadblocks preventing the team’s success. Motivate, compensate, and encourage. (“Carry the food and water.”)