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.

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.

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?

Want to deepen your knowledge on agile? Start teaching it.

The first time I heard the phrase 3rd person teaching I wasn't sure what the presenter was talking about. It was in a Covey Principle Centered Leadership class and I'm pretty sure I was the only person in the class who didn't know what it meant. Or maybe some of the others weren't brave enough to admit they didn't know and they breathed a soft sigh after I asked and the instructor answered. The simple idea is that someone teaches you, then you take what you've learned and teach someone else. When you do this your depth of knowledge increases. So why not try this with agile?

Data centric projects & user stories

I've been able to work on a couple of types of data centric projects. One was creating an ODS based on consolidating customer data from multiple source systems. This involved finding the data, extracting, transforming, & loading, as well as matching customer records, de-dupping, address matching and data cleansing. Now I've been working with some teams who are focused on moving data into a data warehouse. When first working with data teams a typical reaction is that we can't do user stories. Or we have to complete the whole data model done up front. Or we have to load all the data at once otherwise we're duplicating work, ... Basically I get a reasonably long list of why we can't do incremental development for data centric projects.

Agile on COTS projects (for example: Siebel)

Over the past few years I've heard people say - you can't use agile when doing a package implementation, such as Siebel. Does that make sense? Does agile work when building a Siebel CRM or Loyalty system implementation?

Multi-tasking - is it really this bad everywhere?

Multitasking is killing many of the projects I'm currently coaching. Team members literally have 3, 4 or even as many as 5 projects going at once. Teams are formed with multiple members, each on multiple projects. In almost every case, where there's heavy multi-tasking the teams choose to have their daily standup two times per week. Catch that - daily standup, only twice per week...

Embrace your circumstances

Ever notice how some people and some teams seem to thrive in adversity. They seem to be at their best - it's like they're waiting for the chance to show everyone just how strong, how capable they are when the going gets rough. Last year this hit home for me during the NFL season. The New England Patriots, in particular Tom Brady their quarterback, have an extraordinary winning percentage in extreme cold weather conditions.

Reflection

This is Part 5 - the final part of the series

Part 1     Part 2     Part 3    Part 4     Part 5

Well this timing worked out just perfectly. A new year is here; time for reflection which is the last topic in this series on what it takes to improve performance of individuals and teams.

In the previous parts of this series I've used sports and music to evaluate lessons learned on improving  performance. Continuing with that theme, reflection occurs as a natural part of the process of learning. Reflection is also a natural part of agile development and agile coaching. In fact it is the primary way we improve our performance. Inspect and adapt.

Focused Attention

This is Part 4

Part 1     Part 2     Part 3    Part 4     Part 5 
In the context of practicing a musical instrument or a sport, the student can Practice, Practice, Practice all they want, but if they are mindlessly practicing they will not achieve the same level of proficiency as when they are focused towards achieving specific goals.

A few years ago I worked with a client where the IT group was very consistent in their delivery. Unfortunately, they were consistently late on every major initiative. I attended a meeting two weeks prior to the scheduled launch of a newly developed system where the team was discussing basic requirements questions. On another initiative the testing plan was first being discussed as the team was preparing for final data conversion and system launch. I watched other project teams fall victim to delays because of partially allocated resources. And the list goes on.

A Great Coach

This is Part 3

Part 1     Part 2     Part 3    Part 4     Part 5

Great coaches know their sport, know their game, know their playing field and are able to guide & teach to improve performance for individuals and the team as whole. Great Coaches get the most out of their teams.

If you're adopting agile, you're new to it and no one in your organization knows much about agile, it's best to find a great coach to help you get started and progress rapidly. 

Practice, Practice, Practice

This is Part 2

Part 1     Part 2     Part 3    Part 4     Part 5

Growing up I was in the marching band, in the drum section, which to me was the coolest section. As I was learning to play the drums we practiced rudiments - single stroke rolls, multiple bounce rolls, flams, paradiddles, ... Rudiments are the components that allow drummers to play various techniques creating the wide variety of sounds you hear in music. When first learning it took extra time to figure out how to control the sticks, how to keep the right beat, how to play the right sequences. We practiced slow at first then began to increase in speed. We practiced over and over and over again.

The same was true for the times I played sports. For example, in tennis we had a ball machine that would launch one ball after another to the same spot, where I would have to hit cross court forehands over and over and over again. This style of practice allowed me to improve my skills and become a better drummer and tennis player.

In the lean and agile worlds there are a couple of key aspects that allow us to practice.

Learning Agile - Thing One, Thing Two, Thing Three & Thing Four

This is part 1 of 5
Part 1     Part 2     Part 3    Part 4     Part 5

Growing up I enjoyed playing sports. I played little league baseball as well as basketball, tennis, golf and volleyball. In those sports I had very different experiences learning each one and looking back I see how those experiences apply to the world of agile coaching.