Cory Foy, LLC - Agile Training and Consulting - Enterprise Agility Redefined

Posted on February 28th, 2010

[Alternate Title: "If I have to talk about the Scrum Alliance any more, I'm going to vomit"]

Yes, I want this to die. But Jesse Fewell has posted some thoughts around the Scrum Alliance that in fact what they are doing is right, and correct, and they should fix the leaks and stay the course.

I’ll try to be brief with his arguments:

1) “The 75% failure rate of Scrum is one man’s hunch” – Um, no it’s not:

“Why there is such widespread failure is no mystery to us. We’ve been studying why Scrum works and doesn’t work for years”
“I’ve mentioned Scrum because when we see this problem, Scrum seems to be particularly common as the nominative process the team is following. “
“Now many people who call me already have Agile in place (they say), but they’re struggling. They’re having trouble meeting their iteration commitments, they’re experiencing a lot of technical debt, and testing takes too long.”
“Does Scrum really fail to achieve its promise 3 out of 4 times? I am afraid so. I have heard that at the last Scrum gathering this number was bandied about and although it was somewhat arbitrarily selected, seems to have won general acceptance.”
“As XP / Agile / Scrum have become more popular, many teams and individuals have wanted to do them, or “be” them. This has led to a school of Agile methods that wants to be called “context dependent”. The idea is that whatever brand of Agile is under discussion is “too rigid” and “doesn’t fit our context”. So we have to modify Agile because God knows we can’t modify our context.”

If the 75% number was way off-mark, there would be many CSTs jumping to counter it. Heck, even the Scrum Alliance doesn’t counter it. It’s an accepted fact of life. And that’s the troubling thing – it isn’t the number, but the reaction to the number – one of, “Oh, yeah, well, we know”. (And yes, I know some of the quotes above mention agile. I’ll deal with that in a minute)

2) “But what if we instead asked “How many of those who tried Scrum or Agile techniques saw at least some positive improvement?” or “How many teams were in on the whole at least a little bit better off for exploring Scrum?” I bet the answer would be much different.”

Read this. Go on. If you don’t want to read it, look at this quote:

What does a high touch Scrum team do? A high touch Scrum team does
many things to incorporate touch into its daily practice. High touch
Scrum teams:

Hold hands during the Daily Scrum.

Give each other standing backrubs at the start of the Sprint
planning meeting.

Hug each other at the end of the retrospective

How many teams would be, on the whole, a little better off for exploring that? I bet most would be. And what does that tell us?

Nothing.

Because Scrum isn’t about making people “a little better off”:

“Over fifty organizations have successfully used Scrum in thousands of projects to manage and control work, always with significant productivity improvements.” (from Control Chaos)
“With Scrum, these impediments are prioritized and systematically removed, further increasing productivity and quality. Well-run Scrums achieve the Toyota effect: four times industry average productivity and twelve times better quality.” (from Scrum Alliance)

(emphasis mine)

But wait. That last quote is so great, because of what is on that page.

Successful Scrum implementations have many benefits for teams and management. Scrum does, however, require a change from the status quo.

then

These results can only happen, though, when leadership commits to the required changes: teams that adopt Scrum must move away from command-control and wishful-thinking-predictive management.

then

“On the surface, Scrum appears to be simple, but its emphasis on continuing inspect-adapt improvement cycles and self-organizing systems has subtle implications.”

And what are those implications?

Oh. Yeah. That’s the end of the page. Guess you have to figure that out on your own.

3) “The Scrum Alliance is NOT a company that has to choose between a narrow vertical industry or a very specific generic offering. Rather, it is a formalized body that supports an organic movement to “transform the world of work”. It is a big tent that provides tools and products to equip any one person’s niche within that movement. Whether offering an article for how to interact with a large company PMO, or supporting a local user group consisting mostly of GUI designers, the SA responds to what its members ask for.”

I covered that in my last post.

4) “However, I do not think the SA’s execution issues point to having the wrong mission.” – Unfortunately he doesn’t say what it does point to. But I can tell you.

Let’s say I create a new digital camera. People who use it are blown away at how much better it is than every other camera out there. But some people, in fact, many people, aren’t seeing the same results. And when they go to my company’s web site, I tell them:

“The CFmera is a revolution in camera design. However, to use it, note that you have to rethink what it means to be a photographer. The way you shoot pictures has to change, and everything you know about what constitutes being a good photographer is applied differently. If you don’t do these things, then you won’t get the results from the CFmera. Sorry about that.”

