Agile FAQ

Expand all Collapse all

• Are costs and schedule fixed for a sprint and for all sprints in a release?

  
  Scrum uses the term “velocity” to define how much product backlog effort a team can handle in one sprint. If your sprints are of relatively consistent velocity, sprints would ideally be similar in both duration and cost, giving the impression of fixing both. It is possible to increase velocity by adding more resources in a sprint, resulting in commensurate increased costs. However, substantially varying the velocity from sprint to sprint will have an impact on the rhythm of the team. Each team will need to review this in sprint retrospectives to determine how this is working for them.
  

• Is Agile specific to an operating system or a development language?

  
  Agile is an approach to doing the work of a software development project and is completely technology agnostic.
  

• Is Agile better adopted top-down or bottom-up?

  
  We actually have seen it work and fail from the top down — it really depends on the culture and leadership of the company. One company brought us in to teach and train everyone on Agile because the CIO had a good experience with it in a prior company. It was mandated that the company would be Agile by the end of the year. However, there was no authority given to the groups to make Agile truly work. This company is moving along very slowly and not realizing many of the benefits.
  
  Another group we worked with was also top-down but the difference was in the leadership. Leadership took an interest not only in the Agile process but in what it was going to take to make it work. They looked at change management, environments and the individuals and worked on those things in parallel with a couple of pilot projects. That company is doing very well. It has fully adopted Agile and has had a very smooth transition. Another very large company we worked with had huge success with the top-down approach, again because the leadership gave it full support and treated it truly as an organizational change. If you do not have that, then you can have more success with the bottom-up approach because you can show management success and get buy-in.
  
  

• How much time should be spent breaking down requirements into small segments that can be completed during a 1–4 week iteration? Do you see that time as beneficial since it may make the requirements more clear or a necessary evil of Agile?

  
  Agile does not eliminate the need to identify and translate business requirements into working software. What it does is encourage more active dialogue and interactive communication between the business and the development team instead of odious written documents. It is precisely this “conversation” that breaks down the requirement into knowledge that enables the development team to be comfortable designing and developing the solution. The level of granularity of breaking down the requirement will depend on the shared knowledge base of both the business and development personnel. If it is clear, you are done. If it isn’t, you have more work to do.
  
  

• Do you see Agile as beneficial in off-shore development since the developer does not need to understand the big picture but just understand the small requirement?

  
  Agile can certainly be used in an off-shore model, but would require some alterations based on the relationship between those “shipping the work” off-shore and those “receiving it at the dock”. However, much of the self-organizing nature of the team as well as the potential intellectual value of the off-shore resources may be defeated if the off-shore resources are used as “blind labor”.
  
  

• Does Agile work well in virtual teams? What extra challenges occur and what can be done to overcome them?

  
  Agile is based on a high level of interaction and shared communication with transparency of information. While this is not impossible with virtual teams, extra effort is required to meet the challenge of the team not being co-located. Advances in telecommunication have enabled greater tools to keep virtual teams in sync and emotionally connected in spite of their geographical distances. Use of webinars, Skype, instant messaging, Google Talk or simple conference calls all help keep virtual teams feeling more co-located.
  
  There is also a need to spend deliberate time working on the team relationships since the casual interactions that develop these in an ad hoc fashion will not occur. At the heart of all this is trust. Recognizing the existence or absence of trust in a team is a key barometer of high performance teams. And that goes for any team, not just virtual teams.
  
  

• Is Agile a good way to go initially if the project will, at some point, be predictable?

  
  The closer you get to the end, the more the outcome should be understood, regardless of the methods used to get there, because discovery happens. Predictability is a function of how far you can see into the future. Agile just recognizes and works off the premise that the prevue of predictability is relatively myopic. Therefore, take shorter steps to mitigate the risks of the uncertainty of that unpredictability.
  
  

• I have been told that Agile generally uses paired programming. This can be difficult for the client to see as a benefit as they see two people doing the role of one person. How do you convince a client this is beneficial?

  
  Paired programming is a technique used mostly in eXtreme Programming (XP is a member of the family of Agile methodologies) but is not essential on an Agile project. The goal and intent of paired programming is to maximize the interaction between business, development and testing into two people that work in tandem on the same deliverable. Paired programming reduces the latency of communication.
  
  As for convincing a client that it is beneficial, if it produces better software faster, what is there to prove? If it doesn’t, why would you use it? The proof is in the pudding, not in how the pudding is made.
  
  

