I’m going to be excommunicated from Agility for this.

But, in this article, I’m going to propose a way to leverage a maturity level assessment based on a relative estimation that will increase the ease of working between cells/squads/pods/teams in an Enterprise Environment by a significant degree.

How am I going to do it?

It relies a lot on groundwork and consensus.

What do I mean? Let me explain.

The Assumptions

We all know how to do an estimation via Planning Poker in Scrum, right? I’m going to assume that yes, we do. Also, I’m going to assume that you’re following a system based on the Scrum Bible at scrum.org, in an Enterprise setting. You have cells doing work in User Stories, Features and Epics, in two-week Sprints.

You’re also using User Story Points to measure them in the usual changed Fibonacci: 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100.

Do this make sense? If not, tweak it to your preferred values.

The Consensus

We need to set a consensus. It’s going to be arbitrary, but it will help have a frame of reference.

Our consensus is twofold: we can set all the Sprints for two weeks. We will also do this: we’ll assume that 8 User Story Points are the maximum that a single person can produce in a Sprint. Taking this into account, 8 USPs are two weeks. 3 USPs is roughly one week, 5 means a week and some days, 2 more than a couple of days but less than a week and 1 a couple days at most.

Yes, these are rough estimates; that’s the idea. We cannot, at the estimation point, be so precise that we zero in an exact number of hours. When we will know how much it costed? We will know how much the User Story costed after we finish it.

As a bonus point, we can come back later on to check on the cost of the User Story later on.

So, if we follow the usual distribution for Scrum, we can think of a User Story as something that’s going to be taken care in one Sprint (ideally). Therefore, for a 5 person squad/cell, the maximum ideal length of a User Story should be 40 USP (8 USP per person times five).

If we use the 3 Sprints for a release, then Features will be in the 100-120 USPs range (40 times three). And Epics, being worked within quarters, will probably be between 120-240 USPs.

(of course, adjust to size and capacity)

Where does this leaves us? We can use it to check that User Stories, Features, and Epics are estimated, sized, and split correctly.

The Prompt-craft

This is going to take some work. I’ve created a list of Epics, Features and User Stories.

You can download it here.

Now, let’s see if we can get the AI to do the work for us. But this is going to take some explaining.

I’m going to use ChatGPT (on version 4o with Canvas) to get it to understand what we want.

I am an Agile Coach trying to understand if the Epics, Features and User Stories at my work are correctly sized. For that, I have reached this consensus in which a person can only produce 8 User Story Points per Sprint, and a user Story can only take one Sprint. Therefore, the maximum a User Story can be sized is 40 User Story Points for a Team of 5. I also have reached a consensus that a Feature should be produced between one Sprint and three Sprints, therefore, between 40 User Story Points and 120 User Story Points for a team of 5. And an Epic is at most Two Features, that are produced each Quarter, so between 80 and 240 User Story Points for a team of Five. I have the following list of Epics, Features and User Stories. Can you analyze it and let me know which Epics, Features and User Stories are mis-sized? Take into account the team size relative to the sizing. Write an output explaining those who are not acceptable.

Whew! That was a mouthful, wasn’t it? But we can see that we use the role-playing that we introduced last time and now we’re introducing another concept: assumptions.

What does this produce?

Not only a list of the specific issues, and recommendations…

…but a list of general recommendations.

This produces a workable, actionable list of our next focus.

If we run this, we can have some idea of the maturity of our Backlog in terms of sizing.

Hope this is useful and let me know how it works!

#aiaa #ai #agile #backlog #automation

Have you ever wondered why you are working in Agile?

This should be a simple question to answer; hopefully, it is because you can increase value meaningfully.

But is it easy, though?

Have no fear! If you struggle to find that answer, in my experience the answer lies in one place: the Epics.

Don’t limit the Epics to just being a collection of user stories and features. It should provide a place to answer a simple question: Hey, I’m giving you this much $$$. How can this result in a profit for the company?

In real-world Agile, this isn’t true. The most underdeveloped part is the Epics. The purpose is to proceed to the development part quickly. Instead of moving towards a Technological Business, a badly done Epic reinforces the idea of standalone areas.

Well done Epics foster visibility and meaning.

Badly done Epics obscure.

