Guy Kawasaki: The Art of Evangelism

Thursday, September 27, 2007 10:52:21 PM (Mountain Daylight Time, UTC-06:00)

I'd have to admit that I have been in a slump lately.  Work was getting me down.  The Scrum Team in our local office has been doing great.  However, we've been fighting an uphill battle to bring agile practices to the rest of our organization which is heavily entrenched in waterfall and traditional thinking.  Things were seeming stale.  I needed something to pick me up and get me back on track as a Scrum evangelist. 

 

On Wednesday, Dave Bouwman and I tuned in to a Webex presentation that Guy Kawasaki was giving entitled The Art of Evangelism.  Guy is one of my favorite people to turn to when I need inspiration these days.  He is the former chief evangelist of Apple and is currently the co-founder of Truemors and the managing director of Garage Technology Ventures.  Guy's message was so upbeat and inspiring.  It made me want to get back into the saddle and start evangelizing Scrum in our organization again.

 

What did Guy say to make me snap back into reality?  "The most important thing about evangelism is to make meaning.  It's easy to evangelize and get others to evangelize things that are meaningful...things that change the world, make the world a better place."  I'd been so entrenched in making Scrum work for the sake of Scrum that I'd forgotten to make it meaningful to everyone in our organization.  To make things meaningful, Guy suggests that we:

- Perpetuate good things

- Create good things

- End bad things

 

I needed to step back and start living those words.  They fall right in line with Scrum practices and I needed to hear them again.  I needed to get back to affiliating, creating, and associating myself and others with the good things that Scrum promotes.  As Guy says "Great stuff is easy to evangelize.  Crap is hard to evangelize."  I sincerely believe Scrum falls under the great stuff category.  Time to start evangelizing again...

If you want to watch the Webex of Guy's presentation, it was recorded and is available at http://www.webex.com/web-seminars/view_recording/662851581.

Ocean’s Eleven: The perfect agile model?

Wednesday, September 26, 2007 10:15:47 PM (Mountain Daylight Time, UTC-06:00)

One of the things I love about Scrum is that it treats team members like adults.  Teams, not managers, decide what work they do in each Sprint and how to estimate it.  Teams decide how to adapt their processes to maximize their efforts.  Teams decide who the best person is to accept a task. Teams decide what the common goal is and they stay focused on it until it is achieved.  We all get to act like grown-ups again.  We all have a stake in the outcome of our process and we all have input into how we achieve our goals.  However, along with this flexibility comes responsibility; responsibility to the Team and to the Product Owner to deliver value and quality.  For all of this to occur, an organization must have a culture that not only supports this kind of thinking, but also thrives on it.  The organization must foster a culture that respects individuals as intelligent adults who have a valuable set of skills. 

I was reading an article in Business Week today about Netflix.  Netflix has a very interesting culture that not only promotes innovation in the way people rent movies, but also in the way its managers and its staff work.  The founder and CEO of Netflix, Reed Hastings, describes the culture there as “freedom and responsibility”.  Netflix believes its culture is a fully formed adult culture.  To that end, Netflix employees are paid above average salaries, have unlimited vacation, and can determine how to structure their compensation packages.  In exchange for these luxuries, the folks at Netflix are expected to be über performers.  The level of responsibility is very high for individuals within the company.  The marketing director at Netflix says “There is no place to hide”.  If you think this sounds a lot like a place that would embrace Agile practices, you’d be correct.  Netflix has successfully employed Agile practices to create a website that has been rated by independent researchers as number one in the world for customer satisfaction for two consecutive years.

The whole Netflix culture is properly geared to not only support Agile software development practices, but also to recruit the best talent to produce the highest value and quality for its customers.  While most companies go to great lengths to pay their best talent the least amount possible, Netflix does the exact opposite.  They believe in building what their CEO calls “talent density” by allowing their talent hunters to recruit top managers, developers, etc., with the mantra “Money is no object”.  In addition, annual salary increases are tied to the current job market; Netflix constantly amps up salaries to retain their best talent.  H.L. Arledge at Decade Software has stated that “sometimes employees become dissatisfied because they fear they are not getting what they are worth or someone led them to believe that the grass is greener somewhere else.”  Netflix has effectively removed this variable from their talent retention equation.

