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.   

Six Tips to make Story Mapping more effective

Story Mapping is a practice that helps you experience a customer or user journey. You would first capture the end-to-end customer experience by asking what would a user do? This includes establish a backbone, steps, and options.  

The story mapping process promotes the team to think through elements of what the customer finds as valuable from a process perspective. It moves away thinking of functionality first and instead advocates thinking about the customer experience first.  Then you would use an incremental approach of building, inspecting, and adapting for the next increment. What might be some tips to help you more effective work through a story mapping session? 

Tip #1 – Craft your Persona (aka, customer)

Draft the persona that will be taking the customer or user journey.  Place the persona at the top or head of the story map. This provides empathy for the user and inspiration for those that are attempting to craft the journey through the eyes of the user (via the story mapping practice).  Learn more about personas at Personas - Getting to really know your Customer.  

Tip #2 – Everyone stands up around the story map

As simple as it sounds, have everyone working on the story map session stand-up and around the story map as they are creating it. This keeps everyone engaged on crafting the story map.  

Tip #3 – Everyone writes options

When it comes time to imagine options for each step along the customer journey, provide everyone with a post-it pack and marker.  Ensure everyone knows that they should put up the option ideas as they think of them.  This gets lots of options up quickly. This also reduces any single threaded thinking where only one person is doing the writing.  

Tip #4 – Promote lots of chatter during Affinity of options

After a number of options are written by a number of people, it is time to determine if there are affinities.  This is a good opportunity to promote conversation for understanding the customer journey together as each option is discussed.

Tip #5 – Ask owners of options if they are similar

If two options are similar, ask the owner of each to determine if they form an affinity.  Often times when there are similar options on post-its, those that didn’t write them speak up to discuss if they are indeed related. Instead, those that wrote them should determine the affinity (or not) as they would know better.  

Tip #6 – Use verb/noun

Use short verb/noun phrases to capture the backbones, steps, and activities (e.g. capture my address, view my order status, receive invoice). This helps with understanding the expected action for each step of the user journey. 

You can learn details of executing a story mapping session at Story Telling with Story Mapping.

Daily Stand-up Starter Kit

The Daily Stand-up can be one of the easiest or hardest Agile practice to do well.  When introducing the Daily Stand-up (aka, Daily Scrum or huddle), the initial goal is to get people to share their progress in a brief manner.  The benefit of the stand-up is that it promotes transparency of what everyone is doing where you communicate your progress.  It can also be a place to help you understand your impediments where you can collaborate on addressing the challenges. The focus should be on:

• What I did yesterday (or since the last time the team met)?
• What I will do today (or until the team meets again)?
• What impediments have I uncovered?  

The daily stand-up keeps the team aligned as to what everyone is doing. The "What I did yesterday" keeps everyone in-sync on what progress has been made.  The "What I will do today" helps you plan for your day and helps you commit to a day's worth of work.  The "impediments" are to share what is slowing you down or stopping you from making progress. Others can help you address the impediment once the stand-up is over. 

One challenge is when either the sharing of these three questions are too vague (e.g., yesterday I work on the same user story) or too detailed.  The key is speaking with detail yet brevity.  Enough details should be shared to ensure people understand what was worked on (e.g., yesterday I worked on opening the port to allow communications to occur) or what will be worked on (e.g., today I will work on setting up the asynchronous protocol and set a test packet through the port).  To keep from going too long, an initial helpful instruction is for each team member to limit their progress to about 1-2 minutes (assuming a team of 7 +/-).

Part of the initial adoption of the Daily Stand-up is simply getting people to go from one person to another and provide your daily progress. A challenge is when the team members expect the Scrum Master to tell you when your turn is.  Instead, consider a round-robin approach where you identify an order amongst the team to share progress. This can be alphabetical by name or around the virtual table by site. Another helpful technique in a distributed setting is ensuring each person introduces themselves with their name (e.g., I am Mario…) and ending with a code-word such as “Thank you” or “I’m done”, to let the next person know it is his or her turn.  This is particularly useful in a distributed team setting.

Another challenge is that too many team members direct their progress to the Scrum Master (or leader).  Instead, the team should communicate to each other and avoid directing their progress to the Scrum Master. This allows all teams members to know what each other is doing and promotes cross-team communication.

