Author: Robert Galen

Self-Directed, Self-Organized… Really?

Written by Robert Galen on February 2, 2016. Posted in Articles.

One of the core ideas or principles of Agile teams is this notion of a self-directed, self-managed, and self-organized team.

In my experience, it’s one of the hardest things to get right in your coaching and team evolution efforts.

Often I see two extremes, either:

The teams use the self-organization, self-directed mantra as a means of having no accountability. It’s essentially the “inmates running the asylum” and they can choose to do whatever they wish, whenever they wish under the banner of – “don’t bother us…we’re being Agile”.

Or the other extreme is that:

The management team says that they’re empowering their self-directed teams, but when you look at their behavior, they’re doing what they’ve always done…tell folks what to do.

People also seem to like being told what to do; being micro-managed

Self-directed teams are teams that, once given a mission or goal, are expected to sort out the challenges and deliver.

While this is a central notion, in my experience, it’s hard to get individuals and teams to take this on. I’m not quite sure why, because it’s really such a compelling premise. That is (You) own your own destiny (Results) so figure things out.

Instead of folks embracing it, I often see them fighting it. Is it a lack of practice in decision-making? Is it a fear of accountability? Is it a fear of failure?

I’m not quite sure, but it could be aspects of all three and much more.

It seems that many of us have become comfortable complaining about things and “pointing upward” to “them” as being the problem. Point being, many individuals have become comfortable with being told what to do. With the accountability residing with their managers and they simply are – doing as they’re told. However, if Agile is done well, then “they” becomes “us”, which can be particularly scary.

On the flip side of this, when I do see individuals and teams embrace self-direction, then it’s a “magical” thing. There is a shared accountability between the leadership team and the teams doing the work. It’s balanced and effective, with each one supporting and trusting the other.

But this balance can often be quite difficult to achieve.

{module ad 300×100 Large mobile}

What the Scrum Guide has to say…

Next let’s review what the Scrum Guide says related to the overall Scrum Team:

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.

And then it goes on to say the following about the Development Team:

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment.  Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.  Development Teams have the following characteristics:

They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
- Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
- Scrum recognizes no sub-teams in the Development Team, regardless of particular domains  that need to be addressed like testing or business analysis; there are no exceptions to this  rule; and,
- Individual Development Team members may have specialized skills and areas of focus, but  accountability belongs to the Development Team as a whole.

In this case the Scrum Guide is focusing the term self-organizing towards how the team decides to attack the work they’ve been asked to perform via the backlog. Schwaber and Sutherland seem to go to great lengths to emphasize the team owning and deciding work strategy. They also emphasize a blending of roles to the point where they are near meaningless. The key points seem to be: team, teamwork, delivery of a product increment and accountability.

What Esther Derby has to say…

In 2011, Esther Derby wrote a really nice article that tried to address some misconceptions related to self-directed teams. The three misconceptions she highlighted were:

1.Self-organizing teams are completely autonomous, self-managing, and don’t need managers.

2.All you need to do to form a self-organizing team is provide a goal and apply pressure.

3.Since the team is self-organizing, they can accommodate moving people on and off the team easily.

http://www.estherderby.com/2011/07/misconceptions-about-self-organizing-teams-2.html

There is an overall misconception that Esther discusses surrounding the relationship, role or ‘dance’ between the self-organizing team and the leadership structure within the organization sometimes referred to as (‘management’).

In most cases, there isn’t a whole lot of guidance coming from the Agile community around managing/leading agile teams. And usually what does come out emphasizes the team over management. What I mean by that is that management is basically told to “leave the team alone” or “go and handle a few impediments” as their primary role.

I really like the balanced (and necessary) role that Esther describes.

Constraints? Or do the inmates indeed run the asylum?

There seem to be two schools of thought when it comes to applying constraints to Agile teams. One is that they’re inherently bad; that they undermine the empowerment and accountability of the teams.

I sometimes see this in coaching colleagues who use terms like:

Agile Purism;
Un-Agile, Un-Lean;
Arbitrary or Dogmatic;
Prescriptive or Prescription.

To describe anything that “forces” the team to do something against their will. Literally they want the team to be unencumbered in their journey without literally any constraints.

Unless you’re working in your own company, or for a non-profit perhaps, I’ve never encountered a job (yes, Agile team members usually work) with a total lack of constraints. Usually there are quite a few, for example:

quality constraints;
appropriate working conditions (language, dress, hours, etc.)
business & financial constraints;
agile constraints – Definition of Done, agile approaches used, tooling, etc.
legal constraints.

But at the same time as we’re applying constraints, we need to be careful that they’re not too oppressive – that they leave some room for the team to make their own rules and their own decisions.

Definition of Done

I’ll use Definition of Done as an example. I believe teams need to have a deep and broad definition of done. I wrote about what that means here and here. But at the same time, I usually encourage teams to “extend” their DoD with team-based agreements and to make it “their own”.

