What does the 2nd Agile Principle (Welcome Change to Requirements) look like in Action?

Many want to go Agile or claim to be Agile. The question is, are you and will you really align with the Agile values and principles?  To better understand what this means, I dissected the Principles to better discover the intentions behind them and what behaviors they entail. In this article, I expand on the second Principle to better understand what it means and to attempt to model how to marshal supporting evidence that a culture change may be occurring.  

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage is the second Agile principle. From an Agile perspective, you embrace change to increase the chances of delivering value to the customer. You embrace change because you understand that change is necessary as customer needs, market conditions, and general demand change over time. 

Welcoming change implies several qualities. The first is that there is a positive attitude toward change from the team and management. The second is that while change ideas are admitted, they are methodically prioritized based on customer value along with existing requirements. The third is that there is a process that allows prioritized changes to flow without obstruction.

What actions may exhibit “welcoming change to requirements”? Some evidence includes:  

• The PO continually engages with the customer to identify new requirements or changes to existing requirements. 
• A methodical review of the change idea occurs to determine the priority amongst the existing requirements.
• No person or process restricts incoming change ideas. 
• The backlog is continually refined and reprioritized. 
• Increment Planning and/or Sprint Planning is applied to introduce the newly prioritized requirements. 
• Continuous customer engagement via customer visits and sprint reviews are applied. 

It is up to you to determine what supporting evidence will highlight that a culture change is occurring. It is worth experimenting with this as it will help you better understand and embrace the Agile principles. The ultimate question, if you really believe in this principle is, do you welcome change?

-------------------------------------------------------------------------------------------------

To learn about what evidence might look like to support the 1st Agile Principle (aka, Satisfying Customer with Valuable Software), consider reading: https://cmforagile.blogspot.com/2023/09/many-want-to-go-agile-or-claim-to-be.html

Agile Brevity

When working within an Agile context, there is an emphasis on getting work done and meeting the outcomes of the customer needs. The work is typically structured around various Agile ceremonies depending on the methodology or process a team is using. Key to these ceremonies is to keep them concise. In order to do this, often timeboxing is introduced. However, timeboxing is only as effective as the people’s abilities to keep their discussions concise. I call this technique “agile brevity”.

What is agile brevity?  It is a speaking technique that is both art and skill focused on keeping one’s comments as clear, concise, and value-added within the context of the session at hand. This means that the brain must be hyper-focused on the context and purpose of the session and speaking with agile brevity within that context.  It then means that the person must consider what is the most important thing of value to say that will help progress move forward. This leads to more productive and collaborative working sessions. 

Consider the Daily Stand-up. It is meant to be applied at a team level (~7 people) and take no more than 15 minutes. This means that each person has approximately 2 minutes to communicate progress and impediments. Teams new to the stand-up usually takes much longer than 15 minutes to get through their progress as they don’t yet have experience of being brief. Agile brevity means that they must consider what is the highest value information to communication the progress from yesterday, the highest value information that focuses on the work today for potential collaboration, and the specifics of any impediments so others understand it enough to potentially help, all within a very timely manner.  

Agile brevity also applies to Refinement and Sprint Planning ceremonies. Within the context of these ceremonies, there is typically a timebox on how long is spent on each user story. As there is less structure in refinement or planning ceremonies than a daily stand-up, the hyper-focus of crisply asking the right questions to understand the user story is even more important.  The other attribute of agile brevity is determining if your question or information is of greater value than another person’s question or information. In other words, many factors should be quickly swirling in your head before you speak. 

Agile brevity is a combination of art and skill keeping one’s comments or questions as clear, concise, and value-added on the topic at hand as possible. It keeps people mentally focused, keeps working sessions tight and to the point, and ensures the highest value information and questions get discussed. While its called “agile brevity”, it isn’t specific to Agile and can be used to make any ways of working more efficient, effective, and value-added. If you find your working sessions often running long, consider trying this technique.   

Applying the Pair Protocol beyond Programming

-->

Pairing isn't just for programming, it can be advantageous to have two people pairing on any type of work. Have you ever had to pair up with someone on a piece of work?  Have you ever launched into the work only to realize that you haven't discussed how to pair up or realized that you aren’t really working well together? There are dozens of different ways to work as a pair so it is important to have protocol on how to work together through a piece of work.  I call this the Pair Protocol.  This is a guideline on how two (or more) people engage together in a piece of work to have the maximum alignment and productivity. The objective is to get two people to work as one. 

Setting the stage 

You need a piece of work, team of people, and the right pairing mindset. The piece of work can be a feature, a user story, a requirement, an increment, or similar that has been refined so the work ahead is clear.  This forms the basis for what you pair around.  You need people who are coming together for a common purpose, know the context around the work, and are willing to work together.  You also need a mindset of “we” and “us” over “I” and “me” as pairing implies that all collaborators of the work in harmony and get the credit together.   

Pairing up 