Once the team has a good handle on the daily stand-up, it can be helpful to evolve the process via the Retrospective. This helps the team reflect on the Daily Stand-up and determine if it is satisfying the needs of the team. For example, you may want to view the stories in the sprint backlog in a priority order and ask those that are working on the highest priority work to share their brief status. The benefit of this is that the team can more readily be aware if the highest priority work is getting done. Because the Agile mindset focuses us on working on the priority work first, this ensures that the progress sharing is focused on the highest priority work first and then so on. This also provides more visibility when the highest priority work are not getting done especially when others are getting done. It then can help you rally resources around the higher priority work that isn’t done.

The key is to adopt, reflect, and adapt. Good luck on your Daily Stand-up journey. How do you conduct your Daily Stand-up and have you evolved it over time? If so, in what ways did you evolve it?

Gaining first-hand insight into Employee progress within an Agile World

In the Agile world, some people find the performance review process a bit challenging and in some cases feel that it is unneeded.  Because we are moving from a more command-and-control environment to a team empowerment environment, a person acting in the manager role (e.g., functional manager, resource manager, etc) seems to have a harder time understanding what their employee is doing. Also, the manager needs to realize that when we move into an Agile world, discussion of performance should occur in a more collaborative manner with a focus on progress and learning.

Why does it appear harder? First, the employee is not (or should not be) taking work orders from the manager any longer and instead, the work should be driven from the product backlog (via the sprint backlog from sprint to sprint). Second, the manager actually does have less visibility into what the employee is doing since the employee should be 100% commited to their Agile Scrum team. So what should a reporting manager do? I’ve heard about conducting a 360 peer evaluation, but this is basically second-hand information. The question is, is there a way to gain first-hand information? What I recommend are the following ideas that can help a manager who has folks who report to him or her that are on an Agile (or Scrum) Team.

Let us start by considering the areas along the Agile process where a manager could gain direct insight into what the employee is doing. The two Scrum practices where a manager could listen into what their employee is doing is the Daily Stand-up and the End-of-Sprint Review.

• During the Daily Stand-up (aka, Daily Scrum), the manager can quietly listen into the progress that the Scrum team members communicate during this brief meeting. Before you do this, contact the ScrumMaster and verify that this Daily Stand-up is an open meeting that you may quietly attend. If you do so, ensure you tell your employees that you may be sitting in on the Daily stand-up. If you have employees on multiple Scrum teams, you may not have time to sit in on all Daily Stand-ups. Instead of sitting in on random Daily-standups, a tip is to attend the same Daily Stand-up for 5 consecutive days so you get an idea of the work done by your employee for a weekly period (for continuity and consistency). Since the Daily Stand-up focuses on what the team member did yesterday, what they are planning to do today, and their risks, you will have some idea of how story and tasks are connected to the work of the employee and how well they are completing the work.

• During the End-of-Sprint Review, you can potentially understand the employee’s progress by seeing what they demo (assuming the team members conduct the demo and not the Product Owner). If you learn that your employee is demonstrating work software during the sprint review, then you can quietly listen in to see what the employee built and how it works. Before you do this, contact the Product Owner and ScrumMaster to verify that you may quietly attend the meeting. If you do so, ensure you tell your employee that you may be sitting in on the End-of-Sprint Review for transparency.

You may notice that I emphasize “quietly” a couple of times. The key is that the Agile practices that I am talking about are not meant for the manager per se but for the purposes of building customer value and making progress through the project. The Daily Stand-up is specifically meant for the team members to communicate to each other on their progress. The End-of-Sprint Review is meant to gain valuable customer and Product Owner feedback so that we can ensure we are building the right product for our customers.

Next let us discuss other opportunities to gain employee insight  I suggest using 1:1s with employees to collaboratively discuss challenges, progress and learning needs but evolving it to become a continuous performance review.  These should be a low-key sessions that replaces the "big-bang" performance review.  During the continuous 1:1s, there should be an effort from both management and employee to be transparent and this should avoid any surprises when ratings or compensation matters are discussed. Ultimately, I would like to see the performance review process move away from the stogy and often negative intrustive event and evolve into a continous and collaborative discussion on progress and employee needs.  

What do you think of these ideas? Are there other ideas you have seen work successfully where a reporting manager can gain first-hand insight into their direct reports without obstructing the progress of an Agile project or the employee themselves?

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.