They list these reasons:
- Fear of failure
- Fixed mindset
- Over reliance on past performance
- Attribution bias
Who else has studied organization failure? Well I've heard that many academics have studied the failure modes of organizations. One was John Kotter's 8 Steps model developed by studying the failure modes of organizations trying to institute large scale changes. Other's have studied how successful large mergers have been after the fact (some would suggest it's on the order of 20% successful). Some have studied how successful large software development project have been (Chaos Report - it is not a good report).
So what does your leader do to encourage learning at the organizational level? Is failure even allowed in your department? If so then it will be discussed and talked about in formal settings and acknowledged by leaders, rather than only around the dark stairways and in hushed tones.
Leader's drive FEAR out of the room!
Pitfalls of Agile Transformations by Mary Poppendieck
Knut Haanaes - Two reasons companies fail - TED Talk AND how to avoid them: Exploration and Exploitation
4 Questions Smart Leaders Always Ask Employees to Improve Their Performance
They're also great for fostering open dialog and developing meaningful work relationships.
End of nations: Is there an alternative to countries? Nation states cause some of our biggest problems, from civil war to climate inaction. Science suggests there are better ways to run a planet.
Welcome back! We’ve got 9 more tips to help you navigate GitKraken more efficiently.
- Switch between dark and light themes in UI Preferences. We gave the light theme some love in v2.0!
- When viewing file history, select a commit to view its diff then click the commit SHA to jump to that commit in the graph.
- Use keyboard shortcuts to quickly stage S or unstage U selected files in the right panel.
- Shortcut cmd/ctrl + \ will minimize or expand the left panel to make room for larger commit graphs.
- Quickly zoom in/out of GitKraken with cmd/ctrl + +/-. Reset to 100% with cmd/ctrl + 0.
- Remotes can be fetched individually from the left panel – no need to fetch them all!
- Check out a branch 4 ways: 1. double click in the left panel 2. in the graph 3. in the toolbar dropdown 4. in the command palette cmd/ctrl + shift + p.
- Organize branches into folders in the left panel by naming them with a slash between the folder and branch name.
- With the left panel collapsed, switch repos or branches quickly from the toolbar, the fuzzy finder cmd/ctrl + p or the command palette cmd/ctrl + shift + p
The legendary swordsman, Miyamoto Musashi, understood the Lean/Agile mindset perfectly 400 years ago.
Here is an excerpt from Musashi’s Book of Five Rings. Two translations are given, as each brings out different nuances of the original text.
Translation by Victor Harris. This translation is commonly available as a free download from many online sources, most of which do not credit the translator.The gaze should be large and broad. This is the twofold gaze “Perception and Sight”. Perception is strong and sight weak. In strategy it is important to see distant things as if they were close and to take a distanced view of close things. It is important in strategy to know the enemy’s sword and not to be distracted by insignificant movements of his sword.
It is necessary in strategy to be able to look to both sides without moving the eyeballs. You cannot master this ability quickly. Learn what is written here; use this gaze in everyday life and do not vary it whatever happens.
Translation by Hidy Ochiai. I find this translation to be clearer, although in this case the translator does not explain the meaning of kan and ken (perception vs. sight). It’s published in the book, A Way to Victory: The Annotated Book of Five Rings.Your eyes should be able to focus on a large and wide area. There are two kinds of seeing: kan and ken, the former being the most important and the latter less essential. In martial strategy it is crucial that you be able to keenly see objects at a great distance and that objects in close proximity be viewed with a broader perspective. In a combat situation, you must see your opponent’s sword in the context of his strategy as a whole rather than observing each physical movement.
It is important to be able to see on both sides of yourself without moving your eyes. You will not be able to do this suddenly in an emergency situation. You must try to cultivate this method of seeing in everyday life and maintain the same type of eye focus at all times.
The spirit of this advice is consistent with the saying, “Think globally and act locally.” We should apply craftsmanship and precision to each little thing we do, but without losing sight of the larger context in which the thing exists. This may be harder to do than it sounds. Most people I meet tend to be big picture thinkers or detail-oriented “do-ers,” and few are comfortable with both perspectives simultaneously.
In Ochiai’s analysis of Musashi, he notes:Ordinarily one imagines that one’s mind-set when having a cup of tea is different from one’s mind-set in combat. Not according to Musashi. He feels that when one trains and disciplines the self physically and mentally according to the Way, the mind becomes calm and stable at all times, not preoccupied with any preconception or prejudice. This state of mind, which is attained after serious and hard training, Musashi calls heijo-shin. It is not the mental attitude of an ordinary person but of one who has gone through extraordinary training and self-discipline. The everyday mind of an ordinary person is not called heijo-shin, for it is not based on the true inner strength that can be attained only through a hard and authentic training.
I see many connections here. Connections with behaviors that I observe in the field. Connections with LeadingAgile’s pragmatic approach to organizational transformation. Connections to the mountain-climbing or “expedition” metaphor for driving organizational improvement.
The common element in these connections is expressed nicely by Musashi’s description of the warrior’s gaze. It comes down to a holistic perception of the small and the large, the near and the far, the immediate and the deferred, and the ability to maintain consistent focus on what is significant on all those axes.
Behaviors I observe in the field suggest this mindset is not so easy to cultivate. Tell-tale questions include:
- “Whose job is it to refine the backlog?”
- “As we combine technical job functions, who will test my code?”
- “Why should I consider security issues in my design if they aren’t explicitly mentioned in the User Story?”
- “How can we convince business stakeholders to give us permission to refactor our code?”
- “If we’re tracking delivery performance by team, how do we assess individual performance?”
Questions such as these suggest the person sees but does not perceive; they see rules, and do not perceive meaning. They have not cultivated heijo-shin.
In all these cases, and countless others, people are considering one specific job-related task in isolation from its larger context, and they are hoping to find a recipe to dictate what they must do in every situation that may arise. The “task” may be of relatively large scope—something the CTO does, or something a Portfolio-level team does—or of relatively small scope—something an individual programmer or tester does—but there is always a single, overarching organizational context, and it is within that context that people make judgments about what to do from one minute to the next throughout the day. It isn’t a question of rules, although you might benefit from a few rules initially to help you find the path forward.
Such questions would not occur to a person who had cultivated heijo-shin. They would perceive the whole and do the right thing in context naturally, without strain. But cultivating heijo-shin is a challenge that requires mindful practice. Musashi is clear on this point: Reading isn’t enough; you must apply the ideas. Whatever you practice every day is what you will do when the heat is on. Therefore, it’s important to practice the right things. How does one know what to practice? With guidance and a compass, you can find the right path.
LeadingAgile’s approach takes into account three levels of abstraction in the organization, which we call Portfolio, Program, and Delivery Team. Each has its own broad set of responsibilities and scope of work, but all are part of a single cohesive whole. One can view this as an example of Musashi’s notion of perceiving the near and the far in a spatial sense. What we do at the Delivery Team level is part of what we are doing at the Program and Portfolio levels. What we do at the Portfolio or Program level must be done in a way that doesn’t impede Delivery Teams. Each task must be done with high quality but does not exist in isolation.
The LeadingAgile roadmap, which is based on the expedition metaphor, comprises five Basecamps. These represent milestones of improvement. One can view this as an example of Musashi’s notion of perceiving the near and the far in a temporal sense. What we do on the journey from Basecamp 1 to Basecamp 2 will set us up for reaching Basecamp 3 in the future, and Basecamp 4 after that. Each Basecamp is a milestone but not an end state. The real end state is that people no longer think in terms of an “end state” at all, and instead they practice continual improvement as a habit.
We finally did it! A new release for our iOS app is now available in the App Store.Entity view
We’ve changed the way that entity details views are displayed on Apple devices. These views are now much better adjusted to iPhone and iPad screens, so it’s much more convenient to use Targetprocess on your phone or tablet:
- The ability to open links from Description and Comments
- A "share" action for Attachments
- A progress bar for Release, Iteration, Team Iteration, and Project entity views
- A state selector for Projects
- Multiple teams selector on entity details views.
- Projects list on Release views
If you have anything you want to share with us, use the Feedback form in the app's 'Me' tab, or shoot us a message at firstname.lastname@example.org.
Click here to download the iOS app.
I’ve been with Axosoft for almost two years now, and when I started, GitKraken, the company’s Git GUI, was so new it was still in private beta. Working for the marketing team, primarily on web projects, I needed to work collaboratively and use Git on a daily basis.
I had worked with Git before, but prior to Axosoft, I was a web team of one, meaning I rarely, if ever, had to collaborate with other developers on projects. As such, the extent of my Git knowledge was git status, git commit, and, when feeling saucy:
git commit -a -m 'look at me condensing my actions into one command like a big boy.'
It’s timely that as I write this, I’ve just finished reading a blog article by Avdi Grimm (that references GitKraken, as it happens), in which he makes a point I had never really considered:One of the difficult, and at times disheartening lessons I’ve learned over the years is that there is a fine line in software between skills that actually increase your leverage, versus the ones which just make you feel smarter.Avdi Grimm, Having the appearance of good design
Git from the command line, for me, achieves the latter; when using the CLI for Git, I could perform simple commands that made me feel like I was doing something powerful, and maybe I was doing something powerful, but the truth is, I didn’t really know what I was doing. I understood some basics, but I did not, at all, have a sound conceptual grasp of anything outside of those simple commands. Reading up on Git piqued my interest enough to dive further in, but I hit a roadblock, and it started to feel unlearnable.
When I started with Axosoft, we were asked to use GitKraken because a) Axosoft believes in the product and in how strongly it performs (and did even in those early stages of the app’s development); and b) Axosoft wanted devs across the company to put the app through its paces and identify bugs, UX issues, etc.
So, I used GitKraken, and I used Git—truly collaboratively—for the first time. And I started to not only get used to performing tasks quickly, but to actually start making sense of how those tasks were working. Processes were simpler, I was far more productive, and I finally had a visual representation of Git that I felt I could understand.Merging vs Rebasing
A good example of this, and one of my most satisfying ‘ah-ha!’ moments, is with merging and rebasing. Merging is a pretty straightforward concept to understand: you take a branch, merge into another branch, and that target branch now has the changes of both. What I didn’t understand until I could actually see the process, was that this is facilitated by a merge commit. To understand why this is useful in a collaborative environment, it’s probably best to explain with an example.
In the example setup below, I have a branch and I have master. This setup exemplifies a common situation: I have branched off master, made some changes, but have not finished working on the branch. Meanwhile, master has changed, and those changes are ones I’d find useful to have in my branch.
I have two options: I can merge master into branch-from-master, or I can rebase branch-from-master onto master. The former is entirely non-destructive and leaves a footprint of the process:
However, it’s easy to see how keeping things clean could become difficult when applying this method frequently, while lots of updates are happening around you. In order to avoid this potential conceptual spaghetti of merge commits, a friend recommended I rebase instead.
Whoa! I can actually see the difference, and it makes sense! The changes in master have been slotted into branch-from-master, as if my changes in that branch, and in master, were conducted on my one branch. master still has its commits intact, but it’s as if those commits were conducted on both branches at the same time.
Although this loses the footprint of merging, it keeps everyone’s repos looking clean, with histories that are easier to traverse and interpret. We have literally rewritten the commit history.
This is why, when it’s time to push my branch, it tells me I’m behind the remote. I could see how I had rewritten the history of that branch, so I could understand why a force push to my remote was acceptable under these circumstances. I want to reflect the history revision there, too, so I have to get just a little destructive. However, I can now also understand why there is the Golden Rule of Rebasing.
Using GitKraken has provided me with a visual way to learn some Git fundamentals that have made me more competent and confident with using Git collaboratively. Using a GUI for Git has allowed me to take the step from knowing how and when to do something, to knowing why and what it’s actually doing.
Subject: Re: Congratulations on your REI World MasterCard anniversary! Thank you Robert,
Just to let you know - I’m sure this will interest you - I will shortly be canceling my 10 year relationship with REI MasterCard, because of the quality of service you have just required me to deal with. I’ve got a great payment history and have been using our card to pay bills on line and automagically for years. Recently through my oversight, I forgot to pay my bill on time. So in response to this great customer who always pays his bills and once in 10 years paid late, your organization saw fit to block all payments, causing further confusion and customer / client dissections with your service level. When I called in to rectify the situation your senior rep. could not do anything to help - your policy prevented customer satisfaction. Said policy created even more denied automatic payments for my accounts, creating a snowball of unpaid bills. All from a company that is in the business of extending credit. This is unacceptable. So I will be canceling my relationship and moving to VISA. David Koontz, very unhappy customer.Here is the response I received from the Office of the President, US BANK Cardmember Service
One technique for losing customers is to make the very nature of your core business proposition an oxymoronic meme. Let's use this US Bank - REI Credit Card issue as a case study.
The back story: I've been a REI Credit Card user for around 10 years, I've built up a very good customer relationship, paying bills on time for those year, sure there may have been a slip through the cracks from time to time, yet my credit score reflects that I'm a very sound risk for credit.
So when a job transition happened in the sprint of 2016 there was much confusion with cash flow and various credit cards transition from one service vendor to another (seems as if Master Card is losing clients to VISA) and Costco moved away from Am Ex. Lots of changes in the card industry. These had various impacts upon my personal fincianal life...
Some few years ago I started moving auto pay bills to my REI card (US BANK) we loved the cash back rewards at one of our favorite shopping stores, REI. So by 2016 almost every bill I get, from water bills to Amazon to Apple App Store to Netflix etc. is on the card.
Now in March, I missed the $30 min. payment to US BANK. So in silence they blocked all debits and transaction to the card. There was no communication to me about such a significant event. However, I get plenty of alerts of various natures, such as payment due, minimal balances, large transactions, etc. But, for unknown reasons explained by the Office of the President, they are just unable to communicate with customers about this type of event.
I've canceled the card. Kinda hate to lose the REI relationship, but they have not responded to any inquiries either. In today's credit industry there are plenty of reward programs to choose from and I've made other arrangements - did all the work to transition payments away from US BANK's card to a USAA Signature card. Maybe I'll probe that system and see how they respond to a missed payment.
So what would US BANK needed to have done to keep a 10 year customer? A simple alert - your account has been frozen because of late payment. AND then been able to recognize a good customer and rectify the issue over the phone - by extending credit and reinstating the account with the promise of the check is in the mail. After all their core business proposition is extending credit.
Full Disclosure: I own MasterCard stock as well as Amazon, Apple, Costco, Netflix.
I learned this technique from the facilitators of Language Hunting and Where Are Your Keys, they term the technique How Fascinating and practice it quite a few times each game.
The purpose of the technique is to invert the physiology of failure into a learning moment to reflect upon what just went wrong and instead of cringing and curling up into a safe ball, we open up the body and the mind to learning and the experience of reflecting and allowing the universe to teach us something.
Try it a few times...
The Failure bow -DeepFUN by Matt Smith
Go Ahead, Take a Failure Bow by Beth Kanter at HBR
TED Talk: The unexpected benefit of celebrating failure
"Great dreams aren't just visions," says Astro Teller, "They're visions coupled to strategies for making them real." The head of X (formerly Google X), Teller takes us inside the "moonshot factory," as it's called, where his team seeks to solve the world's biggest problems through experimental projects like balloon-powered Internet and wind turbines that sail through the air. Find out X's secret to creating an organization where people feel comfortable working on big, risky projects and exploring audacious ideas.
As an immigrant from Iran, and an American citizen who has lived in the U.S. for more than 33 years, I was disheartened to see President Trump’s executive order to ban certain immigrants from entering the country; especially those who have legally obtained Visas or legally gained permanent residency (although they later reversed this decision).
I believe that America’s greatness comes from its diversity and the power of individual citizens to speak up without fear of persecution. At Axosoft, we embrace diversity. We don’t run from it. We think it’s a fundamental key to success, which is a point I made sure to reiterate in an all employee letter.
Because diversity is foundational to who we are and the culture we’ve created at Axosoft, we knew we had to do something in light of the injustice caused by the President’s executive order. We also knew we couldn’t be the only ones who wanted to fight back.
That’s how we found the American Civil Liberties Union (ACLU), who has already stepped up and is fighting to correct this wrong. After researching more about the ACLU, I learned that they have been defending and preserving the rights and liberties of Americans for nearly 100 years. During this time when our rights are frequently being challenged, I was relieved to find this organization.Tweet this!
So, to show our support, Axosoft will be donating 100% of GitKraken Pro revenues to the ACLU, for the next 3 days (from Wednesday, February 1st, to Friday, February 3rd). Whether you are buying 1 GitKraken Pro license or 100 licenses, the revenues will go directly to the ACLU. You don’t need to do anything special to make this happen.
We will post updates about the progress on our Twitter account in the coming days.Read this follow-up article to find out how much we donated to the ACLU!
I had a conversation with Amitai Schleier last year. I told him how much I enjoyed Agile in 3 Minutes (the podcast). I learned something from each podcast.
He invited me to contribute one. Naturally, I chose management. My podcast, 34: Manage is up. If you like the podcast, you should check out the book, too. See
If you like the podcast, you should check out the book, too. See Agile in Three Minutes. In three minutes, I explain what agile managers do.
Teams can be agile, up to a point. If the managers are not ready to nurture the agile culture, agile won’t work. (See When is Agile Wrong for You?)
I hope you enjoy it the podcast and the book.
I recently spoke at a corporate community of practice event. My session presented a useful model to identify indicators within a system to predict its failure. First, we started by applying the model to everyday systems everyone could relate to. Next, I asked the attendees to map a system of their own. As I walked them through my model step by step, I used Scrum as my example system. Upon completion of the worksheet (see my completed sheet below), attendees were able to see if there were any “gaps” in their systems. The gaps provided an indication that a respective system was at risk of failure.
To clarify, on a delivery team level, I see the Scrum Framework as a solid method for managing product development. But what about Scrum in the context of the entire delivery organization? Using both The Three Things You Need To Know To Transform Any Sized Organization and my model, I look at Scrum in a broader context. With that, I note 5 major gaps.
What are the 5 gaps in Scrum?
My model will segment any system into 5 areas: Clarity, Commitment, Ritual, Progress, and Habit. The gaps that I will note below are those things not mentioned in the Scrum Guide.Gap 1: Clarity
What does the structure of the organization look like (Portfolio, Program, Product) above the Scrum Team? We need a shared understanding. What does the governance of the organization look like (Budget, Dependencies, Risks, Quality,…) above the Scrum Team? What are necessary metrics and tools of the organization above the Scrum Team? Some organizations are very large and heavily distributed. How will you measure the health of the entire delivery system?Gap 2: Commitment
In Mike‘s 3-things talk, he calls this accountability. Given the broad applicability of my model, I prefer to call it commitment. Commitment can be any resource. So, what money and time may be required for Scrum training of all leadership and Scrum teams within an enterprise? What money and time may be required for procurement, installation and training of tooling used to manage and report on the health of the delivery system? Lastly, we need agreement from the Leadership team to follow the Scrum Framework (or more particularly respect that the Scrum team is following it).Gap 3: Progress
As I noted in my post on Productivity Patterns, if you lack progress, you lose momentum. If you lose momentum (or should I be so bold to say velocity or throughput), you will lose commitment to the system. Those who are funding the efforts (those outside the Scrum team) need to know progress is being made in a way that is important to them. What is the Time to Value? Is the Scrum team predictable on a release level (Release Burndown/Burnup chart)? Are we even building the right things? (Product Fit) Are we building things right? (Quality)Gap 4: Rituals
Rituals can be event or meetings, as part of your system of delivery. First, let’s start with product vision. Scrum teams have a horizon of a few weeks (the sprint). Vision is viewed or realized in months, quarters, or years. Read the Scrum Guide and you won’t see Vision mentioned once. Also absent from the Scrum Guide is the notion of portfolio or release planning. Unless you have a delivery capability that allows you to release at the end of every sprint, I can’t champion release planning enough. In addition to that, good portfolio planning ensures we have a balanced system of delivery and ensures we have capacity to make commitments against a roadmap.Gap 5: Habit
Given the rituals I outlined above, you should make it a habit to have periodic Vision Reviews, regularly scheduled Portfolio Planning/Reviews, and ensure you’re consistently doing your Release Planning.Conclusion
I’m not suggesting you abandon Scrum. But after you look at the highlighted gaps I listed above, in a system of delivery larger than a single Scrum team, you should consider more than what is in the Scrum Guide.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
The most discernible activity during a sprint review is a demonstration of the functionality built during the sprint. But, a good sprint review includes more than just a demo. Let’s take a look at an agenda for the review.Welcome Participants & Set the Stage for the Sprint Review
The product owner starts by welcoming everyone to the sprint review. This can be as simple as saying, “Thank you for being here.”
If participants are unfamiliar with one another, the product owner may have attendees briefly introduce themselves. Introductions are generally a good idea at the start of a new product development initiative. The product owner knows that Joe from Marketing is Joe from Marketing but team members may not.
Introductions are also helpful if it is common for an occasional new participant to attend sprint reviews. Perhaps Joe from Marketing will only attend two reviews following the sprints in which the team worked on marketing-related features.
Introductions should be kept extremely short. “Hi, I’m Mike and I’m a developer. I’ve been working on the shopping cart features,” is plenty. In some cases, “I’m Mike and I’m a developer,” would be enough. But once a team reaches a certain size, it can be helpful for stakeholders to hear a few words to let them know who has been doing what.
After an initial welcome by the product owner and any needed introductions, the product owner can share any ground rules or expectations for the sprint review. For example, some product owners find it necessary to state the need to keep the meeting civil. If someone doesn’t like how a feature was implemented it’s fine to say so, but don’t call the implementation “stupid” or so on. Yes, we all should know things like this anyway, but sometimes people need to be reminded.
Depending on the number of attendees and many other factors, a product owner might also state that while she is looking for feedback on what was built, the sprint review itself will not be the time to redesign features.
With the welcome message, introductions, and ground rules out of the way, it’s time to move onto the next item on the agenda.State What Will (and Will Not) Be Demonstrated
At this point, many teams dive right in and start demonstrating. Instead, I recommend the product owner present a very brief overview of what will be demonstrated and what will not be.
To avoid a product owner just reading a list of items that participants won’t be able to follow, display something on the monitor or projector being used. Or have printed copies available for those who want one.
I like to prepare this as a Word document and email it to likely review participants at the end of the day before the review. This allows people a chance to see what will be demonstrated. Each person can then intelligently decide whether to attend or not based on what will be shown.
The following table shows the information I like to include for each product backlog item. I recommend putting this list in the order in which items will be demonstrated, although you can change that on the fly as needed during the meeting.
Description SIZE STATUS DEMO As a user, I .... 5 Finished
YesAs a user, I .... 3
Finished but there’s more we could add to the such-and-such part of this.Yes As a user, I .... 5 We started but there were too many open issues No Bug fix: Update the copyright notice on the About screen 0 Finished No ADDED: As a … 3 We brought this item in when we dropped the item above. Yes
The table starts with a description of the item. Put the user story or other description here. Next include the size of the item, usually this will be in story points. Then list the status of the item. Mostly this is whether the item was finished or not, but include anything else that is important to note. Finally, include a column indicating whether the item will be demonstrated or not.
You may wonder why we’d ever have items that the team would not demonstrate. I’ve provided a couple of examples in the sample table. Obviously, the item that was planned into the sprint but dropped cannot be demonstrated. I’ve also shown a simple bug fix that updates one character on one screen--it is not scheduled for demonstration either.
It’s quite possible that one or more participants might ask to see an item that you had not planned to show. When that happens, go ahead and demonstrate the item along with all others. You’re not trying to avoid showing something, you’re just trying to be respectful of people’s time by not showing them things that don’t really need feedback.
Notice in the sample above, I indicated that one product backlog item was added during the sprint. I think it’s a good idea to indicate items added during the sprint so they can be distinguished from those that were planned into the sprint. If adding items happens frequently, consider adding an initial column and putting P (for Planned) or A (for Added) in it.
You might also want to consider a column at the far right that can be used to indicate whether each item is accepted by the review participants or ready to release or such. Do this if those types of decisions are formally made as part of a sprint review.
Avoid spending too much time on this part of the agenda. The goal here is not to get feedback on the items or to talk about why a planned item was only partially implemented. This is merely a table of contents into the rest of the meeting. After the product owner has presented this list, move onto the main part of the sprint review: the demo itself.Demo New Functionality
This is the heart of the sprint review. And if you’re already doing sprint reviews, it’s quite possible this is the only part of the agenda you’re doing.
During this portion of the review, proceed down the list of items you’ve previously shown meeting participants. Keep in mind that the purpose of the sprint review is to solicit feedback.
There is no hard rule about who gives the demo. In some cases, a product owner will operate the keyboard. I’d recommend doing that in a review with particularly challenging stakeholders. Other times, though, team members will demonstrate the specific product backlog items they worked on. Just about any approach works fine. So experiment to find the one that works best for your team.Discuss Key Occurrences
After all completed product backlog items have been demonstrated, discuss key events or problems that occurred during the sprint.
This discussion could be facilitated by either the product owner or Scrum Master. I’ve found both approaches to work equally well. I do, however, have a slight bias toward having the Scrum Master conduct this part of the meeting.
Up until now, in most sprint reviews the product owner will have done a lot more talking than the Scrum Master. So I find it a good balance to have the Scrum Master facilitate this agenda item. Plus, this is often more a discussion of the process than strictly the product, and so it falls a bit more in the domain of the Scrum Master.Present Upcoming Product Backlog Items
The final item on a sprint review agenda should be a discussion of the next work on the product backlog. Because the purpose of the sprint review is to acquire feedback on the work of the current sprint, this will often influence what will be worked on in subsequent sprints.
If, for example, participants in the review liked the look of the new screens, the product owner may want to accelerate moving other parts of the product to the new design. Or, if participants didn’t like how a feature was implemented, perhaps the next sprint should be spent fixing issues with it instead of moving onto the next items, as might have happened without a sprint review.
The product owner starts this discussion by presenting the next set of potential items from the product backlog. The product owner might say something like, “On the screen, you’ll see what I thought would be our next ten things to work on, but I want to insert such-and-such that came up today. I’ll add that probably as item three.”
The product owner then solicits comments from participants about the proposed next set of items. I do not, however, recommend that the product owner make any prioritization decisions during the sprint review based on these comments. The reasons for this are many. The product owner may need time to think about what was said in the review. Or the product owner may want to get estimates from the team about changes that were requested in the review. And so on. Instead, the product owner solicits opinions during the sprint review and then makes decisions after the meeting.Conclude the Meeting
Simply wrap up by thanking everyone for participating. Consider thanking the team in whole for the work of the sprint. Consider occasionally praising a team member or two who performed exceptionally well during the sprint. Remind everyone when and where the next review will be held.After the Sprint Review
Although not part of the agenda for the actual review, someone should enter any new product backlog items into whatever tool the team is using (or post them on the wall if using physical cards).How Do You Conduct Reviews?
Please let me know how you do your sprint reviews. Do you include anything I didn’t mention? Do you skip some of these steps? Please share your thoughts in the comments below.
Get Your Free Sprint Review Agenda Poster
I once used a hammer and it didn’t work. Therefore, people should never use hammers.
If you find that reasoning satisfactory, then you may also appreciate the following statements:
- We tried pair programming and it didn’t work.
- We tried test-driven development and it didn’t work.
- We tried Scrum and it didn’t work.
- We tried User Stories and they didn’t work.
- We tried Personas and they didn’t work.
- We tried Specification by Example and it didn’t work.
- We tried continuous delivery and it didn’t work.
- We tried baseball and it didn’t work.
There is a notion of logical validity. An argument may be logically valid even it if is untrue or unprovable. Validity is a question of structure. The following structure and example are taken from the Rational Wiki page about logical validity.
- If X then Y
- Therefore, Y
And the example:
- If there is creation there must be a creator.
- There is creation.
- Therefore, there is a creator.
So, is there a creator? Maybe. We can’t tell just by looking at the sample argument. We can tell that the argument is structurally valid.
Logical validity is prerequisite for an argument to be considered logically sound. To be sound, an argument must be valid; but a valid argument is not necessarily sound.
With that background, what do you think of the opening assertion of this post? “I once used a hammer and it didn’t work. Therefore, people should never use hammers.”
I think the argument is logically valid:
- If hammers don’t work, then people shouldn’t use them.
- Hammers don’t work.
- Therefore, people shouldn’t use them.
But I question the logical soundness of the argument. The part of the statement that stands out for me is the phrase “it didn’t work.” What is the definition of “it works?”
My first impulse is to consider the possibility that the hammer did not function properly as a hammer. This could occur due to a fault in the design or manufacture of the hammer. Even so, such a fault would not condemn all hammers categorically. By this definition, as long as a hammer does what hammers normally do, then it “works.”
If we assume the hammer did what hammers normally do, then what might the speaker have meant by saying “it didn’t work?”
Most likely, they meant they did not achieve the result they expected or wanted when they used the hammer. That may be so, but is it reasonable to conclude from that experience that hammers are categorically useless?
A hammer is a kind of tool. A tool is something that aids in accomplishing a task. Hammers are designed to aid people in accomplishing the task of driving nails.
If “it didn’t work” means “I didn’t accomplish my task,” then is the tool to blame? Setting aside faults in design or manufacture, we can assume a hammer always does that which hammers are designed to do: They apply blunt force to a target. We can further assume that a hammer has no goals, hopes, fears, intentions, or ulterior motives. It just strikes whatever you swing it at, whether or not you’ve selected an appropriate target and whether or not you’ve swung the hammer with skill. To say that a hammer “didn’t work” is meaningless.
One can also consider the following to be tools, in the sense they are things that aid in accomplishing tasks:
- pair programming
- test-driven development
- User Stories
- Specification by Example
- continuous delivery
If we want a tool to help us accomplish a task, it seems to me we need to follow a two-step process:
- Choose the right tool for the job
- Use the tool properly
Otherwise, it won’t “work.”
At Syncfusion, we’ve been developing controls and frameworks for software developers since 2001. Over time, as our product line has expanded—emerging from our first grid control to more than 800 different controls across a variety of platforms—our release management process has become increasingly complex. Fortunately, Git came along and made everything easier.
Git is an open source distributed version control system that is flexible and easy to use for all kinds of teams, no matter how big or small. To adopt Git in everyday development, a model called GitFlow was introduced by Vincent Driessen to help simplify development and release management. This article assumes that you have some prior knowledge of Git and its basic terminologies. It aims to further describe Vincent Driessen’s branching model and how his GitFlow extension can be useful in a release management workflow for enterprises.
You can also check out this video, which explains how GitFlow works in GitKraken:Workflow Model
GitFlow utilizes the core feature of Git, which is the power of branches. In this model, a repository has two main branches:
- Master—This is a highly stable branch that is always production-ready and contains the last release version of source code in production.
- Develop—Derived from the master branch, the development branch serves as a branch for integrating different features planned for an upcoming release. This branch may or may not be as stable as the master branch. It is where developers collaborate and merge feature branches.
Apart from those two primary branches, there are other branches in the workflow:
- Feature—This derives from the develop branch and is used to develop features.
- Release—This also derives from develop branch but is used during releases.
- Hotfix—This derives from the master branch and is used to fix a bug in the production branch that was identified after a release.
We will discuss these branches in detail along with the GitFlow extension used to simplify the management of these branches. The commands we use for the GitFlow extension are based on the Windows environment, but other platforms have similar commands. You can check out the GitFlow wiki for complete details regarding supported commands.Installing a GitFlow Extension
The following simplified steps will get you up and running on Windows, although GitHub also hosts installation instructions for different platforms.
- Download and install Git for Windows. By default, it will install in this directory: C:\Program Files\Git.
- Next, you need to retrieve three files: exe from the util-linux package, libintl3.dll, and libiconv2.dll from the dependencies packages (libintl and libiconv). (For ease of installation, we gathered and uploaded all these files to http://www.syncfusion.com/downloads/support/directtrac/general/ze/dependencies142480694.zip.)
- Once you have those three files, copy and paste them to the location where Git is installed in your system (i.e. inside a bin folder at C:\Program Files\Git\bin).
- Next, clone or download this repository: https://github.com/nvie/gitflow.
- When done, navigate to the folder named “contrib” (gitflow-develop\contrib).
- Open the command prompt in that directory in administration mode and type this command: msysgit-install.cmd "C:\Program Files\Git".
- GitFlow will be installed and configured in your system and ready to use. You can test it by typing git flow help in the command prompt.
When starting a project, you won’t have any code files. No problem, just create a Git repository with an empty directory. When finished, you can clone your repository in your system. In this example, we are using a sample GitHub repository, but the procedure applies for any Git repository.
- Clone the branch in your system using the Windows command prompt:
git clone https://github.com/bharatdwarkani/gitflow-example.git
- Switch to the following directory:
- Initialize GitFlow in this repository:
git flow init
You will receive a message stating that no branches exist and prompting you to use common branch names. If you don’t want to change the default branch names, press enter to proceed. When finished, you will have a GitFlow extension initialized in your repository.Note: This process has to be done by every developer for any repository they clone in a system. It is not limited to new repositories; it can be used for existing repositories too. Master and develop branches
The master and develop branches form the base of any repository in Git. The master branch contains a version of the code that is in production, and the develop branch contains a version that is due to be released in an upcoming version. Execute the following commands in the command prompt to check out the master branch in your system.
git checkout master git push -u origin master
You will be prompted for username and password; enter them to proceed. Next, you will need to push the develop branch to a remote repository (i.e. from your system to sync with GitHub). Since the develop branch is only on your local machine, it has to be moved to a remote repository by executing the following commands.
git checkout develop git push origin develop
Now you have a repository containing master and develop branches copied from your local machine. This is required only when you first start a project from scratch; otherwise, you could work with one of the following branches.Feature branch
The feature branch splits from the develop branch and merges back to the develop branch after a feature is complete. The conventional naming of this branch starts with feature/*. This branch is mostly created and used by developers collaborating with teams. The purpose of the feature branch is to develop small modules of a feature in a project.
You might wonder why developers can’t work directly from the develop branch. Why do they need to branch off to a feature branch? To explain this, consider a scenario where you are developing a feature and management decides to drop that feature, as it is no longer required or there is less feasibility of implementing it.
At that time, if you are working in the develop branch directly, it would create a lot of conflicts and possibly break the existing code. Also, to do this you would need to manually delete or comment out code.
Instead, if you branched off a separate feature branch, you could silently discard and delete that branch without affecting the develop branch. Not only does this help develop features, which require the trial-and-error technique, but by using a separate branch you also get an extra level of stability in the develop branch because code from the feature branch undergoes several levels of code reviews and quality assessment before merging into the develop branch.
The lifetime of a feature branch ends once it merges with the develop branch. If multiple developers or teams are working on the same feature, it’s easier for them to collaborate by working on a common feature branch.
The following steps show how a feature branch can be created and published using the GitFlow extension from a Windows command prompt.
- To clone a repository:
git clone https://github.com/bharatdwarkani/gitflow-example.git cd gitflow-example git checkout develop git flow init
- To start a feature branch (the name of the feature branch will be the name of the feature; we are using feature1 in this example).
git flow feature start feature1
After execution, the feature1 branch is created, but it exists only on your system and will not be available in the remote GitHub repository. Now you can continue with your development, adding files and modifying the code. When you’re done with the feature, you can commit it to your local system and later push it to the remote repository.
- Once done, the status of the changes can be checked for newly added or modified files.
git status git add . git commit -am "Your message"
- The following commands publish the feature to the remote repository.
git flow publish feature1 git push
If you check in the remote repository, a branch with the name feature/feature1 will be created.Note: In the command prompt, the name of the branch you use is feature1, but GitFlow adds a naming prefix automatically (feature/branch) as a convention. When specifying a branch name in Git commands, you need to use the full branch name (feature/feature1), but in GitFlow commands the general prefix (feature/) need not be specified.
- Once a feature is complete and the code has been reviewed, you can complete your work in a branch by issuing the command below. Upon execution, the code will be merged to the development branch automatically and the feature branch will be deleted from the remote repository.
git flow finish feature1
- If you need to delete a branch, you can execute: git branch -d feature/feature1
git flow feature track feature1 instead of git flow feature start feature1
Apart from this, there is one more branch called bugfix. It has a workflow similar to the feature branch, but it is used to fix a bug.Release branch
The release branch derives from the develop branch and merges back into the develop and master branches after completion of a release. By convention, the naming of this branch starts with release/*. This branch is created and used when features are completed and finalized for a versioned release.
Why can’t we directly release from the develop branch? Because the sole purpose of the release branch is to isolate a version of a release that is final but needs some quality assistance and stability from the upcoming version. If we branch off from the release branch, then other developers who are assigned to develop features for an upcoming release and are not involved in the release stability process can continue to development and merge their features into the develop branch without waiting on or affecting the current release process. The release branch helps isolate the development of an upcoming version and the current release.
The release branch’s lifetime ends when a particular version of a project is released. Once this branch merges into the develop and master branches, it can be deleted. And once you have done this, you can tag a master branch with a particular release version—let’s say v1.0—to create a historical milestone.
The following example explains how a release branch can be created and published using the GitFlow extension from the command prompt.
- Start a release branch.
git checkout develop git pull git flow release start release1
- Commit newly added or modified changes and push to the remote repository.
git add . git commit -am "Your message" git flow publish release1 git push
- Merge changes to the develop branch.
git checkout develop git merge release/release1
- After a release, merge changes to the master branch.
git checkout release/release1 git pull git flow release finish release1
git flow release finish -m "Your message" "release1" git checkout master git push --all originHotfix branch
The hotfix branch is derived from the master branch and merged back after completion to the develop and master branches. By convention, the name of this branch starts with hotfix/*. This branch is created and used after a particular version of product is released to provide critical bug fixes for the production version.
The reason we do this is because one problem you might face when branching off from the develop branch is that some of your developers would have already started work for the upcoming release while you are in the middle of the current release. Your release would contain the next version of features, which are not finalized, but you only need to provide bug fixes for the current version. Instead of branching off from develop branch, you can branch off from the master branch, as that branch contains only the current version of the code in production. This way, branching off from the master branch will not affect your production or development version of the product.
The hotfix branch can be deleted once a critical fix for the current production version is released and merged with the master and development branches. Once you have done this, you can again tag the master branch with an iterative subversion of the release; let’s say v1.1.
This example shows how the hotfix1 branch can be created and published using the GitFlow extension from a command prompt.
- Start a new hotfix branch and commit changes after modifications.
git checkout develop git flow hotfix start hotfix1 git status git add . git commit -am "Your message"
- Publish the branch to the remote repository.
git flow publish hotfix1
Merge changes to remote repository.
git flow hotfix finish hotfix1
git flow hotfix finish -m "Your message" "hotfix1" git status git checkout master git push --all origin
Note: All commands starting with “git flow” are based on the GitFlow extension. Actual Git commands don’t have flow keywords in them. They start only with “git.”
The GitFlow model helps manage and organize a release better by using GitFlow extensions. Thank you, Vincent Driessen, for proposing GitFlow and for providing an extension that helps simplify the management workflow of enterprise-level releases.
Mastering the full functionality of Git takes time, so you’ll probably benefit from books like Git Succinctly and GitHub Succinctly. Both are part of Syncfusion’s Succinctly series of e-books—an acclaimed library of short technology books designed to orient you quickly with new technologies. The series is a great resource for developers, numbering more than 100 titles—all completely free.
If you choose to fully embrace the tenants of GitFlow order, know that you can use them with Axosoft’s GitKraken, a cross-platform Git GUI built to help put Git into human terms.