Scrum Development Blog

Better teams make better products.

Posts Tagged ‘scrum’

Adaptive Planning

Scrum Terms | Posted by The 3Back Team
Apr 27 2010

adaptive planning and agility in businessAdaptive Planning and Analysis

One of the biggest problems that we encounter in software development is change.  Change comes in many forms and from any sources, but any work that we have done will be degraded over time by change.  The world is going to change.

The traditional approach of trying to plan the project in detail before starting is not immune to this degradation.    This approach also has an implicit assumption that the team knows everything it needs to know to plan the project before starting the project, when they know the least about the problem they are trying to solve.

The goal of complete up-front planning, analysis and specification is to understand the cost, delivery date and features to be delivered by the project.  While this is a valuable goal, often times the cost of the effort to deliver such a plan and specification is not appropriate for the value delivered.    This is true for three main reasons.

  1. The first is the impact of change on the project.  Even if the team could deliver an accurate plan and specification at the beginning of the project, any project that takes more than a few days will almost certainly be impacted by change.
  2. The second reason is even more significant.  Traditionally project managers, subject matter experts, business analysts and sometimes designers and architects do the up-front planning.  The people that are expected to do the work often have little input at this phase.  The schedule is created with functional dependencies mitigated by a complex project plan.  Then the team members doing the work are managed against the plan and schedule that they had little, if any, input into.
  3. Thirdly, if the goal of the organization is to deliver business value quickly,  the question becomes what real business value is delivered by a plan that is most likely fundamentally flawed due to lack of knowledge and understanding of the problem domain and will become more inaccurate as time passes? The answer is commonly, very little.  So let’s get started!

This does not mean that we don’t do any planning, analysis and specification, just that we do what we need to get on to the next steps in the project.

It does not mean that we don’t do any long range road mapping or release planning, just that we recognize that these plans will become more accurate and valuable over time.

adaptive planning changeThe goal of agile analysis is to deliver just enough planning, analysis and specification, just before it is needed to do the work of delivering the business value.

Nor does it mean that we do not estimate the effort involved in delivering the business value, but we do it in a way that will help us estimate the effort more consistently in the future.  That means teams should use a system of planning and estimation that creates the learning that will over time lead to more consistent results.  The first step is involving the developers in that planning.  Using an estimating system that is not based on hours for project planning focuses the team on the work and allows the growth of a tribal-knowledge based system that will lead to more consistent and predictable results.

Tags: , ,
No Comments »

Capabilities

Scrum Terms | Posted by The 3Back Team
Apr 19 2010

Brief:

A capabilities are something that a stakeholder has asked for. Because a stakeholder has asked for they see value in it from their perspective. We call anything the stakeholder asks for as something of value and something they desire. Stakeholders can be considered as observers of the systems, sometimes users and they see things from the view point of capabilities or collections of behavior that they want the system to provide.

Word Confusion:

capability agile wbs open ended in scopeSometime we use the word feature, big story, enhancements, desires, big requirements or major feature to describe these things. However, this often leads to a confusion in the use of words and does not support the analysis. To keep things clear and make the point better with a clean WBS we will focus on primary decomposition pattern of  Capability – Story – Task. The picture will become more involved and complicated than that but, we will focus on the simplest pattern to solve each step of evolving difficulty in managing and analyzing a complex problem. We will answer the questions of a more complicated analysis pattern in an upcoming post on the Analysis and an Agility Enable WBS.

We will break capabilities by the following pattern:  Product => Capabilities => Stories => Tasks (more on this in another post)

What is a capability?

Typically, open ended and fuzzy in scope. A system is made up of behavior that can be broken down into capabilities from the view point of the observer of that system. As an analyst / Product Owner, The point of view we care about is that of the stakeholders.

