Standing Up Agile at a Lean Startup

I left my previous gig for greener pastures when the grass under my feet started to look less green and more napalmed.  The new gig is small, lean, and full of super smart and motivated people burned in previous lives by failed old-school SDLC practices so was leaning toward the anarchy side of the project management spectrum.  But one cannot ship product without a plan and shipping good, solid, reliable product to customers is the #1 job of any company - be it software or a gaming company or what have you.  We need a method to get from point A to point B.  

As an architect, in my old age, I discovered interest both complex distributed systems and how human beings interact with those systems.  How can we tweak the knobs just enough to preserve tight-knit culture and hit targets and produce something everyone is proud to put their names on?  To me, project management is another system of inputs, outputs, pipes and filters - another way to architect the system to build a better machine. I had just come from a gig where Agile had managed to both spectacularly succeed and spectacularly fail -- some my fault, some others.  But I knew what parts of Agile brought value.     

There's two ways to look at project management: a way to push engineers into a system of metrics, control, and dehumanization and a way to foster communication and teamwork around a project while setting reasonable expectations.  Having been an engineer turned into a 'resource' bean-counted by management and then found myself sitting in meetings fighting over 'resources' - my friends - my desire to commoditize well-educated smart engineers is low.  Project management can be a force for evil but also a force for overwhelming good.  Solid project management with good communication and a feel of buy-in from everyone on the team can take a good team who knows where they want to go but not entirely how to get there to a great team that can climb mountains, land on mars, and change the world.  

Agile gives me:

  • A way to manage expectations for everyone -- engineers, stakeholders, customers.
  • A way to capture ideas for the product, put them somewhere, and have a reasonable way to talk about them, analyze them, and give them proper airing.  (Aka "Put it on the backlog.")
  • Keep a focused list of work to get to a working and great deliverable.
  • Keep everyone focused on the near-term goals.
  • Iterate features fast like crazy people toward a great product.
  • Fail fast.
  • Squeeze bad ideas out of engineering and replace them with better ideas while keeping the scope of the ideas manageable.  
  • Foster open communication.
  • Have short horizons so we can discussion the state of the project and change course when needed.

Well run Agile is magical.  I wanted to bring Agile in because I had seen it succeed.  I want to be sensitive to the culture in place.  I want it to be team-owned.  And I want this to succeed.  Synergy!  

Tools:

Bringing in the big bang wall of multicolored 3x5 cards, the giant pin-boards, the pens, and the actual standing up part of standups wasn't going to happen.  Neither was Atlassian's Jira.  Jira is fantastic for big companies where burn-down charts help to predict where multiple teams all working to a common goal will land based on release goals.  But Jira is a huge headache getting setup, working with it, and dealing with its schizophrenic personality.  I went with three tools:

  • Trello
  • Atlassian Confluence
  • Slack

Trello is more a Kanban board than a Scrum board but it can be pressed into service if all its little knobs are twisted.  And while, without plugins, it lacks burn down and velocity charts, what it does have in spades is user-friendliness.  It's flexible for setting up different boards around different classes of workflows for different projects: sprint boards, project backlog boards, bug tracking boards, and even individual boards to break down particularly complex stories.  It also works for shopping lists, travel planning, marketing planning, deciding when various blog posts are published... and it has mobile clients.  The comment feature captures details about a story.  One can use Trello to plan anything with a little bit of cleverness.  

As a hint: trello allows story cards to have checklists which are amazing for tasking.

Confluence is an architecture trick.  The most powerful weapon in the architect's arsenal is not static code analysis or a UML/CAD tool but a good wiki.  While I'm not a fan of Jira, I'm a big fan of Confluence.  While it doesn't allow Markdown in its hosted version, it is feature rich and dead simple to use.  Communication is key and a hosted wiki is a lovely place to host online communication with diagrams, documents, instructions, and information.  Also, the dirty trick is architecture archeology -- never delete pages from Confluence.  Just move them into an archeology folder.  Keep where you've been.  DRY.