I encourage the same thing to happen when the team is making other operational agreements amongst themselves.

How do we “Create” these teams?

I don’t think you do. I think the leadership team has a responsibility to create a fertile space for these sorts of teams to form, become established, and grow.

Aspects of which include:

Staffing the team with the skills required to deliver on their backlog;
Trying to avoid part-time team members at all costs; if you do have some, limit them and clearly define their “capacity” within the team;
If you’re doing Scrum, have a dedicated Product Owner and Scrum Master. Make sure they have the experience, time, and focus to do the job well;
Respect the autonomy of the team and trust them to deliver in your stated goals and directives;
And engage in all aspects of the agile ceremonies so that you leverage the transparency and real-time adjustment nature of the methods.

And the team has self-direction responsibilities as well. For example:

Holding each other accountable to professional ethics and standards;
Having congruent discussions in retrospectives guiding the team towards continuous improvement;
Having the courage to push back as appropriate on traditional leadership that might be pushing the team too hard or in the wrong direction;
Holding quality dear within the team, not only from a Definition of Done perspective, but with solid professional attitudes and practices;
An overall responsibility to respectfully work together (swarming around the work) and avoiding Scrummerfall behaviors – delivering as much high-quality and high-value software as possible.

Wrapping up

I’m quite curious as to how readers might react to this article. What are your experiences in achieving self-direction in your Agile adventures? Is it easy or hard? And have you seen team resistance to the notion?

Have you discovered anything worth sharing about how to achieve this level of organizational balance? I’d be very interested in hearing about it.

And is it something, that once you’ve achieved it, it sticks? Or do you have to continuously work on your self-direction, autonomy, and self-organization?

Stay agile my friends,

Bob.

A few nice references

•http://blogs.agilefaqs.com/2014/10/29/self-organised-vs-self-managed-vs-self-directed-whats-the-difference/

•http://www.infoq.com/articles/what-are-self-organising-teams

•https://mikemacd.wordpress.com/2012/05/01/what-does-a-self-organising-team-really-mean-organisation/ http://www.growingagile.co.za/2012/11/self-organising-teams/

Playing Hockey Without a Goalie

Written by Robert Galen on January 18, 2016. Posted in Articles.

I was watching an NHL game the other evening. The team was playing a hockey game without a goalie.

Apparently the team had decided that their goalie was too expensive. So they traded him away to another team.

Then the backup goalie was sick. And his equipment didn’t fit anyone on the team, so they decided to “go without.”

In a pre-game interview with the General Manager, he said that it was strictly a financial decision. They felt that the team could fill in the goalie role by sharing it amongst themselves.

If it worked out as he expected, then they might consider this change as a permanent part of their hockey team structure.

At the very end of the interview, he wondered –

What does a Goalie do anyway? For 90% of the game, they’re idle. What a waste of money. Why not get the team to “pitch in” and fill that role? It just makes good sense.

Unfortunately, this story ends badly. The team lost 22-1 in the game. Apparently, no one on the team wanted to put themselves “in front of” +100 mph pucks, so the goal was essentially empty for the entire game.

Imagine that!

Before…

Now before you think that I’ve lost my mind, there is a point to my totally made up story. It relates to the ScrumMaster role on Scrum teams.

Not that long ago, I read a LinkedIn article by Ben Linders. You can read it here –

Why Implementing Dedicated Full-Time Scrum Masters Is Difficult – What’s The Alternative?

In it he makes the case that not committing to full-time ScrumMasters is sort of normal behavior. He seems to be saying that it is too costly, too inconvenient, misinterpreted, or too hard to actually COMMIT to doing Scrum as described in the Scrum Guide.

That instead, there are other approaches that are “as good as” having a full-time, dedicated, highly skilled, ScrumMaster.

I simply disagree. And I have a hard time when thought-leaders in our business make these sorts of overarching statements. Sure, I’ve seen all of the anti-patterns that Ben implies. Yes, it’s a hard role. And yes, a large group of the clients I’m coaching initially approach it this way. But I think it’s my job to try to get them to think of applying Scrum principles and practices in a thoughtful, as-intended way.

And being a solid hockey goaltender is a hard role as well. But I don’t think that “doing without” or cobbling something together that marginalizes the role is the way to go.

Wrapping up

Now I’m not trying to pick on Ben. It’s just that his experience is that ScrumMasters are not considered a necessary investment when you’re moving to Scrum. That’s ok.

But I want to go on record as follows:

IF you’re playing hockey, then you need a goalie!

And a skilled goalie, who is full-time, and who is equipped to be successful in their role.

IF you’re playing Scrum, then you need a ScrumMaster!

And a skilled ScrumMaster, who is full-time, and who is equipped to be successful in their role.

That’s just the way I see it.

