Agile teams have no leaders, because everyone on an Agile team is a leader. However, leadership is still important. So, how does leadership work if everyone is a leader? Here are my rules:

1) If something needs to be done, do it. Do it very, very well.

2) Never do anything by yourself. Always ask for help. Always give help.

3) Don’t delegate, cooperate. Never tell anyone to do anything that you can do for yourself.

So who is really in charge? The customer is. The customer knows what she wants and what she is willing to pay for. The team must deliver that.

The team gets to decide how to meet the customer’s needs. You won’t always agree. You have to work it out.

Remember that the right people showed up. You will solve the problem to the best of your ability and so will your teammates. Telling them how is counterproductive. If you know how then do it yourself, but involve them.

If you work this way everyone has an opportunity to succeed, to learn, and to grow.

Good unit tests are:

Fast – they run in no more than a few milliseconds on typical hardware

Isolated – they remove any dependencies using mocks which verify the way the dependencies are called and stub the return value.

Repeatable – they have no dependence on external state and can be run over-and-over with the same results (Unless the code changes.)

Examples – they demonstrate the way that the code is intended to be used and thus enable Coding By Intention (If you write them first.)

(note: due respect to the author of FIRST but I prefer my version.)

Odd Question, isn’t it.  We spend all this time focusing on getting the story to be the right size, chiseling away on the ones that are too big to fit in a release, and so on.  Then we turn around and fight the good fight when Scrum and Agile scales up and we are faced with keeping multiple teams working in peace, harmony and synchronicity.  It is this last problem that I keep on dealing with, particularly when trying to introduce Agile QA.  I got so frustrated that I took Jim Highsmith’s advice about “more being written about Agile than is known”, stopped reading Agile and read other things – like the Harry Potter series and 20^th century history.  It is here I re-read the words that on May 25, 1961, changed a generation’s life. President John F. Kennedy said in his, “Special Message to the Congress on Urgent National Needs,” before a joint session of Congress.

“I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth.”

It struck me it was ‘the’ perfect story. It has a role, action that had to be taken, and a goal.  But most of all it had a very tangible, clear, and explicitly well defined definition of DONE – “returning him safely to the earth.” What a story!  What an Epic! What a way to get a nation – a world – to focus.   But it wasn’t a user story – it had this timeboxing clause,”before this decade is out,” that started the clock ticking.

I refer to it as a Focus Story. It serves as the transforming agent changing a poetic visiony user story into a ‘Mission Statement” and a Commander’s Intent”. With it in place, at the top of Product Vision, enough guide rails are in place to make reasonable initial roadmaps, release plans, prioritization criteria, and definitions of done.  But most of all we have a means to understand core values criteria “safely to the earth”.

We also have triggers to inform us when we are losing focus –  Meetings get longer, Done isn’t understood. Pieces don’t fit and the conventional mindset you have been struggling to win over sighs and goes back to its safe place of waiting for the fad to die.  When these show up it is time to revisit the focus story and build a bigger focus or wrap up what you are doing.  Otherwise you risk having “O”rings show up on your Columbia launch.  Nobody wants to be part of that type of bad day.

I posted this several years ago but can’t seem to access the original blog. So here is a re posting.

I have been meaning to share this for a while.

Holding team meetings where the team members are not in the same place is not fun, and it becomes less fun the more distributed the team becomes. The following rules of thumb came about when I had to run teams of consultants where no one was in the same place and the places they were ranged from their office to their home or car, or airport lounge, or even their bed when they were in on the other side of the world.
The first thing we noticed is that a little more structure and role definition was required so that people could better self herd themselves

Roles
a. ScrumMaster run the scrum, keep time. Must have good phone that does not add noise to the line

b. Scribe take down key points (usually this person was the one in the office or someplace where there was a horizontal writing space and enough quiet to concentrate)

c. TeamMember person who kept their phone on mute unless given the ‘stick to talk’

The second difference is the structure needed a protocol to insure everyone could participate. This led to the following team driven agreements on the Scrum. The most important of which is the timebox with a Max time of 15 minutes to complete the following:

Rules

1. No speaker phones. These are great for everyone sitting together but terrible to listen to.
2. All actions are time boxed
3. First activity is for each team member to answer the questions three with no interruptions (15 secs max per task)
4. Team members keep their questions, comments, and what-have-you on stickies
5. ScrumMaster reports out all actions on blocks, and any new information
6. At the end of the questions 3 the ScrumMaster polls each person for any questions Team members tear up any duplicate stickies
7. Open Microphone – general discussion on each thread – 1 minute max for each comment
8. Synch questions – questions designed to clarify any stray points – 30 sec
9. Take aways and off line – people who want to dive on a point set up a time to set it up and do it, no calendar trolling allowed on line.
10. Scribe time – scribe gets to set the noodles in a row and send out email
11. ScrumMaster Sums up. Sum up includes acknowledging blocks, key linkups, and next meeting time.
12. ScrumMaster asks “What did I miss?” and team memebers fill in holes and then concurs with summary.
13. ScrumMaster then announces “SCRUM Over, Open Microphone for as long as people want it.”

Things to improve this

Team writes up their questions three and sends to Scribe before meeting. Scribe then cuts and pastes into a single email and sends to team during meeting. Teammember still reports them on line.

Conventional wisdom says that literal values in code are bad and should be replaced with constant fields. The usual justification is that when you need to change the value it is easier to change the value of the constant than to change the literal in the various places where it appears. This avoids the real issue: why is the value appearing in multiple places?

Constants are a deodorant. Rather than using a literal value in numerous places, which is bad, we empower ourselves to reference a static field in numerous places, which is almost exactly as bad. Perhaps instead we should consider what concept that value represents that needs to be reused all over our code and find a way to encapsulate that responsibility.

I recently spoke at the two Agile Journal Events; one in Boston and one in Newark and I spoke as the keynote about Agile Software Development and how there is so much more value to it than just turning out software faster, cheaper and with less defects.

There really is a lot of say about this, and I intend to write more,  but for now I wanted to make my presentation available. It can be downloaded here: Agile Beyond Faster, Cheaper and Less Defects

Scrum-But, Scrummerfall, other fizzled Agile transitions…

Goldratt describes these things (not directly), and similar phenomenon (like failure of companies to get the real benefits from ERP, SAP, 6Sig, Lean, etc.) nicely:

Organizations make rules to deal with/operate in the presence of limitations.  By rules, I mean rules, processes, structures, and other arrangements and things (see the dictionary definition).

Technology (see the dictionary definition) improvements remove limitations.

For a change to truly take hold and succeed, the rules that were made to operate in the presence of the old limitations must be eliminated or changed, and new rules created to deal with new limitations

more »