You are hereFeed aggregator

Feed aggregator

3 Thinking Tools for Minimizing Dependencies Between Products

All About Agile - Tue, 03/03/2015 - 04:00

In my post about how to form teams, I talk about products… not in their monolithic, holistic state… but as a subsystem within a larger integrated solutions architecture. In other words, big products are just series of small products that work together in an integrated fashion. Each of these smaller products have a backlog, a […]

The post 3 Thinking Tools for Minimizing Dependencies Between Products appeared first on LeadingAgile.

The Evolution of Teams

All About Agile - Tue, 03/03/2015 - 00:19

My other workshop submission for the Agile 2015 Conference is titled “The Evolution of Teams” and examines one team that stopped doing the traditional agile practices is more agile than ever. Agile practices such as daily stand up meetings, sprint...

Bend the Spoon

All About Agile - Mon, 03/02/2015 - 04:00

Bend the spoon is a phrase we use quite a bit here at LeadingAgile. I don’t want to hear what’s happening, I want to hear what we need to make happen… and what we are doing to make it happen. I don’t want to hear why we can’t do something, I want to talk about what […]

The post Bend the Spoon appeared first on LeadingAgile.

Fueling Delivery Teams

All About Agile - Fri, 02/27/2015 - 13:52

I’ve started using an analogy to illustrate the importance of product owner teams in larger organizations.  When working with organizations to do an agile transformation, almost always, a tiered model is used for scaling across the organization. The model looks something like this: The top tier is portfolio management which is responsible for investment decisions and […]

The post Fueling Delivery Teams appeared first on LeadingAgile.

Changing Behavior by Asking the Right Questions

All About Agile - Fri, 02/13/2015 - 20:16

My article, Agile Adoption: Changing Behavior by Asking the Right Questions, has been published over on (free registration required). It talks about when managers want change, but don’t want to squeeze the Agile out by force.

Can You Mandate Your Agile Transformation?

All About Agile - Fri, 02/13/2015 - 02:00

Well… it depends. If you view agile as a system of beliefs, or a way of looking at the world, or as a culture your company is expected to adopt…I’d suggest that it’s impossible to mandate an agile transformation. There is no way to force people to believe in something they don’t believe in or to […]

The post Can You Mandate Your Agile Transformation? appeared first on LeadingAgile.

The Simplest Systems Thinking Exercise – How to Make Toast.

All About Agile - Wed, 02/11/2015 - 21:27

For many years one example of process thinking, resource gathering, requirements, implementation and acceptance criteria has been the exercise - make PB&J sandwiches.  I've done this with groups to discuss the simple task that we typically ove...

Retrospective Technique: What Did You Learn?

All About Agile - Tue, 02/10/2015 - 18:29

Learn more about our Scrum and Agile training sessions on WorldMindware.comRetrospectives are a key part of continuous improvement in Agile teams.  The retrospective techniques that a team uses should be adjusted to the needs of the team.  In a Scrum … Continue reading →

How It Works: User Stories

All About Agile - Thu, 01/29/2015 - 08:00

Next Tuesday, February 10, our TeamStart webinar series will answer your questions about "Writing Great User Stories." Whether you’re just getting started with Agile or consider yourself an expert, join us to get and give some good Q+A. We’re going to talk about writing compelling stories that focus on business value. Here are a few questions from past "User Stories" webinars:

  • What are some tips for writing a great user story?
  • When do I break down user stories?
  • Who should drive the definition of acceptance criteria?

Here's a preview of what you'll learn in the TeanStart webinar.

Tips for Writing a Great User Story

A great user story has three areas of focus: Who, What, and Why. A great user story is also written from the perspective of the user (hence the name); and a great user story "tells a story" about what that user wants to be able to do, and why (for what outcome.)

Who: Define the person who receives value from a new user story. For example:

As a user of the website ...
As an internal team member ...

What: Indicate what needs to be delivered, from the perspective of the user. For example:

... I want to purchase my items with a credit card ...
... I need a new testing infrastructure ...

Why: Show the value the user gains from the story:

... so that I have a convenient and secure way to pay electronically.
... so that I can prepare for the new test requirements of our organization.

When to Break Down User Stories

When the estimated size of a user story exceeds the total velocity available in a team’s iteration, the story cannot fit and must be broken down into smaller stories. User stories can be broken down multiple times as they move up the backlog -- transitioning from a large, loosely-defined, parent story into a set of small, defined, child user stories that make progress towards the overall goal.

Who Should Drive the Definition of Acceptance Criteria

The entire development team assists the product owner in creating acceptance criteria. Product owners represent the business and stakeholders, and communicate the needs of a story to the team. Teams communicate with the product owner about what implementation methods are possible, and how a story may be completed to meet business needs.  

What are your questions? Get them answered. Join the TeamStart webinar series on Tuesday, February 10th, to learn about "Writing Great User Stories."

Rob Ward

What’s in a Voice? Communicating Who You Are

All About Agile - Tue, 01/27/2015 - 10:00

Learn more about our Scrum and Agile training sessions on WorldMindware.comIn doing business of any kind, we commonly follow the advice to “dress for success.” For better or for worse, we can be judged visually in the first few seconds … Continue reading →

Scrum Alone is Not Enough

All About Agile - Mon, 01/26/2015 - 02:11

To be successful with Scrum in the long term you need more than the basic framework. This is intentional. Scrum provides the structure as a starting point, but it’s designed to work well when applied with other effective patterns. Like the Design Patterns movement of the late ’90s, a pattern can be used by itself or with others. E.g. the Command Pattern and the Memento Pattern can be combined to build an effective undo/redo system. Scrum is only one pattern for one team. It gives you the bare minimum framework that could possibly work, however in many contexts you will need to incorporate other tools/patterns to build more effective systems. Beyond Scrum you should consider: –       Effective Agile Engineering Practices – such as Unit Testing, Continuous Integration, Test Driven Development, Acceptance Test Driven Development (or BDD), Pair Programming. Without practices like these, the health of your codebase will degrade over time. –       Kanban – (a tool to understand and improve flow) to help understand the flow of work at both the team and organization level. Without a good understanding of flow of work through the organization, we might make a change that is a local improvement but harms the whole. –       Portfolio Management – the art of making big picture decisions about which major chunks of work the business would like focused on next. Organizations need portfolio management to ensure that major priorities are understood by the team’s Product Owners and worked on in priority order. –       Organizational Improvement – many issues that Scrum helps to find can’t be solved by the team or their ScrumMaster. Instead, organizations need to establish an ongoing improvement team dedicated to resolving these problems. –       Intra Team Coordination – How will you coordinate the work among teams? Scrum of Scrums is the most well known pattern and yet is rarely the best choice. –       Team Organization – How will you organize your teams? As Component Teams? As Feature Teams? Using the Spotify model of Squads, Tribes and Guilds? There are no best practices. Scrum itself could prescribe all of this, but that would be missing an important Agile point: there are no best practices. A practice that works well in one organization (or context) may not work well in yours.  This is especially true when it comes to working effectively at a large scale where repeatable patterns are only just starting to emerge. Even where consistent patterns are starting to emerge (i.e. Large Scale Scrum, Enterprise Scrum, …), it is often unclear which one will apply in a specific context. Finally, remember that Scrum isn’t intended to fit your current organization and its existing structure. It is intended to force us to consider what is working and what needs improvement. Scrum is just the starting point.   In the next few months, I will explore patterns that can be effective when attempting Scrum at a larger scale (more than three teams). What topics would you like me to explore?

Big Agile, the Route Less Travelled

All About Agile - Thu, 01/22/2015 - 21:40

Scaling Collaboration not Process is the Key to Enterprise Agility. Agile methods have been found to be extremely effective when used correctly. A reasonable reaction to witnessing any great performance in an organization is to demand more of it. So...

5 Steps for Creating High-Performance Teams eBook

All About Agile - Mon, 01/19/2015 - 02:44