Stay agile my friends,

Bob.

Here’s a Meta-Cast podcast episode that nicely compliments this article – http://www.meta-cast.com/2015/09/episode-79-growing-great-scrum-masters.html

User Stories and Mousetraps: A Lifecycle of Conversations

Written by Robert Galen on December 14, 2015. Posted in Articles. 1 Comment on User Stories and Mousetraps: A Lifecycle of Conversations

I teach quite a few teams about User Stories. Most struggle with the concept, at least initially. One of the key challenges for many is the notion that stories are iterative. That you visit and refine them often, instead of the “once and done” view that we have for traditional software requirements.

Part of that revisiting is reinforcing the collaborative nature of the stories. The nature that says they are “intentionally incomplete” in order to encourage conversations around the story. Remember the 3’C’s from Ron Jeffries: Card-Confirmation-Conversation, with conversation being the most important ‘C’?

I thought it might be helpful to go through a life-cycle example of how stories morph and change as they approach an execution-ready state. So here goes a somewhat contrived example—

http://courses.knox.edu/theatre121/Mousetrap.html

Product Owner ideation of a few “stories” related to a new mousetrap. Call them “Epics”

Here’s the core Epic: As an exterminator, I want a better mousetrap, so my customers stop calling me in the middle of the night about ‘rodents’

Build a better mousetrap
Build a board level framework to support the mousetrap
Find the right “trapping” mechanism for the mousetrap; including high strength material

The product owner gathered this list from their constituents and stakeholders from a “back of the napkin” perspective.

At this stage, it’s just good ideas that need exploration and team-based analysis.

Backlog Refinement meeting #1

The Product Owner wants to get a sense for the “size” of these high-level epics from their team. At this stage, they might select a few specific individuals to help in the sizing, so as not to interrupt the entire team.

Since these epics are simply potential ideas, they want to assess their technical complexity and relative level of effort quite quickly. Investing as little time as possible, but still getting a “reasonable feel” for the work.

They use T-shirt sizing: S, M, L, XL, 2XL, etc. so that it’s fast. What’s different here is that the T-Shirt sizes relate to “Release Trains” or release chunks.

A Small “fits” into a ½ Release Train (20 sprints)
A Medium “fits” into a Release Train (40 sprints)
A Large requires 2 (60 sprints)
An XL, requires 2-3 (100 sprints)
A 2XL requires 2-4 (100+ sprints)

After a relatively quick meeting:

• Story #1 the core Mousetrap is sized as an XL by the team.
• Story #2 – is sized as a Medium
• Story #3 – truly is said to be a “Research Spike” and is sized as a Small

The team moves on…

The Product Owner now has some very early, high-level sizing information to initiate investment discussions with their stakeholder team. Note that these aren’t commitments or firm estimates, but instead are high-level, informed guesses.

Off-line discussion: The team is intrigued by the XL parent story and starts to brainstorm how they might go about decomposing it.

Build the base
Build the bait mechanism
Acquire the bait and determine storage requirements
Build the triggering mechanism
Determine the performance requirements – speed, stun level
Determine the size of the mouse the trap can accommodate; no Godzilla mice allowed
Build the packaging for the mousetrap
Build the directions for the mousetrap; include “loading”, “setting”, and “cleaning” 😉

Question comes up about “cascading” mousetraps. For example, for truly infested areas, can/should they connect them together in a “defensive perimeter”? Clearly this needs more investigation.

Backlog Refinement meeting #2

The Product Owner has decided, with the stakeholders, that the mousetrap needs to be built. The following are some high-level clarity that has been added to the epic:

It needs to be built in one Release Cycle
It needs to be very simple – no Rube Goldberg solutions
It has to be sell-able in US, across North & South America, and Yemen
The materials can only cost $1.30 and the manufacturing cost needs to be keep to $.30/piece
Target price is $5.00 for the “Better, Most Reliable, Mousetrap”
It does not need to be “cascade-able”

The Product Owner asks the team to respond to this request with a story brainstorming exercise to gain a feel for the overall scope for a much more complete decomposition of the work.

Story Writing Workshop

The Product Owner reviews a presentation that represents the high-level vision and goals of the leadership team.

Instead of immediately diving into writing stories, the team starts brainstorming roles for the application. After some passionate discussion and debate, they come up with the following initial / primary roles:

Rodent infested home owner
Older home owner, trying to avoid a heart attack induced by rodents
New home owner
Pest service selling rodent removal services

Next they start writing stories. The roles are helpful in that they break up into smaller groups and brainstorm stories aligned with each role. The roles give them a different and more specific perspective than the simple “As a User” role would.

They also write the stories aligned with the key requirements from the stakeholders. In many cases, these requirements not only inspire functional user stories, but non-functional stories, infrastructural stories, and research spike stories. So there is a broad and deep mix created.

Here’s a sample of some of the spikes they think of:

Materials investigation, emphasis on pricing and meeting regulations.
Performance requirements: build a prototype and run experiments for:
1. Size of the mice;
2. Speed (spring material and tension) necessary to “stun”;
3. How long the devices need to “retain” the mice.
The team wants to use a Java-based framework to build the overall trap and they have little experience with it. They need to “play around and learn”.
Material supplier and pricing investigation to ensure the expense requirements can be maintained.
And throughput is in question, since the target is “rodent infested”, what are the potential mouse/hour capture rates?

Estimation

One of the goals the Product Owner had by investing in the story writing workshop was to gain a much more holistic view to the functional work associated with building the mousetrap. In other words, to convert those early stories and estimates into something much more finely grained and tangible with the team.

To that end, the Product Owner and the team establish another scale for estimation that is slightly more finely grained.

Again, T-shirt sizing will be used: S, M, L, XL, etc. will be used so that it’s fast. What’s different here is that the T-Shirt sizes relate to sprints:

• A Small “fits” into a ½ sprint
• A Medium “fits” into a full sprint
• A Large requires 2-4 sprints
• An XL, requires more than 5 sprints

The Product Owner and the team go through the entire list and estimate the stories. This gives the PO a more detailed sense of the level of effort to execute their current vision AND to start trimming things out to fit things into a single release cycle.

They still don’t know if that can be done, nor if the stakeholders will “buy into” the newly established views toward scope. But they continue to “chip away” at the work to better understand the scope, complexity, and overall level of effort. And of course, they include the entire team as much as possible as they drill into the details.

Why you might ask?

Because ultimately the team will be chartered with doing the work – so including them only makes good sense.

Eureka – Alignment

There are a couple of other techniques, probably with many variations, that help the team, Product Owner, and stakeholders align on the ASK vs. what’s FEASIBLE. First is story-mapping, where you align your hierarchical stories based on customer usage.

I borrowed this picture from Jeff Patton here –
http://www.slideshare.net/jeffpatton/user-story-mapping-discovery-the-whole-story

It would be like aligning Microsoft Word features based on the high level menu. In story-mapping, you start grouping your stories in clusters in the way in which your customer might be using them. Think customer workflows. What’s interesting about this technique is several-fold:

You start grouping stories into functional themes and prioritize the themes instead of the stories. This makes prioritization and planning easier.
It exposes any underlying requirements for infrastructure, architecture, UX, and any other “plumbing” needed to enable the higher level functionality.
It also is a great way to uncover dependencies that ultimately will need to be negotiated between teams.
It also helps in creating your products with MVP chunks that immediately begin resonating with your customers.
And finally, it puts the “customer first” in your discussions (or the persona’s first) if you will. So, it helps to keep a customer focus.

The other technique is release planning. Again, here we’re aligning stories according to project execution dynamics. I like to leverage both techniques because they each give me, and more importantly the team, different views towards the workflow for feature development.

Instead of going into the details here for release planning, I’ll point you to an article I wrote quite awhile back that explores the technique in much more detail.

Another nice reference for release planning is in the Scaled Agile Framework or SAFe. In SAFe, there is a periodic event called PI (Program Increment) Planning that is essentially the same thing as release planning. It’s an event where the entire team gets together to:

Decompose their epics into stories;
Layout those stories in time;
Negotiate architecture, design, and technical risk areas;
Negotiate internal AND external (cross-team) dependencies;
Negotiate quality and testing centric focused efforts.

And pull together a holistic “high level plan” that the team thinks is feasible and sound. If the stakeholders and the Product Owner agree on the effort vs. scope, then this “list” becomes the working Product Backlog for the team to begin actually sprinting and delivering meaningful chunks.

Ongoing Refinement meetings

You need to keep in mind that agile teams are constantly refining their backlogs. It doesn’t just stop at some discrete point. Instead, the stories are refined until they are ready for sprint execution.

So completing story-mapping and release planning, while a significant step forward for the team in getting their arms around a project efforts, is only the beginning. As the team starts to execute sprints, they continue to refine the backlog into more discrete chunks.

Quite often, they are not only looking within the current release, but if they’re mature, they’re starting to get their arms around the technical aspects of the next release as well.

Sprint Planning, Execution, and of course, Delivery

One of the first activities after release planning is to tee up your first sprint. All of the planning and estimation the team has explored so far are simply that…estimates. The team hasn’t delivered a thing yet and they don’t have a reliable sense for their velocity to compare back against the estimates.

So there should be a sense of urgency in any Agile team to move as quickly as possible from “talking about” the work, to actually “doing” the work, delivering sprint work, and measuring their velocity.

The teams’ Definition of Done becomes incredibly important here as well, as it contributes to a stable velocity of the team consistently adheres to it.

Wrapping Up