Is that their problem, or mine? I don’t offer them any guidance, any pointers, any suggestions. If my goal is to transform the way people capture memories, well, that doesn’t really seem to help, does it?

Scrum does good in the world. Even Alan Shalloway admits that. I’m not saying that Scrum is at fault.

What I am saying is that the Scrum Alliance is at fault. They say themselves that to adopt Scrum you have to alter the fundamental tenants of management and organizational behavior. Right there, on their web site. But I’m not seeing trainers updated with the latest advancements in Organizational Behavior, or Change Adoption. CSMs aren’t getting paths to how to adopt it in their organization and how to deal with the fallout (some CSTs do this, I know). And this is all in the context of software development, where we have a very strong base, and a fairly good understanding of the issues involved.

But Jesse’s key point was that the Scrum Alliance can do both a Depth and Breadth approach. I disagree. It needs to choose. Either it’s about Scrum, the framework, with no underpinnings in software, or it’s about software and helping build that out. I actually prefer the former, and having industry-specific groups split out, each that can control the requirements for their subsegment.

Scrum is a good framework. And it’s a stable one – it doesn’t change. That means that the Scrum Alliance mission isn’t to make Scrum better, but help organizations adopt it. And since they say that to adopt Scrum you have to change things – fundamental things – about your organization, doesn’t it make sense that most of their work would be in enabling people to understand how to make that change?

It does to me. Because if we want to “Transform the World of Work” we ain’t gonna do it by sticking people who have no authority to make change or understand of how to introduce change through a 2-day class and collecting some fees. We do it by a concerted effort to change how businesses think about delivering software, interacting with customers, and running their entire company. That’s change, and that’s power, and that’s something that could theoretically be within the grasp of a money-making machine like the Scrum Alliance.

And an organization doing work like that can gladly have my fifty bucks.

8 Comments

Posted on February 19th, 2010

Jesse Fewell has written a blog post called Scrum Is Dead. Long Live Scrum. His viewpoint is that the old Scrum is dead, and that it is morphing into something new. In the comments, Jesse asked the following question in response to my call for the Scrum Alliance to focus on the Software Community:

Here’s my question though, if the SA isn’t going to be the one to apply agile thinking to lawyers, financial analysts, music producers, and managers, then who will? Are tech workers the only knowledge workers worthy of agile thinking?

Scrum Alliance Background

(If you don’t want all of the background, skip to Cory Gets to the Point)

It’s a good question. Let’s start with why the Scrum Alliance exists. On their web site it says:

The Scrum Alliance is a nonprofit organization committed to delivering articles, resources, courses, and events that will help Scrum users be successful.

But if you scroll down and look at the Form 990 filed for tax year 2008, it says:

Scrum Alliance’s mission is to promote increased awareness and understanding of Scrum, provide resources to individuals and organizations using Scrum, and support the iterative improvement of the software development professions

(Emphasis mine). Further, in section 4a it says:

Scrum Alliance is organized and operated exclusively for purposes of furthering the advancement of the “Scrum” software development process

(Again, emphasis mine). And while the board members aren’t compensated, the managing director made, in 2008, $240,000 USD. In fact, all told, the Scrum Alliance paid out three quarters of a million dollars in “independent contracting” fees.

Not bad for managing a 3-person staff of independent contractors. Full disclosure – I worked as an independent contractor for 6 months for the Scrum Alliance. I imagine my compensation should be available in the 2009 filing form. But, let’s just say, it was pennies compared to the above numbers.

Ok, so now that we see that the Scrum Alliance states their purpose is furthering software development, let’s look at the break down of staff:

Managing Director
Creative Director (new as of this year – Tobias’ position)
Accountant
Membership Coordinator / Website Coordinator
PR
5-person board

And the heart of Jesse’s question becomes, what is the most effective use of a team like that?

SoftwareScrum < Scrum::BaseScrum

Well, let’s look at the existing programs:

Certified Scrum Master
Certified Scrum Coach
Certified Scrum Product Owner
Certified Scrum Trainer
Scrum Gatherings (4-5 per year held around the globe)
Community outreach (funding of User Groups, Welfare CSM, etc)

Which seems to be the right lineup for what Scrum is (3 roles – ScrumMaster, Product Owner, and “Other”). So, in fact, if one was going to set out to “Transform the World of Work”, then keeping the offerings and programs industry agnostic seems like a good thing. Except for one thing.

