Agile Hermeneutics

Someone recently asked me a really good question: what worries or concerns you about Agile? There’s no wrong answer, except maybe “everything” or “nothing.”

One of my concerns is the mis-application of the Agile Manifesto.

“Working software over comprehensive documentation”

This doesn’t mean that all documentation is taboo. It’s about documenting the right things at the right time, because documentation is a part of delivering working software. Collaboration and communication between team members and entire teams is crucial to success and documenting how the hell you built a feature or ran a test should be a part of the Definition of Done.

If you’re on my scrum team, don’t tell me “That’s so not Agile” when I ask if you’ve documented the parameters for your new feature. Telling someone how to use your product or how it works is part of your job.

“Responding to change over following a plan”

This is not an excuse to inflict an infinite amount of churn on a team. Any agile methodology has boundaries to provide stability, whether it’s limiting WIP in Kanban or timeboxes and commits in Scrum. Respect them or fail.

“Individuals and interactions over processes and tools” 

This does not mean that process is antithetical to agile. Chaos != agile. Your sticky notes and sharpies – and your brain – are tools just like any of the various software programs out there. “Just let me do the work!! Don’t make me use a tool!” is something I hear regularly, but when you have multiple teams, cross dependencies, and complex (and sometimes shared) code bases, things like planning and forethought are crucial.

Tools like any of the number of agile project management SaaS offerings out there may add some additional work (I avoid editing active workflows like the plague) but they’re invaluable.

“Customer collaboration over contract negotiation”

This one I don’t have much insight into, except to say that demos to customers every sprint seems to cover a multitude of potentially missed deliverables. Nothing in my experience to argue about here.

“Anyone want some coffee?”

Thanks to http://www.agileproductowner.com/ for the link.

Rabbit Trail!

I have a theory I’m working on about the mis-interpretation of the Agile Manifesto, so I wanted to read a bit on its history. I came across this phrase from the manifesto history page:

“…marketing, or management, or external customers, internal customers, and, yes, even developers, don’t want to make hard trade-off decisions, so they impose irrational demands through the imposition of corporate power structures.”

Agile and power structures? I’d never put those two categories together, but it seems brilliantly obvious, and now I gotta go read up on my Foucault, et al….

Cynical Scrum Humor

I totally love Scrum, and I love irony, especially when there’s a bit of truth to keep you humble. This is a glossary that turns agile terms on their heads: 
http://www.yuriy-zubarev.com/blog/2012/04/24/cynical-agile-scrum-dictionary.html

One of my favorites – the second definition of Scrum Master:

Scrum Master

1. a person who removes stumbling blocks and in so-doing eventually self destructs
2. a person with a stopwatch, a squeaky toy, and a whistle

That’s what I need! A squeaky toy!

One that I think is particularly poignant:

Agile Manifesto

1. a document that tipped the balance from analysis paralysis to refactor distractor
2. a proof that principles are often mistaken for rules
3. a license for avoiding documentation, and not having a plan

Go enjoy and laugh at yourself.

Release Planning is a Good Time for Doodling

 

… and if it’s a good time for doodling, it’s probably not the most effective use of Engineering time. (Not to denigrate the doodles, they’re good brain fodder. I’m still working on the one to the left.)

The devs and QA at my company have long complained about the uselessness of release planning. I’ve disagreed for an equally long time from a business angle. It’s important to figure out what won’t make it in, given the snapshot of time/people/priorities. It informs the PM priorities and scope, which means we can inform customers earlier about what they will or won’t get and when. I get it.

But honestly, this time around, I think it’s a waste of time, and we should either eliminate it entirely (not likely) or seriously streamline it.

Shooting from the hip:

1. We have an entire week dedicated to sprint planning. This is way too much. We should make it a day or two at most and hopefully do this during the hardening sprint so that we don’t interrupt the team’s cadence.
2. This isn’t detailed sprint-level breakdown. It’s a SWAG-fest where 40 point estimates are, in my book, allowed to stand, because sometimes you have to actually start doing the work before you can estimate it well.
3. We don’t need the entire team involved in release planning. It’s not a commit – it’s a snapshot. It’s not detailed – it’s point-and-shoot. You can do this with a subset of your team or, even better, your lead dev, your lead QA, the PO and the SM. Leave the rest of the team out of it.

This is definitely one of the areas where I disagree with the team-centric nature of Scrum (or at least my perception of it.) Once you view the release planning session as something to help PM prioritize, rather than a multi-month commit, you don’t need team consensus. Just do it and keep moving, because few things irk an agile development team more than vague meetings. Save the consensus and negotiation for sprint planning, where you’re actually committing to something.

Every Team’s a Snowflake

I referenced a blog post by Sinclair Schuller in my last post, where he says there are at least four key questions when transitioning to SaaS:

1. How often do we release?
2. Do we offer a preview release?
3. Do we support multiple versions?
4. Do we have a parallel release environment, or are we constantly merging new features straight into the existing production world?

I can answer those questions for our current model: 2-3 months, no, yes, and parallel. My company makes several distinct but dependent products: basically we provide a server, the APIs, and a few clients. Right now, we have a release model where all of these release in lock step. (In theory. Reality has been different for some time.) In the shiny new SaaS world, each of those (server, API, clients) will release differently. Each client can release separately as well, on its own  cadence.

Bottom line, the amount of variation and differing schedules here is potentially huge. Which is fine – as long as we have a standard meta-process that makes the end result uniform for all products. Right now, that process is highly dependent on branches and build numbers: devs build, QA tests, POs accept, and then POs give me the accepted build numbers and that’s what goes on to the release directory for safe keeping. Those build numbers are gospel, but my understanding of where we’re headed is that the build numbers are nearly irrelevant.

So. Don’t really know what to do there, assuming that I’m actually understanding things properly. This goes back to my previous question list – are we hiding new features via if/else statements or something, where is that done (api? client?) etc. I have a meeting with one of our architects early next week, and I’ll start throwing these questions his way (as well as the four questions at the beginning of this post) and that should be instructive.

Once the whole meta process is figured out, I’m not entirely sure how I’ll managed all of these schedules and releases while still running two scrum teams. Handling the releases now is a fair chunk of work, and I’m not looking to expand that part of my job. My long-term vision is to have scrummasters on each team in charge of managing the release of that team’s product, but we’re not there yet. Right now all of our scrummasters are also developers or managers, and I don’t want to put more on their plates. But…  maybe we’ll get there sooner than I thought!

The Internet Confessional: Why SaaS is Scary

Forgive me, Lords of Cobol, for I have sinned.

Why am I putting this out here? Mainly because, as this blog post by Sinclair Schuller notes, there is almost NO discussion of release management in SaaS. It was a relief to find Sinclair’s post, if for no other reason than to validate my  sense that yes, transitioning to SaaS does indeed have a significant affect on releases and versioning. In light of how little is written on this, I’m going to document my company’s transition here in the hopes that it helps others in my shoes.

My company is careening/dragging its feet (depending on your perspective) towards adopting an actual SaaS deployment model. This is, on the whole, an awesome development and one that we absolutely need to succeed. I’m in full support of it. It’ll be good for everyone in the company:

• Developers and QA can keep delivering value with fewer interruptions
• Easier prioritization on Product (no need to fit things into monolithic chunks of code and time)
• Tech support can get bug fixes to customers faster
• Client managers won’t have clients waiting for months on a new release
• etc.

There’s a fair bit of evangelism needed around all of this, but I’m confident we’ll get there, and fast.

But.

SaaS, right now, is stressing me out because I’m the release manager. I don’t know how to transition away from a versioned monolithic model, I’m still trying to get my head around GitFlow, and I have some major shifts in practice coming at me fast with a lot of stakeholders to satisfy. I’m not even sure that my concerns are coherent, but I’ve gotta start somewhere, so here are a few things that come to mind when teams say “we’re going to release every sprint” or “we don’t actually have builds like SVN anymore…”

1. We have bugs. Yeah, all software has bugs, but seriously? Production? Right away?!
2. How am I supposed to track this every single sprint? Just a list of new features? Version number? Documentation?
3. Are we enabling the new features every single sprint or are we hiding them?
4. If we’re hiding them, how?
5. What does that mean when we actually make these features available to customers? and…
6. How is this different than what we do now?
7. If we’re hiding them, why are you rolling to master and not release anyway?
8. If we’re not hiding them, what are you thinking?! New features every sprint would require a fundamental change in how we deploy to customers and how we educate them – which is definitely possible, but…
9. Did we forget that we have customers still using IE6? These are not people who upgrade quickly and may not accept a SaaS/rapid release model.
10. Did we think about how we would educate Tech Support, our Sales team, our client managers, and our Marketing team?
11. Did we think about how we would have to do that EVERY sprint if you roll to production with enabled new features?
12. Or did we decide that we want to work this way because it’s developer-friendly?

Enough for now. That was productive, I put words to some worries. But what can I do about it?

Well, I’ve started having hardcore conversations with our architects about their vision for how our products and releases work now, and how they’ll work in the future. I’m a visual person, so I’ve also started creating my own diagrams to show the Before and After. From that, I’m hoping to start drawing out the differences between the two models, and use that to figure out how what affects the nitty-gritty details of the release process. I’ve watched the CodeSherpa’s video on GitFlow, just to try to get my head around the tool most teams are or will be using, and understood about 25% of it. But it’s a start. Right?

So please, if you have advice, let me know.