Certified Scrum Trainer Mark Levison has been around the block, more than a few times, and he was getting frustrated by what he saw happening in Scrum. When Mark is invited into businesses and industries to talk with Scrum teams, it’s typically with the request to help them do Scrum better so they can be more productive. But practicing the mechanics of Scrum is not the answer to high performance. Yes, you’ll get some benefits, but not the most important ones. You can focus on the ceremonies – the daily stand-ups, the sprint planning, the retrospectives – and still not get the performance you’re expecting, or seeking. So… why? What’s the secret? What’s the magic formula? That’s what Mark wanted to know, which led him to study the elements that are found in high-performing teams. And what he discovered was actual neuroscience and behavioural psychology that makes the social aspects of team building surprisingly clear in their importance. Now Mark has taken what he learned in those discoveries, and formed them into five proven and practical Agile steps that can put a team on the path to high-performance success. And here’s sharing them with you now, here: A free eBook of the “5 Steps Towards Creating High-Performance Teams“. This outlines the key elements, the magic and neuroscience behind them, and how to implement them with your team. The High-Performance Teams Game. Fun downloadable resources to help teams see the effects of choices/tradeoffs on productivity and team cohesion. This handy – and, dare we say, snazzy – infographic to summarize, focus, and remind.   Building a high-performing team doesn’t have to be complicated, nor is it luck of the draw. Surprisingly, most of it is simply common sense and awareness of human behaviour and relationships. That’s it.

Welcome to the High-Performance Teams Game

All About Agile - Mon, 01/12/2015 - 02:50

Your team is working on the World’s Smallest Online Bookstore, a site that provides the best results (just a few) for every search, not every result on earth. We’re a vulture capital funded company, so if we don’t deliver, our funding will be cut. So begins the opening of the High-Performance Teams Game. My goal is to help you see the effects of choices/tradeoffs on productivity and team cohesion. While some of the benefits of Agile happen at the individual level, there are many things that affect the relationships between team members, and therefore the overall cohesion and productivity of the team. The game is played by a team of 5-9 people, in a series of  5-6 rounds. During each round there is a little bit of teamwork, a little bit of discussion of the science, and some game play. Each round represents 6 weeks, or three 2-week sprints. In each round you have budget for the amount of work/stuff you can do based on your team’s capacity. Some of that budget must be spent on delivering features, otherwise the business will threaten to let you go. Some of it should be spent on growing the team and their engineering skills, otherwise you don’t get more budget capacity. Some of the leading research [1][2] suggests that a key requirement for high performance teams is Cohesion. Cohesion is a measure of the strengths of the relationships between individual team members. In this session we will use this research to discover: ·      Simple communication patterns we can monitor to spot the health of the team. ·      Simple tools we can use to measure and track those patterns. ·      What effect does the location of the watercooler have? What effect do lunch tables have? ·      Can cohesive teams get you into trouble? ·      The importance of dissent and diversity within teams. ·      Bonuses – the negative effects of individual bonuses are well understood by the Agile community. However, we’re left with the question: Are there good bonuses? Downloads Available Game Material (Dropbox folder): Team Member Handout Team Actions Worksheet (1 per team)   Facilitators Material: Teams Game Sample Games – four possible paths through the game played out Slides Magic and Science of Teams Game Edition from Mark Levison   In addition to the game material, I’ve written a paper on the “5 Steps Towards High-Performing Teams”. Enjoy playing with your team.   Feedback from GOAT (Gatineau Ottawa Agile Tour 2015): During game play at the conference, only the facilitator knew the benefit/effects of each action while the game progressed. As a result, in the 90 minute session some teams had a difficult time keeping track of the calculations. Future editions will reveal all the calculation details on paper to the attendees in the round after they’ve played. [1] Sandy Pentland – The New Science of Building Great Teams [2] Ben Waber – People Analytics  

Large Agile Teams

All About Agile - Fri, 01/09/2015 - 13:39

