Sustainable Pace

The teams that I have worked with, don't think and talk about Sustainable Pace enough. I believe that finding a team's sustainable pace is important part of its Agile journey. Let's talk about it a little bit.

Why is Sustainable Pace important? 

One of the reasons of having any software development process is to be able to predict the future. For various legitimate reasons, teams need to predict when a piece of software will roll out to production. For example - release dates help co-ordinate work between various teams - example Software, Hardware, Marketing, Sales etc.

A team working at a sustainable pace is predictable. Sustainable pace allows teams to have a certain amount of confidence when they make their commitments. 

How to achieve Sustainable Pace?

Team Driven Commitments:

One of the ways to achieve sustainable pace is to get your team to do the sprint commitments without any coercion. 

Team Leads / Managers should be involved in facilitating the sprint commitment process - by providing relevant data points, but should stay away from making commitments for the team. This isn't always easy to do especially for projects with extremely tight deadlines. However, my recommendation would be to err on the side of team driven commitments as much as possible.

As a Scrum Master, you can help the team hold itself accountable when the team makes the commitments freely without any coercion. 

Approach:

Usually, projects with tight deadlines come from some executive saying - "this is due yesterday if we are to be successful". If you are in a position where you accept such business critical challenges for your team, consider saying - "We will focus on delivering continuous value to the customer" instead of - "this system will be delivered on (insert a ridiculous deadline here)". 

Even if it is easily possible to have a system ready by the said date, it may not be something that the customer really wants when that day actually arrives. When you focus on delivering value, you don't have to wait for the entire system to be ready before letting the customer play with it. This means you will most probably deliver a working system (and possibly a few customer focused updates) sooner than the deadline. This gives your team some room to find a sustainable pace, which helps them be predictable and sets you up for success. 

All in all, I believe sustainable pace is an extremely important part of a team's Agile journey and should be a topic of conversation for the team and executives alike.

Rate this post!

☆

☆

☆

☆

☆

Go for small

One of the primary advantages of adopting Agile is that it allows you to change course quickly in order to react to changing market dynamics. This benefit can only be realized if you go for small. This is especially important if you are just starting out on adopting Agile / Scrum for your organization. Let's talk about benefits of going for small one by one concentrating on People, Process and Product.

People

Small Teams:

Value small team sizes over large team sizes. A small team involves less co-ordination between people. Research indicates a 4-7 person team size is ideal for Agile. Here is a link to Jeff Sutherland's article where he talks about keeping team size under 7.

Process

Short Sprint Cycle:

One of the principles behind the Agile manifesto states that Agile implementations should go for iteration sizes from a couple of weeks to a couple of months with more preference to shorter time scale. 

Shorter sprint cycles gives more opportunities for the product owner to prioritize what the team is actively working on. This helps deliver the primary advantage of Agile - adapt to changing customer needs.

Short Release Cycles:

With shorter release cycles, the team can deliver value to the customer quickly; allowing for better feedback loops. This enables the team to further add value to the product where it is most needed. 

Shorter release cycles allow for the Product Owner to quickly adapt the product to customer needs by doing feature driven releases. Shorter release cycles also give confidence to customers that the product is actively being worked on, and their concerns will be addressed soon.

I recently worked on a project where there was a crisis of confidence in the customers. The product was not doing well at all when we took over. With shorter sprint and release cycles, my team and I were able to turn the product sentiment in a matter of a few quick releases. 

Product

Small Curated Product Backlog Size:

I encourage product owners to curate / groom only small batches of the product backlog. In my experience, having the top 10-15 items in the product backlog prioritized correctly is enough for the Scrum process to work. 

Teams don't necessarily need clarity on what they are going to work on several years from today, they just need to know what is coming up next. This helps provide transparency - giving the team a good sense of what the minimum viable product looks like. When the team has this view, it can write code that can be refactored to suit the product needs better.

Small sprint backlog size:

If you are doing short sprint cycles, a small sprint backlog follows automatically. Instead of pushing the team to do more in each sprint, it is important to for Scrum Masters to let the team find a sustainable pace. This allows for a valuable velocity estimate, which makes the team predictable. 

Small Stories:

I am a big fan of breaking big problems down into smaller / simpler chunks. I have talked about Valuing Simplicity in another post. Here are some of the advantages of small story sizes:

1. Small and simple stories help the team understand the problem clearly. 
2. Small stories help the product owner and the team solve the correct problem. 
3. Small stories allow for producing working software at the end of the sprint. 
4. Small stories can help produce excellent looking burn down charts. If your team's burn down is a 'falling off a cliff', most probable cause is that the stories are too big.

Code - Small Classes / Small Methods:

All my experience as a Software Developer points to small classes and small methods being more maintainable over large ones. 

I have personally written code and worked on systems that adopt design patterns like Factory, Decorator, Strategy and Observer / Listener among others. All these patterns allow the code to be extendable and maintainable, while not being overly complicated. 

If you have a good design, it can allow you to write code in small classes and small methods. This usually makes the code easy to read and understand - thus making it more maintainable.

Small Test suites:

I have worked on a couple of projects where we had a large battery of small tests. Irrespective of whether they were manual or automated, small tests allowed the teams to pick and choose which tests to run for a particular test cycle. The team could pick and choose the right set of tests for 'Sprint Sanity' depending on the area of the code that was modified. 

Overall, I strongly recommend thinking about how to make things small for a good Agile implementation.

Rate this post!

☆

☆

☆

☆

☆

Fail early, Fail often, Fail better

I am a strong believer of not being afraid to fail. When you give appropriate time for analysis, failure teaches you a lot - it really drives home the message so you don't make the same mistakes over and over; and also helps you develop a thick skin. So, I love Agile / Scrum attitude of - fail early, fail often, fail better. Let's talk about it.

Fail Early:

Failing early on in the cycle is important because it gives you time to recover. Compare the cost of failing early to failing late in the game. 

Failing early teaches you important lessons early on. In this context some example of failure are - not meeting your sprint commitments, not having a demonstrable output at the end of the sprint, not having working software at the end of a sprint etc. 

As a Scrum Master, I consider it is my primary responsibility to let the team fail, especially early on. Along with allowing the team to fail, it is extremely important to keep notes about what the team did. I drive retrospective conversations with the team on the basis of these notes. In my Scrum Master capacity, I consider it important to work with the team to help them find the root cause of the failure. 5 Whys is a great way to get the the root cause. Rather than giving your team the answer, ask them the right questions, so they get to the answer on their own. This also helps build trust between you and the team (and may also give them the illusion that you know what you are doing!)

I loved the advice my mentor had given me. When coaching your child you want to let them make the small mistakes, but avoid the big ones. For example, you may want to let your child touch a hot stove so they never do it again, but you definitely want to stop them from running around on a road where they can have serious injury.

Fail Often:

As a child and even as an adult, I love playing computer games. One of the first games I played was - Dangerous Dave and Prince of Persia. When I think back, I don't remember the number of times I was killed in the game, but I remember when I finally beat the game. No matter how many times I failed, I never lost the commitment to beat the game. 

The way I think about it, failing often means trying often and not giving up. Think of the thing you are failing at as a game. If you are analyzing your failures often, it can help you get to success quicker. Trying out various strategies to 'beat the game' is the best way of finding success quickly. 

I remember one of the first projects that I led as a Scrum Master. In the release retrospective there was a comment made saying - each sprint was a cascading set of failures. The team was quick to point out however, that each time we failed, we learned valuable lessons and were better equipped for the next sprint. We started out by over-committing and under delivering; we had issues where we did not produce any working software for multiple sprints. However, in the end, we had a product that worked reasonably well, and was eventually deployed to millions of smartphones around the world. 

Fail Better:

