Ship It

So I came across Ship It recently as Urban Slang because I’m a Game of Thrones Junkie and recently Briane of Tarth (my hero) and Tormund the wilding guy are starting a romantic relationship.

Evidently Ship it means:

Screen Shot 2016-05-23 at 10.48.11 AM.png


So of course, as an Agilist I’m automatically thinking Ship It means to ship a Potentially Shippable Increment of software.  But I like adding hastags #cute #romantic #lovey and the all important #POapproves to PSI.

Recently I was explaining my company’s product roadmap to a client and they said to me ‘I am amazed at how much confidence you have in the roadmap.’  And I said, “Well, product said it would happen, and so it will.  They always ship on time and they always commit to what they are going to ship.”

And I had to stop for a second and realize  that my expectations for software development had totally gone agile.   Meaning …I now trust in the team, and trust the delivery.  I remember never trusting in the delivery; only vetting a real production date when we were well past UAT and giving people a month timeframe in which UAT could start.

And now, I get excited about features before they’re in production.  I Ship them so much and brag about them like they are my babies. Wow…transition.

This…is scaled agile folks.  It’s why I drank the kool aid.





Using Agile Tools Beyond the Office

Right now I’m using a google doc to manage my budget – I know – its sooo not  But anyway..

I’m really encouraged by this kid who is treating his whole semester as an iteration and has created a Kanban board that that feeds user story cards for all of his upcoming papers and labs onto the board based on a due date.  He’s got a query on his board so that he only sees cards on his Kanban board that are upcoming in the next seven days.

At the start of each semester he basically has a personal planning session where he inputs all of his due dates from his college syllabi as user stories.  He tags them and gives them dates.  Then, he’s off and running.

He’s even using his Cumulative Flow diagram to see where he might need to plan extra time to do work.

I’m so used to living in Rally and Jira on a day to day basis that I hadn’t really thought about transitioning my live into one of these tools. It makes sense to do so, I already have the knowledge.  And both Rally and Jira have free editions.

And my life needs this – I’ve got to move this year and plan a wedding.  I think if I don’t do this, I might lose my mind.  I’ll let you know how it goes.

In the mean time – watch this video and marvel at the ingenuity of youth!


This is my brain on agile OR help me I can’t shut it off

Agile is changing my brain.

I didn’t think that was possible after 40, I mean isn’t science telling us that everything is hardwired by 21?

I realized it in a church committee meeting the other day.  A leader in the committee is stepping down. So, the question now is – who is going to be the next leader?  Good question, groups need leaders Blue-brainright? But before I started thinking about who that person could be, my brain got all counter- cultural and I blurted out “Why do we need a leader, can’t we just self-organize, or maybe just rotate leadership?

Some people agreed, some didn’t.   We talked some more. And then we started talking about developing our agenda document, something that has lots of updates, and takes some time to build.  And again, my brain was like on some agile questioning trip and I blurted out, “Why do we have to do this documentation? Seems like overhead to me.  Can’t we just get a trello board, put up some cards and have the leadership check in on the cards?”

So now..some folks were looking at me funny.  I understand.  It was I who two years earlier gave a lengthy presentation to the same group of people on the importance of creating a project charter.  That was about a 1.5 hour talk on creating a document.  So now…here I am pushing for no documentation?

Then…then…I started asking about our mission.  I asked to see the vision statement. I asked the pastor to explain it.  I then stated that our team should have a say in developing our vision, that it should source democratically from within the group as well as from church leadership and I think I said (probably a bit rudely too) something to the pastor like “Well, we need to be involved in developing this vision with you.”

Yeah, so, I’m having a hard time in my real life (not at work – real life )

  • not breaking things down into minute chunks that can be accomplished in a few hours   i.e. – not Costco, but onesie twosie trips to the grocery store, every other day.
  • not expecting all leaders to collaborate i.e. – assuming that leaders need to work collaboratively with the team (as good product owners should right?)
  • not assuming all teams function better when they self-organize – i.e. maybe we don’t need that council president
  • questioning the need for documentation and extra process overhead everywhere – i.e. “No I’m not giving to that charity, they want paper checks for goodness sake.  That means half of what I’m giving them is going to processing.  When they reduce overhead…then I’ll give.”

But what’s really scary but also kind of cool ….. I’m getting ok with ambiguity.  So with the same church group, we are still figuring things out.  We don’t know what the future will really look like.  We haven’t picked a new leader yet, we’re thinking our process and mission may change significantly…nothing…nothing feels solid right now. But, since we have the next iteration…er…few weeks planned out, I’m ok.  Shrugging it off.  We’ll figure it out.

This is my brain on agile







Scrum “Master” Has to Go

Scrum Master has to be the most un-Agile term.

I mean really what do scrum masters do?


  • Facilitate dialogue, brainstorming, interactionfacilitator
  • Demonstrate good positive people behaviors like cooperation, lack of blame, fact based conversations and encourage the team to do the same
  • Manage team adminstrivia like updating systems (or bugging/reminding their teams to do so) or handling reporting up the SAFE chain
  • Provide top cover aka removing impediments and preventing distractions