Magic. Magic is the little dots in the Scrum diagram which shows what actually happens in those 2-4 weeks sprints, and those 24-hour increments. In software terms, Scrum is an abstract class, which doesn’t implement Do24Hours() and DoIteration(). You have to do that. Anyone implementing Scrum has to do that. It’s that magic which distinguishes the successful teams from the non-successful ones. It’s where Lean and Kanban and XP and all sorts of other things get put in. Or, in other industries, where the real work happens.

For example, if I’m a Lawyer, that 24-hour period, or that iteration, I’m going to be going to court, preparing cases, visiting my clients, bribing judges, etc, etc. Or if I’m a movie producer, I’m going to be coordinating shoots, editing previously filmed clips, pampering the actors and actresses, etc.

Which means that if we want Scrum to be successful, what happens during that 24-hour period, or that iteration, has to be successful. If it isn’t, then what happens outside of it – the product management, the demos, the daily stand-ups – doesn’t mean diddly.

new Scrum::BaseScrum() //raise NotImplementedException

(Also known as Cory Gets to the Point)

In fact, in a quote as famous as the Bill Gates “Nobody needs more than 640k” quote, Ken Schwaber says:

I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.

Proof is in the pudding. If Scrum isn’t executed successfully, it doesn’t work. Which means that if we want Scrum to succeed, then we need to be helping those teams figure out what happens in the “magic” areas of the Scrum process.

So far, so good. Jesse’s question still stands – why not help everyone find the magic quadrant?

Because we can’t. The one thing any coach will tell you is that every engagement is different. Some political game. Some quirk about the product. Some jursidictional rule. Some working hour filming requirement in Pago Pago. But, if the Scrum Alliance wants to help, there are at least two options:

Build a Community of People to Implement Scrum In Specific Industries – Let’s recognize that each industry has specific needs, and therefore will need Scrum taught different ways. In fact, it was already recognized with the creation of the PMP CSM class held earlier in 2009 (I can’t find a link right now). But to expand, you need leaders, and to get leaders, you have to seed the community. The existing CSP/CST program isn’t setup for that at all. So drop it. Stop centralizing the certifications from CSMs all the way up to the CSTs and push that out to the industry-specific subgroups.
Get Scrum Working Well in One Industry – Scrum started to help software teams, and its stated purpose is to help software teams. Yet 75% of the teams aren’t getting the benefit. Hello? Is anyone listening? Why don’t we find how to fix that problem before spreading out to lots of other industries?

Here’s how I look at it. You have a board and directorship of software industry leaders. You have thousands of people in the software industry using Scrum. You have people begging for better ways to do software. And you have your founder saying that 75% of teams aren’t getting the benefit. You want to look at all that and say, “Let’s branch out?”

Look over to your right. That’s a laser going through a prism. Alright, that’s what happens when a laser goes through a prism. It gets split into lots of shiny objects. That are so very pretty to look at. And hear about. Now watch this video:

The Scrum Alliance can be a shiny object, pretty to look at, fun to talk about, neat for a demo or two. Or it can be a focused cost and quality-overrun killing machine by helping the software industry find out what is in those magic circles which is causing 3/4s of the users to not get the benefit. Or, to put it in real numbers, find out why of the members who paid collectively a tad over $2.6 million in 2008, three-quarters (or around $2 million dollars worth of fees) aren’t getting the benefit they should be getting.

So, Jesse, that’s why. The Scrum Alliance can’t hold the keys and want to open the doors at the same time. Either fix what is broken, or split off an industry specific group which has control over the certifications for that industry and can fix it for them.

Personally, I’d prefer to see the certifications dropped and the Scrum Alliance focus on fixing the industry-wide pandemic we call software development. But that’s just me.

Edit: William Pietri points out that lasers are monochomatic, and so when shot through prisms, they split into multiple beams as shown here. It’s still shiny objects with less power than the original – just better represented. Thanks William!

9 Comments

Posted on February 17th, 2010

There’s been a lot of talk in the agile community recently around Software Development Practices, or Engineering Practices, being in Scrum. Scrum, if you’ll remember, is brought up around the 3/3/3 – 3 Roles (ScrumMaster, Product Owner and “Other”), 3 Artifacts (Burndown, Product Backlog, Sprint Backlog) and 3 Ceremonies (Sprint Planning, Daily Stand-Up, Sprint Review).

The orange dots you see may really look like the Scrum Alliance logo, but really means “magic happens here”. That’s because Scrum is a framework, designed for application in any industry. At the Scrum Gathering in Munich, they even had a lawyer present how she used Scrum as a part of her practice.

So, if Scrum is a framework, design to be applied to any type of business, why all the fuss about engineering practices? I’ll save you a lot of headaches and just say that software development teams happen to be the primary people who use Scrum, and for them, they need more than “magic happens here”.