I think there are at least 2 aspects of failing better. The first is to not only learn from your mistakes, but also from others' mistakes. The second is to not only learn from failures, but also learn from successes.

Failure does come at some cost, so it is important to you don't make each and every small mistake. It is important to keep an eye out for what other teams are doing to solve a problem and what they are experimenting on. I encourage other Scrum Masters to listen in on retrospectives of a few other teams - see what they tried, and whether something similar can be applied to your team. You can also see what they failed at, and try to analyze the reason for their failure. Don't wait to make each and every mistake. Read books / guides which helps you avoid some common mistakes. All of this should help you fail a little bit better at your next attempt.

If your team meets all its commitments, produces working software at the end of a sprint, completes a good demo - don't miss the lessons from that retrospective. Ask the team to analyze why they succeeded this particular time. If you and your team can articulate the reasons for your success, you can repeat it. If the success is accidental, you probably will not be able to repeat it. 

My recommendation to all Scrum Masters and teams is to not be afraid of failure. Take chances, experiment in whatever way you can, learn from your mistakes. In the face of failure, I encourage Scrum Masters not to hide it; not to provide justification to your team. Instead, ask the team to analyze the reason for the failure (or success) and learn from the experience. 

Rate this post!

☆

☆

☆

☆

☆

Demos

I think Demos are the most important Scrum meeting your team can do. If your team is starting out on Agile journey, Demos are a fantastic place to start it. 

What problems do demos solve?

Demos help keep everyone on the same page about what to expect from the product. A good sprint demo demonstrates the latest and greatest software that the entire team can sign off on. Ideally this is your team's potentially shippable increment. However it should be considered a huge positive if a team can produce working software at the end of the sprint, even if it is not 100% shippable i.e. has some bugs or stubs for functionality.

Demos help the product owner see their vision taking shape. Demos can provide insight into use cases that weren't previously thought about. As I mentioned in my post on Continuous Improvement, most products aren't used the way they were originally designed. Demos help the product owner quickly adapt the product to a changing landscape. This means that a good demo will prod the product owner to re-prioritize the backlog. This re-prioritization helps the team add the most value to the business case.

Whom to invite?

I'm a strong believer of demos being a public event. Anyone who has the correct privileges to your secret sauce should be invited to the demo. Consider a demo as your team's 15 seconds of fame in front of the high profile audience. 

At the minimum, the team, the Scrum Master and the Product Owner need to be a part of the demo. A couple of levels of the team's line management is an excellent addition as well. 

There may be a time when the team does not produce any demonstrable output in a sprint. In such cases, I strongly recommend continuing with (not cancelling) the demo. Rather than hiding the problem, it is best to put spotlight on it. Failure is the best teacher, I love the Agile mindset of - fail early, fail often, fail better.  

A non-demo is an excellent chance for the team to retrospect on why no demonstrable output was produced. As a Scrum Master, it may make sense for you to give a heads-up to executives attending the demo that the team doesn't really have anything to show. However, I encourage asking them to come to the meeting anyway and then make the team say there is nothing to demo. 

What & When to demo?

I want to reiterate what I said above - A good sprint demo demonstrates the latest and greatest software that the entire team can sign off on. This means both development and test portion of the software. 

I have seen teams demo their sprint increments after they are development complete, but not fully tested / with on-going verification. At best, this can make the demo Gods angry, at worst it can give Product Owner and the team a false sense of where the product actually is. The team can lose credibility if something is demonstrated, but not available for Product Owner to meaningfully use / deploy.

I encourage teams to demo known bugs in the code along with working increments. This allows for easy triage of defects. This also provides transparency about where the product is.

I was recently involved in development of a product where the Product Owner wasn't co-located with the team. The Product Owner was also very busy, managing multiple products at the same time. As a Scrum Master, I encouraged teams to make sound judgments about the product and highlight those decisions in the Demo. If the team was blocked on a UX asset, I encouraged the team to use the worst possible asset at that location, and demo it. I found that when we put spotlight on the problem, it got the right attention and quick resolution.

