They both emphasize the importance of TESTING. Not only does Agile emphasize testing, but one of the key differentiators between Agile and Waterfall is that Agile promotes continuous testing while Waterfall leaves testing for the end. In other words, the earlier you test, the better. Early testing allows for de-risking. When issues are caught early on, they can be addressed before they become insurmountable. In the context of COVID-19, early testing leads to identification of
Sounds crazy doesn't it?
Afterall, the retrospective influences change which we all know is highly valuable.
In an ideal world, a retrospective would include lots of great ideas for improvement that were actually actioned.
Unfortunately, that doesn't always happen.
Some teams get stuck and struggle to come up with new exciting improvement items. Other teams have great ideas but they never get around to actually implementing them.
As a Scrum Master, you could continue to
It does seem to lack something quite critical.
It doesn't address ACCOUNTABILITY.
Most Agile teams have no issues coming up with SMART goals. The problem lies in actual carrying it out.
Many times Agile teams start off their sprint retrospective by reviewing the SMART goals they agreed to at the last retrospective, only to discover that none of them were actually actioned.
What if the team identified consequences for each SMART goal?
Instead of a shaming consequence, the te
At first, the answer may seem obvious.
You may be tempted to assume that the teams are anti-Agile and they’re never going to buy into Agile.
This could be the case, but you may want to consider other explanations.
Some teams are convinced that pair programming and test driven development will slow them down.
For instance, pair programming can be viewed as inefficient (especially when you take it one step further towards mob programming).
The truth is, pair/mob programming
Let’s say you have an Agile team that is composed of team members with only I-shaped skills. Doesn’t sound good, does it?
But collectively these I-shaped individuals have the all the skills necessary to deliver their stories. Maybe they do a great job of handing off work to one another. Starting to sound better?
In this situation, it seems like T-shaped skills are more of a nice-to-have and the team is just fine with their I-shaped skills.
Here are a few questions to ponder
"Come yourself or send no one."
This quote comes from W. Edwards Deming.
Deming was a management consultant who was sending a message to an executive.
Essentially, he was trying to convey that some things need to be experienced and cannot simply be delegated.
Some leaders may cringe at the thought of attending a course, especially if they're expected to participate when discussing a topic they have little knowledge of.
But Agile training doesn't have to be in the form of a
Is there a difference and if so, what is the difference?
All 3 are important and there is definitely overlap.
Consulting typically refers to the relationship between a consultant and a client.
The consultant provides experience, training, and expertise in a particular area. Professional Coaching typically refers to the relationship between a coach and a coachee.
The focus is on developing the coachee. The coach doesn't require background information on the coachee's area
March 2017 we shared a blog about adding “Admit when you’re wrong” to your working agreement.
2.5 years later, we have another one for you.
It is by no means revolutionary and some of you probably already have it (either partially or wholly) as part of your working agreement. “Ask for help after 30 minutes”.
Feel free to replace 30 with whatever makes sense in your context.
So why is this important?
It’s important because it makes it ok to ask for help. Many times we hesi
(This applies to Scrum Masters and Product Owners)
You've just completed Sprint Planning, the team has already returned to their work area and then it hits you. Oh no, I forgot to do...
Re-assembling the team and trying to regain the momentum you've just lost doesn't seem like a wise choice. So you accept your mistake and try to make accommodations throughout the Sprint but it never works well. Then you get to your next Sprint Planning and once again you forget to addres
It's always tempting to aim for efficiency. Why wouldn't you? It doesn't make sense for people to be idle when the could be busy. Maybe this idea came from Microsoft Project where Project Managers would struggle for hours (or days) to ensure each resource on their project was 100% utilized, all the time.
In Agile, efficiency is a fallacy.
Look at it this way. What we're after is working software. Completed stories get us to working software. And even though most people wo
You already know the answer. There is no best tool. The best tool is the one that works best for you. That doesn’t mean your organization is a special snowflake, it just means your organization has its own specific context and that’s ok. So how do you go about choosing a tool? The good news is that it’s actually not that complicated. You need to start out by doing some homework. Investigate some options that seem as if they may work for your context. Focus on your current nee
Not many people have achieved 6 Championships so it's probably not easy. It likely requires hard work, dedication, attention to detail, sacrifice, etc.
While software development is not rewarded with Superbowl Championships, it too can reach a heightened sense of accomplishment. This accomplishment also requires hard work, dedication, attention to detail, sacrifice, etc.
It is common for many Agile teams to employ continuous improvement. Sometimes, iteration retrospective
Whether or not a Scrum Master has a technical background, there are going to be instances when the Scrum Master struggles to understand the technical complications faced by the team. It simply isn't possible to understand all the inner workings of the team without being in the trenches with the team. That's why some teams have one of the developers also function as the Scrum Master. However, that situation isn't ideal because the individual will constantly be pulled in both d
Let's discuss the situation where the team did not create the defect in the first place. Maybe the team inherited a system that was full of technical debt. The answer here is easy, the team should get story points for that.
But if the team is responsible for the defect? If they can't apply any story points for the fix then how do they identify the work and plan accordingly? On the flip side, if they are apply story points then aren't they receiving the points twice?
As you progress through your Agile journey you may start to notice that you (consciously or unconsciously) look for ways to help fellow Agilists. For instance, imagine you’re at an Agile conference and meet someone who is new to Agile and is faced with many challenges. You listen to their struggles and coach them on identifying the root cause as well as recognizing some potential solutions. A few weeks later you reach out to this person (perhaps over email) to assess the outc
Multi Team Retrospectives can be very different than individual team retrospectives. Simply put, encompassing more people introduces challenges.
Various Agile methodologies that focus on scaling deem it necessary to conduct multi team retrospectives. For example, SAFe prescribes that an I&A (Inspect & Adapt) workshop is run at the end of every PI (Program Increment) which can work out to approximately every 3 months.
It can be a daunting task to hear the voice of over 100
When splitting user stories it can be a daunting task to get Agile teams to conform to INVEST.
At some point, teams either struggle to abide by INVEST or they've hit the ceiling and are unsure of what to do next.
In either case, SPIDR may be the next step.
The concept comes from Mike Cohn (www.mountaingoatsoftware.com). The idea is not to necessarily r
Agile teams aren't supposed to have a team lead. After all, Scrum doesn't have a role for that. Besides, Agile teams are supposed to have T-shaped skills so there is no need for a team lead.
The reality is that most teams have at least one team member that has a senior presence. Maybe this person has the most overall experience or maybe they've been with the organization the longest. Regardless, this person often becomes the goto resource whenever the
Here it comes, the typical consultant response "it depends". Agile conferences can be very beneficial but what it really comes down to is ROI. Does the benefit really outweigh the cost and is there really any way of determining that? Let's come back to that.
The main Agile conference is hosted by the Agile Alliance which occurred last week in Orlando (Agile 2017). There are typically over 2000 attendees.
Scrum Gathering (hosted by the Scrum Alliance) hosts conferences aroun