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.