• Does PMI also support Agile?

  
  The Agile framework is documented in PMI’s Project Management Body of Knowledge (PMBOK) and PMI does accept our Agile classes for PDUs. The following formula can be used to calculate PDUs earned: one contact hour of learning relevant to project and/or program management within a structured activity or course equals one PDU.
  
  

• How do you avoid burnout when working in "continuous sprints"?

  
  The word “sprint” may be interpreted to mean you are always sprinting, when in fact, you are performing a series of fixed duration sprints that are planned and reviewed followed by a retrospective, where there is time to catch your breath. However, even that could sound exhausting. The key to avoiding burnout is to determine the velocity of the team, which is basically the comfortable capacity of work that can be completed in the time-boxed sprint with the committed resources. It is important to recognize that you do not plan in order to complete all desired work, you plan the possible work based on a known or expected velocity and then sprint to get that done. Over time, the velocity of the team becomes steadier and teams will commit to the work they know they can deliver and not accept or allow more work jammed into the sprint than they feel they can deliver.
  

• How do RUP and Agile work together?

  
  RUP (Rational Unified Process) is actually an early Agile methodology that is on the more formal end of the Agile spectrum. RUP was one of the first methodologies that proposed an iterative approach to incremental development and delivery. RUP is not as “lite” as some other Agile methodologies such as Scrum, but it does employ the same basic principles, albeit a little more formally.
  

• Which would you recommend — Agile (general) or Scrum — and why?

  
  As Agile is the term for the genre of methodologies, of which Scrum is one, Agile (general) is a bit amorphous to define at the execution level. That is why different instances of Agile have developed. I do personally favor Scrum because of its simplicity, amount of commercially available support and ease of understanding. There are plenty of books, classes, tools and coaches to support and enable Scrum, so while it may not be the right Agile methodology for every organization, it is a great place to start and experiment with Agile.
  

• Agile sounds mostly about software development; how would this method work with infrastructure projects?

  
  While Agile is most often found in software development projects, the principles are equally applicable to infrastructure projects, or any project, for that matter. Infrastructure projects, as well as COTS implementation projects, may have larger chunks of deliverables that cannot be “built or implemented” at the level of granularity they can in software development, so they do require greater planning. The basic values and principles can still be applied; however, the practices may differ.
  

• What is empirical measurement?

  
  Empirical basically means that something is provable or verifiable by experience or experiment. Agile employs an empirical approach by using the working software (something that can be tested and verified objectively) as a measure of success and performance. By using an empirical approach you rely on tangible proof as opposed to predictive conjecture regarding the deliverables and the status of the project.
  

• As most medium to large organizations are traditional command and control or hierarchical, how and what needs to change on the business side to give Agile traction? What conflicts have you seen given these circumstances?

  
  The changes that are necessary are not restricted to the business side. To give Agile traction in an organization, teams need to be allowed to be self-organizing, at least within the constraints of the organization and any regulations. This may be uncomfortable to those conditioned to command and control (both the commanding and the commanded) as it will feel like risking chaos.
  
  One of the major changes the business will have to make is to be more (read daily) involved with development projects. Agile requires a high degree of collaboration that formal requirements gathering and documented sign-offs struggle to facilitate. Again, this will feel uncomfortable and possibly exposed.
  
  Ultimately, for Agile to take hold, the organization has to have a foundation of trust that enables the business and IT to work well together. Without this trust, there will be a natural tendency to resort to more structured and formal interactions which will thwart efforts to behave with agility.
  

• What if the product owner has a “minimum set of scope” that must be delivered to make the "thing" useful, but this is too much to complete in just a few sprints? How does that affect "constraint prioritization"?

  
  This is very common, especially with commercial software, where the market would not pay for software that does not meet the minimum expectations. What this means is that the team will take more sprints to deliver the minimum feature set. However, they still deliver in sprints that can be empirically measured and validated to the minimum feature set, as it could change over time. Prior to each sprint, the feature set (product backlog) is reprioritized and the upcoming sprint addresses the highest priority items they can commit to, within the constraints of their known velocity.
  

• I have difficulty spending so much of my time in the daily/monthly reviews. Currently, I attend when I can, but often can't make them, so I send a status email. Is this acceptable in the Scrum/Agile model?

  
  Agile teams should be self-organizing. If this method of communication is meeting the needs of you and the team and not affecting work quality or productivity, then the team would determine that it is acceptable. However, there are plenty of intangibles to be gained by face-to-face communication, so I encourage teams to religiously scrum even if there are logistical challenges. If the meetings are properly facilitated, both in format and content, the time spent should be worth it, or the team should attempt to organize so it is worth it.
  