Mountain Goat software describes the role like this:

The ScrumMaster is there to help the team in its use of Scrum. Think of the help from a ScrumMaster as similar to a personal trainer who helps you stick with an exercise regimen and perform all exercises with the correct form. A good trainer will provide motivation while at the same time making sure you don’t cheat by skipping a hard exercise. The trainer’s authority, however, is limited. The trainer cannot make you do an exercise you don’t want to do. Instead, the trainer reminds you of your goals and how you’ve chosen to meet them. To the extent that the trainer does have authority, it has been granted by the client. ScrumMasters are much the same: They have authority, but that authority is granted to them by the team.


He’s a master: “These are not the developers you’re looking for”

The pervading wisdom, common knowledge says that Scrum Masters are ‘Servant-Leaders’ who ‘Carry Water’ for their teams.

Further, Agile is all about Self-Organizing teams with flat hierarchies, where team members are encouraged to be accountable, to work together to determine the path forward, to take work without being told to. They are groups of self-directed people, not without leadership but not with total command and control.

So why, why, in this world of Servant-Leaders who Facilitate and Bring Water to Self-Directed teams do we still use the word scrum MASTER?

Master has all kinds of connotations and I can only think of one that’s positive. Here’s my list:

Master Negative Connotations

He's a master: Totally not trying to be on his team. "And WILLLLL update jira!!!!"

He’s a master: Totally not trying to be on his team. “And now….you WILLLLL update jira!!!!”

  • Master and Slave as in the American Slavery Experience
  • Master and Servant as in the English Aristocracy Experience
  • There’s another one bought on by the acronym SM but this is a G rated site and I’m not going there

Master Positive Connotations

  • Someone whose skill is at a superior level

The positive connotation doesn’t really fit in our definition of scrum master. If it did, then we’d be saying in effect that scrum masters were people who are incredibly skilled at scrum. Yet scrum is agile and should be open to the input of a self-directing team. So even if I master our scrum process today, that doesn’t mean that after the next retro I’ll still be the master of that process.

But I don’t think that’s what was intended with the word scrum master anyway.


He’s a master: “Have those unit tests complete when I return from the hunt.”

I think what was intended was probably to step away from the term Project Manager and invite the idea of something of a call player from Rugby, which is where the ‘scrum’ term originated. But I can’t find a ‘scrum master’ role in Rugby, so I’m really not sure here. I’m guessing. Maybe someone can inform us in the scrum lore as to why we all call the scrum master the master.

Anyway – The negative connotations of master are enough to throw the term out the window. A slave master?  Sorry – I’m not gonna be part of that process. An English Lord, well maybe, if I could live in Downton Abbey.

Master is not the energy we are reaching for in scrum or agile.

People, can we get a new term here?

Here are a few suggestions:

  • Team Facilitator
  • Team Mediator
  • Scrum Coach

I’m sure there are many more. Feel free to post them here or on twitter.

But seriously, scrum master – that’s gotta go folks.

Baby RACIs: Keeping it small, keeping it real

I’m not sure how many of us actually use RACIs.


I’ve found that using the RACI in a project charter (or the beginning of project)  inventively results in it being so very high level that its not really about solving problems, its about elaborating spheres or domains of work. This is good for the start.

Poor Ball – Clearly has not been Consulted about his role in the game. Somebody should tell him…..

However, once you  really get into the project, people start bumping into each other.  Some things don’t get done or communicated. Emotions get frayed and then eventually that results in a situation where people want to do a BIG RACI where they sit and solve communication problems by bringing all parties in the room and working through how things fell through the cracks.  These sessions usually start with someone coming with a huge list of tasks along with a lot of people, so therefore the RACI is BIG.

These BIG RACI meets can become massive blames sessions, so I’m not a big fan of doing a BIG RACI.


baby raci

What I’m finding is that using a targeted baby raci can pinpoint problems, zeroing in on just the small amount of people and few tasks needed to remove a communications blocker and or clarify who does what, to get the team moving again.  This is really a MVP (minimal viable product)  approach to RACIs- meaning do the smallest amount with the least of amount of people to solve immediate small problems.

For example, UAT seems to be a place where things can get confusing.  Its also when the project is getting ready to go live, so a lot of new players enter which makes communication channels explode.  A RACI done at the start of the project may have said something like this:


Task QA LEAD PM Product Owner UAT Testers QA Testers
Quality Assurance
Perform Functional Tests     R   A    C   I    R
Manage UAT     C   R   A  R   C


This is good to start.  But then when you get into UAT it gets complicated.  Maybe there’s office politics about who can talk to whom.  And then there are the QA leads and offshore teams that need to be started/stopped and perhaps a vendor who needs to drop to the UAT environment and then the infra guys who control the UAT environment and before you know it – somebody is mad at somebody.

Babies are cuter anyway

Babies are cuter anyway

