1) "Coach as Facilitator " Please respond to the following:

 A) Read case study titled, "Agile Communication Tools and Techniques" located below. Suggest at least two (2) strategies that an agile facilitator can use to coach his / her team during standard agile meetings. Suggest two (2) actions that an agile facilitator should exhibit and two (2) actions that an agile facilitator should not exhibit during the meetings. Provide a rationale for your response.

 B) Recommend two (2) ways that one can use powerful observations, powerful questions, and powerful challenges in order to help a team's communication. Include two (2) examples of the recommended actions to support your response.

2) "The Natural Step" Please respond to the following:

 A) Review the "The Natural Step" attached separately. Discuss whether or not backcasting is an important concept for addressing major forces that shape the role of IT in organizations that compete globally. Explain your answer.

 B) Reflect upon sustainability from the perception of the CIO. Explain why sustainability should be an important concept for every CIO to embrace and support within the IT organization.

3) "Reasoned Responses" Please respond to the following:

 A) Take a position on whether or not the CIO should develop reasoned responses that are driven by the company objectives. Explain your position.

B) Explain how IT strategy facilitates organizational decisions that are related to the forces that shape the role of IT within an organization (consider domestic and global environments).

Analysis and Design

Analysis and design is very important on an Agile project. They're important concepts in Waterfall projects as well, but one of the advantages with an Agile project is we don't have to spend nearly so much time at any given iteration doing the analysis and design work. An iteration in Agile is going to start off with a planning meeting, and we're going to pull off enough user stories that we think we can complete them in the given iteration. But think about those user stories themselves. They're written basically as a description of how certain people might interact with the system, and what's going to happen first and second and third and fourth. They're basically stories, they're textual stories that describe functions that take place in some kind of a system.

So, once we get those user stories, we've still got to do some kind of analysis on them and figure out what are the detailed requirements. The user stories are written kind of high level. They're written with enough information that we can remember what we're talking about, and we can remember what the nature of the function is, but we still have to do the analysis of what are the detailed requirement or specifications.

That's going to be required in Agile projects, just like it is with a traditional Waterfall project. The big difference, though, is that in a Waterfall project, we're going through all of the requirements at once, and we're getting all of the design done at one time. In the Agile project, we're just taking as many user stories as we think we can get done in that iteration. So there's going to be a handful probably that we're going to have to worry about. So we'll do the analysis fairly quickly. We'll be able to get through the requirements process and figure out what are the things that need to happen on this project fairly quickly during the iteration.

We'll then move into design, and this is going to be design, again, within the given iteration. We don't have to worry about designing the entire solution at once. We only have to worry about designing for the particular requirements and user stories that we're developing during this iteration. So although design is very important, there's just not as much of it to do at any given time with the Agile project. We've broken up the requirements and the design into smaller pieces as well. So there's a tendency to think about Agile in terms of breaking up the coding, but we're breaking up the whole lifecycle into various iterations, and it makes the whole process easier. Now, there's a challenge, especially on the design side.

There's a challenge that we have to do some high level design and some high level architecture before we have all of the detailed requirements, so there's a little bit of risk associated with that, but with most Agile teams, they can get the architecture pretty close the first time, and as we go through the detailed requirements, when we look at the detailed design that's required to support those, if there are changes that are required, we can make those slight modifications as we go. So, those are some specific ways that we still need to use analysis and design within each Agile iteration.

A couple other things that Agile teams use, one of them is called a persona. Personas are ways that we can capture characteristics about different roles or different actors within the user story. For instance, if we were doing some kind of a class registration system, we can define a persona as a student, and maybe even a couple ones. We could have a persona to be a tech-savvy student and another persona to be a student that doesn't have nearly so much savvy with technology. And by developing these personas, we can then identify those personas in our user stories and not have to document so much within the user story. We could just identify the actors in terms of the persona and then be able to understand intuitively what that persona means.

Also, another technique we use in an Agile project is modeling. Modeling is used on traditional projects, sure, but it's also important on Agile projects. The big difference with Agile projects is the modeling is usually pretty simplistic. If we're doing process models, we could just put yellow post-it notes on the wall with little lines between them that represent the process flow from activity A to B to C to D to E. We don't have to worry about fancy technology and big tools. We can do it all on a light manner.

We don't have nearly so much we have to worry about at any given time in an iteration. We can also do data models that represent the characteristics of different data elements and how they relate, but again, we'll do them in a fairly light manner, probably again using some kind of a whiteboard or some kind of a flip chart in order to identify the major characteristics and the major relationships between the major data elements. So all of those analysis and modeling and design tools are still used with Agile projects, but just much more simplistic and a much more light fashion than a traditional Waterfall project.

Attachment:- the_natural_step.pdf