Mike Cohn's Blog at Mountain Goat Software.+Add.Feed Info1000FOLLOWERS
Learn agile and Scrum tips and techniques from expert ScrumMaster, educator and author Mike Cohn of Mountain Goat Software.Mike Cohn provides certified scrummaster training and agile training in order to build extremely high performance development organizations.
I've been in a few arguments lately. Each argument was unique but there was a common thread running through each: whether the whole team should be invited to attend certain scrum meetings.
I have a firm belief that agile teams do best when team members feel and act as one team:
Any feelings of "us vs. them" go away
Finger-pointing and CYA activities are eliminated.
Team members put team goals ahead of personal agendas
Team members become more willing to compromise to gain consensus if doing so helps the team achieve its overall goals
Agile teams should foster a whole-team mindset. For example, an agile team should not feel as though it has a programming subteam and a testing subteam. When a team acts as one team, the idea of functional subteams fades away. By the same token, agile teams shouldn’t feel as though they need to hide anything from one another, and that includes the ScrumMaster and the product owner. Teams that act as one team include every role in every sprint meeting: from planning and daily scrums to reviews and retrospectives.
The arguments I found myself in were with people who didn’t value this one-team or whole-team mindset as much as I do. I suspect that’s because they don’t realize how crucial a whole-team mindset is to succeeding with agile.
Team Member Identity
Let me back up for a moment. When I say that agile teams should not have functional subteams like a programming team and a testing team, I'm not saying that everyone should become a generalist. That's a common myth in agile. Rather, I'm saying that people on agile teams should get most of their identity from membership on the team rather than association with others with the same skills.
To see what I mean, think of a sports team. The sport doesn't matter, but I'll use baseball. A pitcher on the New York Yankees should think of himself as a Yankee first and a pitcher second.
Sure, this pitcher may occasionally get together with pitchers from other teams. And when those pitchers come together, they swap stories that only pitchers can relate to--"Man, once I turned 30, I really started to need those ice packs on my shoulder any time I threw more than 80 pitches in a game."
But even so, our pitcher should get most of his identity as a Yankee rather than as a pitcher.
Special Rules Inhibit Whole-Team Thinking
To foster a whole-team mindset, it is important to remove any special rules created by or imposed on the team that apply to only a subset of the team. The baseball team’s morale would suffer if there were a jug of Gatorade in the locker room with a sign saying “pitchers only.” And agile teams can’t thrive when there’s a metaphorical sign on the meeting door that says “Development Team Only.”
But that’s exactly what happens on many teams when it comes to two specific agile meetings: the daily scrum and the sprint retrospective.
The arguments I mentioned earlier centered largely around someone telling me the product owner (and sometimes even the Scrum Master) should not participate in these meetings.
This is wrong, wrong, wrong.
Excluding the Product Owner from Meetings
Any rule a team establishes saying, "This type of person should not participate because of their role" works entirely against the goal of creating a whole-team mindset.
To see how wrong excluding a product owner from these meetings is just because the person is a product owner, imagine a rule that said testers cannot attend. Or left-handed team members can't attend.
If those rules sound wrong then so is a rule that says product owners or Scrum masters can’t attend.
What If Your Product Owner Is a Jerk?
Sometimes I’m told that a team doesn’t want the product owner to participate in a retrospective or daily scrum because the product owner is a jerk. Well, the solution then is to do the same thing the team would do if a programmer were a jerk: Address the behavior of that person.
Don’t make a rule that says a certain role can’t attend.
Yes, some product owners are jerks. But so are some programmers, testers, tech writers, analysts, Scrum Masters, DBAs, and so on.
But we don’t change what is right just because some teams have product owners who abuse a retrospective as a way, for example, to harangue the team over why its velocity hasn’t doubled over the past month.
Agile Teams Need a Whole-Team Mindset
Establishing a whole-team mindset is an important goal for any team that wants to perform at the highest possible level. This doesn’t mean people are interchangeable or that everyone learns how to do everyone else’s job.
But it does mean everyone on the team thinks first about how to achieve the team’s goals rather than each person’s individual goals.
Tommy Lasorda, long-time manager of the Los Angeles Dodgers’ baseball team knew this. He said his job was to get players working for the team name on the front of their shirts rather than their own names on the back. This is the essence of a whole-team mindset in which everyone on the team feels they are in it together.
As agile coaches, Scrum Masters, and other agile leaders, our mission is to help our teams achieve this whole-team mindset. To do that, we need to discourage any behavior that fosters us-them thinking, such as excluding someone from a meeting merely because of their role.
What Do You Think?
Has your team established a whole-team mindset? How did it happen? Has that improved how team members work together? Please share your thoughts in the comments below.
While cleaning my home office recently, I decided I would listen to all of the Beatles' albums. I'd start with "Please, Please Me" from 1963 and work my way to 1970's "Let It Be." My goal was to finish cleaning before the Beatles ended with "Get Back." In doing so, I realized that much of what I know about agile, I learned from the Beatles. In particular, here are the top ten things I learned from Beatles songs.
10. Eight Days a Week
In this song, John Lennon sings to a girl that he "ain't got nothing but love, Babe, eight days a week." Of course, there aren't eight days in a week, so John is really singing about overtime. And from it, I learned that while overtime is best avoided in most cases, it may occasionally be needed when a regular work week is not enough to show I care.
9. Don't Let Me Down
In this song, John assumes the persona of a user or customer of an agile product. And he reminds us that our goal is “don’t let me down.” To ensure that we delight our customers, our agile team must remain focused on delivering value.
8. Come Together
One of the best ways for a team to deliver value to its customers and users is to collaborate with them. This led the Beatles to encourage teams and their stakeholders to “come together” to build the best product possible. In particular, Lennon condemned developers who ignore user's needs and just build what they want. He called such developers "jokers" and sang, "Got to be a joker, he just do what he please." The best agile teams do not have jokers who just build what they please.
7. Tomorrow Never Knows
The popular agile phrase, "You ain't gonna need it" is often simplified to YAGNI. This refers to the difficulty of designing for more than the immediate future. Before we had YAGNI, we had John Lennon warning us that "tomorrow never knows," meaning we should design only for the current day.
6. We Can Work it Out
This collaboration between Lennon and Paul McCartney suggests to teams and stakeholders that when it comes to solving problems, “we can work it out” when we work together.
The line, "Do I have to keep on talking till I can't go on?" reminds teams that code settles arguments. Build it, release it and see what customers think rather than talking until you can't go on.
By cautioning teams that "only time will tell if I am right or I am wrong," Lennon and McCartney urge teams to create a minimum viable product to find out how reality matches up against expectations.
5. I Am the Walrus
In this song, Lennon was singing about what is commonly known as eating your own dog food. The idea here is that team members should, if at all possible, use the product they are building. This means that developers are not just developers but are also users. Or, as Lennon sang, "I am he as you are he as you are me and we are all together."
4. A Day in the Life
In this poignant tune, the Beatles caution that only by watching a user as he “woke up, fell out of bed, and dragged a comb across his head” could agile team members truly understand their users. To develop products that fully meet their users’ needs, agile teams need to get out of their offices and to go study a day in the life of their users.
3. With a Little Help from My Friends
The daily standup is one of the most common practices among agile teams. During these meetings, team members are encouraged to present any impediments they are facing and to solicit help from others on the team. Those working on an agile team quickly learn they can “get by with a little help from [their] friends.”
2. Can't Buy Me Love
In the Beatles' fourth number-one hit, Paul McCartney reminded agile teams that there are some things money can't buy. Many fans heard McCartney sing, "I don't care too much for money, money can't buy me love," and thought he was referring to the love of a woman.
Agile teams understood him, however, to be singing about the love of customers for the team's product. McCartney was admonishing teams to produce high quality software. He knew that even one low quality release would cause customers to no longer love a product and that no amount of money could be thrown at poor quality to buy the customers' love.
1. Getting Better
Even the best of agile teams can get better. The pursuit of continuous improvement is common to all of the best agile teams. McCartney knew this and wrote this song to encourage teams to always be “getting better, a little better all the time.”
There you have it--the top ten things I've learned from Beatles songs.
No wonder they were known as the Fab Four. Beyond the great music and great lyrics, I bet they could have developed some amazing products had they set their minds to it.
What Do You Think?
What do you think? Are there Beatles songs I missed? Are there songs by any other artists that hold agile lessons? Please share your thoughts in the comments section below.
I'm going to ask you to consider being a professional. But, before I do and before you can answer the question I posed, I need to make sure you are fully aware of what I mean when I talk about being a professional.
For me, the difference is simple: A professional always does everything necessary to complete a job. An amateur sometimes chooses only the fun parts.
An Example of the Difference
An amateur golfer, for example, may thrill at the crack of hitting a 300-yard drive but hate putting. And so that amateur may frequently choose to pick up the ball once it's "close enough" to the hole.
A professional golfer could never do this. The professional may still prefer hitting the long drives over making intricate putts. But the professional knows he needs to do both parts of the job.
Professionals and Amateurs in Software Development
The difference between professionals and amateurs shows up on software teams in the team members who only do the portions of the job they like.
This can happen on any role on a project. It could be the tester who doesn't enjoy talking to customers ("Analysts do that."). Or it could be the product owner who only wants to think about strategic, big new features rather than going into the nitty gritty of the implementation.
For any job there are good parts and the bad parts. The professionals do the full job, not just the fun parts.
The Programmer as an Amateur
One of the more common amateurs I've been encountering lately are programmers who will only code exactly what they are told. "I gave you precisely what you asked for," they'll say. And there's nothing wrong with that reply in some cases. But it's not appropriate all the time.
The professional programmer brings his or her full brain, experience and creativity to the job. When asked to develop a feature, the professional thinks about it: Are there gaps in what was asked for? Are there alternative and better solutions? Will it lead to later problems? And then the professional has conversations with the product owner based on the answers to these questions to determine exactly what the feature will look like when implemented.
In contrast, the amateur says, "OK, I'll give you exactly what you asked for." That's easier. The amateur programmer doesn't have to think about the work beyond the specification. Just code what was asked for.
Similarly, an amateur programmer says, "I just write code; I don't test." Oh, that programmer will probably do a bit of testing on his or her own code. But when the team nears the end of a sprint and could use a little help testing for a day, an amateur programmer is likely to just code ahead on the next features rather than doing the more helpful--but to some, less desirable--work of helping test.
Not Doing the Full Job Is a Luxury
Not doing all parts of a job is a luxury only afforded to amateurs. An amateur can hit the glamourous, powerful 300-yard drive and then pick up the ball on the green without putting. The amateur can write code and not be concerned that no users are benefitting from that code until a tester catches up and tests it weeks later.
Professionals don't do that.
A professional knows that ultimately his job is to do whatever it takes to help the team. Often that means taking the time to have conversations about the tasks at hand or taking on some of the less desirable parts of the work.
A Team of Amateurs Makes Software Development Difficult
It’s hard to be agile with a team composed largely of amateurs. Amateurs tend to take the distinctly non-agile attitude of “that isn’t my job” and “I only do this type of work.”
Amateurs are more likely to be highly specialized and to feel entitled to work solely within their one specialization. While this can lead to people in that role feeling more efficient, it will reduce the overall throughput of the team. (That is, overall team velocity will suffer even though one role may feel more efficient.)
For many reasons, a team of amateurs makes software development more difficult.
What Do You Think?
In the comments section below, please share your thoughts.
Are you an amateur or a professional? How do you stay motivated to always do the less glamorous parts of your job? How have you convinced amateurs to become professionals?
Last year I began a new year-end tradition intended to help you catch up on any of my blogs you might have missed: a countdown of my most popular posts. So without further ado, here is my second annual list: My Top 11 Posts of 2017! (If you’re curious about how we arrived at this list, more details about our algorithm are included in last year’s post.)
It’s not hard to imagine how, as the team and organization get better and better at Scrum, the ScrumMaster’s job becomes easier and easier. But does the effort ever go all the way to zero? Find out in this post.
Being a ScrumMaster can be tough. This year’s second most popular blog post details 3 of the most common errors ScrumMasters make and some ways to recover from them.
And now it’s time to reveal the most popular blog post of 2017. Interestingly, it is similar in theme to last year’s number one. Last year’s post had to do with running a sprint retrospective. This year’s number one is focused on the sprint review:
While the demo itself is the most prominent part of a sprint review, an effective review is much more than just a demo. Here is a solid agenda that you can use to generate quality feedback in just about any sprint review.
What About You?
Are any of your favorites missing from the Top 11? Is there something you’d like to know more about in the coming year that you can’t find on the site? Please share your thoughts using the comments below.
A central tenet of agile is to avoid working in phases. On an agile project, There is no analysis phase followed by a design phase followed by a coding phase and ultimately a testing phase. Instead work overlaps in what is commonly called concurrent engineering.
For example, as a user interface is being designed by one team member, a second team member begins coding that functionality. To avoid rework, the programmer will start by working on parts of that functionality that appear unlikely to be affected by pending design work.
Teams Must Become Comfortable with Uncertainty
For concurrent engineering to work, the team must become comfortable with uncertainty. For coding to begin before design is finished, the team needs to become willing to work around open issues.
Yes, before a product backlog item can be finished, those open issues will need to be decided and actions taken. But work can begin on a typical product backlog item without all uncertainty removed.
As an example, suppose a team is working on a user story of “As a user, I am logged out after n minutes of inactivity.” Before that story can be considered complete, someone is going to need to decide how long n is--30 minutes? 12 hours? But, a programmer could absolutely begin work on that story without the answer.
An Answer Is Needed but It’s Not Needed Yet
The key thing for team members to understand is that while they eventually need an answer, they do not always need the answer before starting. Some things can be resolved during the sprint, such as the amount of time before a user is timed out due to inactivity.
Once team members fully grasp that some answers can be learned during the sprint, they become much more willing to live with the uncertainty that is needed to practice the overlapping work of concurrent engineering.
Team Members Start Separately But Finish Together
It doesn’t so much matter when team members start work on a product backlog item. What matters is that all should finish together, or as close to it as practical. In a ten-day sprint, a programmer may start work on a user story on day six and a tester on day eight. Their goal is then to finish together on day ten.
I like to equate this to running a race around a 400-meter track as in the Olympics. Because outside lanes are progressively longer, runners in those lanes begin the race further ahead physically on the track. This ensures that each person runs the same distance and that they finish at the same place, making it possible to judge the winner.
Your Designer Is Probably in an Outside Track
An agile team can think of its analyst and designer being in the outside tracks. They need a bit of a head start. (Yes, I know in a real running race everyone starts running at the same time. But the starting line for the outside track is “ahead” of the inside track.)
The analyst needs to identify what’s even being built. And the designer may need to provide wireframes, mockups or similar starting points to the team if the team is to have any chance to build a test the feature within a sprint.
When we think of the analyst and designer on the outside tracks, we can see how their head start allows everyone on a team to reach the finish line at the same time.
How Far Ahead Does Anyone Start?
No one should start any further ahead than necessary. Remember that the goal is to overlap work in concurrent engineering.
I am not saying that a designer is working apart from the team or working three sprints ahead. The designer is absolutely on the team and the designer’s primary responsibility is helping the team in any way possible to finish the committed work of the current sprint. But even doing that, most designers will likely have some time to look ahead at what is coming next.
This is no different than what a good product owner does. A team is in trouble if the product owner is buried by the work of the current sprint, such that the team arrives at the next planning meeting without the product owner having given any thought to what to work on next.
Certain roles on an agile team need to be looking somewhat ahead. They should look ahead only as far as necessary, but some peering forward by product owners, analysts, or designers can be very helpful.
The goal should be to start the sprint with just enough information that the team can barely finish each product backlog item. Team members should feel that if they had to resolve even one more open issue during the sprint, they could not have finished that product backlog item.
How Do You Do It?
How does your team achieve the goal of overlapping work through concurrent engineering? Please share your thoughts in the comments section below.
One of the most frequent criticisms I hear of Scrum when teaching Certified Scrum Master courses is “Scrum teams have too many meetings.”
With daily scrums, sprint planning meetings, sprint reviews, retrospectives and possibly even product backlog refinement meetings, it’s easy to understand the basis for this concern.
But let’s see if it’s true.
Here’s an experiment I’d like you to try, especially if you think Scrum has too many meetings.
Pick a random number from 5-10. Then think back to when your team first began working in an agile way or perhaps when they first started to get good at it.
Go to that month on your work calendar, whether in Outlook, Google, Apple Calendar or some other program. Now, remember the random number you picked in the previous paragraph? Back up the number of months that corresponds to your random number.
So, for example, suppose your team started to get the hang of agile in October and you picked 5. In that case you’d back up five months from October and look at May.
Next, look through that month, making note of all meetings you had during the month. If you’re like those I’ve had do this before, you will likely find that you had as many or more meetings before becoming agile--they were just different meetings.
You probably had occasional meetings with stakeholders. You had the weekly update with your boss. You might have been on a couple of task forces. Then there were design reviews—whether design, technical, database, or other. You might have had a weekly status meeting. Perhaps there were code inspections or reviews. There were one-off design discussions at the whiteboard. Add a couple of conference calls. And realize you probably had some meetings that were scheduled but never made it onto your calendar so you don’t see them now.
It is entirely possible you had more meetings pre-agile than after.
This definitely won’t be true for everyone. But, for about half the people I’ve done this with in-person, they had more meetings before starting Scrum. Those most likely to have had more meetings pre-agile are team members who need to coordinate their work with others.
Why We Feel Like Scrum Has too Many Meetings
So, why is the feeling that Scrum has too many meetings so prevalent?
It’s because the meetings have names. When we give something a name, it can become a target for criticism. People will complain about “those darn sprint planning meetings” and that “pesky daily scrum.” (They may use more colorful language.)
Many of the meetings on your calendar pre-Scrum did not have names and did not recur regularly. They were more like “Discuss design with Mary,” “Code review with Ashish,” or “Janet - test cases.”
You may have had many design discussion meetings, but they weren’t all with Mary and definitely didn’t have the official name of “Discuss design with Mary.”
When a meeting recurs regularly and is named, it becomes far easier to criticize.
Scrum Done Well Feels Helpful Rather than Burdensome
Scrum’s meetings definitely have the potential to become burdensome. And many teams do spend too long in meetings. For every team I advise to spend more time in a given meeting, I must tell 20 or 30 teams to spent less time. (Overdoing sprint planning and product backlog refinement are particularly common.)
But when done well, Scrum should be a help rather than a hindrance in developing products quickly. Each meeting should feel like it was held
at the right time
for the right length
with the right people
and at the right level of detail
The Scrum framework is setup to make this possible. If a team doesn’t feel this way about its meetings, the Scrum Master should look carefully at how each is being conducted.
In all likelihood, the meetings should continue but be made more efficient rather than abandoned.
There will always be some team members who criticize any meeting. One meeting a decade is one too many for certain people. But, when meetings are conducted well, many Scrum team members will find they spend less time in meetings than before adopting Scrum.
Since it’s Thanksgiving week here in the United States, I took some time out of my schedule to reflect on some lessons I’m very thankful to have learned through my career. While these lessons are not unique to Scrum or even agile, each has been a big part of my success with agile.
For each lesson, I’ll share what I learned and tell a brief story of how I learned it. In doing so, I'm hoping to help you avoid the mistakes I made before these lessons became second nature to me.
When There Are Two Ways to Do Something, Do It the Right Way
One of my first professional programming jobs was working in the litigation support division of one of the big consulting companies. Much of our work was driven by sudden demands from the opposition’s attorneys. We developed software that helped our attorneys comply with those demands.
This often meant writing programs that would be used once, but that were needed within 24-48 hours and needed to be perfect. The boss who had hired me was a Unix shell scripting wiz and he’d managed much of the development with no concern for reuse. Every program was 100 percent new. He didn’t even develop new programs by starting with old ones and extending or generalizing them.
This wasn’t a bad decision necessarily. It was often the fastest way to comply with the attorney’s needs. But over the longer term, I knew we could respond even more quickly if we started to assemble a library of common code. But would it be worth it? Did we even have the time to slow down 10 percent today to be 50 percent faster later?
Soon after joining the project, my boss was promoted and began working elsewhere on the same overall project. And I had a decision to make: continue as I had for the first two weeks on the project or focus on developing a reusable library.
I remember very clearly being in the office one Saturday with the two other programmers on the project, Sean and David. We discussed whether we should start building a reusable library or whether the urgency of deadlines was such that we had to stay focused on just getting things done. It turned out to be an easy decision. We agreed to start assembling the library every time we worked on something.
It was one of the best decisions I’ve ever been involved in making. The payback from that change came much faster than I ever expected because just a few months later we were faced with challenges we could not have met if we hadn’t chosen reusability.
And so, the first thing I’m thankful for is that I learned the lesson:
When there are two ways to do something, do it the right way
The right way may seem more time-consuming or more difficult but in my experience, doing it the right way is always worth it.
Life Is Too Short to Work With People You Don’t Like and Respect
One of the last jobs I had before Mountain Goat Software involved working in a highly dysfunctional culture. That culture was in place long before I got there, and, unfortunately, I didn’t detect it during the interviews. I think perhaps I was so excited by the cool software I’d be involved in that I pushed the culture out of my mind and took the job.
It was horrible. I was one of five VPs reporting to our CEO. She decided one day that people needed to work more hours. Oh not because of some urgent deadline, just because. She assigned each of us VPs a different night of the week and we were expected to stay in the office until 7:00 P.M. so that employees would see us staying late. And that would motivate them to do so as well.
If you know me, you’ll know I’m a complete workaholic because I love what I do. But I also have a mental screw loose. No matter how big the project is, I have a feeling that if we all stay late tonight--pull an all-nighter--we can finish the project by tomorrow. What? Linux rewritten? Let’s work through the night and finish it! The rational part of me knows it can’t happen, but it doesn’t stop me sometimes from trying.
My point is, I work long hours. But I work them on my terms. I like finishing my day at a reasonable time--perhaps 5:00 P.M. and then exercising for a bit before having dinner with my family. And then I’ll work more--often much more--later in the night.
But tell me I must stay until 7:00 P.M. and the anti-establishment part of me kicks in, and I want to rebel. Even though I was often in the office until 7:00, or later, the boss telling me I had to do it pissed me off. And I didn’t like the message it was sending others. I would literally wait until the CEO left (normally no later than 5:15) and then I’d go tell anyone still in the office to go home.
The CEO wasn’t the only dysfunctional person in that company. There were many. There was the architect who wiretapped the boardroom so he could listen in on meetings. There was the developer who claimed to be allergic to our building and went out on medical leave two days after starting. I could go on.
One day our CEO announced some new ludicrous policy--I don’t even remember the specifics. I was in another VP’s office when he read her email to me. We both looked at one another and came to the same conclusion:
Life is too short to work with people you don’t like and respect.
We both decided we would never again work with people we didn’t like and respect. It just isn’t worth it. Within a month, we’d both left that company, and we haven’t looked back. Today we each run successful agile coaching and training businesses. We’ve never been happier.
If you find yourself working with people you don’t like and respect, work to get yourself out of that situation. You’ll be much happier.
Removing Someone from the Team Never Hurts as Much as You Think It Will
Firing someone is never easy, even when it’s for just cause. I had to fire one system engineer who was stealing hardware from our company and selling it online. The police had caught him fencing expensive hardware that he’d purchased for the company, was missing from our data center, and matched serial numbers from the vendors.
I had no doubt about his guilt. His trial was pending. Yet my boss was reluctant to support me in the decision that he needed to go. My boss’s reasoning was, “Do you know what they do to pretty boys like him in prison?” Yes, he really said that to me and hesitated over doing the right thing because he’d seen too many movies. Still this guy had to go, yet it was hard to fire even someone like this. It’s always hard to fire someone.
Sometimes firing someone is hard because the team has become highly dependent on that person as the only one who can do a certain job. And you’re worried that if you fire that person, the team will be slowed dramatically.
My experience is that those fears are way overblown. In a couple of cases I had to fire someone who was the only person who knew how to do some vital thing or was the only person familiar with some very crucial code. But letting those individuals go and watching their teams quickly learn whatever needed to be learned taught me that.
Removing someone from the team never hurts as much as you think it will.
Teams are amazingly resilient. If there is something specific to be learned, they will dig in and learn it.
Also, by the time a manager realizes someone needs to be fired, gathers the energy to do it, and gets the human resources group on board with the idea, the team has thought the person should be fired for months. Teams typically realize these things much faster than managers.
Letting someone go should never be done without significant deliberation. But it’s never as painful as you fear it might be.
The Smartest Person in the Room Is Not Smarter than the Whole Room
A lot of leaders work their way up their careers by being very good at what they do, having that be noticed by someone senior, and then getting promoted. And so many leaders and managers have for at least part of their careers been the smartest person in the room.
And when a decision needed to be made, they would state their opinion, defend it, win the argument over how to do things, and very often lead the team to the right decision. But no matter how smart the smartest person in the room is, it is highly unlikely that the smartest person is smarter than the collective wisdom of the entire team.
I learned this lesson early on in my career. I was a software team leader, which meant I had perhaps 3–5 more years of experience than the average person on my team. And, I probably was the smartest person the room when we were debating design decisions and such.
I remember one debate in which one of the more junior team members changed his opinion without much argument at all. I asked him why and he said that because I was the team lead, I must know best. And that scared me. Even when it might have been true in some cases, I never wanted my teammates backing off their positions and agreeing with mine just because of some job title I had.
Since then I’ve hated job titles. They are how we present ourselves to the outside world. Within a company, job titles should be meaningless.
I am positive that this junior developer did sometimes have better ideas than I did. And what a shame it would have been if he’d been reluctant to share because I had a fancier job title than he did.
This incident and other similar ones led me to learn that
The smartest person in the room is not smarter than the whole room.
No matter how smart the one person may be or how much experience that person might have, the collective wisdom of the team is greater. The best ideas and decisions will be born from the discussion rather than from the mind of just one person.
If You Don’t Manage Expectations, Expect to Fail
I learned this next lesson from perhaps the least technically savvy boss I ever had. But he understood the importance of managing expectations.
We were building a large call center system that was to be used by nurses who worked in our company. The project ultimately was very successful and was instrumental in helping the company grow from 100 employees to over 1,600 employees within a couple of years.
But if I hadn’t shifted my efforts a few months before the end of the project, that same project would have been viewed as a complete disaster.
The problem was that the nurse’s expectations for what the software would do were through the roof. They had somehow started to believe that the software was going to do things that still aren’t possible 20 years later. Some of the things they had just made up in their heads--and then shared among themselves--were amazing.
I was aware of this disconnect between expectations and reality. But I was too busy with the overall technical aspects of the project to worry about it. Until one day my boss gave me some advice that made me reconsider. He told me that to be successful, the project needed to do two things:
provide the necessary functionality
meet or exceed user expectations
He educated me that if we failed at either one, the project would be viewed as a failure. I knew right away that we could never meet or exceed the nurses’ current, inflated expectations. Since I couldn’t change our technical capabilities, I began working to change our users’ minds.
I immediately shifted the focus of my time, spending about half of each week talking to the nurse users about what the system would and wouldn’t do. I traveled to each of the company’s four call centers around the United States every few weeks and presented the equivalent of a sprint review to nurses in each location.
I’d learned the lesson that
If you don’t manage expectations, expect to fail.
If I had stayed focused purely on the technical delivery of that product, our users would have looked at it and said, “Is that all there is?” Their unrealistic (impossible!) expectations would have led them to be disappointed in what was actually a very good product--one which ultimately made billions of dollars for that company.
Giving Thanks for These Lessons
There are many more lessons I’m thankful to have learned. I often have to live through an experience a couple of times before the truth hits me. Each of the truths I’ve shared with you so far is something that I learned relatively early and that had a significant impact on my career.
But there’s one last lesson that I need to share:
I couldn’t do what I do if it weren’t for you.
I wrote above that I love what I do, and that’s why I’m a workaholic. Except most days it doesn’t really feel like work to me. I couldn’t do what I do if it weren’t for the people who visit this blog or who subscribe to my weekly tips.
And for that I am very thankful to each of you.
What Lessons Are You Thankful to Have Learned?
What are you thankful to have learned in your career? Please share a lesson or story in the comments section below.
An agile team should maintain a consistent sprint length. Unfortunately, when I first began doing iterative and incremental development (even a bit before doing what today we’d call agile development), I made the mistake of not having all of our sprints be the same length.
We would meet at the start of a sprint to plan the work of that sprint. One item on the agenda of those early sprint planning meetings was to decide how long that sprint would be. We would bounce around in a seemingly random manner between lengths of two to six weeks.
We would make the decision about how long each sprint should be based on how big we felt the work was, how much of it we needed to deliver before our users could see it, who was planning to be out of the office, and how energized or tired we felt.
Allowing our sprint lengths to vary seemed right at the time—and I have to admit it wasn’t a conscious decision; we just did it without ever discussing whether it was a good idea. It was later that I discovered the four reasons for using the same length every sprint.
Teams Benefit from a Regular Rhythm
First, teams benefit from a regular rhythm. When sprint lengths vary, team members are often a little unsure of the schedule. “Is this the last week?” and “Do we ship this Thursday or next Thursday?” become common questions. Having a set sprint length--whether that’s one week, four weeks, or somewhere in between--helps teams settle into the rhythm most suited to them.
Sprint Planning Becomes Easier
A second reason to use consistent sprint lengths is that sprint planning become easier. As a team runs sprints, team members learn how much work can fit successfully into a sprint. Planning the next sprint then becomes as simple as selecting about the same amount of work.
Tracking Velocity Is Easier
When sprints are the same length, it is easier to track velocity. When a team varies its sprint length, they either have to note each sprint’s length (to explain why longer sprints had higher velocities) or normalize into something like velocity per week or velocity per day.
Unfortunately, there is no guarantee that a four-week sprint will complete exactly twice as much as a two-week sprint. Normalizing velocity to be velocity per week works somewhat but is needless extra work when sprints are kept the same length.
It’s What Richard Feynman Would Do
A fourth reason to keep sprints consistent is that it is what Nobel Prize-winning physicist Richard Feynman would do. In his book Surely You Must Be Joking, Mr. Feynman, he recounts the story of getting tired of having to choose what to have for dessert each evening. From that point on, he resolved he would always choose chocolate ice cream.
Choosing a sprint length at the start of each sprint is a waste of energy. Experiment with a couple of lengths, make a decision, and stick with it until there is a significant reason to change.
Can a Team Ever Change Its Sprint Length?
In stressing that your sprints should all be the same length, I am not suggesting you become obsessive about this. No guideline such as this needs to be turned into an unwavering rule. There may be occasions when it would be best to deviate slightly from this schedule.
Long holidays are sometimes a good reason for a team to change its sprint length. For example, in the United States, it’s common for people to take extra time off around Thanksgiving and Christmas. A team that routinely does two-week sprints may find itself with half the number of person-days during a sprint that includes one of these holidays. In that case, the team may benefit from a three-calendar-week sprint, as this would yield closer to the usual number of person days.
Another example could be a team that is approaching a major milestone that would occur, say, one week into the next sprint. Such a team may very reasonably choose to simply plan a final sprint that is one week longer than a typical sprint.
Changing sprint length even in these situations is usually not my preference, but I understand why a team might choose to do so.
What Has Your Experience Been?
What has your experience been with changing sprint lengths? Does your team change sprint length--if so, has that been a good or a bad thing? If you try to maintain consistent lengths, do you ever change? When? Please share your thoughts in the comments below.
I’ve never been a huge fan of horror movies. But I have always liked Halloween, especially as a kid. I loved dressing in a scary costume and trying to frighten my friends or other trick-or-treaters. And I admit to getting a bit of a thrill from walking through a well executed haunted house.
But, there are aspects to every agile transformation that can send a shiver down a spine--and those moments are not quite so thrilling. So let’s take the fear factor away from five things that might make you want to run for cover along your agile journey--first by naming them and then by talking about why they aren’t so scary once you understand how they work.
Eeek! Agile Has No Design Phase!
Architects and senior tech people are often frightened by the idea that there’s no design phase in agile. While it’s true that agile teams shun an upfront design phase, that does not mean that design doesn’t occur.
Design on an agile project is characterized by two attributes: it is both emergent and intentional. An emergent design is one that comes into existence over time. Rather than being done all upfront in a single phase, design is an ongoing activity. The design emerges through the creation of the software.
But design is also intentional. This means the design does not emerge randomly. Design is guided by the intent of the senior technical people on a project or perhaps even someone in a designated architect role.
If the senior technical people are concerned about a particular part of the system, the product owner should prioritize a product backlog item or two in that area. This will allow the team to explore that part of the system by building some small part of that system. Doing so will help identify the appropriate design in that area.
Allowing design to emerge guided by the intent of the team will reduce the terror of there being no design phase in agile.
Help! I'll Become a Generalist.
A common myth that has persisted since the earliest days of agile is that agile teams don’t value specialists and want everyone to become a generalist. This is frightening to many people for two reasons: First, no one enjoys all types of work equally and second because of the concern it could impact future employability if someone can do four things adequately instead of one thing extremely well.
A goal in agile is the formation of cross-functional teams, which means the team has all skills needed to produce a finished, working deliverable within the iteration. Doing that does not require each person to have all the skills of a cross functional team.
If the thought of becoming a generalist makes your hair curl, understanding that a cross-functional team still allows for specialists should put your mind at ease.
Oh No! We Can’t Plan or Predict Dates!
Management is often chilled to the bone by the idea that an agile team can’t plan or predict dates further ahead than the current iteration or sprint.
Fortunately, this does not need to be the case.
Yes, agile teams give up the false comfort of overly planned projects with intricately drawn Gantt charts showing a precise completion date way in the distant future. But that does not mean agile teams are unable to make plans or predict future delivery dates or scope.
A huge benefit of agile is that every iteration the team turns the crank on the entire development process. That is, they take an idea usually expressed as nothing more than a simple user story, and they full implement that feature. This means that every few weeks, a team can measure its progress: They can know how much they got done.
Contrast this with a traditional development projects, perhaps one with an analysis phase, a design phase, a coding phase and, finally, a testing phase. When that team measures its progress over a period of time, they are measuring only how fast they are at doing one (or perhaps two) types of work. How fast a team is at doing design says nothing of how fast the team will be at coding and testing.
The key with agile planning is embracing the uncertainty--admitting that it’s impossible to know all the functionality that will be built before starting the project--and then adjusting for that in a variety of possible ways. When teams combine this realization with the ability to actually measure the amount of work done every iteration, it leads to reliable planning, which should calm the nerves of a management team daunted by the prospect of having no predictability.
Yikes! I Won't Have a Job!
The prospect of transitioning a team or company to agile is enough to scare the pants off some managers who are concerned they won’t have a job after the transition is complete.
This is understandable. It would be dismaying to start a transition effort aimed at helping a company knowing that it may make your role superfluous.
However, I can clearly say that I have never helped a company adopt agile and then seen that company say, “OK, we no longer need people with job title such-and-such. They’re all terminated.” It just doesn’t happen. Sure, a company may decide a specific job title is no longer needed or appropriate. But the individuals with those titles still have jobs. And in most cases, I believe they end up with better, more focused jobs. With that being said, it is true that some people will end up with less direct control over people or decisions and they may find that frustrating, even to the point of leaving the company.
But because I have never seen significant layoffs of any role or skill as part of transitioning to agile, I believe this fear is as misplaced as that of a zombie apocalypse.
Zoinks! Scrum Has Too Many Meetings!
Like many people, I really hate meetings. In fact, it’s largely why I do what I do. Most days I have no meetings at all. Pure bliss.
But even I can acknowledge that some meetings are important and useful. And that includes the four standard meetings of Scrum: the sprint planning meeting, the daily scrum, the review, and the retrospective.
The thought of all these meetings, however, can send some people into a cold sweat.
Here’s the problem with Scrum meetings--they have names. When something has a name, it’s easier to attack. In my experience, many teams who adopt Scrum had more meetings before Scrum. But the meetings didn’t have names and were mostly ad hoc meetings called to resolve specific issues.
Here’s an experiment I like and that you can easily do to see if you’re having significantly more meetings with Scrum. Randomly pick a month on your calendar from before you started adopting an agile approach. Open that month up in your calendar software and add up the time spent in meetings. Then add up the average time in your Scrum meetings and see how they compare.
Based on my experience, you might well be surprised by the results. But because those pre-agile meetings were not recurring, regular meetings, they didn’t have names and so they don’t stick out in our memories the same way a named meeting, like “Sprint Planning,” does.
The key for overcoming the terrorizing thought of too much time spent in meetings is keeping the meeting short. Occasionally I’ll work with a team that I need to encourage to spend more time in a certain meeting. But most teams spend too much time in each of the standard meetings. Once they find ways to shorten them, those meetings should no longer frighten us out of our wits.
Relax...those Ghosts and Ghouls Aren’t Real.
While it can be fun to walk through a haunted house or dress in a scary costume, most of us can easily remember that it’s all make-believe. Those ghosts, ghouls, vampires, werewolves, and crazed lunatics with chainsaws aren’t real.
And neither are the five agile legends I’ve outlined here. And while no one can be faulted for being afraid at first, education and experience will pull the mask off the myths, leaving us reassured rather than unnerved.
What Have You Been Afraid Of?
What part of transitioning to agile did you find the most scary? How did you overcome your fear? Please share your thoughts in the comments section below.
Today, the advanced Better User Stories course is open for registration again, but only until midnight 11th October, Eastern time (US).
I’m excited to welcome new members into the course. We’ve had fantastic feedback about the materials, and I know from the emails I’ve received that those who missed out last time are keen to take the course and start writing better user stories.
Want to know what it’s like to be a member? Read on
If you’ve been thinking about joining, and want to know what it’s like, today’s blog post is for you.
We asked four members to share their experience and results they had from taking the course. Their answers give you a behind-the-scenes glimpse at Better User Stories and see how it could impact you, your team and the wider organization in which you work.
“We defined the work for three releases in four hours”
Peter Moreira has more than 5 years’ experience in the role of Scrum Master, with several years’ experience as a senior project manager before that. Currently he works with two Scrum teams in an organization that develops apps for its website.
What results have you seen by taking the course?
“The timing of the course was perfect as our teams were transitioning to working on new apps. Having it at this time meant that we could use the course materials and learnings to start with the right step.
“We ran a story-writing workshop and having the graphic of working left to right and top to bottom for sequence and priority, visually, was very powerful. The first time we did it we had people in multiple locations. So we had a big board and someone repeated what we were doing digitally so that those on the video conference could watch and participate. In just four hours we had defined work for three releases, all pointing back to one significant objective. The entire team and stakeholders were so impressed with the exercise and were amazed at the results.”
“I’ve taken a lot of online courses and in-person ones, but this probably had the best sense of community I’ve ever seen.”
Jim was an Expert Level member which meant he could attend live Q&A calls with me, as well as access the private Facebook group for the course. Jim works for a community college district in Southern California with two colleges. His department is responsible for administrative systems for the schools, and these can be very complex. Although they buy and integrate some software for the systems, they also build a lot of their own, and that is where they use agile development techniques. Jim’s been using Scrum and usually has three different agile teams working on things at any given time.
What did you enjoy about the course?
“I liked that the videos were short. You didn’t have to invest a huge amount of time, but it was one of the densest courses I’ve ever seen. You could sit down for 15-20 minutes and get what felt like a day’s workshop in it. I’ve taken a lot of online courses and in-person ones, but this probably had the best sense of community I’ve ever seen. The coaching calls combined with the Facebook group generated a lot of community discussion. The thing that really opened my eyes was how many people are using this in so many places around the world. Everything that was posted was something I could identify with. The diversity and yet commonality of issues was remarkable. To see what’s happening on a worldwide basis was eye-opening, refreshing and exciting.”
“I have a more systematic approach for writing better stories.”
Aurelien Duval is a product owner for a company that builds security solutions for mobile apps to protect them from tampering or hacking attempts. His current company has been using Scrum for around 3-4 years
What made you interested in Better User Stories.
“My stories used to be very ‘tasky’. Telling the team what to do but also how to do it. At the end, I would get a final product that was the vision I have, but I felt that we could get even better results if I let the team organize the work in the way they prefer, within a certain space.”
What results have you seen from the course?
“It’s put me into the mindset of thinking in a different way. The way I used to write stories included the ‘how’. Now I have a more systematic approach for writing better stories. Rather than me generating the stories, I’m trying to create the stories with the team by saying: ‘here is the problem and the big goal, how do we solve it?’ It’s still a little bit prescriptive, but I’m moving forward to more collaborative story-writing.”
“I was impressed with just how much additional information and materials were included in the price”
Michael B. has more than 33 years of experience and works for a consumer products company that is implementing E-commerce capabilities. He’s been both a Scrum Master and a product owner.
What did you enjoy about the course?
“I loved that Mike wasn’t dogmatic about the “As a… I can… So that…” rule as it’s not always that simple. Mike’s course had a much more common sense approach. I loved being able to access the free modules before signing up to the full course. This was brilliant. It addressed concerns I’d been having and gave results, it was information I could action and use when most free samples don’t give you the meat and potatoes.
“Mike has a great conversational style, he’s not lecturing. It’s like having coffee with a friend and I liked that I could watch on my laptop or tablet and sometimes would throw on a session while shaving. The sample website application Mike uses throughout the course is amusing and kept my interest. I was able to follow it and it was also mixed in with other examples. This helps you take generalized concepts and apply it to specifics which helped with the learning.
“I was impressed with just how much additional information and materials were included in the price. I was expecting some notes, but the bonus materials were great, like the fully downloadable transcripts. I currently have the SPIDR poster on my walk at work.”
If you’d like to find out more about Better User Stories including the curriculum, course materials, and bonus content, visit www.betteruserstories.com. There is also a simple option you can select if you would like your employer to pay for your membership. Any other questions about the course? Feel free to comment below and I’ll answer.
Read Full Article
Read for later
Articles marked as Favorite are saved for later viewing.
Scroll to Top
Separate tags by commas
To access this feature, please upgrade your account.