At this point, take the people responsible and accountable only.  Try to keep it small and work out a baby raci.  In this example, the problem is that the ‘managing uat’ task above has really exploded into a bunch of very detailed tasks.   For baby racis I think that its good to get super specific on these tasks because usually the specificity will surface where the confusion lies.

Doing a baby RACI could look like this:


Task QA Lead Infra Lead BA PM UAT Testers QA Testers Product Owner
Quality Assurance
Creating Test Scenarios  A  I  R  I  C  C  I
Creating a UAT Test Plan based on the scenarios  R  I  C  R  C  I  A
Communicating with users on a daily basis about their findings  C  I  R  R  C  I  R, A
Troubleshooting their Findings  A  I R  R  I  R  I
Scheduling pushes to Staging and Production with Release Management  C  C  I  A, R  C  C  I
Halting a release date to solve UAT issues  R  C  I  R  C  C  A
Communicating decisions about UAT with The Vendor  R  I  C  R  I  I  A, R


And then…you’re done.  Just stop there with the baby raci.  No need to figure out the full gamit – just solve the issue at hand.


A Church Does the baby raci

Another team that does this well is my church.  I’m on a team that helps with administration and I’m not sure how the pastors learned about RACIs but we use them really effectively.  Basically if there is a new mini-project the pastor will send out the following type of message:

To: All Teams

Fr: Pastor

Subject: Some Improvement we need to do

Body: Hi folks, we are going to do ‘improvement a’.  After discussion we feel that this is the best RACI for this project:

  • Person A – Accountable
  • Person B  and Person C – Responsible
  • Person D, E, F – Consulted
  • The congregation – Informed


Baby raci guidelines

Give it a try.  Next time you have a block in your project, and people are confused and getting angry, try to take an hour or less, get a few people in a room and whiteboard out a baby raci.  Some guidelines:

  • R&A Only: Include only the Responsible and Accountables to build the RACI.
  • One Area: Focus in on one problem area, not the whole project.
  • Specificity is key:  Be very specific in the tasks.
  • No Blame: Careful not to get into the blame game.  Try to keep people focused on the tasks to solve for past failures, but not on the emotion and frustration of the past failures.  You may want to lay the ground by saying something like ‘We are going to focus on clarifing what needs to be done and understanding our relationship to the tasks.  Things may have gotten dropped but this meeting is to figure out, as a team, how we can help each other do these tasks effectively, not to blame each other about the past.’
  • Confirm: Share with the Consulted and Infromed after the meet for confirmation before you make it official.


One way to bridge the gap from raw requirements to user stories

I’ve been on two Agile projects now where the following has worked.  Not perfect but it helps to solve a problem that I’m seeing a lot at the beginning of projects. That is, how do you get from raw requirements and use cases into INVESTic user stories and epics?


Think – you’ve got a new product, you’ve got stakeholders in the room; they are brainstorming.  They come out with a bunch of requirements.  They leave.  The dev team now has to figure out how to take this long list and turn it into develop-able requirements.  We’ve got a lot of tools for dealing with stories once they are baked; estimation sessions, planning pokers etc.   But the tools don’t seem so clear when you are trying to make sense of requirements at the inception of a project.  So here’s one way I’ve seen that works:

Assuming you’ve got that list of requirements I mentioned earlier:

Move requirements into Features


Analyze the requirements as follows:

  1. True Need Analysis – Figure out what the real requirement is behind the ask.  This is usually the domain of the BA. What is the user really asking for?  For example, they may say they want a button that says ‘eject’ but what they really want is a workflow where they can stop the process at any point.
  2. De-Duping and Current State-ing – Figure out what requirements are really mimics of each other.  For example, one user asks for an ‘eject’ button while another asks for a ‘Stop Process’ button. Merge when possible.   Also – it could be that you’ve already built what the requirements are asking for – your current state meets the need.  So give the requirements a current state pass as well.
  3. Grouping and Aggregating – How do requirements  logically fit in with other requirements? What requirements are similar enough that they could be parts of the same feature in a product?  Spend some time grouping those requirements together and give that feature a name.
  4. Acceptance – Determine how you’ll know that you’ve accurately completed this requirement. Check the language of the requirement because sometimes the requirements themselves can become acceptance criteria.
You’ll come out with a not fully baked list of features which you can go take back to the stakeholders for verification.

Prep the Features in a Spike


To fully Prep requirements, create a spike.

What is fully Prepped?  It means that the feature has documented and clarified use cases, user personas who will verify that the feature meets their needs, high level technical specifications if needed, definition of done (preferable with acceptance criteria), and a priority as provided by the Product Owner. Basically it answers what we’re building, who we are building for, how they will use it.

Handover the feature to the development team 

Usually this is accomplished through a separate spike meeting, with a presentation of the findings. Following the handover, the dev team should be able to breakdown the feature into epics and stories and the (currently well documented and doesn’t need to be rehashed here) Agile process takes place.
How are you handling this move from raw requirements into epics and stories?