The first step is for two people to volunteer to do the work together.  This implies each person is ready, willing, and able to do the work. It also means they can self-organize around the work (e.g., to have the option to volunteer for the work and have the ownership to determine how to do the work).  This typically occurs in a session where the work has been discussed and it's time for people to volunteer to do the work. This could be in a form of a planning session (e.g., for Scrum it would be Sprint Planning, for Kanban it would be the Queue Replenishment, and in traditional approaches, it would be a project planning session. The outcome is that two people (aka, the pair) have willingly volunteered for a piece of work.

Working together

Once the pair has been created and the planning is done, the first step of beginning the work is aligning on how the pair will work together. The pair will briefly meet to re-familiarize themselves of the work (e.g., discuss the “why”, acceptance criteria, etc.) and then discuss how they will navigate through the piece of work (e.g., through task decomposition). This includes an agreement and commitment on who will do which tasks, how they will do the tasks, and when they will do the tasks. As this is pairing, there may be tasks where the pair works together. If so, discuss and gain agreement on how this will occur (e.g., working session, etc.).

Capturing Discussion

As you pair through the sprint, increment, or time period, you should capture important conversions and decisions where the work definition (e.g., user story, etc.) is recorded. There may be ‘discussion’ functionality that can be used that allows the pair to remind themselves of the discussion. 

Incorporating Feedback 

It is important to agree on how you will notify each other when a task is complete and what types of feedback loops you will use with each other and with those outside the pair to gain feedback to ensure the work is moving in the direction of value. There should be an agreement on what feedback loops will be used (e.g., review sessions, etc.) and how will feedback be incorporated back into the work. This information can be recorded in the work definition (e.g., user story details, etc.). If the planning or backlog management tool has a “follow” feature, then activating this will help keep each other aligned with the progress.     

Sharing Results

As the work comes to a conclusion, there needs to be a way to agree that it is completed and meet the acceptance criteria. This should occur prior to sharing the results with the greater team or those outside the pair. Sharing results include identifying the venue where the outcome of the work can be shared and discussed. If you are using Agile or Scrum, the Sprint Review or demo can provide the venue for sharing the work and gaining any additional feedback. The pair should also discuss who would demo the work, collaborate on what type of feedback they are looking for during the demo, then jointly agree on whether they’ve met the acceptance criteria of the work, and what are the next steps (if any). 

Size Matters – using “size” instead of “estimate” on Agile projects

When I help teams implement Agile methods, I find that some folks have a hard time getting their head around “estimating” user stories (aka, requirements) using story points. When I get to the discussion of Sprint Planning where we are scrubbing stories (aka, requirements) as a team, I used to say it is now time to “estimate user stories”. I would emphasize the importance of having the whole team estimate the story together. I also tend to apply the planning poker technique where each team member has a physical or virtual set of cards with the Fibonacci sequence (aka, law of distribution) of numbers on them (e.g., 1, 2, 3, 5, 8, 13, 21, 34, 55, etc.). When it is time to estimate the user story, each team member selects a card from their deck relating to the story points they think reflects their estimate of the work which should include their notion of complexity and risk for that story.

When I educate folks on estimating user stories, some folks ask me to align the story point with days or hours. That’s when it occurred to me… I realized that when I use the word “estimate” it would make some (many?) folks think of the traditional estimation that uses “schedule” as a measure (e.g., hours, days, weeks, months, years). However, in Agile the intent is to size the amount of work based on the functionality you are building for that story. So in effect in Agile, “scope” is the measure of progress. This is when I realized that folks were often trying to apply a schedule measure because of their familiarity with traditional estimation when in fact, story points is meant to represent the size of the functionality we are building or the scope of the work including the amount of work + complexity + risk of that work. In other words, it was like comparing apples and oranges.

With this in mind, I strongly advocate that in Agile it is much more meaningful and appropriate to use the term “size” as the verb to measure the user stories since this relates to the amount of functionality you are building. This is more than just semantics. This takes us a step away from the traditional mindset where schedule is “king” and moves us to the more important focus of scope since to our customers, the functionality is what is valuable. Now make no mistake, there will be trades offs between schedule and scope, but working software that meets customer needs and provides them value is IMHO slightly more important (e.g., working software over schedule).

It is also important to note that a team’s sprint velocity is a representation of how much functionality can be delivered within a sprint. This is yet another reason why I encourage you to use the term “size” since sizing individual stories relates to the functionality you are building and the sprint velocity relates to how much total functionality is delivered in a sprint.

So if you are having trouble understanding or explaining the concept of estimating user stories, think in terms of the scope of functionality and consider using the term “size” instead of “estimation” to break from the traditional mindset of schedule. So maybe size does matter after all…

Agile Definition of Done Starter Kit

I often find it amusing when the definition of ‘done’ in Agile is sometimes called ‘done-done’. This is meant to imply that we are not just done with development (the 1st done), but we are done with testing (the 2nd done) as well. However, if you think about all of the activities that are needed to get stories in a sprint backlog into the shape to be potentially shippable, you should probably call it “done-done-done-done” and possibly more (LOL).

