April 6, 2011

Webinar Q&A: Understanding the Business Case for Agile

Alan Bustamante recently hosted the Only the Agile Survive: Understanding the Business Case for Agile webinar. There were many good questions during the Q&A session, and he wasn't able to answer all of them due to time constraints. As a special treat, Katie Dwyer, Seapine's Agile Padawan and Alan's partner in Agile Services crime, is co-blogging with him. Following are the questions and answers. Also, we'd love to have your feedback - don't forget to add your comments! [toc style="width: 100%;"]

1. How do you apply Agile to multiple projects or projects that do not have dedicated teams?

For multiple projects, I favor a decentralized approach. We know that every project is unique. So, while there should be a common structure around some things that affect many stakeholders, such as reporting (burn downs, burn ups, etc.) and iteration review times, how the team functions in their day to day activities and the artifacts they are responsible for should be decided by the team. For projects that don't have dedicated teams, it comes down to expectations. What I have learned is that the project leader must help the customer and management understand that the more multi-tasked a person is, the less they will be able to accomplish because of the cost of task switching. Many organizations want to achieve the benefits Agile has to offer, but don't want to make the necessary trade-offs. A good article that illustrates the problems with multitasking is Multitasking Gets You There Later.

2. How do you apply Agile with vendors?

If you are dealing with a third-party software vendor, the relationship you have with them will determine a lot of things. Not knowing your situation, I'll assume a typical scenario, where the role of the product manager (or owner) role resides with your organization and entire development team sits with the vendor. One of the selling points of Agile development is that it’s very responsive to change. However, in a new vendor relationship, trust has not been built, so there is often a focus on getting a "fixed scope" for a "fixed price". These types of contracts can cause a lot of heartburn when something does change. In this case, you can define a Statement of Work (SOW) with an agreed level of scope for a fixed price, but word the contract so that changes are allowed, making the net effect zero. In the case I've outlined here, if your product manager wants to add a user story to the product backlog while the product is under development, they simply remove a user story of equal or lesser value. This takes away the need to have a formalized Change Control Board (CCB) and will reduce complications associated with change requests. There are many possibilities, this is just one.

3. How large should a development team be? How well does the Agile process apply to very large development projects?

There is no one right answer to how large a development team can be. The rule of thumb is 7 +/-2 (or five to nine) people for one team. If your project team exceeds the recommended maximum size of nine, then you will need to break the team into sub-teams, each with five to nine people. I've worked with very large distributed Agile teams and I can tell you there are definitely trade-offs that you have to make for large teams that you usually don't with smaller teams. Speeds of communication as well as coordination of activities are probably the two biggest.

4. How do you ensure that there is actually releasable code at the end of each cycle?

There is no one easy answer for this question. A great team will go a long way to help you achieve this goal. Good interpersonal relationships are important and the willingness to pull for the team goal is critical. Team members that are not willing to do work outside of their "scope of responsibilities" will create a toxic environment for the Agile team. From an execution perspective, automate what you can. For example, if you have large sets of regression tests, automation makes running them is less time intensive. Make sure your engineers are refactoring so that the design is more flexible and easier to change without impacting other parts of the product.

5. What automated tools QA are good for an Agile environment?

(Katie) There are numerous tools available for unit testing. What works best for you will depend on the language, IDE, and environment. Continuous integration is also an important aspect of an Agile environment to ensure that all code builds and all unit tests pass after each check in. There are numerous options for continuous integration, including Hudson and Cruise Control. As for automated testing tools, of course, we recommend Seapine's QA Wizard Pro.

6. How does Test-Driven Development (TDD) affect Agile and businesses?

(Katie) The goal of TDD is to produce clean code that works. Since there is no upfront design in an Agile environment, TDD ensures the coding practice is disciplined, and the focus is on quality. It also ensures there are unit tests for all code so regression testing is easier and defects are found earlier..

7. Where can we find some of these studies about the Agile conversion you talked about?

The New York State project I talked about can be found at http://elegantagile.com/blogs/entry/NYS-Government-Case-Example-of-Implementing-Agile-Scrum

8. Does working software over documentation mean no documentation?

The short answer is no. Remember, we put more emphasis on “working software” in Agile projects because we want to show empirically that our assumptions are correct. Documentation is still an important part, but we only want to document what is absolutely necessary.

