AIAA Jam 2

Epic Rockin'

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!

Agile nuns

Constancy reduces Complexity

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