(Originally posted in 2009 – Updated October 11, 2016)
Canada. We love it. We love it so much that we have decided to completely change our strategy for helping organizations here in our home country.
We have noticed that Certified Scrum Trainers from other parts of the world are starting to offer ScrumMaster training here in Canada. But there is a problem. They aren’t local. They won’t be able to stick close by you as you learn about Scrum, learn about hyper productive teams, and learn to transform your organization.
We are local. Our home base is in the Toronto area and we have experienced coaches and consultants in other areas of the country as well. We are here to accompany you on your journey with Scrum and agile methods. How?
By changing the price on our Certified ScrumMaster seminars. The value in our seminars is huge already: three days (vs. the normal two), the focus on implementing Scrum and obstacles to overcome with Scrum, a focus on leadership in Scrum, and a great deal of experience with both successful and not-so-successful attempts to do Scrum.
We are investing in your success. Our new strategy: make the premier Certified ScrumMaster training course more accessible locally! Come to our seminar. Connect with our trainers and coaches. And rest assured that we will be around to help you out when you need it.
“… this was an outstanding class! I was originally very nervous on starting this role, but now have the confidence needed to successfully implement this role.”
— Kristopher Laughrey [Project Lead of Paychex Inc.] about Certified ScrumMaster course.
“Excellent kickstart for any organization going agile.”
— Yvon Leclerc [Dev. Manager of Espial] talking about Certified ScrumMaster course.
“Overall extremely good, best training I have received in years.”
— Deane VanLuven [Manager of Product Development of Pitney Bowes Business Insight] regarding Certified ScrumMaster course.
We provide courses in:
- … and many locations!
We provide training in:
- Certified ScrumMaster
- Certified Scrum Product Owner
- Leading SAFe
The full description of our course goes into even more detail about the advantages of taking this seminar with us!Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The post Certified ScrumMaster Training – Canada Locations – Excellent Prices! appeared first on Agile Advice.
Today was our annual family visit to the pumpkin patch. We go to a local farm that is a sort of pumpkin theme park. In addition to the fields of U-pick pumpkins, they have a petting zoo, pumpkin launchers, halloween themed play structures, hay rides, and a corn maze. It was a beautiful early October afternoon, and the kids roamed through all the usual activities. Finally we got around to the corn maze.
Now you should know that as these things go, this corn maze is pretty decent. I have no idea how large it really is, but my fitbit tells me that it’s at least a few thousand steps or so. I would guess it’s a walk of a mile or two to get through it. You should also understand that it’s relatively robustly built. You really can’t see any nearby landmarks, and the paths are kept far enough apart that you can’t see other adventurers in the maze. So it’s really quite easy to get good and lost.
So I followed the family in and tagged along behind as we made our way through the maze. I was tired, so I was perfectly happy to let the kids make all the decisions and accept the consequences. The pattern usually went something like this: We would come to an intersection and pause. We would look for clues on the ground. Was one path better travelled than another? Did the curve of the path look like it might actually form a loop? Did the path head in a direction that we thought might be the correct destination? We would ponder these questions and consult as a family before moving onward. So some sort of consensus was arrived at as we reached each intersection.
As I stumbled through the maze following my family, lost in my own thoughts, I started to observe how we were making decisions as a team. At each intersection there was usually some sort of debate. Arguments were made for and against different options. The group would informally arrive at a decision. We had the advantage of multiple brains rather than just one, so you would expect some sort of multiplier effect from using those additional noggins. But it really didn’t feel that way.
Instead we were bouncing around the maze, wandering into loops and blind alleys, and as far as I could perceive, we were not much more successful than someone walking the maze and flipping a coin to decide which direction to go. It was quickly becoming apparent that our success rate was hard to discern from a completely random performance. In fact, at some point I joked that we should be using a 20 sided dice to determine our next move. Geek family.
As we came around a bend I saw another family just standing at an intersection expectantly looking down the path like they were waiting for something. The father came running into view from further down the path and I heard him say rather breathlessly, “There’s nothing down that way guys.” We moved on and I couldn’t help but wonder about that approach. That family was using an interesting strategy. They were obviously making an effort to collect some information about the maze before moving on. That seemed to be one level of effectiveness beyond what we were doing. They were trying to look ahead and gather some intelligence that they could use to help make a better decision about the direction to go in the maze.
We continued to ramble about, but it was soon apparent that the kids were starting to get tired. My wife indicated that it was time for us to bring the adventure to a close before we had a riot on our hands. Dad, stop being such a slacker, it’s time for you to make a few decisions! So that’s when I had an idea.
At the next intersection, I sent a child down each avenue with the instruction to continue until they come to another split in the path and then to report back to me. Off they went. I figured I had two children, so I could afford to lose one with this experiment and still call myself a parent.
At the first junction, the kids came back and one reported a dead end, and the other reported yet another junction. Well that made the decision easy, so off we went. At the next junction however, both kids reported the same thing – there was another junction, but no indication beyond that. So it appears that my look ahead strategy had it’s limitations. There was only so far we could see ahead in the maze using my one intersection strategy. So we flipped a coin and moved on.
At the next intersection, we had a choice between an intersection and an obvious milestone, so we continued toward the milestone. A few more choices like that and we found the end of the maze.
As we celebrated and headed back to the car, it occurred to me that wandering through a corn maze is not all that different from the way that we work on projects as teams.
A project has a lot in common with a corn maze. In principle we all know how they work, but the path from start to finish isn’t all that clear when you start (oh you may THINK it is clear, but let’s face it, there are a lot of unknowns). So you kick off your project and get started and before too long you have to make some decisions. All too often when we make decisions as teams, we do it on the spur of the moment, using only the information that is immediately in front of us. Just like me and the family in the corn maze. We are only using the information that is immediately at hand. Decisions are made quickly with a minimum of information. It’s little better than a coin toss. But there is an alternative.
We can be gathering information to help us make better decisions. There are various names for this kind of look ahead strategy, personally I’m thinking of “set based decision making.“ In set based decision making you explore multiple alternatives. You look down multiple paths, but you don’t go too far. You are gathering just enough information to help you make a good decision now before you proceed onward. Just like with the kids running forward reconnaissance in the maze. This is how you improve the information you use for decision making, and this is how you give yourself a chance to make better decisions.
You see projects have many important decisions to be made. You bump into them daily. Go the right direction and you are increasing your project’s likelihood of success, go the wrong direction and the project is that much closer to failure. These are high stakes decisions with lots of money on the line. So using the corn maze escape strategy is a good one. A small qualification is probably in order here: The look ahead doesn’t give you a crystal ball or a guarantee of success.
The point is that we might benefit from a conscious strategy to acquire knowledge that can inform our decisions. It doesn’t have to be very much additional information in order for there to be a substantial benefit. So the next time you find yourself on a complex project where you have to make tough decisions, remember the corn maze. The strategy you choose can make your journey a whole lot easier.
Filed under: Teams Tagged: Agile, Lean, Set Based Decision Making, Teams
Nearly every client I work with asks me this question at some point during consulting:How large should the Development Team be?
How many doers (i.e. exclusive of ScrumMaster and Product Owner) per team? The Scrum Guide offers very limited guidance, suggesting 3-9, without giving reasons or context for those numbers.
Clearly one generic answer can’t define optimal team size for everyone, but it’s worth knowing what factors should be reviewed, and what the tradeoffs are.
Factors that take into consideration the Development Team’s needs are more important than an arbitrary number:
- A sufficiently broad set of skills to build their product – aka Cross Functional
- Team members dedicated to one and only one team
- Stable membership – i.e. team membership is consistent over a long period of time
- Diversity of thought (and also background) – a sufficiently broad set of ideas, ethnicity, religion, gender, and life experience all spark creativity and diversity of thought.
Once the Team is formed, the following factors seem as important as team size when predicting success:
- Psychological safety – i.e. the environment makes it safe for all team members to share ideas
- Collective Intelligence of the Team – which is strongly correlated with average sensitivity of team members
- Equal Communication – the most expressive team member is no more than twice as expressive as the quietest
- Open Mindedness and Willingness to Learn
The earliest Scrum and XP books all suggest a team size number of 7+/-2, applying Miller’s number – the number of integers you can hold in short term memory – to team size. I’m troubled by the applicability, as I can’t see why one’s ability to keep track of numbers should be correlated with team size. In addition, more recent research has demonstrated that as the things you’re keeping track of become more complex, the number of items you can keep In short term memory drops to 4 or less. So we need more applicable sources.
Many coaches cite historical examples going back to the Roman army and earlier, with small unit sizes of around 8 people. Others observe that Bonobos often split into groups of 6-7 to forage for a day. However, since neither example is about teams doing knowledge work, the relevance to Scrum is limited.Relationships between Team Members
The official equation is N (N – 1) / 2. But what exactly does that mean? More importantly, how is it going to help us? Let’s take what resembles a math class problem, and turn it into something we can actually use in real life. Who knew?
Basically, it tells us how many different relationships will exist within a team of a certain size. N = the number of people in the Team. So in the first example, for N=5 we have 10 relationships. 10 different combinations of team members interacting and developing a relationship with another team member. In the second example, n=7 so we have 21 relationships, and at n=9 we have 36 relationships. Each pair of people represents one relationship and that relationship is how they collaborate. High-performing teams need to have strong relationships between each of the team members.
Why does this matter? Because each new person adds some individual productivity to the team, however each new person also increases the communications overhead. To increase a team from 5 to 7 people, we have slightly more than double the communication costs to maintain those relationships. To go from 7 to 9, we don’t quite double it, but the jump is still large.
Just how expensive is it to maintain these relationships? Anecdotally, having studied team member interactions at clients’ sites, I can say that in teams of 7-8 people, upwards of 90 minutes, per person, each day is spent interacting with other team members. This excludes pair programming time. Some of the interaction is talking about work, but just as much is spent socializing. Which is fine, and important, because it’s the combination of work and socializing that builds a team’s resilience and ability to handle challenges effectively. (See the water cooler section in “Five Steps Towards Creating High-Performance Teams“.) So relationships between team members, and the time investment they require, needs to be a factor that is considered when choosing team size, because it will influence productivity.
A general rule of thumb suggests that people typically have from 3 to 5 hours of productive time at work each day. So as a Team gets larger, we either lose productivity or, more often, we start to withdraw socially rather than sacrifice productive time on interacting with our peers. We need strong relationships to become a high-performing team but, as group size grows, we start to avoid the interactions that build those relationships.Research Backed Evidence
The American Sociological Association published a study by Hackman JR, Vidmar NJ of the “Effects of size and task type on group performance and member reactions”
In this study they got people to complete a number of tasks – a mix of Production (writing), Discussion, and Problem-solving. The participants were placed in different groups sized from 2 to 7. After completing each task, volunteers were asked a number of questions, including two that this graph displays: “was your group too small?”, “was your group too large?”. As you can see from the graph, groups around 4-5 in size seemed to have the least negative reaction. The oft-cited number is 4.6. Key experimental conditions: the volunteers were undergraduate students (all men, sadly), the tasks had a cognitive load but were not programming, and the groups weren’t together long enough for a real sense of “team” to form. Nonetheless, it is an interesting data point.
By the time Hackman wrote the book “Leading Teams” his rule of thumb for team size was 6.
Jennifer Mueller cited in “Is Your Team Too Big? Too Small? What’s the Right Number?”:
if companies are dealing with coordination tasks and motivational issues, and you ask, ‘What is your team size and what is optimal?’ that correlates to a team of six. “Above and beyond five, and you begin to see diminishing motivation,” says Mueller. “After the fifth person, you look for cliques. And the number of people who speak at any one time? That’s harder to manage in a group of five or more.”
But it’s not just personal opinions from team members that educate us on optimal group size; we also have objective statistics. Putnam and Myers surveyed data from 491 projects in a large corporation. These are projects with 35,000 – 90,000 SLOC. They broke projects down into buckets based on the number of people involved in the project: 1.5 – 3, 3-5, 5-7, 9-11, 15-20. On average, the smaller groups (3-5, 5-7) took significantly less time (11.9 and 11.6 months) than the larger groups (17.1 and 16.29 months) to complete similar sized projects.
When you multiply the number of team members times the number of months, you get a graph that is even more shocking:
So a team of 9-11 people took ~2.5-3.5 times as long as teams of 5-7 and 3-5 to complete projects of a similar size. That suggests that teams larger than 7 in this dataset were just a way to spend money faster, because of the increased team size but reduced net performance.Evidence from Agile Projects
Larry Maccherone, in his work through both Rally, Tasktop and AgileCraft, has helped build large datasets about practices in Agile Teams. His data shows:
Based on Larry’s data it would appear that teams of 1-3 are more productive but have lower quality. Teams of 3-5 are marginally more productive than 5-9 although they might still have slightly lower quality – the difference is small. Larry’s notes suggest that he thinks the entire range of 3-9 is fine. I wish the data had split the 5-9 group into separate sets of 5-7 and 7-9 so we could see if there is a noticeable difference in his data at the larger end.My Experience
Other factors that affect team size choices: larger teams spend longer in forming, longer in norming, and therefore longer to reach high performance. Why? Because there are more relationships to be negotiated. As we saw before, on a team of 5 there are 10 relationships that need to form, a team of 7 has 21 relationships etc. More relationships take more time to build and establish trust.
Assuming that everything else is equal (e.g. skills required to get the job done, diversity of thought, etc…), teams of 4-6 seem the best choice. They take less time to form and have productivity that is on par with larger teams. In addition, teams of 5-6 can typically cross-skill enough to cover the loss of one team member after they win the lottery.
I would only choose a team of 7 if other pressures, like required breadth of skills, forced it to happen. I no longer recommend teams of 8, as the additional overhead overwhelms the value of the extra person.
With teams of 9 or larger I recommend splitting into two teams. My own experience mirrors that of other Scrum trainers and coaches – separate teams of 4 and 5 get more done than their original large team.
Why not 3 or fewer? Because it would be too little diversity of thought, and very challenging to have sufficient skills to get the job done. Also, there will be very little collaboration, which correlates with the reduction in quality that Figure #2 shows (data from “Impact of Agile Quantified”). Finally, there are the obvious two-on-one power issues that may make the journey more challenging for one team member.
However, more important than team size is this: does the team have the capacity to get to truly done (i.e. shippable) at the end of every Sprint?
If it doesn’t, then you want to re-examine and reconfigure to achieve a more effective team size.What has been your experience with team size? Too small? Too big? Just right?
- Peter Stevens and his own digging: http://www.scrum-breakfast.com/2014/12/how-many-people-do-you-need-in-your-team.html
- Larry Maccherone and access to all of his work
- Joseph Pelrine for pointing me to original research papers
- Brent Barton for telling me about Putnam and Myers
- Manoj Vadakkan and Angela Johnson for other references
- Pawel Brodzinksi: http://brodzinski.com/2014/01/ideal-team-size-fallacy.html who offers an alternate view
Image attributions: Photodune and Agile Pain Relief Consulting unless otherwise noted.https://www.infoq.com/presentations/agile-quantify
 “What Google Learned From Its Quest to Build the Perfect Team”: http://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html?_r=0 and Psychological Safety and Learning Behavior in Work Teams – Amy Edmondson Administrative Science Quarterly 1999 44: 350 DOI: 10.2307/2666999
 “Evidence for a Collective Intelligence Factor in the Performance of Human Groups” – Anita Williams Woolley, Christopher F. Chabris, Alex Pentland, Nada Hashmi, Thomas W. Malone
 “The New Science of Building Great Teams” – Alex “Sandy” Pentland http://hbr.org/2012/04/the-new-science-of-building-great-teams/ar/pr and also “Evidence for a Collective Intelligence Factor in the Performance of Human Groups”
 “Wisdom of Teams” – Jon Katzenbach and Douglas Smith – stated that the Skills Potential are as important as the skills people currently have in predicting effectiveness.
 Miller’s Number: https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two
 The Magical Mystery Four: How Is Working Memory Capacity Limited, and Why? Nelson Cowan –http://www.psychologicalscience.org/journals/cd/19_1_inpress/Cowan_final.pdf?q=the-recall-of-information-from-working-memory
 This has been very informal observations – just sitting watching what was going on in team spaces and around the water cooler. This time didn’t include lunch breaks.
 This is also documented in: Mueller, J. S. Why individuals in larger teams perform worse. Organizational Behavior and Human Decision Processes (2011), doi:10.1016/j.obhdp.2011.08.004
 Stable reference: http://www.jstor.org/stable/2786271
 Familiar Metric Management – Small is Beautiful-Once Again – Lawrence H. Putnam and Ware Myers http://hbswk.hbs.edu/archive/2996.html