I recently wrote a detailed article about Large Agile Teams that was a detailed walkthrough of how to structure agile teams of various sizes.  I suspect that this is the most comprehensive online discussion of this topic.  The article addressed the following topics:

  1. Organizing Agile Teams.  The article starts with a summary of the results of some industry research that I've done regarding the size of agile teams, showing that agile techniques are in fact being successfully applied on a variety of team sizes.  It then goes into detail describing the organization structure of agile teams at various sizes.  The article starts with a discussion of small agile teams, covering the common rhetoric of how to organize such a team and then making observations about what actually happens in practice.  It then walks through two approaches to organizing medium sized teams of 15 to 50 people - a structure for a single team and a structure for a team of teams.  Finally, it walks through how to organize a large agile program of 50+ people, focusing a fair bit on the need for a leadership team to coordinate the overall activities within the program.  This advice is similar to what is seen in the SAFe framework although proves to be a bit more flexible and pragmatic in practice.
  2. Supporting Large Agile Teams.  The leadership structure to support a large agile team is reasonably straightforward once you understand the issues that such a team faces.  In this section the article overviews the need for three important sub teams within your overall leadership team: The Product Delivery Team, The Product Management Team, and The Architecture Team.  It also describes the need for an optional Independent Testing/Integration Team, something misleadingly labeled an integration team in SAFe, that reflects some of the known agile testing and quality practices that I've been writing about for several years.
  3. Organizing subteams.  The article includes a detailed discussion for how to organize the work addressed by agile sub teams within a large agile program.  These strategies include feature teams, component teams, and internal open source teams.  As you would expect with the Disciplined Agile Delivery (DAD) framework, the article clearly summarizes the advantages and disadvantages of each approach on provides guidance for when (not) to apply each one.  I suspect you'll find this portion of the article to be one of the most coherent discussions of the Feature vs. Component team debate.
  4. Tailoring agile practices.  The article provides a detailed overview of how the various DAD process goals are tailored to address the issues faced by large teams.  This advice includes:  Do a bit more up-front requirements exploration; Do a bit more up-front architectural modelling; Do a bit more initial planning; Adopt more sophisticated coordination activities; Adopt more sophisticated testing strategies; and Integrate regularly.  My hope is that you find this part of the article very illuminating regarding how the DAD framework provides flexible and lightweight advice for tailoring your approach to address the context of the situation that you face.
  5. Other Resources.  The article ends with a collection of links to other resources on this topic.

I welcome any feedback that you may have about Large Agile Teams.

The Agile Manifesto – Essay 1: Value and Values

All About Agile - Thu, 01/08/2015 - 10:00

Learn more about our Scrum and Agile training sessions on WorldMindware.comWhat is Agile? In 2001, 17 people got together for a world-changing discussion about software development. They tried to find the common values and principles by which people could do … Continue reading →

Announcing the Agile Advice eBook – Finally Ready!

All About Agile - Wed, 01/07/2015 - 10:00

Learn more about our Scrum and Agile training sessions on WorldMindware.comThanks everyone for feedback, comments and suggestions for my new book, Agile Advice – Creating High Performance Teams In Business Organizations.  It is available for purchase (only $2.99) on … Continue reading →

What It Takes to Develop an Agile Transformation Strategy

All About Agile - Mon, 01/05/2015 - 15:45

Okay… this is going to be a precursor to a more fully developed whitepaper, but I want to see if I can tightly articulate the LeadingAgile approach to designing and executing an enterprise agile transformation. This post is going to focus on the ‘what’ and leave out the ‘why’ and the ‘how’ for the time […]

The post What It Takes to Develop an Agile Transformation Strategy appeared first on LeadingAgile.

Why Not What – An Example

All About Agile - Mon, 01/05/2015 - 08:02

Forbes quoted Steve Jobs as saying “I’m as proud of what we don’t do as I am of what we do.”  This is a really enlightened perspective – and a way to enforce focus from the top down.  Before you can drive a “this goal is more important than that goal” focus, you have to […]

Opposite Views of a Product Roadmap

All About Agile - Fri, 12/05/2014 - 13:22

Your product roadmap a view of what you are building right now, in the near future, and in the more distant future.  Or is your roadmap a view of why you are building whatever you’re building right now, in the near future, and in the more distant future? Your roadmap is both – but one is more […]