Agile vs Waterfall Video Reactions:

Kate and Rusty have the same goals: to build a great product for their client. Their approaches, outcomes, and results are very different. Neither is right nor wrong. BUT I sure know which team I would appreciate.

Tear down the walls of silos, put multiple heads on a problem, and engaging the client frequently are all hallmarks of agility and gaining business value. Every wonder how they get those video games to market so fast? Agility. Proudly deliver a product every two weeks to your clients…

Agility is the ultimate in teamwork. Projects move fast and everyone pulls their own work, thereby creating accountability. Boss-worker mentality is a thing of the past. Kate’s team stays fresh and motivated. Rusty’s team has a hard time staying in for the long haul.
Which team are you on?

Are Product Demos painful and shallow on the feedback?

This is what we hear from our Scrum teams over and over.  The Scrum framework is simple and elegant, but implementation can be complex.

Asking questions is risky business.  We have no control over the answer and we may not like the answer.  But as ScrumMasters, Product Owners, and developers, we must be fearless in our quest to drive greatness for our end users.   Here are some question examples to bring life to your next Scrum ceremony.  

We use an agreement driven approach to handle planning at all levels. In each case we are building an understanding of what we think we can do. For complex work we often encounter new information while doing the work that causes us to rethink and build new agreements.

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

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.