Infusing some Kanban...

The team I am working with was starting to have a few issues. We had too much on our plates, lots of noise, and the CEO was raising concerns that we weren't focused on the right things. We also had a feeling that the sprint end and begin was a magical flurry of stressful activity.

So we've implemented some changes:

• Our cards on a wall board is now restricted. Only 5 things can be in flight at a time. Everything is still in VersionOne; but only the top 5 get the explicit visibility of being important enough to be covered every single day.
• The CEO (highest level product owner) is responsible for filling and prioritizing the +5 queue whenever there is an opening. These are the next 5 things expected to move into flight.
• Our standups are no longer going to be asking the 3 questions going around the circle in the sequence we lined up around the room. Instead we are going to first talk through the top5, and then use the time remaining to discuss other notables as people need to. The team is responsible for taking their turn by importance and not going in sequence.
  

Our hope:

• This will shift focus from what "I am working on" to what "the team is delivering for the company".
• We might not get to every topic since not everyone will have an explicit turn, but we guarantee that we are talking about the right things.
• Outsiders can attend the standing meeting and easily see certain items and their status as opposed to hearing about an item across people throughout the meeting.
• We force the business to shift from magically identifying 5 things every Friday (1 week sprints) to constantly filling a pipe of work every day as we empty it.
• It is easier to see if our commitments of date and cost are at risk and communicate that to stakeholders because the topic is covered at once. (Our commitments are more safely limited to the top5.)
  

We see how it goes... (like many issues, we'll implement changes and slowly snap back to a happy medium as we learn and grow)

SM vs. PM...

Great thread on the VersionOne user forums-


Question from Andre L. Nelson

We have been having a big debate at my company about what is the role of the Scrum Master and the PM/Supervisor in Scrum. We are uncertain if they should be the same person or if they should be separate people. ... I'm kinda just throwing out a line and hoping for some insight from the community about either what they are doing with this or if there are any other posts or blogs I could read for insight.

From Skip Angel, SolutionsIQ Agile Coach:

Here's what I usually ask to determine if the person can be effective
as a ScrumMaster:

• Will the team have autonomy so they can truly self-organize?
• Will the team be able to make their own commitments each sprint?
• Does the team trust the ScrumMaster to protect the team so they can have focus?
• Will the ScrumMaster allow the team to determine the best solution and approach to work that makes sense for them given their collective team skills, knowledge, experience?
• Will the ScrumMaster uphold the Scrum process when things get challenging?
• Is the ScrumMaster somebody the team feels comfortable bringing impediments and bad news to help resolve?
• Is the ScrumMaster a good facilitator that will help the team get through meetings but not be a participant in those discussions?
• Does the ScrumMaster have the authority to do whatever is needed to resolve or escalate impediments the team is having?
  

If there are more No's than Yes's above, I would seriously consider looking for another person that is better suited for the role.

My thoughts:

• For me, the scrum master is dedicated to a scrum team (or at most two).... the project manager may not be.
• Project managers should focus more on resources (hiring/firing/vacations), managing dates (setting expectations), and managing risk
• Scrum masters should focus on the team, process, and impediments.
• I can envision a person doing both roles if the project is supported by only one scrum team (or two).

In my last company, we had 8 scrum teams working on 8 modules that built up to one product (and one release schedule). In this case, we had a product manager and a separate project/release manager working across those 8 scrum teams. I was the scrum master for one team. I dealt with the issues that Skip mentioned, and the project manager dealt with the scrum of scrums issues. This is one example where both roles are needed.

Some people argue different viewpoints on this topic, but I believe the answer differs greatly based on the size of the company, the alignment of scrum teams to products, and the culture of the company.

I wish I worked there...

Actually, I'm [probably] on a cruise ship in the middle of the Caribbean right now... so I'm in no position to complain. But, there are days where I ponder if it would be more fun to work a specific role for a company that is successfully agile, or to work in a company-wide Process/Project Coordinator role like my current one where I can constantly infuse agile concepts into the business in a stealth manner.

I'm undecided...

But, if I were to look for an agile company... it might be a little bit like this.

Register now...

I've gone for the last two years and I have to say it has been an amazing learning and networking experience.










I encourage you to consider going to Agile 2009 in Chicago this year even though I won't be able to go myself.
(I'm expecting my 2nd child to arrive that week!)

Simon Baker's Dozen...

Agile Coaching statements:

#2 - Focus on Purpose, not Process
#3 - Think Big, Start Small
#6 - Working Code Beats Everything
#13 - Be Effective Before Efficient

Read the full list with descriptions.

Permission is not needed!

Over the last few years momentum has increased around the agile movement. It goes by many names (Scrum, XP, Lean...) but they are basically pointing at the same core inspiration: allow the team to be part of the decision making, quality, and accountability chain.

Typically people on the bottom have felt abused by the old system and latch onto this new system. Some test it successfully, and others yearn for more time to learn. Either way, the secret eventually escapes about their activities.

And then the dirty question rises: How do we convince the business to let us keep doing this great thing that increases our morale, quality, and predictability but is not easily quantified in the old world of thinking.

This is where I get confused. Since when did developers lower themselves to a blue collar status. Your job isn't to punch widgets, or flip burgers and assume that every break is clocked and pre-approved. We are a college educated group of people that bring a disciplined skill to our environment. Nobody asks the artist to make the artwork in half the time... only the artist can dictate how long it will take to do their work. Why are developers different?

Alan Cooper's keynote at Agile 2008 spent a lot of time talking about how the software process is more like a trade or craft than an engineering process that can be tuned like a factory. This was his foundation to explaining why usability needs to be incorporated. Here's an expert telling us..."Own your work!"

Then one day later, Uncle Bob presented a keynote that clearly stated the same point again... "Own your work!" His initial summary was craftsmanship over crap and led to a standing ovation of 2000 people which are all leaders in the agile movement.

Today, Tim Ottinger talks about fear of refactoring, TDD, and doing it right and tries to answer the question yet again. He also reposted from the XP mailing list a quote from Jame Grenning :

There are two values to software
1) Business value delivered
2) Ease at which the next important feature can be delivered