So what is the importance of done criteria? First as mentioned, it helps the team understand what is the expectation of getting a story (or the functionality therein) into shape to be potentially shippable. Second, it helps identify the activities and expectations that must occur to build a quality product. Third, all activities in the done criteria are considered when the team sizes the work during Sprint Planning and, therefore, has a direct impact on the sizing of stories. When the team sizes a story, they need to ensure it includes all of the work described in the team’s "done criteria".
 
I usually bring a starter kit of typical tasks to get a story to "done". This helps initiate an active discussion prior to sprint 1 among the team so that each team member understands the various elements of the done criteria and what elements we are agreeing too as a team. Here is my done criteria (aka, definition of done) starter kit:

• Incremental designing (and what type of design type(s) the team will use)
• Incremental development (per the development programming techniques, and this includes developing documentation such as user guides and non-functional requirements associated with the story)
• Incremental building/evolving the unit tests
• Consideration for incrementally building out automation for regression testing, etc
• Applying appropriate source control, checkout/checkin, and branching/merging
• Applying approach incremental local builds (in private workspace)
• Applying code review (or pair programming if being applied) as appropriate
• Incremental testing (per the testing types, e.g., functional, system, integration, etc., pending how much automation there is)
• Meeting acceptance criteria shared by the Product Owner

At this point, the team discusses these elements and establishes a common definition of done for the stories and the sprint. Now keep in mind that this is the team’s common done criteria and it should be flexible depending on the type of work. Also, once the team agrees to done criteria, expect it to evolve over time and it may be a discussion in the Retrospective if it needs improvement. Some of the effort associated with your definition of done is dependent on what tools, infrastructure, and automation, that currently exists and where you want to go, so keep this in mind.

Finally, if your definition of done has nine key activities, then you can call it the “done-done-done-done-done-done-done-done-done” criteria (LOL).  Maybe just one "Done" is enough.  Once you establish the done criteria for the team, don’t forget to evolve it over time to get you to a quality and releasable product!  

Agile – Its more Disciplined than you Think

Agile is known to be an adaptive mindset and approach to conduct work to better align with customer needs.  A side affect and often a myth to this is that some think Agile allows ad-hoc changes and it gets branded as being the cowboy methodology. Some folks who say they are Agile, use it as an opportunity to abandon processes and documentation so that they can enjoy the wild west life. These cowboys know that they get away with pretending to be Agile since many folks, particularly their up-line management have little idea of what Agile really is. Other folks like to term whatever they are doing as Agile in order to be on the Agile bandwagon.

However, it is the cowboy and those that want to pretend they are doing Agile that propagated the myth that Agile is an undisciplined approach. Ultimately, these pretenders can give Agile a bad name in the organization and industry since others will believe that Agile means no process, implies an ad hoc approach, and is undisciplined.

For those that have followed the formal Agile approaches of Scrum, Kanban, eXtreme Programming (XP), Test Driven Development (TTD), and more, when done right realize fairly quickly that Agile instills much more rigor and discipline than some folks realize. Some who follow Scrum properly for instance, learn quickly that there is much more discipline than they originally thought.

One of the early introductions to Scrum is Sprint (or iteration) Planning.  Imagine every two weeks you revisit the backlog to reprioritize it, then scrub and design each story, size the work, and commit to the work for the next sprint. This is meant to be a rigorous day of really understanding the work for the sprint where typically your brain will hurt upon conclusion of this day-long session!

Now let’s visit the Daily Stand-up sometimes known as the Daily Scrum. First, imagine that you MUST show up on time. This shows your commitment to schedule and respect for others' time. Then imagine you must share 'what you did yesterday' and 'what you are doing today', and “what are your impediments” and not just to the Scrum Master but to each other. Imagine, every day this is occurring! This starts to get you into a laser focus of the work and gets you motivated to get work accomplished.  

Finally imagine that at the end of each sprint, you must have working software per the end of sprint review (aka, demo). This means that within the end of a two-week sprint, you need to build the user story (aka, requirement) into a meaningful and viewable piece of functionality for validation by customers (and you cannot show customers junk, can you?). Remember that Agile takes an empirical approach where progress is based on actual observations and data to understand progress. 

To add to this, during the sprint each story you work on has to meet the rigorous “done criteria”. Done criteria is a commitment that (for example) each story that is worked on, must be checked out, incrementally designed, coded (following appropriate coding standards), possibly code-reviewed, built, unit tested, checked-in/promoted, merged, integration built, smoke tested, and system tested. Whew, is that enough discipline for you yet? All of this within a sprint so that you can have some tangible to show the customer so that they can validate if you are meeting customer needs.

Or course there are many more rigorous Agile practices. The discipline helps with the productivity and accountability to really become an empowered team. The discipline also ensures you remain hyper focused on the work. So next time someone says Agile is undisciplined and ad hoc, it is clear that they haven't done Agile as it was meant to be, and more importantly, explain to them the real rigors of Agile when you want to have observable progress.