Capabilities are the things we talk about what our stakeholders, and we talk about them in the stakeholder’s language.  Strictly speaking, capabilities are seldom of concern to the development team, as the developers will be working on stories, which we’ll discuss later in this chapter. Capabilities far too often too big, hard to validate chucks of work, so it is not something we want to feed our team directly as an item of work. The reason is simple, large chunks or difficult to validate chunks of work lead to elongated feedback cycles and this is what got us into trouble in the first place.

Why?

Our development is being done to acquire those capabilities for the stakeholders, and therefore we must be able to talk about capabilities with our stakeholders. Capabilities are the language the stakeholders and thinking in and it’s is what they will use to understand the product we have built.

Tags: , , ,
No Comments »

What is the basic building block in applied Scrum?

Scrum Questions | Posted by The 3Back Team
Apr 13 2010

What is the basic building block in applied Scrum?

Choose:basic scrum team building block

  1. Team
  2. Individuals
  3. Practices
  4. Scrum Team
  5. Scrum Framework

The Scrum Team is self organizing, self managed, cross functional and self aware. Organizations using scrum rely on the basic building block of a Scrum Team to understand how to it can be applied in their context. There is an assumption here that the team exists for some purpose and they have been assembled. So the team is not self assembling. The Scrum Team figures out how to do its work, manages itself to do the job, has all the skills necessary to get the job done and uses its values to deepen its understanding of self to perform better as a well formed team.

Tags: , ,
No Comments »

Agile Development

Agile Pathways, Development, Scrum Terms | Posted by The 3Back Team
Apr 08 2010
empirical-thinking-vs-predictive

Empirical Team Thinking

Agile development is now commonly referred to as those set of methods that come under the umbrella term agile or support agile thinking. To avoid a circular set of definitions we will define the word agile.

Agile is being quick enough to avoid or take advantage of those things that can hurt or help in your pursuit.

A  pursuit in this context would often be called an effort, work or project. However, notice the phrase “quick enough” why is that wording used and relevant. The biggest difference here and said in a very summarized way (which does not reveal the depth of thought behind it) is the difference between predictive thinking vs. adaptive thinking.

No matter who you are and what you do we will all fall prey to predictive thinking in varying degrees. To reduce the likely hood of being tripped up by predictive thinking agile frames a state of mind that leverages those around us to help us detect when we are being predictive and should be adjusting our plan based on new information rather than ignore it. Said another way is that we fail to detect/ignore when our assumption are no longer valid. So, agile is a social agreement to be empirical as a team. Agile development is a description of how we can put that framework to use as a well formed team. A framework for agile development is especially important as the complexity of our effort increases. For simple problems or things that are complicated but knowable a standardized process is suitable. For complex problems that can change just by looking at them we need an empirical framework.

Agile Methods that Support Empirical Thinking

Spectrum of Agile Methods

There are several Agile methods which support an Agile Development process. However, each one is best called a framework because it is applied in a unique way for each context of use.

The above diagram represents the best way we have seen to describe the agile development methods available. The ones on the right are more Bodies of Knowledge and are vast. It is their very nature of vast that can cripple a team of people trying to focus their effort. Typically large systematized thought models can become more than I want to think about and crowd out the purpose for me focus which is my effort/work/project or product that I am trying to build.

There are more such as TSP / PSP but, this model paints out a quick spectrum that summarizes the models of thought and those that sit on the boarder such as RUP. The bodies of knowledge on the right have some very good practices, processes and methods in them and should not be ignored just because they are vast. Often when you scale past 70 or so people on one project effort you will need many of the techniques that can be found in the bodies of knowledge on the right. Or if you are simple running a call center where things are complicated but, knowable and creativity for transcending the current established patterns is not desired then they are more appropriate. We would call this things that fit SOP (standard operating procedures). However, were creativity is desired and the problem is complex then the models that support agile thinking are the only ones that seem to work.

