Register now or log in to join your professional community.
Active Stakeholder Participation. Stakeholders should provide information in a timely manner, make decisions in a timely manner, and be as actively involved in the development process through the use of inclusive tools and techniques.
Architecture Envisioning. At the beginning of an agile project you will need to do some initial, high-level architectural modeling to identify a viable technical strategy for your solution.
Document Continuously. Write deliverable documentation throughout the lifecycle in parallel to the creation of the rest of the solution.
Document Late. Write deliverable documentation as late as possible, avoiding speculative ideas that are likely to change in favor of stable information.
Executable Specifications. Specify requirements in the form of executable "customer tests", and your design as executable developer tests, instead of non-executable "static" documentation.
Iteration Modeling. At the beginning of each iteration you will do a bit of modeling as part of your iteration planning activities.
Just Barely Good Enough (JBGE) artifacts. A model or document needs to be sufficient for the situation at hand and no more.
Look Ahead Modeling. Sometimes requirements that are nearing the top of your priority stack are fairly complex, motivating you to invest some effort to explore them before they're popped off the top of the work item stack so as to reduce overall risk.
Model Storming. Throughout an iteration you will model storm on a just-in-time (JIT) basis for a few minutes to explore the details behind a requirement or to think through a design issue.
Multiple Models. Each type of model has it's strengths and weaknesses. An effective developer will need a range of models in their intellectual toolkit enabling them to apply the right model in the most appropriate manner for the situation at hand.
Prioritized Requirements. Agile teams implement requirements in priority order, as defined by their stakeholders, so as to provide the greatest return on investment (ROI) possible.
Requirements Envisioning. At the beginning of an agile project you will need to invest some time to identify the scope of the project and to create the initial prioritized stack of requirements.
Single Source Information. Strive to capture information in one place and one place only.
Test-Driven Design (TDD). Write a single test, either at the requirements or design level, and then just enough code to fulfill that test. TDD is a JIT approach to detailed requirements specification and a confirmatory approach to testing.
if any queries contact me at
Hello Team,
An Agile team is different from the average development group. Team members come across as poised and ready for where ever the project may lead them. An Agile team member does not fear uncertainty. They look forward to the challenge and they know they will succeed.
Where does this air of self-assurance come from? Is the attitude reflective of the type of people that were hired? Or is it reflective of the processes that are being used? Is the attitude a byproduct of executive support? Does the confidence come for a history of successful deliveries?
The answer to all of the questions above is yes. Each of the items described above supports the effectiveness and self-reliance that is inherent in an Agile team. In some ways creating an Agile team is like baking a cake. You can obtain the ingredients exactly as the recipe requests. You can bake at the suggested temperature. You can let the cake cool the specified time before applying the icing. But what happens if you are at high altitude and you forget to make the necessary adjustments? The cake rises too quickly and then turns out too dry. Or what if someone jumps up and down in the kitchen while the cake is baking? The cake collapses and never rises.
Regards,
Saiyid