So, with an adult culture and a highly paid workforce, it's almost inevitable that innovation, quality, and value stream forward from Netflix.  One of the developers at Netflix describes the culture there as very much like the team in Ocean’s Eleven: They recruit the best of the best, everyone gets a good cut of the take, there is the flexibility for individuals to do what they do best, and the whole team stays focused and united on a common goal.  So maybe that’s the key: every organization striving to be truly Agile needs a Danny Ocean at the helm.  It could very well be that Ocean’s Eleven is the perfect Agile model.

Stop the meeting, I want to get off!

Monday, September 24, 2007 10:35:17 PM (Mountain Daylight Time, UTC-06:00)

We’ve all been there before, The Useless Meeting.  They come in many shapes and forms but share one common element:  the unproductive waste of time.  Nothing can be more damaging to an agile team than being interrupted from their valuable work to attend one of these sucking voids. 

Recently, our Scrum Team had an otherwise productive Sprint interrupted by just such a meeting. We were halfway through our Sprint when we received a Friday afternoon email about a mandatory all-hands offsite meeting of our entire group.  Our V.P. had decided that the next Wednesday, we would all gather in Denver to discuss business strategy for the upcoming year.  Yes…our development team was ecstatic to attend, knowing full well it was going to be chock-full of endless PowerPoints with lots of charts and numbers. 

We decided to raise our voices a bit and protest.  “It’s interrupting our Sprint” was the battle cry.  No luck, that didn’t resonate.  So I tried a different tack.  “If you’re going to interrupt our work make it productive.  If you’re not going to cancel the meeting, make it interesting.”  Our V.P. perked up.  He couldn’t fathom the fact that our development team wasn’t interested in charts, projections, revenues, etc.  He immediately visited our office to find out why we were so upset.  We gave a few reasons and suggested that the group offsite meeting should be about the great things his teams were doing.  Make it a motivational meeting.  Get the teams excited about their work.  He left our office agreeing and made a change to the agenda.  He even asked us to give a talk about the power of agile and our success with Scrum.  We still didn’t want to interrupt our Sprint, but at least we thought this wouldn’t be a complete waste of time.  We worked very hard for the next few days preparing a killer presentation about Scrum and how it could benefit the whole organization, not just our team.

We arrived in Denver at noon.  We were sixth on the “revised” agenda.  The offsite meeting started late.  The first speaker was our HR rep.  Not very inspirational, but she kept it short and sweet.  Next up was our V.P.  He talked for about an hour and a half about things that he thought were very important (he was slated for only 30 minutes on the agenda).  Lots of charts, numbers, and broad, sweeping statements.  Next up was one of our senior product managers.  Lots more charts, lots of numbers and all completely meaningless.  In fact (and I must share this classic Dilbert moment with you) at one point, someone asked where his numbers had come from.  His answer was literally (and I quote) “Ummm…from a matrix…in my head”.  After an hour of this babble (slated for 30 minutes on the agenda) he finally sat down.  The R&D pitch was next.  It was a little confusing as our R&D guy had started his job about 1 week prior to the meeting.  He ran over time as well.  At 3:50 PM in a meeting scheduled to end at 4:00, our CEO strolls in and delivers the most lackluster presentation of the day which ends promptly at 4:20.  The meeting is called to an end and we never got to deliver our Scrum presentation.  The team was incredibly disappointed and couldn’t believe we spent a whole day in a useless meeting.

When we sat down for our Sprint Retrospective, I asked how disruptive this offsite meeting was to the Team.  Aside from the obvious waste of valuable time, the Team agreed that the meeting was indeed disruptive to their work.  Some of our developers were deep into solving some complex problems and had to divert their attention to attend the offsite meeting.  Our lead architect and I were also distracted as we had to entertain our V.P. for the entire time he visited our office, and we had to work on preparing our presentation (which of course we never got to give).  The day following the offsite was difficult as well as most of the Team struggled to get back into the flow of their work.  We were tight on time and some of the developers put in time on the weekend just to finish their coding for the Sprint.  The morale of the office was down as well.  Team members couldn’t believe that so much time was wasted with such flippancy.  In the end, we ran out of time in our Sprint and weren’t able to adequately test what was developed.  We had sacrificed quality for the sake of a useless meeting!