• Is there a test that can be given to developers and/or management to determine where their "tendencies" or comfort levels with Agile are?

  
  I am not aware of any formal test that can be given to determine an individual’s predisposition for Agile. However, if their behavior is consistent with the values and principles, I would expect them to be comfortable with Agile practices. If the underlying values and principles make them feel uncomfortable or run against their belief systems and experiences, getting them to buy into Agile will take a bit more work.
  

• How do you control the scope of a project when it is continuously changing?

  
  You don’t. You allow the scope to continually expand capturing the ecology of ideas in the product backlog. The key thing to understand is that you are time-boxing delivery of something that is working and delivers the highest value with what is known at that point in time.
  
  A key value of Agile is that you embrace change because controlling it only limits value to the customer. However, the flip side of that is that the customer (Product Owner in Scrum terms) needs to be a collaborator in understanding the risks associated with changing scope and direction. It has to make business sense, and if it does, it makes sense to do it.
  
  A small clarification, though. Scope does not change within a sprint, except under extreme circumstances, which should almost be never. That is why sprints are time-boxed in short durations of one to four weeks, so the agreed upon work can be completed, empirically measured and measured for its business value.
  

• Does Agile conflict with traditional phase projects, specifically regarding documentation? In Agile, it sounds like the requirements are developed as the project progresses — not according to any phase-type plan.

  
  Agile methods can be applied within a development phase and co-exist happily with traditional stage-gate project methodologies. However, most formal phase-based project methodologies require detailed documents as deliverables for completion criteria (especially requirements and design) that will leave those looking for complete certainty feeling a little uncomfortable. Meaning you will probably not pass the toll gate or get funding to continue.
  
  Agile is best suited when the requirements are admittedly unclear and discovery is necessary to complete the requirements and design. In these types of projects, complete documentation of the unknown is more an exercise in futility. It will only suffice to leave you with a false sense of knowing the future or waste excessive energy attempting to guess at it. If you don’t know, you don’t know. Pretending to know doesn’t help anyone, it just wastes time.
  

• Is there an ideal team size for using Agile? What are challenges with using Agile in a larger team, say 40+ members?

  
  Ideal team sizes will range based on the situation and circumstances; however, studies have shown that teams should be large enough to have the diversity of skills necessary to complete the work yet small enough to facilitate effective communication and interaction. For most software development teams this is usually six to eight people, give or take a couple.
  
  On larger projects where more people are required to complete the work, function and/or feature, teams are usually established to keep the team size small. Then, leads from each of the teams will form a team to share and collaborate at an aggregate level.
  

• How do you manage project schedules in a Scrum/Agile environment?

  
  Daily. Every day in the daily scrum, each team member reports what was completed the previous day. I typically reflect that in the project schedule as well as in the sprint burndown chart. The burndown chart is a sprint centric schedule that is a subset of the larger project schedule.
  
  I personally use Microsoft Project as it allows me to effectively communicate with key stakeholders and manage any dependencies that are outside the effort of the sprint itself. There are also other tools that can be used, but ultimately the team should use what is most effective for their purposes.
  

• I want to touch on the lack of the predictability in Agile. You can predict when a sprint block is done, but how can you predict when the production backlog (project) is completed?

  
  You can’t and don’t really want to. Unless the product in its entirety can be thoroughly defined (at which point there is probably little value in using Agile methods), the product backlog will continue to grow. However, at some time the items on the backlog will not have enough value to support the effort to complete them. If the value is not there, they shouldn’t be done. If the value is there, the organization will support the effort to continue to work on them with additional sprints and releases.
  

• Have you done any follow up with organizations that you have helped implement Agile? What were the results? Did the change "stick"?

  
  Yes, I have, and the results vary. So much depends on the support system and implementation process. Implementing Agile, or any performance improvement initiative for that matter, has to be seen as an organizational change effort and approached as such.
  
  Organizations that do so show great results and retention. Those who don’t usually go off looking for the next silver bullet.
  

• How do you determine infrastructure design when the requirements are not complete for each sprint?

  
  As part of the release and sprint planning, the items considered have to align with the overall architecture of the product. The architecture is the glue that holds the individual tasks and stories together from sprint to sprint and through a release.
  
  Agile does not eliminate the need for an overall foundational architecture, and in fact requires it to maintain consistency as the requirements morph and evolve. We did not cover the product architecture in this webinar, but it should be recognized that the development team adds items to the product backlog, too. Infrastructure items are usually known by the product architect/lead developer and are taken into consideration when doing sprint planning. Those items are added to the sprint backlog and consume some of the velocity of the team in that sprint.