9. Are you planning a webinar to demonstrate how Seapine tools can be used to plan, monitor, and deploy an iteration (I'd like to learn how other teams manage their iterations, how they know how far along they are in their current iteration, and how they manage their product backlogs)?

Fernando Cremer, a product manager at Seapine, will be demonstrating Agile practices with the Seapine suite of tools on April 13 and April 14.

10. How do you manage the scope of each iteration? The customer might try to squeeze in too much, so how do we control that?

This is an education issue. Even Agile projects have boundaries, so if your customer expects the team to deliver more than their capacity, the customer needs to be educated on how Agile projects work. Remember, the team chooses the work they will complete in the iteration; the customer does not do this. If the team is taking on so much work that they are not able to complete it in the iteration, than that should be a learning point for future iterations.

11. Often we have programs we need to write in our ERP, these are usually new reports or mods to existing code, like data updates to various tables with very complex logic. So often the problem is the customer isn’t all clear on what they want and sometimes the analyst has a hard time doing the investigation and analysis with regard complexity of the problem. Sometimes one report/mod can take a week to line up correctly to the "real" requirements. So, how can we use Agile for this? I have adopted XP's TDD and refactoring as a start.

Yes, TDD is a good start. I see two issues, one is where you say the “customer isn’t all clear on what they want”. Before the team can estimate work for the customer, the team has to have a good understanding of complexity. If they don’t have a good understanding of a story, then the story isn’t ready for estimation. So, from a business value perspective, the customer needs to know what they want. The second issue is that the analyst has to do the investigation. In Agile terms, we call this a spike. Once the customer knows how they want the feature to function, if the team cannot estimate because the underlying code requires some investigation, make sure the team carves out time in the next iteration to investigate through a spike. Just make sure the time spent on the spike is used on something that is likely to go into the product. If you are dealing with legacy code and interested in learning more about TDD, Katie Dwyer will be presenting on TDD best practices in June.

12. What plan of action would you recommend if upper level managers (Director and CTO) are reluctant to use any of the Agile methods? I have had discussions with them but have been unsuccessful.

If you are still at the exploration stage, help management understand the value by referencing case studies for other organizations in your market. If those are not available talk with your local Agile group about arranging a meeting at your company. When I was leading APLN (Agile Project Leadership Network) Houston (www.aplnhouston.org/), we started an APLN To Go program just for that. We were very successful at getting upper level management to the meetings because they were easily accessible. Taking that initiative can help advance your Agile agenda. If your upper level management is already informed, then the best validation of Agile benefits will come from carefully selected pilot projects. Remember, seeing is believing!

13. How is regression testing handled in Agile projects?

Regression testing is just as important in Agile projects as any other type of project. However, in Agile environments there is often more emphasis on automation due to the iterative and fast paced nature of the Agile development cycle.

14. What quality measuring tools are used in Agile project management to ensure that quality is consistent from sprint to sprint?

If the team is using Test-Driven Development, refactoring, and continuous integration, then you should be satisfied that your code and architecture is sound. From a usability and fitness for use perspective, if your customer is happy with the iteration deliverable, then you have delighted the customer and that is also a measure of quality.

15. To maintain quality of modules delivered what unit testing requirements are needed?

(Katie) There are many Agile practices that are devoted to code quality. These include Test-Driven Development (TDD), Pair Programming, Refactoring, and Continuous Integration, not just unit testing. Unit testing is a part of TDD. In TDD, you write a test that fails first, make changes so the test will pass, and then verify that all tests pass. Unit tests are written as a natural part of the TDD process, and there are no specific requirements around the unit tests.

16. Agile Iron Triangle: You reprioritize scope based on cost and schedule. Do you set a preliminary scope for a project and if so, how?

Yes, there is preliminary scope. This can be in the form of a Statement of Work (SOW) when working with vendors or some form of Business Requirements Document (BRD). These documents can serve as the primer for your product backlog if you are unable to move straight to the product backlog.

17. Does every iteration require a separate test plan or is it advisable to use the first test plan and expand it (to a 300-page book, ha ha)?

Believe it or not, the definition of test plan can vary from organization to organization, so I don’t want to assume I know what your definition is. Regardless, your test plan should be built iteratively for Agile projects. There are some things you will want to include upfront and these are normally part of your definition of “Done”. For example, the types of testing you will perform and the workflow for defects. As the project progresses, things will change, so you want to be able to adapt accordingly. As far as the 300-page book, I have yet to see a 300-page test plan and I’ve worked on some very large multimillion-dollar projects. For help managing test cases and your testing strategy, check out TestTrack TCM, Seapine’s test case management solution.

18. How do you adapt Agile practices for extremes of team size, such as two or three people on a team for a highly cost-constrained non-profit organization?

If I understand you correctly, your team is extremely small. In my experience, most organizations have problems on the opposite extreme. That is, they need help with extremely large teams. You are fortunate in that the small team makes a great candidate for initial Agile development. That said, you will need a good understanding of your team’s capacity to deliver. So, while your customer’s expectation to deliver may be high, your team’s capacity to deliver will be constrained by the number of people on the team. Set the appropriate capacity expectations with your customers and commit to deliver as frequently as you can. Ultimately, this will build trust with your customers, which is what you want.

19. Can you provide any guidance in regards to embracing DevOps for communication between IT disciplines across multiple groups and development teams?

For those who are not familiar, the DevOps movement was created to fill the holes uncovered or created by Agile development. For example, how do we make sure that infrastructure and release management is ready for frequent deployments? Or, how do we equip support operations to handle frequent software deployments from a project that won't end for months? There is no simple answer for this one, especially for organizations that have hundreds to thousands of folks in the development organization. The best guidance I can give is to communicate your intentions often. I had a situation where we were releasing code to production every four weeks and release management (RM) made a rule that code had to be approved by RM two weeks ahead of deployment. So, you can see the dilemma. In this case we opted for director approval to bypass the rule. That was a short-term fix and, unfortunately, we never got to a long-term fix. So, communicate what you are doing and why you are doing it to as many people in your organization that are impacted by your actions. Make sure their concerns are addressed.

20. You said you include the customer in your daily stand-up meetings. Who represents the customer at Seapine's daily stand-up?

We have product managers who represent "the customer" at our stand-ups. They gather requests from users through various methods (conversations with users, sales, etc.) and prioritize the work for development.

21. What level of documentation do you create before actually implementing the feature in each iteration?

It depends on your situation. If your Product Manager (or Owner) is not active in your project daily, like they should be, you will need to account for that. The longer your team goes without talking to the customer, the more detail they will need. This is why it is essential for any Agile adoption effort to set a priority on the Product Manager role. User stories work great, but only when you have access to your Product Manager who can provide the details. Agile methods value close collaboration with the customer (www.agilemanifesto.org). So keep this in mind. For regulated environments, the level of documentation will vary depending on what’s required from the governing body. Know your specific situation well enough so you know just how much detail you need.