Prescriptive agile?

When working with new teams there's always a "learning curve" we all have to climb. So I tend to use the phrase "prescriptive start" when working with new teams. It's my way of letting a team know we're going to start with a small set of things the team must do. It's the basics and it will get us started. We can't learn a hundred new things, so let's start small. Let's get going and not try to boil the ocean.

Is it ok to call any form of agile prescriptive?

Definition: Prescriptive - giving exact rules, directions or instructions about how you should do something - from Merriam-Webster dictionary

Scrum lays out a specific set roles, events, artifacts and rules that bind them together. The Scrum Guide is only 16 pages, as compared to some other approaches. I know, I know:

• We do Scrum, but we don't find much use in having a retrospective... 
• We do Scrum, but we don't meet daily instead we meet on Tuesday and Thursday.
• We do Scrum, but...

You can find the full description in the The Scrum Guide.

If you are doing Scrum and not some variation of Scrum, but, then you know there are set of specifics that are part of Scrum. If you're not doing the basics you're doing "Scrum, but."

Domain modeling

A while back I posted a few modeling examples. Today's post is going back to that. This is the domain model. Again this model is for a simple library system which shows how concepts in a domain are related to one another. A box in the diagram is a term or concept. The lines represent connections and the labels on the lines show "how many" for the various relationships.

Cardinality illustrates business rules. As an example a Patron has one and only one account. And an account is associated with only one Patron. An account may have 0 to many fines on an account.


I've found that when using this model it helps to establish clear definitions of the key relationships in your domain. Some of the benefits of a domain model:

• Helps in understanding the problem space
• Creates a common vocabulary 
• Developers can understand the terms and relationships
• Shows what's in and what's out of the domain
• Allows the team to share with other teams when working together

I've used the term Visual Glossary for a long time - long enough I don't remember who said it. I've used it for a while. Either way - it's a visual glossary of the terms in the domain. Give it a try and see if it helps out.

Estimation - Musical Sizing

Do you want to have fun when you're working with teams. Is there a place for fun while working through a 2-day planning workshop? Maybe so...

Agile Requirements - Activity Diagram

If I had to pick one diagram that most people have seen and generally understand, it's the activity diagram. Sometimes called a process flow. The activity diagram can illustrate complicated flows. 

Agile Requirements - System Sequence Diagram (SSD)

In the Previous Post I talked about the System Context Diagram. It provides a high level view of a system and it's interfaces that make up the overall ecosystem for the product under development. The system context diagram is a static model, meaning it doesn't show interactions/changes over time. From a context diagram, we can create another model, the System Sequence Diagram (SSD) that will show interactions over time.

Agile requirements - setting the context

Still in the series of posts about requirements related artifacts - previous post. When I say requirements related, I mean something that assists us in understanding the system under development. As in past posts, the user story, scenarios & tests are all part of the requirements package. What else is there? What other kinds of things can we produce that add value & enhance understanding. As a coach many times when working with a new team, I'm listening to the conversation and I get lost. There are too many applications, acronyms, systems for me to understand what's going on. When I'm lost I almost always ask the team to allow me to draw a system context diagram.

Agile Requirements - what's beyond the user story?

In the my Previous blog I talked about a metaphor to illustrate requirements evolving from a 1-liner, to a paragraph, to a 1-pager, and then to multiple pages. In the process of building systems using agile approaches many teams have forgotten, or worse have never known how to document details around requirements. There's that pesky agile value - "working software over comprehensive documentation." Too many teams take this to mean we no longer have to write anything down. Not so fast cowboys.

Why have we forgotten about requirements analysis in our agile world?

As I coach teams, inevitably the discussion about requirements comes up. Some of the things I've heard from team members:

• We don't write any requirements
• A user story is all we need for requirements
• We don't have time to write requirements, we just talk with our Product Owner
• Since we don't write requirements, we just figure out the features on our own and show the completed work to our product owner
• ... 

When I think of requirements, I think about who consumes them and the value that the consumers get from them. Many teams have lost their way when it comes to agile requirements and requirements related artifacts.

Context Switching - so you think this is a good thing?