Certified Scrum Developer

And, that’s OK. The Scrum Alliance back in 2009 even started down the path of creating guidance for developers. They called it the “Certified Scrum Developer” program, and they got together a group of people like Ron Jeffries, Chet Hendrickson, Brian Marick and Jim Shore to hash out what the heck a CSD would even mean. And what they came up with was more along the lines of a long-term commitment – not one you could teach in a 5-day class, but instead something which led down the practitioner path. In fact, internally there was a big push to say that if they were going to be “stuck” with a CSD program (more on that in a moment) then they should define a CSDP (Certified Scrum Developer Practitioner) which could likely pass the muster of what the community was pushing for.

At Agile 2009, Ron and Chet held an open-space session on the CSD program. At the time, I was the community liaison for the Scrum Alliance, and was there as well. What I saw was a community fed up with where we all stand as developers and development teams. And that desire to change meant there was a lot of passion into the CSD program. And honestly, I think it could have been a great thing. Love it or hate it, (and you can see which side I’m on) the CSM has spread through large organizations and smaller companies like wildfire, and the CSD/CSDP program stood a chance of actually being worthwhile and riding the coattails of the CSM to have a serious impact in the fundamentals of how corporate software is built.

The Scrum Alliance and the Community

One of the challenges the Scrum Alliance faced was community support. There was – and is – a lot of distrust around the Scrum Alliance. I was asked to join after the Orlando Scrum User Group debacle to help with the outreach and communication to the community. I truly believed that the Scrum Alliance was trying to be much more open, honest and transparent in their operations. They certainly were challenged in that none of the people working for the Scrum Alliance had a software background, and so hadn’t been much involved in building software communities (not counting board members). But I was willing to push hard for them in the community because I believed in the direction they were going.

Internally, however, there was a lot of strife going on. Staff members were being told to go in two different directions, and to top it all off, here I was, practically the antichrist to the Scrum Alliance (at least based on what the staff told me). And then, just before the Scrum Gathering in Munich in October, was the final showdown. It led to Ken Schwaber leaving the Scrum Alliance, and appeared to also have Jim Cundiff leaving as well. Lowell Lindstrom became the Managing Director, and the people in Munich were greeted by a board they hardly knew, a CSM Test that no one could say for sure what was going on, and unsatisfied feelings by some (OK, OK, I know, Andy’s hard to please anyway. ;))

Transparency

It seemed like good things might still be on the horizon. The Scrum Alliance had the chance to really break free. They still had the support of the community on the CSD program, and a community energized by the open space session in Munich. What happened next surprised many people. They simply stopped communicating. 22 out of 26 CST applicants were rejected (with very little reason why). The questions around the exam were left open. The CSD program went nowhere and was eventually dropped as a priority due to lack of support from the board or management. As the community liaison, I started finding out information by blog posts and emails from the community rather than internal communications.

In the meantime, Ken Schwaber moved on to create Scrum.org, which caused even more confusion. And, to top it all off, the CSD program – the one I said was dead earlier? It was still moving forward under Ken and Microsoft. All of the alphas and betas of the course still happened.

Towards the end of the year the Scrum Alliance got Mike Cohn on as a board member, and hired Tobias Mayer as “Creative Director”. In general this is viewed as a very good thing. However, the transparency still doesn’t seem to be there – for example, Jim Cundiff is back as the Managing Director and Lowell has stepped back down, but there haven’t been any real announcements around that (although they could be just waiting for the Orlando Gathering). And to cause some more confusion, Mike Cohn has been telling classes that a change is afoot to the naming of the certifications.

Professional Scrum Developer

Which leads us to Ken’s announcement that Scrum.org is putting together a Professional Scrum Developer (PDF) program. The program looks strangely similar to the one I saw around the CSD program, so I imagine it is the same. This particular version didn’t get the input that the community put together which doesn’t make it good, bad or ugly. Time will have to tell, but right now it’s the only thing going, and it’s being heavily promoted in the Microsoft / .NET space (with versions planned for Java as well).

Whether it takes off or not, the truth is the Scrum community has a fracture in it. The support for CSD has moved on to other things, the main figurehead of Scrum is doing his own thing, and it isn’t clear what’s going to happen next. I do know Luke Hohmann has been working closely with the Scrum Alliance using his Innovation Games to help them decide next steps.

But all of this has led us to forget about those developers and team members, working in Scrum Teams, building software, who need guidance. As Mike Cottmeyer points out:

I do not believe it is right to offer certification when there is not standard or a published set of competencies. We should not certify more than Scrum is willing to include in its body of knowledge.

I still strongly believe that helping teams build better software should be the primary focus of the Scrum Alliance – not “Changing the World of Work”. And while I have no idea what they have planned, this is my wishlist:

Cut the “C” - We get it. It’s a cash cow. In Munich I learned there were Scrum Trainers making $400k USD a year + just doing CSM trainings. 2 day class * 15 students * $1500 a head – you do the math. But the CSM needs to die. Now. Make the CSM worthless, and put all of the focus on the CSP.
Refocus on the development space – Software Teams doing Scrum need help and guidance. Should those teams go to Scrum.org? And, if so, then why shouldn’t they go there for everything?
Change the focus of the Scrum Alliance – According to the Scrum Alliance site: “The Scrum Alliance is a nonprofit organization committed to delivering articles, resources, courses, and events that will help Scrum users be successful.” What we really need is leadership in the Scrum Community.
State the intent for CSTs – Is the goal to have only high-quality CSTs, or to actually reach out to the community? I know people are concerned that if the market is flooded with CSTs, that the cost per class won’t be as high. I say, “That’s great!”. The cost for an instructor shouldn’t be based on the scarcity of instructors around the topic, but about what the instructor brings. People like Jeff Sutherland, Mitch Lacey, Ron Jeffries, Tobias Mayer and others deserve every penny they get.
Be transparent – for Realz, yo. Community-Vet the CST applicants. Be open about changes in management and the board. Clue us in on what is going on with name changes and what you all think about them. The Scrum mailing list is a great start.

I suspect that lots of news will happen out of the Orlando Scrum Gathering, so we should all watch that space closely. In the interim, keep pushing for transparency and integrity in certifications, and remember – the Scrum Alliance members pay the Scrum Alliance’s salary ($50 a year for CSMs, $250 for CSPs, $750 for CSCs, $7500 for CSTs). So stay involved – either through the Improvement Communities, the Mailing Lists, or good ‘ol moaning and whining. If we want change, we need to make that change happen. So let’s do it.

3 Comments

Posted on February 15th, 2010

Want to really mess up your adoption of agile methods in your organization? Here are 10 mistakes I’ve come across with teams that will ensure an utter failure, Dilbert style.

Not Reading the Principles of the Agile Manifesto – Everyone likes to quote (and misquote) the Agile Manifesto. But the manifesto is more than just the four value statements – there are also a set of principles behind it. And since you are reading manifestos, read the Software Craftsmanship Manifesto as well.
Not knowing what you want to change – This is the number one question I ask teams. What are you trying to change, and why? Imagine you picked up a book on carpentry, and several expensive tools and said, “This is to make my house better”. I’m pretty sure my wife would be not-so-happy if I did all that and then found out we had to dig up the entire septic system because the problem was a clogged drain.
Not having a solid product vision – Agile methods are designed to increase your quality and decrease your time-to-market. But if you don’t have the foggiest clue what you want to deliver or why, then all the sprints and iterations in the world is just going to cause rework and waste as you discover what you really do want. As an example, I coached a team recently who needed a way to keep features out of the mainline for 6-8 months (until the next release) because there were times when features were completely dumped at the last minute. That’s not waste, nor is it an agile problem. It’s insanity that needs to be fixed.
Not accounting for the learning curve – There are lots of grand claims made about agile, Scrum and Lean software adoptions and I’m here to tell you that they can be true! Those kinds of increases aren’t going to be seen out of the gate, however. Changing into a collaborative process from a heroic, blame-oriented culture takes a lot of adjustment – and requires time to allow trust to be built up.
Not having a plan for resistance – Your laggard adopters are going to want solid data, and are going to resist you every step of the way without it. Be prepared to have heart-to-heart conversations, and to find ways to provide ways to include resistors – or ways to move them out.
Surprises for management – “Surprise! The release you promised for July of 2010 will now be in November of 2013!” Keep management informed of what is going on, and find ways to help them with the conversations they need to have. After all, we may all find Gantt charts unrealistic and a waste of time, but if you help your manager generate them from burndown charts for her executive meetings, she may help support your team even more.
Not recognizing the value system of the organization – As I wrote in Reward Systems and Organizational Change there are deep, embedded assumptions in how people get recognized / rewarded / paid. The unfortunate norm is tying individual performance appraisals to raises. If you want a highly collaborative atmosphere, you can’t rely on rewarding individual employees the same way. Further, the changes you are trying to bring may not even match the organizational values. Trying to bring openness and honesty into a place which values closed-door, buddy system style meetings and exchanges will only lead to frustration.
Local Optimization at the expense of the organization – Anyone who has tried to bring change to a team can likely point out several areas that could not be improved due to organizational constraints (read: politics). To work effectively, agile adoptions need to be able to look at the entire value stream, including marketing, system administrators, database administrators, sales teams, etc. It’s not enough to just shove some development teams into training and hope for the best.
Using techniques for collocated teams with distributed teams – You may have a wonderful business case for how you distribute your development team all over the globe. But as you adopt agile methods, you’ll start discovering just how much time you have to spend communicating with the teams just to get the basics across. Stand-Ups, Planning Poker, Retrospectives, and Big Visible Walls are all vital techniques that require much more overhead to accomplish – with quite a loss in the richness of the information.
Forgetting that formulaic approaches need to be adapted – Sure you can adopt the 3/3/3’s of Scrum. Or the practices of Extreme Programming. But as you begin to gain context and insights, you and your team should be adopting and adapting the practices to fill the gaps. If you just shove forward without reflecting on what you’ve done, and what you want to do, you’ll end back up in a status quo and a bunch of team members who can quit and go out to tell the world how bad agile is.

