Skip to content

Feed aggregator

Forty8Fifty Labs Launches Splunk Connector for Atlassian JIRA

Scrum Expert - Tue, 10/11/2016 - 18:59
Forty8Fifty Labs has announced the Real-Time Splunk Connector for Atlassian JIRA Service Desk. The new solution leverages advanced analytics and reporting to provide a big picture view across all service desk environments so DevOps teams can better understand the incident trends that often create persistent or intermittent service issues. The Real-Time Splunk Connector for Atlassian JIRA Service Desk from Forty8Fifty Labs can trigger enhanced, real-time alerts within HipChat to arm development teams with the information and context they need to build system performance and reliability. Leveraging real-time Searches in Splunk to trigger configurable levels of service incidents associated with JIRA Service Desk, the new product empowers teams to close the loop on responses to issues taking place in their environment. Taking the value a step further, the new product also provides rich visual data analytics on both the operational occurrences taking place along with the Service Desk experience associated with it. This provides development and operations teams with an anytime, anywhere view of the state of their service request and delivers the detailed information needed to act fast. Key features of the Real-Time Splunk Connector for Atlassian JIRA Service Desk include: * Automated incident creation driven by real time search events * Relevant troubleshooting detail linked directly to incident from inception * Integrated alert notification to HipChat Rooms (when using HipChat) * Rich Visual Data Analytics of both Incidents Patterns and Service Desk Experience
Categories: Communities

DSDM Consortium Renamed as Agile Business Consortium

Scrum Expert - Tue, 10/11/2016 - 18:25
The DSDM Consortium, author and custodian of the world-leading DSDM Agile Framework, has announced a new identity and a major new Agile approach. The Agile Business Consortium unveiled its new name and look as it launched the Agile Business Change Framework, designed to support businesses and organisations in adopting Agile at any organisational level and on any scale. Agile Business Consortium CEO Mary Henson said: “Some years ago, Agile became the mainstream approach to software and systems development and in those fields it’s now used more than any other approach. Increasingly, businesses recognise the benefits of adopting Agile methods in many different parts of the enterprise but struggle to understand how to enable it, implement it and ensure robust governance. “The Agile Business Consortium has evolved to address those challenges and, particularly, to develop the Agile Business Change Framework – a new framework that will enable businesses and organisations to take an Agile approach wherever in the enterprise it’s needed and on whatever scale it’s needed.” Building on more than 20 years’ experience in developing DSDM’s highly successful project management and programme management frameworks, the Agile Business Consortium has been developing the new Framework with selected partners and early adopters such as PwC, Tata Consulting and others. It will continue to build a community of like-minded partners to progress the Framework and will provide supportive training through a network of accredited organisations.
Categories: Communities

Using Sprint Data to Modify Behavior

Scrum Expert - Tue, 10/11/2016 - 16:39
In an ideal Agile world, the Scrum team can complete all user stories tasks that it planned for the current sprint. The real world is however different. In this article, Scott Lively explains how to use the sprint data to modify the team behavior. In his introduction, Scott Lively explains the feeling of having some user stories not completed during a sprint and the importance of analyzing the sprint data to improve. The article will focus on the percentage of story points coming from new content versus points from carryover content, and the percentage of points added after sprint planning. His analysis of the issues causing the fact of having often carryover user stories at the end of the sprints led Scott Lively to explore the following improvement opportunities: * Writing smaller and better user stories to improve the sprint estimation process * Taking more time to understand the scope of user stories * Cross-training for the Scrum developers so that there are more resources available for all the different activities and technologies involved in software development * Having a mid-sprint assessment meeting to determine of how likely it is that everything planned for the sprint will be completed. This could lead to change the sprint plan and it also gives the Scrum developers another explicit opportunity to help each other. His conclusion is that “The bottom line is that we need to continue measuring how we do sprint over sprint. Further, we need to be careful about the behaviors [...]
Categories: Communities

Certified ScrumMaster Training – Canada Locations – Excellent Prices!

Learn more about transforming people, process and culture with the Real Agility Program