There is a theme here folks... quit asking for permission and own your work.

I've always struggled with the existence of the permission question for two reasons:

1. I started my career as a developer with a computer science degree and feel I can relate to the issues developers are going through today (though it has been 8 years since I wrote any real code)
2. I spent more than 5 years as a usability engineer. This role forced me to constantly justify the time and science behind this craft to insure I was allowed to do my job correctly. I was fighting against the mentality of developers that user interfaces had to be built with intention and to the business that this process was cheaper than not doing it.

So, I've always had to defend my craft. I've always had to sell my worth. And because of it, I've been successful at reaching my career goals.

Once again, I find myself pointing to the keyboard and saying get back to work and do your job the way you know you need to. Stop letting them make you compromise so much. Prove to them why you are so valuable and stop marching according to their defined instruction. Be the expert at how to do your job and manage your craft!

Now, go forth and quit asking this silly question.

Note: before you take my advice, become a maverick , and get yourself fired you should probably read J.B. Rainsberger's paper from Agile 2007 about "My Greatest Misses: XP"

Local Build... how big and how long?

Peter Morlion raised an interesting topic on the Agile Alliance LinkedIn group about how long a developer build should be allowed to run. It seems his team is split down the lines of "its important, so suck it up" and "this delays me too much, make it better".

His full question was:

Local build takes a while - run a stripped-down version?
Like in a lot of teams, we update from the source repository, change code, run the build locally, and commit if it builds. So far, so good. But the build takes a while of course. Personally, I think that's just something to live with, but my teammembers want to use a stripped down version of the build (mainly not building the sandbox, because it doesn't change much).
What is your opinion on using a non-complete build before committing, while the build server still runs the full build?

As one of the first to answer I said:

I would agree with your team members... unless I already need to take a smoke break every hour or so, that does not enable higher productivity. ; )

In my last team, the local build included the tests... If your developers have to wait more than 2 minutes for the process to complete, they start seeing this time investment as an impediment and may try to work around it by coding larger chunks before committing and integrating. This is the reverse direction agile maturity typically should take a team (especially a team leveraging TDD).

The sooner someone can verify something in the integrated build server, the better off the team will be. The purpose of the local build is to smoke test the local and obviously connected things they are focused on.

A balance has to be created between the two. If you swing too far in the other direction, then the team is hurt because the integrated build is broken more often.

Good luck finding the happy medium.