What mistakes have you come across?

3 Comments

Posted on February 14th, 2010

Last week I spoke at the Pasco County .NET User’s Group here in Florida on Debugging .NET Applications with WinDBG and SOS. Afterwards we all met at a local restaurant and were talking about agile topics – the good, the bad, and the downright ugly. The leader of the group, Greg Leonardo then said a great statement that I immediately posted:

Scrum taught us one thing – we’re still doing waterfall!

The statement itself is actually not a knock at Scrum, or agile topics in general. It’s a realization said time and time again that you can’t just adopt some tools and practices and hope for the best. You have to be willing to change fundamental things about your organization – something that isn’t easy to do.

As an example, let’s say that you decide to adopt Scrum in your organization, and you utilize iterations, story points and burndown charts. You notice over time that your charts look something like this:

The red line is what the team “should” be accomplishing each iteration. The blue line is what they actually “are” accomplishing. The one thing you should notice (other than the two lines not meeting) is the shape of the blue line. It’s not smooth. In fact, it kind of looks stepped. Almost like the team is doing…waterfall!

That’s likely because they are. Each iteration things are not getting done, done, and so it builds up until a big batch is completed at once. Except that a batch is almost never completed at once. There are invariably bugs that crop up, and since code has already been built on that batch, the code has spread out further into the base, and takes more work to fix. Of course, the fixed code isn’t finished until the next batch, when more issues are found, etc, etc.

Worse, this kind of a stepped appearance to burndown charts is typically the graphical manifestation of a deeper systemic problem. And that problem is that change is hard, especially when the organization doesn’t really want to change.

If you are wondering if you are really doing waterfall inside of an agile methodology, you can ask yourself questions like:

Have we ever talked about a “development sprint” and a “testing sprint” and an “acceptance sprint”?
Has the phrase, “I had to stop work on Feature Z because the QA team found a bug in Feature Y I finished up earlier this week” ever come out on a stand-up?
Can anyone articulate the vision, strategy or goal of what we’re doing?
Are you using a burndown chart, but seeing it burn up?
Are people surprised daily by the things that come up at the stand-up meeting?
Is management surprised at the end of an iteration that things aren’t done?
Does management even care that things are done during an iteration (as long as you darn developers get it done by the release!)?

I’m sure I could turn this into a funny checklist with scoring numbers where you could get a badge saying, “We’re Scrummerfallaristic!”, the fact is that it isn’t funny when you are in the middle of it. The good news is that once you recognize the challenge, there are lots of resources to help you. The book Fearless Change is a great start. Reading books like Lean Software Development, Implementing Lean Software Development and Lean-Agile Software Development are great ways to understand the challenges of batch processing and having a lot of work in progress, and how to go about fixing it. For Scrum specific information, Succeeding With Agile is one of the better books out there, but I highly recommend looking at a holistic view of your teams and your organization.

And when worse comes to worse, you always have the option to change your organization, or change your organization. But hopefully you can stop the stairs of waterfall and instead navigate the journey to the bliss of agility.

3 Comments

Posted on February 12th, 2010

Last night I gave a presentation for the Pasco County .NET User’s Group on Debugging .NET Applications with WinDBG and SOS. We covered some basics of the CLR and Memory Management in .NET, and then how to troubleshoot Crashes, Hangs and Memory Leaks when dealing with .NET applications in production.

Debugging NET Applications With WinDBG