Nothing to demo, ever?

I know that some teams that work on the radio layer or in the database layer. I know of teams that believe there is nothing to demo in those layers. I disagree with that. 

I encourage thinking about creative ways of demonstrating the team's work. It is important for the Product Owner to understand how the product is taking shape. The demo doesn't necessarily have to be a video or a UI. For example - if you are working exclusively on the database layer, the demo can be a stored procedure that runs on sample data set producing some output. 

If you can't think of any way to directly demonstrate increments of functionality, I encourage working with the Product Owner to prioritize building a crude UI or some sort for the product. Although the UI may be completely throw-away code, it allows the team to show off their achievements.

Live vs Recorded demos

I like live demos. However, if a live demo is too much of a hassle to coordinate, I encourage showing videos of the latest increment. I hate the way my voice sounds on recordings, so I use Handbrake to cut the audio stream out. I use subtitles to explain what is going on in the video. Here is an example of a .srt subtitle file. 

Rate this post!

☆

☆

☆

☆

☆

Dealing with interrupts

One of the primary responsibilities of a Scrum Master to is deal with the interrupts. Given that at any moment your day can be thrown completely out of whack by interrupts from unknown sources, how do you keep sanity? Here are some thoughts on what Scrum Masters can do.

Apply Scrum knowledge:

If you understand the basics of Scrum, you know that each new work item flows through a backlog where it gets prioritized. The always team works on prioritized backlog of work items. The backlog is continuously groomed, so high priority items are always bubbled up to the top.

I recommend following the same practice for dealing with multiple interrupts. Maintain a to-do list. The list serves as your backlog. When an interrupt comes in, put it on your to-do list first. Next, prioritize your to-do list over again to understand where this latest interrupt fits in. Once the list is prioritized, you can work on the highest priority item in the list. This simple approach helped me stay calm and not get overwhelmed when there were ‘too many things going on’.

Before you leave for the day, consider prioritizing your to-do list again, in preparation for the next day.  That way you are prepared for the next day before you leave. This also helps make sure nothing falls through the cracks.

Take time to prepare:

The best way to make sure you get the most out of your time is to be prepared for meetings, especially the ones where the whole team is going to participate. If the Scrum Master isn’t prepared, it can, at best - waste everyone’s time, or at worst – cause confusion about what the team is supposed to accomplish and how. 

If you are a slave of your calendar, I recommend blocking time off. Consider blocking 15 mins before an important meeting. This gives you time to get organized, and think things through. You can use the time to anticipate the questions that will be asked, and have answers ready. 

If you are behind on your preparation, consider rescheduling the next meeting. Take that time to organize the rest of the meetings and try to get ahead. 

Coach:

I recommend maintaining a list of sources from where you see most of your interrupts. This list can help you take a step back and figure out why you are seeing the interrupts.

If there are standard set of activities that some people / teams can do on their own without your involvement, consider giving them that authority. Coach the interrupt sources to send their requests in a manner that works best with you. For example - if you see that all the interrupts from one particular source can wait until the end of that day, ask them to contact you at a time that works best with you.

If you find that the team's chain of command is the reason the team gets most interrupts, try to influence them - ask the question - is this really so important that you risk derailing the current sprint. Coach the people to put interrupts in the backlog and prioritize them with the help of the PO.

Evasive maneuvers:

If your team is at the end of a major release, it can be true that most of the work is in the form of handling incoming defects. 

Rather than treating each new defect as an interrupt, consider abandoning sprint cycles entirely. Consider working in Kanban mode, where incoming defects / tickets are available for the team to pick up and work on. Folks on the team can pick up defects they are most comfortable fixing. Scrum sprints can be resumed when it is time to start working on stories for the next release.

Rate this post!

☆

☆

☆

☆

☆