——————————————————————–

Why Scrum Developer?

Modern software development is radically different from traditional software development. The procedural systems we built in the past are being replaced with business applications that demand more.  The new business application needs are more complex and thus require better engineering skill. Building these modern business applications requires a team with deep skills in agile process, design patterns and development practices.  These applications are often managed using an Application Lifecycle Management (ALM) Framework that uses Scrum Framework for building the Product. Applied Scrum requires a well formed team with Developers who know what to do.

Working on a modern software team requires a change in both how we build & how we work together. Scrum is a process that was born from the study of effective software development practice. While Scrum has proven itself to be amazingly applicable to other kinds of product development work it is still in demand and growing as an applied practice in software.

Organizations recognize the importance of their software development professionals but, what is often unrecognized is the intense interaction between teams and technology in building today’s products. This Certified Scrum Developer course is designed to do address both the human& technical challenges of a software developer. This course is delivered in the context of a Scrum team that is working to build a modern software centric product focused by business value.

We use stories to drive the team’s work effort. In scrum, stories are prioritized by the Product Owner. The stories are then broken down into tasks by the team. Stories are also know as backlog items in scrum.

Adaptive 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.

The 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.

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:

Sometime 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.

Choose:

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.

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

This makes the word contextually dependent on what it is we are considering. For example each picture below demonstrates the meaning of the word agile by leveraging common metaphors we use. The word when used this way shows up in nature and in man made things. The word agile in this context is moving through time and being able to negotiate patterns and thrive. There are several notable agile development methods with the most popular one being Scrum. The definition of agile follows closely from the dictionary which says nimble or quick. The notable difference from the dictionary’s use of agile is setting this word up to describe a method for a system or team.

A  pursuit in this context would be called an effort, work or project. However, notice the phrase “quick enough”; why is that wording used and relevant.

History:

The agile movement got its biggest boost in the public sector in 2001 with the signing of the Agile Manifesto 2001 and agreement on the word agile to span the class of methods that were being used at that time. The signing of the Agile Manifesto gave birth to the industry agile management movement.

Most of the modern day agile development methods were born from software development practice. However, agile development methods have shown themselves to be easily applicable to other domains especially project management. Software development enabled a rapid feedback loop that allowed a viral exploration and evolution of collaborative methods between humans and technology.

The word agile was extensively used by the military before 2001. The word agile was used in at least one military project with the intent of developing software/hardware using an agile method as early as 1983.

The Agile Alliance 2003 and Scrum Alliance 2005 were both born after the singing of the Agile Manifesto. The Agile Manifesto is also supported by 4 values and 12 principles. These 4 values and 12 principle constrain the definition of agile and thus, trend towards predictive thinking. More on this in a future post “Exploring the 12 Principles of the Agile Manifesto” and “Exploring the 4 Values of the Agile Manifesto”. We will explore both the 12 principles and 4 values, against the definition of Agile as set forth in this article.

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.

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)

In Scrum we have 6 formal time boxed events.

1. Releasing Planning
2. Sprint Planning
3. Sprint
4. Sprint Reveiw
5. Sprint Retrospectvie
6. Daily Scrum

Other time boxes can be applied and should be. The purpose of the time box is to cause movement and to set an expectation that we will limit the time and energy spent in any one direction. Generally people will fall prey to taking on too much work or big amorphous work that has no discernibly edges or clarity. Our understanding is similarly fuzzy and vague.

We can use a time box for many things including as a guide line in how we break work down into tasks or execution. Sometimes people use time boxing as a way to avoid gold platting or excessive polishing of an item or thing.

Time box is a critical practice in agile / scrum and should be applied with care. Arbitrary time boxing can drive motivation down and should not be used as a tool to create a frenetic pace or fearful environment. Time boxing is an important tool for any good scrum master or facilitator.