Becoming Agile ...in an imperfect world
Brilliant book. I have a feeling that I am going to keep this within easy reach for some time to come and it may end up being one of those rare books that I re-read. Takes agile concepts and makes them practical. I feel like I can now see a way forward as to how we make a start on becoming agile within my department and will be putting this into practice over the next few months.
the technical practices that agile brings to the table—short iterations, test-first development, continuous integration—are not optional. Ignore them or leave them until later at your own risk.
the technical practices that agile brings to the table—short iterations, test-first development, continuous integration—are not optional. Ignore them or leave them until later at your own risk.
this book shows how to thoughtfully introduce agile into a company.
this book shows how to thoughtfully introduce agile into a company.
thank you to my daughter, Lauren, for listening to me go on and on about agile for years. Although only 10 years old, Lauren now has the skills necessary to lead any company in its move to agile.
You can view and download many of the graphics in full size from the publisher’s website: www.manning.com/BecomingAgile.
Manning’s commitment to our readers is to provide a venue where a meaningful dialogue between individual readers and between readers and the authors can take place.
Greg currently works for GS Solutions Group, helping teams become agile through training and adoption coaching.
Ahmed is frequently referred to as Dr. Agile on account of having developed a free online agile readiness assessment tool named Doctor Agile (www.doctoragile.com).
Ahmed is frequently referred to as Dr. Agile on account of having developed a free online agile readiness assessment tool named Doctor Agile (www.doctoragile.com).
You discover a missing requirement, you identify a technical constraint that prevents you from following your initial design, or a third party delivers their part of the project later than expected. These types of issues happen on every software project; and to ensure success, agile asks you not to be surprised but to continue to perform by adapting to the reality of the situation.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
It is important to note that you should welcome changing requirements, but no one said this change is free.
It is important to note that you should welcome changing requirements, but no one said this change is free.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Andrew Doran
Has got me thinking and wondering how a startup like Readmill approaches this. Some user feedback will go into the requirements but then also there are features that are on the backlog for a user that doesn't yet exist; a user that therefore can’t give any feedback.
If you have motivated team members they will find a way to give you their best;
Working software is the primary measure of progress.
The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
No code means no bugs. The more code you write, the more bugs your code may have. If something isn’t essential to the product, then don’t build it.
Andrew Doran
Less is more.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. We believe this is probably the most important principle of agility.
You acknowledge the fact that not all of the requirements will be completed by the delivery date. The important question to ask is whether you have delivered enough features to support a system that provides value to the customer.
In the construction industry, the plan-based approach is suitable: the blueprints, which are the requirements, are fixed and probably won’t change while the building is being built.
Blackberry.
Andrew Doran
BlackBerry.
First, the company will create a core team. The core team will be trained and mentored by the agile coach, Jim Moore. The core team will be in charge of reviewing the existing development process at Acme Media to see where agile practices can be injected. This team will consist of actual project team members. After the core team outlines a new process to test, a pilot project team will be selected to actually complete the pilot project.
Broke the development cycle into two feature sets, with the first cycle focused on the most critical features. If issues were encountered during the first cycle, work on the critical features continued into the second cycle.
the longer teams stayed together, the more knowledge they had about the software and customers, which led to quicker development.
You’ll have the equivalent of an iteration 0 when you begin your migration to a more agile process. You’ll need to put the foundation pieces in place that support an environment conducive to the migration.
You’ll evaluate features for their customer value, level of risk, frequency of use, and dependencies. This allows you to do the following: Estimate work and evaluate risks early in the process. Prioritize features in terms of customer value early in the process. Deliver features in usable subsets.
Many projects wait for a fire before identifying their priorities. An agile team knows the project priorities in advance of an emergency and can react quickly to keep the focus on the main objective.
A secondary definition of agile could be continuous risk management. The processes are all intended to make the team alert and responsive to new information and changes as the project progresses.
“Deliver the project needed at the end, not the one requested at the beginning.”
Scrum may be more difficult to use with teams that do one-off projects versus steady-state releases, or if a team has highly specialized resources and skill sets.
Unlike Scrum, XP is specific about the practices that should be used during a software project. These practices include pair programming, TDD, continuous integration, refactoring, and collective code ownership.
Many companies implement an agile methodology and then fade back into their previous process because they didn’t cover all the delicate areas needed to ensure long-term support for agile.
Agile works best in an urgent environment.
Agile works best with a core group of people who work together on continuous projects.
If such team members view themselves as resources on loan, and not as team members dedicated to the project, the result can be functional silos.
If five to seven is perfect, then what is the maximum size for a team to remain agile? On the high side, we believe you can have a team of 15 people without major impact on your agility. When you have more than 15, communication needs to become more formal, which slows the team.
We’ve seen agile teams successfully use offshore resources for commodity or repeatable-type work, such as regression testing, smoke testing, and cookie-cutter development (for example, providing an offshore group with standardized tools to create automated workflows).
Fixed-bid contract work goes against most of the agile principles. The customer isn’t a partner, evolving requirements are a no-no, and adapting is usually called scope creep.
If you have a team that will work together for only one project, they’re usually better served by using a plan-driven methodology unless they have previous exposure to agile.
one of the biggest challenges to introducing agile methods in an organization is the lack of a detailed preliminary evaluation of the challenges this introduction may cause.
Appendix A contains the readiness-assessment tables for more than 20 different agile practices.
Readiness assessments are crucial before agile adoption.
By conducting readiness assessments, you can shorten the period of time during which a drop in productivity usually occurs with a major change initiative.
Why are you pursuing this initiative? What is the value of this initiative? What are the costs? What are the risks? What will it do for me?
Migrating to agile isn’t free, and it should be pursued only if it benefits the company and the bottom line.
your main expense will be obtaining a knowledgeable agile coach or consulting company to come in and train and mentor your team. This usually involves 2 to 10 days of training, with several phone calls and one-off consulting sessions post training. These services can run from US$2,000 to $50,000, depending on the length of the engagement and the level of agile expertise already present in your company.
patience is required during the first few projects.
consider the cost of not migrating.
Begin with projects that have medium priority, and work your way up to critical ones.
heavy consulting wasn’t required and, to a point, could be a hindrance. “You want the team to develop a deep understanding of the agile principles, but you don’t want someone to create the methodology for them.”
Jim suggested a 2- to 3-day session to teach the main principles to the core team and show them examples of how agile has been deployed at other companies. Then the core team could be turned loose on modifying Acme’s methodology, with Jim coaching along the way.
The role of this group, which we call the core team, is to learn as much as they can about agile and to use this knowledge to add agility to your existing process with the help of an agile coach. The team collaborates and reaches consensus on new processes; then they mentor project teams as they use agile techniques.
Imagine a tester going back to the testing team and excitedly telling them what is going on with the new methodology, or a developer doing the same with the development team.
the core team gains part of their power and influence from their status as doers.
You want the makeup of the core team to be similar to the makeup of the company as a whole.
You want the makeup of the core team to be similar to the makeup of the company as a whole.
After your team has been named, you should schedule a kickoff meeting to set expectations and goals.
You should follow Steve’s example during your migration, especially when it comes to emphasizing the importance of the work the team does and how valuable the methodology they develop can be.
Do your homework if you learn of a past failure, and make sure your plan covers the lessons learned from previous attempts to change processes.
The team won’t be forced to remove a legacy process if it’s proven and adds value. If this is true, there is a good chance the legacy process already supports an agile principle.
The methodology will be built iteratively and will be deployed iteratively to mitigate risk. In addition, the new process will not be used on a mission-critical project until it has been piloted and vetted.
a coaching engagement should always have a deadline so the team doesn’t become reliant on the coach.
While Light-Touch Leadership may be “light” in terms of decision making, it’s heavy in articulating goals, facilitating interactions, improving team dynamics, supporting collaboration, and encouraging experimentation and innovation. These characteristics of a leader are more critical to success than delegation of decision-making authority, but decision making is still an important piece of the leader’s role. When a good Light-Touch Leader is working, she or he is nearly invisible. Things seem to happen smoothly and the teams operate seemingly without a leader.
The most important role of the agile manager is to exemplify the agile principles and live them daily.
You need to get the team to inject the same urgency into an iteration that they do with a final deployment deadline.
ABO Continuum
Andrew Doran
Note to self to look this up.
we worry that some teams can become too dependent on the ScrumMaster.
collaborative, open, passionate, courageous, honest, lighthearted, driven, synchronized, customer focused, funny, responsible, innovative, and successful.
Andrew Doran
Agile team culture.
The culture is one of low politics and high transparency. Words are honest but not abrasive. Status is discussed in matter-of-fact terms. The team focuses on the situation, not the person.
There is no lying about how long it will take, in order to appease management.
An agile team focuses on the goal, not their job descriptions.
Everyone wants to work on projects that are important.
Employee evaluations should recognize and evaluate collaboration skills.
The core team lists the processes they feel are still valuable. They want to ensure that these processes are included in the new methodology. Many times, such “trial and error” processes are in line with agile principles and fit naturally into an agile lifecycle.
Requiring load testing for every release is an interesting step. In one sense, it doesn’t seem agile because it takes the decision out of the team’s hands. In another sense, it supports the agile principle of identifying and managing risk. When the Acme team designs their new process, their coach will ask them if they’re able to load test with automated scripts; if so, we’ll label this an agile process.
A collection of sticky-note comments after a first review of the existing process. If you have numerous suggestions, they need to be prioritized. Understanding agile principles is imperative before you perform this exercise.
Here are some of the topics and questions Acme’s core team discusses while developing their process:
Andrew Doran
These are great.
Your pilot project should have an overall completion estimate somewhere between a couple of weeks and a maximum of 8 weeks. If your project runs longer than this, you extend the time needed to record feedback on the process, which delays your ability to adjust your methodology.
They tell us that a short project for them lasts 6 months, and they don’t know how they can do a pilot that meets our criteria. You can handle this issue by finding a subset that meets the criteria of a shorter project. The question you need to ask is, “What do you do during a project that can be completed within 8 weeks?” You need to identify a group of features to serve as a mini-project within the larger project.
Your pilot project needs to have some level of urgency to test the new process under pressure; but if the project is deemed critical, failure isn’t a viable option. You may panic, abort, and revert to methods you’re more comfortable with to complete the project.
Your pilot project needs to touch all major areas related to projects at your company. You don’t need to go deep, but you should go wide.
Although your pilot will go wide, you don’t want to test outside of your company. The reason is that you’ll be busy watching the process within your company. Adding a third party into the mix may diminish your ability to record feedback and learn from the pilot. You can involve third parties in subsequent projects, when you have more bandwidth for their feedback.
It’s tempting to try to test agile area by area, but doing so usually leads to poor results. Your new agile process will be designed to have practices integrate with each other. This integration is where a good portion of the value comes from.
Damien Ryan
Getting Ops teams to see the value can be difficult, if not impossible. The major pushback I get from traditional IT people is constant questioning why everything needs to change so frequently.
Many repercussions can result if you don’t orient the project team to the value of the idea.
We suggest you create a time limit for feasibility work within your company, too. A good rule of thumb is 2 to 5 days.
They note these needs on the Feasibility Team Checklist shown in table 10.1. We suggest that you create a checklist similar to this one, tweaking it to reflect your organization structure and business model.
If you can free up the entire team for the Feasibility phase, and the entire group is about eight people or fewer, then we recommend having the entire project team involved in feasibility activities. In contrast, you may choose to limit involvement to the minimum amount of employees needed to explore the project for value. Many companies do this because they have a limited number of team members.
An average feasibility analysis begins with a 1- or 2-hour meeting that kicks off the process; at this meeting, one person discusses the known requirements with the feasibility team. The feasibility team reviews the idea with the presenter, and team members ask questions about the customer, the project’s value, and potential technology needs. (The next section describes a tool that can help during this process: the Feasibility Discussion Guide.)
While reviewing an idea, you may encounter showstoppers and then either find a solution or abort the project. It may be distressing to identify an issue, but at the same time doing so is a good thing. You haven’t designed or coded anything yet, so there is no code to throw away. Your investment has been minimal. Also, because the issue has been identified early in the cycle, you have the luxury of aborting or spending a little time to try to overcome the issue.
The feasibility team can provide extraordinary value. When your employees get comfortable with the process, it will be like having additional product managers. A competent team can identify issues with an idea and can also identify new opportunities that may be overlooked by a product manager working alone.
You may also have employees who are dedicated to a website or product within your company. If this is true, you have a permanent project team, and you don’t need to select one.
You need to review your pilot-team roster and determine whether the team has enough core-team members to support mentoring and hand-holding during the pilot.
A good rule of thumb is to ensure that the pilot team includes two or more core-team members.
If possible, have your agile coach provide the pilot team’s training, with core-team members contributing to the discussions. This process training takes one or two days and is slightly different for the pilot team. In addition to the fundamental principles and practices of agile, they also need training on how the core team has represented those principles in the custom methodology.
No matter what the feedback is, listen to the pilot team with an open mind. Where applicable, show them how the new design takes their concerns into account.
Because it is not high priority, Jay has only outlined light requirements. This works well for the pilot because most agile projects are initiated with light requirements.
The team will spend many hours trying to understand and define the features over the life of the project, and the customer can reduce this time by performing as much diligence as possible before meeting with the team.
Jay presents the Feature Description Document to the project team at the kickoff meeting and discusses each feature. The team asks questions to better understand the scope of the project.
The goal of creating a tradeoff matrix like that shown in table 11.4 is to be honest from the start and let the project team know what the priorities are in advance of any issues coming to light. Completing this exercise increases the probability of project success.
Similar to a charter, the worksheet is a useful tool for collecting project highlights and presenting them to a product manager, sponsor, or other interested party. The charter can also be posted on a prominent wall to remind the team what they signed up for.
You want the team to begin looking at the features from more of a user perspective now, so they’re relabeled in terms of “Ability to.”
Once you have a running backlog, anyone can populate it.
You and your team will need to break down the requests into features that can be completed in 10 days or less, or else your project will lose transparency and you will have deliveries that have to cross many iterations to be completed.
the words ability to are frequently included in the name to indicate what the user has the ability to do.
Andrew Doran
Is saying “The ability to...” better than using the “As a user...” style of requirements? What do people do in the real world?
Estimated work effort (ideal days) —Total labor estimated to be needed for the feature. It’s a summary of the task estimates on the back side of the card. This field is used only for the first iteration of a project.
Story points will be your main metric for determining capacity as the project proceeds.
feature cards aren’t supposed to replace functional specifications. The feature-card exercise helps your team assess the level of documentation or information that is needed to build the feature. This documentation may include use cases, wireframes, mockups, usability studies, or other requirement artifacts.
The methodology doesn’t dictate the documentation needed for each feature: the team does.
You can also use these guidelines to determine whether your feature cards contain the correct amount and type of information: The functionality described is understandable to users. The card describes functionality, not an implementation task. There is enough information to estimate the implementation effort. The card generally represents 1–10 days’ worth of effort, or it fits in your story point scale (which we’ll discuss later in chapter 14). Each card is as independent of the others as possible. The card is testable.
Some of the people we’ve worked with refer to feature cards as user stories on steroids. We believe this is an accurate description.
The main thing that makes feature cards different is the additional fields for uncertainty, dependencies, and frequency of use. By adding these fields, you make it easier for the team to prioritize and sequence features after the initial customer conversations.
The main thing that makes feature cards different is the additional fields for uncertainty, dependencies, and frequency of use. By adding these fields, you make it easier for the team to prioritize and sequence features after the initial customer conversations.
if use cases are used too early, they can create issues for a project:
there are two types of use cases: essential and real. An essential use case is closer to a feature card; the interaction listed is at a high level and isn’t implementation specific. A real use case describes the detailed interaction with the system, naming screens, databases, triggers, and other system artifacts.
we’ve learned that the best way to deal with large projects is to focus on identifying the critical features first and then use the feature-card process for the critical work. When we need to estimate all the work, we discuss themes for future phases and provide high-level estimates to stakeholders, but we don’t try to estimate a huge project in detail.
In our experience, we’ve gone a step further and created an electronics requirement package that auditors can reference. These packages contain customer discussions, wireframes, interactions diagrams, workflow diagrams, and sometimes use cases. We’ve also stored a record of test results and customer approval. The good news is that our feature cards, and everything we do in an agile environment, are focused around acceptance testing. Other than documenting results in a place they can be referenced, you shouldn’t need to make any process changes.
I suggest that you experiment with paper and electronic methods and then outline a custom process that works for your team.
Physical cards are extremely important for the feature-card exercise and later for release and iteration planning. Use electronic cards to supplement physical cards if you have constraints that limit the availability of physical cards to team members.
Interfaces always present risk. As a rule of thumb, feature cards that involve an interface should have technical uncertainty marked as high.
Third parties (vendors/partners) also represent high risk, especially if you’ve never worked with them before. You want features related to third parties early in the sequence also.
This first sort of the feature cards lets the team understand which features are critical, high, medium, and low. Note that another way of viewing the critical features is to say they’re the minimum features needed to deliver a functional application. Although you aren’t creating a release plan yet, the critical label gives you early insight into what the first iteration will probably contain.
The next sort relates to dependencies. Which features have a high dependency placed on them? What features tie to each other?
The Acme Team follows the dependency evaluation by reviewing feature risk. The team looks for high-risk features, knowing that they must be removed from the project or moved to the top of the sort.
The last step in Acme Media’s sorting exercise is grouping features. Acme needs to group features that must be used together to provide value to the user/customer.
We suggest that you hold off on estimating features until you’ve completed the sequencing exercise. The reason is you may identify several low-value items that you may want to remove from the project. If you remove them, you don’t need to waste time estimating them.
every project/release you perform includes some level of technical work, and this work must be prioritized with the customer-facing features.
The estimation process covered in this chapter is based on the teachings of Mike Cohn in Agile Estimating and Planning.
Andrew Doran
Also in my ‘to read’ pile.
there is a good chance you have volatile requirements, your customer needs to receive valuable software soon, and you must deliver your project in a lean method with limited waste. If this is true, you need an agile estimation process.
How can you improve the accuracy of your initial estimate without doing weeks or months of detailed feature analysis? The answer is story points.
Mike Cohn suggests that you first identify an item that is a 2 and then an item that is a 5. By selecting a 2, you still have room to list an item as smaller; if you identify a 5, you have room to estimate another feature as larger, and you also have the ability to compare a list item to two other list items (the 2 and the 5).
Mike Cohn suggests that you first identify an item that is a 2 and then an item that is a 5. By selecting a 2, you still have room to list an item as smaller; if you identify a 5, you have room to estimate another feature as larger, and you also have the ability to compare a list item to two other list items (the 2 and the 5).
If you don’t have consensus, you investigate why.
Andrew Doran
It’s a shame this isn’t taken further here. I assume you must reach consensus on your estimates? What if two people have different opinions and won’t budge?
We do create plans, but we do not fall in love with them.
Iteration 0 represents the time needed to prepare the project for development iterations. This work can include completing contracts with third parties, preparing development environments, preparing development machines, setting up a project wiki, obtaining funding, and organizing support tools such as bug trackers.
We suggest that you start with 2-week iterations and see how that timeframe works for you.
If you’re just becoming agile, it will be difficult to wrap up a sprint and start a new one in 2 days. A 1- to 2-day turnaround demonstrates a mature team with a well-oiled process. It will take time for your team to develop this rhythm.
As a starting point, we suggest that you space iterations approximately 1 week apart until your team matures around your agile process. You won’t be well oiled right out of the gate, and a week between iterations will let you breathe a little as you’re adapting to your new methodology.
In recent years, we’ve seen a shift in that mentality; many people now factor in production support when determining team capacity for an iteration. Many companies have only one team for projects and production work.
If you’re doing a pilot or first-time agile project, you don’t have any history on which to base your capacity. In this instance, you proceed to detailed planning of your first iteration. In detailed planning, you’ll have the team break down each feature into tasks and perform estimates at the task/hours-needed level.
Features may be dependent on each other to provide value, so you shouldn’t split them across iterations. For example, the ability to record seller feedback is of no value unless the ability to view seller information is also completed.
Andrew Doran
Not sure this is a great example. Surely you can deliver the ability to view seller information in one iteration and then the ability to record seller feedback in a later iteration? There is a dependency, but they are not interdependent?
The first objective of the kickoff meeting is to bring stakeholders and sponsors up to speed. The project team shares the information gathered during the feasibility and chartering exercises, including scope, benefits, key dependencies, constraints, risks, and the release schedule.
you should try to get as many team members to present as feel comfortable doing so.
You know that dates will change as you make discoveries during your project. Use the project kickoff meeting to stress this point with stakeholders.
the larger the project, the more need there is to create the plan electronically so that it can be distributed and viewed throughout the enterprise.
Mike Cohn makes a good suggestion, that you should not even propose a delivery date, but instead provide a delivery range so that expectations aren’t set for a specific date.
Andrew Doran
Fantastic idea.
We suggest reviewing the acceptance tests at the start of iteration planning. The team needs to have a good understanding of what success means before breaking down the work and identifying the tasks needed to complete it.
One process that we’ve found effective is feature-card modeling.
These features aren’t on the current list provided by the customer; they need to be encompassed in existing cards, or new cards must be created for them.
Code is worthless if it does not support the customer’s needs.
We suggest that you accept feature modeling as a reality of software development and do the work up front. It will reduce your overall cycle time for delivering features.
Your team reviews the workflow and screen layouts to identify the tasks they need to complete to build the feature. After they identify the tasks, they estimate them.
The team is committing to doing the work versus having a schedule forced upon them.
We suggest developing your team to a point that anyone can do any task, but this will take time and is rarely possible when you’re first moving to agile.
Over time, the team should cross-train and lose dependency on specific people for specific tasks; but on day one, specialization will probably be a reality, and you must plan capacity around that reality.
Many people believe that tools like Project imply formality and overhead, and they’re good only for traditional projects. We can tell you that this definitely isn’t true. It isn’t the tool that takes away agility but the way the tool is used.
The Progress Matrix allows Acme’s team to quickly digest status. The columns in the matrix convey completeness at each stage.
For our purposes, iteration 0 is the foundational work performed after initial planning but before development begins. Iteration 0 work usually runs for about a week, but it can take less or more time depending on project complexity.
For our purposes, iteration 0 is the foundational work performed after initial planning but before development begins. Iteration 0 work usually runs for about a week, but it can take less or more time depending on project complexity.
We’ve seen some companies perform architectural modeling without a customer advocate in the room. This is possible, but it’s critical to have the requirements drive the architecture, not the other way around.
Greg’s company has realized that this formal process can jeopardize projects that need to be delivered quickly to ensure benefits. To remove this issue and become more agile, Greg’s company has created a process that lets a team receive early funding before a project is formally approved. The team doesn’t receive enough funding to pay for the entire project, but they get enough money to keep working on the project while the final decision is being made and the value is validated.
We typically see architect involvement reduced by half after a project goes through initial planning. The architect will come back for several design sessions and to help Acme’s team resolve issues related to performance or scalability. This also frees the architect to work with other project teams that may just be getting started.
We typically see architect involvement reduced by half after a project goes through initial planning. The architect will come back for several design sessions and to help Acme’s team resolve issues related to performance or scalability. This also frees the architect to work with other project teams that may just be getting started.
we encourage agile teams to wait until the adapt period between iterations to look at noncritical issues that may have occurred in the production environment.
we encourage agile teams to wait until the adapt period between iterations to look at noncritical issues that may have occurred in the production environment.
When the development environment is prepared, you must consider all the ancillary tools and processes required to support the project.
Andrew Doran
How long does iteration 0 last when you team has no experience of continuous integration and automated testing tools?
When the development environment is prepared, you must consider all the ancillary tools and processes required to support the project.
Andrew Doran
How long does iteration 0 last when you team has no experience of continuous integration and automated testing tools?
Greg once worked for a company whose mission statement said it would “meet and exceed customer requirements in an effort to delight them.” This is a dangerous approach to take in software development. Getting code to a state where it can be deployed is challenging enough without adding bonus functionality.
In some sense, testing begins during the feature-card exercise. A QA employee should be in the room during the exercise to identify inconsistency in requirements, potential integration issues, validation of performance needs, and other technical constraints.
Because you’re on a tight schedule for an iteration (usually around 2 weeks), you can’t spend time trying to trace down team members and orchestrate a meeting in the next day or two. You don’t send emails and wait for people to respond. You need to work issues promptly and stay on schedule for delivery at the end of the iteration.
It occurs to Jay that Acme Media serves a wide geographic area and that buyers will want to filter by location when performing a search. Ryan can add that functionality to the search screen without a significant change in his effort, so they agree he should do so. They share this decision with the entire team to see if it has any effect on designs for the other features.
We frequently hear a team member say, “I’ve completed my first pass” at a task or feature, acknowledging that work on other features may require them to revisit their work. This approach is normal. Just be sure you don’t label a feature complete until everyone agrees it is.
a team that works together for a while develops a feel for who should do what on a given feature.
a team that works together for a while develops a feel for who should do what on a given feature.
the team isn’t large enough to begin all features at the same time, so they focus on features that are at the core of the functionality.
the team isn’t large enough to begin all features at the same time, so they focus on features that are at the core of the functionality.
Andrew Doran
Within an iteration.
The team also took digital pictures during their whiteboarding sessions and embedded the photos into the specifications for reference.
Greater levels of documentation are expected if the project or feature requires greater ceremony. This means you should create documentation if it helps the team get the job done or if you have a customer for the documentation. Agile teams must be careful to make sure they don’t skip creating documents because they consider paperwork anti-agile.
Greater levels of documentation are expected if the project or feature requires greater ceremony. This means you should create documentation if it helps the team get the job done or if you have a customer for the documentation. Agile teams must be careful to make sure they don’t skip creating documents because they consider paperwork anti-agile.
Greater levels of documentation are expected if the project or feature requires greater ceremony. This means you should create documentation if it helps the team get the job done or if you have a customer for the documentation. Agile teams must be careful to make sure they don’t skip creating documents because they consider paperwork anti-agile.
It’s common to iteratively build out features in parallel as team members discover feature dependencies.
It’s common to iteratively build out features in parallel as team members discover feature dependencies.
As features are completed, Gina pulls a feature and tests it. If a feature passes, it’s labeled test complete and put into a queue for demonstrations at the end of the iteration.
As features are completed, Gina pulls a feature and tests it. If a feature passes, it’s labeled test complete and put into a queue for demonstrations at the end of the iteration.
If a feature fails the test, it’s put back into the list of features and tasks.
If a feature fails the test, it’s put back into the list of features and tasks.
Work is a subjective term in an agile environment. Many times, you’ll spend more time resolving issues and researching technology than you’ll spend on coding.
Work is a subjective term in an agile environment. Many times, you’ll spend more time resolving issues and researching technology than you’ll spend on coding.
Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.
Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.
Numerous excellent resources can help you with unit testing. One of our favorites is The Art of Unit Testing by Roy Osherove.
A build took from 4 to 6 hours and pulled a developer away from their work.
The tester can bring up risks before the coding begins. In a way, this is early testing; you might even call it design testing. The tester can influence how the feature is created and so reduce the chance of bugs or issues with nonfunctional requirements, such as performance or up time.
In a perfect world, functional testing for each iteration would be complete at the end of the iteration.
Functional testing tries to make sure the software does what it’s supposed to. Exploratory testing tries to make sure the software doesn’t accidentally do things it isn’t supposed to do.
“The plan is useless; it’s the planning that is important.”
Take the world as it is, not as it ought to be.
Here are some of the ways we’ve seen teams adapt to feature overrun:
Continue the incomplete features into the next iteration. When you do this, you should still demonstrate status of the incomplete work.
Partial delivery is usually an iffy proposition. If a feature is incomplete, it will probably need some level of cleanup to be usable.
Stretch the iteration. As a rule of thumb, this isn’t a good practice.
We do a lot of interaction with developers by walking up and asking them if they have a moment to discuss a feature. In the old days, everyone was polite and said “Sure.” These days they frequently ask if we can come back later because they’re in the middle of solving something. We like this new attitude.
Smaller teams and smaller projects can probably go informal throughout the project. As projects get larger and have more customers and stakeholders, it may be best to do formal demonstrations in conjunction with User Acceptance Testing.
You have many options as you review issues within your team. Some common options are as follows:
Andrew Doran
Useful list.
you continually measure the number of story points you complete and add them into your running average. Your running average is the number you use to determine capacity for the next iteration you pursue. For this process to work, you must keep your iteration length consistent and the people on your team the same.
It’s a good idea to perform a quick retrospective between iterations. These meetings are typically informal, and the team can quickly identify areas to improve before the next iteration kicks off.
you may find that you need to stop during an iteration and review what is going on, especially when feature delivery is running late or when major process issues are being encountered.
Demonstration day is a special time for a project team. The team knows their work is valuable because people want to see it and ask questions about it. The demonstration also adds transparency to feature status. True status is evident to everyone.
you don’t complete your work by the end of the iteration date and the feature isn’t in a demonstrable state. What can you do? Here are some options we’ve seen teams use:
Andrew Doran
Useful.
The most important thing to remember is that you need to demonstrate, period.
The great thing about a regular release schedule is it gives you one solid reference point in a world of moving parts. The team acclimates to the deployment cycle, and the customer knows there is always another bus coming if a feature request doesn’t make it into the current release.
determining whether there is enough value to deploy is a subjective exercise.
In the early days of software projects, we had hard rules like “We won’t deploy with any level-3-severity bugs.” This was a nice rule, and we tried to follow it; but at every release, push came to shove, and we had to make the call about whether to miss our date or let some level-3 bugs go out with the deployment.
Andrew Doran
We've all been there.
In the early days of software projects, we had hard rules like “We won’t deploy with any level-3-severity bugs.” This was a nice rule, and we tried to follow it; but at every release, push came to shove, and we had to make the call about whether to miss our date or let some level-3 bugs go out with the deployment.
Andrew Doran
We've all been there.
platform availability target of 99.5 percent. This means the company’s sites can be down for approximately 400 hours in a year.
platform availability target of 99.5 percent. This means the company’s sites can be down for approximately 400 hours in a year.
The metric for data recovery is Recovery Point Objective (RPO), which is specified as the number of minutes of data that can be lost during a failure.
The metric for data recovery is Recovery Point Objective (RPO), which is specified as the number of minutes of data that can be lost during a failure.
Your Recovery Time Objective (RTO) specifies how long you can be down for an individual failure.
Acme Media labels its maintenance scratchpad the Maintenance and Support Worksheet. The Acme team noted their first maintenance concerns when the product was being examined for feasibility, and they recorded their final maintenance concerns during the last development iteration.
In our experience, deployment scripts and processes are a part of the deliverables during a development iteration.
Andrew Doran
They should be!
Acme always deploys to the backup center first as an additional test of the code and as a test of the deployment plan.
Andrew Doran
Is this standard practice? I have always done the opposite, keeping the DR instance on the old version for a day or two in case something went wrong when people started using it in production.
Acme Media’s team members sit relatively close together at their desks, but for deployments they all go into a conference room and sit at a table face to face. This setup allows the team to tell each other when they’re finished with a step during the deployment. It also accelerates troubleshooting if an issue is encountered. The whole team can hear the issue at once, and each team member can investigate the issue from a different angle.
Andrew Doran
This is a great idea for co-located teams.
The critical piece of the celebration is timing: you should celebrate while the project is still on everyone’s mind, before you shift to the next project.
First, you’ll give participants time to reflect on the project before the retrospective meeting. Second, you’ll collect opinions from the team before the meeting, aggregate the information, and publish the results back to the team to review before the meeting. Finally, you’ll prioritize the issues identified during the retrospective and post them prominently in the team work area.
make it clear that you’re meeting to review the process, not to measure whether the project was successful.
we like to send the survey out 3 days before the retrospective meeting and give participants 2 days to respond.
The questions are tailored to your environment. Acme Media cares about project management, development, and delivery. Other companies may want to focus on cost, speed, or efficiency.
if you’re working on a project estimated to run 6 to 12 months, you should identify logical times to stop and review the process.
It’s also good to analyze areas where the team is split. If half the team thinks you did well understanding the customer’s needs and the other half doesn’t, you need to find out where the difference in perception is coming from.
Many teams try to find someone outside of the project to be the facilitator. This helps maintain a neutral perspective on the issues as they’re discussed, but you may also waste a lot of time orienting the facilitator.
Rich believes the Sunday paper shouldn’t go out until Monday if the quality isn’t perfect.
The team forgot one of their own rules: deciding the level of documentation needed throughout the project. In retrospect, they should have created additional documentation to support the bidding feature and its complexity so that it could be tested thoroughly and to keep everyone in synch with the feature’s details.
Creating a successful Scrum team is only the first step on the road to an Agile company. In most enterprises today, you must create a successful product portfolio delivered by distributed/outsourced teams. Even then, to win in a market segment, an Agile approach to the enterprise product strategy is needed to dramatically improve opportunity for success.
how to increase your agility level through the use of the Sidky Agile Measurement Index (SAMI).
The SAMI is similar to Capability Maturity Model Integration (CMMI) in that it uses levels, but the purpose of the levels is to help you measure where you are, not to act as a scoring mechanism.
Common findings after a pilot
Andrew Doran
This is great stuff.
You need to make sure everyone who is supporting your move to agile understands that progress will be slower at first.
This confusion is a good thing, in that it brings questions to the surface and gives your team a chance to normalize on what agile will mean in your company.
you should set expectations with your pilot team and your sponsors that confusion is to be expected on the first few projects and that the process will solidify and improve over time.
Until you do a project with agile, it’s just a buzzword, hype, and conjecture. You can read books like this one, take training, and enlist the help of a coach. But until you do an agile project, you don’t know what agile means.
It isn’t important for you to agree with the agile community or the authors of this book—it’s only important for you and your team to reach agreement about what practices provide value in your environment.
the developers will develop faith in demonstrating portions of a feature as opposed to all the functionality. The customers will get more used to seeing code that is still in development.
this is a terrible practice to get into as a new team. If you view the iteration deadline as optional, you’ll start drifting from the agile principle of just enough and reduce the urgency around your work. The team needs to have discipline and support the iteration schedule.
It’s good to discuss the output at the stand-up meeting, but numerous decisions are made during a project, and the team can become confused about agreements over time. Team members don’t need to create formal notes every time they meet, but in projects as complex as the Auctionator, they must record critical decisions. Going forward, Acme will store these decisions on its intranet/project wiki site.
based on Geoffrey Moore’s book Crossing the Chasm.
It’s important to note that the gateways are virtual. You won’t complete all of your feasibility work before proceeding to planning, but you’ll do the majority of it in the Feasibility phase.
you’ll do the bulk of the planning during the Planning phase, but you’ll do a lot more during development.
we recognize that some people are more verbal than visual. To support this need we have documented one example of an agile process from beginning to end in text format.
Andrew Doran
Note to self to copy and paste this into a checklist for personal use.
Perhaps someone should tell them about Readmill!