Then, we ask ourselves: how can we determine if our Epics are good enough?

Let’s try to do so again using AIAA.

For this example, I will use a very simple approach. I will use another AI tool (Google Gemini Advanced) to process a list of Epics that I wrote, which you can access here.

You can see that they are six Epics, which I wrote in a descending order of correctness. The first two are good, the next two are okay, the fifth one is bad, and the last one is messy. But in order to read them, of course, you will need context. Let’s explain the fundamental technique we’ll be applying today, specifically the Roleplaying point of view. To generate value, User Stories require contextualization; instruct the AI to adopt a viewpoint. In these examples, I’ve used the point of view of a Leasing Product Owner, working to generate products for individuals in a Chilean Bank. How can we make Gemini understand this?

Let’s try this: “First, imagine yourself as an Agile Coach working in a bank in Chile.”

This creates a scenario in which Gemini comments on what could be the major challenges. Ok, we can work with that.

Focus on what we want to do: “I have this list of epics. As an Agile Coach working in the Leasing Product Cell, what would you say about them? Are they all well written?”

This is what Gemini says:

“As an Agile Coach in the Leasing Product Cell, here’s my assessment of the provided epics:

Overall Impression: The list presents a mix of well-structured epics and some that need refinement to truly embody Agile principles. It’s evident that there’s a drive towards digital transformation and customer-centricity, which is positive. However, some epics lack the clarity and conciseness that facilitate effective Agile execution.

Specific Feedback on Each Epic:

Epic 1: Digital Leasing Application for Individuals: This is a well-structured epic. It has a clear business case, a concise description, and measurable success criteria. The inclusion of sizing, team composition, and risk mitigation demonstrates a good understanding of Agile planning.

Epic 2: Leasing Customer Loyalty Program: Another well-defined epic with a strong business case and clear objectives. The focus on customer retention and lifetime value aligns well with the bank’s strategic goals.

Epic 3: Quick Approval for Returning Customers: This epic, while capturing a valuable idea, lacks the structure of the first two. It’s presented more as a casual conversation than a formal epic. It needs a clearer business case, more specific success criteria, and a better definition of scope.

Epic 4: Leasing Mobile App: Similar to Epic 3, this one needs more structure. While the idea is sound, the ‘Why’ and ‘What it needs to do’ sections are quite broad. Defining specific features, target audience, and measurable outcomes would enhance its effectiveness as an epic.

Epic 5: Online Lease Calculator: This is a straightforward epic with a clear objective. However, it might be too small to be considered an epic on its own. It could potentially be incorporated as a feature within a larger epic related to enhancing the online leasing experience.

Epic 6: Leasing Chat: This is the least defined epic. It’s essentially a request to explore a solution rather than a well-articulated epic. It needs a clear problem statement, potential solutions, and measurable goals to guide its development.

Recommendations for Improvement:

Consistent Structure: Ensure all epics follow a consistent format, including a clear business case, description, scope, success criteria, and risk mitigation.

User-Centricity: Frame epics in terms of the value they deliver to customers. Use user stories and personas to capture user needs and expectations.

Measurable Outcomes: Define specific, measurable success criteria for each epic to track progress and demonstrate value.

Right-Sizing: Ensure epics are appropriately sized for Agile development. Break down large epics into smaller, more manageable user stories.

Collaboration: Involve cross-functional teams in epic creation and refinement to ensure diverse perspectives and buy-in.

Overall, while the list contains some promising ideas, refining the less structured epics will significantly improve the Leasing Product Cell’s ability to deliver value through Agile practices.”

Excellent, what do we have now? We have both an assessment of them and a way to improve them. We can try to get them to do a report.

“Create a report for the Epics using a maturity scale, where 5 is written very well and 1 is poor. Include also the main actions where do you think the stories beneath 4 in the scale could be improved”

This is what Gemini creates.

There you have it. An easy, hassle-free way to create a report on the overall health of your Epics.

Next time: sizing!

GenAI, right?

At this point, you probably are tired of hearing it. Yes, it’s going to change the world. But you’d rather have more clarity on how it’s going to do it, right?

So, I’m going to do the opposite of what most consultants do. Instead of starting high, on strategy and vision, I’m going to start very small and concrete and try to explain how I think GenAI can impact positively your day to day.

