Sprint 2 Demo

Went better than I had thought it would. Less time spent setting up the projector. Definitely request this (projector and computer for demos) to be permanently set up. We had one large functional part fall through this sprint. I thought it would hose a huge part of the demo, but there were enough other items to show continued progress. Some of the items were features done earlier in the sprint that I had forgotten about, some was really just bug fixes, but it all looked good. It was very well received.

A little too well received. I'm feeling some groupthink among the business people. Along the lines of "Looks Great! Ship It!" Not enough questions were asked for my taste, and some key stakeholders were not present. Just shows we need to keep pushing the business side to buy in more completely to the process.

Support from the top

Good lunch with THUD today. RG and I (the two leads on the most important products) cornered him for a lunch. Out to fancy Italian. He must have been sweating bullets thinking we were going to quit or ask for big raises. Explained the process answered scenariors, talked about how it fixed certain concerns. I took the tack of showing how it is similar to what we're currently doing to reduce the perceived risk. Then we explained our increased throughput realized by better resource utilization.

Pushback came regarding documentation requirements (which we don't currently satisfy well) and big up-front analysis and design. The first one was easy. The process can be reflected on and adjusted for new best practices at the transition of each iteration (sprint). Technical doc requirements may be managed as an acceptance test to each feature or a separate backlog item. Up-front analysis is a little touche. That balance between good design up-front and too much design must be struck. The short term sale was to point out how big up-front analysis rarely catches all items and situations, yet also concede its necessity and give scenarios for doing it (sprint zero or 1, as a backlog item). It became a good segue into the XP practice of constant refactoring.

At the end of the day we had extracted a commitment from him to work within the process so long as we meet certain document and quality requirements. I fully expect to need to shoo him away from mid-cycle changes to our sprint backlog. Overall, the strategy of building support and consensus at the bottom, then presenting a unified front with an out containing a political win for THUD proved to be an excellent strategy. All that's left now is to deliver product with it.

Always selling, always closing

Moving this process thru the organization is much more about politics and sales than it is about building software. We're asking everyone at all levels to change the way they think about the business and approach the product. Huge fear of change. For now I'm walking through strategies and talking points on how this is not change, but a different way of looking at the same. Couch it in terms of understandable and current processes and methods. Focus on how what we've already been doing IS agile.

This afternoon RG (lead on the other major project team) and I will be strategizing about talking points. Tomorrow we're going out to lunch with THUD for a little sales pitch. Quick manuvering is required as next week will be a meeting of all stakeholders to reevaluate the product and release schedule. We're agile-entrenched with the worker bees. Now we need a toehold with the managers.

Ahhh, I have been waiting for this

Notify the resistance! We're moving in. THUD is making some noises that I don't like. We've been more or less left alone for a while. Now, after a week straight of meetings, management is starting to make noises about adding process, changing features, shipping product, etc. Unfortunately, people tend to be a little mealy-mouthed around here, so the MO when you try to nail someone down on an answer is to try to make it someone else's decision (preferable someone not in the room), thereby spreading the responsibility and blame. The correlary is that THUD has gone into CYA (cover your ass) mode and made some noises about changing back to the old way of doing things so we have a "predictable path" (old way being non or ad-hoc process, constantly shifting priorities, and trying to hide behind the spec - which never exists in a complete and current form - when things start to go to shit).

Delicate times. Despite approaching the end of a second sprint successful out of the gate, change is still feared. How to bring him in to the process more meaningfully (he's forever in meetings) , give him the illusion of driving micro control (he won't currently accept macro-level controls of setting priorities and trusting the team to make good decisions) without allowing him to fuck up the process. Suggestions?

The Value of Use Cases

I've bad mouthed them in the past, but the last two days have started to thaw my ice. While investigating a bug I discovered that an entire suite of functionality "done" last iteration was, in fact, a steaming pile of shit. How did this happen? We haven't added validation/acceptance criteria to our exit process. I came down pretty hard on the dev who did it, too. Not "leave them in tears" hard, but "are you a complete dumbass?" hard (obviously I didn't say that).

Over the course of reflecting and trying to figure out how not to have it happen again, some of the blame is not his. He worked the standard "hide behind the spec (or lack thereof)" excuses, but when when the app is writing data that is incorrect (i.e. a logger that writes you did something which is not remotely what you did) it doesn't take a genius to know it's not a spec issue. But I digress. What we really need are exit criteria - i.e. happy path use cases. Something that actually identifies in a concrete (electronic) format what it means to be done. Item will be added next sprint, along with developer-tester pairing.

A life of its own

I'll continue the back story later. Great developments today. This thing has really taken on a life of it's own. After some initial confusion and resistance, it has become the accepted way for this project. It seems my strategy of striking quickly while no one was looking and getting the process entrenched has worked. After nominal resistance all impacted parties have at least agreed to a wait and see approach. With the (mostly) successful completion of the first iteration people are settling in to following my lead.

I just spoke with HOSER (Head of Support and Everything Release) about using their high level management process to feed into development. They do weekly prioritizations of all feature and function requests from the field.
Previously one of two things would happen:

• Request/priority never makes it down to development
• All requests make it to development, causing shifting priorities every week
  

In the past the latter item was de rigeur for the organization. As a result dev ran in circles and never shipped anything, or shipped things that were so bad they were essentially non-functional (aka thrash mode). An ironic aside is that THUD (the head uf development) claims, with pride, that the group has never missed a ship date. Right. And the Iraqis have never missed a date in their political process either. THUD was able to start shipping functional products by implementing the former bullet with feature lockdown (aka SDLC). This resulted in happy(er) customers, but frustrated management and didn't fix quality or scheduling problems.

Now HOSER sees a shift where management will get more control, and immediately tried to jump back to the model where management constantly shifts priorities. This is where it gets delicate. The answer is: "Yes you get to adjust priorities, and it happens at the iteration breaks/planning meetings." Now I let have to let that stew and brew before THUD gets sold. He's already expressed a disagreement with allowing a living backlog, so the sale will be delicate.

Backstory

Why go agile? The usual reasons: cumbersome process, missed dates because functional changes weren't addressed early, lack of transparency between management and development. That's the short version.

The longer version starts with an organization in transition. Several applications of dubious quality have shipped, causing endless havoc for our customers. Predictably, people have been making noise about "quality." New products are being introduced and there is strong market demand, so the organization is attempting to scale up for the future.

The head of development has been trying to be hands on with managing the projects - not micromanaging, but also not freeing developers to understand the broader product and become self-directed. As a result, development grinds to a halt every time he is in meetings or out of town (quite often). In the past this was semi-adequate, but with greater demands all development efforts have suffered and the process vaccuum cannot be overcome by simple brute force development.

He is PMI (Project Management Institute) certified and holds SDLC and defined process as the holy grail, even while we continue to fail to meet requirements or full process work products. The saving grace is that there are few direct competitors to the product and the timeframe has been able to slip without business repercussions. When one is overloaded there is a human tendency to try to execute the simplist path. Critical or difficult decisions have been put off until later while immediate concerns are addressed. This has resulted in a group that is eternally treading water, unable to take control or direction.

My moment of clarity that I needed to drive Agile development into the organization came back in December. We were 2/3 thru the test cycle, thinking we would ship end of Jan/Feb. The boss was out for a two or three week vacation and the BIG BOSS wanted to meet for a full status update. About the second question out of his mouth was "Where is Feature X?". We (dev and test) looked at each other, dumbfounded, because this was the first we had ever heard of Feature X.

"Well, we've know about this since August. HOD (head of development) has known that this product won't ship without Feature X."

Waiting to let things like this to blind side us and reacting was no longer an option. HOD had know of this for three months and pretended it didn't exist. Now I ship software. That's what I do. I'm a shipper. If software doesn't ship, I don't feel good about quitting my job and going on vacation for two months. I hate working. Working longer than I had planned makes me angry. It makes me very, very angry. You won't like me when I'm angry.

This was completely unacceptable. And this is when I launched my campaign.

Ready or not, here I come

So we're going agile. Like it or not, I'm going to drag this software development group to the dark side (or from the dark side, depending on your perspective). We're one iteration in on the project, so I'll be backfilling commentary for a little while. Additionally, this will be anonymous as to company and who I am for reasons which should be obvious by now to anyone who is awake. I will tell you that I work for a company that provides medical records processing software so you can have an industry perspective.