There are, of course, a variety of ways to go about planning a sprint. I’ve written previously about velocity-driven sprint planning and commitment-driven sprint planning and my preference. But regardless of which approach a team takes to sprint planning, there is also the question of how full to fill the sprint.
Some teams prefer to leave plenty of excess capacity in each sprint, perhaps so there is time for emergent needs or experimentation. Other teams prefer to fill the sprint to the best of their ability to forecast their capacity.
Still other teams like to take on a “stretch goal” each sprint, which is kind of a product backlog item that is not quite in the sprint, but is one the team hopes to complete if the sprint goes well.
In this post, I’d like to share my thoughts on bringing a stretch goal into a sprint.
This is one of those things that needs to be left entirely up to the team. It should not be up to the ScrumMaster or the product owner, but up to the team. Some teams do extremely well with a stretch goal. Other teams do not.
It really depends on how the team views the stretch goal.
For example, I feel stretch goals are like a crushing weight. I feel like I need to complete them. When I set a goal, I almost always achieve it. I have a hard time distinguishing between what I call a “normal goal” and stretch goal. I don’t think this is good, but it’s who I am. But, I’m not the only one who does this.
If a team included me and perhaps a couple of others like me, we would probably not do well with a stretch goal. The stretch goal would likely be in our minds and possibly even affect our ability to finish all of the main work of the sprint.
Other people--those unlike me--have what I’ll call a more mature attitude toward stretch goals. They can look at it as it’s intended. They can think, “OK, great if we get to it but no big deal if not.” Teams comprising mostly people like that will probably do quite well with a stretch goal.
So: Should your team have a stretch goal in their sprints?
This really has to be up to the team. Unless I’m on the team. Then the answer is no.Does Your Team Use Stretch Goals?
What do you do? Does your team use stretch goals? Does it help? Please share your thoughts in the comments below.
Did you know that some major tech companies are hiring women at a rate of 238% faster than they are hiring men?
Although there are still more men than women in the workplace overall, this means that over the next few years, we will see women influencing technology in a way that has never been done before. If more companies follow suit, it won’t be just a small number of companies paving the way for diversity.
One tech company reportedly hiring women faster than men is eBay. Self-described as “the world’s online marketplace,” the company welcomes millions of users each month who want to buy and sell goods online. From unwanted Christmas gifts to designer clothing and handbags, almost anything can be purchased on eBay.
For a company like eBay—an online retailer—proper knowledge from both male and female perspectives is very important. At the moment however, the company currently has an employee breakdown of 24% female and 76% male.
Although tech companies are hiring many women, there is some bad news: a total of 56% of female employees leave tech companies midway through their careers for various reasons.
Here’s the breakdown of those reasons:
- 30% leave their positions because they are not getting enough pay and believe the working conditions to be poor. As of 2013, it is thought that women earn an average of 18% less than men in the United States, which means there is less of an incentive for women to stay in their roles.
- 27% leave their jobs in tech because they are unable to manage a healthy work-life balance.
- 22% simply lose interest in their jobs.
- 17% of women in technology jobs leave because they don’t like their superiors and co-workers.
For an interesting look at the women in tech landscape, check out this infographic: 33 Must Know Facts About Women in Tech. You’ll find stats, figures and at-a-glance facts about female leaders in the tech world. Also, discover some main factors that could encourage women to maintain their tech roles for a longer period of time.
How do you think we can retain more women in tech? Share your answers in the comments section below!
Zuzana Padychova helps international SMEs to adapt and execute their global business strategies in local markets. Zuzana is in a team of Potential Asia digital marketers developing a network of Coupofy online startups across the world.
For many people, agile means an end to all project management. I disagree. I find value in servant leadership in project management.
I explain how you can think about servant leadership and agile project management in my projectmanagement.com column this month: Servant Leadership: The Agile Way.
If you are looking to increase your servant leadership and help your project team (or program), check out the Influential Agile Leader.
The truth is, if you don’t like to constantly be learning new things, web development is probably not for you. You might have chosen the wrong career!
— Josh Burgess
- Google Closure
Eight different frameworks in about as many years. And though we adopted Angular about 2 years ago we’re already dealing with non-backwards compatibility, Angular 2.0. This is a large burden on maintenance and it costs us very real time to spin up on each one when we have to enhance the app or fix a bug.
This is a monolithic app that’s been built over quite a few years, but the big difference is the Rails app was opinionated and stuck to a lot of default conventions. The framework churn of Rails has been much more gradual and generally backwards compatible. The largest pain we experience was going from Rails 2 to 3, when Rails was merged with Merb. The knowledge someone built up in their first few years working in Ruby and Rails still applies. The churn is certainly exists, but at a measure pace.
You see the Node.js philosophy is to take the worst fucking language ever designed and put it on the server.
— Drew Hamlett
In a week, I'll be launching my first online training course on Agile Game Development. This first course is an overview of Scrum and Kanban for game development with a focus on the values and principles (gems) of *why* we do it. My aim was to provide broad training to many of the developers who don't get a change to attend onsite or offsite training.
The training is hosted thought FrontRowAgile.com, which hosts training for other areas of agile (such as agile estimating and planning training by Mike Cohn).
Members of the mailing list will receive discounts for training. http://www.clintonkeith.com/mailing_list.html
Check out the free portions of the training below: https://youtu.be/DQzrFiMDoko
Over on Techwell, my monthly column is Agile Does Not Equal Scrum: Know the Difference.
I wrote the article because I am tired of people saying “Agile/Scrum” as if Scrum was the only way to do agile.
I use iterations, kanban, and the XP technical practices when I work with teams. I am not religious about the “right” way to do agile. I like any combination of approaches that help a team deliver value often. I like anything that helps a team to get feedback on their work and their team process.
I like anything that helps management ask the right questions and create an environment in which teams can succeed.
Dogma doesn’t work very well for me. (I know, you are so surprised.)
If you are thinking about your agile approach, ask yourself, “What does agile mean to me? What value will agile deliver?”
Before you decide on an approach, answer that question. You might be more Dan in my most recent Pragmatic Manager, Define Your Agile Success. Once you know what agile means to you, you might start to read more about possibilities that fit for you.
If you are a leader in your organization trying to use agile more effectively, consider participating in the Influential Agile Leader.
Here at Axosoft, we think it’s time for everyone to have TOTAL CONTROL over their repos. So, as of now, with version 0.6 we are in…Open Beta! OPEN. BETA!
Sick and tired of waiting for your dev ‘friends’ to send you an invite? Well, wait no more! Now you can try a truly beautiful Git client right away, because we’ve unleashed the GitKraken beta to the public so now you can dive in all on your own—no friends required! Our initial months in closed beta allowed us to get the app much more stable and feature-rich, and now we’re ready to have the wider world put the app through its paces to further refine GitKraken.
Still not sure what all the hype is about? Enjoy 30 seconds of pure bliss…
Now unleash your repos with GitKraken; simply visit gitkraken.com, hit the download button and install the app. If you were hoping there would be a convoluted setup process involving OS compatibility or dependencies, sorry to disappoint you. As this post covers, GitKraken works without dependencies (you don’t even need to manually install Git on your machine!) and runs natively cross-platform—Mac, Windows and Linux users all enjoy the same user experience.Forking Amazing Bitbucket Support
GitKraken has supported Bitbucket for some time, but you had to manually copy and paste in your URLs to get going. This was unacceptable to the Kraken, and for this release, full integration with Bitbucket is up and running. Interact directly with your public and private repositories and search forks!Get the Keys and Go
That’s not all that has improved with this release. Existing GitHub integration has been tightened up, with the ability to generate SSH key pairs and also automatically add the public key to GitHub. Less app switching FTW.With All the Fixin’s
Apart from the major items, the GitKraken devs have been busy fixing, tweaking, and improving things under the hood to provide better reliability in the app, and have continued to make ongoing UI improvements for a cleaner, more intuitive user experience with as few unnecessary interactions as possible.For the Newbs
There are far too many to list here in their entirety, but a few notable features from earlier releases include:
- Git Flow support: Initialize a workflow per repository then quickly initiate and work on Feature, Release, and Hotfix branches from right in the ref panel
- SSH support: Including support for shh:// protocol format in URLs with OAuth/GitHub
- Drag and drop rebasing
- Undo local actions
- Fast, beautiful UI with intuitive, clean graph view of commits and branches.
If this is your first time using GitKraken, take a look at the release notes and at our introductory blog post, to git familiar with the app’s features. But, there’s no better way to unleash your repos than to try it yourself. We want v1.0 to be the very best it can be, and your feedback and questions are essential to us achieving that. Please follow @GitKraken on Twitter where you can send us your feedback.
So naturally the conversation went something like this:
Inquisitive person: "Hi David, what's an Agile Transition Guide? Is that like a coach?"
David: "Hi, glad you asked. What does a coach do in your experience?"
Inquisitive person: "They help people and teams improve their software practices."
David: "Yes, I do that also."
Inquisitive person: "Oh, well then why don't you call yourself a coach?"
David: "Great question: Let's see... well one of the foundational principles of coaching (ICF) is that the coached asks for and desires an interaction with the coach, there is no authority assigning the relationship, or the tasks of coaching. So do you see why I don't call myself a coach?"
Inquisitive person: "Well no, not really. That's just semantics. So you're not a coach... OK, but what's is a guide?"
David: "Have you ever been fishing with a guide, or been whitewater rafting with a guide, or been on a tour with a guide? What do they do differently than a coach? Did you get to choose your guide, or were they assigned to your group?"
Inquisitive person: "Oh, yeah. I've been trout fishing with a guide, they were very helpful, we caught a lot of fish, and had more fun than going on our own. They also had some great gear and lots of local knowledge of where to find the trout."
David: "Well, there you have it... that's a guide - an expert, a person that has years of experience, has techniques to share and increase your JOY with a new experience."
Inquisitive person: "Yes, I'm starting to see that difference, but can't a coach do this also?"
David: "No, not unless the coach is willing to switch to a different modality - to one of mentoring, teaching, consulting, or protecting. Some times a guide must take over for the participant and keep the person/group within the bounds of safety - think about a whitewater river guide. A coach - by strict interpretation of the ethics, is not allowed to protect the person from their own decisions (even if there are foreseen consequence of this action."
And now the conversation start to get very interesting, the Whys start to flow and we can go down the various paths to understanding. See Richard Feynman's dialogue about "Why questions"
So, I'm not a Coach
I've been hired as a coach (largely because the organization didn't truly understand the label, role, and the ethics of coaching). This relationship was typically dysfunctional from the standpoint of being a coach. So I decide to study the role of coaching. I've done a few classes, seminars, personal one of one coach, read a lot and drawn some conclusions from my study - I'm not good a coaching within the environment and situation that Agile Coaches are hired. I've learned that regardless of the title that an organization uses (Agile Coach, Scrum Master, etc.) it doesn't mean coaching. It intends the relationship to be vastly different. Since I'm very techie, I appreciate using the correct words, and phrase for a concept. (Paraphrasing Phil Karlton: In software there are two major challenges: cache invalidation and naming things. Two Hard Things)
So to stop the confusing and the absurd use of the terms, I quit referring to my role and skills as coaching. Then I needed a new term. And having lots of friends that have been Outward Bound instructors and understanding their roles, the concept of a river guide appeals to me in this Agile transformational role. Therefore I coin the term Agile Transformation Guide. But many organization do not wish to transform their organization, but they do wish for some type of transition, perhaps from tradition development to a more agile or lean mindset. So a transition guide is more generic, capable of the situational awareness of the desire of the organization.
The Difference Between Coaching & Mentoring
Scrum Master vs Scrum Coach by Charles Bradley
Agile Coach -or- Transition Guide to Agility by David Koontz; the whitewater guide analogy to agile coaching.
Academic paper: Coaching in an Agile Context by David Koontz
Interesting Twitter conversation about the nature of "coaching" with Agile42 group.
challenged my former Head of IT, some years ago. Certainly, it’s a reasonable request to ask how productive a team (or a whole system) is.
But first let’s look at the why behind the question. Why do we measure productivity? Because we should? Because we can? For transparency? Accountability? To drive behaviors and influence culture? Should we measure it at all?
There are three simple, impactful metrics (for Agile or Waterfall workplaces) that I informally collect (through conversations is a good start) to quickly gauge productivity and how healthy and high-performing an organization is.Lead Time
Lead time is the queen of metrics. Lead time tells me how long it takes work to travel through the whole system, from concept to cash:
How quickly is value delivered to customers? Long lead times indicate waste. Lean experts Mary and Tom Poppendieck describe how over 80 percent of time-to-market can be “waste” in the form of delays and non-value-added work. That quickly snowballs into a double-pronged, multi-million dollar cost of delay that directly hits a company’s profits via the delay in value delivered to customers and thousands of wasted person hours.
What do long lead times look like in the real world?
This week I’m working with the largest company of its type in this state. It regularly takes up to six months to get a business case approved, and another 12 months to deliver a project. That’s an 18-month lead time to deliver value to customers. Given that requirements change at an average rate of around 2 percent per month (based on Capers Jones’ empirical research in the 20th century, and it’s probably higher in 2016,) this means a project that goes live today is delivering requirements that were signed off on 12 months ago and have changed (degraded?) by over 24 percent.
This company’s volume of work is expected to increase at least 30 percent in the near future (with no headcount increase.) What happens when we add 30 percent greater volume to an already chockablock freeway? It reduces our speed by an order of magnitude.
This company is adding risk to its portfolio by having such long lead times. Are the teams productive? Not nearly as productive they could be. What actions should they take to reduce lead times? Just reducing the batch size of work (e.g. from 12-month projects into small, discrete features) and setting work in progress (WiP) limits will often double throughput (i.e. halve lead time) as described by Lean management guru Don Reinertsen. These are things you can start doing sooner rather than later.
But, by itself, lead time doesn’t tell me how productive a team is.Predictability
Predictability complements lead time and has an equal seat at the head of the table as the king of metrics. Not only do I want a short lead time, I want to reliably know when work will be done and when value will be delivered to customers. Predictability is not boring—it’s the new black. And it’s sure better than 50 shades of grey, so to speak, in terms of guessing when something might be delivered.
The city I’m working in suffered floods not so long ago. I asked my client, whose offices overlook the river, whether the council knows the volume of water in the river and its rate of flow, i.e. how much water flows into the nearby sea every day. “Of course,” he replied. “So, what about your portfolio? What volume of work can it handle and how quickly will that work flow out to customers?” My client didn’t even pause.We don’t know. We don’t really know what our capacity is at the portfolio level or how quickly we can deliver work.”
That’s not unusual in this type of organization. It would be unusual in manufacturing, where every widget is a physical item and easily traceable. But where work is less tangible it’s easy for “invisible waste” to significantly erode capacity.
Predictable delivery not only increases profits and reduces bottlenecks, it has a more important outcome: it creates trust, trust that teams will deliver on time and that the portfolio can and will deliver the number of features (or requirements) promised. I give my business to companies I can trust—that deliver when they say they will—over companies that don’t deliver when they say they will.
What actions can you take to increase predictability? You need to know the capacity and velocity of your portfolio. Once your requirements are logically grouped into features (see above,) use relative sizing (starting with a small-ish and well-understood feature) to quickly get a view of how much work is in-flight and in the pipeline.
T-shirt sizing is fine if your stakeholders are new to story points (which you can later map over the t-shirt sizes.) It will probably be “way too much” work, which is where prioritization comes in (a topic for another time.) Then, populate “just enough” features to be assigned to the next program increment (say, 12 weeks.) And do this activity with the people close to the work, not far-removed stakeholders.
When I find a company (or a team) with short lead times and high predictability, it’s a good indication that it is productive (although it doesn’t tell me that they are delivering the right things—another topic for another time.) But there’s one other metric that trumps both lead times and predictability.Happiness
Happiness is the most important metric because in a knowledge economy, talented people are the competitive advantage. Are our people (and customers) happy? Simplistically, happy employees deliver good products, which lead to happy customers and good profits. And, the reverse is usually true: an unhappy employee is more likely to deliver a poorer product, leading to unhappy customers and poorer profits. "People, products and profits—in that order,” as our own CA Agile Business Unit GM, Angela Tucci, reiterates. I want to know if my employees are happy or unhappy and why, because it’s closely linked to motivation. As Dan Pink’s now cult classic video explains, give your people autonomy, mastery and purpose and they will be motivated to change the world.
How do we find out whether our people are happy? Ask. Not (just) via an anonymous, annual, online tick box survey. Ask via team retrospectives. Ask via one-on-one or small group sessions. Use a simple 1-5 Likert scale if you want an easy way to quantify the qualitative data. Ask what’s making people happy and unhappy. Frequently improving what’s making people and teams unhappy improves our other two metrics: lead time and predictability.
For example, my client is generally happy but is anxious because the organisation needs to pull 30 percent more work through the “system” as part of its growth objectives. My client’s teams perform reasonably well but are frustrated because there are bottlenecks around key roles and these delays generate significant non-value-added workarounds. Improving these problems would make these people happier and improve lead times and predictability, and lead to happier customers and greater profits.
Let’s return to my former Head of IT and the quest for a single metric for productivity: this may be a holy grail for another explorer. But, armed with metrics for lead time, predictability and happiness, I can reasonably and efficiently infer sustainable productivity—not only at a team level, but at a portfolio and company level.
And so can you.Suzanne Nottage
I met a team recently who was concerned about their velocity. They were always “too late” according to their manager.
I asked them what they measured and how. They measured the burndown for each iteration. They calculated the number of points they could claim for each story. Why? Because they didn’t always finish the stories they “committed” to for each iteration.
This is what their burndown chart looked like.
A burndown chart measures what you have finished. If you look at their burndown, you can see there are times when not much is done. Then, near the end of the iteration, they finish more. However, they don’t finish “everything” before they run out of time.
An iteration is a timebox, by definition. In this case, having to “declare victory” and assess what they were doing should have helped them. But, when this team saw the burndown, two interesting things happened. They beat themselves up for not finishing. And, when they didn’t finish everything, they didn’t always do a retrospective. In addition, the product owner often took the unfinished work and added it to the next iteration’s work. Yes, added, not replaced. That meant they never caught up.
They realized they were “late,” off the ideal line from Day 2. They felt worse about themselves.
They stopped doing retrospectives, which meant they had no idea why they were “late.”
A burndown emphasizes what you have completed. A burndown with the “ideal” line emphasizes what you have done and what you “should” be doing. I have used story points here. You could look at story points against time, looking at the available hours or people days or something like that.
For me, a burndown is interesting, but not actionable. Think about what happens when you take a trip. You plug your destination into your favorite GPS (or app), and it calculates how much longer it will take to get to your destination. You know you have driven some number of miles, but to be honest, that’s done. What’s interesting to you is what you have remaining. That’s what a burnup chart helps you see.
I made these charts from exactly the same data. Yet, I have a different feeling when I see the burnups.
When I see the Story points Done without the ideal line, I see a hockey stick. It’s not as bad a stick as the image in Is the Cost of Continuous Integration Worth the Value on Your Program?, Part 1, and it’s still a significant hockey stick.
When I see this burnup, I can tell by Day 3 that we are “behind” from where we want to be. By Day 5, I know we cannot “make up” the time. As any team member, I can raise this as an impediment in the daily standup. If I am a leader of any sort, I will put this on my list to discuss in the retrospective, if not problem-solve before.
Maybe that’s just the way my mind works. I like seeing where we are headed and what it will take to get there. I’m interested in what we’ve done, but that’s in the past. I can’t address the past except to retrospect. I can address the future and say, “Is there something we can do now to help us accomplish what we thought we could in this timebox?”
George Dinwiddie has a great article on burndown charts: Feel the Burn: Getting the Most out of Burndown Charts.
Oh, and the team I discussed earlier? They decided they were trying to cram too much into an iteration. They made their stories smaller. That put more pressure on their product owner, but then they realized lack of PO time was an impediment. They thought they were to blame with a burndown. They saw their data more easily with a burnup. Maybe we all had a mind-meld going on.
It doesn’t matter which chart you generate. It matters how the chart makes you feel: what action will you take from your chart? If it’s not prompting you to act early, maybe you need a different chart. One project truism is: You cannot “make up” time. You can choose actions based on what your data tells you. Can you hear your data?
I came across the idea of mob programming on an Elixir podcast, Elixir Fountain. Its pair programming on steroids, where you sit together and work on one problem together. There’s still just one driver at a time, though it rotates. There’s already a web site and a conference based on it.
I like the concept, but I’m not sure how effective it would be as a constant practice. I’ve done exercises like mob programming in small doses on particularly hard problems that involve architecture choices and occasionally as an exercise at user group meet ups. Anecdotally I don’t see doing it most of the time, but it is possible it works as a regular practice. It’s different enough that it might need some further experiments.