Slack pre-dated me but it's the best Agile tool in the world.  It gets everyone out of email and into a continuous chat with a history and a back-scroll.  Email is a blight on mankind.  It slows down teams and gets everyone in the habit of merely answering email all day when an issue can be solved with a sentence in a chat.  Integrated chat keeps teams working and communicating together.  Slack is one of the best investments a company can make.  It's too bad one can't get Slack without a corporate account.

What I threw out:

Being highly sensitive to the company's anarchistic leanings, I took out anything that felt over-whelming project-managery.  Agile has a large number of ceremonies and decorations -- we call them meetings but they're ceremonies.  The trick is to figure out which to drop of and which to keep.  When introducing Agile to a brand new team who is a little raw from too much project management, I cut it to the bone.  What went out the window?

  • Walls of 3x5 cards
  • Time estimation
  • Burn down charts
  • Making well worded customer-focused stories - not stories themselves, just pedantic wording
  • Hyper detailed tasking

Time estimation and burn down charts are an important part of Agile, true.  Velocity allows the team to tune how much work it can take in a Sprint.  They are also a part of stress and heart burn.  And, worse, in a lean startup doing new things, stories are near impossible to estimate even after breaking them down into tasks because the tasks devolve into "and underwear gnomes happen here."  I have to trust these are well seasoned engineers who know what they are doing and are driven to hit deadlines.  And fail fast; see above.  Keep sprints as tight as possible, fail fast, and don't worry about the numbers of hours to do X.

Also, tasking is a little light.  That's a point to iterate on.  It will get better as time goes on.

What I kept:

But I kept most of it!  

  • Daily Standup
  • Sprint Planning
  • Release Planning
  • Backlog Grooming
  • Sprint Retrospectives

... and hoping, soon, Sprint Reviews.

Getting up and going was a little rough at start.  There was a huge product backlog to work through and priorities to set and stories to put into priority order.  Some stories turned into swimlanes.  Some were dropped, renamed, or broken into pieces.  It happens.  

I was also faced with the challenge with a globally distributed team on radically different time schedules so daily standup is held in a Slack channel used for Agile administration.  We maintain a ruthlessly managed product backlog and a release backlog so sprint planning is a focused affair designed to be two hours or less.  The team is involved with the backlog grooming.  All boards are available to everyone all the time on trello.  

Sprint Retrospectives are incredibly important for crafting an Agile process around the team and the company culture.  That way the Scrum Master can listen to what everyone has to say about the previous scrum and try to make some changes to improve process.  Just like code, Agile is an ever improving process where we always try to get better.  Again, we use a slack channel for the process to collect feedback and then the results are preserved on a Confluence page so we can have history.  

Overall:

Selling Agile to the team was more a process of doing instead of telling.  I can teach classes in Agile and Agile Methologies all day long but it does not mean anyone listens... it's a process, not a proscription.  We just started doing.  The initial meetings to get the backlog in order and perform a round of release planning were painful but it's rapidly becoming less-so: ritual becomes habituated.  Engineers realize that they own the process as a group so everyone is compelled to contribute.  And there is nary a Gantt or PERT chart in sight.  Nor will there ever be one.  Nor will there be big bang architecture from an ivory tower architect.  SDLC is dead.  Long live short iterate-test-release software cycles.  Us architects need to learn how to design within the context of a sprint.

What we have gotten out of the process so far has been tangible: clarity, we know exactly where we are against our deadlines, clear communication to everyone in the company what is being delivered, and a plan.  Lower blood pressure.  Focus.

Overall, since the team is small and little overhead bureaucracy, Scrum Master duties take up only about 25% of my time -- the rest of my time is focused on architecting solutions and writing code, as it should be. There's probably quite a bit more I could add like how to deal with Issues in Github while trying to track stories and bugs in Trello (solved with a product), and how to deal with sprint planning when half the team is on the other side of the world.  But suffice to say, the process is remarkable as long as the touch is light and the management overhead is non-intrusive.

In other news, I also brought in Continuous Integration and Continuous Delivery, the other half of the Agile toolkit, but that's for another day.