The takeaway message here is really for those who manage Scrum teams and it is very simple: Don’t disturb your Scrum Team mid-Sprint unless it is absolutely essential.  The work of the Sprint is very important and it is providing value to your customers.  If you are going to disturb your Scrum teams, you had better have a very good reason to do so.  If at all possible, schedule your disruption well in advance so your Teams can plan their Sprint tasks around your activity.  From the story above, it should be evident that unproductive interruptions can have a negative impact on performance, quality, and morale. 

The message for ScrumMasters is equally important: If managers cannot justify the importance of these time-wasting activities, don’t interrupt your Scrum Team during a Sprint.  This is easier said than done.  Our managers can exert undue pressure on us to mandate participation in these activities.  The best thing to do is to make them very aware of the consequences of their actions.  In fact, if they insist on disturbing the Team, it is probably beneficial to demonstrate the impact of their actions post-Sprint with hard facts so they have tangible evidence of their impact on quality and performance.  As a last resort, you may want to give them a gift-wrapped copy of Scott Adams’ excellent book Always Postpone Meetings with Time-Wasting Morons.

The Daily Scrum: Scrum gratia totus

Friday, September 21, 2007 11:29:32 PM (Mountain Daylight Time, UTC-06:00)

I am the ScrumMaster on our current project, and this morning I had to miss our Daily Scrum meeting. Our lead architect and I were invited to participate in a local Technology Incubator meeting that we felt was very important to our office's growth and development. When we returned to the office, the Team was hard at work diligently tackling the tasks on our current Sprint Backlog. I visited each Team member and asked "Did you guys do a Scrum today?" After some foot shifting, the general answer was "Um...no." I think they knew what was coming next. "So why didn't you Scrum?" "Well, you and Dave weren't here." So...what's wrong with this picture?

The Daily Scrum is a meeting at which the Team answers the three basic questions:

(1) What did you do yesterday?

(2) What are going to do today?

(3) Are there any impediments?

These three questions are intended to help the Team synchronize it's work and determine if anything is blocking them from making forward progress on their Sprint goal. They are not meant to be a status report to the ScrumMaster or the Product Owner. They are meant to be delivered by the Team, for the Team. The Daily Scrum should be a meeting where Team members commit to each other the work they are going to complete each day of the Sprint. The commitment should not be for the sake of the ScrumMaster, but for the sake of the entire Team.

ScrumMasters should do their best to be at every Daily Scrum. It shows a level of commitment by the ScrumMaster to the work the team is doing and demonstrates good leadership for the rest of the Team. However, on the rare occasions when the ScrumMaster cannot be present at the Daily Scrum, Team members should still conduct their Daily Scrum as usual. Each Team member should still answer the three questions.

The Daily Scrum should require no leader or ScrumMaster to ask questions and seek the answers. In fact, Mike Cohn has suggested in his Certified ScrumMaster training class that if an outsider observed a well oiled Scrum team during their Daily Scrum, s/he should not be able to distinguish who the ScrumMaster is. At every Daily Scrum, the Team should automatically begin answering the questions without prompting and without reporting to a ScrumMaster. This reinforces the idea that Scrum teams are self-managing and self-organizing by definition. It also emphasizes the fact that members of the Scrum team are comitted to each other and are collectively responsible for completing the tasks in each Sprint Backlog and for the success of the project.

On the flip side of the equation, it is equally important that a ScrumMaster understand his/her role at the Daily Scrum. ScrumMasters do not "run" the Daily Scrum meetings. They are there to record any impediments that need to be removed for the sake of the Team's progress on their tasks. The ScrumMaster also ensures that the "rules" of the Daily Scrum are being adhered to. The rules at our Daily Scrum are simple:

(1) Timeboxed to 15 minutes

(2) Answer the 3 questions

(3) Not a problem solving session

Beyond those three rules, the ScrumMaster should have no undue influence on the Daily Scrum.

The success of any Scrum Team's Daily Scrum depends on the level of comittment of the Team members to each other and to the project. It also depends on the ability of the ScrumMaster to truly accept a servant leader role during Daily Scrums. After all, the Daily Scrum is Scrum for the sake of all...Scrum gratia totus!

The Bug Bash Sprint

Monday, September 10, 2007 10:10:47 PM (Mountain Daylight Time, UTC-06:00)