Last post we talked about Agile Clowns multi-tasking and that research has shown that we can't actually multi-task except for repetitive, memorized types of activities. You can't truly multi-task (do 2 or more things at one time) for cognitive activities. Since we can't multi-task, the real issue is context switching. How many projects are you working concurrently? Are you dedicated to one project? Great. Keep it up. Do you have 2 or more projects? 3 or more? Then you're not going to be very efficient.

Agile Clowns or "How to be a great multi-tasker"

What phrase did I see on your resume? Oh yeah: "great multi-tasker." That's awesome! You pride yourself on delivering more in less time by juggling several projects at the same time. It's a badge of honor and you wear it proudly.

Sorry to break it to you, but a clown is better at multi-tasking than you are. If a clown can do it, you must be able to do it just as good, even better.  The question is, are you sure about that?

It surprises me when people don't read and learn...

As a consultant at Improving Enterprises, I regularly have an opportunity to meet and interview potential consultants for our company. As a company we always strive for excellence and that includes continuing to learn. So I always ask candidates about it.

Appreciation in Agile teams - "Shout Outs"

Here's a simple idea that provides great benefits for teams. I was working with a team that started giving "shout-outs" at their retrospectives. Any team member could take a minute to recognize other team members for anything they did - whether it was to help someone, take on a task to help out, take on a role even if it's not their primary role.... how do you think this worked out?

Agile Lunch 'N Learns - ongoing practice

This is well known and simple to use. At my current client, which is in the middle of a large agile transformation, we have regular lunch learning sessions within the various Director's organizations. Not all groups are involved yet, but we working on it. In one of the groups I help we conduct a session about every 2 months with a final retrospective session near the end of the year.

Card Game Ends

It was fun while it lasted. You can look back over the various cards to see how they apply to agile, or maybe they don't apply. This card clearly ends the streak of cards that could be applied to and discussed in the context of agile projects. Living in the Moment by Barbara Ann Kipfer (a deck of 52 inspirational cards).

If you're on a spiritual journey this card applies, otherwise it's just too much of a stretch to make this apply to agile development. So, the card game is over. Back to regular posts after this.

Agile - Act Now

Yet another card to continue the game of drawing cards. This one is about acting now. Living in the Moment by Barbara Ann Kipfer (a deck of 52 inspirational cards).

This continues the theme of focusing on the now, not the later. Keeping in mind that we can only deal with the present moment, not the past and not the future.

Overflowing - Make room for new ideas, new practices, ...

The card game continues. Here's the card I drew this time... Living in the Moment by Barbara Ann Kipfer (a deck of 52 inspirational cards).

So what does this one mean in an agile world.

Agile - Aware Now

Ok, so this picking of cards still seems to be working. This time the card reads:

How does this apply to agile? Living in the Moment by Barbara Ann Kipfer (a deck of 52 inspirational cards).

Agile - now, for later

If you read my last blog you'll know that I pulled a card from a deck of 52 cards my wife has. I then decided I would try it again to see if the card provided impetus for this blog. Here's what the next card had on it: "Now or Later - If you desire a glorious future,, transform the present - Patanjali (circa: 2nd century CE). Living in the Moment by Barbara Ann Kipfer (a deck of 52 inspirational cards).

Some say Patanjali was a single person, others say Patanjali was a series of people who wrote sage advise and wisdom some 5000 to 7000 years ago. I've read some of Patanjali's works and find them interesting.

Back to the card. Ok, so maybe this deck of cards is a pretty good content generator. We'll see when I pick the third card for the next blog. Who knows maybe I have 50 more blogs ready and waiting.

Agile Metamorphosis

I read the following card from a card deck my wife has, called Happiness is Living in the Moment by Barbara Ann Kipfer (a deck of 52 inspirational cards).

When I think about it, that's what I try to do with the teams and team members I work with. I'm asking them to do something different, something foreign to them. Do they understand? Are they just following instructions? Is it becoming part of them? Do they understand how things are shifting?

Building trust on agile project teams

Do you want to know how to build trust? Make an agreement and keep it. Tell the truth. Be transparent. Be open and honest. Give without expectation of getting anything in return. Then do it all again.

In some engagements where I've worked to transform organizations, lack of trust was a big challenge. I've seen IT groups consistently miss commitments, leaving their business partners questioning IT's ability to deliver. Using the practice of incremental delivery with frequent demos & reviews is a great way to change this dynamic.