The obligatory disclaimer: this is basically me future-telling. So take this with a grain of salt.

Shall we drill down?

Let’s think on how GenAi can impact Agile.

But do not stop there. I’ll try to think how to apply GenAI to a concrete problem and I’ll try to provide a concrete solution.

To do that, I’m going to do some fortune-telling. Break out the tarot cards and crystal balls!

My future-assumption

My general view is that Agile is going to change in just a couple of years, going from Agile 2.0 (Scaled Agile) to Agile 3.0, which I call AIAA: AI Augmented Agility.

I think that most teams will quickly migrate to Low code / No code (LcNc) team members, with a lot of the development process, be it tech or business, relying on AI tools. Promptcrafting will become the main skill needed, and you will have small, more mobile teams focusing on Jobs-to-be-Done rather than traditional Scrum roles. Special, dedicated teams of engineers will continue to exists for super-specialized situations, but most work will be done by changeable, mobile teams.

Ok, Fede, you might say. That sounds well and good, but it’s very abstract. Can you give me an example?

I’m going to focus on one problem that today exists, and try to improve it with GenAI.

The Problem

In most of the Enterprise Agility situations (think SAFe, LeSS, etc.) one of the major concern is dependencies. Since Scrum allows a flexible approach to Roadmapping, how does change in which User Story Team A does impacts in Team B? And does Team C suffers any impact?

This, in any major enterprise, becomes quickly a pain, especially once chapter, tribes and other major groupings start to pile up. Suddendly you have 37 teams, with criss-crossing interdependencies that make following the changes a chore. Yes, PI Plannings or Quarterly Plannings can help mitigate the impact, but these are very high-cost, once-a-quarter solutions. Once they are finished, you either rely on people communicating their whole backlog change and other people understanding the impact or you run the risk of impacting the other teams.

Often, this leads to meeting-itis and people investing a lot of hours in trying to understand different backlogs. How can we mitigate this with GenAI?

The Solution

Some general guidelines: I’m going to be as agnostic as possible regarding tools. You can do this with Jira, Rally, ServiceNow or any backlog tool and with most GenAI offerings. I’m going to use for this one plain good-old Excel and ClaudeAI, but feel free to swap them.

I’ve created an interlocking backlog, which you can see here:

User Stories with Dependencies.pdf

There are 8 User Stories (based on a Banking implementation) that have dependencies. I’ve also created the same document without the dependencies there, to mimic a Backlog that hasn’t been analyzed, that you can access here, with 3 teams:

User Stories.pdf

What would be our objective? To find a way to have a first analysis of dependencies that we, as members of Team A, can use to understand if Teams B or C have a dependency with us or vice-versa, and if we see any change on the stories that impact either us or them, have a meeting. That way, we could quickly mitigate the risk of a bottleneck, without the need to wait for a Quarterly Planning meeting or involving dozens of people.