Scrum is by far the most popular of the agile models and has shown some of the best success and transaction because it is not vast. Scrum is a simple rational framework that can be memorized in 20 minutes. Applied Scrum is exceedingly difficult to do well because it requires a tremendous amount of discipline and challenges standing assumptions. The ability to reveal and challenge standing assumptions is what has made Scrum so successful. Scrum has proven itself beyond the realm of software development (form where it orginated) however, its language and purely rational approach are its weaknesses.

A quick list of agile methods

  • Scrum
  • FDD
  • Lean
  • XP
  • Crystal
  • Kanban
  • Other often proprietary Special forms…

When doing software development work a popular pattern is to use the Scrum method wrapper the XP coding practices. This is recomended and has been found to be one of the best patterns for success.

Transitioning to an agile thinking process is best done by building Agile Pathways that supports and nurtures a pattern of adoption. It is important when applying agile to not toss out established processes that work but, instead reveal how they can be improved and reinvigorated. However, a solid implementation requires an almost prescriptive start. There are too many hidden assumptions that need to be re-explored and often changed.

  • Some short phrases that help focus on agile thinking
    • Let the product lead
    • One bite at a time
    • No head works alone
    • Be empirical
    • Reflect early and often
    • Make it visible
    • Pay attention and adapt

The agile movement got it start in the public sector in 2001 with the signing of the Agile Manifesto. The first project done under the term agility and done with 1 week development cycles was in 1983 (more on this later).

For those new to agile, Scrum is a recommended place to start.

In all cases of applied agility or scrum the analysis sets the tone. Without agility in the analysis the remaining part of your effort will “waterfall” or fall prey to predictive thinking. The following set of techniques assumes a complex problem or situation. Analysis is looking for an opportunity to move. There are a few analytic techniques that show up

  • No head works alone: peer review your thought process with someone and avoid heavy process driven peer review
  • Don’t make a belief out of a model: use a data rich subject matter orientation so that you don’t try to overly tidy your thinking at the wrong time
  • Highlight areas of risk and uncertainty: the number one risk is building the wrong thing! adjust your analysis to mitigate that risk first
  • Conceptualize appropriately through time: watch which techniques you are thinking with when you move from past certainty to future uncertainty (i.e. accounting vs. finance)

Tags: , , , ,
3 Comments »

Story Boss

Scrum Terms | Posted by The 3Back Team
Apr 07 2010

story boss scrumIn Agile or Scrum we often see the need for someone to be the Story Boss. The Story Boss is someone who is in charge of the story and sees that it gets to done. The most common place for this is with analysis stories. The Story boss is a temporary role or focus and after the story is done the need for this fades away. The story boss is simply an easy way for the team to track who will be chasing that story to completion.

Tags: , ,
No Comments »

Architecture

Scrum Terms | Posted by The 3Back Team
Apr 02 2010

architecture agile scrumArchitecture is the context within which particular stories are implemented. In the context of scrum or agile we are considering architecture from the context of  software development. The purpose of software architecture is not to define the place for the pieces as much as it is to separate the dependencies of the pieces. The purpose of architecture is not to build a framework within which all things can nicely fit. It is to define the relationships between the major concerns of the system so when they change or new requirements emerge the impact of the changes required are limited to local modifications. Limitation of concerns to local areas allow us to think of the system in a computerized fashion and treat things as independent encapsulate modules.

Architecture has an inherent beauty of design that invites the mind and allows its purpose to be adapted as needed.

Tags: , ,
No Comments »

Sprint Review

Scrum Terms | Posted by The 3Back Team
Mar 28 2010

Sprint Review is when the Product Owner and the Team show the team’s results to their Stakeholders.

There are a few reasons we do thissprint review product demo plans

  1. get stakeholders feedback on what has been done – How do you like it?
  2. improve confidence in the product’s investment – What did you spend the money on?
  3. maintain a rhythmic pattern of feedback –  Take small bites of work and feedback.
  4. manage expectations – Help others see how this is evolving so they can position for optimal product success.
  5. change direction as needed – Detect changes in direction early and often