Have you ever gone out with your friends to a karaoke bar and watched someone, who did not speak English, sing the best Bon Jovi Livin on a Prayer you have ever heard, just short of seeing Bon Jovi live back in 1987? I’ve seen both. Have you ever worked with or for someone who follows a process or framework to the letter but does not have the first clue why they are doing what they are doing? Again, I’ve seen it.
The major difference is one is singing a song for personal entertainment and the other is potentially wasting time, money, and putting projects or product delivery at risk.Cargo Cult
The name is derived from the belief among Melanesians in the late 19th and early 20th century that various ritualistic acts such as the building of an airplane runway will manifest in the appearance of material wealth, particularly cargo, via Western airplanes, though the meaning of the behavior is more complex than a simple misunderstanding. That mouthful is brought to you from Wikipedia.
I hear cargo cult referenced a lot in the Agile community. I’ve been to half a dozen Project Management conferences and never heard the term once. I’ve been to an equal number of Agile conferences and heard it used every time. We reference it all of the time, referring to the rituals of Scrum, SAFe, and other frameworks. People memorize the frameworks but don’t know why they are doing the rituals. They have little hope of improving upon a framework, if they follow rituals blindly.Agile Translation
I recently wrote that the Agile community should consider using terms anyone understands. If I said cargo cult, I would have to spend the next few minutes quoting what I wrote above, to explain it to a customer. It could make you feel smart, needing to educate someone on a new term. But, why not use a new term like karaoke agile? First, I know the Agile community LOVES to use Japanese words. With a Japanese word origin, from kara empty + ōke, short for ōkesutora orchestra, practitioners should be all over this! For better or worse, I don’t know anyone who doesn’t know what karaoke is. This includes anyone outside the Agile community.Karaoke Agile
Combine words of Japanese origin and the word Agile. Stop using the term cargo cult when describing people or organizations that follow processes or frameworks without understanding why they do it. Win-Win.
- Sponsored: 64% off Code Black Drone with HD Camera
Our #1 Best-Selling Drone--Meet the Dark Night of the Sky!
Many years ago I suggested a noble cause for Scrum Masters…to create an amazing workplace and to have happy product owners. Pretty simple right?
While measuring the happiness of others will always be subjective, the premise of this noble cause is to stress the importance of creating an environment for product owners to thrive and a workplace intentionally designed to bring a product to life in a vibrant and productive way.
Before we jump into how we can create this happy and healthy environment for product owners and teams to do their work, let’s align on what we expect from a product owner in the first place. In the simplest of terms, an organization needs a product owner to:
Envision a future that doesn’t exist today. Within the context of their product (and perhaps beyond), they are visionary. They are able to conceptualize and visualize a “new world” others can’t see.
Bring us one step closer to this visionary future every day. This means they are decisive. Their decisions will range from easy to hard and from small to large but the decision-making opportunities required to see their vision become a reality will be ever present and no one else will make them.
Build the communities necessary to bring the vision to life. A product owner is constantly strengthening relationships inside and outside of their team. This includes their customers (or the users of the product) but will also include leaders, stakeholders, technical experts and especially those on their team.
As you can see in this sketch, product owners are being pulled in multiple directions.
There is a pull between where we are going (visionary things), what we are doing (delivery things), and how we work together (community things). And the product owner is at the center of this natural tension.
So given the “linchpin” nature of this role and the natural tension this role will need to navigate every day, what are the characteristics of the happiest product owners I have experienced? Here are 9 of them:
They are immersed with their customers. While this will vary from product to product, product owners should spend a good chunk of their time visiting and observing customers and users. Ideally, this is out of the office but go where your customers are located.
Finding the right amount of time for product owners to spend with users is tricky but I suggest starting with at least one day a week. This consistent immersion increases product owner happiness because their degree of empathy grows with each interaction and heavily informs the shape and size of their vision. Hypothesis should emerge about how the life of the people using their products will be positively impacted.
They have the time and space to be visionary and creative. Product owners need to allocate time to take what they are learning and translate this into a product vision and a series of experiments to run to validate the hypothesis forming their vision. This usually means blocking sections of time each week just to study and think. While we love having our product owners immersed with the team, I suggest changing their scenery every once in awhile by getting them out of the office to find their creative space and reduce distractions. This could mean sitting in a Starbucks or browsing a local library.
They have true ownership over their product. The role of product owner must be given autonomy. While we may say they are “owners,” in reality, they are often negatively influenced or second-guessed by others. This is a recipe for frustration and unhappiness. The happiest product owners are fully trusted by their organization but especially by their leadership. What if a leader or stakeholder doesn’t trust a product owner? I briefly covered this here but will address more on this subject in a future post.
They are receiving meaningful input about the performance of their products. Similar to how being with their customer/users increases confidence so does having quality data about how people are adopting and using the features of the product. With these metrics in hand, they can redefine their hypothesis, run more experiments and adjust their vision.
They have a positive working relationship with their Scrum Master. This relationship is centered around conversations about the health and flow of the team. Use these starter questions if you’re not sure where to start building this relationship: Is the team healthy? (energy, engagement, enthusiasm, sense of community, and the growth of people) How well are we doing in meeting our forecasts or commitments? (velocity, burn charts, and retrospective findings)
They have an even better relationship with technical leads and designers. The connection between the perspectives of value, feasibility and usability should be strong and balanced. Marty Cagan has excellent insights into how this relationship should work in his book “Inspired” and on his blog.
They are proud of what the team is delivering. Happy product owners have a strong connection with their team and builds empathy around the nature of creating and deploying products. In exchange for this empathy, the team should be striving for high levels of craftsmanship. Other than not meeting the needs of their customers/users, nothing stops an agile team faster than poor quality. And this equates to an unhappy product owner – even if they wouldn’t say anything publicly.
They have embraced their constraints. Happy product owners have become comfortable with thinking in short iterations and getting things into the hands of their users as quick as possible. They have developed the “small things” MVP (minimum viable product) muscle and are making many small bets within their product instead of big bets. They understand perfect isn’t the goal – but incrementally delivering what users perfectly need is.
They are keeping themselves healthy. I wrote about how important it is to keep our batteries charged and energy high in the Becoming a Catalyst book for Scrum Masters and this is equally as important for our product owners. Because of the demands of the role, one can easily burn out or lose passion around their product. So whatever it means for you to stay healthy – nutrition, sleep, exercise, family time, quiet time – make this your first priority.
Yikes, this is a long list. No one said this would be easy! But ultimately happy product owners find a healthy balance between visionary things, delivery things and community things. While the following schedule would probably never happen in reality, here is what a week in the life of a happy product owner might look like:
- Monday is for visits outside the office. You spend your day watching, listening, and learning. Bring team members like developers and tests along with you!
- Tuesday morning is an opportune time to think about what you just learned and to tweak your vision and roadmap based on what your users are telling to you. In the afternoon, block off a healthy chunk of time to synchronize around the vision and roadmap with your designer and technical lead.
- Wednesday is the time to make decisions about your vision by blocking time to work on the product backlog and to have conversations with leaders and stakeholders about the decisions you are making. Maybe have lunch or coffee with your Scrum Master or other team members you need to connect with.
- Thursday is team ceremony day. You are fully engaged and energized. Your vision is coming to life and your presence motivates the team to be energized as well.
- Friday can be allocated to catching up on administrative tasks and for building community within the team. This is the time to make sure YOU are staying healthy.
To all the product owners out there, thanks for taking on such a challenging role. My hope is for us to help foster an environment for you to thrive and be, dare we say it, an even happier product owner.
Don’t forget to checkout the behind-the-scenes story behind this post at The Illustrated Agile Podcast.Becoming a Catalyst - Scrum Master Edition
This is an excerpt from The Simple Leader: Personal and Professional Leadership at the Nexus of Lean and Zen
Once, after a particularly claustrophobic, stressful and
over-populated time when there hadn’t been air or space to escape to, suddenly, for a few days, I was alone. It was like emigrating to another planet (in fact I was at home). Who was this person I was living with, this strange, this reasonable, serene foreigner in the house: a becalmed woman who spent her time inwardly humming?
– Mirabel Osler
After meditating and focusing inward for several weeks (or even months), you may realize something: you aren’t who you thought you were. This moment of understanding your true nature, known as kensho in the Zen realm, can be a bit terrifying. What if I told you that your understanding of who you are would continue to evolve and change?
This understanding can be very powerful from both personal and professional leadership perspectives. Your confidence in your decisions and your intuition will increase. You will feel and be seen as more authentic. Life will be more satisfying.
Understanding who you are helps you identify your purpose, and knowing your purpose enables you to focus your efforts on improvement. Embrace and think about the unfolding revelation of your true nature. How does it change your leadership style, your decisions, your commitment to your family, and your career choices? Allow and relish those changes.
- Sponsored: 64% off Code Black Drone with HD Camera
Our #1 Best-Selling Drone--Meet the Dark Night of the Sky!
Our Customer Success team is excited to introduce Office Hours, a virtual meeting room where our experts...
Often teams will start getting into trouble with quality issues and looming ship dates as they close in on that ship date. They'll want to make changes but assume it's too late. It's not.
Recently I visited a team that was a few months away from their first release on Steam. They were confronted with a ton of debt and there wasn't much direct cross-discipline communication going on. After some training, which included deep conversations about the short and long term vision of where to go, they decided to focus on prioritizing the debt and improving the definition of done. This slowed down the introduction of new features they wanted, but it allowed them to better triage the quality of the game. They agreed that the quality of the existing game was more valuable than the number of features.
What they didn't do was radically reform the teams to make them perfectly cross-discipline. A few key changes were made and some over-multitasked people were helped out, but we agreed that overhauling the entire organization at that point was too risky.
This training and discussion took several precious days away from people focused on delivery, but we felt it was worth it. Sometimes we get so focused on what we're trying to do that we forget how we're doing it and how we can improve that.
You’ve probably heard by now that Rally Software has become part of the CA Technologies family. As a result we’re moving the agile blogs you know and love from here, to there: http://blogs.ca.com/tag/agile-management/.
Beginning in mid-October, the Rally blogs will no longer be available in their current locations.
We’ve already moved our most popular blog posts over to the CA Highlight blog. You'll find the same great agile management topics and content written by your favorite bloggers, with added links to interesting, related content. The technical (engineering, development, DevOps) blogs will live at CA Highlight as well.
So set a new bookmark to the CA Highlight blog or subscribe using the link at the bottom of the page. Then, browse the Agile Management and Technical Innovation categories to see posts you may have missed, and check out authors new to you from the CA family. See you there!Rally
Being “outside-in”, “outcome-based”, and “market-driven” is particularly important for creating successful products. The problem is that just saying the words is not enough to help someone shift their thinking. For those of us who are already thinking this way, the phrases become touchstones or short-hand. For folks who are not there yet, these may sound like platitudes or empty words. I know many people who want to switch their roles from “do these things” to “solve these problems.” They have to change their organizations. This example may help get the point across.Contact Manager
I was part of a messaging conversation on my phone last month with three other people (a group MMS). Instead of seeing 3 names, I saw two names and one phone number – not a good way to identify the participants. Because I’ve helped create a messaging app before, I happen to have some insight into how the app is likely to work. When the app receives a message, it receives a “payload” which combines the message with other information about the message (data and meta-data). The payload including the messages and several phone numbers identifying the participants in the conversation. The app then checks the list of contacts on my phone – and for each matching phone number, replaces the phone number with the person’s name. The unmatched phone numbers stay unmatched.
I’m mentioning how the app might work on the inside, because that’s the situation facing people with an inside-out perspective. Specifically because they know how it happens to work – they frame discussions around making changes to what a thing does by changing how it does them. The curse of knowledge undermines market-driven #prodmgmt.
I was able to infer the identity of the unnamed participant because of the context of the conversation. I started the process of adding that person to my contact list. I entered the person’s name, and the messaging app pre-populated the mobile phone number for me. Very convenient. My brain shifted into “requirements management” mode for a moment, and I imagined writing a user story.
As a participant in an SMS conversation, I want to be able to add unidentified people to my contact list…
The important missing piece of the user story fragment above is the intent. As a persona, I want to do some activity (with some frequency), so that I realize some benefit. At first glance, it looks like there is intent – “to add…” but that’s not intent, it is only activity. Don’t confuse action for intent in user stories.
A common mistake would be to write
As a participant in an SMS conversation, I want to be able to add unidentified people to my contact list.
This story has the “feel” of a programmer who is writing the code first, and then documenting the design second. Intuitively, you want to be able to change context from what you’re doing (participating in a conversation) to do some tidying-up (adding someone to your contact list). People like to organize stuff. Especially programmers.
That doesn’t seem quite right – the intent seems off. It feels like someone has already decided this feature is required, and as part of working their way through the list of imagined features, is shoehorning their “inside out” desire into a story syntax designed for communication of discovered customer intent.A less-common mistake would be to write As a participant in an SMS conversation, I want to be able to add unidentified people to my contact list so that I can keep my contact list current. Again, this smells like an inside-out story. Imagine a user has told you they want this. This still would be an example of focusing on the problem manifestation (an out-of-date or incomplete contact list) instead of the problem – identifying people. Users almost always fixate on problem manifestations, versus underlying problems:
- My contact list is missing this person vs. I need to know the identity of this person.
- My phone does not ring loudly enough vs. I am not noticing incoming phone calls
- I need a faster horse vs. I need to get to my destination faster.
Maybe “knowing who someone is” requires more than just “Carla” ; maybe it requires “Carla – you spoke with her about wearable technology at the event at the Citadel hotel on Saturday night.” Have an elegant way for the application to inform you about which Carla it is and how you’re connected.
These are all creative means of solving the problem which your team is not as likely to explore when you tell them you want to “update a contact list.” You miss out on an opportunity to innovate – to invent something valuable – by focusing on an inside-out description of a problem manifestation.Conclusion
Focusing your product creation on solving problems is subtly but powerfully different than focusing on creating features.
Your team can only make what you ask for when you tell them how.
Your team can do truly amazing things when you tell them why.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]