Each week we share a tip on social media to help you use GitKraken like a pro. For those of you who are just getting started with our cross-platform Git client, here’s a great overview of how GitKraken works in less than 2-minutes.
Now, here’s a round-up of all the tips we’ve shared so far!GitKraken Tips
- If you want to see just the commits for a specific branch, use the soloing function.
- Use GitKraken’s fuzzy finder to quickly open a repo, checkout a branch, or view file history.
- Pull any branch, even if it isn’t checked out. Just select “Pull” in the branch actions context menu (you can also push the branch the same way).
- Resize the commit graph to optimize space for repos with many branches, even down to a single column.
- Scale the UI to your liking with ⌘ | Ctrl + +/-, the zoom selector, or the fuzzy finder.
- Forgot something in your previous commit’s message? Amend it by clicking the message in the right panel.
- Drag-and-drop one remote onto another to quickly create a PR without leaving GitKraken.
- Select multiple commits in the graph and easily squash them with 1-click. Use undo to reset if necessary.
- Use the fuzzy finder (⌘ | Ctrl + P) to quickly switch repos without leaving the keyboard.
As a coach and committed Agile Evangelist, I spend most of my time convincing the software organization that they are actually part of the business. In this role, I also help with interpretations of Software / Technical jargon to business speak. Here are 5 of my favorite IT Director phrases:
- We are going to make the date at all cost.
- Refining requirements with business partners is bureaucratic and slow.
- It is up to the Operational team to clean up the process.
- We will work with DevOps to smooth out deployments.
- This new technology will speed up delivery once we re-write everything.
Now drumroll please, here is what they mean to the rest of the business.
- We are going to make the date at all cost. Actually means you need to have funding for 2 support people for every developer on staff. It will take one to three years to make this software run smoothly. At the end of the third year, we will make the case that it is too costly to maintain and try to make the date at all cost for a replacement.
- Refining requirements with business partners is bureaucratic and slow. Actually means we in IT can write a bunch of code much faster if we don’t have to understand how you are going to use it. We will just give it to you and you can figure out how to change your processes to make it work. If you can’t make it work, we can start up a replacement project.
- It is up to the Operational team to clean up the process. While delivering at all cost we created a bunch of manual steps, such as loading data directly to the production database. These manual steps will be turned over to technical operations with knowledge transfer sessions, i.e. someone sitting with someone but nothing actually written down. Once it is in the operational team, it is up to them to figure out how to automate these manual processes as long as they do not use development time.
- We will work with DevOps to smooth out deployments. We were busy delivering at all cost and never got around to automating our deployments. We are turning over that piece of work to the Delivery Operations team to automate. We don’t have time to document the deployment procedures but they have been working with us for the last few months so they can do it.
- This new technology will speed up delivery once we re-write everything. Actually means, I found something new and cool that I want to learn and it will look good on my resume. That old stuff is hard to maintain and change. We have no idea what most of that code is doing so let’s just start from scratch. We will not be able to make any business changes to the existing software. All of our efforts will be building the new software to do what the existing software already does.
Finally, the one that the IT Director says in the hallway but never in a meeting, “I have no idea what all these operational people are doing, I wish I could get that headcount for software delivery.”
The Trello board retrospective techniques for coaches, Scrum masters, and other facilitators provides exercise and ideas to design agile retrospectives. Philip Rogers created this board, he has added me so that I can contribute my experience with retrospectives.
This interesting retrospective resource on Trello has columns with:
- “All-in-one” plans for retrospectives, descriptions of exercises that cover the five phases mentioned below.
- Futurespectives, where the focus of the conversation is not on something that has occurred in the past, but instead on what the team foresees in its future.
- Activities for the five phases from the agile retrospectives book by Esther Derby and Diana Larsen.
Retrospectives Exercises Toolbox - Design your own valuable Retrospectives
The trello board with retrospective techniques has been added to the retrospective exercises toolbox.
I’ve contributed to the board by sharing my blog posts How Futurespectives Help Teams to Reach Their Goals, Retrospective Prime Directive in many languages and What to do when safety is low in a retrospective on this board. More will be added soon.
My mission is to help teams all around the world to increase the value of their agile retrospectives. There’s the book Getting Value out of Agile Retrospectives, the Retrospective Exercises Toolbox, workshops for Valuable Agile Retrospectives in Teams and for Increasing your Agility with Retrospectives and there are lots of blog posts on retrospectives. And you can Ask Your Agile Retrospective Question on line. All these things help you to make your retrospectives valuable.
A big thanks to Philip Rogers for providing me the possibility to share my experience and ideas for agile retrospectives on this board!
I will give two workshops in Kladno (near Prague) on Getting More out of Agile and Lean. In these workshops you’ll learn practices to develop the right products for your business and customers, reduce your delivery time, increase the quality of your software, and create happy high performing teams.
Retrospectives Exercises Toolbox - Design your own valuable Retrospectives
These workshops are done in collaboration with Aguarra, the competence center for agile techniques and technology innovations in Czech Republic, Slovakia and Hungary. Aguarra serves as a platform for experts, who work on research and implementation of agile techniques.
The workshop on Getting More out of Agile and Lean can be combined with the workshop on Valuable Agile Retrospectives that I’m giving on on November 1 or December 1. These two days of workshops on Retrospectives and Agile and Lean practices help you to boost the performance of your teams, enabling them to deliver more value to their customers and stakeholders.
Regular price is 480 EUR / 576 EUR. Price when ordering until 01. 09. 2016 : 440 EUR / 528 EUR.
When you receive a letter that has an official The White House logo on it, you basically have two options: jump for joy or run for the hills! Fortunately, I was a jumper. It read:
Dear Tania, Congratulations! You are one of the nominees chosen to attend The United State of Women Summit on June 14th here in Washington, D.C. We appreciate the work you do to further gender equality and hope that you’ll be able to attend.
So, yes, my job at Axosoft (and in life) is disrupting the status quo, especially when it comes to gender representation in STEAM fields! As co-creator of the #ItWasNeverADress campaign, I speak to thousands (getting close to millions) of people about shifting perceptions and assumptions about women in the world.
Last week, I joined 5,000 women in Washington, D.C. for the first-ever White House Summit on the United State of Women.
And, I’m sad to report, like most government agencies, the line to get in was really long! Fortunately, everyone in line was a “changemaker.” It was filled with leaders, organizers and activists from around the globe who are rallying for economic empowerment, changing health and wellness policies, creating bridges into education, starting businesses, and changing the culture to end violence against women.Standing in line was a good time. It was like summer camp for the most inspiring people you will ever meet!
After more than 13 hours of the most electrifying, heartbreaking and dynamic speeches, stories, panels, and songs; after the President of the United States of America said, “This is what a feminist looks like”; after Jaha Dukureh, a survivor of female genital mutilation said, “I stand here to represent a forgotten population: girls who are a footnote in research papers and never make it past lunchtime conversations”; in the wave that is Oprah Winfrey taking the stage and in her iconic “You get a car!” voice screaming, “We are here for the UNITED STATE OF WOMEN!!”; in a room full of women of color; full of survivors; full of doers, dreamers and those who dare, we reached a peak.Perhaps that’s why they called it a summit.
When I left this historic event, deeply moved and profoundly inspired, I kept thinking, what’s next? How do we take this momentum and turn it into action? What can we do every day that will make a difference? How do we continue this movement? How do we, in the words of First Lady, Michelle Obama, “BE better”?“BE better.”
Turns out, the trailblazers presenting at The United State of Women Summit created a map to help us take action! I identified 6 key roadside attractions I’d like to point out.6 stops on the road map to being better 1. Disrupt the status quo. “Disruption is the only thing that causes change.”Brittany Packnett, Teach for America
Go ahead, pick a system that is clogged up: the economy, education, health care, safety… and interrupt it! Let’s take women in technology for instance. As an Evangelist for a tech company, Axosoft, my job is to stand up in front of 2,000 or more technologists and tell ‘em why it’s important to embrace diversity.
Oftentimes, I’m the only playwright in the room, the only woman in the room, the only LGBT person in the room. As I see it, the more I show up, the more I’m myself, the more I point out subtle (and not-so-subtle) injustices that exist when we think everyone is the same, the more meaningful conversations we can have.“Strategically disrupt the status quo by men and women working in tandem. There must be a willingness to be present, a genuine desire to listen, and the ongoing commitment to transform men.”Matt McGory, Actor on How To Get Away With Murder 2. Make a pledge.
A pledge is a promise, an undertaking, an action. And guess what? We’ve been pledging our allegiance to the flag of this awesome country since we entered the school system, so we know how to do it!
Make your pledge to ensure all human beings are seen, heard, safe, supported and given the resources that every human being deserves.“I will use my voice in service of those who don’t have a voice right now.” “So, President Obama and I started It’s On Us—to wake-up our colleges and universities–and the country–to the epidemic of sexual violence on their campuses.”Joe Biden, Vice Presiden of the United States 3. If you don’t see something, say something.
Oftentimes we are at work, on a panel, in the audience or simply flipping through a business journal and become painfully aware that women and people of color are missing from these spaces; so let’s say something!
Adecco’s research shows that 85% of large global enterprises believe that diversity is critical to fostering innovation in the workplace.
If we say something, we’re helping our companies become more innovative and we’re honoring the company we keep!“If your companies, organizations, and boards don’t have women, you’re not doing women’s work.”Cherno Biko, CoFounder, #BlackTransLivesMatter 4. Humor is a serious tool.
As we all know, chitty-chatting about politics can raise one’s heart rate and, sometimes, alienate the very people we need to connect with in order to create change. Next time you find yourself, ahem, raising your voice at an opposing P.O.V., try finding a connection that you and your adversaries share. Crack a joke, and you just might just make a new ally!
“We use humor. It’s a great way to get people in politics talking about important issues.” Erin Loos Cutraro, Co-Founder & CEO, She Should Run5. Stop name-calling and start dreaming + doing!
When Mikaila Ulmer took the stage, small in stature, but HUGE in confidence and focus, she reminded all of us big shot adults, that the true source for innovation is dreaming; no matter if you are 11 or 100 years old!“Entrepreneurs hold the American dream & the biggest dreamers are kids.”Mikaila Ulmer, 11-Year-Old Businesswoman and Entrepreneur
When First Lady Michelle Obama was in conversation with Oprah (yes, it was amazing), she spoke candidly about the name calling she’s experienced on social media, the bullying aimed at women and at people of color, and the intensity added when your husband is running for president.
Early on in her husband’s bid for office, she stopped engaging in all the noise and realized that, ‘It’s what I do, not what you call me.’
Do you have a dream of leading your team in creating new software, wanna write a book, travel around the world, start your own business?
Ask yourself, ‘What is one thing I can do today, to move forward on my dream map?’
It’s time to do one thing. Reach out to a software developer, start writing, buy a ticket, email an entrepreneur and ask for advice. All it takes is one gesture to swiftly move your dreaming to doing!What’s your dream? You can make it happen. 6. Make caring your business. “When you’re building a culture, every person matters.” Melanie Whelan, CEO, SoulCycle
Whether you’re at the helm of a large company, like SoulCycle, or compelled to start an organization, like Kechie’s Project, caring is a powerful catalyst! What do you care deeply about? It’s time to pair your skills with your caring and innovate the workplace as well as the worldplace!“In 2011, my 68-year-old mother was kidnapped for ransom in Enugu State of Nigeria and was held for two months… This situation has increased my drive to give a voice to other women in Nigeria and other countries in Africa, who cannot speak out for themselves against the onslaught of injustices.”Nkechi Ogbodo, Founder and President, Kechie's Project
If you specify deliverables in your big picture and small picture roadmaps, you have already done a gross form of ranking. You have already made the big decisions: which feature/parts of features do you want when? You made those decisions based on value to someone.
I see many POs try to use estimation as their only input into ranking stories. How long will something take to complete? If you have a team who can estimate well, that might be helpful. It’s also helpful to see some quick wins if you can. See my most recent series of posts on Estimation for more discussion on ranking by estimation.
Estimation talks about cost. What about value? In agile, we want to work (and deliver) the most valuable work first.
Once you start to think about value, you might even think about value to all your different somebodies. (Jerry Weinberg said, “Quality is value to someone.”) Now, you can start considering defects, technical debt, and features.
The PO must rank all three possibilities for a team: features, defects, and technical debt. If you are a PO who has feature-itis, you don’t serve the team, the customer, or the product. Difficult as it is, you have to think about all three to be an effective PO.
The features move the product forward on its roadmap. The defects prevent customers from being happy and prevent movement forward on the roadmap. Technical debt prevents easy releasing and might affect the ease of the team to deliver. Your customers might not see technical debt. They will feel the effects of technical debt in the form of longer release times.
Long ago, I suggested that a specific client consider three backlogs to store the work and then use pair-wise comparison with each item at the top of each queue. (They stored their product backlog, defects, and technical debt in an electronic tool. It was difficult to see all of the possible work.) That way, they could see the work they needed to do (and not forget), and they could look at the value of doing each chunk of work. I’m not suggesting keeping three backlogs is a good idea in all cases. They needed to see—to make visible—all the possible work. Then, they could assess the value of each chunk of work.
You have many ways to see value. You might look at what causes delays in your organization:
- Technical debt in the form of test automation debt. (Insufficient test automation makes frictionless releasing impossible. Insufficient unit test automation makes experiments and spikes impossible or quite long.)
- Experts who are here, there, and everywhere, providing expertise to all teams. You often have to wait for those experts to arrive to your team.
- Who is waiting for this? Do you have a Very Important Customer waiting for a fix or a feature?
You might see value in features for immediate revenue. I have worked in organizations where, if we released some specific feature, we could gain revenue right away. You might look at waste (one way to consider defects and technical debt).
Especially in programs, I see the need for the PO to say, “I need these three stories from this feature set and two stories from that other feature set.” The more the PO can decompose feature sets into small stories, the more flexibility they have for ranking each story on its own.
Here are questions to ask:
- What is most valuable for our customers, for us to do now?
- What is most valuable for our team, for us to do now?
- What is most valuable for the organization, for us to do now?
- What is most valuable for my learning, as a PO, to decide what to do next?
You might need to rearrange those questions for your context. The more your PO works by value, the more progress the team will make.
The next post will be about when the PO realizes he/she needs to change stories.
If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.
Part 1 was about how the PO needs to see the big picture and develop the ranked backlog. Part 2 was about the learning that arises from small stories. Part 3 was about ranking. In this part, I’ll discuss the product owner value team and how to make time to do “everything,” and especially how to change stories.
Let’s imagine you started developing your product before you started using agile. Your product owners (who might have been a combination of product managers and business analysts) gave you a list of features, problems, and who knows what else for a release. They almost never discussed your technical debt with you. In my experience, they rarely discussed defects unless a Very Important Customer needed something fixed. Now, they’re supposed to provide you a ranked backlog of everything. It’s quite a challenge.
Let’s discuss the difference between a product manager and a product owner.
A product manager faces outward, seeing customers, asking them what they want, discussing dates and possibly even revenue. The product manager’s job is to shepherd the customer wishes into the product to increase the value of the product. In my world, the product manager has the responsibility for the product roadmap.
A product owner faces inward, working with the team. The PO’s job is to increase the value of the product. In my world, the PO works with the product manager (and the BAs if you have them) to create and update the product roadmap.
A business analyst might interview people (internal and external) to see what they want in the product. The BA might write stories with the PO or even the product manager.
The product manager and the product owners and any BAs are part of the Product Owner value team. The product owner value team works together to create and update the product roadmap. In a large organization, I’ve seen one product manager, several product owners and some number of BAs who work on one product throughout its lifetime. (I’ve also seen the BAs move around from product to product to help wherever they can be of use.)
What about you folks who work in IT and don’t release outside the company? You also need a product manager, except, with any luck, the product manager can walk down the hall to discuss what the customers need.
If you work in a small organization, yes, you may well have one person who does all of this work. Note: a product manager who is also a product owner is an overloaded operator. Overloaded people have trouble doing “all” the work. Why? Because product management is more strategic. Product ownership is more tactical. You can’t work at different levels on an ongoing basis. Something wins—either the tactical work or the strategic work. (See Hiring Geeks That Fit for a larger discussion of this problem.)
When one person tries to do all the work, it’s possible that many other things suffer: feedback to the team, story breakdown, and ranking.
The Product Owner Value team takes the outside-learned information from customers/sponsors, the inside-learned information from the product development team (the people who write and test the product), and develop the roadmap to define the product direction.
In agile, you have many choices for release: continuous delivery, delivery at certain points (such as at the end of the iteration or every month or whenever “enough” features are done), or monthly/quarterly/some other time period.
Here’s the key for POs and change: the smaller the stories are or the more often the team can release stories, the more learning everyone gains. That learning informs the PO’s options for change.
In this example roadmap, you can see parts of feature sets in in the first and second iterations. (I’m using iterations because they are easy to show in a picture and because people often want a cadence for releasing unless you do continuous delivery.)
If the Product Development team completes parts of feature sets, such as Admin, Part 1, the PO can decide if Admin, Part 2 or Diagnostics, Part 1 is next up for the team. In fact, if the PO has created quite small stories, it’s really easy to say, “Please do this story from Admin and that story from Diagnostics.” The question for the PO is what is most valuable right now: breadth or depth?
The PO can make that decision, if the PO has external information from the Product Manager and internal information from the BA and the team. The PO might not know about breadth or depth or some combination unless there is a Product Owner Value team.
Here are some questions when your PO wants everything:
- What is more valuable to our customers: breadth across which parts of the product, or depth?
- What is more valuable for our learning: breadth or depth?
- Does anyone need to learn something from any breadth or depth?
- What cadence of delivery do we need for us, our customers, anyone else?
- What is the first small step that helps us learn and make progress?
These questions help the conversation. The roadmaps help everyone see where the Product Owner Value team wants the product to go. I’ll do a summary post next. (If you have questions I haven’t answered, let me know.)
Someone needs to learn about what the customers want. That person is outward-facing and I call that person a Product Manager. Someone needs to create small stories and learn from what the team delivers. I call that person a Product Owner. Those people, along with BAs compose the Product Owner Value team, and guide the business value of the product over time. The business value is not just features—it is also when to fix defects for a better customer experience and when to address technical debt so the product development team has a better experience delivering value.
I’ll do a summary post next. (If you have questions I haven’t answered, let me know.)
If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.
One of the biggest buzzwords in the industry lately is DevOps. We all know by now what DevOps is intended to offer, and most organizations are looking for at least some subset of the promise of a continuous delivery flow and the power of “pulling ops into the room”. But can we really do that if our own job of becoming “more agile” is still incomplete?
Let’s explore for a moment what we even mean by agile. I recall back in the early days that agile discussions were about how to turn around features quickly by breaking them down into smaller “bite sized” chunks, delivering those, and then determining where to go next based on that feedback. We invented cool things like user stories, and utilized mechanisms like short iterations and daily standups to move closer to this fast-paced, turn-on-a-dime philosophy toward software development. We discovered, without a doubt, that this was a better way. One major portion of these methods was a set of technical practices that would enable the teams to write software in a way that would support such a nimble environment.
So, where are we now? We have discovered that doing things in these small chunks is hard. It is counter intuitive too. We want to look at things in big picture terms. The question I used to hear the most was “how can I manage a portfolio this way?” Now that question has been turned into “how can we scale this?” My answer to each question is the same: Don’t. The reason we moved to the smaller chunks and stories is because the “big picture” approach doesn’t work. So finding ways to shoehorn agile methods into “scaled” or “Big Up Front Agile” is a waste of time and energy. Rather, let’s learn how to do the real agile methods better, and reap the well-known benefits.
What does this have to do with DevOps? Hang on, we’re getting there. One of the things that got set aside along the way was the focus on practices that enable agility. Test Driven Development (TDD) was at best assumed it would magically happen, and more often set aside as something “we’ll get to once we get all of our release trains and architectural runways laid out”. In other words, never. A possible metaphor is saying “I will start exercising once I’m in better shape.” You have to do the technical practices first, or the rest is just a waste of time. And this is where DevOps comes into play.
DevOps is most closely associated with the idea of Continuous Delivery. The idea that we can at any time build and deploy the results of our development efforts allows us a huge amount of flexibility with deciding what software gets delivered and when. The tools that help us, whether it be for visualizing and orchestrating the moving parts of build, test, and delivery, or the tools that automate these parts, have reached a level of maturity that allows us to move forward. The question remains, does your team have that same level of maturity?
If the extent of your team’s agile mechanisms is identifying “portfolio items” that will be broken into stories that will then be scheduled into sprints, do NOT try to go straight to DevOps. Learn how to truly embrace TDD, both at the Unit Test level and the Acceptance Test level. Once you feel comfortable with that, you can move to Continuous Integration and then Continuous Delivery and DevOps.
If you are doing “some TDD” and daily builds, you are getting there, but ramp up the tests first. You might be inclined to at least get some of the cool DevOps tools into place, but I highly recommend getting your TDD house in order first. Time and energy are finite, so let’s spend them appropriately.
If you still have a “change control board” of some type that controls when a merge happens, you aren’t ready for DevOps. Ensuring that your tests are in place and automated will help build the trust necessary to avoid constructs that are explicitly designed to slow the development process down. Building habits of checking in code and building several times a day will allow us to catch what errors might make it through quickly, and with a much smaller delta between check-ins to identify where the errors might have come from.
So, am I being somewhat absolutist here? Absolutely. Rather than taking our agile practices halfway there and then saying “hey I know, let’s do DevOps now”, work on making agile everything it possibly could be. Once you feel comfortable with your automated tool stack and delivering every iteration, then move to Continuous Delivery and DevOps.
That was the question that was posed to the freshly minted staff at the Open House for Friends and Family for Publix Grocery Stores store #1520 yesterday. It was amazing to be invited to witness the internal opening of one of Publix’s newest stores in Cary, NC.
The air was thick with excitement. Executives traveled in from the regional offices in Charlotte and from the corporate headquarters in Tampa, FL. We met the store leadership. We met everyone.
When it came time for the ribbon cutting, the newly minted store manager took the stage and posed this question, “Who owns this house?” It was met with a resounding, “We own this house!”
Three times the call came.
Three times it was met with with a loud cheer, “We own this house!”
Kevin Murphy, SVP of Retail Operations, summed up Publix’s success as being rooted in two key principles: ownership and pride in your work at every level of the organization. Kevin should know. He started as a front-service clerk at a Publix in 1984. He worked in various positions before being promoted to store manager in 1995. He was promoted to Jacksonville Division district manager in 2003, Atlanta Division regional director in 2009, Miami Division VP in 2014, and his current position was created in 2016.
Ownership and pride in work at all levels. Sounds like the same formula for success in Agile Product Development.
This is also the core of LeadingAgile’s approach to transformation from Basecamp One through Basecamp Five. Without local ownership of decision making at the point of the work being done, we send the message consciously on subconsciously that we don’t trust that the work being performed is high-quality and valuable.
If it isn’t valuable then why are you doing it? Non-valuable work is called waste.
If the work isn’t high-quality, then why? Do you have the correct expectations of how long the work should take? Are you measuring quality correctly? (hint: it’s not just about defect injection rate.) Do you reward the wrong things like heroic efforts?
This is the heart of Agile practices. It expects ownership and pride in work. It expects trusting the people doing the work to know what they are doing. If they don’t, it expects you to let them self-organize to the extent that people who know how to do the work well, can volunteer to do it with the expectation that they also mentor those that don’t.
What about your company? Does it espouse a culture of ownership and pride in work? How would you know? Our assessments cut right to the heart of the matter and help organizations determine if leadership is creating and empowering a culture of ownership and pride in work.
Wouldn’t you like to know?
Congratulations to the people of Publix Store #1520. I can’t wait to experience more ownership and pride in work. The world needs more of it.
When I work with clients, they often have a “problem” with product ownership. The product owners want tons of features, don’t want to address technical debt, and can’t quite believe how long features will take. Oh, and the POs want to change things as soon as they see them.
I don’t see this as problems.To me, this is all about learning. The team learns about a feature as they develop it. The PO learns about the feature once the PO sees it. The team and the PO can learn about the implications of this feature as they proceed. To me, this is a significant value of what agile brings to the organization. (I’ll talk about technical debt a little later.)
One of the problems I see is that the PO sees the big picture. Often, the Very Big Picture. The roadmap here is a 6-quarter roadmap. I see roadmaps this big more often in programs, but if you have frequent customer releases, you might have it for a project, also.
I like knowing where the product is headed. I like knowing when we think we might want releases. (Unless you can do continuous delivery. Most of my clients are not there. They might not ever get there, either. Different post.)
Here’s the problem with the big picture. No team can deliver according to the big picture. It’s too big. Teams need the roadmap (which I liken to a wish list) and they need a ranked backlog of small stories they can work on now.
In Agile and Lean Program Management, I have this picture of what an example roadmap might look like.
This particular roadmap works in iteration-based agile. It works in flow-based agile, too. I don’t care what a team uses to deliver value. I care that a team delivers value often. This image uses the idea that a team will release internally at least once a month. I like more often if you can manage it.
Releasing often (internally or externally) is a function of small stories and the ability to move finished work through your release system. For now, let’s imagine you have a frictionless release system. (Let me know if you want a blog post about how to create a frictionless release system. I keep thinking people know what they need to do, but maybe it’s as clear as mud to you.)
The smaller the story, the easier it is for the team to deliver. Smaller stories also make it easier for the PO to adapt. Small stories allow discovery along with delivery (yes, that’s a link to Ellen Gottesdiener’s book). And, many POs have trouble writing small stories.
That’s because the PO is thinking in terms of feature sets, not features. I gave an example for secure login in How to Use Continuous Planning. It’s not wrong to think in feature sets. Feature sets help us create the big picture roadmap. And, the feature set is insufficient for the frequent planning and delivery we want in agile.
I see these problems in creating feature sets:
- Recognizing the different stories in the feature set (making the stories small enough)
- Ranking the stories to know which one to do first, second, third, etc.
- What to do when the PO realizes the story or ranking needs to change.
I’ll address these issues in the next posts.
If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.
In Part 1, I talked about the way POs think about the big picture and the ranked backlog. The way to get from the big picture to the ranked backlog is via deliverables in the form of small (user) stories. See the wikipedia page about user stories. Notice that they are a promise for a conversation.
I talked about feature sets in the first post, so let me explain that here. A feature set is several related stories. (You might think of a feature set as a theme or an epic.) Since I like stories the team can complete in one day or less, I like those stories to be small, say one day or less. I have found that the smaller the story, the more feedback the team gets earlier from the product owner. The more often the PO sees the feature set evolving, the better the PO can refine the future stories. The more often the feedback, the easier it is for everyone to change:
- The team can change how they implement, or what the feature looks like.
- The PO can change the rest of the backlog or the rank order of the features.
I realize that if you commit to an entire feature set or a good chunk for an iteration, you might not want to change what you do in this iteration. If you have an evolving feature set, where the PO needs to see some part before the rest, I recommend you use flow-based agile (kanban). A kanban with WIP limits will allow you to change more often. (Let me know if that part was unclear.)
Now, not everyone shares my love of one-day stories. I have a client whose team regularly takes stories of size 20 or something like that. The key is that the entire team swarms on the story and they finish the story in two days, maybe three. When I asked him for more information, he explained this it in this way.
“Yes, we have feature sets. And, our PO just can’t see partial finishing. Well, he can see it, but he can’t use it. Since he can’t use it, he doesn’t want to see anything until it’s all done.”
I asked him if he ever had problems where they had to redo the entire feature. He smiled and said,
“Yes. Just last week we had this problem. Since I’m the coach, I explained to the PO that the team had effectively lost those three days when they did the “entire” feature instead of just a couple of stories. The PO looked at me and said, “Well, I didn’t lose that time. I got to learn along with the team. My learning was about flow and what I really wanted. It wasn’t a waste of time for me.”
“I learned then about the different rates of learning. The team and the PO might learn differently. Wow, that was a big thing for me. I decided to ask the PO if he wanted me to help him learn faster. He said yes, and we’ve been doing that. I’m not sure I’ll ever get him to define more feature sets or smaller stories, but that’s not my goal. My goal is to help him learn faster.”
Remember that PO is learning along with the developers and testers. This is why having conversations about stories works. As the PO explains the story, the team learns. In my experience, the PO also learns. It’s also why paper prototypes work well. Instead of someone (PO or BA or anyone) developing the flow, when the team develops the flow in paper with the PO/BA, everyone learns together.
Small stories and conversations help the entire team learn together.
Small features are about learning faster. If you, too, have the problem where the team is learning at a different rate than the PO, ask yourself these questions:
- What kind of acceptance criteria do we have for our stories?
- Do those acceptance criteria make sense for the big feature (feature set) in addition to the story?
- If we have a large story, what can we do to show progress and get feedback earlier?
- How are we specifying stories? Are we using specific users and having conversations about the story?
I’ve written about how to make small stories in these posts:
- Make Stories Small When You Have “Wicked” Problems
- Three Alternatives for Making Smaller Stories
- Feature sets in How to Use Continuous Planning
- Reasons for Continuous Planning
The smaller the story, the more likely everyone will learn from the team finishing it.
I’ll address ranking in the next post.
Description of charts:
Burndown chart - a daily count of the number of task units (aspirin is this teams selected units for task estimation) not done. This includes the task yet to be started, and task in process.
Tasks in Process - a daily count of the number of tasks in process.
Tasks Done - a daily count of the number of tasks that are done.
Stories Done - a daily count of the number of Stories that are done.
Velocity - the empirical measure of Stories that are considered done by the team and accepted as done by the Product Owner during the Sprint Review.
The Back Story on this team:
This team had been attempting to do some form of ad-hoc Scrum / Kanban with little guidance and understanding of the process. The Kanban aspect came from the company's tooling (RTC) template - not from any real practices the team was implementing. After some weeks of observations and workshops with the team - they decided to "hit the reset button" on doing Scrum. Sprint One in the info-graphic is the first sprint right after a week long workshop on learning Scrum practices and principles. Key to this team's adoption of Scrum is their adoption of a physical task board (see also Elements of an Effective Scrum Task Board).
Observations on Sprints:
Sprint One - Started with many stories from past sprint that were not yet done - as the team had no empirical data of velocity we guessed at how many stories we could complete in the 2 week sprint, and chose 15 stories. At this point we had 4 product silos where people we working within the silo to deliver the stories - very little cross team collaboration.
Rules siloSprint Two - Tear down the silo walls - the team decided that the original silos of working was harming a long term desire of cross-functional team members - so a removal of the silo walls (tape on the scrum task board) happened.
Sprint Three - Enforced the use of empirical data to constrain the team's selection of how many stories to bring into the sprint (team select top 5 stores and finished all of them).
Sprint Four - Team planed for 30 points of stories but finished early and pulled in additional stories and finished them within the sprint.
Objectives for the Team:
This teams objectives for hitting the reboot button on a scrum implementation was to achieve a consistent level of reliability to deliver value (stories) to the business. Also to maintain and supporting the existing 4 products line internal organizational clients, and transitioning tacit knowledge from several remote employees to the team and increasing cross-functional capabilities of the team members.
Commentary on Metric Charts:
Burndown - Sprint 1 and 2 task burndown charts show that the team started with around 100 aspirin and discovered between 50 and 100 aspirin more by doing the work - but didn't finish the 15 stories and left lots of stories started but incomplete at the end of the sprint. In sprint 3 and 4 the team had developed the ability to forecast the proper amount of work to pull into sprint planning and were able to deliver the completed stories.
Tasks in Process - this simple metric showed that the team of about 8 people were consistently task switching. There are many "reasons" (excuses) for this behavior, and it is a hard habit to correct in this era of high utilization rate driven management. Just tracking this metric had little effect on the teams behavior - however we had empirical data that other practices (avatars, re-estimating in process tasks, etc.) had a positive effect upon this metric over several sprints.
Tasks Done - this metric is redundant for a team using a traditional sticky note task board. In general this reflects the sprint burndown. It does point out for this team that tasks done stalls out when there support tasks flare up, as these support (maintenance and production, M&P) issues require task switching to the more urgent unplanned work. Reflecting upon this metric lead the team to start tracking the planned tasks separate from the urgent support tasks in our burndown chart for sprint 5.
Stories Done - an interesting trend shows up in this simple to trend metric. The team was capable of finishing 5 stories, regardless of how many they planned. In sprint 3 when the team constrained the planning to the empirical evidence (~28 points, 5 stories) they had there first successful sprint (on time, on budget, with planned scope).
Capabilities developed by the Team not shown in these Metrics:
Tasking - working toward tiny tasks. Within the first two sprints the focus was to develop the ability to task stories. Several synergic practices lead to this capability - re-estimating each time the task is touched in stand-up; recognizing that task that last for several days are way-too-large; learning to decompose tasks that are too large; realizing that doing work leads to discovery of new tasks that need to be recorded and added to the board. See Also: What belongs on the TASKS board?
Single Piece Flow - working on a task until it is done. Smaller task effect this behavior in a virtuous manner. Re-estimating each day makes the antithesis of this pattern apparent, and also offers the opportunity for team members to recognize when help is needed. The use of avatars on the story tasks reinforces the practice of lowering work in process and reducing task switching.
In Sprint 5 the team decided to move from a 2 week time box to a 3 week sprint. The charts also show the support (M&P) tasks tracking independently of the planned tasks and the new chart at the bottom (M&P task vs Planned task deltas per day) indicates the inverse relationship of the priority shifts the team has to deal with.
Develop the capabilities to deliver agile release plans and forecast feature release time frames for business coordination with other teams that depend upon the infrastructure product lines developed by this team.
At the team coaching level an objective is to measure cycle time of stories within scrum teams.
Metrics for a Scrum Team - 10 suggested metrics and examples
Measuring Process Improvements - Cycle Time by Mishkin Berteig, June 2008
7 Lean metrics to Improve Flow - LeanKit
Agile is hot! Kleine en grotere organisaties zijn bezig met het invoeren van agile, vaak met (grootschalige) veranderprogramma’s die niet altijd tot succes leiden. Met een plan wordt je niet agile, dat gebeurd door daadwerkelijk te veranderen, door het te doen. De vraag is: Hoe kun je agile worden door agile te doen.
Agile is geen doel, het is een middel wat je slim toepast om sneller en flexibeler te worden en meer waarde te leveren. Agile principes en practices van b.v. Scrum en Kanban helpen om je de agility van je organisatie te verhogen. Agile doen
Retrospectives Exercises Toolbox - Design your own valuable Retrospectives
Als ik organisaties help bij het toepassen van agile dan begin ik vaak met kleine veranderingen waar op kortere termijn winst te halen is. Van zulke veranderingen leert de organisatie dat ze kunnen veranderen. Ze zien de waarde van de verandering snel terug. Dat versterkt het effect en geeft energie voor verdere verandering. Ze worden meer agile door agile te doen.
Ook pak ik die veranderingen aan waar een groot risico zit. “Learn fast by failing fast.” Dat helpt ook om mensen wakker te schudden. Als het lukt, dan is het een mooi bewijs dat veranderen kan. Gaat het fout, dan weten we dat die aanpak niet de oplossing is. Een leermoment waarvan we beter en sterker worden. Kortom, het kan niet fout gaan. Agile zijn
Managers vragen mij wanneer ze “agile zijn”. Agile is nooit “af”. Het is geen kwestie van Scrum, Kanban of SAFe invoeren. Het is een reis van continue verbetering, waarin de resultaten van de organisatie steeds verder groeien. Onderweg borg je veranderingen om te zorgen voor blijvend resultaat.
Met agile worden organisaties beter in staat om zich aan te passen aan veranderingen in hun omgeving, en leveren ze meer waarde aan bestaande en nieuwe klanten. Dat houdt nooit op, gelukkig maar. Agile worden
Het nadeel van een veranderprogramma met een plan is dat het de suggestie wekt dat er een einddoel is waarin de organisatie agile is. Om geen verkeerde verwachtingen te wekken werkt ik bij voorkeur met een verander backlog. Daarin staat wat we de komende tijd gaan doen, en waarom we dat doen, om agile te worden. Continue verbeteren met Agile!
Met de feedback van de veranderingen, veranderen de prioriteiten in de veranderbacklog. Er komen dingen bij en vallen er dingen af. We komen nooit op een punt waarop alles gedaan is. We zorgen er op deze manier wel voor dat we met de belangrijkste veranderingen bezig zijn. Is dat genoeg? Voor veel organisaties wel! Continu Verbeteren
Verbeteren kan en moet anders. Continu maar beheerst veranderen, in kleine stapjes op weg naar meer resultaten. Mijn aanpak maakt de veranderingen inzichtelijk en geeft stakeholders een instrument om mee te sturen. De workshop continu verbeteren met Agile zorgt voor tevreden klanten, stakeholders en medewerkers!
Hopelijk heeft dit artikel je geholpen om manieren te vinden om agile worden door agile te doen. Ik ben benieuwd naar jouw ervaringen. Wat doe je om de agility te verhogen? Wat werkt, en wat niet? Deel je ervaringen middels een comment op dit artikel.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]