So, let’s go to Claude’s page (https://claude.ai/) and upload the file (User Stories.pdf) with the following prompt:

I have an Excel of User Stories for Banking. I want you to read the User Story Number (column A), User Story (column B) and Acceptance criteria (column C) and then tell me which User Story has dependencies with each other, keeping in mind that stories might have more than a single dependency

As you can see, the AI quickly reads and identifies several dependencies. But this can also be difficult to follow up.

So, let’s refine a little bit our Promptcrafting. What should we focus on?

Using this information, which stories could be a high-impact bottleneck?

Ok, using this promp, the AI can rank the importance of the User Stories based on dependency and priority (which I agree).

So we have a list of stories that we have to monitor, but this is not really a comfortable way to do so. Can, perhaps, find another way to do it?

create a dashboard to follow up on these stories

Of course, this is a static dashboard. I wonder if we can implement it via Javascript into a dynamic page?

implement this dashboard in javascript

And there you have it. A dynamic Dashboard that takes the input from a spreadsheet and makes following it a trivial matter.

Bear in mind that I’m doing this in a bare-bones way. Any kind of tool beyond Excel (like Jira, or ServiceNow) will also include the ability to export the contents, but more importantly, the ability to connect via an API. This means that you can have a bot in any kind of embedded AI (like Microsoft’s Copilot) constantly trawling the different backlogs and alerting the teams about unmet dependencies.

Is this perfect? No, it will probably require some fine tunning, and you should always double-check the results (you can do so with my file User Stories with Dependencies.pdf to see which stories I thought have dependencies with each other).

Will this save you time and effort? Absolutely.

How much? Well, let’s do something. Let’s map total hours (i.e. hours per participant) in all the Scrum of Scrum or Sync meetings that your RTEs, ATFs, etc. go to. Let’s tally them up.

How much do you think that they will save if, instead of going through their backlog, they just meet to check the points that they already have? Shall we say, a conservative 60% savings of time?

Now, let’s go back to our organization of 37 teams. That, plus RTEs and Portfolio Managers means that if you have 2 hours of sync per sprint, will mean that you will average around 185 hours (2.5 people x 37 teams, which is 92.5 people per hour of sync, times two, which is 185 hours). This will mean that you will save 111 hours per sprint. If you’re using two weeks for your sprint, this is 222 hours per month. This is more than a FTE of a high salary.

And we’re being conservative here. Once this is fine-tuned, the cost of missing a particular dependency is probably less than the cost of running the meeting.

Does this make sense? Of course, this is just a very brief way in which you can implement AIAA, but I’ll be exploring how to Augment Agility in further articles.

Let me know what you think!

#agile #ai #genai #safe #scrum #less

So…we’ve just finished the #M10D Challenge. This was an exponential challenge, beyond the #M6D by leaps and bounds. And it was incredible! We had people from Japan to the Aleutians, from Sweden to the southern Patagonia here in Argentina. But I also learn a lot about organizing it, and how it differs from the basic #M6D, so I thought that I would put this learning in writing. In case that this is the first article that you read about it, I suggest that you go to the brief explanation that I’ve posted here or to my Youtube channel for more in depth coverage. Also, you might want to refresh the previous Marathons based on #M6D. Also, just for fun, I’m including our playlist at the Present Show

So, first, let’s do an unorthodox retro. Let’s first focus on what has continued and what has changed between the other massive Meditation Marathons that we’ve done, #M6D and this #M10D.

What has remained the same

• The way to practice: you can follow up on your own or do it on a group
• The format: a series of timed meditations, through a series of pre-defined days
• The ways of contact: vía either mail, Facebook, twitter, Instagram or forum (if at IBM)
• The main distribution of people who sign up vs people who do all the practices (which are about a 4-6% of the total signers)

What has changed

• First of all, the number of people who signed up has been much higher than before (8.453 total) from a more diverse range of timezones and countries
• Instead of a single meditation and instruction, we had four different meditations across the ten days
• Daily webcasts so people can join and practice online with us
• More focus on production values: each meditation had a custom-designed flyer, a video in several languages and also audio

So, having said that, let’s go on the Bad, the Good and What We should Try Next

The Bad

• This was, actually, exhausting. Even with a small group of people helping me, the sheer volume of mails and questions meant that I spent about 3-4 hours more per day that I had planned, so the last days I was running basically on empty.
• The lack of segmentation that this meditation presupposes had an advantage: large number of signers. But it also made upkeep  very time consuming, since it means that every meditation should at least be recorded, edited, exported, etc…at least four times.
• A running issue through all Meditative Marathons and also Workshops is the low adhesion to the habit of Mindfulness, usually less than 10%. This is an improvement from the usual rates of 1-2% adhesion bandied about, but still, need improving.

The Good

• Great response from everyone who wrote about the meditations and the way they ramped up on complexity.
• A lot of good questions and follow up, which allows me to fine tune the next iteration
• It was super fun to be in a lot of live shows at the internet.

What should we try in the next iteration

• Having an established group of helpers who’ve had gone through the #M10D. So, basically, I need to come up with an M10D Facilitator Training
• I need to work on something that helps to keep up the commitment
• Also, I need to segment the way of getting the practices, so instead of producing a meditation in various languages across various media, I can cut the workload. For that and the previous point, I think that an app should be the way to go. I’ll think about it.
• As the last point: we’ve already got sponsorship from programs and corporations. I think we need to get serious and start talking government and education sponsorship and overview.

So…those are my points for the M10D. As you can see, they suggest a roadmap for what remains of the year. What do you think of it? Have I missed something?

F

Let’s dive a little bit deeper. How can we use Storytelling for something concrete? Say: how can we do Storytelling to reduce the cost of bringing up to speed a new team member who’s fresh from the street?

So, let’s think about the cost. Suppose that we bring someone right from the street into an established team. Let’s assume (I know, mother of dragons and disappointments, but let’s anyway) that the HR folk and that the person is neither a junior and that he or she has the skills needed for the job. What’s the main cost, then, that is incurred?

Mostly, I think, is getting him or her to have a transmission of experience.

What experience? The experience of that particular work and workplace. Because we love to think in abstract levels, every workplace and every team seems interchangeable. But anyone who has worked deep in delivery knows the truth: each team, like each project is a relationship. And like any relationship, it takes time and effort to get accustomed. Hence, the cost of getting someone to speed.

So, let’s again focus deeper. What is experience and how do we go about getting it?

Let me share how I got the insight on experience that I use at work. When I was young…or less old, anyway my first corporate job was in the worst of the worst areas: Development support. This was a job that theoretically entailed giving guidelines and best practices to programmers. But it practice, we were the Fire Department: we usually got involved in a project when it was just on the deadline and we need it online within a short timeframe. If you’re thinking that’s not a job for a rookie you would be absolutely correct. But it was a consulting manpower firm, there was a place open, and that was that.

So I tried not to flounder and was helped by this twenty seven year old guy, who at that time seemed to me to be the veteran of a thousand psychic wars. He told me, one night when we were staying trying to get some C++ code working “be glad, kid…this is the only thing to do. Yo do something and gain experience…look at me, I’ve been doing the same thing for the last three years and I know exactly now where the devs will have their bugs”.

While I appreciated his kindness and the interest on training me that he had, that answer bothered me for a long time. If you know where the bugs are…what are we doing trying to search for them at one in the morning? Also…why don’t you go beforehand to the devs and tell them? Those questions went back and forth in my head, until I realized what was the problem.

He was doing things but he wasn’t using that doing to really gain experience.

And that’s where I understood something about experience. For me, experience requieres doing; no two ways about that. You cannot be experienced in something until you’ve done it enough. But just doing is not sufficient. You have to reflect on what you’re doing and specially why you’re doing in order to compare the result of that particular case to the ideal outcome. You have to do, to measure and to adjust or improve.

So, for me, the formula is

EXPERIENCE = DOING + REFLECTION

Ok. So…how do we reflect on something, within, say an Agile Framework?

Let me introduce you to the

Agile Retrospective

A Retropective is a ceremony, a part of the Scrum Process that is executed each and every iteration, just at the end. The main objective of an iteration is to generate a reflection on how do we work. And this reflection is a vital part of the work. This is how we gain experience.

A retro essentially has two roles

• The team members who have worked
  The facilitator (usually a Scrum Master, but anyone can do it)

It is alloted between one or two hours of time, on the last day of iteration. If the iteration is two weeks long, it is done usually in one hour. If it’s longer, you allot half an hour per week.

The mechanism of the iteration is very simple. The facilitator opens the meeting and asks everyone to reflect on the iteration that just finished. Then he asks three simple questions:

1. What should we Start doing? What we would have been better served doing before and we need to formally include in the process? For example, does the client always have a delay in testing, so we have to factor it on estimations? Or perhaps do x stakeholder never comes to the meetings, so we need to establish a formal escalation channel for her?
2. What should we Stop doing? What do we do that makes no sense or actually hurts our work? For example: do we have meetings that we can pare down or eliminate entirely? Are we doing documentation for its own sake?
3. What we should Continue & Emphasize? For example: the Retro meetings are producing great experience. Shouldn’t we emphasize them and include more people so they become better known?

The way that this is done varies: some people use a “just shout what you want to say” approach. Some people use an object to designate a speaker (usually a rubber ball) where one can solicit from another team member at any time. Another way is to do a round, member by member. Yet another is to do an anonymous proposal in three jars, one for each category. It varies: personally I usually go by the ball approach and perhaps a member by member if that’s not working, but it depends on the team. This I let run for about 3/6th of the meeting’s time.


Image by Mountaingoat Software

After the part where we reflect, then we do a vote. Each person usually votes the most important item on each category or, if there are a lot of them, we vote the first three. That takes 1/6th of the meeting time.

The last part of the meeting is bringing out something where all the results of previous Retros are kept. I usually call it the Black Bible because I tend to use black notepads, but it can be an Excel, a Word file, etc. We enter the picked things into it, and we quickly go over the previous items on each category asking ourselves: have we kept what experience we had in our minds? If we thought that we should stop doing X two retros ago…have we really stopped or we need to again bring it to the forefront? This adding of the new items and review of the old usually takes 2/6th of the meeting’s time.

And that’s the way to generate experience in a group via Retro.

Storytelling comes in

Ok. So you got the why it is good to create experience and the how to create experience in a group. How does this translate in a reduced cost for a new member in a team? How do you transmit the experience of the group, that resides on its Black Bible to the new member?

The way it would have been done when I started working was depressingly literal: I usually was sat in a workstation by the team’s lead and given some documents, without context, to read. This was a very, very inefficient way: first I had to discover what the project was about. Then I had to understand the business side of it. Then, I had to start putting faces, names and roles together. Then I had to start going to meetings, hearing terms being discussed for current functionality and try to tie them in my own to the documentation, which by that point was probably outdated…and so on. I took in some cases months until someone was up to speed.

Imagine that you’re starting a project and are given its Black Bible. Probably it is full of annotations that doesn’t mean anything to you, like “We have to engage Larry two weeks before sending it to Mary” or “Need to emphasize clearing standards with John’s dept”. What does that mean? Who are these guys? How does that relate to the project?

And now, imagine something else. Imagine that someone takes the time to craft a small Business story for each one of the different parts of the project. An overarching story: what are we trying to do and why. Some small stories (called Clarity Stories in our framework) that talk about departments, roles, modes of work. Some stories that explain why we did what we did: these are called Solution stories…and so on.

This, of course, meant that there will be someone crafting these stories and someone tasked to tell them to a new arrival. This will take time, of course. In one case, for example, it took me about one full day to both tell the stories and answer questions about them. One full day + time to write and craft them…say…two more days.

Three days total…vs months?

I’m not claiming that crafting a story will make any person be ready to work as soon as three days. But here’s what I know: stories provide meaning and are memorable. How much more memorable is a well crafted story that a sheaf of documentation? Try it by yourself: who among those that are reading this can bring to mind the plot of the Red Riding Hood? The acts of the Story? The characters?

Ok, now try to remember the table of contents of the documentation for a project a couple of years back. The modules? The org chart?

Stories are more efficient. They excel at transmitting experience by co-creating it with their listener. If we use them alongside methods for gaining experience, the resulting accelerator will both reduce our cost and create a richer, more meaningful experience.

So now you know the why, the how and the way to measure it. Let’s give it a try!

I have been, of late, promoted to (drum roll, please!) Global Leader of Business Storytelling at IBM.
Now, this is one of those Linkedin updates that, besides the usual congrats tends to generate questions; questions that, like a bad case of political commentary can be boiled down to, basically, just one question.

“What’s that thing, Storytelling”

So I tell them; “I help people tell stories about what they want, to craft stories with meaning and emotion. And that helps them work and communicate better”.

And almost always, there it comes. Like the tide, like taxes, like the next big thing that ends up just like the old, tired thing. The follow up question. “Oh, can they just tell you the requirements? It’s not a big deal…they can tell you what they want and you can go work on that”.

Oh, sweet summer child; the winter of a client’s discontent has not wilted thee yet, but it will come to pass.

Any of us that has worked for some time in Scrum remembers when we called the User Stories “Backlog Items”. Why did we make the switch? Why don’t we call them requirements anymore?

Let me answer this with another question.

Who remembers Claude Shannon?

This dapper gent right here

So Claude Shannon, mathematician, engineer and the motherlovin’ Father of Information Technologies (Hi, dad!) thought that a story was, essentially a way to move a message from one place to another. That is, he thought of stories as quintessential data carriers.

In his view, that for a lot of years has been the default, when a client talks to a developer he only transmits flawlessly information, and just information about a rational decision that he or she has made and how he or she came to that conclusion.

And yet…has any of us that has truly worked on development had a case like this? I suspect not. Let’s talk, for example, about the Online Prospectus.

The Open University (http://www.open.ac.uk/) is the largest University in the UK. In order to enroll into a course, you have to go through an Online Prospectus (https://www.open.ac.uk/request/prospectus). When they designed that part, they just offered a course listing.

After some time, the people from OU found out something strange: they had the largest rates for enrollment in the UK…but also the largest drop rates. So, they thought, perhaps we haven’t included enough information. So they modified the Prospectus…but still, they found the rates unchanged.

So they did something truly revolutionary: they talked to the prospective students.

And when they talked, the OU people found out, firsthand, that the students weren’t interested as much in pure info than in how the courses aligned with their dreams and hopes. I don’t care as much for a course, they said, as long as it is a path for me to be a banker/footy player/shipwright, etc.

They also talked with dropouts. Like Priti, a Pakistani woman who had enrolled into an English course after she had put his career on hold to raise a family. But being a Pakistani emigré had its challenges, challenges that weren’t being met by a course listing. On how many courses is there a “Are you an immigrant from a former colony from South Asia?” check-box?

So what they do now, what they have found out keeps the best enrollment rates but reduces the dropout rates to almost nothing is…they talk to people. Just that. They hear the prospective students; they listen to their dreams and expectations. They have found out that they have to engage in the level of emotions and sell them into an idea before talking courses. And that they have to empower the student to be the co-creator of his or hers career path.

This is done via understanding the requirement of the student and the realization that a story is not something that moves information from a place to another, but rather a co-creation.

And yet…we know this. At some level, we know it. But we don’t use it in the traditional development approach.

Let’s say that you want to take a date to a fancy dinner. Not just fancy, but downright swanky. You find out the best place, a new place that you’ve never been into and make a reservation in advance; you fix your hair and meet your date at the door in your best clothes.

You are an Ace, that night. Witty and charming, you make small talk with the Maitre D’ and the waiter. Everyone is pleased, everyone is charmed. The wine, entrée and dinner menus are brought to you.

Now, at this point…do you just wave them down and say “I know what we want. Give us two burgers, medium rare, some fries and two Coors light, please”?

Of course not; you browse the menu. The Maitre might ask a quick question and offer a suggestion. You will review it and think how this is fitting. Perhaps the wine is white: should we have seafood? Or is it a deep red and some savory meet? What will we have for dessert? What will we have with dessert?. You decide based on a series of feedback clues and your own desire.

This situation is analogous to a development project. If you go into a restaurant, of course…you want to be fed. This is the general requirement. But what, how and in which order is not a given. Your date preferences, your own, the specialty of the house, what you will be drinking…the specific requirements will not be set in stone beforehand you walk into that place. It will be constructed by a dance of factors and will be rechecked at each course (if the Maitre is good) for feedback. While we know that we want to have a memorable dinner, we don’t know exactly what we will get; and that finding out is what makes it great. The story not only provides pure information, but also motivation and context: what are we looking for?

And yet…when we expect to work in something much more complex than a dinner, something as complex as a development project…we assume more and have less time and interest than when we go to a fancy dinner. We end up ordering burgers, all the time and then complaining that they weren’t as good as McDonalds. We have to get to grips that while we can have a general idea, this is more a framework than a real requirement. The specific needs to be worked on, distilled like a good whiskey from the malt.

And the distillery is the Storytelling act. If you don’t think that it is important…try drinking dried malt.

NUNS fret not at their convent’s narrow room;
And hermits are contented with their cells;
And students with their pensive citadels;
Maids at the wheel, the weaver at his loom,
Sit blithe and happy; bees that soar for bloom,
High as the highest Peak of Furness-fells,
Will murmur by the hour in foxglove bells:
In truth the prison, unto which we doom
Ourselves, no prison is: and hence for me,
In sundry moods, ‘twas pastime to be bound 10
Within the Sonnet’s scanty plot of ground;
Pleased if some Souls (for such there needs must be)
Who have felt the weight of too much liberty,
Should find brief solace there, as I have found.
1806. William Wordsworth

Wordsworth certainly knew what probably is the main stumbling block to an Agile coach after we start a Transformation, the wailing that won’t quit. Why so much structure? Why do we have to have Sprint Reviews? Can’t we do everything in the Retrospective?

When one starts an Agile transition or an Agile transformation, there are, always, forever, two big stumbling blocks. One is hit with the toe right away: the roles. How come there are no Managers? Hey, I’m a Business Analyst, why I’m grouped with the Developers? And so on. This usually is solved with a two-pronged approach: some clear concepts and some good working techniques deployed by the Coach usually are enough for the team to start working and from there, the methodology itself works its magic.

But the second stumbling block rears its head later, stubbing our little toe. Why, oh why, do we have to do all the sprints the same way? Why can’t we do the daily when we need it? Why don’t we plan the meetings in an ad-hoc basis? Sure, that’s more Agile and flexible?

This questions have a very simple answer: because Constancy Reduces Complexity

Let’s go back to our elementary education. In my case, I went to a state school where we were supposed to express poetry. To this day, I still don’t know exactly what they meant. When I was in the 4rd grade, they had poetry reading and composition, which meant that you had to go to the front of the class and read something you wrote.
Now, I was never a particularly bright kid, but the depths of my confusion were unplumbed by human mind. Having some time to prepare, I took some books on poetry and basically mock-copied the metric (a copy-paste before there was copy-paste) and wrote something about a bird in my window. I don’t have it anymore and repression, having done its work in preserving my sanity (such as it is) has divorced me from the exact lines, but they were unimpressive, but certainly metric.

So, being called Andino in a school that used alphabetic order meant that I was going to go first and didn’t know what to expect, which didn’t help. But anyway, I did the work and the next Monday I was trying to not giggle while I recited my fourteen line shade of a sonnet.

There were some giggles in my fellow classmates (which didn’t mean anything, we at that age giggled at everything) but glacial silence from my teacher, which I knew it meant that I did something wrong. This particular teacher was also not very communicative, so I waited in silence while she decided on what to say.

After a short while, she spoke

“Federico”, she said in that cold, disappointed voice “that is not a poem”.

“well…” I tried “I thought that fourteen lines makes a sonnet. My book says so”.

“That might as well be” she said “but as usual, you missed the main point”.

And silence again

Now, I was then, as now, a little bit of a contrarian spirit. If she didn’t get around to say what was wrong, far from me to ask her. So she stared at me and I stared at nothing; tar pits of silence grew to entangle the saber-tooth tigers of talk.

She broke first, I recall.

“You have no emotion. You’re not expressing yourself. Who cares about a bird? You worry so much about structure that you forgot to cry”.

And so, the start of my great hatred for poetry began; luckily, I was, in my twenties, to read it again and even write some published sonnets and the like in books. But from age ten to twenty-two, the memory that I had associated with poetry was of the rest of my classmates who (being smarter than myself) had got the message loud and clear. The next, a girl, started crying and talking how her father didn’t love her.

This is what lack of structure brings. Emotion? Sure. Have you ever sat through a recital of excited pre-teens who have been told to express yourself fully without caring for rhyme or reason?

It is enough to yearn for Mencken

Every normal man must be tempted, at times, to spit on his hands, hoist the black flag, and begin slitting throats.

The same happens when one tries to be Agile without any caring for the structure of the methodology. Let’s take a simple example: the Daily. Say, someone says: let’s have the daily when we need it and in the time that we have free. That entails:

• That one person, at least, must have a clear criterium of what we need is.
• That this person can communicate that this criterium has been met
• One person that tries to negotiate the calendar time of every member in the team
• That the meeting time agreed is communicated
• That everyone attends the meeting

Just how much more complex is that compared to just show up for fifteen minutes every day in the cafeteria? There can be a lot of things that can go wrong with the complex example; very little chance that, day in and day out, people don’t get in the rhythm of Agile. And if someone’s sick that particular day? There’s always tomorrow.

This example boils down to something: Agile Is something you Are, not something you Do. You can’t be Agile without the mindset. But the mindset is not gained in a single, one moment thing. It grows from rhythms and seasons, like any good organic thing. And in order to grow strong, we need to reduce the possibilities of going wrong. And for that, again, Constancy Reduces Complexity.

After all, as Wordsworth said:
In truth the prison, unto which we doom
Ourselves, no prison is