Are you measuring the value, risk, and quality flowing through your DevOps pipelines? Here is a value-based approach to measuring DevOps performance that will help your organization better evaluate the effectiveness of its DevOps initiatives. As organizations become increasingly value-stream … Continue reading →
The post Measuring DevOps Performance Using a Value-Based Approach appeared first on The Agile Management Blog.
Are there any Guns N’ Roses fans in the house? Anyone? You over there in the corner—yeah you, what was the name of the amazing guitarist who wore a top hat and even though he wasn’t the lead singer, somehow managed to outshine Axl Rose?
Yes, it’s Slash! Good job!
Why are we talking about Slash? Well, because our left panel keeps improving with every release and for v1.8, it’s all about the slash.
You’ll remember in our last release, v1.7, we made significant performance improvements to the left panel, which made life much better for everyone. Now, we’re introducing folders to the famed left panel.Folder Hierarchy
If you have slashes in your branch, GitKraken will simply build a folder hierarchy for you.
GitKraken will build a folder hierarchy for you in the left panel.
News like this is so glorious, it’s just like hearing that sweet opening riff to Sweet Child O’ Mine. You should probably listen to it now just to remember how good it is. We’ll wait.Filtering
Okay, you’re back! And you’re already familiar with the fuzzy finder: another one of our helpful features that makes it easier and quicker to find things. Now, we’ve simply taken that functionality and applied it to the left panel as well.
You’ll notice that a new search box has been ever so delicately placed at the top of that left panel. So, you can use cmd or ctrl+ shift + F to find what you’re looking for. Suddenly you’re a rockstar…but with code, not a guitar!Filtering has been added to the left panel. It’s So Easy.
No more clicking, scrolling, cursing or wondering where your branches, remotes, pull requests, etc. are. Don’t Breakdown. Now you can simply filter with the search box. Oh, oh, oh, sweet love of mine!
Run on over to the release notes to read more. They won’t let you down like perhaps The Spaghetti Incident? did.
It didn't start out that way. Scrum Day Portugal is a two day event. I arrived Tuesday afternoon, half way into the first day. The speakers were interesting, the talks were great, but we were running late. It felt like a death march project, even though the conference had barely begun.
My job was to facilitate the second day. We had a really tight schedule! Seven igniter talks followed by 2 Pecha Kuchas and 3 ½ hours of Open Space. I realized that staying on schedule would be both challenging and really important. If people are exhausted at the Open Space, they can employ the law of two feet (leave), and all the air goes out of the event. This would be a disaster. How to fix the problem?
Tuesday night, the speakers went out for dinner together. We talked about the problem. A big challenge was that most participants arrived late on Tuesday, and would probably do so again on Wednesday, so we could not just ignore our customers and start on time. Another challenge was that one speaker needed more time than originally planned. Not knowing how late we would have to start, we couldn't decide how to address the scheduling problem. We agreed to make the decision Wednesday morning.
On Wednesday, I invited all the speakers to a daily scrum, shortly before the opening was scheduled. While I tried to make a plan for the start times of each speaker, Chet Hendrickson started writing cards on the table. He made a card for each speaker, the coffee break and lunch.
Visualizing the program à la XP
At this point, I gave up on my “spreadsheet”! Using Chet's cards and the original schedule, we calculated the duration of each session. We agreed to start 15 minutes late, but keep the original timings. So we calculated the new start times for each speaker. What about the speaker, who needs more time? “I can shorten my talk, no problem!” said Manny Gonzales, CEO of the Scrum Alliance (when was the last time you heard a CEO volunteer to shorten their talk?).
What about transition times? There are no transition times, this is the time each of us starts. “Oh, so I have to shorten my talk a bit.” We all understood the problem and the goal. We had implicitly agreed to do our best to make it happen.
“The key word is responsibility,” explained Chet, “Everyone in the team has an obligation to do the right thing. The cards are a tool he uses in Extreme Programming to visualize system architecture, and thanks to the visualization, everyone knew what they had to do.
How did we stay on time? During the each session, I just needed to know who the next speaker was, when their session was scheduled to start. The speakers asked for a friendly wave at five minutes before the end of their session, so they could remain aware of when the had to finish.
In the worst case, a session ended in 1 whole minute late. Some of the speakers over-compensated (shortened), so by lunchtime, we were back on the original schedule!
So the conference ran smoothly and everybody left the conference with a smile. What does this have to do with Scrum and XP?
- Someone was responsible for the process, and raised the questions. In Scrum, that person is called the Scrum Master.
- The team got together to figure out how to achieve the day's goal. In Scrum that's called a Daily Scrum. We left the meeting with a plan and a common goal.
- The Scrum Master remained focused on the process, giving friendly reminders when it was helpful.
- The time-boxing gave us orientation and helped us deliver a great conference.
- Visualizing the problem and giving it to the whole team made solving the problem much easier. (I don't know what Chet calls his board, but it's a great approach.)
Nowadays though, divide et impera is more and more recognised as a highly unadapted approach for the complex world of business. Agile thinking trend heavily agree with this. Nevertheless, we Agile supporters may have a hard time to provide a clear explanation why is this so. A metaphor (oh, thank you, Clean Language!)inspired by Karlene Roberts on HRO organisations help to build some - hopefully helpful - arguments to describe the negative effect of siloted organisations. Specialized silos, when they interact, create a "space in-between" that behave like "interstices" or "holes". Like in a raw material or fabric, these interstices are the main source of fragility. Organisational interstices behavior effectsLoss of knowledge when dividing the work by specialisationThe specialized, eventually externalized, organization has very sharp expertise, but ignores the synergy and the integrated knowledge of the whole operational chain.Conflicting interests The high cost of interstices One of the more or less recognised reasons of creating specialized organisms is cost reduction. Usually the cost of this set-up is considerably higher because of interstices costs. When an interstices between two organizations happens, the need of "transve" communication and coordination rises quickly. Therefore groups of coordinators, teams in charge of transversal communication and facilitators are created. The cost of the coordination can blow-up ceilings.
Enhanced fragility. What does creating a transverse management and coordination group mean? More interstices, with all the related dysfunctions.! An infernal loop is created: interstices tend to self-multiply to fix their dysfunctions, therefore creating extra dysfunctions. Breaking the loop and and shift the associated mental model is the next challengeHow to close an interstices The no punishment policy Inspired by the HRO ( High Reliable Organisatins) model. The practice of "immunity" in case of error is phased on the principle that learning and knowledge is acquired when there is no fear to tell all the facts that create the big picture of a post-incident. Silence is no value for learning, improving and avoiding further incidents....And punishment is the mother of silence.
Dear reader, does this seem an idealistic Disney world framework to you tight now? Then let me give you examples of organisations that apply the "non-punishment policies of HRO : flight companies, Air Force, and more and more hospitals and emergency units. So to say, very unexpected references of La-La Wonderlands.
The non punishment policy leads to high reliability because big accidents can be avoided by open learning from minor incidents (near miss).
We have made some huge changes in our prioritization and planning process this year. In a nutshell, we have switched to open allocation. Here is the story.Old way: boards, feature ranking, top-down approach
During the last several years we used to have a Product Board. This was a committee that focused on annual product plans. It consisted of up to a dozen people with various roles from sales to developers. We discussed our product strategy and set high-level goals (like "increase the market share at the enterprise market"). We created a ranking model that we used to prioritize features and create roadmaps:
It kinda worked, but at some point I understood that somehow we pushed more and more features into Targetprocess, making it even more complex and heavy. Many people inside the company were not happy with this direction and they did not believe in it. Large customers demanded complex features like more flexible teams management, people allocation, an advanced QA area, etc. These are all good features, but we, as a company, somehow lost the feeling of end-user experience. Some simple things like search, navigation, performance, and simplicity were buried under fancy new features. This year, we put an end to that approach.
We want to create a tool that is pleasant to use. A tool that boosts your productivity and is almost invisible. A tool that saves your time. To achieve this goal, we have to go back to the basics. We should fix and polish what we have in Targetprocess already (and we have a lot) and then move forward with care to create new modules and explore new possibilities.
We have disbanded the Product Board, removed feature prioritization, done away with the top-down approach to people/team allocation, and replaced it with a few quite simple rules.New way: Product Owner, Initiatives, and Sources
The Product Owner sets a very high level strategic theme for the next 1-2 years. Our current theme is very simple to grasp:
Basically, we want to do anything that reduces complexity, simplifies basic scenarios like finding information, improves performance, and fixes your pain points in our product.
This does not mean that we will not add new features. For example, the current email notification mechanism is really outdated, so we are going to replace it and implement in-app notifications. But, most likely, we will not add new major modules into Targetprocess in the near future. Again, we are focusing on existing users and their complaints.Initiatives
Our people have virtually full freedom to start an Initiative that relates to the strategic theme. An Initiative is a project that has start/end dates, a defined scope and a defined team. It can be as short as 2 weeks with a single person in the team or as large as 3 months with 6-8 people in a team.
There are just three simple rules:
- Any person can start an Initiative. The Initiative should be approved by the Product Owner and the Technical Owner (we plan to use this approval mechanism for some time in order to check how the new approach goes). The Initiative should have a deadline defined by the Team.
- Any person can join any Initiative.
- Any person can leave an Initiative at any time.
A Source is the person who started the Initiative. He or she assembles the team, defines the main problem the Initiatives aims to solve, and is fully responsible for the Initiative's success. The Source can make all final functional decisions, technical decisions, etc. (Remember, Helpers are free to leave the Initiative at any time, so there is a mechanism to control poor leadership).
A Helper is a person who joins an Initiative and is committed to help complete it by the agreed deadline. He or she should focus on the Initiative and make it happen.
The Initiative deadline day is pretty significant. Two things should happen on the deadline day:
- The Source makes a company-wide demo. They show the results to the whole company and explain what the team has accomplished.
- The Initiative should be live on production.
As you see, freedom meets responsibility here. People are free to start Initiatives and work on almost anything, but they have to meet their deadlines and deliver the defined scope. This creates significant peer pressure, since you don't want to show bad results during the demo.
This process was started in July. We still have a few teams finalizing old features, but the majority of developers are working in the Initiatives mode now. Here's a screenshot of the Initiatives currently in progress:
The Initiatives in the Backlog are just markers; some of them will not go into development, and there is no priority here. Next is the Initiatives Kanban Board:
You may ask, how do we define what is most important? The answer is: it does not matter. If we have a real pain from customers, and we have a few people that really want to solve this problem — it will be solved. Nobody can dictate a roadmap, nobody can set priorities, even the Product Owner. The Product Owner can start their own Initiatives (if they can get enough Helpers) or decline some Initiatives (if it takes tooooo long or doesn't fit the strategic theme).
As a result, we don't have roadmaps at all. We don't discuss priorities. And we can't provide answers to your questions like "when will you have a better Git integration". We can only make promises about things already started (you can see some of them above). All the people inside our company care about making our customers happy with the product, and now they have been enabled with real power to react faster and help you.
We can also promise that Targetprocess will become easier, faster, and more useful with every new release.
In Coaches, Managers, Collaboration and Agile, Part 1, I wrote about circumstances under which a team might want a coach. It wasn’t an exhaustive list. It had several questions defining when coaches might help the team to become agile, not be cargo cult agile.
One of the reasons we might need coaches for a team is because of the changed manager role in agile.
In functional organizations, managers coached the team members on how to do their jobs better. (Okay, some managers did.) Development managers coached developers. Test managers coached testers. Project manager-managers coached project managers, etc. Each functional manager coached the people in their functions on how to do their functions better.
Some managers learned how to coach the functional people to perform better in teams. To be honest, that was often quite difficult. The organization rewarded the function, not the teamwork.
Agile is changing this mindset of “coach the function, let the teamwork take care of itself.” (Yes, that’s a generalization, and not fair. However, I see a lot of it.)
In agile, we want a product as a result of team effort. That leads us to think about the role of managers and teams and coaching in different ways. (Well, it does for me.)
If you are not aware of Human Systems Dynamics, let me introduce you to the ideas of Containers, Differences, and Exchanges. I read about this in Adaptive Action: Leveraging Uncertainty in Your Organization.
When people and projects choose agile, the managers have new and different roles. People no longer affiliate with managers (the container part). They affiliate with projects. This means that manager-as-coach changes in any number of ways.
Instead of being able to, or even having the time, to coach people on their functional roles, the manager might create communities of practice, or other ways of encouraging people to learn about their role better. If the manager knows about the function, the manager can coach the people.
And, many managers only know about or have experience in their own functions, such as strictly development or testing or writing. I call these managers “ignorant.” That’s because unless a manager can see the entire picture (including the dynamics of a project, the manager might not realize the problem with the impediments the team faces.
Ignorant managers cannot create the environment in which a team can deliver working product. Yes, the team has responsibility for a significant part of that environment, especially working as a team to move features across the board. And, the manager creates the container in which the team works.
I’ve seen ignorant managers create these problems for the team:
- They don’t realize the effect of multitasking on the people or the team
- They don’t realize that a team being able to go fast is a result of technical excellence and getting to done on small features
- They want guarantees (often in the form of estimates) instead of seeing the learning that teams require
You might see other problems in your organization. An ignorant manager cannot help the team or the team members at all, because the ignorant manager does not realize the problems these impediments cause.
The agile manager’s role changes, especially managers who “manage” technical teams. I wrote about this years ago in Agile Managers: The Essence of Leadership.
Agile managers help facilitate the environment for the team (possibly along with an agile project manager/Scrum Master or a program manager). They are servant leaders. They provide coaching and feedback and meta coaching and meta feedback. The manager’s role is about facilitating what the team members can deliver, to the team, to the product, and to themselves. It’s about inspect and adapt for team members.
That’s where we encounter the affiliation problem. Who do we want the team members to identify with? With the functional manager—who with good intentions—ask a team member to do work not on the board? Or, do we want team members to identify with the team? I vote for the team. (I vote for the team regardless of the approach, agile or otherwise.)
Managers might need coaches so they learn about what the team members do. Then, managers can provide feedback and coaching and meta feedback and meta coaching as someone who can see from the outside of the team. Managers can learn what the impediments are for agile (too-long duration commitments, resource vs. flow efficiency, HR and finance issues). Managers can help lead the organization’s agile approach.
And, many managers need coaching to do this: agile coaching and how the functions work in an agile team. That’s because we want managers to be the best managers they can be to help the organization move to agile.
When managers change what they do, they might need coaching to learn how, and to get the feedback to see the possibilities of their decisions. Management coaching is not about weakness. It’s about the realization that if we want to change culture, we change behavior. Not just team behavior. Management behavior is a key part of the agile transformation.
In part 3, I’ll address coaching and collaboration for middle and senior managers.
On-Demand users will be able to switch to the beautiful beta of our new Visual Report Editor from Report Settings.
With this editor, you will have a lot of useful and easy options:
- You can drag-n-drop fields in reports to edit them and explore your data
- Aggregate fields, and make title and sorting changes with one click
- Important milestones and threshold lines can be added from field annotations
- Browse and edit chart data with the built-in visual editor
- Easy custom calculations via a formulas editor with full autocomplete
Read more at this dedicated release post for the new Report EditorBatch Actions: Text, Number custom fields, batch change Effort, link Relations
In v.3.10.1 you can reset or set new efforts for a group of selected cards. Only roles, who are common for all selected cards, are available in a batch action panel. Here you can set a new effort number or reset it to zero. If you see a certain number in the Effort field, it means that all cards in the selection have the same effort set. The 'Set new' placeholder means there are different Effort value sets in different cards (if the selection is for a given role).
You will also be able to batch attach any Targetprocess entity to a group of cards as a Relation.
We've also added support for two more types of Custom Fields (in addition to drop-down lists) in the Batch Actions panel: Text and Number. We're now working on Date, Checkbox and Multiple Selection Custom Fields support.Clone Dashboards
Somehow, the Clone action was missing from Dashboards. We fixed this inequity - you will now be able to make a copy of any Dashboard.
- Fixed Custom Field Constraints mashup to support custom teams workflow states
- Fixed '0' drop-down list value wich couldn't be set properly
- Fixed 'Share report' option
- Fixed ban on adding users if their email is the same as a deleted user had
- Screen Capture Extension: login issue fixed
- Fixed problem with Copy to project / Convert not working if there is a deleted user assigned to a card or its child entity
- *.m4a attachments now download correctly
- Fixed Dark skin for TV to show view name properly
- The *.Count().* DSL filter supports more complex predicates. Example: 'UserStories.Count(Feature.Name.Contains('Web') and Effort > 0) > 5'
- Added the option to open URLs with the Targetprocess site domain from Custom fields in a current window
You may find the following features to be useful:
- Editing reports and visually exploring your data can now be done simply with interactive fields and drag-n-drop
- Aggregate fields, and make title and sorting changes with one click
- Important milestones and threshold lines can be added using field annotations
- Browse and filter chart data using the built-in visual editor UI
- Custom calculations can be done easilly via a formulas editor with full autocomplete. This will bring your creation of complex calculations to the next level
- Low-level data details are available within the tooltip data reveal extension
Here's how you can try out the new Report Editor:
We will really appreciate your feedback on this beta release of our new editor. What do you like about it? What could be improved? Let us know what you think at email@example.com
It all began about a year ago. The sea was calm, and the wind was blowing steadily. I saw a small object floating away on the high seas, and I quickly grabbed my harpoon to pull it out of the water.
Upon close inspection, I saw a box with a greenish (almost blue) monster, with tentacles carved in it, and even though it was just a carving, its eyes seemed to pierce my soul. I took a deep breath and, after gaining some courage, I opened the box, and then the whole world changed…
The Kraken had been unleashed, and I controlled the great beast of the seas!
Leaving the metaphorical explanation of how I found this piece of software, I should probably tell you why GitKraken is my Linux Git GUI of choice. Here are some specific reasons:Linux
Why would I bring up Linux? For two reasons: Linux Git GUIs aren’t that good, and the real competition doesn’t have a Linux version. Let’s unpack this statement, shall we? First of all, most Git GUIs for Linux make me feel like I’m back to Windows 95, in need of multiple windows to do a simple commit and push.I want to go to any OS, download my favorite app and use it; GitKraken gives me just that.
Others fill the screen with views that I only use once every four months and exist only because I messed up while reverting a commit. Other Linux GUIs are old-fashioned or complex and crowded.
GitKraken offers a modern view of how Git should be used and ends the starvation for a good Linux Git client.
Secondly, most of us know one or two really good Git GUIs: for example SourceTree or GitHub for Windows. These are two pieces of software that I used for quite a while, but when I moved to Linux they were missing. I want to go to any OS, download my favorite app and use it; GitKraken gives me just that.User Interface
Let’s backtrack a bit to where I said, “GitKraken offers a modern view.” If you’ve never tried GitKraken, you are probably thinking, “Yeah right… that’s what they all say.”
Well, here’s what I say: just try it. Commit some code, then revert the commit. Did you do it? How hard was it? A push of a button? Really, it’s that that simple.If you’re like me and prefer it simple, this is for you. Just open the app, write your message and commit the hell out of the repo.
In addition, there are no weird hidden menus, and drag-and-drop is also a very nice feature. Tell me I’m not right. Just try it.
Check out that drag and drop feature. Rad!
Perhaps you’d like to see more controls so that you can easily do those weird commands Git offers. Or maybe you prefer the CLI because you want to master all the commands.
But if you’re like me and prefer it simple, this is for you. Just open the app, write your message and commit the hell out of the repo. Don’t forget you can always undo the commits that you mess up.The Dark Side
If there is light, there must be darkness, and yes, even GitKraken has its weaknesses. One weakness that I’ve experienced is the hooks. When pushing in GitKraken, hooks (in .git/hooks/) are not triggered, which made me stop using GitKraken in a specific project.
Another weakness is that there is no forum for users to report issues (akin to something like Stack Overflow.) Don’t get me wrong, GitKraken is very active with the community; just see their blog and Twitter feed.
It’s awesome to see such proximity between a company and the common folk, but when more technical problems arise, there isn’t really a place to go, other than to contact support if you are using the Pro version.
Editor’s Note: We launched our GitKraken Slack Community just after this article was written. This is a great place for users to discuss tips and ask/answer each other’s questions.
In conclusion, if you like a modern design, a handy undo button, a beautiful layout, and Linux support, then GitKraken is for you. Try it and see, you’ll be amazed!
There was a fascinating Twitter conversation last week when I was busy writing other things. (I also find Twitter to be a difficult-for-me arena to have a conversation. I need more than 140 characters.)
The conversation started when Neil Killick tweeted this:
orgs need coaches not because “agile is unintuitive”, but because effective sw delivery is a team game requiring folks at their best.
I liked that and retweeted it.
Mohinder Khosla asked (quite reasonably, in my opinion):
Do we have stats that this is real? Just saying
Mohinder, I am sure we do not have stats. We rarely do what I would categorize as real research in how software product development works. That’s because we continually learn and even if we start a new project with exactly the same people, we have learned to work together in previous projects. If we don’t keep teams together, we have to relearn how to work together. (See Hackman’s Leading Teams book for this and much more insight on teams.)
Agile challenges all of our previous assumptions about how software product development works.
- We think in product, not just project. See terms as releasing, product owner, and MVP.
- We think in flow efficiency, not resource efficiency.
- We integrate all of the work we might have done as phases into small stories that we release often.
- We invite change, we don’t try to control it
- and much more…
One of the big changes in agile is that we work as a team. We work as a team to move work across the board. We don’t hand off work from developers to testers. We don’t hand off work from architects to developers. We don’t hand off work from testers to operations.
Can each team do that now? Probably not the first time they try to use agile. This notion of the cross-functional team being the team in question challenges everything we, our managers, and our organizations “know” about product development.
Coaches can help teams and managers learn what it’s like to create the agile mindset and an agile culture. Do you need a coach? Maybe not. Here are some questions I have asked my clients when they asked whether a coach would be useful for them:
- Do you have a cross-functional team? Or, is it a team of developers, followed by a team of testers, etc.
- Can you create features as one cross-functional team, by yourselves? (You might not be doing this now, but can you? Or, do you need other people across the organization?)
- Does the team demonstrate on a regular basis? (My guideline: at least once every two weeks.)
- Does the team retrospect on a regular basis? (My guideline: at least once every two weeks.)
Notice that these questions are about team collaboration and delivery.
Agile creates transparency. We can see when a team is not “performing.” I put that in quotes because often the environment is what causes teams to not “perform.”
Some teams have trouble working as a team. Coaches can help. Other teams cannot answer yes to my four questions. If so, coaches can help the team and the managers. Can the organization help itself? Of course. Would it be easier with a coach? Probably.
You don’t need agile coaches to be successful. You can do it yourself. And, if you look at people and teams who fit your definition of success, they will often tell you they have coaches. (I do.)
Agile teams deliver working product on a regular, frequent cadence. They can use flow-based agile or iteration-based agile to do so. It doesn’t matter.
When teams deliver on a regular basis, they work as a collaborative team. That idea and practice might be quite new to everyone in the organization. Coaches might help.
The next post will be the role of managers in coaching in an agile environment.
We're entering flu season. No, no, I feel fine. And you won't catch anything from me just by reading this.
But flu seasons means some of your teammates are bound to be sick soon. And that means they'll occasionally stay home and miss a meeting.
What should a Scrum team do when the whole team will not be present for a meeting?
In most cases, everything should roll forward as planned. Let's look at each of the common Scrum meetings.The Daily Scrum
A daily scrum should never be cancelled simply because a person (or two) cannot attend. The meeting will still be valuable for synchronizing the work of those who can participate. When someone calls or emails to say they'll be out sick, the person can--if necessary--provide a minimal update or pose a question to the team. This would be something like, "Tell Lena I've just about finished the code she's waiting on. I just want to do a few more tests before I check it in."The Sprint Review and Retrospective
I don't recommend canceling a sprint review, and I would never cancel one because a team member was out sick. I have, however, canceled a few sprint reviews that were being given to a client on a contract development project when the key client stakeholder could not participate.
I'd prefer to proceed with only the other stakeholders present. But sometimes the client prefers not to. That mostly happens when one client participant is the boss and that's who cannot attend. The review could proceed with just the other stakeholders. But if they're going to say things like, "We should hold off on that decision until Martin can be here," I think it's OK to reschedule the review as long as that isn't a regular occurrence.
I would also never reschedule a sprint retrospective. Those who are able to participate should proceed as planned.Product Backlog Refinement
Product backlog refinement meetings can be rescheduled if necessary. Since these don't occur on the first or last day of a sprint, they're much easier to move. I would avoid rescheduling this (or any meeting) very often because any rescheduled meeting can feel like an interruption. But, if the product owner or any other truly necessary participant will be out sick, a backlog refinement meeting is OK to reschedule.Sprint Planning Meeting
In general, I would not reschedule a sprint planning meeting because someone is sick. If the person is truly the superstar of the team and we absolutely cannot plan a sprint without that person, go ahead and re-schedule the meeting for the next day. But then spend the rest of the day in an impromptu retrospective discussing how to get out of the problem of being so dependent on one person that the team cannot even plan (let alone, do) its work.
Even if it is the product owner who cannot participate in the sprint planning meeting, a team should be able to plan one sprint without their product owner. If a team does everything I advocate (such as story-writing workshops, product backlog refinement, estimating to gain shared understanding of a product backlog item and so on), the team will have a good understanding of each product backlog item by the time it comes into a sprint.
Sure, they will usually have a few questions left for a product owner to answer during sprint planning. But the team will largely understand what needs to be done to deliver the highest priority product backlog items. And so, they can plan a sprint even without the product owner.
As a precaution, the team might opt to plan the sprint a bit less full than normal. That leaves room for items to take a bit more effort if needed when the product owner returns and clarifies the last few open issues. Or it allows a product owner to add a user story or two when they return to work. Either approach allows sprint planning to proceed and to be fine-tuned when the product owner is available.What Do You Think?
Would you ever cancel one of Scrum’s standard meetings? Under what circumstances? Please share your thoughts in the discussion below.
Looking for more information on handling Scrum meetings?
Sign-up for Mike's weekly tips and also receive his PDF "Guide to Handling Absences from Scrum Meetings.”