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.

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?

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.

A new day

"Agile - day by day" is simply a place to talk about practical ways of applying lean and agile principles and practices for individuals, teams and organizations. What I see in the work I do to help teams move to agile approaches, typically with a mix of Scrum and XP, will be the primary source for my blog entries. However, looking to other areas & other fields, will also yield interesting and useful information we can  apply in our agile world.

The first few blogs will be based on what it takes to become good at something in general and how those same ideas apply to learning agile principles & practices. An initial look at how students learn to play a sport or a musical instrument will show the keys to learning anything new.