View more presentations from Cory Foy.

If you are interested in learning more, I’d highly recommending checking out Tess Ferrandez’s blog where she has a set of labs for really digging into this stuff. If you are trying to debug an application or service that is crashing on startup, the blog post I mention is on my site, and the KB article for automatically attaching a debugger to a service on startup is KB824344.

Finally, you can download WinDBG from the Microsoft Web Site, and you can download the sample application here. The slides are available on SlideShare or you can download the PowerPoint presentation. And if you are interested in learning more, we offer a training class in WinDBG and Production .NET Debugging which includes much more detail in the fundamentals and a series of hands-on labs to really understand even more. Simply contact us for more information!

No Comments

Posted on February 10th, 2010

If you ask most any organization, they will tell you how much they value their customers. How much they want their feedback. And they show this by having events, or conferences, or demos and show off the latest widget, or plan, or feature to their customers. And then they wait. Wait for what, you might ask?

The amazing flood of Astoundingly Amazingly Great Ideas from their customers. Perfectly fit into bite-sized questions that answer exactly what the company wants.

And they end up waiting for a long time. Baffled, the company leaves the conference frustrated at the lack of communication from their customers. Not surprisingly, the customers also leave frustrated at not feeling like the company was interested in what they had to say.

Yesterday I attended a public session on “light rail” – basically a local train system – for the county just south of us. I say “county”, but Hillsborough County is actually bigger than 7 states in the US. Throughout the session, I learned that the team working on the light rails proposal – made up of County staff and HARTLine (the local bus company) staff – was looking for the following information from the public meeting:

Should we put a referendum on the ballot to increase the sales tax to pay for transit improvements?
What mix of transit (train, bus) and non-transit (bike paths, roadway) projects should be included?
What routes do people expect to use often? (For example, this meeting was held at a very large retirement area, so many of them wanted to be able to go from there to the local Veteran’s hospital which is about a 50-minute drive)
What do people like or not like about the proposed routes?

These are all very good questions, and the answers would certainly help the county leaders figure out the next steps. But that’s not what happened. Instead what happened was the following:

Thanks for coming out! Here’s the plan we’ve spent 2 years putting together. As you can see, our maps and documents clearly outline the impact to every single area in our county without actually having maps and documents showing the impact to your specific area. The referendum will be on the November ballot, and we’ve allocated 75% of the funds for transit activities, and 25% for non-transit activities. The list of each of the funded initiatives is here. Any questions?

Any questions? Ok, so the above wasn’t a direct quote – but it does cover a summary of what happened. They sat everyone down, showed them a video about the “plan” (not “proposed plan”) and at the end, split them into two groups to “answer their questions” about the transit and non-transit activities. At no point did they raise that this was a proposal they wanted feedback on or that they wanted to tweak. Nor did they ever just list the questions they wanted. The list above came from my observations of the group and the feedback from the leaders in the meeting.

Not surprisingly, there was a lot of animosity in the meeting as people felt a “plan” had been pitched that they had no say in. This is not different from other “focus groups” or “roundtables” where it’s more of a marketing gimmick than a chance to truly collaborate.

Now, imagine if the meeting had been started by the leaders showing a “transportation proposal” and simply listing the questions above – the ones they really wanted the answers to. Even better, the transit/non-transit projects and the route plans could have been broken down and the people in the room could have helped prioritize them – either by having whiteboards, or by using various Innovation Games such as “Buy a Feature” or “20/20 Vision”. Suddenly the participants have a focus and a realization that they can have some input into the process. Before you know it, the company is getting great feedback and suggestions, the participants are feeling heard, and everyone starts feeling much more satisfied that they could express the things they wanted to express.

So the next time you are gathering a group of your customers together, think not only about what you’d like to hear from them, but how you can truly engage them and communicate that what you’d like isn’t just a comment, but a partner.

No Comments

Posted on February 8th, 2010

Retrospective Stickies on Music Stands One of the more interesting things about facilitation is that you have to be prepared for just about anything. Retrospectives and exploratory sessions can generate very strong emotional responses – from yelling, to crying, to utter silence. However, most retrospectives are about improvement – part of the kaizen philosophy. At the end of the day, the group expresses their emotions, we find things within their scope of power they can act on to change, and the group gets a little better. However, the outcome isn’t always about improvement – sometimes it can be about dissolution.

