When a software development professional first hears about Agile, they are often initially incredulous that this type of approach can work due to a misperception that Agile simply means “no planning.” This belief could not be further from the truth. Agile teams tend to plan more throughout the course of a project than a traditional approach, albeit in a different fashion than they may be accustomed to. Rather than planning once at the beginning of a project, Agile teams practice continuous planning throughout the project.
This web seminar explored the five Levels of Agile planning, and how they help teams ensure that teams are able to benefit from what they learn over the course of their development and delivery efforts.
Mark Arntz answered a few more of your questions after the seminar. Check out the remaining Q&A below:
Q1: What are the planning tools and key planning deliverables to clients in case we don’t use Microsoft project
A: There are many different tools available for Agile Project management, but the most important thing to remember is the tools should not drive the process. An Agile Manifesto value states: We value Individuals and Interactions over Processes and Tools. It’s a really good idea to figure out how we want to get the work done before going to an automated management tool. Of course, from the very start, we do want some kind of tool to help organize the work, but Agile at its simplest form leans on physical cards placed on taskboards on the wall. It is recommended that whenever possible this approach precede a more automated approach. When we have distributed teams, this may not be possible. Also, when we have a more mature Agile organization, we may have already settled this question and new teams tend to bypass the more physical / manual approach for managing the team. Some tools that are very popular, based on feedback from my classes and personal experience are:
Jira – a less expensive option
Rally – more expensive but more sophisticated
Mingle – more customizable to your approach
VersionOne – Much like Rally
TFS with Agile extensions – a Microsoft product – for Microsoft shops.
Key Planning Deliverables:
I’m going to try and answer this is in a paragraph, which is difficult. Planning deliverables should never be created in isolation from the customer. The Agile team has a role called the Product Owner. The Product Owner most ideally comes from the business side and owns the Product Vision and Product Roadmap – planning deliverables. The Release Plan is shared between the Product Owner and the Agile team. The Agile team owns the Iteration Plan and the Daily planning of the Daily Standup (Scrum). The requirements that eventually will fill up the Release Plan and then an Iteration Plan are called User Stories. These are owned by the Product Owner, but the development team contributes to their Progressive Elaboration (filling in the details Just-In-Time). Other deliverables are determined by the Agile team and belong to the Definition of Done – the things we do to complete a requirement. Another type planning deliverable not really prescribed but allowed for in the Agile approach is a compliance type Story. If the organization requires some document for internal use or regulation satisfaction, this can be created as a Story that resides on the requirements list called the Product Backlog. This Story will be done by the Agile team, when the Product Owner sets it as a priority.
Q2: Any special considerations while adopting agile to a Fixed Price contract?
A: From the Agile Manifesto: We value Customer Collaboration over Contract Negotiation. This does not infer that in Agile we don’t have contracts, it just instructs us that any contract type that tends to reduce or eliminate Customer Collaboration is not advised. The Agile Process addresses risk in a different way than by creating a Black Box contract that a vendor signs up for and if all aspects of the contract are met success is declared. Experience has shown that while a contract may be met, the customer may not be happy with the end results. Firm Fixed Price Contracts would be the least attractive contract approach for Agile work. Even with US Government work, options are available to avoid this approach and still meet objectives that protect the taxpayer investment. There is a document that the government has produced that can help with more ideas around this subject:
Contracting Guidance to Support Modular Development
Q3: any comments about doing an agile process with PCI (payment credit info) apps. Some say like CMMI that agile is not for this type of dev because of the governance
Agile is for anything that is complex (or in other words, learning is required – i.e. invention). Governance can be accommodated as customer/stakeholder specified value captured as a story and scheduled as work to be done by the development team. Some aspects of governance can also be built into the Definition of Done. An example of Definition of Done:
DoD: To complete any Story we do the following:
1) Design the solution
2) Create Acceptance Tests
3) Create Unit Tests
4) Build the Solution
5) Write User Documentation
6) Update the Release Notes
7) Do Code Review
If there is a requirement to do a Security Review as part of completing any requirement, then just add it to the checklist of things we do, or the Definition of Done.
Q4: Is there a project management tool specifically developed for Agile or a tool shouldn’t use at all as it will become a admin burden
Q5: We have seen various level of planning the complete requirement/ roadmap/ vision. Do we break the design process accordingly? if yes, it might introduce risk with addition of each requirement where design might be changed
A: Requirements called stories that are implemented by the Agile team should align with the previously created Vision and Roadmap. They have been scheduled for implementation during Release Planning in a Release Plan. Before taking them into an Iteration the Agile team digs into the “requirement design” which is delayed until close to the time the Story is implemented. Usually one to two iterations ahead of implementing a requirement, developers and customers go into a room in front of a whiteboard and start discussing the details of the requirement. Whiteboard diagrams, screen mockups or wireframes, use cases and any other known methods can be used at this time to dig into the details of the upcoming Story. The bottom line is that in Agile we embrace change and therefore expect that things will absolutely change. That’s why we do Agile.
Q6: Mark, we had challenge in using Agile for ERP implementation particularly due to larger work packet which may not fit in 2 weeks cycles. What is your experince in such cases say SAP implementation?
A: I don’t have experience specific to SAP. My experience is with the Oracle ERP solution, but I assume that there is great similarity. I’m having a hard time imagining work that cannot be broken down smaller. I agree that it may take some practice if you have not thought about it before, but with practice a team can usually learn to think about it in a way that accommodates slicing it up. If there is no way to slice it up, then this becomes an impediment to doing Agile.
Q7: How do we estimate a Scrum project which is fixed price project where we do not have all product requirements upfront.
Driving Investment Decisions:
What is the defined project goal? (Vision / Project Charter)
If the goal is reached what would be the benefit? (Business Model supporting the Vision)
• How much investment would be reasonable to achieve the return or to make the Business Model work?
• What is the expected payback period?
• Have you considered the time value of money and is the payback period acceptable?
Feature Based Validation:
• Create a backlog of stories / epics / features
• Estimate all features in Story Points (size the backlog)
o You will first need to calibrate your Story Point size
• Build a team (maybe hypothetical team) and determine the cost of the team
• Define a Definition of Done or Standard Work
o What’s included in each Story Point
• Estimate # of Story Points that team can do in an Iteration
o be realistic – on the pessimistic side
• Divide the # Story Points in the backlog by the Velocity to find the # of Iterations needed to complete the backlog.
o Velocity = # Story Points a team can address on average in an Iteration
• Multiply the number of Iterations by the cost per Iteration
• Does the cost associated to complete the backlog support the Business Case?
Schedule Based Execution:
• Break your features into Stories
• Prioritize your Stories
– must have, should have, could have
• Use the team that will do the work to estimate the work in Story points
• Determine a realistic estimate of how many Story Points this team can accomplish per Iteration.
– Consider the Definition of Done and the amount of Productivity (6 hours per day?)
• Using the cost of the team, determine how many Iteration can be accommodated by the business model to set the go-live date.
• Locate the place in the backlog where all money has been spent or the go-live date has been reached.
• Decide if all must have’s and enough should have or could have stories can be included to support the business case.
• Move forward with flexible scope and fixed cost and schedule.
• Track against expectations.
Q8: What team composition is required for a successful Agile environment? Please discuss skills, positions, and team size.
A: The recommended team size is 5 to 9. The 5 to 9 guideline is not set in stone and it does not include the Agile PM or Product Owner, in my opinion. The team is eventually made up of Specialized Generalists. In other words, we don’t limit the kind of work that any member of an Agile team can pick up, but each team member has some proclivity towards certain types of work based on the specialization that they bring to the team. The team works together to build quality working software. When building an Agile team, a manager will want to have some QA, Dev, BA, Tech writing expertise so that the team has the skills to accomplish the work. Over time, these team members will pick up things that aren’t in their specialty and will grow into this Specialized Generalist.
Q9: how do we track re-opens from QA(testing)? or bugs coming from QA – adding those will change the iteration planning we had initially right?
A: This question promotes the paradigm of separation between QA and Dev. This is the traditional view not the Agile view. Agile promotes the concept of “Build Quality In” instead of “Check Quality Out.” The Inspection idea is not the same. So, things are not done until everyone says they’re done as part of the process. If a tester find a deficiency, it’s not really a defect, its just something more that needs to be done before we declare the requirement done. There may or may not even be an artifact of deficiency to track. The tester sitting next to the developer in the same room, may simply point it out and the developer says a minute later, “That’s fixed.”
Q10: Don’t you think is there any need to add additional step in the Agile planning that takes care of Lessons learned with focus on strengths and areas for improvement occur after each sprint and are included in the next sprints or so..
A: Yes, this is part of the Agile process and is called the Retrospective. It is not part of product planning, it’s part of the process continuous improvement or Inspect and Adapt process.
Q11: how does an iteration delay affect the total planned schedule/cost?
A: Scope is adjusted to meet cost and schedule expectations. This can only happen if the scope has enough non-must have requirements in the initial scope used to budget. See Q7.
Q12: Are there any best practices for a test manager to manager multiple agile testing projects?
A: The truth is that there is no such thing as a Test Manager in the Agile team. That does not mean that in practice the role has gone away, but usually test resources are primarily assigned to teams. They secondarily are members of what might be called a Center of Competency called QA, or BA, or DEV, or PM. These represent vertical silos. Generally silos are bad, but if they are loose or weak silos, residing in a weak matrix organization, then they provide benefit of promoting the competency that they represent while making the project team dedicated and protected from interruption from the Silo.
Q13: Which agile planning tool is widely used?
A: See Q1
Q14: do you recommend any tools that is very good for tracking Agile plans – iterations etc?
A: See Q1
Q15: where Business analyst role fit in Agile planning?
A: Same as Q12 and Q9.
Q16: Which are the 2-3 key quality metrics in agile?
A: Agile uses visual management tools or Information Radiators to track progress of the work. A non-Agile example is the use of a thermometer used in a United Way campaign to grow towards the goal set for the campaign. The most commonly used are called Burn-up Charts, Burn-down Charts, and Taskboards. Other metrics that are tracked:
• Commit v. Complete – we committed to 20 Story Points in the Iteration and only achieved 18 Story Points – CvC rate is 99%.
• Escaped Defects: The number of defects that get out into the field that should have been found before release but were not. These indicate a process that is in some way deficient.
o # Escaped Defects per Story Point could be one way to measure this.
Q17: Do we call a Requirement as a Requirement in Waterfall model and a User Story in Agile?
A: Usually yes.
Q18: Can we have a brief discussion on backlog ?
A: The backlog is a prioritized Requirements List. It contains Stories. There are two types of stories: User Stories and non-User Stories. User Stories are needs statements that represent a functional requirement. Non-User Stories are things that are needed for the product to represent quality, but the User may not recognize the value. The Backlog is DEEP (Roman Pichler – Product Management with Scrum)
1) Detailed Appropriately
3) Emergent (Progressive Elaboration)
Q19: Do you have any recommendations for implementing Agile in a PRINCE2 centric environment?
A: Sorry, I do not. I’ve never been exposed to PRINCE2. If this is a more Waterfall kind of SDLC, then milestones can be lined up with the Agile process and teams can include work in the backlog that help achieve the milestones. If Check Quality Out requirements are needed, then these can be after-the-fact and not really included in Agile, but used as an after process that will then feed new requirements into the Agile process if things are found.
Q20: I manage a process improvement program for a CMMI Level 3 company. The biggest complaint is that our process set requires too much planning and paperwork. They say, “we want to be more agile.” How do I explain that agile’s planning is just as rigorous?
A: Remember, Agile is Barely Sufficient. Not insufficient. But, if you are doing things that nobody will look at after it is created – that is a good indication that it is waste and should be eliminated from the process. The LEANEST process is represented in the sitcom Bewitched. Darin asks for something and Samantha twinkles her nose and voila – there it is. If we could twinkle our nose and have working software, wouldn’t we want to do that. The fact is that we don’t have any such magic. So we do the things that bring us working software, but don’t get carried away, imagining that every possible document actually represents something of value.
This web seminar occurred on Tuesday, January 13th, 2015. Missed it? Find the slides and recording here!