My key goal in writing this article was to explore or show you the cyclical nature of the conversations that surround the evolution of user stories. The other missing piece is documentation. Often the Agile community gets falsely accused of not delivering any documentation. And to be fair, there are many immature Agile teams who don’t.

But nothing in the methods or the mindset is contrary to documentation and I usually recommend that teams keep notes of their conversations during the entire story evolutionary process. These are detailed requirements, but they ARE note surrounding clarifying discussions, critical decisions, and the why behind the story.

They also include the teams’ memory as I mention in this related post.

I hope your own mousetraps are developed iteratively, collaboratively and well.

Stay agile my friends,

Bob.

Focusing on the STORY in the User Story

Written by Robert Galen on November 3, 2015. Posted in Articles.

The user story has nearly become the ubiquitous requirements artifact in Agile contexts. User stories have had much written about them, their format, how to write them, the associated acceptance tests, and more.

As for acceptance tests, we’ve moved beyond writing them to articulating them as “executable tests” in tools such as Cucumber and Robot Framework.

All of this evolution has been great, as is the focus on the collaborative aspects of the user story.

But I’m starting to see something troubling in my coaching travels. I think we might be focusing too much on the user story as an Agile requirement artifact. Instead, we should be taking a step back and considering the user story as a much simpler communication device.

That is simply as a STORY, and much less as a written story, but moreso as a story told face-to-face.

Imagine

In fact, as I’m writing this, I’m envisioning the quintessential storytelling scene where a group of scouts is in the woods, surrounding a fire, late in the evening. And the Scoutmaster is recounting a story to them. It’s usually a scary story, intended to entertain, but also raise the angst of the listeners.

As the story continues the scouts lean forward. Their pulse increases and they begin to hear noises in the surrounding woods that raises the hair on their arms. They become a part of the story. It becomes real to them, and they can envision the words. In fact, for a short time, the story becomes their reality.

I believe this is the sort of intention that Kent Beck had for user stories when he initially created them. It wasn’t a requirement, but instead it was an engaged conversation between the team and their client.

It was intended to get the client or stakeholder to sit down with their team and share their vision in a storytelling fashion. It was intended to be collaborative, with ideas being shared, and questions being asked. As the discussion unfolded, the team would become intimately familiar with the client’s challenges or problems that they were trying to improve.

And instead of telling the team what to deliver, they simply shared their perspectives. And the team would respond with empathy and understanding around how to implement things to help their client. In fact, they also started thinking of the experiments they might run to narrow any gaps in their understanding.

If that was the original intent, let’s start to look at some of the aspects of potential storytelling within agile teams.

Put The Client First

The more we can envision the client and their context, the better the team will be able to implement solutions that will solve their challenges and ultimately surprise and delight them.

Tell stories about your clients. What is their motivation? What is their environment? What is their experience level? Who are they – specifically? And importantly, what problems are they trying to solve with their requests?

Related Article: 50 Ways to Write a Great User Story

Find out what excites them and what doesn’t. Don’t just explore their immediate needs, but try to understand their future challenges and where they might be in a year or more.

The Kano Model talks about three basic categories of customer needs:

Delighters or Exciters – the WOW factor in a product or application.
Basic Needs or Must Have’s – these are “table stakes” for the product.
Performance or Linear – the more of it, the better.

These three types of customer needs are mapped against how satisfied the customer’s reaction to them are AND against the execution and quality delivery dynamics of the team.

Better than talking about the client, invite them into your team. The more direct the communication, the better. And using a model such as Kano to explore their reactions to features, priority, impact, and need can be powerful. Not only in deciding what to build and when to build it, but the conversations around Kano are even more powerful.

Here’s my reference to Kano – http://www.agilebuddha.com/agile/faster-time-to-market-or-lower-cost-of-development-is-a-delighter-anymore/

The Backstory

Quite often there are a series of reasons why your clients are asking for a software feature. Some of them are driven by business needs. Others are more contextual, for example, an older system is so aged that it no longer meets their needs. Or they need the functionality, but in an upgraded, more maintainable “package”.

Often the backstory is unsaid, and you’ll need to “tease it out” of your clients, stakeholders, or customers.

You also need to push through the first reaction, which is often – I need it because I need it. You’ll need to patiently “dive deeper” into their thought processes and motivations.

One effective way to do this is observation. Asking the customer to show you what they do today, which might give you insights into why they are requesting something new. For example, if they show you that their current process is slow or unwieldy, then speed and simplicity will be paramount.

Another way to explore this is by demonstration. Showing them simple paper and code prototypes that cost very little to build, to get their reactions and feedback. No matter how we do it, we have a responsibility for exploring the drivers behind our customer’s requests.

Now I want to switch gears a bit and explore some of the crucial tactics of our storytelling.

Tactics of Story Telling

A Good Introduction