A couple of months ago I was asked to facilitate a discussion for a local church’s council members. After nearly 12 years of work, they had come to the point where it was time to close their doors from an emotional, personal and financial perspective. As you can imagine, a church has a strong emotional bond for its members – especially those who spent many years of their life building it up. Over the course of several hours we were able to move the council through an objective look at their current state while honoring the necessary subjective and emotional content they felt the need to express. By the end, with the group literally in tears, they had all agreed on a course of action.

When dealing with these kinds of emotional situations as a facilitator, there are some steps you can do to help make things go smoother:

Take Control – This is key no matter what you are facilitating, but especially true in high-emotion situations. You need to be able to focus and direct conversations. In this session, both the existing pastor and the council president initially stayed standing with me in the front of the room. I “allowed” it – until they couldn’t control their need to jump into the conversation and answer questions, at which point I asked them both to sit down
Understand the situation – I’ve had some experience with building churches, and with the challenges this particular group faced. This isn’t about being an expert, but instead about being able to empathize and predict where the conversation is going
Understand the grief process – When a facilitation involves end scenarios – closing of a business, shutting down of a team, talking about death – you should be prepared for working through a grieving process. While the grieving process is talked about to be in stages – denial, anger, bargaining, depression and acceptance – it can be much more complicated. In this scenario it meant that I had to be prepared for the group to outright reject the discoveries they were making – and then to be angry with them, then to bargain through them until we got to acceptance. Amazingly, I saw very clear delineations throughout the session:

Denial – This stage is interesting in that emotional reactions can lead people to reject outright facts in front of them. One key to getting through denial is gently keeping the information in front of them. The picture above is from the facilitation session – the yellow stickies were all of the group-identified challenges, compared to the greens which were the positives they had. This helped keep the group reminded that we weren’t meeting because they thought there was a problem – there was a problem.
Anger – Once the true facts of their situation came to light, there was a lot of anger. This was generally expressed in the form of blame – blame towards each other, towards the church body, towards other groups that were involved. The key here is to allow the expression of anger without allowing it to devolve into personal attacks. One particular challenge was that people who were still in the denial phase felt they needed to “defend against the attacks”.
Bargaining – As the group began to accept where they were, the bargaining started in. “Maybe we can just make it through Christmas.” “We could sell X, Y and Z, and have each of us contribute $10,000.” While this kind of exploration is healthy – and perhaps vital at an earlier stage – it’s important to recognize that the group needs to move through this, and as a facilitator keeping back to the facts the group developed will help this.

Stay Calm – When emotions are running high, anything is bound to happen. I’ve had people walk out of emotional retrospectives, yell and scream, and seen physical outbursts. One of your most important jobs is to maintain a safe environment. This does not mean shutting down all outbursts, since different groups may have different cultural norms. Instead, carefully watch the other participants to see if they are pulling back, and ask others to hold their expressions – or to leave, if necessary.
Allow the group to decide – As a third-party not caught up in the emotional aspect you may feel the need to point details out, or get the group to a vote, thinking that will help. The best outcomes I see are when the group feels it is time to decide. You may be able to help this with timeboxed activities, where you can give gentle reminders of where they should be at, but ultimately the group has to feel they came to the decision through their discussions. With this group, I timeboxed the exploratory exercises into short segments, and had an overall timebox for the session that we agreed on which helped keep the group focused during the more open time periods. While I was fairly stringent on the shorter timeboxes, I was willing to allow the general conversation to go a little longer if needed. At the end, the group decided to do a vote to close – and unanimously voted to do just that.

Dealing with any kind of reflective activity can generate strong emotional responses. It’s up to you as the facilitator to not only guide the group – but to stay out of the emotional whirlwind. By doing that, you can help the group discover the decisions they need to make and allow them the room they need to work through those decisions.

No Comments

Posted on February 5th, 2010

It’s official! Scott Allen had a scheduling conflict, so I’ll be presenting IronRuby for the .NET Developer at MIX10 March 15th-17th, which is the culmination of a whirlwind of speaking events before that – Tools for Agility and Lean/Kanban Principles at the Southwest Florida Code Camp Feburary 27th, and a Blackberry 101 / J2ME TDD Session at the Day of Mobile in Chicago March 6th. Hope to see you at one or more of the events!

.net, Announcement, IronRuby

1 Comment

Posted on February 2nd, 2010

This evening I did an online presentation for the Ft. Lauderdale .NET User’s Group on ~~DataDude~~ ~~Visual Studio Team Edition for Database Professionals~~ Visual Studio Team System Database Edition showing how you can use the refactoring, testing and data generation features to do Test-Driven Development in your SQL Server Databases. I’ve put the slides (which include screenshots from all of the demos) up online (PDF), or you can view it on SlideShare. Enjoy!