In every Sprint we do, we try very hard to produce the highest quality software possible.   However, we’re all human and we still produce software with defects. On one of our current projects, we had reached a point at which our Product Owner wanted to demo the software we had developed so far to his statewide GIS coordinators. He set the priority for our next Sprint to be to fix any defects in our defect list so he could have a smooth demo. We agreed, but also made sure we included a few small pieces of functionality that we could develop to meet our goal of producing some potentially shippable product increment during each Sprint.

 Since we made our move to Rally Software, managing our defect list has become much easier. And moving defects from our defect list to our Sprint backlog was even easier. After we had filled our Sprint backlog with all of the bugs that we estimated we could fix in our two week  Sprint, we created a set of tasks for each defect. The minimum requirement for each defect was that we would verify the defect, fix the defect, test the fix, and have an in-house Product Owner proxy verify the fix.

We were quickly moving through our Sprint backlog and it looked like we’d finish very far ahead of our ideal burndown for the Sprint. We decided that one of our developers would take a look at any new, incoming bug reports from the customer, triage the defects, and create new tasks in the Sprint on an ad hoc basis. At first, I thought this might not be the best idea, and it sort of goes against Scrum’s “rule” of not adding new work during a Sprint. However, given our burndown rate and our success at bashing the other bugs at that point in the Sprint, we thought we should really try to fix as much as we could for our customer’s demo. We told our customer that the Friday at the midway point of the current Sprint would be the cutoff for defects that we could address in the current Sprint. We suddenly received a flurry of defects before the deadline, but nothing that was too hard to handle.

Our developer did a great job triaging the defects as they arrived. We decided that anything that was an enhancement would be placed in the project backlog to be prioritized at a later date by the Product Owner. High priority bugs, as defined by the Product Owner, were placed in the Sprint backlog. We triaged, fixed, tested, and verified nearly every bug. At the end of the Sprint, we successfully fixed all of the high priority bugs in our defect list.

One of the unexpected benefits of this bug bashing Sprint was the knowledge transfer we experienced between developers. Because the tasks were so short in duration, our developers were picking up lots of tasks quickly, and most had nothing to do with the functionality they had developed. This in turn created a need for more communication between our developers than usual. This gave them a much better and deeper understanding of our entire codebase.

At our Sprint retrospective, the development team expressed a high level of satisfaction with the Sprint. They were very happy to have the opportunity to understand each other’s work on a deeper level. The team also decided that instead of fixing defects in drips and drabs, they preferred fixing them in one dedicated bug bashing Sprint before each release. They thought the benefit of the knowledge transfer, and the ability to focus on just defect fixes was significant enough to do more bug bashes in the future. This was a huge indicator for me that our team was really grasping the “inspect and adapt” mantra of Scrum. They had thought about what made this Sprint so productive and decided that it was a practice worth keeping. The bug bash Sprint was a smash for our team. Maybe it can be for yours as well.

Northern Colorado/Wyoming Agile software Meetup group

Wednesday, September 05, 2007 3:25:38 PM (Mountain Daylight Time, UTC-06:00)

I've been kicking around the idea of starting an Agile software Meetup group for the Northern Colorado/Wyoming area.  The Meetup group would allow members to meet other local people interested in Agile methods of software development. We'd probably meet once a month in different locations to promote and grow the local Agile community and to discuss all flavors of Agile practices including (but most definitely not limited to) Scrum, Extreme Programming (XP), Agile Modeling, Adaptive Software Development (ASD), Crystal Methodologies, Dynamic inSystems Development Method (DSDM), Feature Driven Development (FDD), Test Driver Development (TDD), Lean software development, Agile Unified Process (AUP), etc.  We'd probably be based out of Fort Collins and would consider the Meetup group area to run from around Longmont, CO to Laramie, WY, but anyone would be welcome to join in. 

If you're interested in seeing an Agile software meeting group started in the Northern Colorado/Wyoming area, use the voting widget on the sidebar at http://www.chrisspagnuolo.com/.  If you're accessing this post from an RSS reader or aggregator, you can go directly to http://www.polldaddy.com/p.asp?p=99683 to cast your vote. 

If you've never heard of Meetup before, check out the Meetup website at http://meetup.com/.

Meetup