(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:

  • Waterloo
  • Toronto
  • Ottawa
  • Edmonton
  • Vancouver
  • Regina
  • … and many locations!

We provide training in:

  • Certified ScrumMaster
  • Certified Scrum Product Owner
  • Leading SAFe
  • Kanban
  • OpenAgile

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.

Categories: Blogs

The Corn Maze Strategy

Agile Tools - Tue, 10/11/2016 - 06:52


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
Categories: Blogs

Agile Cincinnati, Cincinnati, USA, October 17 2016

Scrum Expert - Mon, 10/10/2016 - 17:26
Agile Cincinnati or Agile Cindy is a one-day conference focused on Agile software development and Scrum project management. It has a wide range of Agile topic coverage to suit the needs of early adopters and certified Agile professionals. It is also a unique opportunity in Cincinnati to learn and experience Agile while networking with leading professionals. In the agenda of the Agile Cincinnati conference you can find 24 breakout sessions covering software development, scaling Agile, change management, product ownership and Agile process. Some session will also follow the open space format for conferences. Open space is a simple methodology for self-organizing conference tracks. It relies on participation by people who have a passion for the topics to be discussed. There is no preplanned list of topics, only time slots and a space in the main meeting room where interested participants propose topics and pick time slots Web site: Location for the Agile Cincinnati conference: Northern Kentucky University, 100 Louie B Nunn Dr, Newport, KY 41099
Categories: Communities

Agile Dev East, Orlando, USA, November 13-18 2016

Scrum Expert - Mon, 10/10/2016 - 17:11
Agile Dev East is a full week conference that includes presentations and workshops around Agile software development and Scrum project management. Agile Dev East is held in conjunction with Better Software and DevOps East, allowing you to choose from three distinct programs. In the agenda of Agile Dev East you can find topics like “Creating a Continuous Delivery Pipeline: A Hands-On”, “Fostering Sustained”, “Principles and Practices of Lean Software Development”, “Planning to Learn and Learning from Delivery: Scrum, Kanban and Beyond”, “Acceptance Test-Driven Development”, “Help Retain Knowledge: Increase Engagement to Achieve Learning”, “Agile Project Failures: Root Causes and Corrective Actions”, “Scrum: Answering the Tough Questions”, “Advanced Test Automation in Agile Development”, “Producing Products and Coaching Agility: Make Agile Practices Matter”, “Plan, Architect, and Implement Test Automation within the Lifecycle”, “Lean/Agile Metrics for the Rest of U”. Web site: Location for the Agile Dev East conference: Hilton Orlando Lake Buena, 1751 Hotel Plaza Boulevard, Lake Buena Vista, FL 32830
Categories: Communities

Choosing the Team Size in Scrum

Notes from a Tool User - Mark Levison - Mon, 10/10/2016 - 14:20


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[1]
  • 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[2]
  • Collective Intelligence of the Team – which is strongly correlated with average sensitivity of team members[3]
  • Equal Communication –  the most expressive team member is no more than twice as expressive as the quietest[4]
  • Open Mindedness and Willingness to Learn[5]
Team Size Numbers

The earliest Scrum and XP books all suggest a team size number of 7+/-2, applying Miller’s number[6] – 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[7] 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

 Agile Pain Relief Consulting

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[8]. 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[9].

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”[10]



Figure 1 – Source: Hackman JR, Vidmar NJ. Effects of size and task type on group performance and member reactions. Sociometry. 1970;33 :37-54.

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.[11]

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[12]. 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:

 Agile Pain Relief Consulting

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:

Used with Permission from Larry Maccherone – from Impact of Agile Quantified Late 2014

Figure 2 – Used with Permission from Larry Maccherone – from Impact of Agile Quantified Late 2014

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?

Thanks to:

Image attributions: Photodune and Agile Pain Relief Consulting unless otherwise noted.

[1] “Impact of Agile Quantified” – Larry Maccherone demonstrated that dedicating team members to one team doubled productivity and stable teams improved productivity by 60%.
[2] “What Google Learned From Its Quest to Build the Perfect Team”: and Psychological Safety and Learning Behavior in Work Teams – Amy Edmondson Administrative Science Quarterly 1999 44: 350 DOI: 10.2307/2666999
[3] “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
[4] “The New Science of Building Great Teams” – Alex “Sandy” Pentland and also “Evidence for a Collective Intelligence Factor in the Performance of Human Groups”
[5] “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.
[6] Miller’s Number:,_Plus_or_Minus_Two
[7] The Magical Mystery Four: How Is Working Memory Capacity Limited, and Why? Nelson Cowan –
[8] 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.
[9] 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
[10] Stable reference:
[11] Familiar Metric Management – Small is Beautiful-Once Again – Lawrence H. Putnam and Ware Myers
Categories: Blogs

Karaoke Agile

Leading Agile - Mike Cottmeyer - Mon, 10/10/2016 - 14:13
karaoke agile

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.




The post Karaoke Agile appeared first on LeadingAgile.

Categories: Blogs

Links for 2016-10-09 []

Zachariah Young - Mon, 10/10/2016 - 09:00
Categories: Blogs

Even Happier Product Owners

Illustrated Agile - Len Lagestee - Mon, 10/10/2016 - 04:38

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.

The Role of a Product Owner

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

The post Even Happier Product Owners appeared first on Illustrated Agile.

Categories: Blogs

The Simple Leader: Evolution

Evolving Excellence - Sun, 10/09/2016 - 10:21

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.

Categories: Blogs

Links for 2016-10-07 []

Zachariah Young - Sat, 10/08/2016 - 09:00
Categories: Blogs

Introducing Office Hours

Our Customer Success team is excited to introduce Office Hours, a virtual meeting room where our experts...

The post Introducing Office Hours appeared first on Blog | LeanKit.

Categories: Companies

When to adopt agile on your game?

Agile Game Development - Fri, 10/07/2016 - 17:46
A frequent concern for adopting agile practices is when to do it.   Most would prefer to do a major transition of practices and roles at the start of developing a new game.  There are definitely benefits in timing training and a shifting of roles and responsibilities then, but it's not the only option.

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.
Categories: Blogs

We’re Moving: Rally Blog Has a New Home on CA Highlight

Rally Agile Blog - Thu, 10/06/2016 - 17:24

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:

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!

Categories: Companies

Fighting for Value

Scrum Expert - Thu, 10/06/2016 - 17:23
Business that want to earn money and people who want to make a difference! In the morning everything looked so promising. When they met it was a disaster. Will the goals be achieved? Can the dream survive? You will dive into the story and live it through. You will see emotional snapshots from people’s lives that eventually brought them to the real value(s). In this presentation you will learn: * How the everyday life for Business owner and developers can go wrong. * Ignorance and wrong expectations creating waste. * How Agile way of thinking can make things to the better. * Real collaboration that matters. * Early delivery and value of short feedback loops. * Moving from quantity to the real value. Video producer:
Categories: Communities

Outside-In User Story Example

Tyner Blain - Scott Sehlhorst - Thu, 10/06/2016 - 12:48

thumbnails in a messaging app identifying conversation members

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.

JSON extract of messaging payload

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.

organizing colored books on shelves

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.
Underlying Intent The underlying intent of your user (or stakeholder) is the requirement.  When you express requirements inside-out (with a presumed design approach) you miss out on opportunities to make a markedly better product.  How you articulate the requirement unequivocally biases and constrains the solution-space within which your team will solve the underlying problem.  Consider our example, of not being able to identify all of the participants in the conversation.  When you give your team “As a participant in an SMS conversation, I want to be able to add unidentified people to my contact list.” they will design a way to do exactly this. They could craft an elegant workflow where the user long-presses on the phone number of the unidentified party, and the phone presents a minimally disruptive interaction – perhaps adding only first and last name – and then returns the user to the conversation.  The phone may even create a notification which pops up only after 5 idle minutes pass, indicating the conversation is complete – encouraging the user to provide additional information.  Sounds great, right? Here’s the problem.  The user does not want to update their contact list.  The user does not care about having a contact list.  The user wants to know who is in the conversation.  Let’s rewrite the story like this: As a participant in an SMS conversation, I want to know who all the participants in the conversation are. Now your team can design things like the following solution to the underlying problem. If there is a contact list, and the phone number matches an identity, use it. If not, update the contact list once the identity of the participant is discovered. Attempt to infer the names of the participants from the context of the conversation (and other conversations including the same phone number – even from other users. Perhaps the platform provides backup and restore capabilities, including saving messages – that data can be mined for the identity of the person associated with the phone number. Perhaps your messaging app is part of (or owned by) a social network or some other product or service which has an index mapping identities to phone numbers – now you can look it up directly. Go one step further – don’t just infer the name, find the profile picture associated with the participant. Find the participant’s avatar. Then automatically update the messaging app to replace the phone number with the avatar and/or name. Use whatever technique is most elegant to “remember” identities in the future.

automatic recognition of a person

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.


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.

Categories: Blogs

Rules Governing Software Innovation That Do Work

NetObjectives - Thu, 10/06/2016 - 12:47
In my last blog post, I talked about the parallel between designing a game and transforming an organization along Lean and Agile tenets. Both involve defining rules that people will follow; both may start from the assumption that you need a rule for everything. If you design the rules correctly, according to this approach (the technical term, in game design parlance is design for cause), you'll...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Knowledge Sharing

SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.