What is agile analysis?
Simple put, “finding the stories anyway you can”.
Analysis is classically defined in the dictionary as breaking something down
into it’s component parts or pieces. We will explore a different definition of analysis so that it supports the notion of agile / scrum product development.
Analysis is finding an opportunity to proceed and agile analysis is finding those opportunities any way you can. Typically in agile we use stories as the fundamental element in analysis. We use stories as a way to drive the team or channel the teams effort toward desired outcomes. In scrum, stories are prioritized by the Product Owner who may or may not have found them.
When we do agile analysis we are finding these stories anyway we can. The goal is to cause movement. Movement from the team will reveal issues, realities and impediments faster. The more complex a problem then the more we are looking for ways to move which will allow us to explore the problem from other angels. The exploration of a problem space is analysis and it often yields more opportunities to stories. There are many techniques we can use to find stories (i.e. Use Cases, CVA, User Roles, Themes, Epics etc).
For more on this contact us for our white paper or take our training course on Agile Analysis.
Scrum coaches are vital to the success of any scrum implementation. Although the role scrum coach is not called out formally in Scrum, the notion of Scrum Coach can be thought of as someone who is very senior in experience and typically someone who has been an experienced ScrumMaster previously. A senior expert in Scrum can also be thought of as a Scrum Professional, certified or not. Scrum coaches find ways to nurture and advance the knowledge of applied scrum within an organization. The notion of an agile coach is similar to that of a scrum coach.
In all of these cases what is important is that professional have experience in applied scrum and helping organizations stay or become agile. Find a good scrum coach to help your organization apply scrum across the enterprise.
“Becoming agile is an agile process, staying agile is an agile process.”, DW
Understanding distributed agile development or teams is easier when we consider distribution of agile teams along two dimensions. The first dimension is separation. Separation occurs along time zones, physical distance, language, culture, The second dimension of a distributed agile development effort will be gravity. Building and sustaining distributed agile development efforts requires a process that focuses on teams and building up their protocols one at a time. Tools can help in this distribution process and enable a rapid evolution of team behavior. However, most organizations
simple look at the tool as the means and never find the way. As a result most efforts of distributed agile development are still done very mechanistically which often leads to process fog and low success outcomes. The dimensions of separation and gravity gives us a way to consider things that encourage distance vs. those things that bring the team close together.
ScrumMaster is a role in the Scrum Methodology. Sometimes it is written as “Scrum Master“. The ScrumMaster is responsible for the health of the team. They are sometimes referred to as the project manager but, this title is usually not appropriate.
The ScrumMaster removes impediments or helps identify impediments to be removed. The ScrumMaster helps both the team and the organization become better. A good ScrumMaster is someone who likes to work with people and can establish a pattern of continuous improvement.
A ScrumMaster with technical background is not required but, can help. However, the ScrumMaster does need to be passionate about people.
Many organizations are faced with the demand to work online and through virtual forums in a scrum like manner.
So, why is there so little emphasis on getting agile / scrum online IT
certification training? Organizations are conducting their work this way and professionals should be getting their training this way. Training in person is one type of valuable training and training delivered via distance methods is another. Both methods of delivery should be done in an agile manner and train the IT professional to master skills in both instances.
Scrum methodology belongs to the family of agile methodologies. Scrum like agile in general marks a dramatic departure from classic methodologies (often called waterfall but, this is not an appropriate name) which have been known for their strong structured upfront approach. The Scrum framework is extremely light and often misunderstood because of its stark simple nature.
Scrum was inspired by the realization that classic approaches to software development were showing a dismal track record and that almost no process process was getting the job done.
The Scrum methodology yields better communication and collaboration, working software, and the ability to adapt to emerging business realities.
ScrumMaster training is intended to prepare you to lead Scrum team. Leading a scrum team as a ScrumMaster is radically different than traditional project management. Traditional methods of plan, instruct, and direct are replaced with facilitation, coaching, and leading.
Most training courses today follow a 2-day format and offer a
Certified ScrumMaster designation. Training should provided the fundamentals you need to begin a mastering Scrum. Training is typically provided by Scrum Alliance recognized trainers.
Generally, this word can be used for any Agile Practice but, we will focus on the word by using the Scrum Framework for context. From a Scrum point of view we can understand commitment based planning as something that takes place between sprints.
Planning, for an agile team, is actually a commitment that the Team makes. In Scrum, this commitment is based on a negotiation between the Product
Owner and the rest of the Team, where the Product Owner is speaking for all the Stakeholders that are outside the Team.
For more read commitment-Based planning, and the major issues that arise when doing it.
Commitment-Based planning begins with the Product Owner having a collection of Stories sufficient to fill the Sprint. Typically, you would expect up to two or three Sprint’s worth of stories to be available, with a minimum of 1¼ sprint’s worth. See the chapter on Backlog Grooming (xx) for discussion of getting stories ready for planning.
- At the beginning of planning, the Team discusses the overall goals and priorities, and the PO selects a single story to consider (the highest priority). The Team (including the Product Owner) negotiates the “doneness” Agreement for this single story, and the Team (without undue influence from the Product Owner, or consideration of the Story’s size in SPs) commits to this single story. What they are actually committing to is the “doneness” Agreement, which we typically simply refer to as the story’s Agreement.
- The Team may not be able to commit to a story, or might not even be able to agree on “done.” This makes the story in question an epic, by definition, and the Team must decide what to do. Typical choices include committing to an Analysis Story to figure out what to do about the epic, or extracting a smaller story from the epic to do instead (putting the remainder back on the backlog), or skipping the story altogether and moving to the next one.
- After a Story is committed to, the Team (with the PO in the lead) has the option to reprioritize the Story list, and the Team takes the next one to consider. Once again, the Team comes to the “doneness” Agreement and commits to adding the Story to the list of already-committed-to Stories. This process is repeated until the Sprint is “full” and the Sprint Plan is complete.
Summary:
This process is quite simple, but leads to a number of issues that are tightly intertwined.
A useful contrast is Velocity-Based Planning vs. Commitment-Based planning. Generally, Commitment-Based planning is better than Velocity-Based planning for most agile teams.
The approach for metrics in agile is often different because of the intent you are using to measure things. Agile metrics need to be collected from the system without being used as a tool to drive behavior. The reason for this is simple. Most people doing agile or scrum development are using it for highly creative acts. The common phrase you get what you measure shows up big time here. People will optimize their behavior to support the metric but, when this happens the creativity plummets. 
Read Perfect Planning for a deeper discussion of this topic.
Creative acts are exactly that, new creative and cannot be measured for ahead of time because we don’t know what they are. Use an agile scorecard to understand velocity and commitment based planning.
The word information radiator is analygous to big visible display as it is generally used in the agile / scrum lexicon.
There are many forms of visible displays…
- task boards
- request planning boards
- card pulled systems
- slip methods
- scrum planning boards
- sprint planning boards
- product planning boards
- road mas
Each one of these works when it engages the human visual systems and makes a focused conversation easy for 2 or more participants.
Digg
into it’s component parts or pieces. We will explore a different definition of analysis so that it supports the notion of agile / scrum product development.