Often it is quite useful simply to get to know your customer. What is their name? What is their job title or role within the company? Another point is their experience level? Before jumping in to say – how do you want this function or feature designed, stop and get to know them.

And this includes introducing yourself and sharing what motivates you as well. Come to a place where you’re simply getting to know one another to improve your ongoing relationship. Spend some time together and, most importantly, observe, ask open-ended questions, and deeply listen.

Motivation

I’ve watched actors prepare for their roles or scenes in plays, and a topic that often comes up is “their motivation”. The actress explores the role and the events and experiences leading up to the current situation or context.

Often the actress tries to connect the situation to their experience and history so that they can better understand and express the moment for the audience.

Another way of describing this is the WHY behind the request. In his book Start With Why, author Simon Sinek explores how effective leaders start with the why behind their goals. In other words, exploring what they’re trying to achieve. I think effective Product Owners do the same thing, instead of simply making a request for a feature; they first start with the reason behind the request.

Visualization

I’m an avid reader of Science Fiction and Fantasy novels – particular the fantasy genre. One of the things that set great authors apart from good authors is their ability to develop a world that you can visualize. Often they are developing an entire world full of cultures, races, geographies, families, histories, characters, and a dichotomy of good versus evil.

As I read, I can often visualize the world, both the things that the author has established, but also start to add my imagination to the environment and context.

User stories need to invoke the same. They need to encourage the reader or listener to leverage their imagination. To ask questions based on what’s already been shared. Or better yet, to make suggestions about how something might unfold or look to the user.

Whiteboards are particularly useful in this. I love it when during storytelling the team gathers around a whiteboard some various individuals start drawing and visualizing options.

Filling in the Blanks

Often a good story doesn’t simply give you the plot. Instead, the plot unfolds with twists and turns. In fact, in a good whodunit, you rarely know who the villain is until the final pages. You’re left trying to “figure things out” during most of the story.

It’s this mystery or intrigue that often makes the story compelling to the reader (or listener).

I believe one of the reasons that user stories are intended to have holes or are “intentionally vague” is to encourage the listeners to fill in the blanks with their experience and intuition. This is a powerful way to activate the whole team’s creativity.

Excitement

A good story should draw the listener into the moment. It should catch their attention and ultimately, generate some energy and excitement.

And you don’t have to generate that excitement all at once. I think stories are often iterative in nature. You start telling it, and you run out of time. So you let the listener “stew on” or think about the story for a while. Let them start to make it their own story, which is ultimately the goal of the storyteller.

Empathy

I think of empathy as putting yourself “in the shoes” of another. It’s not simply a role-play or a thinking exercise. It’s a deep and committed effort to put on the mindset of your customer.

Often interviewing and observation can help here. I remember when I was at iContact all of us in the engineering team would spend 2-3 hours per month sitting with our customer support staff listening to customer calls. Amongst many benefits, it phenomenally increased our empathy for our customers AND our support staff.

And it improved our product quality too.

Success

One of the cool things about acceptance tests or acceptance criteria is that they help define what done and what success looks like for a user story. That’s a very useful concept.

Often in our storytelling we want to not only share what we want but even more importantly, what we don’t want or need. This clarity of boundaries can help the team stay focused towards a solution and not fall into the trap of gold plating.

Next Steps

Of course each story should result in actions and follow-up. Or I should say that it inspires action. There should be a visceral sense of what to do next and momentum to go out and start implementing it.

In fact, when we deliver the story, we should also include the backstory that we heard that led us to the implementation or solution. And that’s just the closing of one chapter of the story.

Wrapping up

As part of my writing efforts, I often tell or share stories. One critical aspect to it is that they have to be real and relevant.

But I have this feeling that it’s one of the best ways to convey information to my readers – to make my lessons real, and to have it resonate to the readers “real world”.

I’m not saying I’m the best storyteller. I’m certainly not. But the act of storytelling is one of the richest ways to communicate that I’ve found.

I hope I’ve inspired you to look at your user stories in a different way and to increase your attempts to tell your stories.

Stay agile my friends,

Bob.

PS: after I write this, I discovered a brief article by Brian Hoadley on LinkedIn where he explored – Understanding the Importance of Narratives in My Work. While it’s UX-related, I think it nicely compliments this article

Simplicity – The Newest Craze in Agile

Written by Robert Galen on October 6, 2015. Posted in Articles.

My motivation for this article isn’t to slam or denigrate any of the scaling frameworks (and those that continue to emerge). Full disclosure, I’m a SAFE SPC, and I find significant value in leveraging some framework for Agile at scale.

That being said, I have a great concern that I want to share. I think we’re losing some of the original thinking and approaches from early instances of Agile. The methods grew out of small teams doing big things.

But as we’ve gone forward and introduced agility into larger instances (enterprises, large-scale companies, distributed projects, etc.), I’m afraid that we’re losing the very essence of agility that made it attractive in the first place. Things like:

Small teams
Simple, focused solutions
Just enough
Face-to-face collaboration
Working code
High-value delivery

These seem to have lost their attractiveness. I want to share a series of stories that I think (hope) might shine a light on returning to our Agile roots. Or at the very least, might get you to rethink some things.

First Story – Remember Wordstar?

I doubt whether many of the readers will recognize this program. But at one point, pre-Microsoft Word in the early to mid-1980s, Wordstar was the premier word processor on the planet. It was supported on something called CP/M and later on DOS.

What was amazing about Wordstar, at least to me, was that it fit into 64k of RAM. In fact, it fit into less than that because it had to share that space with the operating system. Imagine that, a simple, but full-function word processor fitting into less than 64k of RAM. Clearly the designers had to make incredibly tough choices as to what features were critical to the program. In today’s terminology, we call it an MMP or Minimal Marketable Product.

Did folks complain about missing features and capabilities? You bet! But that didn’t stop a whole generation of programmers from being able to use Wordstar to get the jobs done.

I reminisce about Wordstar and similar programs because I think today we’ve gotten a bit lazy. Since we have hardware resources to spare, we design bloated products just to prove that we can design 100 complex ways to do inherently simple things. It’s easier than thinking about simple designs and simple solutions to complex problems. When Agile came around, it placed a renewed focus on design simplicity, heck simplicity everywhere. Getting to the essence of a problem and solving…just it.

I think we could relearn something important by revisiting those software design goals from so long ago…

The Lesson: Wordstar had hardware limitations that forced the developers to minimize the product to an MMP feature set. Today we would do well to imagine that we had a small hardware footprint to encourage us to be creative, innovative, and frugal in our applications.

Related Article: Agile is Focused on Capacity Equalization

Second Story – Unix

The beginning of Unix is another one of those minimalist stories. It was developed by a handful of developers in the early 1970s at AT&T Bell Labs. While some of the early Unix contributors were considered super-programmers, nonetheless it’s another case where a small group did big things.

As Unix’s popularity grew, the software got bigger of course. However, I still remember the “erector set” nature of basic Unix commands and how you could “pipe them together” to do more complex tasks. The architecture itself was simple, yet elegant, and it remained that way as it historically expanded.

In the early 1990’s, Linus Torvalds famously released an Open Source version of Unix called Linux. In the beginning, it too was incredibly small. He initially worked on it himself and then with a small group of dedicated maintainers. Again, Linux has grown well beyond its original size constraints. But both systems are clear examples of elegantly designed small systems that had a huge impact on our technology.

The Lesson: Again simplicity, but not only that, the beginning of the realization that a small group of programmers could deliver big, useful things. It didn’t take a team the size of Montana to deliver meaningful products or applications.

Third Story – Bloatware and Pareto

I’ve been using a quote for quite a long time in my classes. I can’t remember where I’ve seen it before, but it goes like this:

Less than 20% of the features of Microsoft Word are actually used by human beings on the planet earth. So how did the other 80% of features get in there if they have no (lean) value?

Competitive pressures
Marketing checklists
Flat out guesses
Gold plating
Feature creep
Youthful enthusiasm

All probably contributed. But at the end of the day, the only determinant of value should be REAL customer usage. Now if only Microsoft would agree to trim Word down to size.

Here’s a supporting quote by Kelly Waters from a 2007 www.allaboutAgile.com blog post:

Anyway, back to my point about the 80/20 rule, Microsoft’s own research found that the average user of Word uses only *8%* of the functionality. That’s 8%! And I wouldn’t mind betting at least 80% of us use the same 8% too! [assertion]. If Microsoft had developed only the important 8% of Word, maybe they could still have captured the same market share? Maybe, maybe not; sadly we will never know.
http://www.allaboutAgile.com/Agile-principle-8-enough-is-enough/

The article also alludes to leveraging the Pareto Principle when it comes to mining for customer features that truly make a difference. Otherwise known as the 80/20 Rule, here’s an article I shared about Pareto in another context.

The Lesson: Pareto is alive and well and applicable in everything we do in software. We need to continue to look for the 20% of features that deliver 80% or more of the value to our clients. Then deliver that FIRST before we worry about the edge cases.

Fourth Story – Chrysler C3

The original Chrysler C3 Extreme Programming project was the inspiration behind the Extreme Programming Agile approach. I wasn’t part of the project, but my understanding is that it was a typical, large-scale, Waterfall project that failed. There were perhaps 50+ folks who were working on the effort for over a year.

When it was initially cancelled, the project had been a dismal failure. The story goes that Kent Beck made a case for a much smaller team to use a different approach to try and recover the project. The team was about 20% of the original team size.

As you can guess, the team recovered the project and delivered a workable HR system. But the project never met the overall goals and was ultimately cancelled again in 2000.

