Agile Development: Three Pillars of Success – Follow up on webcast Q&A
jl.marechaux 060001NWA6 Visits (10470)
On January 22, Vishy Ramaswamy and I talked about Agile architecture during an InformationWeek webcast: Agile Development: Three Pillars of Success.
(CLICK HERE to access the on-demand replay)
Questions which had not been answered during the Q&A session for lack of time are listed in this blog entry. We hope that you will find the information you were looking for.
Question from Yvonne: “With which tool are you capturing informal design diagrams (sketches) and architecture diagrams?”
Jean-Louis (JL): I personally like the sketching capability available from the Design Management Server (Rational Software Architect Design Manager). Web sketches are well adapted for informal diagrams, and they support collaborative work even for distributed teams.
Vishy: The sketching capability is supported in RSA as well RSA Design Manager. We have sketches that can be created in RSA rich client or you can use the Design Manager web client. Sketches are simple diagrams that can illustrate any technology-related or business-related interaction at a high level of abstraction and are great for capturing and collaborating on initial design ideas. Rich-text documents are used to capture text-based content and create design documents which can embed other diagrams as well.
Question from Lisa: “If you are rolling out Agile methodology, what type of training do you recommend (i.e. just in time or company wide) to get people on board and up to speed?”
Vishy: The following can be used for Green field development or any maintenance initiatives:
JL: There is no definite answer to your question Lisa. Company wide training can be useful to raise the level of awareness on Agile principles. But if people are not involved in agile projects, chances are they will forget about what they learned pretty quickly. This is why just in time education is often recommended, so that the team receives training when needed. And one approach to provide just in time training is to have agile coaches to support the team in their day to day activities.
Question from Pradeep: “You mentioned that there would be test cases during requirement gathering phase. Did you mean by high level acceptance criteria from UAT stand point OR actual test cases which will be executed during functional testing phase?”
JL: There is no requirement gathering phase in an agile lifecycle. Requirements (user stories) are collected and refined during each sprint, throughout the project. When a sprint starts, agile teams can define User Acceptance Tests (UAT). This approach is sometime called “acceptance test driven development”. The acceptance test helps team capture completion criteria for a feature. In addition, agile teams are developing test cases to execute during the iteration. So I would say that both UAT and test cases are created during a sprint.
Vishy: As soon as the stories being implemented in a sprint have been decided developers or testers start writing tests cases (functional) for testing in this sprint. The stories need to have reasonable elaborations for writing meaningful tests. At the same time across the sprints there may be UAT being written by a system verification test team as well which include higher levels aspects of the software including deployment, performance, integrations and migration. These may or may not require the detailed elaborations for each user story in each sprint
Question from Manj: “I understand we estimate a story using story points. Is there a need to further create tasks within that story and estimate those tasks in hours? What would a burndown chart indicate?”
Vishy: We do create tasks which are children of that story for managing the owners and also include supplementary work that may be involved including some investigation work. We do not estimate individual tasks.
JL: When dealing with simple user stories (simple project), it may not be necessary to create tasks. But as soon as they are involved in complex systems, agile teams may leverage tasks as well. Generally, a story is decomposed into tasks during the sprint planning when multiple people need to work on the story. Then tasks can be assigned to different team members. It is up to you to estimate the tasks. If you don’t, you can create a burndown chart at the story level (remaining story points). If you provide tasks estimates, then you can create a burndown chart at the task level (remaining hours).
Question from Naveen: “When the design is done without getting the full view of the project and with a limited view of the application, would they be suitable in the long run or would need multiple changes going forward ?”
JL: You will definitively need multiple changes to the design going forward. This is the whole point of agile architecture and evolutionary design. You refine and adapt the design over time, when technical challenges are uncovered. Rework is inevitable, but it ensures that the design really addresses the needs of the development team.
Vishy: You will need changes going forward. The key is to make sure that architectural significant changes are addressed in early sprints so that the churn reduces as you reach the middle of your life cycle. With respect to designs of specific capabilities these changes can occur throughout the lifecycle since the feedback from collaboration and end user usage may reveal new requirements or modify existing ones.
Vishy: I don’t have concrete numbers in terms of cost savings. The basic benefit we found is the active collaboration from the key stakeholders which helps us deal with change more efficiently and hence improve the quality of the product. The need to quickly get feedback from the end users helps us to automate many things (like builds, deployment, tests) thereby enabling consistency and reliability. The difficult part for us was to get started and have the team believe in the process and practices around being agile. Some early enablement training around our agile process could have expedited this transition. As mentioned in another question above something along the following lines would help
Question from Ester: “I had some discussion with my Business Analyst colleges about our role during the Agile project. From your prior projects, what was the BA role during the agile project?”
JL: I have seen some BAs playing the role of the Product Owner in agile project. I have also seen BAs becoming Scrum team members to do just-in-time analysis during sprints.
Vishy: BA’s can play the role of product owner and elaborate the stories from the backlog. They make sure that the high priority stories are reasonably elaborated before the sprint starts so that team leaders can do a fair job in assessing the feasibility of implementing these stories within a sprint
Question from Thomas: “So I heard AUTOMATION is one of the 3 'Pillars'. What are the other two? Please clearly state what the 3 pillars are.”
Vishy: At the heart of a successful agile development team is a skilled group of developers. Agile software professionals continuously deliver on their objectives, but they need robust development tools and practices to maximize their productivity. The three pillars of success for Agile development success are:
1) Resilient architecture
2) Collaborative dev tools
3) Automated processes
JL: To what Vishy said on the “3 pillars”, I would add that pragmatic architecture is based on team collaboration, evolutionary design and simplicity.
JL: Defects from a sprint are not automatically added to the next sprint, they are added to the product backlog first. It is the responsibility of the Product Owner to manage priorities for the next sprint, to identify which product backlog items will be addressed during the next iteration. Many agile teams are doing release planning to define the scope and the delivery date of a product.