If necessary, the Release Goals, Release Strategy, and Backlog are updated as part of the Review (or soon thereafter), taking into account the review and any “business reality” changes the Stakeholders may have . When teams are small we can rely on more intuitive reasoning to determine what the “right direction” is. As we scale we will see a need for more sophisticated techniques that use metrics to help us us answer what the “right direction” is.

Tags: ,
No Comments »

Team Swarm

Scrum Terms | Posted by The 3Back Team
Mar 11 2010

Team swarm is an observable pattern of cohesive team work. The word swarm is the right word because to an outside (outside: someone not directlyteam swarm scrum on the team doing the work) observer the pattern almost looks random. However, to those on the team they are moving with intent and purpose even though the observer cannot easily discern why they are focused the way they are.

Well formed teams will exhibit a team swarm pattern after they mature. A good sign of your team maturing is that they tend to swarm and jump on work together and often one story at a time. This is an observable point of view that the Scrum Master can use to detect when his/her team is starting to work well together. To an untrained observer this will be a sign of chaos and the tendency is for them to step in and clean up mess “who’s in charge here anyway” or “this needs to be tidy’ed up”. These types of management practices are anathema to a good agile scrum team and interfere with it’s ability to self organize.

The pattern of team swarm is generally observed for teams when strong task orientation is present. Scrum teams are often working on software development problems that require a team head to work through. The Product Owner, in scrum, provides the direction or line of purpose for the team.

Great project management recognizes team swarm and is good at stimulating the environment to encourage small team tactical behaviors. A competent agile project manager will not usurp the teams work pattern to fulfill a desire to know what is happening. This means that reporting of work done on the agile team is incumbent on the team members to make it visible. Therefore a great leader charges the team with the constraint to both make it visible internally so that common task orientation and make it visible externally so that reporting/decision making can be supported.

The team swarm pattern is critical to decision making. Tactical agility (team level agility) can result when the work is visible and an emergent adaption can occur. Externally there is a need to supply concrete realities the team encounters to inform and enable strategic agility. Again this informs decision making both internal and external to the team. A trained agile project manager will know how to stimulate team behaviors without compromising the team’s need to self organize and simultaneously feed that information up the decision making apparatus of the organization so that strategic agility can happen. The result is a bidirectional flow of information. Team swarm is one way to know you are on the road to making that happen as smart as possible.

Tags: , ,
No Comments »

Professional Scrum Training

Scrum Terms | Posted by The 3Back Team
Mar 11 2010

scrum team goldThere are a number of organizations out there offering Professional Scrum Training. Most of them are part of the Scrum Alliance which maintains a strict set  training practices and quality standards. However, there are many who are starting to offer their own certification and special class of designations because of money or because they could not tolerate guidelines they did not personally control.

Scrum is a open development methodology founded by a team and has a long history of being team based in it’s origins. There are some very strong writers who have popularized Scrum and are well known for their work, writing and contributions.  More later on the founding history of Scrum….

Tags: , , ,
No Comments »

Team Fragmentation

Scrum Terms | Posted by The 3Back Team
Feb 27 2010

Team fragmentation occurs when there is a lack of unifying purpose in product development work. For simple groups this is often referred to as task orientation. Since the word task is so heavily loaded in agile project management or an any agile / scrum team our industry commonly uses team fragmentation.

In agile distributed teams can easily become fragmented from lack of task orientation. For a distributed scrum agile teamscrum team fragmentation this can be very challenging. Most organizations are faced with the reality of distributed team work in the form of offshore or nearshore typically done as outsourcing.

  • How do you manage these teams?
  • How do you bring new team up to speed?
  • What tools do we use?
  • How do you juggle time zones?
  • Language barriers?
  • Cultural barriers?
  • How do you form effective team habits and without getting blinded by process fog?

Successfully developing a product with a distributed agile team is a modern day challenge most companies.  For the 3back team this topic is one of our favorite.

Tags: , ,
No Comments »