This was the project where Kent, Ron Jeffries, and several other famous Agilists earned their chops. It also inspired XP as a popular methodology and initiated the movement, as it exists today.

The majority of software projects today make use of XP practices even if they’re not Agile. Those early XP experiments in things like pair programming, refactoring, and continuous integration have proven to be incredibly sound ways to build software iteratively.

The lesson: A small group of focused technical folks can do big things IF they apply the principles and practices of the Agile manifesto. Bigger isn’t necessarily better.

Fifth Story – iContact vs. MailChimp

I worked at iContact from 2009 – 2012. iContact provided a SaaS email marketing application that competed primarily with Constant Contact and MailChimp. At the time, we mostly focused on MailChimp because of their phenomenal customer growth.

Beyond MailChimp being a direct competitor, we were both Agile shops. And I was at the time and still am enamored with the nimbleness of MailChimp.

In 2012, iContact had nearly 400 employees. Around the same time, MailChimp was reported to have approximately 80 employees. So they were 20% of our size. I just did a LinkedIn search for MailChimp and it showed 106 employees. So they are still relatively small and nimble.

What’s my point?

Well, to put it bluntly, MailChimp cleaned our clock! They kicked our butt when it came to head-to-head comparative measures of our SMB email marketing applications. They were quicker to deliver features. They were quicker to change and pivot directions. They were more creative, bringing out a freemium offering that drove tremendous growth A strategy that we tried to copy and failed.

I’m currently a MailChimp customer, and I’m amazed how insightful they are into the needs of their customers and how frequently they bring out new and, more importantly, useful features.

If you extrapolated from the numbers, we had about 100 people in technology. Mailchimp would have had 20-30 of the same folks developing, deploying and supporting their products.

I was at the time and still am envious of them. They were truly Agile in spirit and action. They had an incredibly small team that built and evolved a robust email platform that simply rocked in its market space.

The Lesson: We all seem to have a tendency to bring more people to bear on problems, under the impression that we’ll achieve our goals faster. However, that often doesn’t happen. Instead focusing a small, Agile team on thoughtful, high-impact client goals seems to be a winning strategy.

BTW: there are numerous other companies that are quite small, but that do incredible things. One historical example is 37 Signals the makers of Basecamp. Another is Menlo Innovations, who focuses on application development.

Final Story – ChannelAdvisor

Here is one final story just to finish whetting your appetite around my article themes.

This comes from my personal experience. During 2007 – 2009 I worked as an Agile coach and leader at a company called ChannelAdvisor here in Raleigh, North Carolina. As with iContact, ChannelAdvisor was an Agile shop (Scrum), and they built a SaaS application suite for eCommerce customers.

We had a large Scrum team that was focused on developing web search application extensions for our platform. The company was growing, and we were of the habit to grow our Scrum teams rather large before we would split them into two smaller teams. Our search team was approximately 12 in size.

A business priority change happened that caused us to split the search team in two – essentially making two Scrum teams of six members each. One continued to develop the search application, and the other was redirected to another component area.

What’s interesting about the story is that the search teams’ velocity didn’t change after we split them. They were averaging 25 points per sprint before the split and 24 points per sprint after the split.

I know what you’re thinking…that’s impossible. Well, no, this really happened. So what was going on here?

Simply put, the smaller team was more efficient in delivering software. There were fewer communications channels, fewer hand-offs, more collaboration, and better focus on their goals.

The Lesson: Try to solve your problems with as small a team as possible. Let them form and mature and achieve a steady velocity. Then “feed them” a prioritized backlog. You may just be surprised at how much they can get done IF you get out of their way.

Wrapping Up

I think that all of the scaling hoopla is just that. I don’t believe we have a distributed team problem or a scaling problem in today’s small or large-scale Agile contexts. And huge applications don’t need to be built by 10-50 Scrum teams.

We have an un-scaling problem. We have a boiling the ocean problem. We have a trying to throw too many people at it problem. We have a love of size and scope problem.

We’re looking at problems and creating the most complex solutions we can come up with. We are enamored with:

Distributed teams and/or large groups of teams
Way too complex architectures and designs
Solving problems with project management thinking
Management solving problems with “old thinking”
Building bloated software with features nobody uses
Not truly understanding our clients
Allowing business-facing folks to ask for everything
Scattershot vision hoping that we eventually hit the target

I can’t tell you how often I hear someone explain why his or her systems are complex. They reference the complexity as a badge of honor and a must have.

I would argue that there is no need for 100’s of developers to build systems. Small teams can do great things. That is if we allow them to do it.

That was the essence of agility in the beginning and it still is. I hope this article has inspired you to reduce your teams, break up your products, and take a new look at how you build your software and what you build.

Remember – a handful of Agile teams can do great things. And a handful of product visionaries can guide them towards just enough, lean, and wonderful software.

Stay Agile my friends,

Bob.